protocol family

CDMA & GSM Cellular TechnologyReference Page

Wireless Communication Protocols and Standards The protocols described here are from the GSM and the CDMA protocol families and most are common to both protocol families.

For more protocols related to cellular protocols see the following families: GPRS, UMTS, CDMA2000

See SS7 for a description of SS7 protocols.

GSM and CDMA protocols described here include:BSMAP Base Station Management Application PartBSSAP BSS Application PartBSSLAP BSSAPLE BSSMAP BSS Managment Application PartBTSM Base Transceiver Station Management CC Call ControlDTAP (CDMA) Direct Transfer Application Part for CDMADTAP (GSM) Direct Transfer Application Part for GSMMM Mobility ManagementMMS Mobile IP Mobile Internet ProtocolRR Radio ResourceSMS Short Message ServiceSMSTP Short Message Transfer Layer Protocol

GSM

In 1989, GSM responsibility was transferred to the European Telecommunication Standards Institute (ETSI), and phase I of the GSM specifications were published in 1990. Commercial service was started in mid1991, and by 1993 there were 36 GSM networks in 22 countries, with 25 additional countries having already selected or considering GSM In addition to Europe, South Africa, Australia, and many Middle and Far East countries have chosen to adopt GSM. By the beginning of 1994, there were 1.3 million subscribers worldwide. The acronym GSM now (aptly) stands for Global System for Mobile telecommunications.

From the beginning, the planners of GSM wanted ISDN compatibility in services offered and control signaling used. The radio link imposed some limitations, however, since the standard ISDN bit rate of 64 Kbps could not be practically achieved.

The digital nature of GSM allows data, both synchronous and asynchronous data, to be transported as a bearer service to or from an ISDN terminal. The data rates supported by GSM are 300 bps, 600 bps, 1200 bps, 2400 bps, and 9600 bps.

The most basic teleservice supported by GSM is telephony. A unique feature of GSM compared to older analog systems is the Short Message Service (SMS). Supplementary services are provided on top of teleservices or bearer services, and include features such as international roaming, caller identification, call forwarding, call waiting, multiparty conversations, and barring of outgoing (international) calls, among others.

CDMA

Code Division Multiple Access (CDMA) is a digital air interface standard, claiming eight to fifteen times the capacity of traditional analog cellular systems. It employs a commercial adaptation of a military spread-spectrum technology. Based on spread spectrum theory, it gives essentially the same services and qualities as wireline service. The primary difference is that access to the local exchange carrier (LEC) is provided via a wireless phone.

Though CDMA’s application in cellular telephony is relatively new, it is not a new technology. CDMA has been used in many military applications, such as:

Anti-jamming (because of the spread signal, it is difficult to jam or interfere with a CDMA signal).

Ranging (measuring the distance of the transmission to know when it will be received). Secure communications (the spread spectrum signal is very hard to detect).

CDMA is a spread spectrum technology, which means that it spreads the information contained in a particular signal of interest over a much greater bandwidth than the original signal. With CDMA, unique digital codes, rather than separate RF frequencies or channels, are used to differentiate subscribers. The codes are shared by both the mobile station (cellular phone) and the base station, and are called pseudo-random code sequences. Since each user is separated by a unique code, all users can share the same frequency band (range of radio spectrum). This gives many unique advantages to the CDMA technique over other RF techniques in cellular communication.

CDMA is a digital multiple access technique and this cellular aspect of the protocol is specified by the Telecommunications Industry Association (TIA) as IS-95. In CDMA, the BSSAP is divided into the DTAP and BSMAP (which corresponds to BSSMAP in GSM).

Telephony Cellular Family

BSMAP

TIA/EIA/IS-634-A, revision A

The Base Station Management Application Part (BSMAP) supports all Radio Resource Management and Facility Management procedures between the MSC and the BS, or to a cell(s) within the BS. BSMAP messages are not passed to the MS, but are used only to perform functions at the MSC or the BS. A BSMAP message (complete layer 3 information) is also used together with a DTAP message to establish a connection for an MS between the BS and the MSC, in response to the first layer 3 interface message sent by the MS to the BS for each MS system request.

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

8 7 6 5 4 3 2 1 Octet

Message type 1

Parameter 2-n

BSMAP header structure

Message TypeA one octet field defining the message type. This mandatory field uniquely defines the function and format of each BSSMAP message.

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

BSSLAP

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

BSSLAP defines the SMLC-BSS layer 3 protocol .The following Location Services related messages are exchanged between the SMLC and the BSS, with the VMSC acting as a relay.

1. TA Request 2. TA Response 3. TOA Request 4. TOA Response 5. Reject 6. Reset 7. Abort 8. TA Layer3 9. MS Position Command 10. MS Position Response

On the A interface the messages are contained in the Location Information IE which is encapsulated in the BSSMAP-LE Connection Oriented Information message as specified in 3GPP TS 08.08. On the Ls interface the messages are contained in the Location Information IE which is encapsulated in the BSSMAP-LE Connection Oriented Information message as specified in 3GPP TS 09.31.

The protocol header appears as follows:

8 7 6 5 4 3 2 1 Octet

Message type 1

Information elements 2-n

Message TypeThe following messages types are available:

Reserved 00000000 TA EQUEST 00000001 TA Response 00000010 TOA Request 00000100TOA Response 00000101 Reject 00001010 Reset 00001011 Abort 00001100 TA LAYER3 00001101 MS Position Command 00001111 MS Posiiton Response 00010000

BSSAP

GSM 08.06 http://www.etsi.fr

The MTP and the SCCP are used to support signalling messages between the Mobile Services Switching Center (MSC) and the Base Station System (BSS). One user function of the SCCP, called BSS Application Part (BSSAP) is defined. In the case of point-to-point calls the BSSAP uses one signalling connection per active mobile station having one or more active transactions for the transfer of layer 3 messages. In the case of a voice group or broadcast call there is always one connection per cell involved in the call and one additional connection per BSS for the transmission of layer 3 messages. There is an additional connection for the speaker in a broadcast call or the first speaker in a voice group call up to the point at which the network decides to transfer them to a common channel. Additional connections may also be required for any mobile stations in the voice group or broadcast call which the network decides to place on a dedicated connection. The BSSAP user function is further subdivided into two separate functions:

The Direct Transfer Application sub-Part (DTAP), also called GSM L3, is used to transfer messages between the MSC and the MS (Mobile Station); the layer-3 information in these messages is not interpreted by the BSS. The descriptions of the layer 3 protocols for the MS-MSC information exchange are contained in the 04- series of GSM Technical Specifications.

The BSS Management Application sub-Part (BSSMAP) supports other procedures between the MSC and the BSS related to the MS (resource management, handover control), or to a cell within the BSS, or to the whole BSS. The description of the layer 3 protocol for the BSSMAP information exchange is contained in Recommendation GSM 08.08.

Both connectionless and connection-oriented procedures are used to support the BSSMAP. Rec. GSM 08.08 explains whether connection oriented or connectionless services should be used for each layer 3 procedure. Connection oriented procedures are used to support the DTAP. A distribution function located in BSSAP, which is reflected in the protocol specification by the layer 3 header, performs the discrimination between the data related to those two subparts.

BSSAP messages include the following fields:

1 byte 1byte

Discrimination DLCI Length

BSSAP header structure

DiscriminationDistribution between the two sub-protocols: BSSMAP and DTAP.

DLCIOnly for DTAP. Used in MSC to BSS messages to indicate the type of origination data link connection over the radio interface.

LengthSubsequent Layer3 message parameter length.

BSSAPLE

http://webapp.etsi.org/key/queryform.asp. 3GPP TS 09.31 and 3GPP TS 04.71

BSSAP-LE is an extension to BSSAP that contains messages and parameters specific to the support of LCS. The BSSAP-LE is part of the LB interface. The following subsets of BSSAP-LE are defined: DTAP-LE and BSSMAP-LE. DTAP-LE messages are transfered between an SMLC and a Type A LMU. BSSMAP-LE messages are transferred between a BSC, MSC and SMLC.

The header appears as follows:

BSSMAP-LE Header

8 7 6 5 4 3 2 1 Octet0 0 0 0 0 0 0 D=0 1

Length indicator = n 2BSSMAP-LE Message Contents 3-n

DTAP-LE Header

8 7 6 5 4 3 2 1 Octet0 0 0 0 0 0 0 D=0 1

DLCI 2Length indicator = n 3

DTAP-LE Message Contents 4-n

Discrimination IndicatorBSSMAP-LE 0 DTAP-LE 1

DLCIThe DLCI in octet 2 is applicable only to DTAP-LE messages.For signaling to a type A LMU using an SDCCH and SAPI=0, the value of the DLCI is 10000000.

Length IndicatorThe length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent BSSMAP-LE or DTAP-LE message parameter.

DTAP-LE MessagesThe following DTAP message types are available: 0X32 REGISTER 0X31 FACILITY 0X21 RELEASE COMPLETE

BSSMAP-LE MessagesThe following BSSMAP-LE message types are available:

0X2B Perform Location Request 0X2D Perform Location Response 0X2E Perform Location Abort 0X1 LMU Connection Request 0X2 LMU Connection Accept 0X3 LMU Connection Reject 0X4 LMU Connection Release 0X2A Connection Oriented Information 0X3A Connectionless Information 0X30 Reset 0X31 Reset Acknowledge

BSSMAP


