UMTS Family

UMTS Family
AMR 3GPP TS 26.101. (You can download all the ETSI files from www.ETSI.org) The Adaptive Multi-Rate (AMR) speech codec is a mandatory codec for for third generation systems, and will be widely used in cellular systems. This codec is a multi-mode codec with 8 bit narrow band speech modes with a bit rate between 4.75 and 12.2 kbps. The sampling is 8000 HZ and processing is done on 20 ms frames. 3 AMR modes are already adopted standards of their own:

6.7 kbps mode as PDC-EFR 7.4 kbps mode as IS-641 codec in TDMA 12.2 kbps mode as GSM-EFR
Described below is a generic frame format for the Adaptive Multi-Rate (AMR) speech codec. This format is used as a common reference point when interfacing speech frames between different elements of the 3G system and between different systems. Appropriate mappings to and from this generic frame format are used within and between each system element. The AMR header appears as follows: 8 7 6 5 4 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 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
9 10 11 12-14 15
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:

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 6 TI value 5
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
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 BMCSAP that are to be broadcast into a specified cell. The BMC protocol does the following:

Storage of Cell Broadcast Messages. Traffic volume monitoring and radio resource request for CBS. Scheduling of BMC messages. Transmission of BMC messages to UE. Delivery of Cell Broadcast messages to upper layer (NAS).
The BM-SAP provides a broadcast/multicast transmission service in the user plane on the radio interface for common user data in unacknowledged mode. The BMC sublayer interacts with other entities. The interactions with the upper layer/U-plane and the RRC layer are specified in terms of signaling messages where the signaling messages represent the logical exchange of information and control between the BMC sublayer and higher layers. They do not specify or constrain implementations. The (adjacent) layers connect to each other through Service Access Points (SAPs). The messages are signaling messages. There can be 3 types of signaling messages, Request, Indication and Confirm. The messages structure is of 2 types: Between BMC and upper layer (U-plane): BMC - Generic name - Type: Parameters. Between BMC and the RRC entity: CBMC - Generic name - Type: Parameters. The following message types are available: BMC Header: 8 7 6 5 4 3 2 1 Octet 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)
BSSAP+ ETSI TS 129 018. (You can download all the ETSI files from www.ETSI.org) BSSAP+ for UMTS is the Base Station System Application Part protocol. The Gs interface connects the databases in the MSC/VLR and the SGSN. The procedures are used to co-ordinate the location information of MSs that are IMSI attached to both GPRS and non-GPRS services. The Gs interface is also used to convey some circuit switched related procedures via the SGSN. The basis for the interworking between a VLR and an SGSN is the existence of an association between those entities per MS. An association consists of the SGSN storing the number of the VLR serving the MS for circuit switched services and the VLR storing the number of the SGSN serving the MS for packet switched services. The association is only applicable to MSs in class-A mode of operation and MSs in class-B mode of operation. All the messages described here use the SCCP class 0 connectionless service. When the return option in SCCP is used and the sender receives an N_NOTICE indication from SCCP, the sending entity reports to the Operation and Maintenance system. The behaviour of the VLR and the SGSN entities related to the Gs interface are defined by the state of the association for an MS. Individual states per association, i.e. per MS in class-A mode of operation and MS in class-B mode of operation, are held at both the VLR and the SGSN. The BSSAP+ header appears as follows: 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
CAMEL ETSI TS 101 044. (You can download all the ETSI files from www.ETSI.org) The Customized Applications for Mobile network Enhanced Logic (CAMEL) provides the mechanisms to support services of operators, which are not covered by standardized GSM services even when roaming outside the HPLMN (Home Public Land Mobile Network). The CAMEL feature is a network feature and not a supplementary service. It is a tool to help the network operator provide the subscribers with the operator specific services even when roaming outside the HPLMN. In this specification, the GSM Service Control Function (gsmSCF) is treated as being part of the HPLMN. The regulatory environment in some countries may require the possibility that the gsmSCF and the HPLMN are controlled by different operators, and the gsmSCF and the HPLMN are therefore distinct entities. In the first phase the CAMEL features support:

Mobile originated and forwarded calls Mobile terminating calls Any time interrogation Suppression of announcements
Note that CAMEL is not applicable to Emergency Setup (TS 12), i.e., in case an emergency call has been requested the gsmSSF is not invoked. The CAMEL mechanism addresses especially the need for information exchange between the VPLMN (Visited PLMN) or IPLMN (Interrogating PLMN) and the HPLMN for support of operator specific services. Subscribers who have subscribed to operator specific services and therefore need the functional support of the CAMEL feature are marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL support, the appropriate procedures, which provide the necessary information to the VPLMN or to the HPLMN, are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a gsmSCF, which is controlled by the HPLMN. The CAMEL protocol is an upper layer protocol which is carried over the TCAP protocol as the data portion. In an analogy to common protocols we can parallel the TCAP to the header and the CAMEL to the rest of the decode. The message types are in the format of asn1 messages. Like most asn1 applicable protocols, the CAMEL protocol has many message types that carry a high volume of data.
Enlarge
More Details
CC
ETSI TS 124 008.(You can download all the ETSI files from www.ETSI.org) The Circuit-switched Call Control protocol (CC) must be supported by every mobile station. If a mobile station does not support any bearer capability at all then it responds to a SETUP message with a RELEASE COMPLETE message. In UMTS only, integrity protected signalling is mandatory. In addition, all protocols use integrity protected signalling. Integrity protection (activated by the network) of all CC signalling messages is the responsibility of lower layers and is performed using the security mode control procedure (3GPP TS 25.331 [23c]). In CC, more than one CC entity is defined. Each CC entity is independent from the other and communicatse with the correspondent peer entity using its own MM connection. Different CC entities use different transaction identifiers. With a few exceptions protocol here relates to the call control protocol only with regard to two peer entities. The call control entities are described as communicating finite state machines which exchange messages across the Radio interfaces and communicate internally with other protocol (sub) layers. This description is only normative as far as the consequential externally observable behaviour is concerned. Certain sequences of actions of the two peer entities compose "elementary procedures" which are used as a basis for the description here. These elementary procedures may be grouped into the following classes:

Call establishment procedures Call clearing procedures Call information phase procedures Miscellaneous procedures.
The terms "mobile originating" or "mobile originated" (MO) are used to describe a call initiated by the mobile station. The terms "mobile terminating" or "mobile terminated" (MT) are used to describe a call initiated by the network. The structure of the CC protocol is as follows: 8 7 6 5 4 3 2 1 Octet 1 1-n
Message type Information element
Message Type The messge type, the following message types are available. 0x01 0x02 Alerting Call Proceeding
0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0B 0x0E 0x0F 0x10 0x13 0x17 0x18 0x19 0x1A 0x1C
Progress CC-ESTABLISHMENT Setup CC-ESTABLISHMENT CONFIRMED Connect Call Confirmed START CC RECALL Emergency Setup Connect Acknowledge User Information Modify Reject Modify Hold Hold Acknowledge Hold Reject Retrieve
Enlarge
More Details
FP 3GPP TS 25.435, 25.427 (You can download all the ETSI files from www.ETSI.org)
The Frame Protocol (FP) is one of the UTRAN Iur and Iub interfaces user plane protocols for Dedicated Transport Channel (DTC) data streams. DCH frame protocol provides the following services:

