umts family

UMTS Family

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:8

7

6

5

4

3

2

1

Frame type

FQI

Padding

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

Mode Indication

Mode Request

Frame content (AMR mode, comfort noise, or other)

0

0

0

AMR 4,75 kbit/s

1

1

1

AMR 5,15 kbit/s

2

2

2

AMR 5,90 kbit/s

3

3

3

AMR 6,70 kbit/s

4

4

4

AMR 7,40 kbit/s

5

5

5

AMR 7,95 kbit/s

6

6

6

AMR 10,2 kbit/s

7

7

7

AMR 12,2 kbit/s

8

-

-

AMR SID

9

-

-

GSM-EFR SID

10

-

-

TDMA-EFR SID

11

-

-

PDC-EFR SID

12-14

-

-

For future use

15

-

-

No Data (No transmission/No reception)

FQIIndicates whether the data in the frame contains errors.0 Bad or corrupted frame1 Good frame

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:

87654321Octet

Transaction identifierProtocol discriminator1

Message type2

Information elements3-n

BCC header structure

Protocol discriminatorThe protocol discriminator specifies the message being transferred

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

8765

TI flagTI value

Transaction identifier

TI flagIdentifies 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 valueThe 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 typeThe message type defines the function of each BCC message. The message type defines the function of each BCC message. The following message types exist:

0x110001IMMEDIATE SETUP

0x110010SETUP

0x110011CONNECT

0x110100TERMINATION

0x110101TERMINATION REQUEST

0x110110TERMINATION REJECT

0x111000STATUS

0x111001GET STATUS

0x111010SET PARAMETER

Information elementsEach 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.

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:87654321Octet

Message Type1

Information Element2-n

Coding of message types:

1CBS Message

2Schedule Message

3CBS41 Message