The BSS Management Application Part (BSSMAP) supports all of the procedures between the MSC and the BSS that require interpretation and processing of information related to single calls, and resource management. Some of the BSSMAP procedures result in, or are triggered by, Radio Resource (RR) management messages defined in GSM 04.08.The format of the BSSMAP protocol is as follows:

8 7 6 5 4 3 2 1 Octet

Message type 1

Information Element 2-n

BSSMAP header structure

Message TypeA one octet field defining the message type. This mandatory field uniquely defines the function and format of each BSSMAP message.


BTSM


BTSM is the Base Station Controller to Base Transceiver Station (BSC - BTS) interface protocol (the A-bis interface). BTSM allows sending messages between the Base Station Controller and the Base Transceiver Station. Protocol messages consist of a series of information elements. For each message there are mandatory information elements and optional information elements. BTSM messages are transmitted on the A-bis interface using the I format of LAPD, except for the Measurement Result message which is sent in UI format.

The structure of BTSM messages is shown in the following diagram:

8 7 6 5 4 3 2 1 Octet

Message discriminator 1

Message type 2


BTSM structure

Message discriminator1-octet field used in all messages to discriminate between Transparent and Non-Transparent messages and also between Radio Link Layer Management, Dedicated Channel Management, Common Channel Management and TRX Management messages.

Message typeUniquely identifies the function of the message being sent. It is a single octet field.

CC


The call control (CC) protocol is one of the protocols of the Connection Management (CM) sublayer. Every mobile station must support the call control protocol. If a mobile station does not support any bearer capability at all then it must respond to a SETUP message with a RELEASE COMPLETE message. In the call control protocol, more than one CC entity are defined. Each CC entity is independent from each other and communicates with the correspondent peer entity using its own MM connection. Different CC entities use different transaction identifiers.

Certain sequences of actions of the two peer entities compose elementary procedures. 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 CC structure is shown here:

8 7 6 5 4 3 2 1 Octet

Protocol Distriminator Transaction ID 1

Message type 2


CC structure

Protocol discriminator0011 identifies the CC protocol.

Transaction IdentifierThe format of the transaction identifier is as follows:

8 7 6 5 4 3 2 1 Octet

TI flag TI value - - - - 1

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 valueTI 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 typeCC message types may be as follows. 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.

0x000000 Escape to nationally specific message types0x00- - - - Call establishment messages:

0001 ALERTING1000 CALL CONFIRMED 0010 CALL PROCEEDING0111 CONNECT

1111 CONNECT ACKNOWLEDGE 1110 EMERGENCY SETUP0011 PROGRESS 0101 SETUP

0x01- - - - Call information phase messages:0111 MODIFY1111 MODIFY COMPLETE0011 MODIFY REJECT0000 USER INFORMATION1000 HOLD1001 HOLD ACKNOWLEDGE1010 HOLD REJECT1100 RETRIEVE1101 RETRIEVE ACKNOWLEDGE1110 RETRIEVE REJECT

0x10- - - - Call clearing messages:0101 DISCONNECT1101 RELEASE1010 RELEASE COMPLETE

0x11- - - - Miscellaneous messages: 1001 CONGESTION CONTROL 1110 NOTIFY1101 STATUS 0100 STATUS ENQUIRY0101 START DTMF 0001 STOP DTMF0010 STOP DTMF ACKNOWLEDGE0110 START DTMF ACKNOWLEDGE0111 START DTMF REJECT1010 FACILITY

DTAP (CDMA)

TIA/EIA/IS-634-A, revision A

The Direct Transfer Application Part (DTAP) messages are used to transfer call processing and mobility management messages to and from the MS. The BS does not use DTAP messages, but must map messages going to and coming from the MSC into the appropriate air interface signaling protocol. Transaction IDs are used to associate the DTAP messages with a particular MS and the current call.The format of the header is shown in the following illustration:

8 7 6 5 4 3 2 1 Octet

Transaction identifier Protocol discriminator 1

Message type 2


DTAP header structure

Protocol discriminatorThe protocol discriminator specifies the message being transferred (CC, MM, RR).Transaction identifierDistinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:

8 7 6 5

TI flag TI value

Transaction identifier


TI valueTI 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 TypeThe message type defines the function of each DTAP message.

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.

DTAP (GSM)

GSM 04.08, 08.06, 08.08 http://www.etsi.fr

The Direct Transfer Application Part (DTAP) is used to transfer call control and mobility management messages between the MSC and the MS. The DTAP information in these messages is not interpreted by the BSS. Messages received from the MS are identified as DTAP by the

Protocol Discriminator Information Element. The majority of radio interface messages are transferred across the BSS MSC interface by DTAP, except for messages belonging to the Radio Resource (RR) management protocol.

The DTAP function is in charge of transferring layer 3 messages from the MS (or from the MSC) to the MSC (or to the MS) without any analysis of the message contents. The interworking between the layer 2 protocol on the radio side and signalling system 7 at the landside is based on the use of individual SCCP connections for each MS and on the distribution function.

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

8 7 6 5 4 3 2 1 Octet

Protocol Distriminator Transaction / Skip 1

0 N(SD) Message Type 2

Information Elements 3-n

GSM L3 structure

Protocol discriminatorIdentifies the L3 protocol to which the standard layer 3 message belongs. Values may be as follows:0000 Group call control0001 Broadcast call control0010 PDSS10011 Call control; call related SS messages0100 PDSS20101 Mobility Management Messages0110 Radio resources management messages1001 SMS messages1011 Non-call related SS messages1110 Extension of the PD to one octet length1111 Tests procedures described in TS GSM 11.10

Transaction ID / Skip identifierEither a transaction identifier, or a skip indictor depending on the level 3 protocol. The transaction identifier contains the transaction value and flag which identifies who allocated the TI.

N(SD)For MM and CM, N(SD) is set to the value of the send state variable. In other level 3 messages, bit 7 is set to 0 by the sending side. Messages received with bit 7 set to 1 are ignored.

Message typeUniquely defines the function and format of each GSM L3 message. The message type is mandatory for all messages. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings in different protocols) and direction (the

same value may have different meanings in the same protocol, when sent from the Mobile Station to the network and when sent from the network to the Mobile Station).

Information elementsThe message type may be followed by various information elements depending on the protocol.

MM