Transport of TBS across Iub and Iur interface. Transport of outer loop power control information between the SRNC and the Node B. Support of transport channel synchronization mechanism. Support of node synchronization mechanism. Transfer of DSCH TFCI from SRNC to Node B. 3.84 Mcps TDD - Transfer of Rx timing deviation from the Node B to the SRNC. Transfer of radio interface parameters from the SRNC to the Node B.
The transport layer must deliver Frame Protocol PDUs. When there is data to be transmitted, DCH data frames are transferred every transmission time interval from the SRNC to the Node B for downlink transfer, and from Node B to the SRNC for uplink transfer. An optional error detection mechanism may be used to protect the data transfer if needed. At the transport channel setup it shall be specified if the error detection on the user data is used. Data Transfer procedure is used to transfer data received from Uu interface from Node B to CRNC and vice versa.
The general structure of a DCH FP frame consists of a header and a payload. Header Payload
General structure of a Frame Protocol 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
GCC
3G TS 24.068 version 3.1.0 www.3gpp.org/ftp/specs
This protocol is a variant of the GPRS GCC protocol. The Group Call Control (GCC) protocol is used by the Voice Group Call Service (VGCS) on the radio interface within the 3GPP system. It is one of the protocols of the Connection Management (CM) sublayer (see GSM 04.07). Generally a number of mobile stations (MS) participate in a group call. Consequently, there is in general more than one MS with a GCC entity engaged in the same group call, and there is one GCC entity in the network engaged in that group call. The MS ignores GCC messages sent in unacknowledged mode and which specify as destination a mobile identity which is not a mobile identity of that MS. Higher layers and the MM sub-layer decide when to accept parallel GCC transactions and when/whether to accept GCC transactions in parallel to other CM transactions. The group call may be initiated by a mobile user or by a dispatcher. In certain situations, a MS is assumed to be the originator of a group call without being
the originator. The originator of the GCC transaction chooses the Transaction Identifier (TI). The call control entities are described as communicating finite state machines which exchange messages across the radio interface and communicate internally with other protocol (sub) layers. In particular, the GCC protocol uses the MM and RR sublayer specified in GSM 04.08. The network should apply supervisory functions to verify that the GCC procedures are progressing and if not, take appropriate means to resolve the problems. The elementary procedures in the GCC include:

Group call establishment procedures Group call termination procedures Call information phase procedures Various miscellaneous procedures.
All messages have the following header: 8 7 6 5 4 3 2 1 Octet 1 2 3-n
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 6 TI value 5
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 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
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.
3-n
Message type Uniquely defines the function and format of each GMM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GMM message types may be: 0 0 0 0 0 0 0 1 Attach request 0 0 0 0 0 0 1 0 Attach accept 0 0 0 0 0 0 1 1 Attach complete 0 0 0 0 0 1 0 0 Attach reject 0 0 0 0 0 1 0 1 Detach request 0 0 0 0 0 1 1 0 Detach accept 0 0 0 0 1 0 0 0 Routing area update request 0 0 0 0 1 0 0 1 Routing area update accept 0 0 0 0 1 0 1 0 Routing area update complete 0 0 0 0 1 0 1 1 Routing area update reject 0 0 0 1 0 0 0 0 P-TMSI reallocation command 0 0 0 1 0 0 0 1 P-TMSI reallocation complete 0 0 0 1 0 0 1 0 Authentication and ciphering req 0 0 0 1 0 0 1 1 Authentication and ciphering resp 0 0 0 1 0 1 0 0 Authentication and ciphering rej 0 0 0 1 0 1 0 1 Identity request 0 0 0 1 0 1 1 0 Identity response 0 0 1 0 0 0 0 0 GMM status 0 0 1 0 0 0 0 1 GMM information Information elements Various information elements. Interested in more details about testing this protocol?
GSM
3GPP TS 24.008 http://www.etsi.org
This protocol is a variant of the GPRS GSM protocol. The main function of the GPRS session management (SM) is to support PDP context handling of the user terminal. The SM comprises procedures for: identified PDP context activation, deactivation and modification, and anonymous PDP context activation and deactivation. The format of the header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n
Skip indicator
Information elements GSM header 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: 0 1 x x x x x x Session management messages 0 1 0 0 0 0 0 1 Activate PDP context request 0 1 0 0 0 0 1 0 Activate PDP context accept 0 1 0 0 0 0 1 1 Activate PDP context reject 0 1 0 0 0 1 0 0 Request PDP context activation 0 1 0 0 0 1 0 1 Request PDP context activation rej. 0 1 0 0 0 1 1 0 Deactivate PDP context request 0 1 0 0 0 1 1 1 Deactivate PDP context accept 0 1 0 0 1 0 0 0 Modify PDP context request 0 1 0 0 1 0 0 1 Modify PDP context accept 0 1 0 1 0 0 0 0 Activate AA PDP context request 0 1 0 1 0 0 0 1 Activate AA PDP context accept 0 1 0 1 0 0 1 0 Activate AA PDP context reject 0 1 0 1 0 0 1 1 Deactivate AA PDP context request 0 1 0 1 0 1 0 0 Deactivate AA PDP context accept 0 1 0 1 0 1 0 1 SM Status Information elements
Various information elements. Interested in more details about testing this protocol?
GTP
3GPP TS 29.060 http://www.etsi.fr
This protocol is a variant of the GPRS GTP protocol. GPRS Tunnelling Protocol (GTP) is the protocol that is used between GSN nodes in the UMTS backbone network. GTP is defined both for the Gn interface, i.e. the interface between GSNs within a PLMN, and the Gp interface between GSNs in different PLMNs. GTP is encapsulated within UDP. GTP allows multiprotocol packets to be tunnelled through the UMTS backbone between GPRS Support Nodes (GSNs). In the signalling plane, GTP specifies a tunnel control and management protocol which allows the SGSN to provide UMTS network access for an MS. Signalling is used to create, modify and delete tunnels. In the transmission plane, GTP uses a tunnelling mechanism to provide a service for carrying user data packets. The choice of path is dependent on whether the user data that is going to be tunnelled requires a reliable link or not. The GTP protocol is implemented only by SGSNs and GGSNs. No other systems need to be aware of GTP. UMTS MSs are connected to a SGSN without being aware of GTP. It is assumed that there will be a many-to-many relationship between SGSNs and GGSNs. An SGSN may provide service to many GGSNs. A single GGSN may associate with many SGSNs to deliver traffic to a large number of geographically diverse mobile stations. The GTP header is a fixed format 16 octet header used for all GTP messages. 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 1 Octet 1 2 3 4 5 6
MCC digit 2 MNC digit 1 MSIN digit 1 MSIN digit 3 MSIN digit 5 MSIN digit 7
MSIN digit 9 NSAPI
MSIN digit 8 MSIN digit 10 TDI structure
7 8
MCC, MNC, MSIN digits Parts of the IMSI (defined in GMS 04.08). NSAPI Network service access point identifier. LLC supports two modes of operation:

Unacknowledged peer-to-peer operation. Acknowledged peer-to-peer operation.
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 Octets
1 1 2 Frame Control Part Frame Check Sum Part Frame Payload part .
PDU Type (=0) FQC Header CRC
Frame Number RFCI Payload CRC
3 4 5-n n-n+4 .
Payload CRC Payload Fields Payload Fields Padding 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]). 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 4-n Frame Number RFCI Spare Octets 1 2 3 Frame Control Part Frame Check Sum Part Frame Payload
Spare extension IUup PDU Type 1Format TheIuUP PDU Type 1 is made of three parts:
n-n+4 part . .
1. IuUP Frame Control part (fixed size); 2. IuUP Frame Check Sum part (fixed size); 3. IuUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not consider the usage of spare extension field]). TheIuUP Frame Control Part and theIuUP Frame Check Sum constitute theIuUP PDU Type 1 Frame Header. PDU Type 14 PDU Type 14 is defined to perform control procedures over theIuUP in support mode for pre-defined SDU sizes. The control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to the control procedure. The figure below shows the Iu frame structure for PDU Type 14 of theIuUP protocol at the SAP towards the transport layers (TNL-SAP). Bits 8 7 6 5 4 3 2 1 Number of Octets 1 2 3 Frame Control Part
Ack/Nack PDU Type PDU Type (=14) (=0, i.e. 14 Frame procedure) Number IUup Mode version Procedure Indicator Payload CRC
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.
Enlarge
More Details
MAC 3GPP TS 25.321 V3.7.0 (2001-03) (You can download all the 3G files from www.3gpp.org ) The MAC (Medium Access Control) protocol architecture is constructed from MAC entities. The entities are assigned the following names: MAC-b and MAC-c/sh. MAC-b is the MAC entity that handles the BCH broadcast transport channel MAC-c/sh, is the MAC entity that handles the following transport channels:

Paging channel (PCH) Forward access channel (FACH) Random access channel (RACH) Common packet channel (UL CPCH). The CPCH exists only in FDD mode. Downlink shared channel (DSCH)
Uplink shared channel (USCH). The USCH exists only in TDD mode.
MAC-d is the MAC entity that handles the Dedicated transport channels (DCH) The exact functions completed by the entities are different in the UE from those completed in the UTRAN. The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for different kinds of data transfer services as offered by MAC. Each logical channel type is defined by the type of information being transferred. Each MAC PDU consits of an optional MAC header and a MAC Service Data Unit (MAC SDU), Both the MAC header and the MAC SDU are of variable size. The content and the size of the MAC header depends on the type of the logical channel, and in some cases none of the parameters in the MAC header are needed. The size of the MAC-SDU depends on the size of the RLC-PDU, which is defined during the setup procedure. The structure of the MAC protocol header is as follows: 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 UE-Id Type bits 00 U-RNTI
01 10 11
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:
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)
Enlarge
More Details
MAP EIA/TIA IS41.5 1997 IS41-D The MAP (Mobile Application Part) protocol typically runs on top of the Signaling System 7 (SS7) protocol. MAP is a non call-associated signaling protocol. It provides the support for interactive mobile applications ( cellular, paging, voice messaging, etc.) in a distributed environment. MAP defines the end-to-end protocol between applications which may be located in an SS7 network, and/or other networks supporting the MAP protocol. SS7 is a common channel signaling protocol that enables resources in broadband and narrowband networks to exchange messages related to call setup, supervision and teardown, information needed for distributed application processing and network management. The MAP protocol provides mechanisms to communicate between a Mobile Switching Center (MSC) and Visitor Location Register (VLR) ("B" interface), MSC and Home Location Register (HLR) ("C" interface), Visitor Location Register (VLR) and HLR ("D" Interface), VLR and VLR ("G" Interface), MSC and MSC ("E" interface), MSC and Short Message Service gateway (SMS) ("H" interface) and MSC and Equipment Identification Register (EIR) ("F" interface).
The MAP protocol is encoded in ASN.1 Basic Encoding rules (BER) as a part of the SS7 stack above the TCAP protocol. The operations provided by MAP are:

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

3G.TS.24.008 v.3.3.1 www.3gpp.org/ftp/specs
The main function of the Mobility Management (MM) sub-layer is to support the mobility of user terminals, for instance; informing the network of its present location and providing user identity confidentiality. A further function
of the MM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer. The format of the header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n
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 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:
0x01
0x10
0x11
0001
MM STATUS
Information elements Various information elements. Interested in more details about testing this protocol?
MTP- 3B SS7 Layer 3. (part of UMTS) http://www.itu.int/ITU-T/. Recommendation Q.2210, Q.704. The MTP-3B (Message Transfer Part) Protocol describes the functions and procedures for and relating to the transfer of messages between the signalling points, which are the nodes of the signalling network. Such functions and procedures are performed by the Message Transfer Part at level 3, and therefore they assume that the signalling points are connected by signalling links, incorporating the functions described in Recommendations Q.702 and Q.703. The signalling network functions must ensure a reliable transfer of the signalling messages, according to the requirements specified in Recommendation Q.706, even in the case of the failure of signalling links and signalling transfer points; therefore, they include the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and to appropriately reconfigure the routing of messages through the signalling network. According to these principles, the signalling network functions can be divided into two basic categories, namely:

Signalling message handling; and Signalling network management.
The MTP-3B protocol structure appears as follows: 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 Spare 7 6 5 4 Spare Service Indicator 3 2 1 Octets 1 2
networks for the following purposes. 0 1 3 5 Management Messages Testing/Maintenance Messages SCCP ISUP
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]). 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) Frame Number Octets 1 Frame Frame Number RFCI Payload CRC Octets 1 2 3 4 5-n Frame Control Part Frame Check Sum Part Frame Payload part .
FQC Header CRC
RFCI Spare
2 3
Control Part Frame Check Sum Part Frame Payload part .
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: 4-n
1. NbUP Frame Control part (fixed size); 2. NbUP Frame Check Sum part (fixed size); 3. NbUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not consider the usage of spare extension field]). The NbUP Frame Control Part and the NbUP Frame Check Sum constitute the NbUP PDU Type 1 Frame Header. PDU Type 14 PDU Type 14 is defined to perform control procedures over the NbUP in support mode for pre-defined SDU sizes. The control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to the control procedure. The figure below shows the Iu frame structure for PDU Type 14 of the NbUP protocol at the SAP towards the transport layers (TNL-SAP). Bits 8 7 6 5 4 3 2 1 Number of Octets 1 2 3 Frame Control Part
Ack/Nack PDU Type PDU Type (=14) (=0, i.e. 14 Frame procedure) Number NbUP Mode version Procedure Indicator Payload CRC
Header CRC Payload CRC
Frame Check Sum Part
Reserved for procedure data Spare extension
Frame Payload n-n+32 part
5-n
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.
Enlarge
More Details
PCAP (3GPP TS 25.453) The PCAP protocol is the Positioning Calculation Application Part between the Radio Network Controller (RNC) and the Stand-alone A-GPS SMLC (SAS). An SAS performs the following procedures:

Provides GPS related data to the RNC. Performs the position calculation function for UE assisted GPS.
The PCAP consists of Elementary Procedures (EPs). An Elementary Procedure is a unit of interaction between the RNC and the SAS. An EP consists of an initiating message and possibly a response message. Two kinds of EPs are used:

Class 1: Elementary Procedures with a response (success or failure). Class 2: Elementary Procedures without a response. For Class 1 EPs, the types of responses can be as follows: o Successful: A signaling message explicitly indicates that the elementary procedure successfully completed with the receipt of the response. o Unsuccessful: A signaling message explicitly indicates that the EP failed. Class 2 EPs are always considered always successful.
PCAP Services PCAP provides the signaling services between RNC and SAS that are required to fulfill the PCAP functions. PCAP services are categorized as follows:
Position Calculation Service: They are related to a single UE and involve the transfer of GPS measurement data and UE position estimate data over the Iupc interface between the SRNC and the SAS. They utilize connectionless signaling transport provided by the Iupc signaling bearer. Information Exchange Service: They involve the transfer of GPS related data over the Iupc interface between the RNC and the SAS on demand, on modification, or at regular intervals. They utilize connection-oriented signaling transport provided by the Iupc signaling bearer.
PCAP Functions PCAP has the following functions:

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

