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
Frame type
FQI
Padding
Frame Type
One of the eight
AMR codec
modes, one of 4
different comfort noise frames, or an empty frame.

The following frame types are available:
Frame
Type
0
1
2
3
4
5
6
7
8
9
10
11
12-14
15
Mode
Indication
0
1
2
3
4
5
6
7
-
Mode
Request
0
1
2
3
4
5
6
7
-
Frame content (AMR mode, comfort noise, or other)

AMR 4,75 kbit/s
AMR 5,15 kbit/s
AMR 5,90 kbit/s
AMR 6,70 kbit/s
AMR 7,40 kbit/s
AMR 7,95 kbit/s
AMR 10,2 kbit/s
AMR 12,2 kbit/s
AMR SID
GSM-EFR SID
TDMA-EFR SID
PDC-EFR SID
For future use
No Data (No transmission/No reception)
FQI
Indicates whether the data in the frame contains errors.
0 Bad or corrupted frame
1 Good frame
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
Transaction identifier
Octet
Protocol discriminator
Message type
Information elements
3-n
BCC header structure
The protocol discriminator specifies the message being transferred
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the
transaction identifier is as follows:
8
TI flag
6
TI value
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
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.
BMC
3GPP TS 25.324 (You can download all the ETSI files from www.ETSI.org)
The Broadcast/Multicast Control Protocol adapts broadcast and multicast services on the radio interface.
Broadcast/Multicast Control (BMC) is a sublayer of L2 that exists in the User-Plane only and is located
above RLC. The L2/BMC sublayer is assumed as transparent for all services except broadcast/multicast. At
the UTRAN side, the BMC sublayer consists of one BMC protocol entity per cell. Each BMC entity requires a
single CTCH (Common Traffic Channel), which is provided by the MAC sublayer, through the RLC sublayer.
The BMC requests the Unacknowledged Mode service of the RLC. It is assumed that there is a function in
the RNC above BMC that resolves the geographical area information of the CB message (or, if applicable,
performs evaluation of a cell list) received from the Cell Broadcast Centre (CBC). A BMC protocol entity
serves only those messages at BMC-SAP that are to be broadcast into a specified cell.
The BMC protocol does the following:
Storage of Cell Broadcast Messages.

Traffic volume monitoring and radio resource request for CBS.
Scheduling of BMC messages.
Transmission of BMC messages to UE.
Delivery of Cell Broadcast messages to upper layer (NAS).
The BM-SAP provides a broadcast/multicast transmission service in the user plane on the radio interface for
common user data in unacknowledged mode. The BMC sublayer interacts with other entities. The
interactions with the upper layer/U-plane and the RRC layer are specified in terms of signaling messages
where the signaling messages represent the logical exchange of information and control between the BMC
sublayer and higher layers. They do not specify or constrain implementations. The (adjacent) layers connect
to each other through Service Access Points (SAPs).

The messages are signaling messages. There can be 3 types of signaling messages, Request, Indication
and Confirm.
The messages structure is of 2 types:
Between BMC and upper layer (U-plane):

BMC - Generic name - Type: Parameters.
Between BMC and the RRC entity:

CBMC - Generic name - Type: Parameters.
The following message types are available:
BMC Header:
8
Octet
Message Type
Information Element
2-n
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 classB 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
Octet
Message type
2-n
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.
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.
MM information.
Cell Global Identity.
Location information age.
Mobile station state.
Erroneous message.
CAMEL
ETSI TS 101 044. (You can download all the ETSI files from
www.ETSI.org)
The Customized Applications for Mobile network Enhanced Logic (CAMEL) provides the mechanisms to
support services of operators, which are not covered by standardized GSM services even when roaming
outside the HPLMN (Home Public Land Mobile Network).
The CAMEL feature is a network feature and not a supplementary service. It is a tool to help the network
operator provide the subscribers with the operator specific services even when roaming outside the HPLMN.
In this specification, the GSM Service Control Function (gsmSCF) is treated as being part of the HPLMN.
The regulatory environment in some countries may require the possibility that the gsmSCF and the HPLMN
are controlled by different operators, and the gsmSCF and the HPLMN are therefore distinct entities.
In the first phase the CAMEL features support:
Mobile originated and forwarded calls

Mobile terminating calls
Any time interrogation
Suppression of announcements
Note that CAMEL is not applicable to Emergency Setup (TS 12), i.e., in case an emergency call has been
requested the gsmSSF is not invoked.
The CAMEL mechanism addresses especially the need for information exchange between the VPLMN
(Visited PLMN) or IPLMN (Interrogating PLMN) and the HPLMN for support of operator specific services.
Subscribers who have subscribed to operator specific services and therefore need the functional support of
the CAMEL feature are marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL
support, the appropriate procedures, which provide the necessary information to the VPLMN or to the
HPLMN, are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a
gsmSCF, which is controlled by the HPLMN.
The CAMEL protocol is an upper layer protocol which is carried over the TCAP protocol as the data portion.
In an analogy to common protocols we can parallel the TCAP to the header and the CAMEL to the rest of
the decode. The message types are in the format of asn1 messages. Like most asn1 applicable protocols,
the CAMEL protocol has many message types that carry a high volume of data.
CC
ETSI TS 124 008.(You can download all the ETSI files from www.ETSI.org)
The Circuit-switched Call Control protocol (CC) must be supported by every mobile station. If a mobile
station does not support any bearer capability at all then it responds to a SETUP message with a RELEASE
COMPLETE message.
In UMTS only, integrity protected signalling is mandatory. In addition, all protocols use integrity protected
signalling. Integrity protection (activated by the network) of all CC signalling messages is the responsibility of
lower layers and is performed using the security mode control procedure (3GPP TS 25.331 [23c]).
In CC, more than one CC entity is defined. Each CC entity is independent from the other and communicatse
with the correspondent peer entity using its own MM connection. Different CC entities use different
transaction identifiers.
With a few exceptions protocol here relates to the call control protocol only with regard to two peer entities.
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
Octet
Message type
Information element
1-n
Message Type
The messge type, the following message types are available.
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0B
0x0E
0x0F
0x10
0x13
0x17
0x18
0x19
0x1A
0x1C
Alerting
Call Proceeding
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
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
Header CRC
1
FT
CFN
Spare
Octet
1
2
TFI of first DCH
3
4
Spare
TFI of last DCH
DL Data Frame Header

