CDMA & GSM Cellular Technology

Reference 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 Part BSSAP BSS Application Part BSSLAP BSSAPLE BSSMAP BSS Managment Application Part BTSM Base Transceiver Station Management CC Call Control DTAP (CDMA) Direct Transfer Application Part for CDMA DTAP (GSM) Direct Transfer Application Part for GSM MM Mobility Management MMS Mobile IP Mobile Internet Protocol RR Radio Resource SMS Short Message Service SMSTP 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 CDMAs application in cellular telephony is relatively new, it is not a new technology. CDMA has been used in many military applications, such as:
y y y

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 1 2-n

Message type Parameter BSMAP header structure

Message Type A one octet field defining the message type. This mandatory field uniquely defines the function and format of each BSSMAP message. Information Element Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

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 1 2-n

Message type Information elements Message Type The following messages types are available: Reserved TA EQUEST TA Response TOA Request TOA Response Reject Reset Abort TA LAYER3 MS Position Command MS Posiiton Response 00000000 00000001 00000010 00000100 00000101 00001010 00001011 00001100 00001101 00001111 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:
y

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 Discrimination 1byte DLCI Length BSSAP header structure Discrimination Distribution between the two sub-protocols: BSSMAP and DTAP. DLCI Only for DTAP. Used in MSC to BSS messages to indicate the type of origination data link connection over the radio interface. Length Subsequent 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 0 7 0 6 5 4 3 2 0 0 0 0 0 Length indicator = n BSSMAP-LE Message Contents 1 Octet D=0 1 2 3-n

DTAP-LE Header 8 0 7 0 6 0 5 0 4 0 3 0 2 0 1 Octet D=0 1 2 3 4-n

DLCI Length indicator = n DTAP-LE Message Contents Discrimination Indicator BSSMAP-LE 0 DTAP-LE 1

DLCI The 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 Indicator The 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 Messages The following DTAP message types are available: 0X32 REGISTER 0X31 FACILITY 0X21 RELEASE COMPLETE

BSSMAP-LE Messages The following BSSMAP-LE message types are available: 0X2B 0X2D 0X2E 0X1 0X2 0X3 0X4 0X2A 0X3A 0X30 0X31 Perform Location Request Perform Location Response Perform Location Abort LMU Connection Request LMU Connection Accept LMU Connection Reject LMU Connection Release Connection Oriented Information Connectionless Information Reset Reset Acknowledge

BSSMAP GSM 08.08 http://www.etsi.fr 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 1 2-n

Message type Information Element BSSMAP header structure

Message Type A one octet field defining the message type. This mandatory field uniquely defines the function and format of each BSSMAP message. Information Element Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator. BTSM GSM 08.58 http://www.etsi.fr

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 1 2 3-n

Message discriminator Message type Information elements BTSM structure

Message discriminator 1-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 type Uniquely identifies the function of the message being sent. It is a single octet field.

CC GSM 04.08 http://www.etsi.fr 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:
y y y y

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 1 2 3-n

Protocol Distriminator Message type

Transaction ID

Information elements CC structure Protocol discriminator 0011 identifies the CC protocol. Transaction Identifier The format of the transaction identifier is as follows: 8 TI flag 7 6 TI value Transaction Identifier 5 4 3 ---2 1

Octet 1

TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. Message type CC 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 types 0x00- - - - Call establishment messages: 0001 ALERTING 1000 CALL CONFIRMED 0010 CALL PROCEEDING 0111 CONNECT 1111 CONNECT ACKNOWLEDGE

1110 0011 0101 0x01- - - 0111 1111 0011 0000 1000 1001 1010 1100 1101 1110 0x10- - - 0101 1101 1010 0x11- - - 1001 1110 1101 0100 0101 0001 0010 0110 0111 1010

EMERGENCY SETUP PROGRESS SETUP Call information phase messages: MODIFY MODIFY COMPLETE MODIFY REJECT USER INFORMATION HOLD HOLD ACKNOWLEDGE HOLD REJECT RETRIEVE RETRIEVE ACKNOWLEDGE RETRIEVE REJECT Call clearing messages: DISCONNECT RELEASE RELEASE COMPLETE Miscellaneous messages: CONGESTION CONTROL NOTIFY STATUS STATUS ENQUIRY START DTMF STOP DTMF STOP DTMF ACKNOWLEDGE START DTMF ACKNOWLEDGE START DTMF REJECT 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 1

Transaction identifier

Protocol discriminator

Message type Information elements DTAP header structure

2 3-n

Protocol discriminator The protocol discriminator specifies the message being transferred (CC, MM, RR). Transaction identifier Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows: 8 TI flag 7 6 TI value Transaction identifier TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. Message Type The message type defines the function of each DTAP message. Information elements Each information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included. 5

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 0 7 N(SD) 6 5 4 3 2 1 Octet 1 2 3-n

Protocol Distriminator

Transaction / Skip Message Type

Information Elements GSM L3 structure

Protocol discriminator Identifies the L3 protocol to which the standard layer 3 message belongs. Values may be as follows: 0000 Group call control 0001 Broadcast call control 0010 PDSS1 0011 Call control; call related SS messages 0100 PDSS2 0101 Mobility Management Messages 0110 Radio resources management messages 1001 SMS messages 1011 Non-call related SS messages 1110 Extension of the PD to one octet length 1111 Tests procedures described in TS GSM 11.10 Transaction ID / Skip identifier Either 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 type Uniquely 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 elements The message type may be followed by various information elements depending on the protocol.

MM GSM 04.08 http://www.etsi.fr 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 1 2 3-n

Protocol distriminator

Skip indicator

Message type Information elements MM header structure Protocol discriminator 0101 identifies the MM protocol.

Message type MM 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- - - 0001 0010 0100 1000 0x01- - - 0001 0010 0100 1000 1001 1010 1011 0x10- - - Registration messages: IMSI DETACH INDICATION LOCATION UPDATING ACCEPT LOCATION UPDATING REJECT LOCATION UPDATING REQUEST Security messages: AUTHENTICATION REJECT AUTHENTICATION REQUEST AUTHENTICATION RESPONSE IDENTITY REQUEST IDENTITY RESPONSE TMSI REALLOCATION COMMAND TMSI REALLOCATION COMPLETE Connection management messages:

0001 0010 0011 0100 1000 1001 0x11- - - 0001

CM SERVICE ACCEPT CM SERVICE REJECT CM SERVICE ABORT CM SERVICE REQUEST CM REESTABLISHMENT REQUEST ABORT Miscellaneous messages: 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 0x8D 0x8E 0x8F 0x90 0x91 0x92 0x93 0x94 0x95 0x96 0x97 0x98 0x99 0x9A 0x9B 0x9C 0x9D 0x9E 0x9F 0xA0 0xA1

X-Mms-Message-Type X-Mms-MMS-Version X-Mms-Message-Size X-Mms-Priority X-Mms-Read-Report X-Mms-Report-Allowed X-Mms-Response-Status X-Mms-Response-Text X-Mms-Sender-Visibility X-Mms-Status Subject To X-Mms-Transaction-Id X-Mms-Retrieve-Status X-Mms-Retrieve-Text X-Mms-Read-Status X-Mms-Reply-Charging X-Mms-Reply-ChargingDeadline X-Mms-Reply-Charging-ID X-Mms-Reply-Charging-Size X-Mms-Previously-Sent-By X-Mms-Previously-Sent-Date

Message Type The 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 GSM 04.08 http://www.etsi.fr 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 1 2 3-n

Protocol distriminator

Skip indicator

Message type Information elements RR structure Protocol discriminator 0110 identifies the RR Management protocol. Skip identifier Value of 0000.

Message type Uniquely defines the function and format of each RR message. The message type is mandatory for all messages. RR message types may be: 00111- - 011 111 001 010 00110- - 101 010 00101- - 110 001 111 011 100 000 101 00001- - 101 010 111 00100- - 001 010 100 Channel establishment messages: ADDITIONAL ASSIGNMENT IMMEDIATE ASSIGNMENT IMMEDIATE ASSIGNMENT EXTENDED IMMEDIATE ASSIGNMENT REJECT Ciphering messages: CIPHERING MODE COMMAND CIPHERING MODE COMPLETE Handover messages: ASSIGNMENT COMMAND ASSIGNMENT COMPLETE ASSIGNMENT FAILURE HANDOVER COMMAND HANDOVER COMPLETE HANDOVER FAILURE PHYSICAL INFORMATION Channel release messages: CHANNEL RELEASE PARTIAL RELEASE PARTIAL RELEASE COMPLETE Paging messages: PAGING REQUEST TYPE 1 PAGING REQUEST TYPE 2 PAGING REQUEST TYPE 3

