UMTS Family

AMR

3GPP TS 26.101. (You can download all the ETSI files from www.ETSI.org)

The Adaptive Multi-Rate (AMR) speech codec is a mandatory codec for for third generation systems, and will be widely used in cellular systems. This codec is a multi-mode codec with 8 bit narrow band speech modes with a bit rate between 4.75 and 12.2 kbps. The sampling is 8000 HZ and processing is done on 20 ms frames. 3 AMR modes are already adopted standards of their own:

• 6.7 kbps mode as PDC-EFR
• 7.4 kbps mode as IS-641 codec in TDMA
• 12.2 kbps mode as GSM-EFR

Described below is a generic frame format for the Adaptive Multi-Rate (AMR) speech codec. This format is used as a common reference point when interfacing speech frames between different elements of the 3G system and between different systems. Appropriate mappings to and from this generic frame format are used within and between each system element.

The AMR header appears as follows:

Frame Type
One of the eight AMR codec modes, one of 4 different comfort noise frames, or an empty frame.
The following frame types are available:

FQI
Indicates whether the data in the frame contains errors.
0 Bad or corrupted frame
1 Good frame

Enlarge	More Details

Interested in more details about testing this protocol?

BCC

3G TS 24.069 version 3.1.0 www.3gpp.org/ftp/specs

This protocol is a variant of the GPRS BCC protocol. The Broadcast Call Control (BCC) protocol is used by the Voice Group Call Service (VGCS) on the radio interface. It is one of the protocols of the Connection Management (CM) sublayer (see GSM 04.07).

Generally a number of mobile stations (MS) participate in a broadcast call. Consequently, there is in general more than one MS with a BCC entity engaged in the same broadcast call, and there is one BCC entity in the network engaged in that broadcast call.

The MS ignores BCC messages sent in unacknowledged mode and which specify as destination a mobile identity which is not a mobile identity of that MS. Higher layers and the MM sub-layer decide when to accept parallel BCC transactions and when/whether to accept BCC transactions in parallel to other CM transactions.

The broadcast call may be initiated by a mobile user or by a dispatcher. The originator of the BCC transaction chooses the Transaction Identifier (TI).

The call control entities are described as communicating finite state machines which exchange messages across the radio interface and communicate internally with other protocol (sub)layers. In particular, the BCC protocol uses the MM and RR sublayer specified in GSM 04.08. The network should apply supervisory functions to verify that the BCC procedures are progressing and if not, take appropriate means to resolve the problems.
The elementary procedures in the BCC include:

• Broadcast call establishment procedures,
• Broadcast call termination procedures
• Broadcast call information phase procedures
• Various miscellaneous procedures.

All messages have the following header:

Protocol discriminator
The protocol discriminator specifies the message being transferred

Transaction identifier
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:

TI flag
Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.

TI value
The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface.

Message type
The message type defines the function of each BCC message. The message type defines the function of each BCC message. The following message types exist:

Interested in more details about testing this protocol?

BMC

3GPP TS 25.324 (You can download all the ETSI files from www.ETSI.org)

The Broadcast/Multicast Control Protocol adapts broadcast and multicast services on the radio interface. Broadcast/Multicast Control (BMC) is a sublayer of L2 that exists in the User-Plane only and is located above RLC. The L2/BMC sublayer is assumed as transparent for all services except broadcast/multicast. At the UTRAN side, the BMC sublayer consists of one BMC protocol entity per cell. Each BMC entity requires a single CTCH (Common Traffic Channel), which is provided by the MAC sublayer, through the RLC sublayer. The BMC requests the Unacknowledged Mode service of the RLC. It is assumed that there is a function in the RNC above BMC that resolves the geographical area information of the CB message (or, if applicable, performs evaluation of a cell list) received from the Cell Broadcast Centre (CBC). A BMC protocol entity serves only those messages at BMC-SAP that are to be broadcast into a specified cell.
The BMC protocol does the following:

• Storage of Cell Broadcast Messages.
• Traffic volume monitoring and radio resource request for CBS.
• Scheduling of BMC messages.
• Transmission of BMC messages to UE.
• Delivery of Cell Broadcast messages to upper layer (NAS).

The BM-SAP provides a broadcast/multicast transmission service in the user plane on the radio interface for common user data in unacknowledged mode. The BMC sublayer interacts with other entities. The interactions with the upper layer/U-plane and the RRC layer are specified in terms of signaling messages where the signaling messages represent the logical exchange of information and control between the BMC sublayer and higher layers. They do not specify or constrain implementations. The (adjacent) layers connect to each other through Service Access Points (SAPs).
The messages are signaling messages. There can be 3 types of signaling messages, Request, Indication and Confirm.
The messages structure is of 2 types:

Between BMC and upper layer (U-plane):
BMC - Generic name - Type: Parameters.

Between BMC and the RRC entity:
CBMC - Generic name - Type: Parameters.

The following message types are available:

BMC Header:

Coding of message types:

Interested in more details about testing this protocol?

BSSAP+

ETSI TS 129 018. (You can download all the ETSI files from www.ETSI.org)

BSSAP+ for UMTS is the Base Station System Application Part protocol. The Gs interface connects the databases in the MSC/VLR and the SGSN. The procedures are used to co-ordinate the location information of MSs that are IMSI attached to both GPRS and non-GPRS services. The Gs interface is also used to convey some circuit switched related procedures via the SGSN.
The basis for the interworking between a VLR and an SGSN is the existence of an association between those entities per MS. An association consists of the SGSN storing the number of the VLR serving the MS for circuit switched services and the VLR storing the number of the SGSN serving the MS for packet switched services. The association is only applicable to MSs in class-A mode of operation and MSs in class-B mode of operation.
All the messages described here use the SCCP class 0 connectionless service.
When the return option in SCCP is used and the sender receives an N_NOTICE indication from SCCP, the sending entity reports to the Operation and Maintenance system. The behaviour of the VLR and the SGSN entities related to the Gs interface are defined by the state of the association for an MS. Individual states per association, i.e. per MS in class-A mode of operation and MS in class-B mode of operation, are held at both the VLR and the SGSN.

The BSSAP+ header appears as follows:

The message type uniquely identifies the message being sent. The following BSSAP+ message types exist:

Each message type has specific information elements

Enlarge	More Details

Interested in more details about testing this protocol?

CAMEL

ETSI TS 101 044. (You can download all the ETSI files from www.ETSI.org)

The Customized Applications for Mobile network Enhanced Logic (CAMEL) provides the mechanisms to support services of operators, which are not covered by standardized GSM services even when roaming outside the HPLMN (Home Public Land Mobile Network).
The CAMEL feature is a network feature and not a supplementary service. It is a tool to help the network operator provide the subscribers with the operator specific services even when roaming outside the HPLMN. In this specification, the GSM Service Control Function (gsmSCF) is treated as being part of the HPLMN.
The regulatory environment in some countries may require the possibility that the gsmSCF and the HPLMN are controlled by different operators, and the gsmSCF and the HPLMN are therefore distinct entities.
In the first phase the CAMEL features support:

• Mobile originated and forwarded calls
• Mobile terminating calls
• Any time interrogation
• Suppression of announcements

Note that CAMEL is not applicable to Emergency Setup (TS 12), i.e., in case an emergency call has been requested the gsmSSF is not invoked.
The CAMEL mechanism addresses especially the need for information exchange between the VPLMN (Visited PLMN) or IPLMN (Interrogating PLMN) and the HPLMN for support of operator specific services. Subscribers who have subscribed to operator specific services and therefore need the functional support of the CAMEL feature are marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL support, the appropriate procedures, which provide the necessary information to the VPLMN or to the HPLMN, are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a gsmSCF, which is controlled by the HPLMN.

The CAMEL protocol is an upper layer protocol which is carried over the TCAP protocol as the data portion. In an analogy to common protocols we can parallel the TCAP to the header and the CAMEL to the rest of the decode. The message types are in the format of asn1 messages. Like most asn1 applicable protocols, the CAMEL protocol has many message types that carry a high volume of data.