The structure of the DL data frame header is as follows:
8
Header CRC
CFN
Spare
TFI of first DCH
Octet
FT
1
2
3
4
Spare
TFI of last DCH
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.
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).
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
Message type
Octet
1
2
3-n
GCC header structure
The protocol discriminator specifies the message being transferred
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the
transaction identifier is as follows:
8
TI flag
TI value
TI flag
TI value
The side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI
value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After
a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two
identical transaction identifier values may be used when each value pertains to a transaction originated at
opposite ends of the interface.
Message type
The message type defines the function of each GCC message. The following message types exist:
0x110001
0x110010
0x110011
0x110100
0x110101
0x110110
0x111000
0x111001
0x111010
IMMEDIATE SETUP
SETUP
CONNECT
TERMINATION
TERMINATION REQUEST
TERMINATION REJECT
STATUS
GET STATUS
SET PARAMETER
Each information element has a name which is coded as a single octet. The length of an information
element may be fixed or variable and a length indicator for each one may be included.
GMM
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
Skip indicator
Octet
1
Message type
3-n
GMM header structure
1000 identifies the GMM protocol.
Skip indicator
The value of this field is 0000.
Message type
Uniquely defines the function and format of each GMM message. The message type is mandatory for all
messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send
sequence number in messages sent from the mobile station. GMM message types may be:
0 0 0 0 0 0 0 1 Attach request
0 0 0 0 0 0 1 0 Attach accept
0 0 0 0 0 0 1 1 Attach complete
0 0 0 0 0 1 0 0 Attach reject
0 0 0 0 0 1 0 1 Detach request
0 0 0 0 0 1 1 0 Detach accept
0 0 0 0 1 0 0 0 Routing area update request
0 0 0 0 1 0 0 1 Routing area update accept
0 0 0 0 1 0 1 0 Routing area update complete
0 0 0 0 1 0 1 1 Routing area update reject
0 0 0 1 0 0 0 0 P-TMSI reallocation command
0 0 0 1 0 0 0 1 P-TMSI reallocation complete
0 0 0 1 0 0 1 0 Authentication and ciphering req
0 0 0 1 0 0 1 1 Authentication and ciphering resp
0 0 0 1 0 1 0 0 Authentication and ciphering rej
0 0 0 1 0 1 0 1 Identity request
0 0 0 1 0 1 1 0 Identity response
0 0 1 0 0 0 0 0 GMM status
0 0 1 0 0 0 0 1 GMM information
Various information elements.
GSM
3GPP TS 24.008 http://www.etsi.org
This protocol is a variant of the GPRS GSM protocol. The main function of the GPRS session management
(SM) is to support PDP context handling of the user terminal. The SM comprises procedures for: identified
PDP context activation, deactivation and modification, and anonymous PDP context activation and
deactivation.
8
Skip indicator
Octet
1
Message type
3-n
GSM header structure
1010 identifies the GSM protocol.
Skip indicator
Message type
Uniquely defines the function and format of each GSM message. The message type is mandatory for all
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
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 manyto-many relationship between SGSNs and GGSNs. An SGSN may provide service to many GGSNs. A single
GGSN may associate with many SGSNs to deliver traffic to a large number of geographically diverse mobile
stations.
The GTP header is a fixed format 16 octet header used for all GTP messages.
Version
Reserved
1
LFN
Octet
1
Message type
Length
3-4
Sequence
5-6
Flow label
7-8
Reserved
9-12
TID
13-20
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
Octet
MCC digit 2
MCC digit 1
MNC digit 1
MCC digit 3
MSIN digit 1
MNC digit 2
MSIN digit 3
MSIN digit 2
MSIN digit 5
MSIN digit 4
MSIN digit 7
MSIN digit 6
MSIN digit 9
MSIN digit 8
NSAPI
MSIN digit 10
TDI structure
MCC, MNC, MSIN digits

Parts of the IMSI (defined in GMS 04.08).
NSAPI
Network service access point identifier.
LLC supports two modes of operation:
Unacknowledged peer-to-peer operation.

Acknowledged peer-to-peer operation.
IUup
3GPP TS 25.415 (You can download all the ETSI files from www.ETSI.org)
TheIuUP (Iu User Plane) protocol is located in the user plane of the Radio Network layer over the Iu
interface; theIuUP protocol layer. It is used to convey user data associated to Radio Access Bearers.
OneIuUP protocol instance is associated to one RAB and one RAB only. If several RABs are established
towards one given UE, then these RABs make use of severalIuUP protocol instances.
Whenever a RAB requires transfer of user data in theIuUP, anIuUP protocol instance exists at each Iu
interface access points. TheseIuUP protocol instances are established, relocated and released together with
the associated RAB.
Frame Format for predefined size SDUs
PDU Type 0
PDU Type 0 is defined to transfer user data over theIuUP in support mode for pre-defined SDU sizes. An
error detection scheme is provided over theIuUP for the payload part.
The following shows the Iu frame structure for PDU type 0 of theIuUP protocol at the SAP towards the
transport layers (TNL-SAP).
Bits
8
PDU Type (=0)

FQC
Frame Number
RFCI
Octets
1
2
Payload
CRC
Header CRC
Payload CRC
Payload Fields
5-n
Payload Fields
Padding
Spare extension
n-n+4
IUup PDU Type 0 Format
Frame
Control
Part
Frame
Check
Sum
Part
Frame
Payload
part
.
TheIuUP PDU Type 0 is made of three parts:

1.
2.
3.
IuUP Frame Control part (fixed size);

IuUP Frame Check Sum part (fixed size);
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
PDU Type (=1)
Frame Number
FQC
Octets
1
RFCI
Header CRC
Spare
Payload CRC
Payload Fields
Payload Fields
4-n
Padding
Spare extension
n-n+4
IUup PDU Type 1Format
Frame
Control
Part
Frame
Check
Sum
Part
Frame
Payload
part
.

1.
2.
3.

IuUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not
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
Bits
8
PDU Type (=14)
Number
3
Ack/Nack (=0, PDU Type 14

i.e. procedure) Frame Number
of
Octets
1
Frame
Control
IUup Mode version
Procedure Indicator
Part
3
Header CRC
Payload CRC
Payload CRC
Frame
Check
Sum Part
4
Reserved for procedure data

Spare extension
5-n
Frame
Payload
n-n+32 part
IUup PDU Type 14 Format for procedure sending

1.
2.
3.

IuUP Frame Payload part (variable length, rounded up to octet).
Header.
MAC
3GPP TS 25.321 V3.7.0 (2001-03) (You can download all the 3G files from www.3gpp.org )
The MAC (Medium Access Control) protocol architecture is constructed from MAC entities. The entities are
assigned the following names: MAC-b and MAC-c/sh.
MAC-b is the MAC entity that handles the BCH broadcast transport channel
MAC-c/sh, is the MAC entity that handles the following transport channels:
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
<------------------------------------->
UE-Id
type
TCTF
UE-Id
C/T
MAC SDU
TCTF
Target Channel Type Field
The TCTF field is a flag that provides identification of the logical channel class on FACH and RACH
transport channels, i.e. whether it carries BCCH, CCCH, CTCH, SHCCH or dedicated logical channel
information. Note that the size of the TCTF field of FACH for FDD is either 2 or 8 bits depending of the value
of the 2 most significant bits and for TDD is either 3 or 5 bits depending on the value of the 3 most significant
bits. The TCTF of the RACH for TDD is either 2 or 4 bits depending on the value of the 2 most significant
bits.
UE-Id Type
The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC headers.
UE-Id Type field 2 bits UE-Id Type
00
01
10
U-RNTI
C-RNTI
Reserved(PDUs with this coding will be discarded by this version of
the protocol)
11
Reserved(PDUs with this coding will be discarded by this version of

the protocol)
UE-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)
MAP
EIA/TIA IS41.5 1997 IS41-D
The MAP (Mobile Application Part) protocol typically runs on top of the Signaling System 7 (SS7) protocol.
MAP is a non call-associated signaling protocol. It provides the support for interactive mobile applications
( cellular, paging, voice messaging, etc.) in a distributed environment. MAP defines the end-to-end protocol
between applications which may be located in an SS7 network, and/or other networks supporting the MAP
protocol. SS7 is a common channel signaling protocol that enables resources in broadband and narrowband
networks to exchange messages related to call setup, supervision and teardown, information needed for
distributed application processing and network management.
The MAP protocol provides mechanisms to communicate between a Mobile Switching Center (MSC) and
Visitor Location Register (VLR) ("B" interface), MSC and Home Location Register (HLR) ("C" interface),
Visitor Location Register (VLR) and HLR ("D" Interface), VLR and VLR ("G" Interface), MSC and MSC ("E"
interface), MSC and Short Message Service gateway (SMS) ("H" interface) and MSC and Equipment
Identification Register (EIR) ("F" interface).
The MAP protocol is encoded in ASN.1 Basic Encoding rules (BER) as a part of the SS7 stack above the
TCAP protocol. The operations provided by MAP are:
Update Location, Cancel Location, PurgeMS, Send Identification