0, 4.. 255Reserved for future use (PDUs with this coding will be discarded by this version of the 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:87654321Octet

Message type1


BSSAP+ header structure

The message type uniquely identifies the message being sent. The following BSSAP+ message types exist:0x10x20x70x80x90xA0xB0xC0xD0xE0xF0x100x110x120x130x140x150x160x170x180x1A0x1D0x1FBSSAP+-PAGING-REQUEST BSSAP+-PAGING-REJECTBSSAP+-DOWNLINK-TUNNEL-REQUESTBSSAP+-UPLINK-TUNNEL-REQUEST BSSAP+-LOCATION-UPDATE-REQUESTBSSAP+-LOCATION-UPDATE-ACCEPTBSSAP+-LOCATION-UPDATE-REJECT BSSAP+-TMSI-REALLOCATION-COMPLETE BSSAP+-ALERT-REQUEST BSSAP+-ALERT-ACKBSSAP+-ALERT-REJECTBSSAP+-MS-ACTIVITY-INDICATION BSSAP+-GPRS-DETACH-INDICATION BSSAP+-GPRS-DETACH-ACK BSSAP+-IMSI-DETACH-INDICATION BSSAP+-IMSI-DETACH-ACK BSSAP+-RESET-INDICATION BSSAP+-RESET-ACK BSSAP+-MS-INFORMATION-REQUEST BSSAP+-MS-INFORMATION-RESPONSEBSSAP+-MM-INFORMATION-REQUEST BSSAP+-MOBILE-STATUS BSSAP+-MS-UNREACHABLE

Each message type has specific information elements0000000100000010000000110000010000000101000001100000011100001000 00001001000010100000101100001100000011010000111000001111000100000001000100010010 00010011000101000001010100010110000101110001100000011001000110100001101100011100to11111111IMSI. VLR number. TMSI.Location area identifier. Channel Needed. eMLPP Priority.Unassigned: treated as an unknown IEI. Gs cause. SGSN number. GPRS location update type. Unassigned: treated as an unknown IEI. Unassigned: treated as an unknown IEI. Mobile station classmark 1. Mobile identity. Reject cause.IMSI detach from GPRS service type. IMSI detach from non-GPRS service type. Information requested.PTMSI.IMEI. IMEISV. Unassigned: treated as an unknown IEI.MM information.Cell Global Identity. Location information age.Mobile station state. Erroneous message.

Unassigned: treated as an unknown IEI.

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.

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:

87654321Octet

Message type1

Information element1-n

Message TypeThe messge type, the following message types are available.

0x010x020x030x040x050x060x070x080x090x0B0x0E0x0F 0x100x130x170x180x190x1A0x1CAlerting Call Proceeding Progress CC-ESTABLISHMENT Setup CC-ESTABLISHMENT CONFIRMED Connect Call Confirmed START CC RECALL Emergency Setup Connect Acknowledge User Information Modify Reject Modify HoldHold AcknowledgeHold Reject Retrieve

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

General structure of a Frame Protocol PDUThe 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:87654321Octet

Header CRCFT1

CFN2

SpareTFI of first DCH3

4

SpareTFI of last DCH5

DL Data Frame Header

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

Header CRCFT1

CFN2

SpareTFI of first DCH3

4

SpareTFI of last DCH5

Header CRCResult 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.FTThe 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=data1=control.

CFNThe 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 DCHTFI 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.GCC

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

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:

87654321Octet

Transaction identifierProtocol discriminator1

Message type2


GCC header structure

Protocol discriminatorThe protocol discriminator specifies the message being transferred

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

8765

TI flagTI value

Transaction identifier

TI flagIdentifies 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 valueThe 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 typeThe message type defines the function of each GCC message. The following message types exist:

0x110001IMMEDIATE SETUP

0x110010SETUP

0x110011CONNECT

0x110100TERMINATION

0x110101TERMINATION REQUEST

0x110110TERMINATION REJECT

0x111000STATUS

0x111001GET STATUS

0x111010SET PARAMETER

Information elementsEach 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.

GMM

3G.TS.24.008 v3.2.1:www.3gpp.org/ftp/specs

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:

87654321Octet

Protocol discriminatorSkip indicator1

Message type2


GMM header structure

Protocol discriminator1000 identifies the GMM protocol.

Skip indicatorThe value of this field is 0000.

Message typeUniquely 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 request0 0 0 0 0 0 1 0 Attach accept0 0 0 0 0 0 1 1 Attach complete0 0 0 0 0 1 0 0 Attach reject0 0 0 0 0 1 0 1 Detach request0 0 0 0 0 1 1 0 Detach accept0 0 0 0 1 0 0 0 Routing area update request0 0 0 0 1 0 0 1 Routing area update accept0 0 0 0 1 0 1 0 Routing area update complete0 0 0 0 1 0 1 1 Routing area update reject0 0 0 1 0 0 0 0 P-TMSI reallocation command0 0 0 1 0 0 0 1 P-TMSI reallocation complete0 0 0 1 0 0 1 0 Authentication and ciphering req0 0 0 1 0 0 1 1 Authentication and ciphering resp0 0 0 1 0 1 0 0 Authentication and ciphering rej0 0 0 1 0 1 0 1 Identity request0 0 0 1 0 1 1 0 Identity response0 0 1 0 0 0 0 0 GMM status0 0 1 0 0 0 0 1 GMM information

Information elementsVarious information elements.

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:

87654321Octet


Message type2


GSM header structure

Protocol discriminator1010 identifies the GSM protocol.


Message typeUniquely 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 messages0 1 0 0 0 0 0 1 Activate PDP context request0 1 0 0 0 0 1 0 Activate PDP context accept0 1 0 0 0 0 1 1 Activate PDP context reject0 1 0 0 0 1 0 0 Request PDP context activation0 1 0 0 0 1 0 1 Request PDP context activation rej.0 1 0 0 0 1 1 0 Deactivate PDP context request0 1 0 0 0 1 1 1 Deactivate PDP context accept0 1 0 0 1 0 0 0 Modify PDP context request0 1 0 0 1 0 0 1 Modify PDP context accept0 1 0 1 0 0 0 0 Activate AA PDP context request0 1 0 1 0 0 0 1 Activate AA PDP context accept0 1 0 1 0 0 1 0 Activate AA PDP context reject0 1 0 1 0 0 1 1 Deactivate AA PDP context request0 1 0 1 0 1 0 0 Deactivate AA PDP context accept0 1 0 1 0 1 0 1 SM Status


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.

87654321Octet

VersionReservedLFN1

Message type2

Length3-4

Sequence5-6

Flow label7-8

Reserved9-12

TID13-20

GTP header structure

VersionSet to 0 to indicate the first version of GTP.

ReservedReserved bits for future use, set to 1.

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

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

LengthIndicates 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 numberA transaction identity for signalling messages and an increasing sequence number for tunneled T-PDUs.

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

TIDThe 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:

87654321Octet

MCC digit 2MCC digit 11

MNC digit 1MCC digit 32

MSIN digit 1MNC digit 23

MSIN digit 3MSIN digit 24




NSAPIMSIN digit 108

TDI structure

MCC, MNC, MSIN digitsParts of the IMSI (defined in GMS 04.08).NSAPINetwork service access point identifier.LLC supports two modes of operation:

Unacknowledged peer-to-peer operation.

Acknowledged peer-to-peer operation.

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 0PDU 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).BitsOctets