Enlarge	More Details

Interested in more details about testing this protocol?

CC

ETSI TS 124 008.(You can download all the ETSI files from www.ETSI.org)

The Circuit-switched Call Control protocol (CC) must be supported by every mobile station. If a mobile station does not support any bearer capability at all then it responds to a SETUP message with a RELEASE COMPLETE message.
In UMTS only, integrity protected signalling is mandatory. In addition, all protocols use integrity protected signalling. Integrity protection (activated by the network) of all CC signalling messages is the responsibility of lower layers and is performed using the security mode control procedure (3GPP TS 25.331 [23c]).
In CC, more than one CC entity is defined. Each CC entity is independent from the other and communicatse with the correspondent peer entity using its own MM connection. Different CC entities use different transaction identifiers.
With a few exceptions protocol here relates to the call control protocol only with regard to two peer entities.
The call control entities are described as communicating finite state machines which exchange messages across the Radio interfaces and communicate internally with other protocol (sub) layers. This description is only normative as far as the consequential externally observable behaviour is concerned.
Certain sequences of actions of the two peer entities compose "elementary procedures" which are used as a basis for the description here. These elementary procedures may be grouped into the following classes:

• Call establishment procedures
• Call clearing procedures
• Call information phase procedures
• Miscellaneous procedures.

The terms "mobile originating" or "mobile originated" (MO) are used to describe a call initiated by the mobile station.
The terms "mobile terminating" or "mobile terminated" (MT) are used to describe a call initiated by the network.
The structure of the CC protocol is as follows:

Message Type
The messge type, the following message types are available.

Enlarge	More Details

Interested in more details about testing this protocol?

FP

3GPP TS 25.435, 25.427 (You can download all the ETSI files from www.ETSI.org)

The Frame Protocol (FP) is one of the UTRAN Iur and Iub interfaces user plane protocols for Dedicated Transport Channel (DTC) data streams.
DCH frame protocol provides the following services:

• Transport of TBS across Iub and Iur interface.
• Transport of outer loop power control information between the SRNC and the Node B.
• Support of transport channel synchronization mechanism.
• Support of node synchronization mechanism.
• Transfer of DSCH TFCI from SRNC to Node B.
• 3.84 Mcps TDD - Transfer of Rx timing deviation from the Node B to the SRNC.
• Transfer of radio interface parameters from the SRNC to the Node B.

The transport layer must deliver Frame Protocol PDUs.
When there is data to be transmitted, DCH data frames are transferred every transmission time interval from the SRNC to the Node B for downlink transfer, and from Node B to the SRNC for uplink transfer.
An optional error detection mechanism may be used to protect the data transfer if needed. At the transport channel setup it shall be specified if the error detection on the user data is used. Data Transfer procedure is used to transfer data received from Uu interface from Node B to CRNC and vice versa.


The general structure of a DCH FP frame consists of a header and a payload.

General structure of a Frame Protocol PDU
The header contains a CRC checksum, the frame type field and information related to the frame type.
There are two types of DCH FP frames (indicated by the FT IE):
- DCH data frame.
- DCH control frame.
The payload of the data frames contains radio interface user data, quality information for the transport blocks and for the radio interface physical channel during the transmission time interval (for UL only), and an optional CRC field.
The payload of the control frames contains commands and measurement reports related to transport bearer and the radio interface physical channel but not directly related to specific radio interface user data.

UL Data Frame Header

The structure of the UL data frame header is as follows:

DL Data Frame Header

The structure of the DL data frame header is as follows:

Header CRC
Result of the CRC applied to the remaining part of the header, i.e. from bit 0 of the first byte, (the FT IE) to the bit 0 (included) of the last byte of the header) with the corresponding generator polynomial the length of the field is 7 bits.

FT
The FT describes if it is a control frame or a data frame. The length of the field is 1 bit. Its value can be:
0=data
1=control.

CFN
The CFN is an indicator as to which radio frame the first data was received on uplink or shall be transmitted on downlink. It can have a value of 0-255 and is 8 bits long.

TFI of first/last DCH
TFI is the local number of the transport format used for the transmission time interval. It can have a value of {0-31} and a length of 5 bits.

Enlarge	More Details

Interested in more details about testing this protocol?

GCC

This protocol is a variant of the GPRS GCC protocol. The Group Call Control (GCC) protocol is used by the Voice Group Call Service (VGCS) on the radio interface within the 3GPP system. It is one of the protocols of the Connection Management (CM) sublayer (see GSM 04.07).

Generally a number of mobile stations (MS) participate in a group call. Consequently, there is in general more than one MS with a GCC entity engaged in the same group call, and there is one GCC entity in the network engaged in that group call.

The MS ignores GCC messages sent in unacknowledged mode and which specify as destination a mobile identity which is not a mobile identity of that MS. Higher layers and the MM sub-layer decide when to accept parallel GCC transactions and when/whether to accept GCC transactions in parallel to other CM transactions.

The group call may be initiated by a mobile user or by a dispatcher. In certain situations, a MS is assumed to be the originator of a group call without being the originator. The originator of the GCC transaction chooses the Transaction Identifier (TI).

The call control entities are described as communicating finite state machines which exchange messages across the radio interface and communicate internally with other protocol (sub) layers. In particular, the GCC protocol uses the MM and RR sublayer specified in GSM 04.08. The network should apply supervisory functions to verify that the GCC procedures are progressing and if not, take appropriate means to resolve the problems.

The elementary procedures in the GCC include:

• Group call establishment procedures
• Group call termination procedures
• Call information phase procedures
• Various miscellaneous procedures.

All messages have the following header:

Protocol discriminator
The protocol discriminator specifies the message being transferred

Transaction identifier
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:

TI flag
Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.

TI value
The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface.

Message type
The message type defines the function of each GCC message. The following message types exist:

Information elements
Each information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included.

Interested in more details about testing this protocol?

GMM

This protocol is a variant of the GPRS GMM protocol. UMTS and GPRS use the GSM MM (Mobility Management) protocol. Here it is known as the GPRS MM protocol (GMM). The main function of the MM sub-layer is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. A further function of the GMM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer.

The format of the header is shown in the following illustration:

Protocol discriminator
1000 identifies the GMM protocol.

Skip indicator
The value of this field is 0000.

Message type
Uniquely defines the function and format of each GMM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GMM message types may be:

0 0 0 0 0 0 0 1 Attach request
0 0 0 0 0 0 1 0 Attach accept
0 0 0 0 0 0 1 1 Attach complete
0 0 0 0 0 1 0 0 Attach reject
0 0 0 0 0 1 0 1 Detach request
0 0 0 0 0 1 1 0 Detach accept
0 0 0 0 1 0 0 0 Routing area update request
0 0 0 0 1 0 0 1 Routing area update accept
0 0 0 0 1 0 1 0 Routing area update complete
0 0 0 0 1 0 1 1 Routing area update reject
0 0 0 1 0 0 0 0 P-TMSI reallocation command
0 0 0 1 0 0 0 1 P-TMSI reallocation complete
0 0 0 1 0 0 1 0 Authentication and ciphering req
0 0 0 1 0 0 1 1 Authentication and ciphering resp
0 0 0 1 0 1 0 0 Authentication and ciphering rej
0 0 0 1 0 1 0 1 Identity request
0 0 0 1 0 1 1 0 Identity response
0 0 1 0 0 0 0 0 GMM status
0 0 1 0 0 0 0 1 GMM information

Information elements
Various information elements.

Interested in more details about testing this protocol?

GSM

3GPP TS 24.008 http://www.etsi.org

This protocol is a variant of the GPRS GSM protocol. The main function of the GPRS session management (SM) is to support PDP context handling of the user terminal. The SM comprises procedures for: identified PDP context activation, deactivation and modification, and anonymous PDP context activation and deactivation.
The format of the header is shown in the following illustration:

Protocol discriminator
1010 identifies the GSM protocol.

Skip indicator
The value of this field is 0000.

Message type
Uniquely defines the function and format of each GSM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GSM message types may be:

0 1 x x x x x x Session management messages
0 1 0 0 0 0 0 1 Activate PDP context request
0 1 0 0 0 0 1 0 Activate PDP context accept
0 1 0 0 0 0 1 1 Activate PDP context reject
0 1 0 0 0 1 0 0 Request PDP context activation
0 1 0 0 0 1 0 1 Request PDP context activation rej.
0 1 0 0 0 1 1 0 Deactivate PDP context request
0 1 0 0 0 1 1 1 Deactivate PDP context accept
0 1 0 0 1 0 0 0 Modify PDP context request
0 1 0 0 1 0 0 1 Modify PDP context accept
0 1 0 1 0 0 0 0 Activate AA PDP context request
0 1 0 1 0 0 0 1 Activate AA PDP context accept
0 1 0 1 0 0 1 0 Activate AA PDP context reject
0 1 0 1 0 0 1 1 Deactivate AA PDP context request
0 1 0 1 0 1 0 0 Deactivate AA PDP context accept
0 1 0 1 0 1 0 1 SM Status

Information elements
Various information elements.

Interested in more details about testing this protocol?

GTP

3GPP TS 29.060 http://www.etsi.fr

This protocol is a variant of the GPRS GTP protocol. GPRS Tunnelling Protocol (GTP) is the protocol that is used between GSN nodes in the UMTS backbone network. GTP is defined both for the Gn interface, i.e. the interface between GSNs within a PLMN, and the Gp interface between GSNs in different PLMNs. GTP is encapsulated within UDP.
GTP allows multiprotocol packets to be tunnelled through the UMTS backbone between GPRS Support Nodes (GSNs). In the signalling plane, GTP specifies a tunnel control and management protocol which allows the SGSN to provide UMTS network access for an MS. Signalling is used to create, modify and delete tunnels. In the transmission plane, GTP uses a tunnelling mechanism to provide a service for carrying user data packets. The choice of path is dependent on whether the user data that is going to be tunnelled requires a reliable link or not.
The GTP protocol is implemented only by SGSNs and GGSNs. No other systems need to be aware of GTP. UMTS MSs are connected to a SGSN without being aware of GTP. It is assumed that there will be a many-to-many relationship between SGSNs and GGSNs. An SGSN may provide service to many GGSNs. A single GGSN may associate with many SGSNs to deliver traffic to a large number of geographically diverse mobile stations.
The GTP header is a fixed format 16 octet header used for all GTP messages.

Version
Set to 0 to indicate the first version of GTP.

Reserved
Reserved bits for future use, set to 1.

LFN
LLC frame number. Flag indicating whether the LLC frame number is included or not, set to 0 in signalling messages.

Message type
Indicates the type of GTP message. In signalling messages, it is set to the unique value that is used for each type of signalling message.

Length
Indicates the length in octets of the GTP message (G-PDU). In signalling messages, this is the length, in octets, of the signalling message (including the GTP header).

Sequence number
A transaction identity for signalling messages and an increasing sequence number for tunneled T-PDUs.

Flow label
Identifies unambiguously a GTP flow. In signalling Path Management messages and Location Management messages, the flow label is not used and is set to 0.

TID
The Tunnel Identifier that points out MM and PDP contexts in the destination GSN. In signalling messages, it is set to 0 in all V Management messages, Location Management messages and Mobility Management messages. The format of the TID is as follows:

MCC, MNC, MSIN digits
Parts of the IMSI (defined in GMS 04.08).

NSAPI
Network service access point identifier.
LLC supports two modes of operation:

• Unacknowledged peer-to-peer operation.
• Acknowledged peer-to-peer operation.

Interested in more details about testing this protocol?

IUup

3GPP TS 25.415 (You can download all the ETSI files from www.ETSI.org)

TheIuUP (Iu User Plane) protocol is located in the user plane of the Radio Network layer over the Iu interface; theIuUP protocol layer. It is used to convey user data associated to Radio Access Bearers.
OneIuUP protocol instance is associated to one RAB and one RAB only. If several RABs are established towards one given UE, then these RABs make use of severalIuUP protocol instances.
Whenever a RAB requires transfer of user data in theIuUP, anIuUP protocol instance exists at each Iu interface access points. TheseIuUP protocol instances are established, relocated and released together with the associated RAB.

Frame Format for predefined size SDUs

PDU Type 0
PDU Type 0 is defined to transfer user data over theIuUP in support mode for pre-defined SDU sizes. An error detection scheme is provided over theIuUP for the payload part.
The following shows the Iu frame structure for PDU type 0 of theIuUP protocol at the SAP towards the transport layers (TNL-SAP).

TheIuUP PDU Type 0 is made of three parts:

1. IuUP Frame Control part (fixed size);
2. IuUP Frame Check Sum part (fixed size);
3. IuUP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not consider the usage of spare extension field]).

TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 0 Frame Header.

PDU Type 1
PDU Type 1 is defined to transfer user data over theIuUP in support mode for pre-defined SDU sizes when no payload error detection scheme is necessary overIuUP (i.e. no payload CRC). The following shows the Iu frame structure for PDU type 1 of theIuUP protocol at the SAP towards the transport layers (TNL-SAP).

TheIuUP PDU Type 1 is made of three parts:

1. IuUP Frame Control part (fixed size);
2. IuUP Frame Check Sum part (fixed size);
3. IuUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not consider the usage of spare extension field]).

TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 1 Frame Header.

PDU Type 14
PDU Type 14 is defined to perform control procedures over theIuUP in support mode for pre-defined SDU sizes. The control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to the control procedure.
The figure below shows the Iu frame structure for PDU Type 14 of theIuUP protocol at the SAP towards the transport layers (TNL-SAP).

TheIuUP PDU Type 14 is made of three parts:

1. IuUP Frame Control part (fixed size);
2. IuUP Frame Check Sum part (fixed size);
3. IuUP Frame Payload part (variable length, rounded up to octet).

TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 14 Frame Header.

Enlarge	More Details

Interested in more details about testing this protocol?

MAC

3GPP TS 25.321 V3.7.0 (2001-03) (You can download all the 3G files from www.3gpp.org )

The MAC (Medium Access Control) protocol architecture is constructed from MAC entities. The entities are assigned the following names: MAC-b and MAC-c/sh.
MAC-b is the MAC entity that handles the BCH broadcast transport channel
MAC-c/sh, is the MAC entity that handles the following transport channels:

• Paging channel (PCH)
• Forward access channel (FACH)
• Random access channel (RACH)
• Common packet channel (UL CPCH). The CPCH exists only in FDD mode.
• Downlink shared channel (DSCH)
• Uplink shared channel (USCH). The USCH exists only in TDD mode.

MAC-d is the MAC entity that handles the Dedicated transport channels (DCH)

The exact functions completed by the entities are different in the UE from those completed in the UTRAN.
The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for different kinds of data transfer services as offered by MAC. Each logical channel type is defined by the type of information being transferred.

Each MAC PDU consits of an optional MAC header and a MAC Service Data Unit (MAC SDU), Both the MAC header and the MAC SDU are of variable size. The content and the size of the MAC header depends on the type of the logical channel, and in some cases none of the parameters in the MAC header are needed. The size of the MAC-SDU depends on the size of the RLC-PDU, which is defined during the setup procedure.

The structure of the MAC protocol header is as follows:

TCTF
Target Channel Type Field
The TCTF field is a flag that provides identification of the logical channel class on FACH and RACH transport channels, i.e. whether it carries BCCH, CCCH, CTCH, SHCCH or dedicated logical channel information. Note that the size of the TCTF field of FACH for FDD is either 2 or 8 bits depending of the value of the 2 most significant bits and for TDD is either 3 or 5 bits depending on the value of the 3 most significant bits. The TCTF of the RACH for TDD is either 2 or 4 bits depending on the value of the 2 most significant bits.