Prepare HandOver, Send End Signal, Proceed Access Signalling
Forward Access Signalling, Prepare Subsequent Hand Over
Send Authentication Info, Authentication Failure Report
Check IEMI, Insert Subscriber Data, Delete Subscriber Data
Reset, Forward Check SS Indication, Activate Trace Mode
Deactivate Trace Mode, Send Routing Info
Provide Roaming Number, Resume Call Handling
Provide SIWFSN Number, SIWFSS Signalling Modify
Set Reporting State, Status Report, Remote User Free
IST-Alert, IST Command, Register SS, Erase-SS
Activate-SS, Deactivate-SS, Interrogate-SS
Procceed Unstructed-SS, Unstructed-SS Request
Unstructed-SS Notify, Register Password,
Get Password, Register CC-Entry
Erase-CC Entry, Send Routing Info For SM
MO Forward SM, MT Forward SM, Report SM Delivery Status
Inform Service Center, Alert Service Center, Ready For SM
Provide Subscriber Info, Any Time Interrogation
Any Time Subscription Interrogation, Any Time Modification
Note subscriber Data Modified, SS Invocation Notification
Prepare Group Call, Send Group Call End-Signal
Process Group Call Signalling, Forward Group Call Signalling
Update GPRS Location, Send Routing INFO For GPRS
Failure Report, Note MS Present For GPRS
Provide Subscriber Location, Send Routing Info For LCS
Subscriber Location Report, Note-MM-Event, System Failure
Data Missing, Unexpected Data Value, Facility Not supported
Incompatible Terminal, Resource Limitation, Unknown Subsriber
Number Changed, Unknown MSC, Unidentied Subscriber
Unknown Equipment, Roaming Not Allowed, Illegal Subscriber
Illegal Equipment, Bearer Service Not Provisioned,

Tele Service Not Provisioned, No Handover Number Available
Subsequent Handover Failure, Target Cell Outside Group Call Area
Tracing Buffer Full, No Roaming Number Available, Absent Subscriber
Busy subscriber, No Subscriber Reply, Call Barred, Forwarding Failed
OR-Not Allowed, Forwarding Violation, CUG-Reject, ATI-Not Allowed
ATSI Not Allowed, ATM Not Allowed, Information Not allowed
No Group Call Number Available, Illegal SS-Operation, SS-Error Status
SS-Not available, Subscription Violation, SS Incompatibility
Unknown Alphabet, USSD-Busy, PW Registration Failure
Negative PW-Check, Number Of PW Attempts Violation
Short Term Denial, Long Term Denial, Subscriber Bust For MT-SMS
SM Delivery Failure, Message Waiting List Full, Absent Subscriber SM
Unauthorized Requesting Network, Unautorized LCS Client
Position Method Failure, Unknown Or Unreachable LCS Client
MM Event Not Supported, Send Parameters, Process Unstructed SS Data
Preform HandOver, Preform Subsequent HandOver
Not Internal HandOver, Note Subscriber Present, Unknown Base Station
Alert Service Center Without Result, Trace Subscriber Activity
Begin Subscriber Activity, Invalid Target Base Station
No Radio Resource Available
MM
3G.TS.24.008 v.3.3.1 www.3gpp.org/ftp/specs
The main function of the Mobility Management (MM) sub-layer is to support the mobility of user terminals, for
instance; informing the network of its present location and providing user identity confidentiality. A further
function of the MM sub-layer is to provide connection management services to the different entities of the
upper Connection Management (CM) sub-layer.
8
Skip indicator
Octet
1
Message type
3-n
MM header structure
0101 identifies the MM protocol.
Skip indicator
Message type
Uniquely defines the function and format of each MM message. The message type is mandatory for all
sequence number in messages sent from the mobile station. MM message types may be:
0x00
xxxx
0001
0010
0100
1000
xxxx
0001
0010
0100
1000
1001
1010
1011
xxxx
0001
0010
0011
0100
1000
1001
xxxx
0001
0x01
0x10
0x11
Registration messages:
IMSI DETACH INDICATION
LOCATION UPDATING ACCEPT
LOCATION UPDATING REJECT
LOCATION UPDATING REQUEST
Security messages:
AUTHENTICATION REJECT
AUTHENTICATION REQUEST
AUTHENTICATION RESPONSE
IDENTITY REQUEST
IDENTITY RESPONSE
TMSI REALLOCATION COMMAND
TMSI REALLOCATION COMPLETE
Connection management messages:
CM SERVICE ACCEPT
CM SERVICE REJECT
CM SERVICE ABORT
CM SERVICE REQUEST
CM REESTABLISHMENT REQUEST
ABORT
Miscellaneous messages:
MM STATUS
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
Spare
Spare
Service Indicator
Octets
1
2
Service Indicator
Used to perform message distribution and in some cases to perform message routing. The service indicator
codes are used in international signalling networks for the following purposes.
0
1
3
5
Management Messages
Testing/Maintenance Messages
SCCP
ISUP
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
Bits
8
Octets
PDU Type (=0)
Frame Number
FQC
RFCI
2
Payload
CRC
Header CRC
Payload CRC
Payload Fields
5-n
Payload Fields
Padding
Spare extension
n-n+4
NbUP PDU Type 0 Format
Frame
Control
Part
Frame
Check
Sum
Part
Frame
Payload
part
.
The NbUP PDU Type 0 is made of three parts:

1.
2.
3.
NbUP Frame Control part (fixed size);

NbUP Frame Check Sum part (fixed size);
NbUP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not
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
PDU Type (=1)

FQC
Frame Number
RFCI
Octets
1
2
Header CRC
Spare
Payload CRC
Payload Fields
Payload Fields
4-n
Padding
Spare extension
n-n+4
NbUP PDU Type 1Format
Frame
Control
Part
Frame
Check
Sum
Part
Frame
Payload
part
.

1.
2.
3.