111 00011- - 000 001 010 011 100 101 110 111 00000- - 010 011 101 110 00010- - 000 010 111 100 101 110 011 SMS

PAGING RESPONSE System information messages: SYSTEM INFORMATION TYPE 8 SYSTEM INFORMATION TYPE 1 SYSTEM INFORMATION TYPE 2 SYSTEM INFORMATION TYPE 3 SYSTEM INFORMATION TYPE 4 SYSTEM INFORMATION TYPE 5 SYSTEM INFORMATION TYPE 6 SYSTEM INFORMATION TYPE 7 System information messages: SYSTEM INFORMATION TYPE 2bis SYSTEM IN FORMATION TYPE 2ter SYSTEM INFORMATION TYPE 5bis SYSTEM INFORMATION TYPE 5ter Miscellaneous messages: CHANNEL MODE MODIFY RR STATUS CHANNEL MODE MODIFY ACKNOWLEDGE FREQUENCY REDEFINITION MEASUREMENT REPORT CLASSMARK CHANGE CLASSMARK ENQUIRY

GSM 04.11 http://www.etsi.fr 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 1 2 3-n

Protocol distriminator

Skip indicator

Message type Information elements SMS CP structure Protocol discriminator 1001 identifies the SMS protocol.

Transaction Identifier See CC for the format of the Transaction ID. Message type The message type, together with the protocol discriminator, identifies the function of the message being sent. Messages may be of the following: 00000001 CP-DATA 00000100 CP-ACK 00010000 CP-ERROR Information Element Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator. The SMS structure is as follows for relay messages: 8 0 7 0 6 0 5 0 4 0 3 2 MTI 1 Octet 1 2 3-n

Message Reference Information elements SMS structure MTI Message type indicator. Values are as follows:
Bit Value (3 2 1) 000 000 001 001 010 010 011 011 100 100 101 101 110 110 111 111 Direction ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms RP-Message RP-DATA Reserved Reserved RP-DATA RP-ACK Reserved Reserved RP-ACK RP-ERROR Reserved Reserved RP-ERROR RP-SMMA Reserved Reserved Reserved

Message Reference Used to link an RP-ACK message or RP-ERROR message to the associated RP-DaATA or RPSMNA message.

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

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

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 Element Message type Type/Reference Presence Format Length Message type M V 1

Message Type The type of messge. The following message types are available: SC To MS 0 1 2 3 SMS-DELIVER SMS-SUBMIT-REPORT SMS-STATUS-REPORT Reserved

MS To SC 0 1 2 3 SMS-DELIVER-REPORT SMS-SUBMIT SMS-COMMAND Reserved

Global System for Mobile communication (GSM) protocol family

GSM 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 Spcial 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.
y y y y y

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.

Network Elements and Interfaces

Network and Switching Subsystem Circuit Switching Control Nodes ("Core Circuit") MSC Mobile Switching Center
y

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

y

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

Registers VLR Visitor Location Registry

y

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

HLR Home Location Registry

y

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

y

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

y

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

y

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

GSM Radio Access Network (GERAN) BSC Base Station Controller

y

Maintains and controls the radio part of the network.

BTS Base Tranceiver Station

y

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

MS Mobile Set
y

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

y

Like the BSC but for UMTS.

Node-B (RBS) Radio Base Station

y

Like the BTS but for UMTS.

UE User Equipment
y

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

y

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

GGSN Gateway GPRS Support Node

y

A gateway between the SGSNs and the other networks

GSM Interfaces A Interface

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

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

Abis (Ab) Interface

Interface between the BTS and the BSC:

y y y

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.

y

GSMMAP MAP Mobile Application Protocol

C Interface

Interface between an MSC and a HLR.

y

GSMMAP MAP Mobile Application Protocol

D Interface

Interface between a VLR and a HLR.

y

GSMMAP MAP Mobile Application Protocol

E Interface

Interface between two MSCs or TSCs.

y y

GSMMAP MAP Mobile Application Protocol ISUP ISDN User Part

F Interface

Interface between an MSC and an EIR.

y

GSMMAP MAP Mobile Application Protocol

G Interface

Interface between VLRs.

y

GSMMAP MAP Mobile Application Protocol

H Interface

Interface Between an HLR and the AuC

y y

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

Um Interface

Interface between an MS and a BTS.

y y

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

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.

y

Control Plane Protocols:

o o

ISUP ISDN User Part BICC Bearer Independent Call Control

Mc

Interface between an MSC or TSC and its controlled MGws.

y

Control Plane Protocol:

o

H248/MEGACO Media Gateway Control Protocol

Nb

Interface between two Media Gateways.

y y y

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 o

RTP Real Time Protocol RTCP Real Time Control Protocol

AAL2

ATM
o

IuCS

Interface between the MGw and the RNC.

y y y

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

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.

y

IuB-CP Control Plane

o o

NBAP Node-B Application Protocol 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 CS circuit switched (calls) ATM  AAL2 PS packet switched (IP)
o o o

IP over GTP over IP over ATM

IuBC
y

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.

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 Page

Upgrade GSM Technology GPRS protocols described here include: BCC Broadcast Call Control BSSAP+ BSS Application Part Plus BSSGP Base Station System GPRS Protocol GCC Group Call Control GMM GPRS Mobility Management GSM GPRS Session Management GTP GPRS Tunneling Protocol LLC Logical Link Control NS Network Service RLP Radio Link Protocol SMSCB Short Message Service Cell Broadcast SNDCP Sub-Network Dependant Convergence Protocol TOM Tunnelling of Messages TRAU Transcoding Rate and Adaption Unit See 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 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:
y y y y

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 1 2 3-n .

Transaction identifier

Protocol discriminator

Message type Information elements BCC beader structure

Protocol discriminator The protocol discriminator specifies the message being transferred

Transaction identifier Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows: 8 TI flag 7 Transaction identifier TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. Message type The message type defines the function of each BCC message. The message type defines the function of each BCC message. The following message types exist: 0x110001 0x110010 0x110011 0x110100 0x110101 0x110110 0x111000 0x111001 0x111010 IMMEDIATE SETUP SETUP CONNECT TERMINATION TERMINATION REQUEST TERMINATION REJECT STATUS GET STATUS SET PARAMETER 6 TI value 5

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

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+ SCCP MTP L3 MTP L2 L1 SGSN Gs BSSAP+ SCCP MTP L3 MTP L2 L1 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 classA 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 1 2-n .

Message type Information elements 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 00000010 00000011 to 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111 00010000 00010001 00010010 00010011 00010100 00010101 00010110 00010111 00011000 00011001 00011010 00011101 00011110 00011111

BSSAP+-PAGING-REQUEST. BSSAP+-PAGING-REJECT

Unassigned: treated as an unknown Message type. 00001001BSSAP+-LOCATION-UPDATE-REQUEST. BSSAP+-LOCATION-UPDATE-ACCEPT. BSSAP+-LOCATION-UPDATE-REJECT. BSSAP+-TMSI-REALLOCATION-COMPLETE. BSSAP+-ALERT-REQUEST. BSSAP+-ALERT-ACK. BSSAP+-ALERT-REJECT. BSSAP+-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-RESPONSE. Unassigned: treated as an unknown Message type. BSSAP+-MM-INFORMATION-REQUEST. BSSAP+-MOBILE-STATUS. Unassigned: treated as an unknown Message type. BSSAP+-MS-UNREACHABLE.

Each message type has specific information elements 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111 00010000 00010001 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.

00010010 00010011 00010100 00010101 00010110 00010111 00011000 00011001 00011010 00011011 00011100 to 11111111

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.

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

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 1 2-n

PDU type Other Information Elements 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:
y y y y

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

All messages have the following header: 8 7 6 5 4 3 2 1 Octet 1 2 3-n .

Transaction identifier

Protocol discriminator

Message type Information elements GCC beader structure