The main function of the Mobility Management (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 MM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer

8 7 6 5 4 3 2 1 Octet

Protocol distriminator Skip indicator 1

Message type 2


MM header structure

Protocol discriminator0101 identifies the MM protocol.

Message typeMM message types may be as follows. 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.

0x00- - - - Registration messages:0001 IMSI DETACH INDICATION0010 LOCATION UPDATING ACCEPT 0100 LOCATION UPDATING REJECT1000 LOCATION UPDATING REQUEST

0x01- - - - Security messages: 0001 AUTHENTICATION REJECT0010 AUTHENTICATION REQUEST 0100 AUTHENTICATION RESPONSE 1000 IDENTITY REQUEST1001 IDENTITY RESPONSE1010 TMSI REALLOCATION COMMAND1011 TMSI REALLOCATION COMPLETE

0x10- - - - Connection management messages:0001 CM SERVICE ACCEPT

0010 CM SERVICE REJECT0011 CM SERVICE ABORT0100 CM SERVICE REQUEST1000 CM REESTABLISHMENT REQUEST1001 ABORT

0x11- - - - Miscellaneous messages:0001 MM STATUS

MMS

http://www.openmobilealliance.org/ OMA-MMS-ENC-v1_1-20021030-C.

The WAP Multimedia Messaging Service (MMS) uses WAP WSP/HTTP as underlying protocols to transfer MMS PDUs between the MMS Client, which resides on the terminal (MS) and the MMS Proxy -Relay.

This structure is based on the well-known message structure of Internet email binary encoding of MMS PDUs. Because of the limited bandwidth of the air interface of mobile networks MMS PDUs are transferred between an MMS Client and an MMS Proxy -Relay in binary encoded message format. This process is called encapsulation. WSP PDUs or HTTP messages, which contain MMS PDUs as their body, are used for this transport.

MMS PDUs, which are described in this specification, are included in WSP PDUs/HTTP messages of different types. The entire MMS information is contained in MMS PDUs, which are encapsulated in WSP PDUs/HTTP messages.

The content type of WSP PDUs/HTTP messages containing MMS PDUs is"application/vnd.wap.mms - message."

MMS has no header structure as it consists of messages.

Field Reference Number: 0x81 Bcc 0x82 Cc 0x83 X-Mms-Content-Location 0x84 Content-Type 0x85 Date 0x86 X-Mms-Delivery-Report 0x87 X-Mms-Delivery-Time 0x88 X-Mms-Expiry 0x89 From 0x8A X-mms-Message-Class 0x8B Message-ID 0x8C X-Mms-Message-Type

0x8D X-Mms-MMS-Version 0x8E X-Mms-Message-Size 0x8F X-Mms-Priority 0x90 X-Mms-Read-Report 0x91 X-Mms-Report-Allowed 0x92 X-Mms-Response-Status 0x93 X-Mms-Response-Text 0x94 X-Mms-Sender-Visibility 0x95 X-Mms-Status 0x96 Subject 0x97 To 0x98 X-Mms-Transaction-Id 0x99 X-Mms-Retrieve-Status 0x9A X-Mms-Retrieve-Text 0x9B X-Mms-Read-Status 0x9C X-Mms-Reply-Charging 0x9D X-Mms-Reply-Charging-

Deadline0x9E X-Mms-Reply-Charging-ID0x9F X-Mms-Reply-Charging-Size0xA0 X-Mms-Previously-Sent-By0xA1 X-Mms-Previously-Sent-Date

Message TypeThe following message types are contained in the PDU: 128 m-send-req 129 m-send-conf 130 m-notification-ind 131 m-notifyresp-ind 132 m-retrieve-conf 133 m-acknowledge-ind 134 m-delivery-ind 135 m-read-rec-ind 136 m-read-orig-ind 137 m-forward-req 138 m-forward-conf

RR


RR (Radio Resource) management procedures include the functions related to the management of the common transmission resources, e.g., the physical channels and the data link connections on control channels. The general purpose of Radio Resource procedures is to establish, maintain and release RR connections that allow a point-to-point dialogue between the network and a Mobile Station. This includes the cell selection/reselection and the handover procedures.

Moreover, Radio Resource management procedures include the reception of the uni-directional BCCH and CCCH when no RR connection is established. This permits automatic cell selection/reselection.

8 7 6 5 4 3 2 1 Octet


Message type 2


RR structure

Protocol discriminator0110 identifies the RR Management protocol.

Skip identifierValue of 0000.

Message typeUniquely defines the function and format of each RR message. The message type is mandatory for all messages. RR message types may be:

00111- - - Channel establishment messages: 011 ADDITIONAL ASSIGNMENT111 IMMEDIATE ASSIGNMENT001 IMMEDIATE ASSIGNMENT EXTENDED 010 IMMEDIATE ASSIGNMENT REJECT

00110- - - Ciphering messages: 101 CIPHERING MODE COMMAND 010 CIPHERING MODE COMPLETE

00101- - - Handover messages: 110 ASSIGNMENT COMMAND 001 ASSIGNMENT COMPLETE111 ASSIGNMENT FAILURE011 HANDOVER COMMAND100 HANDOVER COMPLETE000 HANDOVER FAILURE101 PHYSICAL INFORMATION

00001- - - Channel release messages: 101 CHANNEL RELEASE010 PARTIAL RELEASE111 PARTIAL RELEASE COMPLETE

00100- - - Paging messages:001 PAGING REQUEST TYPE 1010 PAGING REQUEST TYPE 2100 PAGING REQUEST TYPE 3111 PAGING RESPONSE

00011- - - System information messages: 000 SYSTEM INFORMATION TYPE 8 001 SYSTEM INFORMATION TYPE 1010 SYSTEM INFORMATION TYPE 2 011 SYSTEM INFORMATION TYPE 3100 SYSTEM INFORMATION TYPE 4 101 SYSTEM INFORMATION TYPE 5110 SYSTEM INFORMATION TYPE 6111 SYSTEM INFORMATION TYPE 7

00000- - - System information messages:010 SYSTEM INFORMATION TYPE 2bis 011 SYSTEM IN FORMATION TYPE 2ter101 SYSTEM INFORMATION TYPE 5bis110 SYSTEM INFORMATION TYPE 5ter

00010- - - Miscellaneous messages:000 CHANNEL MODE MODIFY010 RR STATUS111 CHANNEL MODE MODIFY ACKNOWLEDGE100 FREQUENCY REDEFINITION 101 MEASUREMENT REPORT110 CLASSMARK CHANGE011 CLASSMARK ENQUIRY

SMS


The purpose of the Short Message Service (SMS)is to provide the means to transfer messages between a GSM PLMN Mobile Station and a Short Message Entity via a Service Center, as described in TS GSM 03.40. The terms "MO" - Mobile Originating - and "MT" - Mobile Terminating - are used to indicate the direction in which the short message is sent.

The SMS structure is as follows for control messages:

8 7 6 5 4 3 2 1 Octet


Message type 2


SMS CP structure

Protocol discriminator1001 identifies the SMS protocol.

Transaction IdentifierSee CC for the format of the Transaction ID.

Message typeThe message type, together with the protocol discriminator, identifies the function of the message being sent. Messages may be of the following:00000001 CP-DATA00000100 CP-ACK00010000 CP-ERROR


The SMS structure is as follows for relay messages:

8 7 6 5 4 3 2 1 Octet

0 0 0 0 0 MTI 1

Message Reference 2


SMS structure

MTIMessage type indicator. Values are as follows:

Bit Value (3 2 1) Direction RP-Message0 0 0 ms -> n RP-DATA0 0 0 n -> ms Reserved0 0 1 ms -> n Reserved0 0 1 n -> ms RP-DATA0 1 0 ms -> n RP-ACK 0 1 0 n -> ms Reserved0 1 1 ms -> n Reserved0 1 1 n -> ms RP-ACK1 0 0 ms -> n RP-ERROR1 0 0 n -> ms Reserved1 0 1 ms -> n Reserved1 0 1 n -> ms RP-ERROR1 1 0 ms -> n RP-SMMA1 1 0 n -> ms Reserved1 1 1 ms -> n Reserved1 1 1 n -> ms Reserved

Message ReferenceUsed to link an RP-ACK message or RP-ERROR message to the associated RP-DaATA or RP-SMNA message.


SMSTP

ETSI TS 100 901. (You can download all the ETSI files from www.ETSI.org)

The Short Message Transfer Layer Protocol (SMSTP) short message point-to-point services comprise two basic services:

SM MT (Short Message Mobile Terminated Point-to-Point). SM MO (Short Message Mobile Originated Point-to-Point).

SM MT denotes the capability of the GSM system to transfer a short message submitted from the SC to one MS, 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.SM MO denotes the capability of the GSM 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.The message must include the address of that SME to which the SC will eventually attempt to relay the short message.The text messages to be transferred by means of the SM MT or SM MO contain up to 140 octets.The structure of the SMSTP protocol header is as follows:

Information Type/Reference Presence Format Length

Element

Message type Message type M V 1

Message TypeThe type of messge. The following message types are available:SC To MS -

0123

SMS-DELIVERSMS-SUBMIT-REPORT SMS-STATUS-REPORT Reserved

MS To SC -

0123

SMS-DELIVER-REPORT SMS-SUBMIT SMS-COMMAND Reserved

Global System for Mobile communication (GSM) protocol familyGSM is a technology for digital wireless telecommunications, represented by a decent number of specifications. Parts of GSM are based on the fixed-line ISDN technology.

The original "air interface" for GSM handsets, for second-generation (2G) wireless telephony, was a TDMA interface; the third-generation interface, W-CDMA, is a CDMA interface. GSM, however, refers to more than just the "air interface"; it refers to the complete set of protocols.

The 3rd Generation Partnership Project (3GPP) maintains the GSM standards; most of the specifications for GSM can now be found at the 3GPP Web site.

History

Incidentally, the initial abbreviation of GSM was "Groupe Spécial Mobile" (Special Mobile Group). The acronym was preserved but a new, English meaning was given to it later, once the potential of the technology was understood.

Protocols

The GSM protocol family consists of many protocols, and other protocols are conveyed on top of these.

GSMMAP : GSM Mobile Application Part, ETSI TS 129 002 GSM SMS : The GSM Short Messaging Service. CAMEL : Customized Applications for Mobile Enhanced Logic ETSI 300 374 GSM A : GSM A Interface (BSSMAP/DTAP) WapProtocolFamily : The entire collection of WAP protocols can be conveyed over

GSM.

http://wiki.wireshark.org/WAP

http://wiki.wireshark.org/WapProtocolFamily

http://wiki.wireshark.org/GSM%20A

http://wiki.wireshark.org/CAMEL

http://wiki.wireshark.org/GSM%20SMS

http://wiki.wireshark.org/ETSI

http://wiki.wireshark.org/GSMMAP

http://www.3gpp.org/

http://wiki.wireshark.org/3GPP

http://wiki.wireshark.org/ISDN

Network Elements and Interfaces

Network and Switching Subsystem

Circuit Switching Control Nodes ("Core Circuit")

MSC Mobile Switching Center

Controls Mobile Calls. Is in charge of the radio part. In Release 4 of UMTS, this function is split between a Media Gateway (MGw), which handles the bearer (user) traffic (voice, video, etc.) and an MSC Server, which handles the call control. In GSM and earlier releases of UMTS, the base stations communicate with the MSC, which handles both bearer traffic and call control. A Gateway MSC, or Gw MSC (or GMSC) connects to other networks, such as the PSTN or other mobile networks.

TSC Transit Switching Center

Transit Exchange for calls to be routed either between MSCs or towards other networks.

Registers

VLR Visitor Location Registry

Keeps track of the users of the network both resident and in roaming

HLR Home Location Registry

Keeps track of (a part of) the subscribers of the network and how they can use it. Each user is identified by the IMSI, a 12 digit number (ususally printed in the SIM); the first three digits are the country identifier (eg. 222 is Italy), the following two digits are the network (in Italy 01 is TIM, 02 is Vodaphone), and the rest is the unique number of the SIM. The HLR contains such data as the current roaming, redirection, and special services settings.

EIR Equipment Information Registry

Keeps track of Mobile Phones; it could be used to find stolen equipment if operators were forced to use it (they make plenty of money out of calls made from stolen phones so they won't do it unless forced).

AuC Authentication Centre

Mantains information regarding the cryptographic keys that are in the SIM (Subscriber Information Module). It authenticates the user in the network.

FNR Flexible Number Registry

Keeps a Database of Numbers owned and exported by the network (Number Portability).

GSM Radio Access Network (GERAN)

BSC Base Station Controller

Maintains and controls the radio part of the network.

BTS Base Tranceiver Station

The machine with the antennae. A slave of the BSC from which it takes its configuration.

MS Mobile Set

The phone or modem. "PC" refers to a personal computer with the MS as a modem.

UMTS Radio Access Network (UTRAN)

RNC Radio Network Controller

Like the BSC but for UMTS.

Node-B (RBS) Radio Base Station

Like the BTS but for UMTS.

UE User Equipment

The phone or modem. "PC" refers to a personal computer with the UE as a modem.

GPRS Nodes (Packet Core)

SGSN Serving GPRS Support Node

Does for the Packet part what the MSC does for the Circuit Switched Part

GGSN Gateway GPRS Support Node

A gateway between the SGSNs and the other networks

GSM Interfaces

A Interface

Interface between the MSC and the BSC. Control Plane Protocols:

GSM A DTAP (MS<-->MSC) GSM A BSSAP Base Station System Application Part

Abis (Ab) Interface

Interface between the BTS and the BSC:

Layer2: LAPD Link Access Procedure, Channel D Layer3: RSL (Radio Signalling Link) as per GSM TS 08.58 Layer3: OML (Organization and Maintenance Link) as per GSM TS 12.21

B Interface

Interface between an MSC and a VLR.

GSMMAP MAP Mobile Application Protocol




C Interface

Interface between an MSC and a HLR.


D Interface

Interface between a VLR and a HLR.


E Interface

Interface between two MSCs or TSCs.

GSMMAP MAP Mobile Application Protocol ISUP ISDN User Part

F Interface

Interface between an MSC and an EIR.


G Interface

Interface between VLRs.


H Interface

Interface Between an HLR and the AuC

GSMMAP MAP Mobile Application Protocol ??? DIAMETER Diameter ???

Um Interface

Interface between an MS and a BTS.

BSSAP BSS Application Part GSMTAP pseudo-header for encapsulating Um into IP

http://wiki.wireshark.org/GSMTAP

http://wiki.wireshark.org/BSSAP

http://wiki.wireshark.org/DIAMETER




http://wiki.wireshark.org/ISUP




UMTS Interfaces

UMTS uses packet networks, ATM and/or IP, instead of TDM to transport user data (Voice, Video, etc.) So two sets of protocols are used - Control Plane Protocols (that control the calls) and user plane protocols (that carry the user's data).

Nc

Interface between two MSCs or TSCs.

Control Plane Protocols:

o ISUP ISDN User Part o BICC Bearer Independent Call Control

Mc

Interface between an MSC or TSC and its controlled MGws.

Control Plane Protocol:

o H248/MEGACO Media Gateway Control Protocol

Nb

Interface between two Media Gateways.

Control Protocols IP

o Q.1970 IPBCP IP Bearer Control Protocol (a dialect of SDP) ATM (AAL2)

o Q.2930 ALCAP Access Link Control Application Part

User Plane Transport Protocols

IP

o RTP Real Time Protocol o RTCP Real Time Control Protocol

ATM o AAL2

IuCS

Interface between the MGw and the RNC.

http://wiki.wireshark.org/RTCP

http://wiki.wireshark.org/RTP

http://wiki.wireshark.org/ALCAP

http://wiki.wireshark.org/H248/MEGACO

http://wiki.wireshark.org/BICC

http://wiki.wireshark.org/ISUP

IuCS-CP Control Plane

RANAP Radio Access Network Application Protocol IuCS-UP User Plane ATM

o AAL2

IuR

Interface between the two RNCs (used for switching calls that had been handed over from one RNC to the other).

IuR-CP Control Plane

RNSAP Radio Network Subsystem Application Protocol IuR-UP User Plane CS circuit switched (calls)

o ATM AAL2

PS packet switched (IP)

o IP over GTP over IP over ATM

IuB

Interface between an RNC and a Node-B.

IuB-CP Control Plane

o NBAP Node-B Application Protocol

o Q.2930 ALCAP Access Link Control Application Part, runs directly on top of SSCOP while on the Iu and IuR it runs on top of MTP3b

o MAC Medium Access Control o RLC Radio Link Control

IuB-UP Control Plane

o CS circuit switched (calls) o ATM

AAL2 PS packet switched (IP)

o IP over GTP over IP over ATM

http://wiki.wireshark.org/GTP

http://wiki.wireshark.org/RLC

http://wiki.wireshark.org/MAC

http://wiki.wireshark.org/SSCOP

http://wiki.wireshark.org/ALCAP

http://wiki.wireshark.org/NBAP


http://wiki.wireshark.org/RNSAP

http://wiki.wireshark.org/RANAP

IuBC

SABP Service Area Broadcast Protocol (SABP) TS 25.419

IuPS

Interface between the RNC and the SGSN.

Uu

Radio Resource Control (RRC) 3G TS 25.331

GPRS Interfaces

Gb

The Gb interface is the name given to the logical connection between a SGSN and a BSS (also referred to as a PCUSN or PCU). (The Um interface applies between the BSS and MS.) Even though the physical Gb interface is between the SGSN and the BSS, it includes the LLC and SNDCP protocol layers, which are used for logical communication directly between the SGSN and MS.

Gn

Used to carry signalling and data traffic between GSNs using GTP protocol.

Gi

The interface between GGSN and external packet data networks such as the Internet.

Gf

Gs

This is an optional interface for PS/CS interoperability. Using the Gs interface it is possible to perform combined GPRS/IMSI attaches, combined location updates and paging the subscriber using PS facilities. The protocol is BSSAP+ specified in 3GPP TS 29.016 ( supported by Wireshark on ssn 98)

Gr

GSMMAP MAP-based interface between SGSN and HLR.


http://www.3gpp.org/ftp/Specs/html-info/29016.htm

http://wiki.wireshark.org/BSSAP%2B


http://wiki.wireshark.org/RRC

http://wiki.wireshark.org/SABP

Gc

Gp

Same as Gn, but hadles GTP traffic between GSNs in different PLMNs.

Ge

The Ge is an interface between gprsSSF entity in SGSN and gsmSCF entity in SCP. It is used to handle CAMEL dialogues using the CAP protocol (supported by Wireshark).

GPRS Reference PageUpgrade GSM Technology GPRS protocols described here include:BCC Broadcast Call ControlBSSAP+ BSS Application Part PlusBSSGP Base Station System GPRS ProtocolGCC Group Call ControlGMM GPRS Mobility ManagementGSM GPRS Session ManagementGTP GPRS Tunneling ProtocolLLC Logical Link ControlNS Network ServiceRLP Radio Link ProtocolSMSCB Short Message Service Cell BroadcastSNDCP Sub-Network Dependant Convergence ProtocolTOM Tunnelling of MessagesTRAU Transcoding Rate and Adaption UnitSee SS7 for a description of SS7 protocols.See Cellular for a description of GSM protocols.

For more information on GPRS decoding and analysis

GPRS (general packet radio service) is used as a data services upgrade to any GSM network. It allows GSM networks to be truly compatible with the Internet. GPRS uses a packet-mode technique to transfer bursty traffic in an efficient manner. It allows transmission bit rates from 9.6 Kbps to more than 150 Kbps per user.

The two key benefits of GPRS are a better use of radio and network resources and completely transparent IP support. GPRS optimizes the use of network and radio resources. It uses radio

http://wiki.wireshark.org/CAMEL


http://www.radcom.com/Products.aspx?BoneId=663&ObjId=-1&=&=&=&staticName1=&staticName2=

resources only when there is data to be sent or received. As a true packet technology it allows end user applications to only occupy the network when a payload is being transferred, and so is well adapted to the very bursty nature of data applications. Another important feature of GPRS is that it provides immediate connectivity and high throughput.

Applications based on standard data protocols such as IP and X.25 are supported. In GPRS four different quality of service levels are supported. To support data applications GPRS utilizes several new network nodes in addition to the network nodes in the GSM PLMN. These nodes are responsible for traffic routing and other interworking functions with external packet-switched data networks, subscriber location, cell selection, roaming and many other functions that any cellular network needs for operation.

The GPRS is illustrated here in relation to the OSI model:Click the protocols on the map to see more details.

GPRS Family

BCC

3G TS 24.069 version 3.1.0

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

Generally a number of mobiles stations (MS) participate in a broadcast call. Consequently, there is generally 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:

8 7 6 5 4 3 2 1 Octet


Message type 2


BCC beader 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:

8 7 6 5

TI flag 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:

0x110001 IMMEDIATE SETUP0x110010 SETUP0x110011 CONNECT0x110100 TERMINATION0x110101 TERMINATION REQUEST0x110110 TERMINATION REJECT0x111000 STATUS0x111001 GET STATUS0x111010 SET PARAMETER


BSSAP+

http://www.etsi.org/ GSM 09.18 version 7.1.0 release 1998

BSSAP+ defines use of mobile resources when a mobile station supports both GSM circuit switched services and GSM packet switched services. It defines procedures used on the Serving GPRS Support Node (SGSN) to Visitors Location Register (VLR) for interoperability between circuit and packet switched services. Layer 3 messages on the Gs interface are defined.

BSSAP+ BSSAP+

SCCP SCCP

MTP L3 MTP L3

MTP L2 MTP L2

L1 L1

SGSN Gs MSC/VLR

BSSAP+ protocol layer structure over Gs interface

The Gs interface connects the databases in the MSC/VLR and the SGSN. The procedures the of BSSAP+ protocol 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 in BSSAP+ 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 (see ITU-T Q.714).

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.

8 7 6 5 4 3 2 1 Octet

Message type 1


BSSAP+ beader structure .

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

Value Message type

00000000 Unassigned: treated as an unknown Message type.00000001 BSSAP+-PAGING-REQUEST.00000010 BSSAP+-PAGING-REJECT00000011to00001000 Unassigned: treated as an unknown Message type.00001001 00001001BSSAP+-LOCATION-UPDATE-REQUEST.00001010 BSSAP+-LOCATION-UPDATE-ACCEPT.00001011 BSSAP+-LOCATION-UPDATE-REJECT.00001100 BSSAP+-TMSI-REALLOCATION-COMPLETE.00001101 BSSAP+-ALERT-REQUEST.00001110 BSSAP+-ALERT-ACK.00001111 BSSAP+-ALERT-REJECT.00010000 BSSAP+-MS-ACTIVITY-INDICATION.00010001 BSSAP+-GPRS-DETACH-INDICATION.00010010 BSSAP+-GPRS-DETACH-ACK.00010011 BSSAP+-IMSI-DETACH-INDICATION.00010100 BSSAP+-IMSI-DETACH-ACK.00010101 BSSAP+-RESET-INDICATION.00010110 BSSAP+-RESET-ACK.00010111 BSSAP+-MS-INFORMATION-REQUEST.00011000 BSSAP+-MS-INFORMATION-RESPONSE.00011001 Unassigned: treated as an unknown Message type.00011010 BSSAP+-MM-INFORMATION-REQUEST.00011101 BSSAP+-MOBILE-STATUS.00011110 Unassigned: treated as an unknown Message type.00011111 BSSAP+-MS-UNREACHABLE.

Each message type has specific information elements

00000001 IMSI.00000010 VLR number.00000011 TMSI.00000100 Location area identifier.00000101 Channel Needed.00000110 eMLPP Priority.00000111 Unassigned: treated as an unknown IEI.00001000 Gs cause.00001001 SGSN number.00001010 GPRS location update type.00001011 Unassigned: treated as an unknown IEI.00001100 Unassigned: treated as an unknown IEI.00001101 Mobile station classmark 1.00001110 Mobile identity.00001111 Reject cause.00010000 IMSI detach from GPRS service type.

00010001 IMSI detach from non-GPRS service type.00010010 Information requested.00010011 PTMSI.00010100 IMEI.00010101 IMEISV.00010110 Unassigned: treated as an unknown IEI.00010111 MM information.00011000 Cell Global Identity.00011001 Location information age.00011010 Mobile station state.00011011 Erroneous message.00011100to11111111 Unassigned: treated as an unknown IEI.

BSSGP

GSM 08.18 version 6.1.0 http://www.etsi.fr

The NS transports BSS (base station system) GPRS protocol PDUs between a BSS and an SGSN (serving GPRS support node). The primary functions of the BSSGP include:

Provision by an SGSN to a BSS of radio related information used by the RLC/MAC function (in the downlink).

Provision by a BSS to an SGSN of radio related information derived from the RLC/MAC function (In the uplink).

Provision of functionality to enable two physically distinct nodes, an SGSN and a BSS, to operate node management control functions.

BSSGP PDUs are of the following format:

8 7 6 5 4 3 2 1 Octets

PDU type 1

Other Information Elements 2-n

NS PDU structure

GCC

3G TS 24.068 version 3.1.0

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 Connection Management (CM) sublayer protocols (see GSM 04.07).

Generally a number of mobiles 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 assumes 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.


8 7 6 5 4 3 2 1 Octet


Message type 2


GCC beader structure .



8 7 6 5

TI flag TI value




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



GMM

GSM 04.08 http://www.etsi.org

GPRS uses 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, for instance, 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.


8 7 6 5 4 3 2 1 Octet

Protocol discriminator Skip indicator 1

Message type 2


GMM beader 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

GSM 04.08 http://www.etsi.org

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.


8 7 6 5 4 3 2 1 Octet


Message type 2


GSM beader 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

specifies a tunnel control and management protocol which allows the SGSN to provide GPRS 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 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. GPRS 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 20 octet header used for all GTP messages.

8 7 6 5 4 3 2 1 Octets

Version PT Spare ' 1 1 1 ' SNN 1

Message type 2

Length 3-4

Sequence Number 5-6

Flow label 7-8

SNDCP N-PDULLC Number 9

Spare ' 1 1 1 1 1 1 1 1 ' 10

Spare ' 1 1 1 1 1 1 1 1 ' 11

Spare ' 1 1 1 1 1 1 1 1 ' 12

TID 13-20

Outline of GTP header

VersionSet to 0 to indicate the first version of GTP

ReservedReserved bits for future use, set to 1.

LFNFlag indicating whether the LLC frame number is included or not.

Message TypeType of GTP message.

LengthIndicates the length in octets of the GTP message (G-PDU).

Sequence numberTransaction identity for signalling messages and an increasing sequence number for tunnelled T-PDUs.

Flow labelIdentifies unambiguously a GTP flow.

LLC frame numberUsed at the Inter SGSN Routing Update procedure to coordinate the data tranmsission on the link layer between the MS and the SGSN.

xSpare bits x indicate the unused bits which are set to 0 by the sending side and are ignored by the receiving side.

FNContinuation of LLC frame number.

TIDTunnel identifier that points out MM and PDP contexts.The format of the TID is as follows:

8 7 6 5 4 3 2 1 Octets

MCC digit 2 MCC digit 1 1

MNC digit 1 MCC digit 3 2

MSIN digit 1 MNC digit 2 3

MSIN digit 3 MSIN digit 2 4




NSAPI MSIN digit 10 8

TID Format

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

NSAPINetwork service access point identifier.

LLC


LLC defines the logical link control layer protocol to be used for packet data transfer between the mobile station (MS) and a serving GPRS support node (SGSN). LLC spans from the MS to the SGSN and is intended for use with both acknowledged and unacknowledged data transfer.

The frame formats defined for LLC are based on those defined for LAPD and RLP. However, there are important differences between LLC and other protocols, in particular with regard to frame delimitation methods and transparency mechanisms. These differences are necessary for independence from the radio path.

LLC supports two modes of operation:

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

All LLC layer peer-to-peer exchanges are in frames of the following format:

8 7 6 5 4 3 2 1 Octets

Address Field 1

Control Field(variable length, max. 36 octets)

2-n

Information Field (variable length, max. N201 octets)

Frame Chack Sequence Field

(3 octets)

LLC frame format

AddressThe address field contains the SAPI and identifies the DLCI for which a downlink frame is

intended and the DLCI transmitting an uplink frame. The length of the address field is 1 byte and it has the following format:

8 7 6 5 4 3 2 1

PD C/R XX SAPI

Address field structure

PDProtocol Discriminator bit indicates whether a frame is an LLC frame or belongs to a different protocol. LLC frames have the PD bit set to 0. If a frame with the PD bit set to 1 is received, then it is treated as an invalid frame.

C/R Identifies a frame as either a command or a response. The MS side sends commands with the C/R bit set to 0, and responses with the C/R bit set to 1. The SGSN side does the opposite; i.e., commands are sent with C/R set to 1 and responses are sent with C/R set to 0. The combinations for the SGSN side and MS side are as follows.

Type Direction C/R value Command SGSN side to MS side 1 Command MS side to SGSN side 0 Response SGSN side to MS side 0 Response MS side to SGSN side 1

XXReserved.

SAPIService Access Point Identifier identifies a point at which LLC services are provided by an LLE to a layer-3 entity.

ControlIdentifies the type of frame. Four types of control field formats are specified:

Confirmed information transfer (I format) Supervisory functions (S format) Unconfirmed information transfer (UI format) Control functions (U format)

InformationContains the various commands and responses.

FCSFrame check sequence field consists of a 24 bit cyclic redundancy check (CRC) code. The CRC-24 is used to detect bit errors in the frame header and information fields.

NS


The Network Service performs the transport of NS SDUs between the SGSN (serving GPRS support node) and BSS (base station system). Services provided to the NS user include:

Network Service SDU transfer. The Network Service entity provides network service primitives allowing for transmission and reception of upper layer protocol data units between the BSS and SGSN. The NS SDUs are transferred in order by the Network Service, but under exceptional circumstances order may not be maintained.

Network congestion indication. Congestion recovery control actions may be performed by the Sub-Network Service (e.g. Frame Relay). Congestion reporting mechanisms available in the Sub-Network Service implementation shall be used by the Network Service to report congestion.

Status indication. Status indication shall be used to inform the NS user of the NS affecting events e.g. change in the available transmission capabilities.

NS PDUs are of the following format:

8 7 6 5 4 3 2 1 Octets

PDU type 1


NS PDU structure

PDU typePDU type may be:NS-ALIVENS-ALIVE-ACKNS-BLOCKNS-BLOCK-ACKNS-RESETNS-RESET-ACKNS-STATUSNS-UNBLOCKNS-UNBLOCK-ACKNS-UNITDATA

Information element valueThe following IEs may be present depending on the PDU type:CauseNS-VCINS PDU

BVCINSEI

RLP


The Radio Link Protocol (RLP) for data transmission over the GSM PLMN covers the Layer 2 functionality of the ISO OSI reference model. It has been tailored to the needs of digital radio transmission and provides the OSI data link service. RLP spans from the Mobile Station (MS) to the interworking function located at the nearest Mobile Switching Center (MSC) or beyond. Three versions of RLP exist.

Version 0: Single-link basic versionVersion 1: Single-link extended versionVersion 2: Multi-link version.

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:

Header Information FCS

16 bit 200 bit 24 bit


RLP 240-bit frame format

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 header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames.

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

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

U C/R X X 1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X

S C/R S1 S2 0 1 1 1 1 1 N(R)

I+S C/R S1 S2 N(S) P/F N(R)

Bits 1-16

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.

U C/R X X 1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X

S X X X 0 1 1 1 1 1 P/F S1 S2 N(R) X UP

I+S N(S) P/F S1 S2 N(R) S UP

Bits 1-24

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

1 command0 response

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

XDon'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:

SABMUADISC

11100001100010

DMNULLUIXIDTESTREMAP

110001111000000111010011110001

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

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

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

DM11000The disconnected mode encoding is used as a response message.

NULL11110

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

XID11101Exchange 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 00111The information field of this frame is test information.

REMAP 0001A 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.

SS represents the L2 status bit.

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

RR 00REJ 01RNR 10SREJ 11

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

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

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

SREJSelective Reject is used to request retransmission of a single frame.

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

SMSCB


The Short Message Service Cell Broadcast (SMSCB) protocol is a service in which short messages may be broadcast from a PLMN to Mobile Stations (MS)s. SMSCB messages come from different sources (e.g. traffic reports, weather reports). The source and subject of the SMSCB message is identified by a message identifier in the SMSCB message header. A sequence number in the SMSCB message header enables the MS to determine when a new message from a given source is available. SMSCB messages are not acknowledged by the MS. Reception of SMSCB messages by the MS is only possible in idle mode. The geographical area over which each SMSCB message is transmitted is selected by the PLMN operator, by

agreement with the provider of the information. A SMSCB message is an end-to-end message that is formatted by/for the SMSCB application, and which is intended for customer viewing. A CB message is any message sent on the basic or extended CBCH. It can be an occurrence of a SMSCB message, or a schedule message. The SMS Cell Broadcast service is designed to minimize the battery usage requirements on a MS. A MS can read the first part of a CB message and then decide whether or not to read the rest of the message. In addition, the network may broadcast Schedule Messages, providing information in advance about the CB messages that will be sent immediately afterwards. The MS may use this scheduling information to restrict reception to those messages the customer is interested in receiving. This SMSCB DRX feature is optional in the network and the MS.

The structure of the SMSCB protocol header is as follows:

8 7 6 5 4 3 2 1 Octets

Spare0

Link ProtocolDiscriminator0 1

Last Block

Sequence number 1

Link Protocol DiscriminatorThe link protocol discriminator.

Last BlockWhen the LB bit is set to "0", the next block may contain SMSCB information.

Sequence NumberThe sequence number. Sequence numbers can be as follows:

0123415 Default

First block Second block Third block Fourth block First schedule block NULL messageReserved

SNDCP


Sub-Network Dependant Convergence Protocol (SNDCP) uses the services provided by the LLC layer and the Session Management (SM) sub-layer. 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 LLC protocol data units (LL-

PDUs) and re-assembly of LL-PDUs into an N-PDU.

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

8 7 6 5 4 3 2 1 Octets

X C T M NSAPI 1

DCOMP PCOMP 2

Data3-n

SN-DATA PDU structure

The SN-UNITDATA PDU is used for unacknowledged data transfer. Its format is as follows:

8 7 6 5 4 3 2 1 Octets

X C T M NSAPI 1

DCOMP PCOMP 2

Segment offset N-PDU number 3

E N-PDU number (continued) 4

N-PDU number (extended) 5

Data 6-n

SN-UNITDATA PDU structure

NSAPINetwork service access point identifier. Values may be:

0 Escape mechanisms for future extensions 1 Point-to-mutlipoint multicast (PTM-M) information 2-4 Reserved for future use 5-15 Dynamicallly allocated NSAPI value

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

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

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

XSpare bit is set to 0.

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

0 No compression.1-14 Points to the data compression identifier negotiated

dynamically.15 Reserved for future extensions.

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

0 No compression.1-14 Points to the protocol control information compression

identifier negotiated dynamically.15 Reserved for future extensions.

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

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

EExtension bit for N-PDU number.0 Next octet is used for data.1 Next octet is used for N-PDU number extensions.

TOM

ftp://ftp.3gpp.org/Specs 3GPP TS 04.64 version 8.6.0 Release 1999 – Annex B. (ETSI TS 101 351 V8.6.0 (2000-12)).

Tunnelling of Messages (TOM) is a generic protocol layer used for the exchange of TOM Protocol Envelopes between the MS and the SGSN. TOM uses two LLC SAPs, one for high-priority messages and another for low-priority messages. The TOM Protocol Envelope is composed of a header (containing one or more octets) and a message capsule. The TOM Protocol Header contains information about the specific application using the TOM protocol layer and any other protocol discriminator-specific information. The Message Capsule is the actual payload of information in the TOM Protocol Envelope. One of the uses of the TOM protocol layer is to tunnel signalling messages between an MS and a non-GSM MSC/VLR when GPRS network elements are used in non-GSM networks. The Structure of the TOM protocol header is as follows:

8 7 6 5 4 3 2 1

Remaining Length of TOM Protocol Header

TOM Protocol Discriminator

Remaining Octets of TOM Protocol Header (Variable length, max. 14 octets)

Message Capsule (Variable length, max. 220 octets)

TOM Protocol Discriminator

0 0 0 0 Not specified

0 0 0 11 1 1 1

TIA/EIA-136 [22]Reserved for extension

All other values are reservedIf any other value than 0 0 0 1 is received, then the TOM Protocol Envelope is discarded with no further action

Remaining Length of TOM Protocol HeaderRemaining Length of TOM Protocol Header indicates the number of octets remaining in the TOM-protocol-header part of the TOM Protocol Envelope, and is coded as follows:

bits 8 7 6 5

0 0 0 0 00 0 0 1 1 1 1 1 0 141 1 1 1

octets remaining in TOM protocol headeroctet remaining in TOM protocol headeroctets remaining in TOM protocol headerReserved for extension

If the value 1 1 1 1 is received, then the TOM Protocol Envelope is discarded with no further action.Remaining Octets of TOM Protocol HeaderThis field contains the octets following the first octet in the TOM-protocol-header. If present, the interpretation of the information contained in this field is TOM Protocol Discriminator-specific.

Message CapsuleThis field contains TOM Protocol Discriminator-specific payload in the TOM Protocol Envelope (field Length depends on the general length of the frame).

TRAU

GSM 08.60. (You can download all the ETSI files from www.ETSI.org)

The Transcoding Rate and Adaptation Unit. (TRAU) protocol is an entity that performs a transcoding function for speech channels and RA (Rate Adaptation) for data channels. It works as follows: when the transcoders/rate adaptors are positioned remote to the BTS, the information between the Channel Codec Unit (CCU) and the remote Transcoder/Rate Adaptor Unit (TRAU) is transferred in frames with a fixed length of 320 bits (20 ms). These frames are denoted "TRAU frames". Within these frames, both the speech/data and the TRAU associated control signals are transferred.The Abis interface should be the same if the transcoder is positioned 1) at the MSC site of the BSS or if it is positioned 2) at the BSC site of the BSS. In case 1), the BSC should be considered as transparent for 16 kbit/s channels.In case of 4,8 and 9,6 kbit/s channel coding when data is adapted to the 320 bit frames, a conversion function is required in addition to the conversion/rate adaptation specified in GSM