NbUP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note:this does not
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
Bits
8
Number
3
of
Octets
PDU Type (=14)
Ack/Nack (=0, PDU Type 14

i.e. procedure) Frame Number
NbUP Mode version
Procedure Indicator
Frame
Control
Part
3
Header CRC
Payload CRC
Payload CRC
Reserved for procedure data
Spare extension
Frame
Check
Sum Part
4
5-n
Frame
Payload
n-n+32 part
NbUP PDU Type 14 Format for procedure sending

1.
2.
3.

NbUP Frame Payload part (variable length, rounded up to octet).
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.
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
Octets
0-n
Data
PDCP Data PDU
8
PDU type
Octets
PID
Data
2-n
PDCP SeqNum PDU

8
PDU type
2
PID
Octets
1
Sequence number
Data
4-n
PDU Type
The PDU type indicates the PDCP date PDU type. (sequence number included or not)
The possible values of the PDU types are as follows:
0
1
Default
PDCP Data PDU

PDCP SeqNum PDU
Reserved
PID
Indicates the header compression identifier used. Header compression is different for each type of protocol.
Sequence Number
The PDCP PDU sequence number
Data
PDCP SDUs that have been header compressed are mapped to this field if header compression is
negotiated. Otherwise, PDCP SDUs are mapped to this field
Q2630
ATM
Layer 2 (also UMTS)
ITU-T Recommendation Q.2630.1
http://www.itu.int/ITU-T/
The AAL type 2 signalling protocol provides the signalling capability to establish, release and maintain AAL
type 2 point-to-point connections across a series of ATM VCCs that carry AAL type 2 links. These services
are accessible via the AAL type 2 served user service access point (A2SU-SAP).
The AAL type 2 signalling protocol also provides maintenance functions associated with the AAL type 2
signalling.
An AAL type 2 signalling endpoint should be able to control AAL type 2 links on more than one ALL type 2
path. These AAL type 2 paths may be contained on different ATM VPCs, which in turn may be carried on
different ATM physical interfaces.
Two peer AAL type 2 signalling entities rely on the generic signalling transport service to provide assured
data transfer between them and service availability indications. These services are accessible via the
Generic Signalling Transport Service Access Point (GST-SAP).
Note that primitives over the A2SU-SAP, GST-SAP, and LM-SAP are used for descriptive purpose only. They
do not imply a specific implementation. Both peer AAL type 2 signalling entities provide the same set of
services.
The AAL type 2 signalling entity is subdivided into protocol entities and nodal functions. At each AAL type 2
service endpoint, the AAL type 2 signalling entity communicates with the AAL type 2 served user. At an AAL
type 2 switch, the AAL type 2 signalling entity does not communicate with an AAL type 2 served user.
The AAL2 protocol header structure appears as follows
8
Destination signalling association identifier
Octets
1
2
3
4
Message identifier
Message compatibility
Destination Signalling Association Identifier

The Destination Singalling Association Identifier.
Message Identifier
The message identifier. The following types of messge identifier are available:
1
2
3
4
5
6
7
8
9
10
11
Block Confirm
Block Request
Confusion
Establish Confirm
Establish Request
Release Confirm
Release Request
Reset Confirm
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
Octets
Parameter identfier
Parameter compatibility
Parameter length
Fields
4-n
Payload
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
26
27
28
RAB-Assignment
Iu-Release
RelocationPreparation
RelocationResourceAllocation
RelocationCancel
SRNS-ContextTransfer
SecurityModeControl
DataVolumeReport
CN-InformationBroadcast
Reset
RAB-ReleaseRequest
Iu-ReleaseRequest
RelocationDetect
RelocationComplete3
Paging
CommonID
CN-InvokeTrace
LocationReportingControl
LocationReport
InitialUE-Message
DirectTransfer
OverloadControl
ErrorIndication
SRNS-DataForward
ForwardSRNS-Context
PrivateMessage5
CN-DeactivateTrace
ResetResource
RANAP-Relocation
RLC
3GPP TS 25.322 v3.7.0 (2001-06) (You can download all the ETSI files from www.ETSI.org)
The Radio Link Control protocol (RLC) has 3 different peer entities. There is one transmitting and one
receiving entity for the transparent mode service and the unacknowledged mode service; and one combined
transmitting and receiving entity for the acknowledged mode service.
The following functions are supported by RLC.
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
Octets
Data
TrD PDU
UMD PDU (Unacknowledged Mode Data PDU).

The UMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. It is used by RLC
when using unacknowledged data transfer. The length of the data part is an integer number of octets. The
UMD PDU header consists of the first octet, which contains the sequence number. The RLC header consists
of the first octet and all the octets that contain length indicators.
8
Octets
Sequence Number
Length Indicator
(Optional)(1)
(Optional)
.
.
.
.
Length Indicator
.
.
Data
PAD
OctN
(Optional)
AMD PDU (Acknowledged Mode Data PDU).

The AMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. The AMD PDU
transfers user data and piggybacked status information and requests status report by setting Poll bit when
RLC is operating in acknowledged mode. The length of the data part is an integer number of octets. The
AMD PDU header consists of the first two octets, which contain the sequence number. The RLC header
consists of the first two octets and all the octets that contain length indicators.
8
D/C
Octets
Sequence Number
Sequence Number
1
HE
Length Indicator
2
E
(Optional)(1)
.
.
.
Length Indicator
(Optional)
Data
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:
8
D/C
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
PDU type
2
SUFI1
Octets
1
SUFI1
...
SUFIK
PAD
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
PDU type
SUFI1
Octets
1
SUFI1
...
SUFIK
PAD
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
PDU type
3
RSN
HFNI
Octets
R1
1
2
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
PDU Type
The length of this field is 3 bits. The PDU type field indicates the Control PDU type. The following types are
available.
000
001
010
011-111
STATUS
RESET
RESET ACK
Reserved
Sequence Number (SN)

The SN field indicates the sequence number of the PDU encoded in binary.
Polling bit (P)

The polling bit is used to request a status report (one or several STATUS PDUs) from the receiver RLC.
0
1
Status report not requested

Request a status report
Extension bit
This bit indicates if the next octet will be a length indicator with an E bit.
0
1
data
Length indicator and E bit.
Reserved 1 (R1)
This field in the RESET PDU and RESET ACK PDU is used to achieve octet alignment and for this purpose
it is coded as 000. Other functions of it are left for future releases.
Header Extension Type (HE)

This two-bit field indicates if the next octet will be data or a length indicator and E bit.
00
01
10-11
The succeeding octet contains data

The succeeding octet contains a length indicator and E bit
Reserved (PDUs with this coding will be discarded by this version of the protocol)
Length Indicator (LI)