Protocol discriminator The protocol discriminator specifies the message being transferred

Transaction identifier Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows: 8 TI flag 7 Transaction identifier TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. Message type The message type defines the function of each GCC message. The following message types exist: 0x110001 0x110010 0x110011 0x1100100 0x110101 0x110110 0x111000 0x111001 0x111010 IMMEDIATE SETUP SETUP CONNECT TERMINATION TERMINATION REQUEST TERMINATION REJECT STATUS GET STATUS SET PARAMETER 6 TI value 5

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

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. The format of the header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n .

Protocol discriminator Message type

Skip indicator

Information elements GMM beader structure Protocol discriminator 1000 identifies the GMM protocol. Skip indicator The value of this field is 0000.

Message type Uniquely defines the function and format of each GMM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GMM message types may be: 00000001 00000010 00000011 00000100 00000101 00000110 00001000 00001001 00001010 00001011 00010000 00010001 00010010 00010011 00010100 00010101 00010110 00100000 00100001 Attach request Attach accept Attach complete Attach reject Detach request Detach accept Routing area update request Routing area update accept Routing area update complete Routing area update reject P-TMSI reallocation command P-TMSI reallocation complete Authentication and ciphering req Authentication and ciphering resp Authentication and ciphering rej Identity request Identity response GMM status GMM information

Information elements Various 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. The format of the header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n .

Protocol discriminator Message type

Skip indicator

Information elements GSM beader structure Protocol discriminator 1010 identifies the GSM protocol. Skip indicator The value of this field is 0000.

Message type Uniquely defines the function and format of each GSM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GSM message types may be: 01xxxxxx 01000001 01000010 01000011 01000100 01000101 01000110 01000111 01001000 01001001 01010000 01010001 Session management messages Activate PDP context request Activate PDP context accept Activate PDP context reject Request PDP context activation Request PDP context activation rej. Deactivate PDP context request Deactivate PDP context accept Modify PDP context request Modify PDP context accept Activate AA PDP context request Activate AA PDP context accept

01010010 01010011 01010100 01010101

Activate AA PDP context reject Deactivate AA PDP context request Deactivate AA PDP context accept SM Status

Information elements Various information elements.

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 Version 6 5 PT 4 3 2 1 SNN Octets 1 2 3-4 5-6 7-8 9 10 11 12 13-20

Spare ' 1 1 1 '

Message type Length Sequence Number Flow label SNDCP N-PDULLC Number Spare ' 1 1 1 1 1 1 1 1 ' Spare ' 1 1 1 1 1 1 1 1 ' Spare ' 1 1 1 1 1 1 1 1 ' TID Outline of GTP header Version Set to 0 to indicate the first version of GTP

Reserved Reserved bits for future use, set to 1. LFN Flag indicating whether the LLC frame number is included or not. Message Type Type of GTP message. Length Indicates the length in octets of the GTP message (G-PDU). Sequence number Transaction identity for signalling messages and an increasing sequence number for tunnelled TPDUs. Flow label Identifies unambiguously a GTP flow. LLC frame number Used at the Inter SGSN Routing Update procedure to coordinate the data tranmsission on the link layer between the MS and the SGSN. x Spare bits x indicate the unused bits which are set to 0 by the sending side and are ignored by the receiving side. FN Continuation of LLC frame number. TID Tunnel 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 1 2 3 4 5 6 7 8

MCC digit 2 MNC digit 1 MSIN digit 1 MSIN digit 3 MSIN digit 5 MSIN digit 7 MSIN digit 9 NSAPI

MCC digit 1 MCC digit 3 MNC digit 2 MSIN digit 2 MSIN digit 4 MSIN digit 6 MSIN digit 8 MSIN digit 10

TID Format

MCC, MNC, MSIN digits Parts of the IMSI (defined in GMS 04.08). NSAPI Network service access point identifier.

LLC GSM 04.64 version 6.1.0 http://www.etsi.fr 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:
y y

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 1 2-n Control Field (variable length, max. 36 octets)

Address Field

Information Field (variable length, max. N201 octets)

Frame Chack Sequence Field (3 octets)

LLC frame format Address The 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 PD 7 C/R 6 XX 5 4 3 SAPI 2 1

Address field structure PD Protocol 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 Command Command Response Response XX Reserved. SAPI Service Access Point Identifier identifies a point at which LLC services are provided by an LLE to a layer-3 entity. Control Identifies the type of frame. Four types of control field formats are specified:
y y y y

Direction SGSN side to MS side MS side to SGSN side SGSN side to MS side MS side to SGSN side

C/R value 1 0 0 1

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

Information Contains the various commands and responses.

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

NS GSM 08.16 version 6.1.0 http://www.etsi.fr 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:
y

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 1 2-n

PDU type Information Elements NS PDU structure PDU type PDU type may be: NS-ALIVE NS-ALIVE-ACK NS-BLOCK NS-BLOCK-ACK NS-RESET NS-RESET-ACK NS-STATUS NS-UNBLOCK NS-UNBLOCK-ACK NS-UNITDATA

Information element value The following IEs may be present depending on the PDU type: Cause NS-VCI NS PDU BVCI NSEI

RLP GSM 04.22 version 7.0.1 http://www.etsi.fr 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: Version 1: Version 2: Single-link basic version Single-link extended version 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 16 bit 24 bit Information 200 bit 192 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 format of the 576-bit frame is: The header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames. Header Contains control information of one of the following 3 types: unnumbered protocol control FCS 24 bit 24 bit

information (U frames), supervisory information (S frames) and user information carrying supervisory information piggybacked (I+S frames). FCS This is the Frame Check Sequence field. The RLP entity will be in the Asynchronous Balanced Mode (ABM), which is the data link operation mode; or Asynchronous Disconnected Mode (ADM), which is the data link nonoperational 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 I+S C/R S1 S2 N(S) P/F 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 I+S X X X 0 1 1 1 1 1 P/F S1 S2 N(S) P/F S1 S2 Bits 1-24 C/R The Command Response Bit indicates whether the frame is a command or a response frame. It can have the following values: 1 0 command response N(R) N(R) X UP S UP N(R) N(R)

P/F The Poll/Final bit marks a special instance of command/response exchange X Don't care Unnumbered Frames (U)

The M1 M2 M3 M4 and M5 bits have the following values in the U frames according to the type of information carried: SABM UA DISC DM NULL UI XID TEST REMAP 11100 0011 00010 11000 11110 00000 11101 00111 10001

SABM11100 The Set Asynchronous balance mode is used either to initiate a link for numbered information transfer or to reset a link already established. UA00110 The Unnumbered Acknowledge is used as a response to acknowledge an SABMM or DISC command. DISC00010 The disconnect is used to disestablish a link previously established for information transfer. DM11000 The disconnected mode encoding is used as a response message. NULL11110 UI 00000 Unnumbered information signifies that the information field is to be interpreted as unnumbered information. XID11101 Exchange Identification signifies that the information field is to be interpreted as exchange identification, and is used to negotiate and renegotiate parameters of RLP and layer 2 relay functions. TEST 00111 The information field of this frame is test information. REMAP 0001 A remap exchange takes place in ABM following a change of channel coding. If an answer is not received within a specific time, then the mobile end enters ADM. S and I+S frames

N(S) The send sequence number contains the number of the I frame. N(R) The Receive sequence number is used in ABM to designate the next information frame to be sent and to confirm that all frames up to and including this bit and been received correctly. S S represents the L2 status bit. The S1, S2 bits can have the following significance in the S and I+S frames: RR REJ RNR SREJ 00 01 10 11

RR Receive Ready can be used either as a command or a response. It clears any previous busy condition in that area. REJ The Reject encoding is used to indicate that in numbered information transfer 1 or more out-ofsequence frames have been received. RNR The Receive Not Ready indicates that the entity is not ready to receive numbered information frames. SREJ Selective Reject is used to request retransmission of a single frame. UP This is used in version 2 to indicate that a service level upgrading will increase the throughput.

SMSCB ETSI TS 124 012. (You can download all the ETSI files from www.ETSI.org) 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 1

Link Protocol Spare Last Discriminator 0 Block 0 1 Link Protocol Discriminator The link protocol discriminator.

Sequence number