08.20. This function constitutes the RAA. In case of 14,5 kbit/s channel coding, no RAA rate adaptation is required because V.110 framing is not used.The TRAU is considered a part of the BSC, and the signaling between the BSC and the TRAU (e.g. detection of call release, handover and transfer of O&M information) may be performed by using BSC internal signals. The signaling between the CCU and the TRAU, using TRAU frames as specified here, is mandatory when the Abis interface is applied.The functions inside the TRAU are:

"Remote Transcoder and Rate Adaptor Control Function" (RTRACF); "Remote Speech Handler Function" (RSHF); The RAA function in case of 4,8 and 9,6 kbit/s channel coding; The RAA' function in case of 14,5 kbit/s channel coding; The RA2 function; The transcoder function. Optionally the TFO functions (see GSM 08.62).

The protocol header structure of the TRAU protocol is as follows:

8 7 6 5 4 3 2 1 octets

Synchronize1

2

Syn Frame Type 3

SynchronizeThe frame synchronization is obtained by means of the first two octets in each frame, with all bits coded binary "0", and the first bit in octet no. 2, 4, 6, 8, ... 38 coded binary "1".

Frame TypeThe Frame Type:

25681416202226272831

Full RateO&M Adaptive Multi-Rate DataIdle Speech Idle Speech Data 14.5 Data Enhanced Full Rate O&M Full Rate Extended Data