UE-Id Type
The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC headers.

UE-Id
The UE-Id field provides an identifier of the UE on common transport channels. The following types of UE-Id used on MAC are defined:

• UTRAN Radio Network Temporary Identity (U-RNTI) may be used in the MAC header of DCCH when mapped onto common transport channels.
• Cell Radio Network Temporary Identity (C-RNTI) is used on DTCH, DSCH in FDD mode, and may be used on DCCH, when mapped onto common transport channels.

The UE Id to be used by MAC is configured through the MAC control SAP. The lengths of the UE-Id field of the MAC header are given in the table below.

C/T field
The C/T field provides identification of the logical channel instance when multiple logical channels are carried on the same transport channel. The C/T field is used also to provide identification of the logical channel type on dedicated transport channels and on FACH and RACH when used for user data transmission. The size of the C/T field is fixed to 4 bits for both common transport channels and dedicated transport channels.

Enlarge	More Details

Interested in more details about testing this protocol?

MAP

EIA/TIA IS41.5 1997 IS41-D

The MAP (Mobile Application Part) protocol typically runs on top of the Signaling System 7 (SS7) protocol. MAP is a non call-associated signaling protocol. It provides the support for interactive mobile applications ( cellular, paging, voice messaging, etc.) in a distributed environment. MAP defines the end-to-end protocol between applications which may be located in an SS7 network, and/or other networks supporting the MAP protocol. SS7 is a common channel signaling protocol that enables resources in broadband and narrowband networks to exchange messages related to call setup, supervision and teardown, information needed for distributed application processing and network management.

The MAP protocol provides mechanisms to communicate between a Mobile Switching Center (MSC) and Visitor Location Register (VLR) ("B" interface), MSC and Home Location Register (HLR) ("C" interface), Visitor Location Register (VLR) and HLR ("D" Interface), VLR and VLR ("G" Interface), MSC and MSC ("E" interface), MSC and Short Message Service gateway (SMS) ("H" interface) and MSC and Equipment Identification Register (EIR) ("F" interface).
The MAP protocol is encoded in ASN.1 Basic Encoding rules (BER) as a part of the SS7 stack above the TCAP protocol. The operations provided by MAP are:

• Update Location, Cancel Location, PurgeMS, Send Identification
• Prepare HandOver, Send End Signal, Proceed Access Signalling
• Forward Access Signalling, Prepare Subsequent Hand Over
• Send Authentication Info, Authentication Failure Report
• Check IEMI, Insert Subscriber Data, Delete Subscriber Data
• Reset, Forward Check SS Indication, Activate Trace Mode
• Deactivate Trace Mode, Send Routing Info
• Provide Roaming Number, Resume Call Handling
• Provide SIWFSN Number, SIWFSS Signalling Modify
• Set Reporting State, Status Report, Remote User Free
• IST-Alert, IST Command, Register SS, Erase-SS
• Activate-SS, Deactivate-SS, Interrogate-SS
• Procceed Unstructed-SS, Unstructed-SS Request
• Unstructed-SS Notify, Register Password,
• Get Password, Register CC-Entry
• Erase-CC Entry, Send Routing Info For SM
• MO Forward SM, MT Forward SM, Report SM Delivery Status
• Inform Service Center, Alert Service Center, Ready For SM
• Provide Subscriber Info, Any Time Interrogation
• Any Time Subscription Interrogation, Any Time Modification
• Note subscriber Data Modified, SS – Invocation Notification
• Prepare Group Call, Send Group Call End-Signal
• Process Group Call Signalling, Forward Group Call Signalling
• Update GPRS Location, Send Routing INFO For GPRS
• Failure Report, Note MS Present For GPRS
• Provide Subscriber Location, Send Routing Info For LCS
• Subscriber Location Report, Note-MM-Event, System Failure
• Data Missing, Unexpected Data Value, Facility Not supported
• Incompatible Terminal, Resource Limitation, Unknown Subsriber
• Number Changed, Unknown MSC, Unidentied Subscriber
• Unknown Equipment, Roaming Not Allowed, Illegal Subscriber
• Illegal Equipment, Bearer Service Not Provisioned,
• Tele Service Not Provisioned, No Handover Number Available
• Subsequent Handover Failure, Target Cell Outside Group Call Area
• Tracing Buffer Full, No Roaming Number Available, Absent Subscriber
• Busy subscriber, No Subscriber Reply, Call Barred, Forwarding Failed
• OR-Not Allowed, Forwarding Violation, CUG-Reject, ATI-Not Allowed
• ATSI Not Allowed, ATM Not Allowed, Information Not allowed
• No Group Call Number Available, Illegal SS-Operation, SS-Error Status
• SS-Not available, Subscription Violation, SS Incompatibility
• Unknown Alphabet, USSD-Busy, PW Registration Failure
• Negative PW-Check, Number Of PW Attempts Violation
• Short Term Denial, Long Term Denial, Subscriber Bust For MT-SMS
• SM Delivery Failure, Message Waiting List Full, Absent Subscriber SM
• Unauthorized Requesting Network, Unautorized LCS Client
• Position Method Failure, Unknown Or Unreachable LCS Client
• MM Event Not Supported, Send Parameters, Process Unstructed SS Data
• Preform HandOver, Preform Subsequent HandOver
• Not Internal HandOver, Note Subscriber Present, Unknown Base Station
• Alert Service Center Without Result, Trace Subscriber Activity
• Begin Subscriber Activity, Invalid Target Base Station
• No Radio Resource Available

Enlarge	More Details

Interested in more details about testing this protocol?

MM

The main function of the Mobility Management (MM) sub-layer is to support the mobility of user terminals, for instance; informing the network of its present location and providing user identity confidentiality. A further function of the MM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer.

The format of the header is shown in the following illustration:

Protocol discriminator
0101 identifies the MM protocol.

Skip indicator
The value of this field is 0000.

Message type
Uniquely defines the function and format of each MM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. MM message types may be:

0x00	xxxx	Registration messages:
	0001	IMSI DETACH INDICATION
	0010	LOCATION UPDATING ACCEPT
	0100	LOCATION UPDATING REJECT
	1000	LOCATION UPDATING REQUEST
0x01	xxxx	Security messages:
	0001	AUTHENTICATION REJECT
	0010	AUTHENTICATION REQUEST
	0100	AUTHENTICATION RESPONSE
	1000	IDENTITY REQUEST
	1001	IDENTITY RESPONSE
	1010	TMSI REALLOCATION COMMAND
	1011	TMSI REALLOCATION COMPLETE
0x10	xxxx	Connection management messages:
	0001	CM SERVICE ACCEPT
	0010	CM SERVICE REJECT
	0011	CM SERVICE ABORT
	0100	CM SERVICE REQUEST
	1000	CM REESTABLISHMENT REQUEST
	1001	ABORT
0x11	xxxx	Miscellaneous messages:
	0001	MM STATUS

Information elements
Various information elements.

Interested in more details about testing this protocol?

MTP- 3B

SS7 Layer 3. (part of UMTS)
http://www.itu.int/ITU-T/. Recommendation Q.2210, Q.704.

The MTP-3B (Message Transfer Part) Protocol describes the functions and procedures for and relating to the transfer of messages between the signalling points, which are the nodes of the signalling network. Such functions and procedures are performed by the Message Transfer Part at level 3, and therefore they assume that the signalling points are connected by signalling links, incorporating the functions described in Recommendations Q.702 and Q.703. The signalling network functions must ensure a reliable transfer of the signalling messages, according to the requirements specified in Recommendation Q.706, even in the case of the failure of signalling links and signalling transfer points; therefore, they include the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and to appropriately reconfigure the routing of messages through the signalling network.
According to these principles, the signalling network functions can be divided into two basic categories, namely:

• Signalling message handling; and
• Signalling network management.

The MTP-3B protocol structure appears as follows:

Priority
The priority