Last Block When the LB bit is set to "0", the next block may contain SMSCB information. Sequence Number The sequence number. Sequence numbers can be as follows: 0 1 2 3 4 15 Default First block Second block Third block Fourth block First schedule block NULL message Reserved

SNDCP GSM 04.65 version 6.1.0 http://www.etsi.fr 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:
y y y y

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 (LLPDUs) 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 X 7 C 6 T 5 M 4 3 2 1 Octets 1 2 3-n

NSAPI PCOMP Data

DCOMP

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

8 X

7 C

6 T

5 M

Octets 1 2 3 4 5 6-n

NSAPI PCOMP N-PDU number

DCOMP Segment offset E

N-PDU number (continued) N-PDU number (extended) Data SN-UNITDATA PDU structure

NSAPI Network service access point identifier. Values may be: 0 1 2-4 5-15 Escape mechanisms for future extensions Point-to-mutlipoint multicast (PTM-M) information Reserved for future use Dynamicallly allocated NSAPI value

M More bit. Values may be: 0 Last segment of N-PDU 1 Not the last segment of N-PDU, more segments to follow. T SN-PDU type specifies whether the PDU is SN-DATA (0) or SN-UNITDATA (1). C Compression indicator. A value of 0 indicates that compression fields, DCOMP and PCOMP, are not included. A value of 1 indicates that these fields are included. X Spare bit is set to 0. DCOMP Data compression coding, included if C-bit set. Values are as follows: 0 1-14 15 No compression. Points to the data compression identifier negotiated dynamically. Reserved for future extensions.

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

0 1-14 15

No compression. Points to the protocol control information compression identifier negotiated dynamically. Reserved for future extensions.

Segment offset Segment offset from the beginning of the N-PDU in units of 128 octets. N-PDU number 0-2047 when the extension bit is set to 0; 2048-524287 if the extension bit is set to 1. E Extension bit for N-PDU number. 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 highpriority 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 0000 Not specified

0001 1111

TIA/EIA-136 [22] Reserved for extension

All other values are reserved If 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 Header Remaining 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 00000 00011 1 1 1 0 14 1111 octets remaining in TOM protocol header octet remaining in TOM protocol header octets remaining in TOM protocol header Reserved 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 Header This 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 Capsule This 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:
y y y y y y y

"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 1 2 3

Synchronize Syn Frame Type

Synchronize The 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 Type The Frame Type: 2 5 6 8 14 16 20 22 26 27 28 31 Full Rate O&M Adaptive Multi-Rate Data Idle Speech Idle Speech Data 14.5 Data Enhanced Full Rate O&M Full Rate Extended Data

UMTS Technology Reference Page

An evolution from the GSM technology network standards

The following protocols appear in this family AAL2 see ATM AAL5 see ATM AMR Adaptive Multi-Rate Speech Codec BCC Broadcast Call Control. BMC Broadcast/Multicast Control Protocol BSSAP+ Base Station System Application Part Protocol CAMEL Customized Applications for Mobile network Enhanced Logic CC Circuit-switched Call Control Protocol FP Frame Protocol GCC Group Call Control GMM GPRS Mobility Management. GSM GPRS Session Management GTP GPRS Tunneling Protocol luUP Iu User Plane Protocol MAC Medium Access Control MAP Mobile Application Part

MM MTP-3B NbUP NBAP PCAP PDCP Q2630 RANAP RLC RLP RNSAP RRC SCCP SCTP SNDCP SM SMS SMS (TP) SS SSCOP SSCF-NNI

Mobility Management. Message Transfer Part Level 3B: Node B Application Part Packet Data Convergence Protocol (ALCAP) Access Link Control Application Part. Radio Access Network Application Protocol. Radio Link Control Protocol Radio Link Protocol Radio Network Subsystem Application Part Radio Resource Control Signalling Connection Control Part. Stream Control Transmission Protocol Sub-Network Dependant Convergance Protocol Session Management. Short Message Service Short Message Transfer Protocol Supplementary Services (Q.2110) (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:
y y y

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 FQI 3 2 Padding 1

Frame type

Frame Type One of the eight AMR codec modes, one of 4 different comfort noise frames, or an empty frame. The following frame types are available: Frame Type 0 1 2 3 4 5 6 7 8 9 10 11 12-14 15 Mode Mode Indication Request 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 Frame content (AMR mode, comfort noise, or other) AMR 4,75 kbit/s AMR 5,15 kbit/s AMR 5,90 kbit/s AMR 6,70 kbit/s AMR 7,40 kbit/s AMR 7,95 kbit/s AMR 10,2 kbit/s AMR 12,2 kbit/s AMR SID GSM-EFR SID TDMA-EFR SID PDC-EFR SID For future use No Data (No transmission/No reception)

FQI Indicates whether the data in the frame contains errors.

0 Bad or corrupted frame 1 Good frame

Enlarge

More Details

Interested in more details about testing this protocol?

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

This protocol is a variant of the GPRS BCC protocol. The Broadcast Call Control (BCC) protocol is used by the Voice Group Call Service (VGCS) on the radio interface. It is one of the protocols of the Connection Management (CM) sublayer (see GSM 04.07). Generally a number of mobile stations (MS) participate in a broadcast call. Consequently, there is in general more than one MS with a BCC entity engaged in the same broadcast call, and there is one BCC entity in the network engaged in that broadcast call. The MS ignores BCC messages sent in unacknowledged mode and which specify as destination a mobile identity which is not a mobile identity of that MS. Higher layers and the MM sub-layer decide when to accept parallel BCC transactions and when/whether to accept BCC transactions in parallel to other CM transactions. The broadcast call may be initiated by a mobile user or by a dispatcher. The originator of the BCC transaction chooses the Transaction Identifier (TI).

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

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 1 2 3-n

Transaction identifier

Protocol discriminator

Message type Information elements BCC header structure

Protocol discriminator The protocol discriminator specifies the message being transferred Transaction identifier Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows: 8 TI flag 7 Transaction identifier TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. 6 TI value 5

Message type The message type defines the function of each BCC message. The message type defines the function of each BCC message. The following message types exist: 0x110001 0x110010 0x110011 0x110100 0x110101 0x110110 0x111000 0x111001 0x111010 IMMEDIATE SETUP SETUP CONNECT TERMINATION TERMINATION REQUEST TERMINATION REJECT STATUS GET STATUS SET PARAMETER

Information elements Each information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included. Interested in more details about testing this protocol?

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

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 1 2-n

Message Type Information Element Coding of message types: 1 2 3 0, 4.. 255

CBS Message Schedule Message CBS41 Message Reserved for future use (PDUs with this coding will be discarded by this version of the protocol)

Interested in more details about testing this protocol?

BSSAP+ ETSI TS 129 018. (You can download all the ETSI files from www.ETSI.org) BSSAP+ for UMTS is the Base Station System Application Part protocol. The Gs interface connects the databases in the MSC/VLR and the SGSN. The procedures are used to co-ordinate the location information of MSs that are IMSI attached to both GPRS and non-GPRS services. The Gs interface is also used to convey some circuit switched related procedures via the SGSN.

The basis for the interworking between a VLR and an SGSN is the existence of an association between those entities per MS. An association consists of the SGSN storing the number of the VLR serving the MS for circuit switched services and the VLR storing the number of the SGSN serving the MS for packet switched services. The association is only applicable to MSs in classA 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 1 2-n

Message type Information elements BSSAP+ header structure

The message type uniquely identifies the message being sent. The following BSSAP+ message types exist: 0x1 0x2 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE 0xF 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x1A 0x1D 0x1F BSSAP+-PAGING-REQUEST BSSAP+-PAGING-REJECT BSSAP+-DOWNLINK-TUNNEL-REQUEST BSSAP+-UPLINK-TUNNEL-REQUEST BSSAP+-LOCATION-UPDATE-REQUEST BSSAP+-LOCATION-UPDATE-ACCEPT BSSAP+-LOCATION-UPDATE-REJECT BSSAP+-TMSI-REALLOCATION-COMPLETE BSSAP+-ALERT-REQUEST BSSAP+-ALERT-ACK BSSAP+-ALERT-REJECT BSSAP+-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-RESPONSE BSSAP+-MM-INFORMATION-REQUEST BSSAP+-MOBILE-STATUS BSSAP+-MS-UNREACHABLE

Each message type has specific information elements 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111 00010000 00010001 00010010 00010011 00010100 00010101 00010110 00010111 00011000 00011001 00011010 00011011 00011100 to 11111111 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.

Enlarge

More Details

Interested in more details about testing this protocol?

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

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

Note that CAMEL is not applicable to Emergency Setup (TS 12), i.e., in case an emergency call has been requested the gsmSSF is not invoked. The CAMEL mechanism addresses especially the need for information exchange between the VPLMN (Visited PLMN) or IPLMN (Interrogating PLMN) and the HPLMN for support of operator specific services. Subscribers who have subscribed to operator specific services and therefore need the functional support of the CAMEL feature are marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL support, the appropriate procedures, which provide the necessary information to the VPLMN or to the HPLMN, are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a gsmSCF, which is controlled by the HPLMN. The CAMEL protocol is an upper layer protocol which is carried over the TCAP protocol as the data portion. In an analogy to common protocols we can parallel the TCAP to the header and the CAMEL to the rest of the decode. The message types are in the format of asn1 messages. Like most asn1 applicable protocols, the CAMEL protocol has many message types that carry a high volume of data.

Enlarge

More Details

Interested in more details about testing this protocol?

CC ETSI TS 124 008.(You can download all the ETSI files from www.ETSI.org) The Circuit-switched Call Control protocol (CC) must be supported by every mobile station. If a

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

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 1 1-n

Message type Information element

Message Type The messge type, the following message types are available. 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 Alerting Call Proceeding Progress CC-ESTABLISHMENT Setup CC-ESTABLISHMENT CONFIRMED Connect Call Confirmed

0x09 0x0B 0x0E 0x0F 0x10 0x13 0x17 0x18 0x19 0x1A 0x1C

START CC RECALL Emergency Setup Connect Acknowledge User Information Modify Reject Modify Hold Hold Acknowledge Hold Reject Retrieve

Enlarge

More Details

Interested in more details about testing this protocol?

FP 3GPP TS 25.435, 25.427 (You can download all the ETSI files from www.ETSI.org) The Frame Protocol (FP) is one of the UTRAN Iur and Iub interfaces user plane protocols for Dedicated Transport Channel (DTC) data streams. DCH frame protocol provides the following services:
y y

Transport of TBS across Iub and Iur interface. Transport of outer loop power control information between the SRNC and the Node B.

y y y y y

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 PDU The header contains a CRC checksum, the frame type field and information related to the frame type. There are two types of DCH FP frames (indicated by the FT IE): - DCH data frame. - DCH control frame. The payload of the data frames contains radio interface user data, quality information for the transport blocks and for the radio interface physical channel during the transmission time interval (for UL only), and an optional CRC field. The payload of the control frames contains commands and measurement reports related to transport bearer and the radio interface physical channel but not directly related to specific radio interface user data. UL Data Frame Header The structure of the UL data frame header is as follows: 8 7 6 5 CFN Spare Spare TFI of first DCH TFI of last DCH 4 3 2 1 FT Octet 1 2 3 4 5

Header CRC

DL Data Frame Header The structure of the DL data frame header is as follows: 8 7 6 5 CFN Spare Spare TFI of first DCH TFI of last DCH 4 3 2 1 FT Octet 1 2 3 4 5

Header CRC

Header CRC Result of the CRC applied to the remaining part of the header, i.e. from bit 0 of the first byte, (the FT IE) to the bit 0 (included) of the last byte of the header) with the corresponding generator polynomial the length of the field is 7 bits. FT The FT describes if it is a control frame or a data frame. The length of the field is 1 bit. Its value can be: 0=data 1=control. CFN The CFN is an indicator as to which radio frame the first data was received on uplink or shall be transmitted on downlink. It can have a value of 0-255 and is 8 bits long. TFI of first/last DCH TFI is the local number of the transport format used for the transmission time interval. It can have a value of {0-31} and a length of 5 bits.