The Length Indicator is used to indicate, each time, the end of an SDU that occurs in the PDU. The Length
Indicator points out the number of octets between the end of the last Length Indicator field and up to and
including the octet at the end of an SDU segment. Length Indicators are included in the PDUs that they refer
to. The size of the Length Indicator may be either 7 bits or 15 bits.
SUFI
The SUFI field that are used is dependant on the implementation, but when a STATUS PDU includes
information about which PDUs have been received and which are detected as missing, information is not
included PDUs that have not yet reached the receiver.
The SUFI (Super-Field) includes three sub-fields: type information (type of super-field, e.g. list, bitmap,
acknowledgement, etc), length information (providing the length of a variable length field within the following
value field) and a value
RLP
ETSI TS 124 022. (You can download all the ETSI files from www.ETSI.org)
Three versions of the RLP (Radio Link Protocol) are defined:
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 multilink 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
200 bit
24 bit
24 bit
192 bit
24 bit
RLP 240-bit frame format

The header is 16 bits in versions 0 and 1 and in version 2 (U frames). It is 24 bits in version 2 (S and I+S
frames).
The 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
C/R S1 S2 0 1 1 1 1 1
I+S
C/R S1 S2
1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X
N(S)
N(R)
P/F
N(R)
Bits 1-16
Header structure of version 2

S is a L2R status Bit, N(S) is a bit 1 low order bit, N(R) is a bit 14 low order bit and UP is a UP bit.
U C/R X X 1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X
S
X X 0 1 1 1 1 1 P/F S1 S2
I+S
N(S)
P/F S1 S2
N(R)
UP
N(R)
UP
Bits 1-24
C/R
The Command Response Bit indicates whether the frame is a command or a response frame. It can have
the following values:
1
0
command
response
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.
RNSAP
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
Octets
Message type
Transaction ID
2 or 2,3
Message Type
All messages are text messages in asn.1 format.
Transaction ID
Associates all the messges belonging to the same procedure.
RRC
3GPP TS 25.331
The RRC is an upper layer protocol which is part of the IUB Interface.
The RRC has the following interfaces:
RRC Application
Radio Link Control (RLC) for control and configuration of RLC entities
Medium Access Control (MAC) for control and configuration of MAC entities
Framing Protocol (FP) for paging related functionality
The functional entities of the RRC (Radio Resource Control) layer are described below:
Routing of higher layer messages to different MM/CM entities (UE side) or different core network
domains (UTRAN side) is handled by the Routing Function Entity (RFE)
Broadcast functions are handled in the broadcast control function entity (BCFE). The BCFE is
used to deliver the RRC services, which are required at the GC-SAP. The BCFE can use the lower
layer services provided by the Tr-SAP and UM-SAP.
Paging of UEs that do not have an RRC connection is controlled by the paging and notification
control function entity (PNFE). The PNFE is used to deliver the RRC services that are required at
the Nt-SAP. The PNFE can use the lower layer services provided by the Tr-SAP and UM-SAP.
The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE. The
DCFE is used to deliver the RRC services that are required at the DC-SAP and can use lower layer
services of UM/AM-SAP and Tr-SAP depending on the message to be sent and on the current UE
service state.
In TDD mode, the DCFE is assisted by the Shared Control Function Entity (SCFE) location in the
C-RNC, which controls the allocation of the PDSCH and PUSCH using lower layers services of
UM-SAP and Tr-SAP.
The Transfer Mode Entity (TME) handles the mapping between the different entities inside the RRC layer
and the SAPs provided by RLC.
The RRC performs the functions listed below.
Broadcast of information related to the non-access stratum (Core Network)

Broadcast of information related to the access stratum
Establishment, maintenance and release of an RRC connection between the UE and UTRAN
Establishment, reconfiguration and release of Radio Bearers
Assignment, reconfiguration and release of radio resources for the RRC connection
RRC connection mobility functions
Control of requested QoS
UE measurement reporting and control of the reporting
Outer loop power control
Control of ciphering
Slow DCA (TDD mode)
Paging
Initial cell selection and cell re-selection
Arbitration of radio resources on uplink DCH
RRC message integrity protection
Timing advance (TDD mode)
CBS control.
The RRC offers the following services to upper layers:
General Control
Notification
Dedicated control.
The RRC layer provides signalling connections to the upper layers to support the exchange of upper layer's
information flow. The signalling connection is an acknowledged-mode link between the user equipment and
the core network to transfer upper layer information. For each core network domain, at most one signalling
connection may exist at the same time. The RRC layer maps the signalling connections for one UE on a
single RRC connection.
Messages are in the format of ASN.1 messages.
SCTP
The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over
IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol
operating on top of an unreliable datagram service such as UDP. It offers the following services to its users:
Acknowledged error-free non-duplicated transfer of user data. Application-level segmentation to

conform to discovered MTU size.
Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival
delivery of individual datagrams.
Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
Enhanced reliability through support of multi-homing at either or both ends of the association.
The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and
masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks
contain either control information or user data.
The following is the format of the SCTP header.
8
Source Port Number
Destination Port Number
Octets
1
2
3
4
5
Verification Tag
6
7
8
9
Adler 32 Checksum
10
11
12
Source Port Number

This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP
Address, to identify the association to which this datagram belongs.
Destination Port Number

This is the SCTP port number to which this datagram is destined. The receiving host will use this port
number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.
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
Octets
Chunk ID
Chunk Flags
Chunk Length
Chunk Value (variable)
3
4
5-n
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 subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs
acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.
Heartbeat Request (HEARTBEAT)

An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability
of a particular destination transport address defined in the present association. The parameter fields contain
the time values.
Heartbeat Acknowledgement (HEARTBEAT ACK)

An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The
parameter field contains the time values.
Abort Association (ABORT)

The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort
chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not
bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in
the SCTP datagram or they will be ignored.
SHUTDOWN
An endpoint in an association uses this chunk to initiate a graceful termination of the association with its
peer.
Shutdown Acknowledgement (SHUTDOWN ACK)

This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown
process. The SHUTDOWN ACK chunk has no parameters.
Operation Error (ERROR)

This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or
more error causes.
State Cookie (COOKIE)

This chunk is used only during the initialization of an association. It is sent by the initiator of an association
to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the
association, but may be bundled with one or more Data chunks in the same datagram.
Cookie Acknowledgement (COOKIE ACK)

This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a
COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with
one or more Data chunks in the same SCTP datagram.
Payload Data (DATA)

This contains the user data.
Vendor Specific Chunk Extensions

This chunk type is available to allow vendors to support their own extended data formats not defined by the
IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk
sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information
should make an attempt to operate without it, although they may do so (and report they are doing so) in a
degraded mode.
SNDCP
GSM 04.65 version 6.1.0 www.3gpp.org/ftp/specs
Sub-Network Dependant Convergence Protocol (SNDCP) uses the services provided by the Logical Link
Control (LLC) layer and the Session Management (SM) sub-layer. SNDCP splits into either IP or X.25 and
maps them on to the LLC. It also provides fintions such as the compresssion, segmentation and multiplexing
of network-layer messages to a single virtual connection.
The main functions of SNDCP are:
Multiplexing of several PDPs (packet data protocol).