UMTS Technology Reference PageAn evolution from the GSM technology network standards

The following protocols appear in this familyAAL2 see ATMAAL5 see ATMAMR Adaptive Multi-Rate Speech CodecBCC Broadcast Call Control.BMC Broadcast/Multicast Control Protocol BSSAP+ Base Station System Application Part ProtocolCAMEL Customized Applications for Mobile network Enhanced LogicCC Circuit-switched Call Control ProtocolFP Frame ProtocolGCC Group Call ControlGMM GPRS Mobility Management.GSM GPRS Session ManagementGTP GPRS Tunneling ProtocolluUP Iu User Plane ProtocolMAC Medium Access ControlMAP Mobile Application Part

MM Mobility Management.MTP-3B Message Transfer Part Level 3B:NbUP NBAP Node B Application Part PCAP PDCP Packet Data Convergence ProtocolQ2630 (ALCAP) Access Link Control Application Part.RANAP Radio Access Network Application Protocol.RLC Radio Link Control ProtocolRLP Radio Link ProtocolRNSAP Radio Network Subsystem Application PartRRC Radio Resource Control SCCP Signalling Connection Control Part.SCTP Stream Control Transmission ProtocolSNDCP Sub-Network Dependant Convergance ProtocolSM Session Management.SMS Short Message ServiceSMS (TP) Short Message Transfer ProtocolSS Supplementary Services SSCOP (Q.2110)SSCF-NNI (Q.2140)