Enlarge

More Details

Interested in more details about testing this protocol?

GCC
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:
y y y y

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

All messages have the following header: 8 7 6 5 4 3 2 1 Octet 1 2 3-n

Transaction identifier

Protocol discriminator

Message type Information elements GCC header structure

Protocol discriminator The protocol discriminator specifies the message being transferred Transaction identifier Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows: 8 TI flag 7 Transaction identifier TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. 6 TI value 5

Message type The message type defines the function of each GCC message. The following message types exist: 0x110001 0x110010 0x110011 0x110100 0x110101 0x110110 0x111000 0x111001 0x111010 IMMEDIATE SETUP SETUP CONNECT TERMINATION TERMINATION REQUEST TERMINATION REJECT STATUS GET STATUS SET PARAMETER

Information elements Each information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included. Interested in more details about testing this protocol? GMM
3G.TS.24.008 v3.2.1 www.3gpp.org/ftp/specs

This protocol is a variant of the GPRS GMM protocol. UMTS and GPRS use the GSM MM (Mobility Management) protocol. Here it is known as the GPRS MM protocol (GMM). The main function of the MM sub-layer is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. A further function of the GMM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer. The format of the header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n

Protocol discriminator Message type

Skip indicator

Information elements GMM header structure Protocol discriminator 1000 identifies the GMM protocol.

Skip indicator The value of this field is 0000. Message type Uniquely defines the function and format of each GMM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GMM message types may be: 0 0 0 0 0 0 0 1 Attach request 0 0 0 0 0 0 1 0 Attach accept 0 0 0 0 0 0 1 1 Attach complete 0 0 0 0 0 1 0 0 Attach reject 0 0 0 0 0 1 0 1 Detach request 0 0 0 0 0 1 1 0 Detach accept 0 0 0 0 1 0 0 0 Routing area update request 0 0 0 0 1 0 0 1 Routing area update accept 0 0 0 0 1 0 1 0 Routing area update complete 0 0 0 0 1 0 1 1 Routing area update reject 0 0 0 1 0 0 0 0 P-TMSI reallocation command 0 0 0 1 0 0 0 1 P-TMSI reallocation complete 0 0 0 1 0 0 1 0 Authentication and ciphering req 0 0 0 1 0 0 1 1 Authentication and ciphering resp 0 0 0 1 0 1 0 0 Authentication and ciphering rej 0 0 0 1 0 1 0 1 Identity request 0 0 0 1 0 1 1 0 Identity response 0 0 1 0 0 0 0 0 GMM status 0 0 1 0 0 0 0 1 GMM information Information elements Various information elements.

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 1

Protocol discriminator

Skip indicator

Message type Information elements GSM header structure Protocol discriminator 1010 identifies the GSM protocol. Skip indicator The value of this field is 0000.

2 3-n

Message type Uniquely defines the function and format of each GSM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GSM message types may be: 0 1 x x x x x x Session management messages 0 1 0 0 0 0 0 1 Activate PDP context request 0 1 0 0 0 0 1 0 Activate PDP context accept 0 1 0 0 0 0 1 1 Activate PDP context reject 0 1 0 0 0 1 0 0 Request PDP context activation 0 1 0 0 0 1 0 1 Request PDP context activation rej. 0 1 0 0 0 1 1 0 Deactivate PDP context request 0 1 0 0 0 1 1 1 Deactivate PDP context accept 0 1 0 0 1 0 0 0 Modify PDP context request 0 1 0 0 1 0 0 1 Modify PDP context accept 0 1 0 1 0 0 0 0 Activate AA PDP context request 0 1 0 1 0 0 0 1 Activate AA PDP context accept 0 1 0 1 0 0 1 0 Activate AA PDP context reject 0 1 0 1 0 0 1 1 Deactivate AA PDP context request 0 1 0 1 0 1 0 0 Deactivate AA PDP context accept 0 1 0 1 0 1 0 1 SM Status Information elements Various information elements.

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 Version 6 5 4 3 2 1 LFN Octet 1 2 3-4 5-6 7-8 9-12 13-20

Reserved Message type Length Sequence Flow label Reserved TID

GTP header structure Version Set to 0 to indicate the first version of GTP. Reserved Reserved bits for future use, set to 1. LFN LLC frame number. Flag indicating whether the LLC frame number is included or not, set to 0 in signalling messages. Message type Indicates the type of GTP message. In signalling messages, it is set to the unique value that is used for each type of signalling message.