Compression/decompression of user data.
Compression/decompression of protocol control information.
Segmentation of a network protocol data unit (N-PDU) into Logical Link Control Protocol Data Units
(LL-PDUs) and re-assembly of LL-PDUs into a N-PDU.
The SN-DATA PDU is used for acknowledged data transfer. Its format is as follows:
8
DCOMP
Octet
NSAPI
PCOMP
Data
3-n
SN-DATA PDU structure
NSAPI
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 SN-UNITDATA (1).
C
Compression indicator. A value of 0 indicates that compression fields, DCOMP and PCOMP, are not
included. A value of 1 indicates that these fields are included.
X
Spare bit is set to 0.
DCOMP
Data compression coding, included if C-bit set. Values are as follows:
0
No compression.
1-14 Points to the data compression identifier negotiated dynamically.
15
Reserved for future extensions.
PCOMP
Protocol control information compression coding, included if C-bit set. Values are as follows:
0
No compression.
Points to the protocol control information compression identifier negotiated
1-14
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.
8
Skip indicator
Octet
1
Message type
3-n
SM header structure
1010 identifies the SM protocol.
Skip indicator
Message type
Uniquely defines the function and format of each SM message. The message type is mandatory for all
sequence number in messages sent from the mobile station. SM message types may be:
01xxxxxx
01000001
01000010
01000011
01000100
01000101
01000110
01000111
01001000
01001001
01010000
01010001
01010010
01010011
01010100
01010101
Session management messages

Activate PDP context request
Activate PDP context accept
Activate PDP context reject
Request PDP context activation
Request PDP context activation rej.
Deactivate PDP context request
Deactivate PDP context accept
Modify PDP context request
Modify PDP context accept
Activate AA PDP context request
Activate AA PDP context accept
Activate AA PDP context reject
Deactivate AA PDP context request
Deactivate AA PDP context accept
SM Status
SMS
3GPP TS 24.011 http://www.etsi.org
The Short Message Service (SMS) is used to transfer text messages over mobile networks between a GSM
PLMN Mobile Station and a Short Message Entity via a Service Center. The terms MO (Mobile Originating)
and MT (Mobile Terminating) are used to indicate the direction in which the short message is sent.
SMS messages can be encapsulated in control or relay messages.
SMS Control Message

The format of the control protocol message header is shown in the following illustration:
8
Octet
1
Message type
3-n
SMS control protocol header structureheader structure
1001 identifies the SMS protocol.
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
2
TI value
1
----
TI flag
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
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
Octet
1
Message reference
3-n
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.
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and
may or may not include a length indicator.
SMS TP
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
Octet
Message type
Information Elements
2-n
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
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
Protocol Discriminator
Transaction ID
Octet
1
Message type
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
ATM
ATM relies on cell-switching technology. ATM cells have a fixed length of 53 bytes which
allows for very fast switching. ATM creates pathways between end nodes called virtual
circuits which are identified by the VPI /VCI values.
This section describes the ATM UNI and NNI cell header structures and the PDU structures
for the various ATM/SAR formats including: AAL0, AAL1, AAL2, AAL3/4 and AAL5.
UNI/NNI Cells
The UNI or NNI cell header comprises the first 5 bytes of the ATM cell. The remaining 48
bytes comprise the payload of the cell whose format depends on the AAL type of the cell.
The structure of the UNI and NNI cell headers are given here:
8 bits
GFC
VPI
VPI
VCI
VCI
VCI
PTI (3 bits)
CLP
HEC
UNI cell header
8 bits
VPI
VPI
VCI
VCI
VCI
PTI (3 bits)
CLP
HEC
NNI cell header
GFC
Generic flow control (000=uncontrolled access).
VPI
Virtual path identifier.
VCI
Virtual channel identifier.
Together, the VPI and VCI comprise the VPCI. These fields represent the routing
information within the ATM cell.
PTI
Payload type indication.
CLP
Cell loss priority.
HEC
Header error control.
AAL0
AAL0 cells are sometimes referred to as raw cells. The payload consists of 48 bytes and
has no special meaning.
AAL1 PDU
The structure of the AAL1 PDU is given in the following illustration:
SN
CSI
SNP
SC
CRC
EPC
SAR PDU Payload

47 bytes
1 bit
3 bits
3 bits
1 bit
AAL1 PDU
SN
Sequence number. Numbers the stream of SAR PDUs of a CPCS PDU (modulo 16). The sequence number
is comprised of the CSI and the SN.
CSI
Convergence sublayer indicator. Used for residual time stamp for clocking.
SC
Sequence count. The sequence number for the entire CS PDU, which is generated by the Convergence
Sublayer.
SNP
Sequence number protection. Comprised of the CRC and the EPC.
CRC
Cyclic redundancy check calculated over the SAR header.
EPC
Even parity check calculated over the CRC.
SAR PDU payload

47-byte user information field.
AAL2
ITU-T I.366.2
AAL2 provides bandwidth-efficient transmission of low-rate, short and variable packets in delay sensitive
applications. It supports VBR and CBR. AAL2 also provides for variable payload within cells and across
cells. AAL type 2 is subdivided into the Common Part Sublayer (CPS ) and the Service Specific
Convergence Sublayer (SSCS ).
AAL2 CPS Packet

The CPS packet consists of a 3 octet header followed by a payload. The structure of the AAL2 CPS packet
is shown in the following illustration.
CID
LI
UUI
HEC
Information payload
8 bits
6 bits
5 bits
5 bits
1-45/64 bytes
AAL2 CPS packet
CID
Channel identification. Values may be as follows:
0
Not used
1
Reserved for layer management peer-to-peer procedures
2-7
Reserved
8-255 Identifies AAL2 user (248 total channels)
LI
Length indicator. This is the length of the packet payload associated with each individual user. Value is one
less than the packet payload and has a default value of 45 bytes (may be set to 64 bytes).
UUI
User-to-user indication. Provides a link between the CPS and an appropriate SSCS that satisfies the higher
layer application. Values may be:
1-15
16-22
23
24
25
26
27
28-30
31
Encoding format for audio, circuit mode data and demodulated fascimile image data
using SSCS type 1 packets.
Reserved.
Reserved for SSCS type 2 packets.
SSCS type 3 packets except alarm packets.
Non-standard extension.
Framed mode data, final packet.
Framed mode data, more to come.
Reserved.
Alarm packets.
HEC
Header error control.
Information payload
Contains the CPS/SSCS PDU as described below.
AAL2 CPS PDU

The structure of the AAL2 SAR PDU is given in the following illustration.
Start field
CPS-PDU payload
OSF
SN
6 bits
1 bit
1 bit
AAL2 PDU payload
PAD
0-47 bytes
AAL2 CPS PDU
OSF
Offset field. Identifies the location of the start of the next CPS packet within the CPS-PDU.
SN
Sequence number. Protects data integrity.
P
Parity. Protects the start field from errors.
SAR PDU payload

Information field of the SAR PDU.
PAD
Padding.
AAL2 SSCS Packet

The SSCS conveys narrowband calls consisting of voice, voiceband data or circuit mode data. SSCS
packets are transported as CPS packets over AAL2 connections. The CPS packet contains a SSCS
payload. There are 3 SSCS packet types.
Type 1 Unprotected; this is used by default.