Third Generation Cellular Networks (commonly referred to as 3G) represent the next phase in the evolution of cellular technology, evolution from the analog systems (1st generation) and digital systems (2nd generation). 3G networks will represent a shift from voice-centric services to converged services, including voice, data, video, fax and so forth.

UMTS is the dominant 3G solution being developed, representing an evolution from the GSM network standards, interoperating with a GSM core network. The 3G will implement a new access network, utilizing both improved radio interfaces and different technologies for the interface between the access network and the radio network.

UMTS will use a wideband CDMA technology for transmission, and a more efficient modulation than GSM. This will allow UMTS to reach higher utilization, and offer higher bandwidth to the end-user. UMTS also implements an ATM infrastructure for the wireline interface, using both AAL2 and AAL5 adaptations; AAL2 for real-time traffic and AAL5 for data and signaling.

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/s1 1 1 AMR 5,15 kbit/s2 2 2 AMR 5,90 kbit/s3 3 3 AMR 6,70 kbit/s4 4 4 AMR 7,40 kbit/s5 5 5 AMR 7,95 kbit/s6 6 6 AMR 10,2 kbit/s7 7 7 AMR 12,2 kbit/s8 - - AMR SID9 - - GSM-EFR SID10 - - TDMA-EFR SID11 - - PDC-EFR SID12-14 - - For future use15 - - No Data (No transmission/No reception)