Length Indicates the length in octets of the GTP message (G-PDU). In signalling messages, this is the length, in octets, of the signalling message (including the GTP header). Sequence number A transaction identity for signalling messages and an increasing sequence number for tunneled T-PDUs. Flow label Identifies unambiguously a GTP flow. In signalling Path Management messages and Location Management messages, the flow label is not used and is set to 0. TID The Tunnel Identifier that points out MM and PDP contexts in the destination GSN. In signalling messages, it is set to 0 in all V Management messages, Location Management messages and Mobility Management messages. The format of the TID is as follows: 8 7 6 5 4 3 2 MCC digit 1 MCC digit 3 MNC digit 2 MSIN digit 2 MSIN digit 4 MSIN digit 6 MSIN digit 8 MSIN digit 10 TDI structure MCC, MNC, MSIN digits Parts of the IMSI (defined in GMS 04.08). NSAPI Network service access point identifier. LLC supports two modes of operation:
y y

1 Octet 1 2 3 4 5 6 7 8

MCC digit 2 MNC digit 1 MSIN digit 1 MSIN digit 3 MSIN digit 5 MSIN digit 7 MSIN digit 9 NSAPI

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 0 PDU Type 0 is defined to transfer user data over theIuUP in support mode for pre-defined SDU sizes. An error detection scheme is provided over theIuUP for the payload part. The following shows the Iu frame structure for PDU type 0 of theIuUP protocol at the SAP towards the transport layers (TNL-SAP). Bits 8 7 6 5 4 3 2 1 PDU Type (=0) FQC Header CRC Payload CRC Payload Fields Payload Fields Padding n-n+4 . Spare extension 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]). Frame Number RFCI Payload CRC Octets 1 2 3 4 5-n Frame Control Part Frame Check Sum Part Frame Payload part .

TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 0 Frame Header. PDU Type 1 PDU Type 1 is defined to transfer user data over theIuUP in support mode for pre-defined SDU sizes when no payload error detection scheme is necessary overIuUP (i.e. no payload CRC). The following shows the Iu frame structure for PDU type 1 of theIuUP protocol at the SAP towards the transport layers (TNL-SAP). Bits 8 7 6 5 4 3 2 1 PDU Type (=1) FQC Header CRC Payload CRC Payload Fields Payload Fields Padding n-n+4 . Spare extension IUup PDU Type 1Format TheIuUP PDU Type 1 is made of three parts: 1. IuUP Frame Control part (fixed size); 2. IuUP Frame Check Sum part (fixed size); 3. IuUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not consider the usage of spare extension field]). TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 1 Frame Header. PDU Type 14 PDU Type 14 is defined to perform control procedures over theIuUP in support mode for predefined 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 8 7 6 5 4 3 2 1 Number of Octets 4-n Frame Number RFCI Spare Octets 1 2 3 Frame Control Part Frame Check Sum Part Frame Payload part .

PDU Type (=14) IUup Mode version

Ack/Nack PDU Type (=0, i.e. 14 Frame procedure) Number Procedure Indicator Payload CRC

1 2 3

Frame Control Part

Header CRC Payload CRC

4 5-n

Frame Check Sum Part

Reserved for procedure data Spare extension

Frame Payload n-n+32 part

IUup PDU Type 14 Format for procedure sending TheIuUP PDU Type 14 is made of three parts: 1. IuUP Frame Control part (fixed size); 2. IuUP Frame Check Sum part (fixed size); 3. IuUP Frame Payload part (variable length, rounded up to octet). TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 14 Frame Header.

MAC 3GPP TS 25.321 V3.7.0 (2001-03) (You can download all the 3G files from www.3gpp.org ) The MAC (Medium Access Control) protocol architecture is constructed from MAC entities. The entities are assigned the following names: MAC-b and MAC-c/sh. MAC-b is the MAC entity that handles the BCH broadcast transport channel MAC-c/sh, is the MAC entity that handles the following transport channels:
y y y y y y

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 <---------------------------------- <-------------------------------------> --> TCTF UE-Id UE-Id type C/T MAC SDU

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

UE-Id Type The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC headers. UE-Id Type field 2 bits 00 01 10 11 UE-Id Type U-RNTI C-RNTI Reserved(PDUs with this coding will be discarded by this version of the protocol) Reserved(PDUs with this coding will be discarded by this version of the protocol)

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

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 U-RNTI C-RNTI Length of UE ID field 32 bits 16 bits

C/T field The C/T field provides identification of the logical channel instance when multiple logical channels are carried on the same transport channel. The C/T field is used also to provide identification of the logical channel type on dedicated transport channels and on FACH and RACH when used for user data transmission. The size of the C/T field is fixed to 4 bits for both common transport channels and dedicated transport channels. C/T field 0000 0001 ... 1110 1111 Designation Logical channel 1 Logical channel 2 ... Logical channel 15 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:
y y y y

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

y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y

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

y y

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) sublayer. The format of the header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n

Protocol discriminator Message type

Skip indicator

Information elements MM header structure Protocol discriminator 0101 identifies the MM protocol. Skip indicator The value of this field is 0000.

Message type Uniquely defines the function and format of each MM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. MM message types may be: 0x00 xxxx 0001 0010 0100 1000 xxxx 0001 0010 0100 1000 1001 1010 1011 xxxx 0001 0010 0011 0100 1000 1001 xxxx 0001 Registration messages: IMSI DETACH INDICATION LOCATION UPDATING ACCEPT LOCATION UPDATING REJECT LOCATION UPDATING REQUEST Security messages: AUTHENTICATION REJECT AUTHENTICATION REQUEST AUTHENTICATION RESPONSE IDENTITY REQUEST IDENTITY RESPONSE TMSI REALLOCATION COMMAND TMSI REALLOCATION COMPLETE Connection management messages: CM SERVICE ACCEPT CM SERVICE REJECT CM SERVICE ABORT CM SERVICE REQUEST CM REESTABLISHMENT REQUEST ABORT Miscellaneous messages: MM STATUS

0x01

0x10

0x11

Information elements Various information elements.

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

Signalling message handling; and Signalling network management.

The MTP-3B protocol structure appears as follows: 8 Priority Sub Service Indicator Priority The priority Service Indicator Used to perform message distribution and in some cases to perform message routing. The service indicator codes are used in international signalling networks for the following purposes. 0 1 3 5 Management Messages Testing/Maintenance Messages SCCP ISUP Spare 7 6 5 4 Spare Service Indicator 3 2 1 Octets 1 2

Sub Service Indicator The sub-service field contains the network indicator and two spare bits to discriminate between national and international messages. 0 1 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 0 PDU Type 0 is defined to transfer user data over the IuUP in support mode for pre-defined SDU sizes. An error detection scheme is provided over the NbUP for the payload part. The following shows the Iu frame structure for PDU type 0 of the NbUP protocol at the SAP towards the transport layers (TNL-SAP). Bits 8 7 6 5 4 3 2 1 PDU Type (=0) FQC Header CRC Payload CRC Payload Fields Payload Fields Padding n-n+4 . Spare extension NbUP PDU Type 0 Format The NbUP PDU Type 0 is made of three parts: 1. NbUP Frame Control part (fixed size); 2. NbUP Frame Check Sum part (fixed size); 3. NbUP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not consider the usage of spare extension field]). Frame Number RFCI Payload CRC Octets 1 2 3 4 5-n Frame Control Part Frame Check Sum Part Frame Payload part .

The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 0 Frame Header. PDU Type 1 PDU Type 1 is defined to transfer user data over the NbUP in support mode for pre-defined SDU sizes when no payload error detection scheme is necessary over NbUP (i.e. no payload CRC). The following shows the Iu frame structure for PDU type 1 of the NbUP protocol at the SAP towards the transport layers (TNL-SAP). Bits 8 7 6 5 4 3 2 1 PDU Type (=1) FQC Header CRC Payload CRC Payload Fields Payload Fields Padding n-n+4 . Spare extension NbUP PDU Type 1Format The NbUP PDU Type 1 is made of three parts: 1. NbUP Frame Control part (fixed size); 2. NbUP Frame Check Sum part (fixed size); 3. NbUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not consider the usage of spare extension field]). The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 1 Frame Header. PDU Type 14 PDU Type 14 is defined to perform control procedures over the NbUP in support mode for predefined 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 8 7 6 5 4 3 2 1 Number of Octets 4-n Frame Number RFCI Spare Octets 1 2 3 Frame Control Part Frame Check Sum Part Frame Payload part .