Service Indicator
Used to perform message distribution and in some cases to perform message routing. The service indicator codes are used in international signalling networks for the following purposes.

Sub Service Indicator
The sub-service field contains the network indicator and two spare bits to discriminate between national and international messages.

Interested in more details about testing this protocol?

NbUP

3GPP TS 29.415 http://webapp.etsi.org/key/queryform.asp

The NbUP is located in the user plane of the CS core network over the Nb interface. It is used to convey data between MGWs. The NbUP protocol is initiated at one MGW and acknowledged by the adjoining MGW. The NbUP framing is identical to the IuUP framing, i.e., the same PDU types are valid for both protocols.

The figure shows the logical location of the NbUP protocol layer in relation to the Nb interface.

The structure is the same as IuUP.

Frame Format for predefined size SDUs

PDU Type 0
PDU Type 0 is defined to transfer user data over the IuUP in support mode for pre-defined SDU sizes. An error detection scheme is provided over the NbUP for the payload part.
The following shows the Iu frame structure for PDU type 0 of the NbUP protocol at the SAP towards the transport layers (TNL-SAP).

The NbUP PDU Type 0 is made of three parts:

1. NbUP Frame Control part (fixed size);
2. NbUP Frame Check Sum part (fixed size);
3. NbUP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not consider the usage of spare extension field]).

The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 0 Frame Header.

PDU Type 1
PDU Type 1 is defined to transfer user data over the NbUP in support mode for pre-defined SDU sizes when no payload error detection scheme is necessary over NbUP (i.e. no payload CRC). The following shows the Iu frame structure for PDU type 1 of the NbUP protocol at the SAP towards the transport layers (TNL-SAP).

The NbUP PDU Type 1 is made of three parts:

1. NbUP Frame Control part (fixed size);
2. NbUP Frame Check Sum part (fixed size);
3. NbUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not consider the usage of spare extension field]).

The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 1 Frame Header.

PDU Type 14
PDU Type 14 is defined to perform control procedures over the NbUP in support mode for pre-defined SDU sizes. The control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to the control procedure.
The figure below shows the Iu frame structure for PDU Type 14 of the NbUP protocol at the SAP towards the transport layers (TNL-SAP).

The NbUP PDU Type 14 is made of three parts:

1. NbUP Frame Control part (fixed size);
2. NbUP Frame Check Sum part (fixed size);
3. NbUP Frame Payload part (variable length, rounded up to octet).

The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 14 Frame Header.

NBAP
ETSI TS 125 433 (You can download all the ETSI files from www.ETSI.org)

The Node B Application Part, (NBAP), protocol is used over the IUR Interface. It includes common procedures and dedicated procedures. It covers procedures for paging distribution, broadcast system information, request / complete / release of dedicated resources and management of logical resources. It is an upper layer protocol which is part of the IUB Interface. Like most asn1 applicable protocols, the NBAP protocol has many message types that carry a high volume of data.

The NBAP protocol header appears as follows. Each NBAP-PDU has a unuiqe header format, that contains a number of fields. The following is an example of the NBAP Initiating Message PDU:

The protocol is implemented using asn.1 rules and the data transferred is packed in a PER format.

PDU
The type of PDU sent.

Procedure ID
Procedure ID is to be used if Criticality Diagnostics is part of the Error Indication procedure, and not within the response message of the same procedure that caused the error.

Procedure code
These 2 fields combine the message type and uniquely identify the message being sent.

Criticality
The Procedure Criticality is used for reporting the Criticality of the Triggering message (Procedure)

Message discriminator
This field is used to discriminate between Dedicated NBAP and Common NBAP messages.

Transaction ID
The transaction ID is used to associate all the messages belonging to the same procedure.

Enlarge	More Details

Interested in more details about testing this protocol?

PCAP

(3GPP TS 25.453)

The PCAP protocol is the Positioning Calculation Application Part between the Radio Network Controller (RNC) and the Stand-alone A-GPS SMLC (SAS).

An SAS performs the following procedures:

• Provides GPS related data to the RNC.
• Performs the position calculation function for UE assisted GPS.

The PCAP consists of Elementary Procedures (EPs). An Elementary Procedure is a unit of interaction between the RNC and the SAS. An EP consists of an initiating message and possibly a response message.

Two kinds of EPs are used:

• Class 1: Elementary Procedures with a response (success or failure).
• Class 2: Elementary Procedures without a response.
  For Class 1 EPs, the types of responses can be as follows:
  • Successful: A signaling message explicitly indicates that the elementary procedure successfully completed with the receipt of the response.
  • Unsuccessful: A signaling message explicitly indicates that the EP failed. Class 2 EPs are always considered always successful.

PCAP provides the signaling services between RNC and SAS that are required to fulfill the PCAP functions.

PCAP services are categorized as follows:

• Position Calculation Service: They are related to a single UE and involve the transfer of GPS measurement data and UE position estimate data over the Iupc interface between the SRNC and the SAS. They utilize connectionless signaling transport provided by the Iupc signaling bearer.
• Information Exchange Service: They involve the transfer of GPS related data over the Iupc interface between the RNC and the SAS on demand, on modification, or at regular intervals. They utilize connection-oriented signaling transport provided by the Iupc signaling bearer.

PCAP has the following functions:

• Position Calculation. This function enables the SRNC to interact with an SAS in the process of performing a position estimate of a UE.
• Information Exchange. This function enables the RNC to obtain GPS related data from an SAS.
• Reporting of General Error Situations. This function allows reporting of general error situations for which function specific error messages have not been defined.

The following PCAP procedures exist:

• Position Calculation.
• Information Exchange Initiation.
• Information Reporting.
• Information Exchange Termination.
• Information Exchange Failure.
• Error Indication.
• Private Message.

Interested in more details about testing this protocol?

PDCP

ETSI TS 125 323.
http://webapp.etsi.org/key/queryform.asp.
Packet Data Convergence Protocol.

PDCP provides its services to the NAS at the UE or the relay at the Radio Network Controller (RNC). It uses the services provided by the Radio Link Control (RLC) sublayer. Network layer protocols are intended to be capable of operating over services derived from a wide variety of subnetworks and data links. UMTS supports several network layer protocols providing protocol transparency for the users of the service. At that point of view supported protocols are IPv4 and IPv6. Introduction of new network layer protocols to be transferred over UTRAN must be possible without any changes to UTRAN protocols. Therefore, all functions related to transfer of packets from higher layers (PDCP SDUs) are carried out in a transparent way by the UTRAN network entities. This is one of the requirements for UTRAN PDCP.
It performs the following functions:

• Header compression and decompression of IP data streams (e.g., TCP/IP and RTP/UDP/IP headers) at the transmitting and receiving entity, respectively. The header compression method is specific to the particular network layer, transport layer or upper layer protocol combinations e.g. TCP/IP and RTP/UDP/IP.
• Transfer of user data. Transmission of user data means that PDCP receives PDCP SDU from the NAS and forwards it to the RLC layer and vice versa.
• M<intenance of PDCP sequence numbers for radio bearers that are configured to support lossless SRNS relocation.

Header compression is different for each type of protocol.
There are three possible PDU header types:

PDCP-No-Header PDU

PDCP Data PDU

PDCP SeqNum PDU

PDU Type
The PDU type indicates the PDCP date PDU type. (sequence number included or not)
The possible values of the PDU types are as follows:

PID
Indicates the header compression identifier used. Header compression is different for each type of protocol.

Sequence Number
The PDCP PDU sequence number

Data
PDCP SDUs that have been header compressed are mapped to this field if header compression is negotiated. Otherwise, PDCP SDUs are mapped to this field

Enlarge	More Details

Interested in more details about testing this protocol?

Q2630

ATM
Layer 2 (also UMTS)
ITU-T Recommendation Q.2630.1
http://www.itu.int/ITU-T/