Type 2 Partially protected.
Type 3 Fully protected: the entire payload is protected by a 10-bit CRC which is computed as for OAM cells.
The remaining 2 bits of the 2-octet trailer consist of the message type field.
AAL2 SSCS Type 3 Packets:
The type 3 packets are used for the following:
Dialled digits
Channel associated signalling bits
Facsimile demodulated control data
Alarms
User state control operations.
The following illustration gives the general sturcture of AAL2 SSCS Type 3 PDUs. The format varies and
each message has its own format according to the actual message type.
Redundancy
Time
stamp
Message
dependant
information
14
16
Message type CRC-10
10 bits
AAL2 SSCS Type 3 PDU
Redundancy
Packets are sent 3 times to ensure error correction. The value in this field signifies the transmission number.
Time stamp
Counters packet delay variation and allows a receiver to accurately reproduce the relative timing of
successive events separated by a short interval.
Message dependant information

Packet content that varies, depending on the message type.
Message type
The message type code.
The following message type codes exist:
Information stream
Message type
code
Packet format
Dialled digits
000010
Dialled digits
Channel associated signalling
000011
CAS bits
Facsimile demodulation control 100000
T.30 Preamble
100001
EPT
100010
Training
100011
Fax Idle
100100
T.30 Data
Alarms
000000
Alarm
User state control
000001
User state control
CRC-10
The 10-bit CRC.
AAL3/4
AAL3/4 consists of message and streaming modes. It provides for point-to-point and point-to-multipoint
(ATM layer) connections. The Convergence Sublayer (CS) of the ATM Adaptation Layer (AAL) is divided into
two parts: service specific (SSCS ) and common part (CPCS ). This is illustrated in the following diagram:
AAL3/4 packet
AAL3/4 packets are used to carry computer data, mainly SMDS traffic.
AAL3/4 CPCS PDU

The functions of the AAL3/4 CPCS include connectionless network layer (Class D), meaning no need for an
SSCS; and frame relaying telecommunication service in Class C. The CPCS PDU is composed of the
following fields:
Header
CPI
Info
Btag
Basize
Trailer
CPCS SDU
Pad
Etag
Length
0-65535
0-3
2 bytes
AAL3/4 CPCS PDU
CPI
Message type. Set to zero when the BAsize and Length fields are encoded in bytes.
Btag
Beginning tag. This is an identifier for the packet. It is repeated as the Etag.
BAsize
Buffer allocation size. Size (in bytes) that the receiver has to allocate to capture all the data.
CPCS SDU
Variable information field up to 65535 bytes.
PAD
Padding field which is used to achieve 32-bit alignment of the length of the packet.
0
All-zero.
Etag
End tag. Must be the same as Btag.
Length
Must be the same as BASize.
AAL3/4 SAR PDU

The structure of the AAL3/4 SAR PDU is illustrated below:
ST
SN
MID
Information
LI
10
352
2-byte header
44 bytes
48 bytes
AAL3/4 SAR PDU
ST
Segment type. Values may be as follows:
Segment type Value Meaning

BOM
10
Beginning of message
CRC
10 bits
2-byte trailer
COM
EOM
SSM
00
01
11
Continuation of message
End of message
Single segment message
SN
Sequence number. Numbers the stream of SAR PDUs of a CPCS PDU (modulo 16).
MID
Multiplexing identification. This is used for multiplexing several AAL3/4 connections over one ATM link.
Information
This field has a fixed length of 44 bytes and contains parts of CPCS PDU.
LI
Length indication. Contains the length of the SAR SDU in bytes, as follows:
Segment type
LI
BOM, COM
EOM
EOM (Abort)
SSM
44
4, ..., 44
63
9, ..., 44
CRC
Cyclic redundancy check.
Functions of AAL3/4 SAR include identification of SAR SDUs; error indication and handling; SAR SDU
sequence continuity; multiplexing and demultiplexing.
AAL5
The type 5 adaptation layer is a simplified version of AAL3/4. It also consists of message and streaming
modes, with the CS divided into the service specific and common part. AAL5 provides point-to-point and
point-to-multipoint (ATM layer) connections.
AAL5 is used to carry computer data such as TCP/IP. It is the most popular AAL and is sometimes referred
to as SEAL (simple and easy adaptation layer).
AAL5 CPCS PDU

The AAL5 CPCS PDU is composed of the following fields:
Info
Trailer
CPCS payload
Pad
0-65535
0-47
UU CPI Length
1
AAL5 CPCS PDU
CRC
4 bytes
CPCS payload
The actual information that is sent by the user. Note that the information comes before any length indication
(as opposed to AAL3/4 where the amount of memory required is known in advance).
Pad
Padding bytes to make the entire packet (including control and CRC) fit into a 48-byte boundary.
UU
CPCS user-to-user indication to transfer one byte of user information.
CPI
Common part indicator is a filling byte (of value 0). This field is to be used in the future for layer
management message indication.
Length
Length of the user information without the Pad.
CRC
CRC-32. Used to allow identification of corrupted transmission.
AAL5 SAR PDU

The structure of the AAL5 CS PDU is as follows:
Information
PAD
UU
CPI
Length
CRC-32
1-48
0-47
4 bytes
8-byte trailer
AAL5 SAR PDU
The fields are as described for the AAL5 CPCS PDU.
F4/F5 OAM
The structure of the F4 and F5 OAM cell payload is given in the following illustration.
OAM type
Function type
Function specific
Reserved
CRC-10
360
10 bits
48 bytes
F4/F5 OAM PDU
CRC-10
Cyclic redundancy check: G(x) = x 10 +x 9 +x 5 +x 4 +x+1
OAM type / Function type

The possible values for OAM type and function type are listed below:
OAM type
Value
Function type
Value
Fault Management
0001
Alarm Indication Signal (AIS)
0000
Far End Receive Failure (FERF)
0001
OAM Cell Loopback
1000
Continuity Check
0100
Forward Monitoring
0000
Backward Reporting
0001
Monitoring and Reporting
0010
Performance Monitoring
0000
Continuity Check
0001
Performance Management 0010
Activation/ Deactivation
1000
OAM F4 cells operate at the VP level. They use the same VPI as the user cells, however, they use two
different reserved VCIs, as follows:
VCI=3 Segment OAM F4 cells.
VCI=4 End-end OAM F4 cells.
OAM F5 cells operate at the VC level. They use the same VPI and VCI as the user cells. To distinguish
between data and OAM cells, the PTI field is used as follows:
PTI=100 (4) Segment OAM F5 cells processed by the next segment.
PTI=101 (5) End-to-end OAM F5 cells which are only processed by end stations terminating an ATM link.
RM Cells
There are two types of Rate Management (RM) cells: RM-VPC, which manages the VP level and RM-VCC,
which manages the VC level.
The format of RM-VPC cells is shown in the following illustration:
ATM Header: VCI=6 and PTI=110 (5 bytes)

RM protocol identifier (1 byte)
Message type (1 byte)

ER (2 bytes)
CCR (2 bytes)
MCR (2 bytes)
QL (4 bytes)
SN (4 bytes)
Reserved (30 bytes)
Reserved (6 bits) + CRC-10 (10 bits)
RM-VPC cell format
RM protocol identifier
Always 1 for ABR services.
Message type
This field is comprised of several bit fields:
Bit Name
Description
8
7
6
5
4
Direction of the RM cells: 0=forward, 1=backward.