PDU Type (=14) NbUP Mode version

Ack/Nack PDU Type (=0, i.e. 14 Frame procedure) Number Procedure Indicator Payload CRC

1 2 3

Frame Control Part

Header CRC Payload CRC

4 5-n

Frame Check Sum Part

Reserved for procedure data Spare extension

Frame Payload n-n+32 part

NbUP PDU Type 14 Format for procedure sending The NbUP PDU Type 14 is made of three parts: 1. NbUP Frame Control part (fixed size); 2. NbUP Frame Check Sum part (fixed size); 3. NbUP Frame Payload part (variable length, rounded up to octet). The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 14 Frame Header.

NBAP ETSI TS 125 433 (You can download all the ETSI files from www.ETSI.org) The Node B Application Part, (NBAP), protocol is used over the IUR Interface. It includes common procedures and dedicated procedures. It covers procedures for paging distribution, broadcast system information, request / complete / release of dedicated resources and management of logical resources. It is an upper layer protocol which is part of the IUB Interface. Like most asn1 applicable protocols, the NBAP protocol has many message types that carry a high volume of data. The NBAP protocol header appears as follows. Each NBAP-PDU has a unuiqe header format, that contains a number of fields. The following is an example of the NBAP Initiating Message PDU: 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. PDU The type of PDU sent. Procedure ID Procedure ID is to be used if Criticality Diagnostics is part of the Error Indication procedure, and not within the response message of the same procedure that caused the error. Procedure code These 2 fields combine the message type and uniquely identify the message being sent. Criticality The Procedure Criticality is used for reporting the Criticality of the Triggering message (Procedure) Message discriminator This field is used to discriminate between Dedicated NBAP and Common NBAP messages. Transaction ID The transaction ID is used to associate all the messages belonging to the same procedure.

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

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

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

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:

y y y

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:

y y y y y y y

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

y y

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 Data PDCP Data PDU 8 7 6 5 Data PDCP SeqNum PDU 8 7 6 5 4 3 PID 2 1 Octets 1 2 4-n 4 3 PID 2 1 Octets 1 2-n 4 3 2 1 Octets 0-n

PDU type

PDU type Sequence number Data

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

PID Indicates the header compression identifier used. Header compression is different for each type of protocol. Sequence Number The PDCP PDU sequence number Data PDCP SDUs that have been header compressed are mapped to this field if header compression is negotiated. Otherwise, PDCP SDUs are mapped to this field

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

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

Destination signalling association identifier

10 11

Unblock Confirm Unblock Request

Message Compatibility The instructions specific for the handling of the complete message. The header is followed by a parameter, that appears as follows: . Header 8 7 6 5 4 3 2 1 Octets 1 2 3 4-n

Parameter identfier Parameter compatibility Parameter length

Payload Fields

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

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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 RAB-Assignment Iu-Release RelocationPreparation RelocationResourceAllocation RelocationCancel SRNS-ContextTransfer SecurityModeControl DataVolumeReport CN-InformationBroadcast Reset RAB-ReleaseRequest Iu-ReleaseRequest RelocationDetect RelocationComplete3 Paging CommonID CN-InvokeTrace LocationReportingControl LocationReport InitialUE-Message DirectTransfer OverloadControl ErrorIndication SRNS-DataForward ForwardSRNS-Context PrivateMessage5 CN-DeactivateTrace ResetResource 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.
y y y y y y y y y y y y

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 Data 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 3 2 1 Octets 1

Sequence Number Length Indicator . . . . Length Indicator Data

E E

. .

. (Optional)(1)

E . .

(Optional)

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 D/C 7 6 5 4 3 P 2 HE E 1 Octets 1 2 3 (Optional)(1) .

Sequence Number Length Indicator . . . Length Indicator Data E

Sequence Number

(Optional)

PAD or a piggybacked STATUS PDU Control PDUs

(Optional)

STATUS PDU and Piggybacked STATUS PDU The STATUS PDU and the Piggybacked STATUS PDU are used in acknowledged mode. The

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

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. 7 6 PDU type SUFI1 ... SUFIK PAD 5 4 3 2 1 Octets 1 2 . . N

8 D/C

SUFI1

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

SUFI1

RESET PDU The RESET PDU is used in acknowledged mode to reset all protocol states, protocol variables and protocol timers of the peer RLC entity in order to synchronise the two peer entities. RESET ACK PDU The RESET ACK PDU is an acknowledgement to the RESET PDU. The RESET PDU and RESET ACK PDU have a one-bit sequence number field (RSN). With the aid of this field the Receiver can define whether the received RESET PDU is transmitted by the Sender for the first time or whether it is a retransmission of a previous RESET PDU.

8 D/C

6 PDU type

5 HFNI HFNI

3 RSN

1 R1

Octets 1 2

HFNI PAD N 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 Field The length of this field is one bit. The D/C field indicates the type of an acknowledged mode PDU. It can be either a data or a control PDU. 0 1 Control PDU Acknowledged mode data PDU

PDU Type The length of this field is 3 bits. The PDU type field indicates the Control PDU type. The following types are available. 000 001 010 011-111 STATUS RESET RESET ACK Reserved

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. 0 1 Status report not requested Request a status report

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

0 1