FQIIndicates whether the data in the frame contains errors.

0 Bad or corrupted frame1 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).

http://www.radcom.com/Products.aspx?BoneId=+663++&ObjId=+120+&=&=&=&staticName1=&staticName2=

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.


8 7 6 5 4 3 2 1 Octet


Message type 2


BCC header structure



8 7 6 5

TI flag TI value




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:




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:

8 7 6 5 4 3 2 1 Octet

Message Type 1

Information Element 2-n

Coding of message types:

1 CBS Message2 Schedule Message3 CBS41 Message0, 4.. 255 Reserved for future use (PDUs with this coding will be

discarded by this version of the protocol)


BSSAP+


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:

8 7 6 5 4 3 2 1 Octet

Message type 1


BSSAP+ header structure

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

0x10x20x70x80x90xA0xB0xC0xD0xE0xF0x100x110x120x130x140x150x160x170x180x1A0x1D0x1F

BSSAP+-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 elements

0000000100000010000000110000010000000101000001100000011100001000 00001001000010100000101100001100000011010000111000001111000100000001000100010010 00010011000101000001010100010110000101110001100000011001000110100001101100011100to11111111

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


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:

8 7 6 5 4 3 2 1 Octet

Message type 1

Information element 1-n

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

0x010x020x030x040x050x060x070x08

Alerting Call Proceeding Progress CC-ESTABLISHMENT Setup CC-ESTABLISHMENT CONFIRMED Connect Call Confirmed

0x090x0B0x0E0x0F 0x100x130x170x180x190x1A0x1C

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.

Header Payload

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:

8 7 6 5 4 3 2 1 Octet

Header CRC FT 1

CFN 2

Spare TFI of first DCH 3

4

Spare TFI of last DCH 5

DL Data Frame Header

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

8 7 6 5 4 3 2 1 Octet

Header CRC FT 1

CFN 2

Spare TFI of first DCH 3

4

Spare TFI of last DCH 5

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.


8 7 6 5 4 3 2 1 Octet


Message type 2


GCC header structure



8 7 6 5

TI flag TI value




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




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.


8 7 6 5 4 3 2 1 Octet


Message type 2


GMM header structure

Protocol discriminator1000 identifies the GMM protocol.



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


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:

8 7 6 5 4 3 2 1 Octet


Message type 2


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.

8 7 6 5 4 3 2 1 Octet

Version Reserved LFN 1

Message type 2

Length 3-4

Sequence 5-6

Flow label 7-8

Reserved 9-12

TID 13-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:

8 7 6 5 4 3 2 1 Octet

MCC digit 2 MCC digit 1 1

MNC digit 1 MCC digit 3 2

MSIN digit 1 MNC digit 2 3





NSAPI MSIN digit 10 8

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

8 7 6 5 4 3 2 1

PDU Type (=0) Frame Number 1 Frame Control PartFQC RFCI 2

Header CRCPayload

CRC3 Frame

Check Sum PartPayload CRC 4

Payload Fields 5-n Frame Payload

part

Payload Fields Padding

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

8 7 6 5 4 3 2 1


Header CRC Spare 3 Frame Check Sum Part

Payload CRC


part



IUup PDU Type 1Format . .


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



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

Bits Number

of Octets

8 7 6 5 4 3 2 1

PDU Type (=14)Ack/Nack (=0, i.e.

procedure)

PDU Type 14 Frame Number

1Frame Control Part

IUup Mode Procedure Indicator 2

version

Header CRCPayload

CRC

3 Frame Check Sum PartPayload CRC

4

Reserved for procedure data 5-n Frame Payload

partSpare extension n-n+32

IUup PDU Type 14 Format for procedure sending


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


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-Id C/T MAC 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 bits

UE-Id Type