BECN: 0=source is generated; 1=network is generated.
Congestion Indication: 0=no congestion, 1=congestion.
No increase: 1=do not increase the ACR.
Not used.
DIR
BN
CI
NI
RA
ER
Explicit rate.
CCR
Current cell rate.
MCR
Minimum cell rate.
QL
Not used.
SN
Not used.
RM-VCC cells are exactly the same as RM-VPC cells, except that the VCI is not specified. The cell is
identified solely by the PTI bits.
Reserved VPI/VCI Values

A number of VPI/VCI values are reserved for various protocols or functions, e.g., 0,5 is used for signalling
messages. The following table contains a list of all reserved VPI/VCI values and their designated meanings:
VPI
VCI
Description
Idle cells. Must also have GFC set to zero. Idle cells are added by the
transmitter to generate information for non-used cells. They are removed
by the receiver together with bad cells.
Meta signalling (default). Meta-signalling is used to define the subchannel

for signalling (default value: 0,5).
Non-zero 1
Meta signalling .
General broadcast signalling (default). Can be used to broadcast

signalling information which is independent of a specific service. Not used
in practice.
Non-zero 2
General broadcast signalling.
Point-to-point signalling (default). Generally used to set-up and release

switched virtual circuits (SVCs).
Non-zero 5
Point-to-point signalling.
Segment OAM F4 flow cell. OAM cells are used for continuity checks as
well as to notify and acknowledge failures.
End-to-end OAM F4 flow cell.
RM-VPC cells for rate management.
15
SPANS . The Simple Protocol for ATM Network Signalling is a simple

signalling protocol, developed by FORE systems and used by FORE and
other manufacturers working in cooperation with FORE, for use in ATM
networks. Refer to Chapter 3 for more information.
16
ILMI . The Interim Local Management Interface is used to manage and

compare databases across an ATM link. This is used for signalling
address registration, RMON applications, SNMP, etc. Refer to ILMI in
this book for more information.
18
PNNI signalling .
SSSAR
http://www.itu.int/ITU-T/ ITU-T RECOMMENDATION I.366.1.
The Segmentation and Reassembly Service Specific Convergence sublayer of the ATM Adaptation Layer
(AAL) type 2 (SSSAR) allows bandwidth-efficient transmission of low-rate, short, and variable length packets
in delay sensitive applications. The Segmentation and Reassembly Service Specific Convergence sublayer
may be deployed on one or more AAL type 2 user information streams. The SSSAR protocol defines the
sublayer structure and the procedures for the segmentation and reassembly process, as well as the optional
transmission error detection and assured data transfer.
With this Segmentation and Reassembly Service Specific Convergence sublayer applied for a Service
Specific Convergence sublayer for the AAL type 2, it is possible to transport a packet size of more than the
maximum length specified in the CPS and also to multiplex with low-rate and short length packets in delay
sensitive application.
The Segmentation and Reassembly Service Specific Convergence sublayer is subdivided into the Service
Specific Segmentation and Reassembly sublayer (SSSAR), the Service specific Transmission Error
Detection sublayer (SSTED), and the Service Specific Assured Data Transfer sublayer (SSADT). The
protocol header structure is as follows:
Format of the SSSAR-PDU :

UUI
MSB LSB
SSSAR-PDU Payload
CPS-Packet Header (CPS-PH)
CPS-Packet Payload (CPS-PP)
<------------------------------------>
<---------------------------------------------->
Format of the SSTED-PDU:

SSTED-PDU
Trailer
SSTED-PDU payload (SSTED-SDU)

SSTED-PDU
SSTEDC L
Reserved
UU
I P
Length
CRC
SSTED-PDU Trailer
CI-Congestion Indication (1 bit)
CRC-Cyclic Redundancy Check (4 octets)
Length-Length of SSTED-SDU (2 octets)
LP-Loss Priorit y (1 bit)
Reserved-Reserved Field (set to zero) (6 bits)
SSTED-UU-SSTED User-to-User indication (1 octet)
SSTED User-to-User indication (SSTED-UU) field

The CPCS-UU field is used to transparently transfer CPCS user-to-user information.
Congestion Indication (CI)

This field is provided for compatibility with the service of the CPCS of the AAL type 5. It is transported
transparently from the user of the transmitter to the user of receiver.
Loss Priority (LP)

This field is provided for compatibility with the service of the CPCS of the AAL type 5. It is transported
transparently from the user of the transmitter to the user of receiver.
Length field
The Length field is used to encode the length of the SSTED-PDU payload field. The Length field value is
also used by the receiver to detect the loss or gain of information. The length is binary encoded as number
of octets. The Length field value of "0" is used to indicate that the received SSTED-PDU is to be aborted.
CRC field
The CRC-32 is used to detect bit errors in the SSTED-PDU.

UMTS Family

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UMTS Family

Enviado por

Direitos autorais:

Formatos disponíveis

UMTS Family

6.7 kbps mode as PDC-EFR

different comfort noise frames, or an empty frame.

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

Broadcast call establishment procedures,

All messages have the following header:

BCC header structure

Storage of Cell Broadcast Messages.

to each other through Service Access Points (SAPs).

Between BMC and upper layer (U-plane):

Between BMC and the RRC entity:

Coding of message types:

BSSAP+ header structure

Each message type has specific information elements

IMSI. VLR number.

Unassigned: treated as an unknown IEI.

Mobile originated and forwarded calls

Call establishment procedures

Call clearing procedures

Transport of TBS across Iub and Iur interface.

The transport layer must deliver Frame Protocol PDUs.

General structure of a Frame Protocol PDU

UL Data Frame Header

TFI of first DCH

TFI of last DCH

DL Data Frame Header

TFI of first DCH

TFI of last DCH

TFI of first/last DCH

Group call establishment procedures

All messages have the following header:

GCC header structure

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

GMM header structure

GSM header structure

GTP header structure

MCC, MNC, MSIN digits

Unacknowledged peer-to-peer operation.

PDU Type (=0)

IUup PDU Type 0 Format

TheIuUP PDU Type 0 is made of three parts:

IuUP Frame Control part (fixed size);

PDU Type (=1)

IUup PDU Type 1Format

TheIuUP PDU Type 1 is made of three parts:

IuUP Frame Control part (fixed size);

PDU Type (=14)

Ack/Nack (=0, PDU Type 14

IUup Mode version

Reserved for procedure data

IUup PDU Type 14 Format for procedure sending

IuUP Frame Control part (fixed size);

Paging channel (PCH)

Reserved(PDUs with this coding will be discarded by this version of

Update Location, Cancel Location, PurgeMS, Send Identification

Illegal Equipment, Bearer Service Not Provisioned,

Signalling message handling; and

The MTP-3B protocol structure appears as follows:

Sub Service Indicator

The structure is the same as IuUP.

PDU Type (=0)

NbUP PDU Type 0 Format

The NbUP PDU Type 0 is made of three parts:

NbUP Frame Control part (fixed size);