data Length 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. 00 01 10-11 The succeeding octet contains data The succeeding octet contains a length indicator and E bit Reserved (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. SUFI The SUFI field that are used is dependant on the implementation, but when a STATUS PDU includes information about which PDUs have been received and which are detected as missing, information is not included PDUs that have not yet reached the receiver. The SUFI (Super-Field) includes three sub-fields: type information (type of super-field, e.g. list, bitmap, acknowledgement, etc), length information (providing the length of a variable length field within the following value field) and a value

RLP ETSI TS 124 022. (You can download all the ETSI files from www.ETSI.org) Three versions of the RLP (Radio Link Protocol) are defined:
y y y

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

The format of the 240-bit frame is: Header 16 bit 24 bit Information 200 bit 192 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 format of the 576-bit frame is: The header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames. Header Contains control information of one of the following 3 types: unnumbered protocol control information (U frames), supervisory information (S frames) and user information carrying supervisory information piggybacked (I+S frames). FCS This is the Frame Check Sequence field. The RLP entity will be in the Asynchronous Balanced Mode (ABM), which is the data link operation mode; or Asynchronous Disconnected Mode (ADM), which is the data link nonoperational 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 I+S C/R S1 S2 N(S) P/F 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 N(R) N(R) FCS 24 bit 24 bit

I+S

N(S)

P/F S1 S2 Bits 1-24

N(R)

S UP

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

P/F The Poll/Final bit marks a special instance of command/response exchange X Don't care Unnumbered Frames (U) The M1 M2 M3 M4 and M5 bits have the following values in the U frames according to the type of information carried: SABM UA DISC DM NULL UI XID TEST REMAP 11100 0011 00010 11000 11110 00000 11101 00111 10001

SABM11100 The Set Asynchronous balance mode is used either to initiate a link for numbered information transfer or to reset a link already established. UA00110 The Unnumbered Acknowledge is used as a response to acknowledge an SABMM or DISC command. DISC00010 The disconnect is used to disestablish a link previously established for information transfer. DM11000 The disconnected mode encoding is used as a response message. NULL11110

UI 00000 Unnumbered information signifies that the information field is to be interpreted as unnumbered information. XID11101 Exchange Identification signifies that the information field is to be interpreted as exchange identification, and is used to negotiate and renegotiate parameters of RLP and layer 2 relay functions. TEST 00111 The information field of this frame is test information. REMAP 0001 A remap exchange takes place in ABM following a change of channel coding. If an answer is not received within a specific time, then the mobile end enters ADM. S and I+S frames N(S) The send sequence number contains the number of the I frame. N(R) The Receive sequence number is used in ABM to designate the next information frame to be sent and to confirm that all frames up to and including this bit and been received correctly. S S represents the L2 status bit. The S1, S2 bits can have the following significance in the S and I+S frames: RR REJ RNR SREJ 00 01 10 11

RR Receive Ready can be used either as a command or a response. It clears any previous busy condition in that area. REJ The Reject encoding is used to indicate that in numbered information transfer 1 or more out-ofsequence frames have been received. RNR The Receive Not Ready indicates that the entity is not ready to receive numbered information frames.

SREJ Selective Reject is used to request retransmission of a single frame. UP This is used in version 2 to indicate that a service level upgrading will increase the throughput.

RNSAP ETSI TS 125 423. (You can download all the ETSI files from www.ETSI.org) The Iur interface RNSAP (Radio Network Subsystem Application Part) procedures are divided into four modules as follows: 1. 2. 3. 4. RNSAP Basic Mobility Procedures RNSAP DCH Procedures RNSAP Common Transport Channel Procedures 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 1 2 or 2,3

Message type Transaction ID Message Type All messages are text messages in asn.1 format.

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

RRC 3GPP TS 25.331 http://webapp.etsi.org/key/queryform.asp The RRC is an upper layer protocol which is part of the IUB Interface. The RRC has the following interfaces:
y y y y

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

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

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:

y y y

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

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 orderof-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 1 2 3 4 5 Verification Tag 6 7 8 9 Adler 32 Checksum 10 11 12 Source Port Number This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs. Destination Port Number This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Source Port Number Destination Port Number

Verification Tag The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization. For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's. Adler 32 Checksum This field contains an Adler-32 checksum on this SCTP datagram. Chunk Field Descriptions The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field. 8 7 6 5 4 3 2 1 Octets 1 2 3 4 5-n

Chunk ID Chunk Flags Chunk Length Chunk Value (variable)

Chunk ID The type of information contained in the chunk value field. The values of the chunk ID are defined as follows: ID Value Chunk Type 00000000 Payload Data (DATA) 00000001 Initiation (INIT) 00000010 Initiation Acknowledgment (INIT ACK) 00000011 Selective Acknowledgment (SACK) 00000100 Heartbeat Request (HEARTBEAT) 00000101 Heartbeat Acknowledgment (HEARTBEAT ACK) 00000110 Abort (ABORT) 00000111 Shutdown (SHUTDOWN) 00001000 Shutdown Acknowledgment (SHUTDOWN ACK) 00001001 Operation Error (ERROR) 00001010 State Cookie (COOKIE) 00001011 Cookie Acknowledgment (COOKIE ACK) 00001100 Reserved for Explicit Congestion Notification Echo (ECNE)

00001101

Reserved for Congestion Window Reduced (CWR)

00001110 to 11111101 - reserved by IETF 11111110 Vendor-specific Chunk Extensions 11111111 IETF-defined Chunk Extensions Chunk Flags The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified. Chunk Length The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields. Chunk Value This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID. Chunk Types Initiation (INIT) This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk. Fixed Parameters Initiate Tag Receiver Window Credit Number of Outbound Streams Number of Inbound Streams Initial TSN Variable Parameters IPv4 Address/Port IPv6 Address/Port Cookie Preservative Reserved For ECN Capable Host Name Address Supported Address Types Status Mandatory Mandatory Mandatory Mandatory Mandatory Status 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. SHUTDOWN An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer. Shutdown Acknowledgement (SHUTDOWN ACK) This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters. Operation Error (ERROR) This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes. State Cookie (COOKIE) This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram. Cookie Acknowledgement (COOKIE ACK) This chunk is used only during the initialization of an association. It is used to acknowledge the

receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram. Payload Data (DATA) This contains the user data. Vendor Specific Chunk Extensions This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

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

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 X 7 C 6 T 5 M Data SN-DATA PDU structure NSAPI Network service access point identifier. Values may be: 4 3 2 1 Octet 1 2 3-n

NSAPI PCOMP

DCOMP

0 1 2-4 5-15

Escape mechanisms for future extensions. Point-to-multipoint multicast (PTM-M) information. Reserved for future use. Dynamically allocated NSAPI value.

M More bit. Values may be: 0Last segment of N-PDU. 1Not the last segment of N-PDU, more segments to follow. T SN-PDU type specifies whether the PDU is SN-DATA (0) or SN-UNITDATA (1). C Compression indicator. A value of 0 indicates that compression fields, DCOMP and PCOMP, are not included. A value of 1 indicates that these fields are included. X Spare bit is set to 0. DCOMP Data compression coding, included if C-bit set. Values are as follows: 0 No compression. 1-14 Points to the data compression identifier negotiated dynamically. 15 Reserved for future extensions. PCOMP Protocol control information compression coding, included if C-bit set. Values are as follows: 0 No compression. Points to the protocol control information compression identifier 1-14 negotiated dynamically. 15 Reserved for future extensions. Segment offset Segment offset from the beginning of the N-PDU in units of 128 octets. N-PDU number 0-2047 when the extension bit is set to 0. 2048-524287 if the extension bit is set to 1. E Extension bit for N-PDU number. 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 1 2 3-n

Protocol discriminator Message type

Skip indicator

Information elements SM header structure Protocol discriminator 1010 identifies the SM protocol. Skip indicator The value of this field is 0000.

Message type Uniquely defines the function and format of each SM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. SM message types may be: 01xxxxxx 01000001 01000010 01000011 01000100 01000101 01000110 01000111 01001000 01001001 01010000 01010001 01010010 01010011 01010100 Session management messages Activate PDP context request Activate PDP context accept Activate PDP context reject Request PDP context activation Request PDP context activation rej. Deactivate PDP context request Deactivate PDP context accept Modify PDP context request Modify PDP context accept Activate AA PDP context request Activate AA PDP context accept Activate AA PDP context reject Deactivate AA PDP context request Deactivate AA PDP context accept

01010101

SM Status

Information elements Various information elements.

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

The Short Message Service (SMS) is used to transfer text messages over mobile networks between a GSM PLMN Mobile Station and a Short Message Entity via a Service Center. The terms MO (Mobile Originating) and MT (Mobile Terminating) are used to indicate the direction in which the short message is sent. SMS messages can be encapsulated in control or relay messages. SMS Control Message The format of the control protocol message header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n

Protocol discriminator

Transaction identifier

Message type Information elements SMS control protocol header structureheader structure Protocol discriminator 1001 identifies the SMS protocol.

Transaction identifier The transaction identifier (TI) distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows: 4 TI flag 3 2 TI value Transaction identifier TI flag Identifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value. TI value TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for 1 ----

the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface. Message type The message type, together with the protocol discriminator, identifies the function of the message being sent. Messages may be of the following: 0000 0001 0000 0100 0001 0000 CP-DATA CP-ACK CP-ERROR

Information elements Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator. SMS Relay Protocol Message The format of the relay protocol message header is shown in the following illustration: 8 0 7 0 6 0 5 0 4 0 3 2 1 Octet 1 2 3-n

Message reference Information elements SMS relay protocol header structure MTI Message type indicator. Values are as follows: Bit Value (3 2 1) Direction RP-Message 000 000 001 001 010 010 011 011 100 100 101 101 110 110 111 ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n n -> ms ms -> n RP-DATA Reserved Reserved RP-DATA RP-ACK Reserved Reserved RP-ACK RP-ERROR Reserved Reserved RP-ERROR RP-SMMA Reserved Reserved

Message reference Used to link an RP-ACK message or RP-ERROR message to the associated RP-Data or RPSMMA message transfer attempt. Information elements Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator.

SMS TP ETSI TS 123 040. (You can download all the ETSI files from www.ETSI.org) The SMS TP (Short Message Transfer Layer Protocol) is comprised of two basic services:
y y

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 1 2-n

Message type Information Elements

Message Type The type of message, the following message types are available: SC To MS 0 1 2 3 SMS-DELIVER SMS-SUBMIT-REPORT SMS-STATUS-REPORT Reserved

MS To SC 0 SMS-DELIVER-REPORT 1 SMS-SUBMIT

2 SMS-COMMAND 3 Reserved

SS 3GPP TS 24.080 http://webapp.etsi.org/key/queryform.asp This Supplementary Services protocol defines the structure of the messages of the layer 3 protocol defined in 3GPP TS 24.080. These messages are standard L3 messages. SS is both for GPRS and for UMTS. The structure of the header is as follows: 8 7 6 5 4 3 2 1 Octet 1 2 3-n

Protocol Discriminator Message type

Transaction ID

Information elements Protocol Discriminator Transaction Identifier Message Type

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

The following message types are available 42 58 59 Release Complete Facility Register