00 U-RNTI01 C-RNTI10 Reserved(PDUs with this coding will be discarded by

this version of the protocol)11 Reserved(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 type Length of UE ID fieldU-RNTI 32 bitsC-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 field Designation0000 Logical channel 10001 Logical channel 2... ... 1110 Logical channel 151111 Reserved(PDUs with this coding will be discarded by this

version of the 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

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.


8 7 6 5 4 3 2 1 Octet


Message type 2


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:

0x00 xxxx Registration messages:0001 IMSI DETACH INDICATION0010 LOCATION UPDATING ACCEPT0100 LOCATION UPDATING REJECT1000 LOCATION UPDATING REQUEST

0x01 xxxx Security messages:0001 AUTHENTICATION REJECT0010 AUTHENTICATION REQUEST0100 AUTHENTICATION RESPONSE1000 IDENTITY REQUEST1001 IDENTITY RESPONSE1010 TMSI REALLOCATION COMMAND1011 TMSI REALLOCATION COMPLETE

0x10 xxxx Connection management messages:0001 CM SERVICE ACCEPT0010 CM SERVICE REJECT0011 CM SERVICE ABORT0100 CM SERVICE REQUEST1000 CM REESTABLISHMENT REQUEST1001 ABORT

0x11 xxxx Miscellaneous messages:0001 MM 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:

8 7 6 5 4 3 2 1 Octets

Priority Spare 1

Sub Service Indicator Spare Service Indicator 2

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

Frame 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

8 7 6 5 4 3 2 1


Header CRCPayload

CRC3 Frame

Check Sum PartPayload CRC 4


part



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


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

8 7 6 5 4 3 2 1


Header CRC Spare 3 Frame Check Sum Part

Payload CRC


part



NbUP PDU Type 1Format . .


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



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

Bits Number

of

8 7 6 5 4 3 2 1

Octets

PDU Type (=14)Ack/Nack (=0, i.e.

procedure)

PDU Type 14 Frame Number

1 Frame Control PartNbUP Mode

versionProcedure Indicator 2

Header CRCPayload

CRC

3 Frame Check Sum PartPayload CRC

4

Reserved for procedure data 5-n Frame Payload

partSpare extension n-n+32

NbUP PDU Type 14 Format for procedure sending


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


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.

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: o Successful: A signaling message explicitly indicates that the elementary

procedure successfully completed with the receipt of the response. o Unsuccessful: A signaling message explicitly indicates that the EP failed. Class 2

EPs are always considered always successful.

PCAP Services

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 Functions

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.

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

8 7 6 5 4 3 2 1 Octets

Data 0-n

PDCP Data PDU

8 7 6 5 4 3 2 1 Octets

PDU type PID 1

Data 2-n

PDCP SeqNum PDU

8 7 6 5 4 3 2 1 Octets

PDU type PID 1

Sequence number 2

Data 4-n

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

01 Default

PDCP Data PDUPDCP SeqNum PDUReserved

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

Sequence NumberThe PDCP PDU sequence number

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

Q2630

ATMLayer 2 (also UMTS)ITU-T Recommendation Q.2630.1http://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

8 7 6 5 4 3 2 1 Octets

Destination signalling association identifier 1

2

3

4

Message identifier 5

Message compatibility 6

Destination Signalling Association IdentifierThe Destination Singalling Association Identifier.

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

123456789

Block Confirm Block Request Confusion Establish Confirm Establish Request Release Confirm Release RequestReset Confirm Reset Request

1011

Unblock Confirm Unblock Request

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

. 8 7 6 5 4 3 2 1 Octets

Header Parameter identfier 1

Parameter compatibility 2

Parameter length 3

Payload

Fields 4-n

RANAP

3G TS 25.413 V3.1.0 www.3gpp.org/ftp/specs

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:

0 RAB-Assignment1 Iu-Release2 RelocationPreparation3 RelocationResourceAllocation4 RelocationCancel5 SRNS-ContextTransfer 6 SecurityModeControl7 DataVolumeReport8 CN-InformationBroadcast9 Reset10 RAB-ReleaseRequest11 Iu-ReleaseRequest12 RelocationDetect13 RelocationComplete314 Paging 15 CommonID16 CN-InvokeTrace17 LocationReportingControl18 LocationReport19 InitialUE-Message20 DirectTransfer 21 OverloadControl22 ErrorIndication23 SRNS-DataForward24 ForwardSRNS-Context 25 PrivateMessage526 CN-DeactivateTrace27 ResetResource 28 RANAP-Relocation

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.

8 7 6 5 4 3 2 1 Octets

Data 1

TrD PDU

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.

8 7 6 5 4 3 2 1 Octets

Sequence Number E . .

Length Indicator E . (Optional)(1)

.

.

.

.

Length Indicator E . (Optional)

Data. .

PAD OctN (Optional)

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.

8 7 6 5 4 3 2 1 Octets .

D/C Sequence Number 1

Sequence Number P HE 2

Length Indicator E 3 (Optional)(1)

.

.

.

Length Indicator E (Optional)

Data

PAD or a piggybacked STATUS PDU N (Optional)

Control PDUs

STATUS PDU and Piggybacked STATUS PDUThe 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.

8 7 6 5 4 3 2 1 Octets

D/C PDU type SUFI1 1

SUFI1 2

... .

SUFIK .

PAD N

Piggybacked Status PDUThe 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.

8 7 6 5 4 3 2 1 Octets

R2 PDU type SUFI1 1

SUFI1 2

... .

SUFIK .

PAD N

RESET PDUThe 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 PDUThe 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.

8 7 6 5 4 3 2 1 Octets

D/C PDU type RSN R1 1

HFNI 2

HFNI

HFNI

PADN

RESET, RESET ACK 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 FieldThe 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.

01

Control PDU Acknowledged mode data PDU

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

000001010 011-111

STATUSRESETRESET ACKReserved

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.

01

Status report not requestedRequest a status report

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

01

dataLength indicator and 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.

000110-11

The succeeding octet contains dataThe succeeding octet contains a length indicator and E bitReserved (PDUs with this coding will be discarded by this version of the protocol)

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.

SUFIThe 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

RLP


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.


Header Information FCS



RLP 240-bit frame format

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 header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames.

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

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

U C/R X X 1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X

S C/R S1 S2 0 1 1 1 1 1 N(R)

I+S C/R S1 S2 N(S) P/F N(R)

Bits 1-16

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.

U C/R X X 1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X

S X X X 0 1 1 1 1 1 P/F S1 S2 N(R) X UP

I+S N(S) P/F S1 S2 N(R) S UP

Bits 1-24

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

1 command0 response

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

XDon'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:

SABMUADISCDMNULLUIXIDTESTREMAP

11100001100010110001111000000111010011110001

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

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

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

DM11000The disconnected mode encoding is used as a response message.

NULL11110

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

XID11101Exchange 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 00111The information field of this frame is test information.

REMAP 0001A 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.

SS represents the L2 status bit.

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

RR 00REJ 01RNR 10SREJ 11

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

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

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

SREJSelective Reject is used to request retransmission of a single frame.

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

RNSAP


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

1. RNSAP Basic Mobility Procedures2. RNSAP DCH Procedures3. RNSAP Common Transport Channel Procedures4. 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:

8 7 6 5 4 3 2 1 Octets

Message type 1

Transaction ID 2 or 2,3

Message TypeAll messages are text messages in asn.1 format.

Transaction IDAssociates all the messges belonging to the same procedure.

RRC


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.

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.

8 7 6 5 4 3 2 1 Octets

Source Port Number1

2

Destination Port Number3

4

Verification Tag

5

6

7

8

Adler 32 Checksum

9

10

11

12

Source Port NumberThis 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 NumberThis 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 TagThe 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 ChecksumThis 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.

8 7 6 5 4 3 2 1 Octets

Chunk ID 1

Chunk Flags 2

Chunk Length3

4

Chunk Value (variable) 5-n

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

ID Value Chunk Type00000000 00000001 00000010 00000011 00000100 0000010100000110 00000111 00001000 00001001 00001010 00001011 00001100

Payload Data (DATA)Initiation (INIT)Initiation Acknowledgment (INIT ACK)Selective Acknowledgment (SACK) Heartbeat Request (HEARTBEAT) Heartbeat Acknowledgment (HEARTBEAT ACK)Abort (ABORT)Shutdown (SHUTDOWN) Shutdown Acknowledgment (SHUTDOWN ACK) Operation Error (ERROR)State Cookie (COOKIE)Cookie Acknowledgment (COOKIE ACK) Reserved for Explicit Congestion Notification Echo (ECNE)

00001101 Reserved for Congestion Window Reduced (CWR)

00001110 to 11111101 - reserved by IETF 11111110 11111111 -

Vendor-specific Chunk Extensions IETF-defined Chunk Extensions

Chunk FlagsThe 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 LengthThe size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk ValueThis 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.

Fixed Parameters StatusInitiate Tag Receiver Window Credit Number of Outbound Streams Number of Inbound Streams Initial TSN

MandatoryMandatoryMandatory MandatoryMandatory

Variable Parameters Status IPv4 Address/Port IPv6 Address/Port Cookie Preservative Reserved For ECN Capable Host Name Address Supported Address Types

Optional Optional Optional Optional Optional Optional

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.

SHUTDOWNAn 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 ExtensionsThis 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.

SNDCP

GSM 04.65 version 6.1.0 www.3gpp.org/ftp/specs

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:

8 7 6 5 4 3 2 1 Octet

X C T M NSAPI 1

DCOMP PCOMP 2

Data 3-n

SN-DATA PDU structure

NSAPINetwork service access point identifier. Values may be:

0 Escape mechanisms for future extensions.1 Point-to-multipoint multicast (PTM-M) information.2-4 Reserved for future use.5-15 Dynamically allocated NSAPI value.

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

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

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

XSpare bit is set to 0.

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

0 No compression.1-14 Points to the data compression identifier negotiated dynamically.15 Reserved for future extensions.

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

0 No compression.

1-14Points to the protocol control information compression identifier negotiated dynamically.

15 Reserved for future extensions.

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

N-PDU number0-2047 when the extension bit is set to 0.2048-524287 if the extension bit is set to 1.

EExtension bit for N-PDU number.

0 Next octet is used for data.

SM

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

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:

8 7 6 5 4 3 2 1 Octet


Message type 2


SM header structure

Protocol discriminator1010 identifies the SM protocol.


Message typeUniquely 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:

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 accept

0 1 0 1 0 1 0 1 SM Status


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 MessageThe format of the control protocol message header is shown in the following illustration:

8 7 6 5 4 3 2 1 Octet

Protocol discriminator Transaction identifier 1

Message type 2


SMS control protocol header structureheader structure

Protocol discriminator1001 identifies the SMS protocol.

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

4 3 2 1

TI flag TI value - - - -



TI valueTI 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 typeThe message type, together with the protocol discriminator, identifies the function of the message being sent. Messages may be of the following:

0000 0001 CP-DATA0000 0100 CP-ACK0001 0000 CP-ERROR

Information elementsEach 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 MessageThe format of the relay protocol message header is shown in the following illustration:

8 7 6 5 4 3 2 1 Octet

0 0 0 0 0 1

Message reference 2


SMS relay protocol header structure

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

0 0 0 ms -> n RP-DATA0 0 0 n -> ms Reserved0 0 1 ms -> n Reserved0 0 1 n -> ms RP-DATA0 1 0 ms -> n RP-ACK 0 1 0 n -> ms Reserved0 1 1 ms -> n Reserved0 1 1 n -> ms RP-ACK1 0 0 ms -> n RP-ERROR1 0 0 n -> ms Reserved1 0 1 ms -> n Reserved1 0 1 n -> ms RP-ERROR1 1 0 ms -> n RP-SMMA1 1 0 n -> ms Reserved1 1 1 ms -> n Reserved

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

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


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:

8 7 6 5 4 3 2 1 Octet

Message type 1


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

0123

SMS-DELIVER SMS-SUBMIT-REPORT SMS-STATUS-REPORT Reserved

MS To SC

01

SMS-DELIVER-REPORT SMS-SUBMIT

23

SMS-COMMAND Reserved

SS


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:

8 7 6 5 4 3 2 1 Octet

Protocol Discriminator Transaction ID 1

Message type 2


Protocol Discriminator The Protocol discriminator (must be 0x0B). Transaction Identifier The format and coding of transaction identifier values. Message Type The Message type number.

The following message types are available

42 Release Complete 58 Facility 59 Register

protocol family

Documents