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).