The AAL type 2 signalling protocol provides the signalling capability to establish, release and maintain AAL type 2 point-to-point connections across a series of ATM VCCs that carry AAL type 2 links. These services are accessible via the AAL type 2 served user service access point (A2SU-SAP).
The AAL type 2 signalling protocol also provides maintenance functions associated with the AAL type 2 signalling.
An AAL type 2 signalling endpoint should be able to control AAL type 2 links on more than one ALL type 2 path. These AAL type 2 paths may be contained on different ATM VPCs, which in turn may be carried on different ATM physical interfaces.
Two peer AAL type 2 signalling entities rely on the generic signalling transport service to provide assured data transfer between them and service availability indications. These services are accessible via the Generic Signalling Transport Service Access Point (GST-SAP).
Note that primitives over the A2SU-SAP, GST-SAP, and LM-SAP are used for descriptive purpose only. They do not imply a specific implementation. Both peer AAL type 2 signalling entities provide the same set of services.
The AAL type 2 signalling entity is subdivided into protocol entities and nodal functions. At each AAL type 2 service endpoint, the AAL type 2 signalling entity communicates with the AAL type 2 served user. At an AAL type 2 switch, the AAL type 2 signalling entity does not communicate with an AAL type 2 served user.
The AAL2 protocol header structure appears as follows

Destination Signalling Association Identifier
The Destination Singalling Association Identifier.

Message Identifier
The message identifier. The following types of messge identifier are available:

Message Compatibility
The instructions specific for the handling of the complete message.
The header is followed by a parameter, that appears as follows:

Enlarge	More Details

Interested in more details about testing this protocol?

RANAP

RANAP (Radio Access Network Application Part) is the Radio Network Layer signalling protocol for the Iu interface. It manages the signalling and GTP connections between RNC and 3G-SGSN. It also manages signalling and circuit-switched connections between RNC and 3G MSC on the Iu interface. It resides in UTRAN & CN and handles signalling between RNC and 3G SGSN on Iu-PS and between RNC and 3G MSC on the Iu-CS interface. It also provides a signalling channel to transparently pass messages between UE and the Core Network. HSS RANAP protocol implementation provides the Elementary procedures for accomplishing Radio Access Bearer Management, Serving RNS Relocation, Transport of NAS Information between UE and CN, Paging UE and Release of Iu resources.

RANAP gives 3 types of services:

• General control services
• Notification services
• Dedicated control services

All messages are text messages in ASN.1 format and can contain the following text messages:

Interested in more details about testing this protocol?

RLC

3GPP TS 25.322 v3.7.0 (2001-06) (You can download all the ETSI files from www.ETSI.org)

The Radio Link Control protocol (RLC) has 3 different peer entities. There is one transmitting and one receiving entity for the transparent mode service and the unacknowledged mode service; and one combined transmitting and receiving entity for the acknowledged mode service.
The following functions are supported by RLC.

• Segmentation and reassembly
• Concatenation
• Padding
• Transfer of user data
• Error correction
• In-sequence delivery of higher layer PDUs
• Duplicate detection
• Flow control
• Sequence number check
• Protocol error detection and recovery
• Ciphering
• Suspend/resume function.

The protocol is tranmitted as PDUs. They can be Data PDUs or Control PDUs. The protocol data units are:

Data PDUs

TrD PDU (Transparent Mode Data PDU).
The TrD PDU is used to convey RLC SDU data without adding any RLC overhead. The TrD PDU is used by RLC when it is in transparent mode. No overhead is added to the SDU by RLC. The data length is not constrained to be an integer number of octets.

UMD PDU (Unacknowledged Mode Data PDU).
The UMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. It is used by RLC when using unacknowledged data transfer. The length of the data part is an integer number of octets. The UMD PDU header consists of the first octet, which contains the sequence number. The RLC header consists of the first octet and all the octets that contain length indicators.

AMD PDU (Acknowledged Mode Data PDU).
The AMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. The AMD PDU transfers user data and piggybacked status information and requests status report by setting Poll bit when RLC is operating in acknowledged mode. The length of the data part is an integer number of octets. The AMD PDU header consists of the first two octets, which contain the sequence number. The RLC header consists of the first two octets and all the octets that contain length indicators.

Control PDUs

STATUS PDU and Piggybacked STATUS PDU
The STATUS PDU and the Piggybacked STATUS PDU are used in acknowledged mode. The STATUS PDU is used to report the status between two RLC AM entities. Both receiver and transmitter status information may be included in the same STATUS PDU:

• by the receiving entity to inform the transmitting entity about missing PDUs at the receiving entity;
• by the receiving entity to inform the transmitting entity about the size of the allowed transmission window;
• by the transmitting entity to request the receiving entity to move the receiving window.

Piggybacked Status PDU
The format of the piggybacked STATUS PDU is the same as the ordinary Control PDU except that the D/C field is replaced by a reserved bit (R2). This PDU can be used to piggyback STATUS PDU in an AMD PDU if the data does not fill the complete AMD PDU. The PDU Type field is set to zero and all other values are invalid for this version of the protocol and the PDU is discarded.

RESET PDU
The RESET PDU is used in acknowledged mode to reset all protocol states, protocol variables and protocol timers of the peer RLC entity in order to synchronise the two peer entities.

RESET ACK PDU
The RESET ACK PDU is an acknowledgement to the RESET PDU.
The RESET PDU and RESET ACK PDU have a one-bit sequence number field (RSN). With the aid of this field the Receiver can define whether the received RESET PDU is transmitted by the Sender for the first time or whether it is a retransmission of a previous RESET PDU.

The size of a RESET or RESET ACK PDU is variable and upper bounded by the maximum RLC PDU size used by the logical channel on which the control PDUs are sent. Padding shall be included to exactly fit one of the PDU sizes used by the logical channel on which the control PDUs are sent.
Explanations for the parameters in the fields of the PDUs are as follows:

D/C Field
The length of this field is one bit. The D/C field indicates the type of an acknowledged mode PDU. It can be either a data or a control PDU.

PDU Type
The length of this field is 3 bits. The PDU type field indicates the Control PDU type. The following types are available.

Sequence Number (SN)
The SN field indicates the sequence number of the PDU encoded in binary.

Polling bit (P)
The polling bit is used to request a status report (one or several STATUS PDUs) from the receiver RLC.

Extension bit
This bit indicates if the next octet will be a length indicator with an E bit.

Reserved 1 (R1)
This field in the RESET PDU and RESET ACK PDU is used to achieve octet alignment and for this purpose it is coded as 000. Other functions of it are left for future releases.

Header Extension Type (HE)
This two-bit field indicates if the next octet will be data or a length indicator and E bit.

Length Indicator (LI)
The Length Indicator is used to indicate, each time, the end of an SDU that occurs in the PDU. The Length Indicator points out the number of octets between the end of the last Length Indicator field and up to and including the octet at the end of an SDU segment. Length Indicators are included in the PDUs that they refer to. The size of the Length Indicator may be either 7 bits or 15 bits.

SUFI
The SUFI field that are used is dependant on the implementation, but when a STATUS PDU includes information about which PDUs have been received and which are detected as missing, information is not included PDUs that have not yet reached the receiver.
The SUFI (Super-Field) includes three sub-fields: type information (type of super-field, e.g. list, bitmap, acknowledgement, etc), length information (providing the length of a variable length field within the following value field) and a value

Enlarge	More Details

Interested in more details about testing this protocol?

RLP

ETSI TS 124 022. (You can download all the ETSI files from www.ETSI.org)

Three versions of the RLP (Radio Link Protocol) are defined:

• RLP version 0: single-link basic version;
• RLP version 1: single-link extended version (e.g. extended by data compression);
• RLP version 2: multi-link version.