Position Calculation. Information Exchange Initiation. Information Reporting. Information Exchange Termination. Information Exchange Failure. Error Indication. Private Message.
PDCP ETSI TS 125 323. http://webapp.etsi.org/key/queryform.asp. Packet Data Convergence Protocol. PDCP provides its services to the NAS at the UE or the relay at the Radio Network Controller (RNC). It uses the services provided by the Radio Link Control (RLC) sublayer. Network layer protocols are intended to be capable of operating over services derived from a wide variety of subnetworks and data links. UMTS supports several network layer protocols providing protocol transparency for the users of the service. At that point of view supported protocols are IPv4 and IPv6. Introduction of new network layer protocols to be transferred over UTRAN must be possible without any changes to UTRAN protocols. Therefore, all functions related to transfer of packets from higher layers (PDCP SDUs) are carried out in a transparent way by the UTRAN network entities. This is one of the requirements for UTRAN PDCP. It performs the following functions:
Header compression and decompression of IP data streams (e.g.,
TCP/IP and RTP/UDP/IP headers) at the transmitting and receiving entity, respectively. The header compression method is specific to the particular network layer, transport layer or upper layer protocol combinations e.g. TCP/IP and RTP/UDP/IP. Transfer of user data. Transmission of user data means that PDCP receives PDCP SDU from the NAS and forwards it to the RLC layer and vice versa. M<intenance of PDCP sequence numbers for radio bearers that are configured to support lossless SRNS relocation.
Header compression is different for each type of protocol. There are three possible PDU header types: PDCP-No-Header PDU 8 7 6 5 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 PDCP Data PDU 1 PDCP SeqNum PDU Default 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
Enlarge
More Details
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 Block Confirm Block Request Confusion Establish Confirm Establish Request Release Confirm Release Request Reset Confirm 5 6
Destination signalling association identifier
9 10 11
Reset Request 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
Enlarge
More Details
Interested in more details about testing this protocol? RANAP

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

General control services Notification services Dedicated control services
All messages are text messages in ASN.1 format and can contain the following text messages: 0 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 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
26 27 28
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.

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 3 2 1 Octets 1
TrD PDU UMD PDU (Unacknowledged Mode Data PDU). The UMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. It is used by RLC when using unacknowledged data transfer. The length of the data part is an integer number of octets. The UMD PDU header consists of the first octet, which contains the sequence number. The RLC header consists of the first octet and all the octets that contain length indicators. 8 7 6 5 4 3 2 1 E E Octets . . . (Optional)(1)
Sequence Number Length Indicator . . . . Length Indicator Data
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 . . .
Sequence Number
Length Indicator Data
(Optional)
PAD or a piggybacked STATUS PDU
(Optional)
Control PDUs STATUS PDU and Piggybacked STATUS PDU The STATUS PDU and the Piggybacked STATUS PDU are used in acknowledged mode. The STATUS PDU is used to report the status between two RLC AM entities. Both receiver and transmitter status information may be included in the same STATUS PDU:

by the receiving entity to inform the transmitting entity about missing PDUs at the receiving entity; by the receiving entity to inform the transmitting entity about the size of the allowed transmission window; by the transmitting entity to request the receiving entity to move the receiving window. 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 5 4 3 2 1 Octets 1 2
SUFI1
... SUFIK PAD
. . N
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 7 6 PDU type HFNI HFNI 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 5 4 3 RSN 2 1 R1 Octets 1 2
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 STATUS 001 RESET 010 RESET ACK 011-111 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
Enlarge
More Details
RLP ETSI TS 124 022. (You can download all the ETSI files from www.ETSI.org) Three versions of the RLP (Radio Link Protocol) are defined:

RLP version 0: single-link basic version; RLP version 1: single-link extended version (e.g. extended by data compression); RLP version 2: multi-link version.
RLP uses one physical link (single-link) or from 1 up to 4 (multi-link) substreams on one or more physical links. However, the RLP multi-link
version is designed to be able to support up to 8 physical links. If, in the call set-up signalling, either end indicates that it cannot support multi-link operation, neither end can use RLP versions higher than 1. If the BC negotiation during call set-up results in a possibility for multi-link operation during the call, both ends can only use RLP version 2 only. RLP makes use of an underlying FEC (Forward Error Correction) mechanism. For RLP to perform adequately it is assumed that the basic radio channel together with FEC provides for a block error rate of less than 10 %, where a block consists of 240 or 576 bits. Furthermore, it is assumed that in case of multi-link RLP the difference of the delay between all physical links is less than timer T4. In A/Gb mode, RLP frames are sent in strict alignment with the radio transmission. RLP frames are of a fixed size of 240 (TCH/F4.8 and TCH/F9.6 channel codings) or 576 bits (TCH/F14.4, TCH/F28.8 and TCH/F43.2 channel codings). Whenever a frame is to be sent, the RLP entity has to provide the necessary protocol information to be contained in it. In Iu mode, the RLP frame size does not depend on the channel coding, only 576 bit frames are used. RLP entities running only in an Iu mode environment need only to support the 576 bit frame length. The REMAP function is not necessary. RLP entities running in both of the systems have to support the REMAP function. In a handover from Iu mode to A/Gb mode the frame either stays 576 bits long or changes from 576 bits to 240 bits incurring a REMAP. In a handover from A/Gb mode to Iu mode the frame either stays 576 bits long or changes from 240 bits to 576 bits incurring a REMAP. Provision is made for discontinuous transmission (DTX). RLP spans from the User Equipment (UE) to the interworking function (IWF), located at the nearest Mobile Switching Centre (MSC), or beyond. Depending on the exact location of the IWF, handover of the UE may result in link-reset or even total loss of the connection. The UE shall initiate the RLP link. In addition the MSC/IWF may initiate the RLP link. In the terminology of HDLC, RLP is used in a balanced configuration, employing asynchronous operation, i.e. either station has the right to set-up, reset, or disconnect a link at any time. Procedural means are provided for to deal with contentious situations, should they ever occur. RLP is full duplex in the sense that it allows for information to be transferred in both directions simultaneously. The RLP frames have a fixed length of either 240 or 576 bits consisting of a header, information field and an FCS field. The format of the 240-bit frame is: Header Information FCS
16 bit 24 bit
200 bit 192 bit RLP 240-bit frame format
24 bit 24 bit
The header is 16 bits in versions 0 and 1 and in version 2 (U frames). It is 24 bits in version 2 (S and I+S frames). The format of the 576-bit frame is: The header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames. Header Contains control information of one of the following 3 types: unnumbered protocol control information (U frames), supervisory information (S frames) and user information carrying supervisory information piggybacked (I+S frames). FCS This is the Frame Check Sequence field. The RLP entity will be in the Asynchronous Balanced Mode (ABM), which is the data link operation mode; or Asynchronous Disconnected Mode (ADM), which is the data link non-operational mode. Header structure of versions 0 and 1 N(S) is a bit 4 low order bit and N(R) is a bit 11 low order bit. 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 N(R) N(R) X UP S UP N(R) N(R)
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-of-sequence frames have been received. RNR
The Receive Not Ready indicates that the entity is not ready to receive numbered information frames. SREJ Selective Reject is used to request retransmission of a single frame. UP This is used in version 2 to indicate that a service level upgrading will increase the throughput. Interested in more details about testing this protocol?
RNSAP ETSI TS 125 423. (You can download all the ETSI files from www.ETSI.org) The Iur interface RNSAP (Radio Network Subsystem Application Part) procedures are divided into four modules as follows: 1. 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.
Enlarge
More Details
RRC 3GPP TS 25.331 http://webapp.etsi.org/key/queryform.asp The RRC is an upper layer protocol which is part of the IUB Interface. The RRC has the following interfaces:

RRC Application Radio Link Control (RLC) for control and configuration of RLC entities Medium Access Control (MAC) for control and configuration of MAC entities Framing Protocol (FP) for paging related functionality
The functional entities of the RRC (Radio Resource Control) layer are described below:
Routing of higher layer messages to different MM/CM entities (UE side) or different core network domains (UTRAN side) is handled by the Routing Function Entity (RFE) Broadcast functions are handled in the broadcast control function entity (BCFE). The BCFE is used to deliver the RRC services, which are required at the GC-SAP. The BCFE can use the lower layer services provided by the Tr-SAP and UM-SAP. Paging of UEs that do not have an RRC connection is controlled by the paging and notification control function entity (PNFE). The PNFE is used to deliver the RRC services that are required at the Nt-SAP. The PNFE can use the lower layer services provided by the Tr-SAP and UM-SAP. The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE. The DCFE is used to deliver the RRC services that are required at the DC-SAP and can use lower layer services of UM/AM-SAP and Tr-SAP depending on the message to be sent and on the current UE service state. In TDD mode, the DCFE is assisted by the Shared Control Function Entity (SCFE) location in the C-RNC, which controls the allocation of the PDSCH and PUSCH using lower layers services of UM-SAP and Tr-SAP.
The Transfer Mode Entity (TME) handles the mapping between the different entities inside the RRC layer and the SAPs provided by RLC. The RRC performs the functions listed below.

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

General Control Notification Dedicated control.
The RRC layer provides signalling connections to the upper layers to support the exchange of upper layer's information flow. The signalling connection is an acknowledged-mode link between the user equipment and the core network to transfer upper layer information. For each core network domain, at most one signalling connection may exist at the same time. The RRC layer maps the signalling connections for one UE on a single RRC connection. Messages are in the format of ASN.1 messages. Interested in more details about testing this protocol?
SCTP The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services to its users:

Acknowledged error-free non-duplicated transfer of user data. Application-level segmentation to conform to discovered MTU size. Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams. Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions. Enhanced reliability through support of multi-homing at either or both ends of the association.
The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data. The following is the format of the SCTP header.
Octets 1 2 3 4 5 6 7 8 9 10 11 12
Source Port Number Destination Port Number
Verification Tag
Adler 32 Checksum
Source Port Number This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs. Destination Port Number This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application. Verification Tag The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization. For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's. Adler 32 Checksum This field contains an Adler-32 checksum on this SCTP datagram.
Chunk Field Descriptions The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field. 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. Interested in more details about testing this protocol?
SNDCP
GSM 04.65 version 6.1.0 www.3gpp.org/ftp/specs
Sub-Network Dependant Convergence Protocol (SNDCP) uses the services provided by the Logical Link Control (LLC) layer and the Session Management (SM) sub-layer. SNDCP splits into either IP or X.25 and maps them on to the LLC. It also provides fintions such as the compresssion, segmentation and multiplexing of network-layer messages to a single virtual connection. The main functions of SNDCP are:

Multiplexing of several PDPs (packet data protocol). Compression/decompression of user data. Compression/decompression of protocol control information. Segmentation of a network protocol data unit (N-PDU) into Logical Link Control Protocol Data Units (LL-PDUs) and re-assembly of LLPDUs 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 4 3 2 1 Octet 1 2 3-n
NSAPI PCOMP
DCOMP
Network service access point identifier. Values may be: 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 SNUNITDATA (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
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 Session management messages Activate PDP context request Activate PDP context accept Activate PDP context reject Request PDP context activation
01000101 01000110 01000111 01001000 01001001 01010000 01010001 01010010 01010011 01010100 01010101
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 SM Status
Information elements Various information elements. Interested in more details about testing this protocol?
SMS
3GPP TS 24.011 http://www.etsi.org
The Short Message Service (SMS) is used to transfer text messages over mobile networks between a GSM PLMN Mobile Station and a Short Message Entity via a Service Center. The terms MO (Mobile Originating) and MT (Mobile Terminating) are used to indicate the direction in which the short message is sent. SMS messages can be encapsulated in control or relay messages. SMS Control Message The format of the control protocol message header is shown in the following illustration: 8 7 6 5 4 3 2 1 Octet 1 2 3-n
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 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 1 ----
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 RP-SMMA message transfer attempt. Information elements Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and may or may not include a length indicator. Interested in more details about testing this protocol?
SMS TP ETSI TS 123 040. (You can download all the ETSI files from www.ETSI.org) The SMS TP (Short Message Transfer Layer Protocol) is comprised of two basic services:

SM MT (Short Message Mobile Terminated). SM MO (Short Message Mobile Originated).
SM MO denotes the capability of the GSM/UMTS system to transfer a short message submitted by the MS to one SME via an SC, and to provide information about the delivery of the short message either by a delivery report
or a failure report with a specific mechanism for later delivery. The message must include the address of that SME to which the SC shall eventually attempt to relay the short Message Transfer Layer Protocol. The text messages to be transferred by means of the SM MT or SM MO contains up to 140 octets. The structure of the SMS TP protocol header is as follows: 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 1 2 3 SMS-DELIVER-REPORT SMS-SUBMIT SMS-COMMAND 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
Protocol Discriminator Message type
Transaction ID
Information elements
3-n
Protocol Discriminator The Protocol discriminator (must be 0x0B). Transaction Identifier The format and coding of transaction identifier values. Message Type The Message type number. The following message types are available 42 58 59 Release Complete Facility Register
SS7 Protocol Suite

This page describes the following SS7 protocols: BICC BISUP DUP ISUP MAP MTP-2 MTP-3 Q2140 SCCP TCAP TUP Bearer Independent Call Control protoco B-ISDN User Part Data User Part ISDN User Part Mobile Application Part Message Transfer Part Level 2 Message Transfer Part Level 3 Recommendation Q.2140 Signalling Connection Control Part Transaction Capabilities Application Part Telephone User Part
For information on SS7 and other telecom protocol testing View this file in pdf format. CCITT developed the Signalling System 7 (SS7) specification. SS7 is a common channel signalling system. This means that one channel is used only for sending the signalling information, whether the system has one bearer channel or multiple bearer channels. The hardware and software functions of the SS7 protocol are divided into layers which loosely correspond to the OSI 7 layer model.
See the Performance Technologies SS7 Tutorial for more information on the SS7 standard.
The SS7 protocol suite is illustrated here in relation to the OSI model: Click the protocols on the map to see more details.
BICC ITU-T Q.1901 Bearer Independent Call Control protocol is a call control protocol used between serving nodes. This protocol is based on the ISUP protocol, and was adapted to support the ISDN services independent of the bearer technology and signalling message transport technology used.
The format of the BICC packet is shown in the following illustration: 8 7 6 5 CIC CIC CIC MSB CIC Message Type BICC packet structure Routing Label The label contained in a signalling message, and used by the relevant user part to identify particulars to which the message refers. It is also used by the Message Transfer Part to route the message towards its destination point. Call Instance Code (CIC) The allocation of call instance codes to individual circuits is determined by bilateral agreement and/or in accordance with applicable predetermined rules. Message Type Code The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each ISDN User Part message. Each message consists of a number of parameters. Message types may be: 4 3 2 1 LSB Octet 1 2 3 4 5
6 9 44 24 26 23 41 25 27 7 5 47 32 33 31 8 1 12 16 18 14 2 13 45
Address complete. Answer. Call progress. Circuit group blocking. Circuit group blocking acknowledgement. Circuit group reset. Circuit group reset acknowledgement. Circuit group unblocking. Circuit group unblocking acknowledgement. Connect. Continuity. Confusion Facility accepted. Facility reject. Facility request. Forward transfer. Initial address. Release. Release complete. Reset circuit. Resume. Subsequent address. Suspend. User-to-user information.
Parameters Each parameter has a name which is coded as a single octet. The length of a parameter may be fixed or variable, and a length indicator for each parameter may be included.
Enlarge
More Details
BISUP Recommendation Q.2763 (02/95). http://www.itu.int/ITU-T/. The B-ISDN User Part (B-ISUP) is applicable to international B-ISDN networks. In addition, the B-ISDN User Part is suitable for national applications. Most messages and parameters specified for international use are also required in typical national applications. Moreover, coding space has been reserved in order to allow national administrations and recognized operating agencies to introduce network specific signalling messages and parameters within the internationally standardized protocol structure. B-ISDN user part messages are carried on the ATM signalling link by means of SAAL service data units, the format of which is described in 6.2/Q.2110. As a national option B-ISDN user part messages can be carried on the STM signalling link by means of signal units, the format of which is described in 2.2/Q.703. The format of, and the codes used in the service information octet are described in 14.2/Q.704. The service indicator for the B-ISDN user part is coded 1001. The signalling information field of each message signal unit containing an BISDN user part message consists of an integral number of octets and encompasses the following parts:
a) b) c) d) e)
routing label; message type code; message length; message compatibility information; message content.
The structure of the B-ISUP protocol is as follows: 8 7 6 5 4 3 2 1 Octets 1 2 3
Message Type Length Indicator Ext. Broadband/narrow- Pass on Discard Send Release Transit band interworking not message notification call ind at ind possible ind ind intermed ind exch. ind Message Type The different message types. The following message types are available: 0x01 0x02 0x05 0x06 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x2C INITIAL ADDRESS SUBSEQUENT ADDRESS CONSISTENCY CHECK REQUEST ADDRESS COMPLETE FORWARD TRANSFER ANSWER IAM ACKNOWLEDGE IAM REJECT RELEASE SUSPEND RESUME RESET ACKNOWLEDGE RELEASE COMPLETE CONSISTENCY CHECK REQ ACK RESET BLOCKING UNBLOCKING BLOCKING ACKNOWLEDGE UNBLOCKING ACKNOWLEDGE CONSISTENCY CHECK END CONSISTENCY CHECK END ACK CALL PROGRESS
0x2D 0x2F 0x32 0x34 0x35 0x38
USER-TO-USER INFORMATION CONFUSION NET RESOURCE MANAGMENT USER PART TEST USER PART AVAILABLE SEGMENTATION
Message Length The message length in octets. Broadband/narrow-band Iinterworking Ind: 0 Pass on 1 Discard message 2 Release call 3 Reserved Pass on not Possible Indicator The following indicators are available 0 Release call 1 Discard information Discard Message Indicator The following indicators are available 0 Do not discard message 1 Discard message Send Notification Indicator The following indicators are available 0 Do not send notification 1 Send notification Release call indicator The following indicators are available 0 Do not release call 1 Release call Transit at intermed exch. Indicator The following indicators are available 0 Transit interpretation 1 End node interpretation
Enlarge
More Details
DUP
ITU-T recommendation X.61 (Q.741) http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q741.html
The Data User Part (DUP) defines the necessary call control, and facility registration and cancellation related elements for international common channel signalling by use of Signalling System No. 7 for circuit-switched data transmission services. The data signalling messages are divided into two categories:

Call and circuit related messages: used to set up and clear a call or control and supervise the circuit state. Facility registration and cancellation related messages: used to exchange information between originating and destination exchanges to register and cancel information related to user facilities.
The general format of the header of call and circuit related messages is shown as follows:
15 8 7 0
OPC
DPS
BIC TCS Message specific parameters
OPC BIC Heading Code
The general format of the header of facility registration and cancellation messages is shown as follows: 15 OPC Spare bits Message specific parameters 87 DPS OPC Heading code 0
Routing Label The label contained in a signalling message and used by the relevant user part to identify particulars to which the message refers. This is also use by the message transfer part to route the message towards its destination point. It contains the DPS, OPC, BIC and TSC fields. DPS The destination point code (14 bits) is the code applicable to the data switching exchange to which the message is to be delivered. OPC The originating point code (14 bits) is the code applicable to the data switching exchange from which the message is sent. BIC Bearer identification code (12 bits). For bearers which form part of a 2.048 Mbit/s PCM system according to Recommendation G.734, the bearer identification code contains in the 5 least significant bits a binary representation of the actual number of the time slot which is assigned to the bearer. The remaining bits of the bearer identification code are used where necessary, to identify one among several systems, interconnecting the originating point and destination point. For bearers which form part of a 8.448 Mbit/s PCM system the bearer identification code is coded in accordance with the scheme specified for the circuit identification code for the corresponding case in Recommendation Q.723. TSC Time slot code (8 bits). If the data circuit is derived from the data multiplex carried by the bearer, identified by the bearer identification code: Bits 1-4 contain, in pure binary representation, the channel number of the circuit within the 12.8 kbit/s or 12 kbit/s phase; the channel number being in the range: 0-15 for 600 bit/s circuits
0- 3 for 2400 bit/s circuits 0- 1 for 4800 bit/s circuits 0 for 9600 bit/s circuits Bits 5-7 contain, in pure binary representation, the number of the 12.8 kbit/s or 12 kbit/s phase, the phase number being in the range 0-4; Bit 8 is coded 0. In the case where the data circuit uses the full 64 kbit/s bearer rate, the time slot code will be 01110000. Heading code The heading code (4 bits) contains the message type code which is mandatory for all messages. It uniquely defines the function and format of each DAP message. Message specific parameters Contains specific fields for each message. Spare bits Not used, should be set to "0000". Interested in more details about testing this protocol?
ISUP
Q.763 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.html
ISUP is the ISDN User Part of SS7. ISUP defines the protocol and procedures used to setup, manage and release trunk circuits that carry voice and data calls over the public switched telephone network. ISUP is used for both ISDN and nonISDN calls. Calls that originate and terminate at the same switch do not use ISUP signalling. ISDN User Part messages are carried on the signalling link by means of signal units. The signalling information field of each message signal unit contains an ISDN User Part message consisting of an integral number of octets. The format of the ISUP packet is shown in the following illustration: Routing label Circuit identification code Message type code Mandatory fixed part - (Parameters)
Mandatory variable part - (Parameters) Optional part - (Parameters) ISUP packet structure Routing label The label contained in a signalling message, and used by the relevant user part to identify particulars to which the message refers. It is also used by the Message Transfer Part to route the message towards its destination point. Circuit identification code The allocation of circuit identification codes to individual circuits is determined by bilateral agreement and/or in accordance with applicable predetermined rules. Message type code The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each ISDN User Part message. Each message consists of a number of parameters. Message types may be: Address complete Answer Blocking Blocking acknowledgement Call progress Circuit group blocking Circuit group blocking acknowledgement Circuit group query @ Circuit group query response @ Circuit group reset Circuit group reset acknowledgement Circuit group unblocking Circuit group unblocking acknowledgement Charge information @ Confusion Connect Continuity Continuity check request Facility @ Facility accepted Facility reject Forward transfer Identification request Identification response Information @ Information request @ Initial address
Loop back acknowledgement Network resource management Overload @ Pass-along @ Release Release complete Reset circuit Resume Segmentation Subsequent address Suspend Unblocking Unblocking acknowledgement Unequipped CIC @ User Part available User Part test User-to-user information Parameters Each parameter has a name which is coded as a single octet. The length of a parameter may be fixed or variable, and a length indicator for each parameter may be included.
ISUP decode Interested in more details about testing this protocol?
MAP
EIA/TIA-41 http://www.tiaonline.org.com
Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming are carried by TCAP In mobile networks (IS-41 and GSM) when a mobile subscriber roams into a new mobile switching center (MSC) area, the integrated visitor location register requests service profile information from the subscriber's home location register (HLR) using MAP (mobile application part) information carried within TCAP messages. The packet consists of a header followed by up to four information elements. The general format of the header is shown here: The format of the header is shown in the following illustration: 1 byte Operation specifier MAP Parameters ... MAP header structure Operation specifier The type of packet. The following operations are defined:

1 byte Length
AuthenticationDirective AuthenticationDirectiveForward AuthenticationFailureReport AuthenticationRequest AuthenticationStatusReport BaseStationChallenge Blocking BulkDeregistration CountRequest FacilitiesDirective FacilitiesDirective2 FacilitiesRelease FeatureRequest FlashRequest HandoffBack HandoffBack2 HandoffMeasurementRequest
HandoffMeasurementRequest2 HandoffToThird HandoffToThird2 InformationDirective InformationForward InterSystemAnswer InterSystemPage InterSystemPage2 InterSystemSetup LocationRequest MobileOnChannel MSInactive OriginationRequest QualificationDirective QualificationRequest RandomVariableRequest RedirectionDirective RedirectionRequest RegistrationCancellation RegistrationNotification RemoteUserInteractionDirective ResetCircuit RoutingRequest SMSDeliveryBackward SMSDeliveryForward SMSDeliveryPointToPoint SMSNotification SMSRequest TransferToNumberRequest TrunkTest TrunkTestDisconnect Unblocking UnreliableRoamerDataDirective UnsolicitedResponse
Length The length of the packet. MAP parameters Various parameters dependent on the operation. Interested in more details about testing this protocol?
MTP-2
Message Transfer Part - Level 2 (MTP-2) is a signalling link which together with MTP-3 provides reliable transfer of signalling messages between two directly connected signalling points. (Compliant with ITU Q.703 1994 and ANSI T1.111 199.) The format of the header is shown in the following illustration: 7 Flag BSN (7 bits) FSN (7 bits) LI (6 + 2 bits) SIO SIF Checksum (16 bits) Flag MTP-2 header structure BSN Backward sequence number. Used to acknowledge message signal units which have been received from the remote end of the signalling link. BIB Backward indicator bit. The forward and backward indicator bit together with forward and backward sequence number are used in the basic error control method to perform the signal unit sequence control and acknowledgment functions. FSN Forward sequence number. FIB Forward indicator bit. LI Length indicator. This indicates the number of octets following the length indicator octet. SIO Service information octet. BIB FIB 8 bits
SIF Signalling information field. Checksum Every signal unit has 16 check bits for error detection. Interested in more details about testing this protocol?
MTP-3
Q.704 http://www.itu.ch/itudoc/itu-t/rec/q/q500-999/q704_27792.html
Message Transfer Part - Level 3 (MTP-3) connects Q.SAAL to the users. It transfers messages between the nodes of the signalling network. MTP-3 ensures reliable transfer of the signalling messages, even in the case of the failure of the signalling links and signalling transfer points. The protocol therefore includes the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and appropriately reconfigure the routing of messages through the signalling network. The structure of the MTP-3 header is shown in the following illustration: Service indicator 4 bits MTP-3 header structure 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:

Subservice field 4 bits
Signalling network management messages Signalling network testing and maintenance messages SCCP Telephone user part ISDN user part Data user part Reserved for MTP testing user part.
Sub-service field The sub-service field contains the network indicator and two spare bits to discriminate between national and international messages.
Q2140 Recommendation Q.2140. http://www.itu.int/ITU-T/ The SSCF for NNI Signaling standard consists of the Service Specific Coordination Function (SSCF) in conjunction with the Service Specific Connection Oriented Protocol (SSCOP) which defines the Service Specific Convergence Sublayer (SSCS). The purpose of the Service Specific Coordination Function is to enhance the services of SSCOP to meet the needs of the requirements of the NNI level 3 protocol. In addition the SSCF at the NNI provides communication with Layer Management for proper operation of signalling links. The SSCF at the NNI is the uppermost sub-layer in the protocol stack for the SAAL at the NNI. By construction, it utilizes the services of the underlying SAAL sub-layers, in combination with its own functions, to provide an overall SAAL service to the SAAL user, as described below. The SAAL at the NNI provides signalling link functions for the transfer of signalling messages over one individual signalling data link. The SAAL functions provide a signalling link for reliable transfer of signalling messages between two signalling points. A signalling message delivered by the higher levels is transferred over the signalling link in variable length Protocol Data Units (PDUs). For proper operation of the signalling link, the PDU comprises transfer control information in addition to the information content of the signalling message. The protocol header structure is as follows: 8 7 6 5 4 3 2 1 Octets 1 2 3 SSCF Status SSCF Type The SSCF status: 1 Out of Service 4
Reserved
2 3 4 5 7 8 9 10
Processor Outage In Service Normal Emergency Alignment Not Successful Management Initiated Protocol Error Proving Not Successful
Enlarge
More Details
SCCP
The Signalling Connection Control Part (SCCP) offers enhancements to MTP level 3 to provide connectionless and connection-oriented network services, as well as to address translation capabilities. The SCCP enhancements to MTP provide a network service which is equivalent to the OSI Network layer 3. (Compliant with the ITU specification Q.713, ITU-T: Signalling System No. 7 SCCP Formats And Codes 03-93 SS7 Basics/ Toni Beninger/ S038 1991 ANSI T1.112.) The format of the header is shown in the following illustration:
Routing label Message type code Mandatory fixed part Mandatory variable part Optional part SCCP header structure Routing label A standard routing label. Message type code A one octet code which is mandatory for all messages. The message type code uniquely defines the function and format of each SCCP message. Existing Message Type Codes are: CR CC CREF RLSD RLC DT1 DT2 AK UDT UDTS ED EA RSR RSC ERR IT XUDT XUDTS Connection Request. Connection Confirm. Connection Refused. Released. Release Complete. Data Form 1. Data Form 2. Data Acknowledgment. Unidata. Unidata Service. Expedited Data. Expedited Data Acknowledgment. Reset Request. Reset Confirm. Protocol Data Unit Error. Inactivity Test. Extended Unidata. Extended Unidata Service.
Mandatory fixed part The parts that are mandatory and of fixed length for a particular message type will be contained in the mandatory fixed part. Mandatory variable part Mandatory parameters of variable length will be included in the mandatory variable part. The name of each parameter and the order in which the pointers are sent is implicit in the message type. Optional part
The optional part consists of parameters that may or may not occur in any particular message type. Both fixed length and variable length parameters may be included. Optional parameters may be transmitted in any order. Each optional parameter will include the parameter name (one octet) and the length indicator (one octet) followed by the parameter contents. Interested in more details about testing this protocol?
TCAP
TCAP (Transaction Capabilities Application Part) enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signalling points using the SCCP connectionless service. TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion. (Compliant with ITU recommendation q.773.) A TCAP message is structured as a single constructor information element consisting of the following: Transaction Portion, which contains information elements used by the Transaction sub-layer; a Component Portion, which contains information elements used by the Component sub-layer related to components; and, optionally, the Dialogue Portion, which contains the Application Context and user information, which are not components. Each Component is a constructor information element. Tag Length Contents
TCAP packet structure Information Element An information element is first interpreted according to its position within the syntax of the message. Each information element within a TCAP message has the same structure. An information element consists of three fields, which always appear in the following order. Tag The Tag distinguishes one information element from another and governs the
interpretation of the Contents. It may be one or more octets in length. The Tag is composed of Class, Form and Tag codes. Length Specifies the length of the Contents. Contents Contains the substance of the element, containing the primary information the element is intended to convey. TCAP Packet Types TCAP packet types are as follows:

Unidirectional Query with permission Query without permission Response Conversation with permission Conversation without permission Abort
TUP ITU-T Recommendation Q.723. http://www.itu.int/ITU-T/. Signalling System No.7 - Telephone User Part. The Telephone User Part (TUP) carries the telephone user messages on the signalling data link by means of signal units. The signalling information of each message constitutes the signalling information field of the corresponding signal unit and consists of an integral number of octets. It basically contains the label, the heading code and one or more signals and/or indications. The service information octet comprises the service indicator and the subservice field. The service indicator is used to associate signalling information with a particular User Part and is only used with message signal units (see Recommendation Q.704, 12.2). The information in the subservice field permits a distinction to be made between national and international signalling messages. In national applications when this discrimination is not required possibly for certain national User Parts only, the
subservice field can be used independently for different User Parts. The TUP header structure is as follows: 8 7 6 5 4 3 2 1 Octets 1
Message Type Code
Message Type Code The message type code. The following message type codes are available: 0x11 0x21 0x31 0x41 0x12 0x32 0x42 0x13 0x14 0x24 0x15 0x25 0x35 0x45 0x55 0x65 0x75 0x85 0x95 0xA5 0xB5 0xC5 0xF5 0x06 0x16 0x26 0x36 0x46 0x56 0x66 0x76 0x17 0x27 0x37 0x47 Initial Address Initial Address With Additional Information Subsequent Address Subsequent Address With One Signal General Forward Setup Information Continuity Signal Continuity Failure Signal General Request Address Complete Charging Switching Equipment Congestion Signal Circuit Group Congestion Signal National Network Congestion Signal Address Incomplete signal Call Failure Signal Subscriber Busy Signal (electrical) Unallocated Number Signal Line Out Of Service Signal Send Special Information Tone Signal Access Barred Signal Digital Path Not Provided Signal Misdialled Trunk Prefix Extended Unsuccessful Backward Setup Information Answer Signal, Unqualified Answer Signal, Charge Answer Signal, No Charge Clear Back Signal Clear Forward Signal Reanswer Signal Forward Transfer Signal Calling Party Clear Signal Release Guard Signal Blocking Signal Blocking Acknowledgement Signal Unblocking Signal
0x57 0x67 0x77 0x18 0x28 0x38 0x48 0x58 0x68 0x78 0x88 0x98 0xA8 0xB8 0xC8 0xD8 0xE8 0x1A 0x2C 0x1D 0x1E 0x2E 0x1F
Unblocking Acknowledgement Signal Continuity Check Request Signal Reset Circuit Signal Maintenance Oriented Group Blocking Maintenance Oriented Group Blocking Acknowledgement Maintenance Oriented Group Unblocking Maintenance Oriented Group Unblocking Acknowledgement Hardware Failure Oriented Group Blocking Hardware Failure Oriented Group Blocking Acknowledgement Hardware Failure Oriented Group Unblocking Hardware Failure Oriented Group Unblocking Acknowledgement Circuit Group Reset Circuit Group Reset Acknowledgement Software Generated Group Blocking Software Generated Group Blocking Acknowledgement Software Generated Group Unblocking Software Generated Group Unblocking Acknowledgement Automatic Congestion Control Information Metering Pulse Message Operator Signal Subscriber Local - Busy Signal Subscriber Toll - Busy Signal Malicious Call Tracing Signal
Enlarge
More Details

UMTS Family

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UMTS Family

Încărcat de

Drepturi de autor:

Formate disponibile

UMTS Family

Interested in more details about testing this protocol?

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

Message type Information elements BCC header structure

Message Type Information Element Coding of message types:

Interested in more details about testing this protocol?

Message type Information elements BSSAP+ header structure

Each message type has specific information elements

Unassigned: treated as an unknown IEI.

Interested in more details about testing this protocol?

Interested in more details about testing this protocol?

Message type Information element

Interested in more details about testing this protocol?

Interested in more details about testing this protocol?

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

Message type Information elements GCC header structure

Protocol discriminator Message type

Protocol discriminator Message type

Reserved Message type Length Sequence Flow label Reserved TID

MSIN digit 9 NSAPI

MSIN digit 8 MSIN digit 10 TDI structure

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

Interested in more details about testing this protocol?

PDU Type (=0) FQC Header CRC

Frame Number RFCI Payload CRC

Header CRC Payload CRC

Frame Check Sum Part

Reserved for procedure data Spare extension

Frame Payload n-n+32 part

Interested in more details about testing this protocol?

Interested in more details about testing this protocol?

Interested in more details about testing this protocol? MM

Protocol discriminator Message type

Signalling message handling; and Signalling network management.

Interested in more details about testing this protocol?

FQC Header CRC

Control Part Frame Check Sum Part Frame Payload part .

Header CRC Payload CRC

Frame Check Sum Part

Reserved for procedure data Spare extension

Frame Payload n-n+32 part

Interested in more details about testing this protocol?

PCAP Functions PCAP has the following functions:

The following PCAP procedures exist:

Interested in more details about testing this protocol?

Header compression and decompression of IP data streams (e.g.,

PDU type Sequence number Data

Interested in more details about testing this protocol?

Destination signalling association identifier

Reset Request Unblock Confirm Unblock Request

Parameter identfier Parameter compatibility Parameter length

Interested in more details about testing this protocol? RANAP

General control services Notification services Dedicated control services

CN-DeactivateTrace ResetResource RANAP-Relocation

Interested in more details about testing this protocol?

Sequence Number Length Indicator . . . . Length Indicator Data

Sequence Number Length Indicator . . .

Length Indicator Data

PAD or a piggybacked STATUS PDU

... SUFIK PAD

Interested in more details about testing this protocol?

200 bit 192 bit RLP 240-bit frame format

Message type Transaction ID Message Type