87654321

PDU Type (=0)Frame Number 1Frame Control Part

FQCRFCI 2

Header CRCPayload CRC3Frame Check Sum Part

Payload CRC4

Payload Fields5-nFrame Payload part

Payload FieldsPadding

Spare extension n-n+4

IUup PDU Type 0 Format..

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

BitsOctets

87654321


FQCRFCI 2

Header CRCSpare3Frame Check Sum Part

Payload CRC




IUup PDU Type 1Format..




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 14PDU 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).BitsNumber of Octets

87654321

PDU Type (=14)Ack/Nack (=0, i.e. procedure)PDU Type 14 Frame Number1Frame Control Part

IUup Mode versionProcedure Indicator2


Payload CRC

4

Reserved for procedure data5-nFrame Payload part

Spare extensionn-n+32

IUup PDU Type 14 Format for procedure sending




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.

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 channelMAC-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:

MAC header MAC SDU

TCTFUE-Idtype UE-IdC/TMAC SDU

TCTF Target Channel Type FieldThe 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 TypeThe UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC headers.

UE-Id Type field 2 bitsUE-Id Type

00U-RNTI

01C-RNTI

10Reserved(PDUs with this coding will be discarded by this version of the protocol)


UE-IdThe 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.

UE ID typeLength of UE ID field

U-RNTI32 bits

C-RNTI 16 bits

C/T fieldThe 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. C/T fieldDesignation

0000Logical channel 1


......



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 MM

3G.TS.24.008 v.3.3.1 www.3gpp.org/ftp/specs

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:

87654321Octet


Message type2


MM header structure

Protocol discriminator0101 identifies the MM protocol.


Message typeUniquely 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: 0x00xxxxRegistration messages:

0001IMSI DETACH INDICATION

0010LOCATION UPDATING ACCEPT

0100LOCATION UPDATING REJECT

1000LOCATION UPDATING REQUEST

0x01xxxxSecurity messages:

0001AUTHENTICATION REJECT

0010AUTHENTICATION REQUEST

0100AUTHENTICATION RESPONSE

1000IDENTITY REQUEST

1001IDENTITY RESPONSE

1010TMSI REALLOCATION COMMAND

1011TMSI REALLOCATION COMPLETE

0x10xxxxConnection management messages:

0001CM SERVICE ACCEPT

0010CM SERVICE REJECT

0011CM SERVICE ABORT

0100CM SERVICE REQUEST

1000CM REESTABLISHMENT REQUEST

1001ABORT

0x11xxxxMiscellaneous messages:

0001MM STATUS


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:

87654321Octets

PrioritySpare1

Sub Service IndicatorSpareService Indicator2

PriorityThe priority

Service IndicatorUsed 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.0135 Management MessagesTesting/Maintenance Messages SCCP ISUP

Sub Service IndicatorThe sub-service field contains the network indicator and two spare bits to discriminate between national and international messages.01 International Network(14 bit SPC)/National Network(16 bit SPC) International Network(14 bit SPC)/National Network(16 bit SPC

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 IuUPFrame Format for predefined size SDUs

PDU Type 0PDU 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).BitsOctets

87654321


FQCRFCI 2


Payload CRC4




NbUP PDU Type 0 Format..

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

BitsOctets

87654321


FQCRFCI 2

Header CRCSpare3Frame Check Sum Part

Payload CRC




NbUP PDU Type 1Format..




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 14PDU 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).BitsNumber of Octets

87654321

PDU Type (=14)Ack/Nack (=0, i.e. procedure)PDU Type 14 Frame Number1Frame Control Part

NbUP Mode versionProcedure Indicator2


Payload CRC

4

Reserved for procedure data5-nFrame Payload part

Spare extensionn-n+32

NbUP PDU Type 14 Format for procedure sending




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.

NBAPETSI 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:

NBAP-PDU

Procedure ID

Procedure code

Dd mode

Criticality

Message discriminator

Transaction ID

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

PDUThe type of PDU sent.

Procedure IDProcedure 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 codeThese 2 fields combine the message type and uniquely identify the message being sent.

CriticalityThe 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 IDThe transaction ID is used to associate all the messages belonging to the same procedure.

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

umts family

Documents