RLP uses one physical link (single-link) or from 1 up to 4 (multi-link) substreams on one or more physical links. However, the RLP multi-link version is designed to be able to support up to 8 physical links. If, in the call set-up signalling, either end indicates that it cannot support multi-link operation, neither end can use RLP versions higher than 1. If the BC negotiation during call set-up results in a possibility for multi-link operation during the call, both ends can only use RLP version 2 only.
RLP makes use of an underlying FEC (Forward Error Correction) mechanism. For RLP to perform adequately it is assumed that the basic radio channel together with FEC provides for a block error rate of less than 10 %, where a block consists of 240 or 576 bits. Furthermore, it is assumed that in case of multi-link RLP the difference of the delay between all physical links is less than timer T4.
In A/Gb mode, RLP frames are sent in strict alignment with the radio transmission.
RLP frames are of a fixed size of 240 (TCH/F4.8 and TCH/F9.6 channel codings) or 576 bits (TCH/F14.4, TCH/F28.8 and TCH/F43.2 channel codings). Whenever a frame is to be sent, the RLP entity has to provide the necessary protocol information to be contained in it. In Iu mode, the RLP frame size does not depend on the channel coding, only 576 bit frames are used.
RLP entities running only in an Iu mode environment need only to support the 576 bit frame length. The REMAP function is not necessary. RLP entities running in both of the systems have to support the REMAP function. In a handover from Iu mode to A/Gb mode the frame either stays 576 bits long or changes from 576 bits to 240 bits incurring a REMAP. In a handover from A/Gb mode to Iu mode the frame either stays 576 bits long or changes from 240 bits to 576 bits incurring a REMAP. Provision is made for discontinuous transmission (DTX). RLP spans from the User Equipment (UE) to the interworking function (IWF), located at the nearest Mobile Switching Centre (MSC), or beyond. Depending on the exact location of the IWF, handover of the UE may result in link-reset or even total loss of the connection.
The UE shall initiate the RLP link. In addition the MSC/IWF may initiate the RLP link.
In the terminology of HDLC, RLP is used in a balanced configuration, employing asynchronous operation, i.e. either station has the right to set-up, reset, or disconnect a link at any time. Procedural means are provided for to deal with contentious situations, should they ever occur.
RLP is full duplex in the sense that it allows for information to be transferred in both directions simultaneously.

The RLP frames have a fixed length of either 240 or 576 bits consisting of a header, information field and an FCS field.

The format of the 240-bit frame is:

The header is 16 bits in versions 0 and 1 and in version 2 (U frames). It is 24 bits in version 2 (S and I+S frames).

The format of the 576-bit frame is:

The header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames.

Header
Contains control information of one of the following 3 types: unnumbered protocol control information (U frames), supervisory information (S frames) and user information carrying supervisory information piggybacked (I+S frames).

FCS
This is the Frame Check Sequence field.
The RLP entity will be in the Asynchronous Balanced Mode (ABM), which is the data link operation mode; or Asynchronous Disconnected Mode (ADM), which is the data link non-operational mode.

Header structure of versions 0 and 1

N(S) is a bit 4 low order bit and N(R) is a bit 11 low order bit.

Header structure of version 2

S is a L2R status Bit, N(S) is a bit 1 low order bit, N(R) is a bit 14 low order bit and UP is a UP bit.

C/R
The Command Response Bit indicates whether the frame is a command or a response frame. It can have the following values:

P/F
The Poll/Final bit marks a special instance of command/response exchange

X
Don't care

Unnumbered Frames (U)

The M1 M2 M3 M4 and M5 bits have the following values in the U frames according to the type of information carried:

SABM11100
The Set Asynchronous balance mode is used either to initiate a link for numbered information transfer or to reset a link already established.

UA00110
The Unnumbered Acknowledge is used as a response to acknowledge an SABMM or DISC command.

DISC00010
The disconnect is used to disestablish a link previously established for information transfer.

DM11000
The disconnected mode encoding is used as a response message.

NULL11110

UI 00000
Unnumbered information signifies that the information field is to be interpreted as unnumbered information.

XID11101
Exchange Identification signifies that the information field is to be interpreted as exchange identification, and is used to negotiate and renegotiate parameters of RLP and layer 2 relay functions.

TEST 00111
The information field of this frame is test information.

REMAP 0001
A remap exchange takes place in ABM following a change of channel coding. If an answer is not received within a specific time, then the mobile end enters ADM.

S and I+S frames

N(S)
The send sequence number contains the number of the I frame.

N(R)
The Receive sequence number is used in ABM to designate the next information frame to be sent and to confirm that all frames up to and including this bit and been received correctly.

S
S represents the L2 status bit.

The S1, S2 bits can have the following significance in the S and I+S frames:

RR
Receive Ready can be used either as a command or a response. It clears any previous busy condition in that area.

REJ
The Reject encoding is used to indicate that in numbered information transfer 1 or more out-of-sequence frames have been received.

RNR
The Receive Not Ready indicates that the entity is not ready to receive numbered information frames.

SREJ
Selective Reject is used to request retransmission of a single frame.

UP
This is used in version 2 to indicate that a service level upgrading will increase the throughput.

Interested in more details about testing this protocol?

RNSAP

ETSI TS 125 423. (You can download all the ETSI files from www.ETSI.org)

The Iur interface RNSAP (Radio Network Subsystem Application Part) procedures are divided into four modules as follows:

1. RNSAP Basic Mobility Procedures
2. RNSAP DCH Procedures
3. RNSAP Common Transport Channel Procedures
4. RNSAP Global Procedures.

The Basic Procedures module contains procedures used to handle the mobility within UTRAN.
The DCH Procedures module contains procedures that are used to handle DCHs between two RNSs. If procedures from this module are not used in a specific Iur, then the usage of DCH traffic between corresponding RNSs is not possible.
The Common Transport Channel Procedures module contains procedures that are used to control common transport channel data streams over Iur interface.
The Global Procedures module contains procedures that are not related to a specific UE. The procedures in this module are in contrast to the above modules involving two peer CRNCs.
The RNSAP header appears as follows:

Message Type
All messages are text messages in asn.1 format.

Transaction ID
Associates all the messges belonging to the same procedure.

Enlarge	More Details

Interested in more details about testing this protocol?

RRC

3GPP TS 25.331 http://webapp.etsi.org/key/queryform.asp

The RRC is an upper layer protocol which is part of the IUB Interface.
The RRC has the following interfaces:

• RRC Application
• Radio Link Control (RLC) for control and configuration of RLC entities
• Medium Access Control (MAC) for control and configuration of MAC entities
• Framing Protocol (FP) for paging related functionality

The functional entities of the RRC (Radio Resource Control) layer are described below:

• Routing of higher layer messages to different MM/CM entities (UE side) or different core network domains (UTRAN side) is handled by the Routing Function Entity (RFE)
• Broadcast functions are handled in the broadcast control function entity (BCFE). The BCFE is used to deliver the RRC services, which are required at the GC-SAP. The BCFE can use the lower layer services provided by the Tr-SAP and UM-SAP.
• Paging of UEs that do not have an RRC connection is controlled by the paging and notification control function entity (PNFE). The PNFE is used to deliver the RRC services that are required at the Nt-SAP. The PNFE can use the lower layer services provided by the Tr-SAP and UM-SAP.
• The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE. The DCFE is used to deliver the RRC services that are required at the DC-SAP and can use lower layer services of UM/AM-SAP and Tr-SAP depending on the message to be sent and on the current UE service state.
• In TDD mode, the DCFE is assisted by the Shared Control Function Entity (SCFE) location in the C-RNC, which controls the allocation of the PDSCH and PUSCH using lower layers services of UM-SAP and Tr-SAP.

The Transfer Mode Entity (TME) handles the mapping between the different entities inside the RRC layer and the SAPs provided by RLC.

The RRC performs the functions listed below.

• Broadcast of information related to the non-access stratum (Core Network)
• Broadcast of information related to the access stratum
• Establishment, maintenance and release of an RRC connection between the UE and UTRAN
• Establishment, reconfiguration and release of Radio Bearers
• Assignment, reconfiguration and release of radio resources for the RRC connection
• RRC connection mobility functions
• Control of requested QoS
• UE measurement reporting and control of the reporting
• Outer loop power control
• Control of ciphering
• Slow DCA (TDD mode)
• Paging
• Initial cell selection and cell re-selection
• Arbitration of radio resources on uplink DCH
• RRC message integrity protection
• Timing advance (TDD mode)
• CBS control.

The RRC offers the following services to upper layers:

• General Control
• Notification
• Dedicated control.

The RRC layer provides signalling connections to the upper layers to support the exchange of upper layer's information flow. The signalling connection is an acknowledged-mode link between the user equipment and the core network to transfer upper layer information. For each core network domain, at most one signalling connection may exist at the same time. The RRC layer maps the signalling connections for one UE on a single RRC connection.

Messages are in the format of ASN.1 messages.

Interested in more details about testing this protocol?

SCTP

The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services to its users:

• Acknowledged error-free non-duplicated transfer of user data. Application-level segmentation to conform to discovered MTU size.
• Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
• Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
• Enhanced reliability through support of multi-homing at either or both ends of the association.

The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data.

The following is the format of the SCTP header.

Source Port Number
This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.

Destination Port Number
This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Verification Tag
The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization.
For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's.

Adler 32 Checksum
This field contains an Adler-32 checksum on this SCTP datagram.

Chunk Field Descriptions

The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field.

Chunk ID
The type of information contained in the chunk value field. The values of the chunk ID are defined as follows:

Chunk Flags
The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified.

Chunk Length
The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk Value
This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID.

Chunk Types

Initiation (INIT)
This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk.

Initiate Acknowledgement (INIT ACK)
The INIT ACK chunk is used to acknowledge the initiation of a SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The Responder Cookie and the Unrecognized Parameter.

Selective Acknowledgement (SACK)
This chunk is sent to the remote endpoint to acknowledge received Data chunks and to inform the remote endpoint of gaps in the received subsequences of Data chunks as represented by their TSNs.
The selective acknowledgement chunk contains the highest consecutive TSN ACK and Rcv Window Credit (rwnd) parameters. By definition, the value of the highest consecutive TSN ACK parameter is the last TSN received at the time the Selective ACK is sent, before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the reporting end. This parameter therefore acknowledges receipt of all TSNs up to and including the value given.
The Selective ACK also contains zero or more fragment reports. Each fragment report acknowledges a sub-sequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.

Heartbeat Request (HEARTBEAT)
An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability of a particular destination transport address defined in the present association. The parameter fields contain the time values.

Heartbeat Acknowledgement (HEARTBEAT ACK)
An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The parameter field contains the time values.

Abort Association (ABORT)
The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in the SCTP datagram or they will be ignored.

SHUTDOWN
An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer.

Shutdown Acknowledgement (SHUTDOWN ACK)
This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters.

Operation Error (ERROR)
This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes.

State Cookie (COOKIE)
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram.

Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram.

Payload Data (DATA)
This contains the user data.

Vendor Specific Chunk Extensions
This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

Interested in more details about testing this protocol?

SNDCP

Sub-Network Dependant Convergence Protocol (SNDCP) uses the services provided by the Logical Link Control (LLC) layer and the Session Management (SM) sub-layer. SNDCP splits into either IP or X.25 and maps them on to the LLC. It also provides fintions such as the compresssion, segmentation and multiplexing of network-layer messages to a single virtual connection.

The main functions of SNDCP are:

• Multiplexing of several PDPs (packet data protocol).
• Compression/decompression of user data.
• Compression/decompression of protocol control information.
• Segmentation of a network protocol data unit (N-PDU) into Logical Link Control Protocol Data Units (LL-PDUs) and re-assembly of LL-PDUs into a N-PDU.

The SN-DATA PDU is used for acknowledged data transfer. Its format is as follows:

NSAPI
Network service access point identifier. Values may be:

M
More bit. Values may be:
0Last segment of N-PDU.
1Not the last segment of N-PDU, more segments to follow.

T
SN-PDU type specifies whether the PDU is SN-DATA (0) or SN-UNITDATA (1).

C
Compression indicator. A value of 0 indicates that compression fields, DCOMP and PCOMP, are not included. A value of 1 indicates that these fields are included.

X
Spare bit is set to 0.

DCOMP
Data compression coding, included if C-bit set. Values are as follows:

PCOMP
Protocol control information compression coding, included if C-bit set. Values are as follows:

Segment offset
Segment offset from the beginning of the N-PDU in units of 128 octets.

N-PDU number
0-2047 when the extension bit is set to 0.
2048-524287 if the extension bit is set to 1.

E
Extension bit for N-PDU number.

Interested in more details about testing this protocol?

SM

This protocol is a variant of the GPRS SM protocol. SM handles mobility issues such as roaming, authentication, selection of encryption algorithms and maintains PDP context. The main function of the session management (SM) is to support PDP context handling of the user terminal. The SM comprises procedures for: identified PDP context activation, deactivation and modification; and anonymous PDP context activation and deactivation.
The format of the header is shown in the following illustration:

Protocol discriminator
1010 identifies the SM protocol.

Skip indicator
The value of this field is 0000.

Message type
Uniquely defines the function and format of each SM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. SM message types may be:

Information elements
Various information elements.

Interested in more details about testing this protocol?

SMS

3GPP TS 24.011 http://www.etsi.org

The Short Message Service (SMS) is used to transfer text messages over mobile networks between a GSM PLMN Mobile Station and a Short Message Entity via a Service Center. The terms MO (Mobile Originating) and MT (Mobile Terminating) are used to indicate the direction in which the short message is sent.
SMS messages can be encapsulated in control or relay messages.

SMS Control Message
The format of the control protocol message header is shown in the following illustration:

Protocol discriminator
1001 identifies the SMS protocol.

Transaction identifier
The transaction identifier (TI) distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:

TI flag
Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.

TI value
TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface.

Message type
The message type, together with the protocol discriminator, identifies the function of the message being sent. Messages may be of the following:

Information elements
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

SMS Relay Protocol Message
The format of the relay protocol message header is shown in the following illustration:

MTI
Message type indicator. Values are as follows:
Bit Value (3 2 1) Direction RP-Message

Message reference
Used to link an RP-ACK message or RP-ERROR message to the associated RP-Data or RP-SMMA message transfer attempt.

Information elements
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

Interested in more details about testing this protocol?

SMS TP

ETSI TS 123 040. (You can download all the ETSI files from www.ETSI.org)

The SMS TP (Short Message Transfer Layer Protocol) is comprised of two basic services:

• SM MT (Short Message Mobile Terminated).
• SM MO (Short Message Mobile Originated).

SM MO denotes the capability of the GSM/UMTS system to transfer a short message submitted by the MS to one SME via an SC, and to provide information about the delivery of the short message either by a delivery report or a failure report with a specific mechanism for later delivery. The message must include the address of that SME to which the SC shall eventually attempt to relay the short Message Transfer Layer Protocol.
The text messages to be transferred by means of the SM MT or SM MO contains up to 140 octets.
The structure of the SMS TP protocol header is as follows:

Message Type
The type of message, the following message types are available:
SC To MS

MS To SC

Interested in more details about testing this protocol?

SS

3GPP TS 24.080 http://webapp.etsi.org/key/queryform.asp

This Supplementary Services protocol defines the structure of the messages of the layer 3 protocol defined in 3GPP TS 24.080. These messages are standard L3 messages. SS is both for GPRS and for UMTS.

The structure of the header is as follows:

The following message types are available

Interested in more details about testing this protocol?

1 2

UMTS Family Protocol Information
AAL2 | AAL5 | AMR | BCC | BMC | BSSAP+ | CAMEL | CC | FP | GCC | GMM | GSM | GTP |IuUP | MAC | MAP | MM | MTP-3B | NBAP | NbUP | PCAP | PDCP | Q2630 | RANAP | RLC | RLP | RNSAP | RRC | SCCP | SCTP | SM | SMS | SMS TP | SNDCP | SS | SSCOP | SSCF-NNI | UMTS Reference Page