04 CN3203EN01GLN01 Iu-PS Interface 1

PCN Signaling
Iu-PS Interface
Training Document
Iu-PS Interface
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This document is intended for the
use of Nokia's customers only for the purposes of the agreement under which the document is
submitted, and no part of it may be reproduced or transmitted in any form or means without
the prior written permission of Nokia. The document has been prepared to be used by
professional and properly trained personnel, and the customer assumes full responsibility
when using it. Nokia welcomes customer comments as part of the process of continuous
development and improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or
performance of the mentioned hardware or software products cannot be considered binding
but shall be defined in the agreement made between Nokia and the customer. However,
Nokia has made all reasonable efforts to ensure that the instructions contained in the
document are adequate and free of material errors and omissions. Nokia will, if necessary,
explain issues which may not be covered by the document.
Nokia's liability for any errors in the document is limited to the documentary correction of
errors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS
DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING
MONETARY LOSSES), that might arise from the use of this document or the information in it.
This document and the product it describes are considered protected by copyright according
to the applicable laws.
NOKIA logo is a registered trademark of Nokia Oyj.
Other product names mentioned in this document may be trademarks of their respective
companies, and they are mentioned for identification purposes only.
Copyright © Nokia Oyj 2009. All rights reserved.
2 (161)
Contents
Contents
2 Objectives....................................................................................4
3 Introduction.................................................................................5
4 Iu-PS Control Plane ....................................................................6

4.1.1 Iu-PS Over ATM Control Plane.....................................................7
4.1.2 Iu-PS Over IP Control Plane.........................................................9
4.2 3G-SGSN-UE Control Plane.......................................................12
4.3 Example of the message flow on Iu-PS Control Plane: ..............14
4.4 SCCP..........................................................................................16
4.4.1 Signalling connection control part messages: ............................16
4.4.2 SCCP Sub fields .........................................................................22
4.5 RANAP .......................................................................................25
4.5.1 Functions ....................................................................................25
4.5.2 RANAP Procedures ....................................................................25
4.6 Mobility Management Procedures (MM, GSM L3)......................60
4.6.1 The Attach Procedure.................................................................62
4.6.2 Service Request Procedure........................................................73
4.7 Session Management Procedures (SM, GSM L3)......................78
4.7.1 PDP Context Activation Procedure in detail ...............................79
4.7.2 PDP Context Activation Response .............................................91
5 Iu-PS User Plane .......................................................................93

5.1 IuPS User Plane Protocol Stack .................................................95
5.1.1 UDP/IP........................................................................................95
5.1.1.1 UDP Header ...............................................................................95
5.1.1.2 IP Header....................................................................................96
5.1.2 GTP-U.........................................................................................97
5.1.2.1 GTP-U Protocol Entity ................................................................98
5.1.2.2 Protocol Stack.............................................................................98
5.2 Iu UP Protocol Layer.................................................................100
5.2.1 Iu UP protocol modes of operation ...........................................101
5.3 GTP-U Message .......................................................................104
6 SGSN SG6.0 Iu over IP ...........................................................106

6.1.1 SGSN SG6.0 Iu over IP Control Plane and User Plane
stacks........................................................................................106
6.1.2 Iu over IP Control Plane SIGTRAN protocols ...........................107
6.1.3 Stream Control Transmission Protocol (SCTP) ........................107
6.1.4 MTP3 User Adaptation Layer (M3UA) ......................................110
6.1.5 SGSN SG6.0 Iu over IP Control Plane signalling
messages .................................................................................110
3 (161)
Iu-PS Interface
2 Objectives
After this module the student will be able to:
 Describe the main functions of RANAP signalling protocols in Iu-PS
interface
 Explain the Attach procedure in the Iu-PS interface
 Explain the PDP Context Activation procedure in the Iu-PS interface
 Describe the main Function of GTP-U in Iu-PS
4 (161)
Contents
3 Introduction
The Iu interface connects the UTRAN or GERAN and the Core Network packet
domains allowing the exchange of signalling information and user data. The
user plane of the Iu interface shall allow user data from many users to be
multiplexed over the same physical resource. Resources are given to a user
upon activity (when data is sent or received) and are reallocated immediately
thereafter.
In UMTS only user data is transmitted on this shared physical medium.
Signalling data is transferred via an SCCP connection. A reference
configuration for the Iu interface control and user plane is given in Figure 1.
3G SGSN
Figure 1: Protocol stack in Iu-PS Interface
5 (161)
Iu-PS Interface
4 Iu-PS Control Plane

The protocol stack for the Iu-PS Control Plane is shown in figure 2. The
standard allows operators to choose one out of two standardised protocol suites
for transport of SCCP messages.
Iu-PS Control Plane
RANAP
SCCP-SAP
SCCP
M3UA MTP-3b
SCTP SSCF
SSCOP SAAL-NNI
IP
AAL5
L2 ATM
Figure 2: SAP between RANAP and its transport for the Iu-PS Control Plane
Figure 2 shows, for the Iu-PS Control Plane, the point at which the service
primitives are invoked. A single SAP is defined independently of the signalling
bearer. The SAP provides the SCCP primitives. The figure is not intended to
constrain the architecture.
6 (161)
Contents
4.1.1 Iu-PS Over ATM Control Plane
Figure 3: Iu-PS Over ATM Control Plane Protocol Stacks
1. SCCP (ITU-T Rec. Q.711 (07/1996)) The SCCP protocol offers direct
signalling connections (Layer 3 Session and Mobility Management) for
each active UE. The SCCP connections are used to differentiate the
signalling transactions between different subscribers. It provides
connectionless service, class 0, connection oriented service, class 2,
separation of the connections mobile by mobile basis on the connection
oriented link and establishment of a connection oriented link mobile by
mobile basis.
2. MTP-3b (ITU-T Rec. Q.2210 (07/1996)) The MTP-3b protocol is used
to transport the Signalling Connection Control Part (SCCP) packets over
several parallel signalling links, if one of the signalling links fails,
MTP-3b layer directs the traffic to the remaining links. It provides
message routing, discrimination and distribution (for point-to-point link
only), signalling link management load sharing and changeover/back
between links within one link-set. The need for multiple link-sets is
precluded.
7 (161)
Iu-PS Interface
3. SAAL-NNI (ITU-T Rec. Q.2100 (07/1994)) consists of the following

sub-layers: - SSCF-NNI (ITU-T Rec. Q.2140 (02/1995)) - SSCOP (ITU-
T Rec. Q.2110 (07/1994)) and – AAL5. (ITU-T Rec. I.363.5 (08/1996)).
Broadband SS7 has built-in protection features. The Service Specific
Connection Oriented Protocol (SSCOP) is used over the ATM PVC to
monitor the operation of one signalling link. SAAL connection
management, link status and remote processor status mechanisms are
provided. SSCOP provides mechanisms for the establishment and release
of connections and the reliable exchange of signalling information
between signalling entities. Adapts the upper layer protocol to the
requirements of the Lower ATM cells.
The Service Specific Co-ordination Function (SSCF) protocol is a 'thin' sub-
layer that maps general signalling transport services provided by the
SSCOP to more simple services used by the MTP-3b layer.
The SSCF maps the requirements of the layer above to the requirements
of SSCOP.
Control plane protocol stack specify that low-level data is to be
assembled into ATM cells for transmission using the ATM Adaptation
Layer type 5 (AAL5) mechanisms. Data cells assembled by AAL5 are
carried over ATM Permanent Virtual Circuits (PVCs).
4. SAAL-NNI (ITU-T Rec. Q.2100 (07/1994)) consists of the following

sub-layers: - SSCF-NNI (ITU-T Rec. Q.2140 (02/1995)) - SSCOP
(ITU-T Rec. Q.2110 (07/1994)) and – AAL5. (ITU-T Rec. I.363.5
(08/1996)).
5. ATM (ITU-T Rec. I.361 (11/1995)).

ATM Permanent Virtual Circuits (PVCs) are configured on the network
connection between the 3G SGSN and the RNC. ATM PVCs are logical
point-to-point links between the 3G SGSN and the RNC.
The physical Iu-PS interface is implemented on the 3GSGSN and RNC
ATM units. The ATM interface card supports an STM-1 (155Mbps)
Single-Mode Fiber (SMF) interface. Logical connections within one
physical interface are based on PVCs configured permanently.
8 (161)
Contents
4.1.2 Iu-PS Over IP Control Plane
Figure 4: Iu-PS Over IP Control Plane Protocol Stacks
1. SCTP refers to the Stream Control Transmission Protocol ) is an Internet

Protocol (IP) transport protocol which provides transport layer functions
to many Internet-based applications. The SCTP layer is between the
SCTP user adaptation layer (for example M3UA) and a connectionless
packet network service such as IP. SCTP is connection oriented, that is, it
establishes a connection between two endpoints (SCTP association)
before transmitting the user data. SCTP is specified in RFC 2960 and
RFC 3309.
Basically, the SCTP offers a reliable transfer of user messages between
peer SCTP users. The following list explains the services the SCTP offers
to its users in more detail:
 Multi-homing: each SCTP endpoint is known by multiple IP
addresses. Routing to one address is independent of all others and, if
one route becomes unavailable, another will be used.
 Multi-streaming capability: data is split into multiple streams, each
stream with independent sequenced delivery.
 Reliable transport of user data - detecting when data is corrupt or out
of sequence.
 Application-level fragmentation and multiplexing of user datagrams.
9 (161)
Iu-PS Interface
 Initialisation procedure: based on cookies and used to prevent denial

of service attacks.
 Appropriate congestion avoidance behaviour and resistance to
flooding and masquerade attacks.
 Fast retransmission.
 Segmentation and bundling.
 Selective ACK.
 Initialisation procedure: based on cookies and used to prevent denial
of service attacks.
2. M3UA (RFC3332) M3UA refers to the SCCP adaptation layer ’SS7

MTP3 – User Adaptation Layer’ also developed by the SIGTRAN
working group.
MTP3 User Adaptation Layer (M3UA) defines a protocol for supporting the
transport of any Message Transfer Part Level 3 (MTP3) user signalling over
Internet Protocol (IP) using the services of Stream Control Transmission
Protocol (SCTP). It handles the MTP level 3 functions and services in the IP
network.
M3UA sets up associations between signalling endpoints so that when one
association breaks up it does not stop all the traffic between the endpoints.
M3UA does network address translation and mapping for ongoing routing to
the final IP destination.
M3UA was designed to support fault tolerance and load sharing. Fault
tolerance is provided using many IP Server Processes (IPSPs) or M3UA
instances, which provide the services at the same time. If a local M3UA
instance fails, the Signalling Connection Control Part (SCCP) service
provider and the remote node (IPSP instance) diverts the traffic to the
remaining active instances.
M3UA is specified in RFC 3332.
3. IP Sub-Network shall use the Internet Protocol (IP) as defined in either

RFC 791 or RFC 2460
The Internet Protocol (IP) is the most widely used internetworking layer
protocol though it provides an unreliable, connectionless delivery service. IP
is unreliable because it does not guarantee the delivery of packets and is
therefore referred to as "best effort" system. The IP layer does not worry
about packets being lost, delayed, duplicated, and so on. It is up to the higher
layers to deal with those problems. In addition, the IP layer provides a
connectionless service since neither a physical nor virtual circuit is
established between a sender and a receiver. It provides a packet switched,
datagram delivery service.
The main functions performed by the IP layer are:
10 (161)
Contents
 Packaging transport layer PDUs (T-PDU) into IP packets.

 Routing packets to the destination.
 Fragmentation and reassembly (if necessary) based on the maximum
transfer unit (MTU) of the data link layer.
 Datagram lifetime checking to remove packets that are lost.
 Error control on the packet header.
 Delivering packets to the appropriate higher layer at the receiver.
4. L2 Network is built using Ethernet technology.

The physical interface is based on the 10/100BaseTX Ethernet interface card.
The control and user plane traffic do not need to use the same physical
Ethernet interface.
11 (161)
Iu-PS Interface
4.2 3G-SGSN-UE Control Plane
UE Uu RNC Iu-PS 3G SGSN
Figure 5: 3G-SGSN – UE Control Plane Protocol Stack
GMM/SM/SMS The Layer 3 Session and Mobility Management (L3-SMM)

signalling between the UE and the SGSN transports the messages concerning
the Mobility Management and Session Management. SMS delivery is also
performed via the same signalling.
RANAP The Radio Access Network Application Protocol is the signalling

protocol between the 3G SGSN and RNC. These network elements use it to
manage the user connections and the usage of resources on the Iu interface.
Therefore, RANAP provides the 3G SGSN with the means to create GTP
tunnels and request and reserve resources in the Radio Access Network.
RANAP also facilitates the transmission of 3G SGSN-UE signalling messages.
RRC The Radio Resource Control manages the physical layer and its activities
whenever required. For instance, if a radio link is to set up, the RRC layer
commands to perform this activity, command is delivered through RLC to the
MAC and MAC performs this activity and finally, the radio link set up is
carried through the Layer 1.
12 (161)
Contents
RLC The functionality of the Radio Link Control is similar than in “normal”
Layer 2. This means mainly flow control related activities like for instance data
block sequencing.
MAC The Medium Access Control physically implements radio link
management, i.e. radio link set-up, maintaining, physical radio channel
configuration, error protection, encryption and radio link deletion.
L1 The physical layer (Layer 1) of the Uu interface (Air interface) is
implemented with WCDMA technology and either FDD or TDD variant can be
used.
SCCP The Signalling Connection Control Part protocol offers direct signalling
connections (Layer 3 Session and Mobility Management) for each active UE.
The SCCP connections are used to differentiate the signalling transactions
between different subscribers. It provides connectionless service, class 0,
connection oriented service, class 2, separation of the connections mobile by
mobile basis on the connection oriented link and establishment of a connection
oriented link mobile by mobile basis.
13 (161)
Iu-PS Interface
4.3 Examples of the message flow on Iu-PS Control

Plane:
UE BS RNC SGSN HLR
RRC: INITIAL DIRECT TRANSFER (Attach Request)

Follow On Request NOT Pending
SCCP CR: RANAP: INITIAL UE MESSAGE (Attach Request)

Follow On Request NOT Pending
Update Location
Insert Subscriber Data
Ack
Update Location Ack
SCCP CC
RANAP: DT (Attach Accept)
RRC: DL DT (Attach Accept)
RRC: UL DT (Attach Complete)
RANAP: DT (Attach Complete)
“Follow-on request” NOT set to pending in Attach Request, thus SGSN will release Iu
(and RNC the RRC connection) – continued on next page
Figure 6: Example of the message flow on Iu-PS Control Plane
14 (161)
Contents
Iu-PS over ATM - Attach Procedure message flow:
Iu-PS over ATM - Routing Area Update Procedure message flow:
Iu-PS over ATM - PDP Context Activation Procedure message flow:
Iu-PS over ATM - Service Request Procedure message flow:
15 (161)
Iu-PS Interface
4.4 SCCP
4.4.1 Signalling connection control part messages:
The SCCP protocol offers direct signaling connections (Layer 3 Session and
Mobility Management) for each active UE. The SCCP connections are used to
differentiate the signalling transactions between different subscribers.
There is always an SCCP connection for a user actively transmitting and/or

receiving data. A user can also have an SCCP connection when no data delivery
is activated. RANAP uses the connection-oriented SCCP service for a user
signalling connection set-up (ex. the GPRS Attach procedure).
RANAP uses connectionless SCCP delivery for element related connectionless
messages (ex. the Paging procedure).
Services provided by the SCCP
Connectionless Connection-oriented
Services Services
Protocol Class 0 1 2 3
Basic Flow Control
Basic Sequenced
Connection- Connection-
Connectionless Connectionless
oriented oriented
Service Service
Service Service
Figure 7: SCCP Services
SCCP provides control of logical signalling connections in a SS7 network.

In the Iu-PS interface the user signalling messages concerning signalling
procedures are identifyied and matched using the "Destination Local Reference"
and the "Source Local Reference" parameter values specifyied at the SCCP
protocol layer:
 In the Attach Request message (from RNC to 3G SGSN) the SCCP "Source
Local Reference" parameter value is a unique user SCCP signalling
transaction identifier which is equal to the SCCP “Destination Local
Reference” parameter value in the Attach Accept Message (from 3G SGSN
to RNC).
 In the Attach Accept message (from 3G SGSN to RNC) the SCCP "Source
Local Reference" parameter value is a unique user SCCP signalling
transaction identifier which is equal to the SCCP “Destination Local
16 (161)
Contents
Reference” parameter value in the Attach Complete Message (from RNC to

3G SGSN).
 In the Activate PDP Context Request message (from RNC to 3G SGSN) the
SCCP “Destination Local Reference” parameter value is a unique user
SCCP signalling transaction identifier which is equal to the SCCP
“Destination Local Reference” parameter value in the Attach Complete
Message (from RNC to 3GSGSN).
 In the Activate PDP Context Accept message (from 3G SGSN to RNC) the
SCCP “Destination Local Reference” parameter value is a unique user
SCCP signalling transaction identifier which is equal to the SCCP
“Destination Local Reference” parameter value in the Attach Accept
Message (from 3G SGSN to RNC).
The Signalling Connection Control Part (SCCP) messages are used by the peer-
to-peer protocol. All messages are uniquely identified by means of a message
type code, which is to be found in all the messages. The meaning and definition
of the various parameter fields contained in these messages are specified in
clause 2. The actual inclusion of these parameter fields in a given message
depends on the class of protocol and is specified in clause 3.
4.4.1.1 connection confirm (CC):

A Connection Confirm message is initiated by the called SCCP to indicate to
the calling SCCP that it has performed the set-up of the signalling connection.
On reception of a Connection Confirm message, the calling SCCP completes
the set-up of the signalling connection, if possible. It is used during connection
establishment phase by connection-oriented protocol class 2 or 3.
4.4.1.2 connection request (CR):

A Connection Request message is initiated by a calling SCCP to a called SCCP
to request the setting up of a signalling connection between the two entities. The
required characteristics of the signalling connection are carried in various
parameter fields. On reception of a Connection Request message, the called
SCCP initiates the set-up of the signalling connection, if possible. It is used
during connection establishment phase by connection-oriented protocol class 2
or 3.
4.4.1.3 connection refused (CREF):

A Connection Refused message is initiated by the called SCCP or an
intermediate node SCCP to indicate to the calling SCCP that the set-up of the
signalling connection has been refused. It is used during connection
establishment phase by connection-oriented protocol class 2 or 3.
17 (161)
Iu-PS Interface
4.4.1.4 data acknowledgement (AK):

A Data Acknowledgement message is used to control the window flow control
mechanism, which has been selected for the data transfer phase. It is used
during the data transfer phase in protocol class 3.
4.4.1.5 data form 1 (DT1):

A Data Form 1 message is sent by either end of a signalling connection to pass
transparently SCCP user data between two SCCP nodes. It is used during the
data transfer phase in protocol class 2 only.
4.4.1.6 data form 2 (DT2):

A Data Form 2 message is sent by either end of a signalling connection to pass
transparently SCCP user data between two SCCP nodes and to acknowledge
messages flowing in the other direction. It is used during the data transfer phase
in protocol class 3 only.
4.4.1.7 expedited data (ED):

An Expedited Data message functions as a Data Form 2 message but includes
the ability to bypass the flow control mechanism which has been selected for
the data transfer phase. It may be sent by either end of the signalling connection.
It is used during the data transfer phase in protocol class 3 only.
4.4.1.8 expedited data acknowledgement (EA):

An Expedited Data Acknowledgement message is used to acknowledge an
Expedited Data message. Every ED message has to be acknowledged by an EA
message before another ED message may be sent. It is used during the data
transfer phase in protocol class 3 only.
4.4.1.9 inactivity test (IT):

An Inactivity Test message may be sent periodically by either end of a
signalling connection section to check if this signalling connection is active at
both ends, and to audit the consistency of connection data at both ends. It is
used in protocol classes 2 and 3.
4.4.1.10 protocol data unit error (ERR):

A Protocol Data Unit Error message is sent on detection of any protocol errors.
It is used during the data transfer phase in protocol classes 2 and 3.
4.4.1.11 released (RLSD):

A Released message is sent, in the forward or backward direction, to indicate
that the sending SCCP wants to release a signalling connection and the
associated resources at the sending SCCP have been brought into the disconnect
pending condition. It also indicates that the receiving node should release the
connection and any other associated resources as well. It is used during
connection release phase in protocol classes 2 and 3.
18 (161)
Contents
4.4.1.12 release complete (RLC):

A Release Complete message is sent in response to the Released message
indicating that the Released message has been received, and the
appropriate procedures have been completed. It is used during connection
release phase in protocol classes 2 and 3.
4.4.1.13 reset confirm (RSC):

A Reset Confirm message is sent in response to a Reset Request message to
indicate that Reset Request has been received and the appropriate procedure has
been completed. It is used during the data transfer phase in protocol class 3.
4.4.1.14 reset request (RSR):

A Reset Request message is sent to indicate that the sending SCCP wants to
initiate a reset procedure (re-initialisation of sequence numbers) with the
receiving SCCP. It is used during the data transfer phase in protocol class 3.
4.4.1.15 subsystem-allowed (SSA):

A Subsystem-Allowed message is sent to concerned destinations to inform those
destinations that a subsystem which was formerly prohibited is now allowed or
that a SCCP which was formerly unavailable is now available. It is used for
SCCP management.
4.4.1.16 subsystem-out-of-service-grant (SOG):

A Subsystem-Out-of-Service-Grant message is sent, in response to a Subsystem-
Out-of-Service-Request message, to the requesting SCCP if both the requested
SCCP and the backup of the affected subsystem agree to the request. It is used
for SCCP subsystem management.
4.4.1.17 subsystem-out-of-service-request (SOR):

A Subsystem-Out-of-Service-Request message is used to allow subsystems to go
out-of-service without degrading performance of the network. When a
subsystem wishes to go out-of-service, the request is transferred by means of a
Subsystem-Out-of-Service-Request message between the SCCP at the
subsystem’s node and the SCCP at the duplicate subsystems, node. It is used for
SCCP subsystem management.
4.4.1.18 subsystem-prohibited (SSP):

A Subsystem-Prohibited message is sent to concerned destinations to inform
SCCP Management (SCMG) at those destinations of the failure of a subsystem.
It is used for SCCP subsystem management.
4.4.1.19 subsystem-status-test (SST):

A Subsystem-Status-Test message is sent to verify the status of a subsystem
marked prohibited or the status of an SCCP marked unavailable. It is used for
SCCP management.
19 (161)
Iu-PS Interface
4.4.1.20 unitdata (UDT):

A Unitdata message can be used by an SCCP wanting to send data in a
connectionless mode. It is used in connectionless protocol classes 0 and 1.
4.4.1.21 unitdata service (UDTS):

A Unitdata Service message is used to indicate to the originating SCCP that a
UDT sent cannot be delivered to its destination. Exceptionally and subject to
protocol interworking considerations, a UDTS might equally be used in
response to an XUDT or LUDT message. A UDTS message is sent only when
the option field in that UDT is set to “return on error”. It is used in
connectionless protocol classes 0 and 1.
4.4.1.22 extended unitdata (XUDT):

An Extended Unitdata message is used by the SCCP wanting to send data
(along with optional parameters) in a connectionless mode. It is used in
4.4.1.23 extended unitdata service (XUDTS):

An Extended Unitdata Service message is used to indicate to the originating
SCCP that an XUDT cannot be delivered to its destination. Exceptionally and
subject to protocol interworking considerations, an XUDTS might equally be
used in response to a UDT or LUDT message. An XUDTS message is sent only
when the return message on error option in the XUDT (or possibly LUDT) is
set. It is used in connectionless protocol classes 0 and 1.
4.4.1.24 subsystem congested (SSC):

A Subsystem Congested message is sent by an SCCP node when it experiences
congestion.
4.4.1.25 long unitdata (LUDT):

A Long Unitdata message is used by the SCCP to send data (along with
optional parameters) in a connectionless mode. When MTP capabilities
according to Recommendation Q.2210 are present, it allows sending of NSDU
sizes up to 3952 octets without segmentation. It is used in Connectionless
protocol classes 0 and 1.
4.4.1.26 long unitdata service (LUDTS):

A Long Unitdata Service message is used to indicate to the originating SCCP
that an LUDT cannot be delivered to its destination. An LUDTS message is sent
only when the return message on error option in the LUDT is set. It is used in
Example of SCCP Messages:
CR - CONNECTION REQUEST
Source Local Reference
20 (161)
Contents
- 61F144h
Protocol Class
- 2h, connection oriented
Called Party Address
- length 2 (02h)
- no global title present
- routing based on SSN and MTP routing label
- subsystem: RANAP
Calling Party Address
- length 4 (04h)
- point code : 4144 (1030h)
- subsystem: RANAP
SCCP User Data
- length: 97 (61h)
- data :
00 13 40 5D 00 00 07 00 03 40 01 80 00 0F 40 06 00 32 F4 02 00 05 00 37
40 01 02 00 3A 40 08 00 32 F4 02 00 05 00 A2 00 10 40 26 25 08 01 02 E5
00 79 07 02 05 F4 38 A9 05 5A 32 F4 02 00 05 02 0A 14 F3 82 33 4C 03 26
3C A0 60 19 63 92 B6 17 16 00 4F 40 03 01 61 01 00 56 40 05 32 F4 02 00
01
End of Optional Parameters
CC - CONNECTION CONFIRM
Destination Local Reference
- 61F144h
- 040000h
Protocol Class
- length 4 (04h)
- point code : 4144 (1030h)
- subsystem: RANAP
RLSD - RELEASED
- 61F144h
- 040000h
Release Cause
- end user originated
RLC - RELEASE COMPLETE

- 040000h
- 61F144h
21 (161)
Iu-PS Interface
4.4.2 SCCP Sub fields
In SCCP Messages, the following sub fields might be analysed in further detail:
4.4.2.1 affected point code:

The “affected point code” identifies a signalling point where the affected
subsystem or SCCP is located.
4.4.2.2 affected subsystem number:

The “affected subsystem number” parameter field identifies the SCCP or a
subsystem which is failed, withdrawn, congested or allowed. In the case of SST
messages, it also identifies the subsystem being audited. In the case of SOR or
SOG messages, it identifies a subsystem requesting to go out-of-service. The
SSN for SCMG is used to denote the SCCP as a whole in the SSA, SSC and
SST messages.
4.4.2.3 calling/called party address:

The “calling/called party address” parameter field, together with additional
information given by the MTP, contains enough information to uniquely
identify the origination/destination signalling point and/or the SCCP service
access point. It can be any combination of a global title (dialled digits, for
example), a signalling point code, and a subsystem number. The subsystem
number (SSN) identifies an SCCP user when provided. In order to allow the
interpretation of this address, it begins with an address indicator indicating
which information elements are present. The address indicator also includes a
routing indicator specifying if translation is required, and a global title indicator
specifying global title format. The “calling/called party address” parameter field
has two different meanings depending on whether it is included in a connection-
oriented or connectionless message. For a connection-oriented message, the
significance of these fields is related to the direction of the connection set-up
(i.e. independent of the direction the message is going). For a connectionless
message, the significance of these fields is dependent on the direction the
message is going (just as for OPC and DPC).
4.4.2.4 credit:
The “credit” parameter field is used in the acknowledgements to indicate to the
sender how many messages it may send, i.e. window size. It is also used in the
CR and CC message to indicate the proposed and selected credit, and in the IT
message to audit the consistency of this connection data at both ends of a
connection section.
4.4.2.5 data:
The “data” parameter field contains information coming from upper layers or
from SCCP management. In connectionless and connection-oriented messages
the “data” parameter field contains information coming from upper layers.
22 (161)
Contents
Information coming from SCCP management can be contained in the “data”

parameter field of a UDT or XUDT message. In this case the “data” parameter
field of the UDT/XUDT message will only contain the SCCP management
message.
4.4.2.6 diagnostic:
The “diagnostic” parameter field has been deleted.
4.4.2.7 error cause:
The “error cause” parameter field is used in the Protocol Data Unit Error
message in order to indicate what is the exact protocol error.
4.4.2.8 end of optional parameters:

The “end of optional parameters” parameter field is used in any message
containing optional parameters to indicate where the part allocated to these
optional parameters ends.
4.4.2.9 local reference number (source/destination):

The “local reference number (source/destination)” parameter field uniquely
identifies a signalling connection in a node. It is an internal working number
chosen by each node independently from the destination node. At least one local
reference number is to be found in any message exchanged on a signalling
connection section. NOTE – Remote reference number is used to reflect the
local reference number at the remote end of a connection section.
4.4.2.10 protocol class:

For connection-oriented protocol classes, the “protocol class” parameter field is
used during the connection establishment phase; it is negotiated between the
two end SCCP. It is also used during data transfer phase to audit the consistency
of this connection data at both ends of a connection section. For connectionless
protocol classes, the “protocol class” parameter field is used to indicate whether
or not a message should be returned on error occurrence, and to indicate
whether or not in-sequence delivery of message is required.
4.4.2.11 receive sequence number:

The “receive sequence number” parameter field P(R) is used in the data
acknowledgement message to indicate the lower edge of the receiving window.
It also indicates that at least all messages numbered up to and including P(R) - 1
are accepted.
4.4.2.12 refusal cause:

The “refusal cause” parameter field is used in a Connection Refused message to
indicate the reason why the connection set-up request was refused.
4.4.2.13 release cause:

The “release cause” parameter field is used in a Released message to indicate
the reason of the connection release.
23 (161)
Iu-PS Interface
4.4.2.14 reset cause:

The “reset cause” parameter field is used in a Reset Request message to indicate
the reason why a reset procedure is invoked.
4.4.2.15 return cause:

For connectionless protocol classes, the “return cause” parameter field is used to
indicate the reason why a message was returned.
4.4.2.16 segmenting/reassembling:
The “segmenting/reassembling” parameter field is used in the data message for
the segmenting and reassembling function. It is the more data indicator (M-bit).
This is used only in connection-oriented messages. It is set to one in a data
message to indicate that more data will follow in a subsequent message. It is set
to zero in a data message to indicate that the data in this message forms the end
of a complete data sequence.
4.4.2.17 sequencing/segmenting:
The “sequencing/segmenting” parameter field contains the information
necessary for the following functions: sequence numbering, flow control,
segmenting and reassembling.
4.4.2.18 subsystem multiplicity indicator:

The “subsystem multiplicity indicator” is used in SCCP management messages
to indicate the number of associated replicated subsystems. This parameter is
reserved for national use.
4.4.2.19 hop counter:

The “hop counter” parameter field is used in the CR, XUDT, XUDTS, LUDT
and LUDTS messages to detect excessively long routes at the SCCP layer.
4.4.2.20 segmentation:
The “segmentation” parameter field is used in the XUDT, XUDTS, LUDT and
LUDTS messages to indicate that a SCCP message has been segmented, or, in
case of the LUDT(S), that it may undergo segmenting at an MTP/MTP-3b
interworking node. The parameter also contains all the information necessary to
allow the correct reassembly of the message.
4.4.2.21 importance:
The “importance” parameter is an optional parameter transported in CR, CC,
RLSD, CREF, LUDT, LUDTS, XUDT and XUDTS messages. It gives SCCP
the ability to restrict messages based on their importance.
4.4.2.22 congestion level:

The “SCCP congestion level” parameter is included in the Subsystem Congested
message (SSC) to report the severity of the congestion referring to either the
whole SCCP node or to the local SCCP.
24 (161)
Contents
4.4.2.23 long data:

The “long data” parameter is a “data” parameter with a two octet length
indicator. It allows sending of up to 3952 octets in a single LUDT or LUDTS
message when MTP-3b capabilities are present. The information coming from
SCCP management can be contained in the “long data” parameter field of an
LUDT message. In this case, the “long data” parameter of the LUDT message
will only contain the SCCP management message.
4.5 RANAP
4.5.1 Functions
Radio Access Network Application Protocol (RANAP): This protocol

encapsulates and carries higher-layer signalling, handles signalling between the
3G SGSN and RAN, and manages the GTP connections on the Iu interface.
RANAP is specified in 3G TS 25.413. The layers below RANAP are defined in
3G TS 23.121.
It is the signalling protocol between the 3G SGSN and RNC. These network
elements use it to manage the user connections and the usage of resources on
the Iu interface. Therefore, RANAP provides the 3G SGSN with the means to
create GTP tunnels and request and reserve resources in the Radio Access
Network. RANAP also allows the transmission of 3G SGSN-UE signalling
messages.
The most important functions of RANAP are:
 Relocating the Serving RNC. This function facilitates the change of the
Serving RNC including the related Iu resources.
 Overall Radio Access Bearer (RAB) management. This function is
responsible for setting up, modifying and releasing RABs (for example,
PDP contexts).
 Paging the user. This function provides the 3G SGSN with the
capability to page the UE.
 Location reporting. This function is used for transferring the actual
location information from the RNC to the 3G SGSN.
 Reporting general error situations.
Messages are sent via the Signalling Connection Control Part (SCCP) in the
connection associated mode with dedicated resources.
A complete list of all RANAP functions is added as Appendix D to this

document.
4.5.2 RANAP Procedures

RANAP procedures are divided into three classes depending on the number of
possible response messages:
25 (161)
Iu-PS Interface
1. Class 1 procedures have exactly one response message.

2. Class 2 procedures have no response messages.
3. Class 3 procedures have at least one response message.
A complete list of all RANAP procedures is added as Appendix A to this
document.
4.5.2.1 Initial UE Message

The purpose of the Initial UE Message procedure is to establish an Iu signalling
connection between a CN domain and the RNC and to transfer the initial NAS-
PDU to the CN. The procedure uses connection-oriented signalling.
The figure below describes the Initial UE Message procedure.
Figure 8: Initial UE Message
INITIAL UE-MESSAGE
RANAP-PDU
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 19 RAC: '01'H
- padding: 00000 - contents
- contents - id: 58
- criticality: ignore - contents
- contents (in bits): 01 - criticality: ignore
initiatingMessage - contents (in bits): 01
- padding: 000000 - padding: 000000
- opentype length - - opentype length SAI
InitialUE-Message - preamble: 0
- extension flag: 0 - pLMNidentity: '32F403'H
- preamble: 0 - padding: 0000000
protocolIEs - contents
- padding: 000000 - lAC: '03EF'H
- length - contents
- id: 3 - sAC: 'EA62'H
- contents - contents
- criticality: ignore - id: 16
- contents (in bits): 01 - contents
- padding: 000000 - criticality: ignore
- opentype length - contents (in bits): 01
CN-DomainIndicator: ps-domain - padding: 000000
26 (161)
Contents
- contents (in bits): 1 - opentype length

- trailing bits: 0000000 NAS-PDU: '080C1605F42A00035B32022000'H
- id: 15 - length
- criticality: ignore - id: 79
- padding: 000000 - criticality: ignore
- opentype length - contents (in bits): 01
LAI - padding: 000000
- preamble: 0 - opentype length
- pLMNidentity: '32F403'H IuSignallingConnectionIdentifier:
- padding: 0000000 '000000011111011000000000'B
- lAC: '03EF'H - id: 86
- id: 55 - criticality: ignore
- contents - contents (in bits): 01
- criticality: ignore - padding: 000000
- contents (in bits): 01 - opentype length
- padding: 000000 GlobalRNC-ID
- opentype length - pLMNidentity: '32F403'H
- contents
- rNC-ID: 3007
- contents
27 (161)
Iu-PS Interface
4.5.2.2 Direct Transfer

The purpose of the Direct Transfer procedure is to carry UE -
CN signalling messages over the Iu interface. The UE - CN
signalling messages are not interpreted by the UTRAN. The
UE - CN signalling messages are transported as parameters in
the DIRECT TRANSFER messages. The procedure uses
connection-oriented signalling.
CN originated Direct Transfer
The figure below describes the CN originated Direct Transfer procedure.
Figure 9: CN originated Direct Transfer
DIRECT TRANSFER
RANAP-PDU
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 20 - contents (in bits): 01
- contents - opentype length
- criticality: ignore NAS-PDU: '8A47'H
- contents (in bits): 01 - length
initiatingMessage - contents
- padding: 000000 - id: 59
- opentype length - contents
DirectTransfer - criticality: ignore
- extension flag: 0 - contents (in bits): 01
- preamble: 0 - padding: 000000
protocolIEs - opentype length
- padding: 000000 SAPI: sapi-0
- length - extension range: 0
- id: 16 - contents (in bits): 0
- contents - trailing bits: 000000
- criticality: ignore
28 (161)
Contents
UTRAN originated Direct Transfer
The figure below describes the UTRAN originated Direct Transfer procedure.
Figure 10:Utran Initiated Direct Transfer Procedure
DIRECT TRANSFER
RANAP-PDU
- extension flag: 0
- choice index: 00 LAI
initiatingMessage - preamble: 0
- procedureCode: 20 - pLMNidentity: '32F403'H
- criticality: ignore - lAC: '03EF'H
initiatingMessage - id: 55
- opentype length - criticality: ignore
DirectTransfer - contents (in bits): 01
- extension flag: 0 - padding: 000000
- preamble: 0 - opentype length
protocolIEs RAC: '01'H
- length - id: 58
- id: 16 - contents
- contents - criticality: ignore
- criticality: ignore - contents (in bits): 01
- contents (in bits): 01 - padding: 000000
- padding: 000000 - opentype length
- opentype length SAI
NAS-PDU: '0A4624'H - preamble: 0
- length - pLMNidentity: '32F403'H
- contents - padding: 0000000
- id: 15 - contents
- contents - lAC: '03EF'H
- criticality: ignore - contents
- contents (in bits): 01 - sAC: 'EA62'H
- opentype length
29 (161)
Iu-PS Interface
4.5.2.3 RAB Assignment

The purpose of the RAB Assignment procedure is to set up, modify or release
Radio Access Bearers (RABs) from the mobile to the Nokia 3G SGSN.
The CN shall initiate the procedure by sending a RAB ASSIGNMENT
REQUEST message. When sending the RAB ASSIGNMENT REQUEST
message, the CN shall start the T RABAssgt timer.
The CN may request UTRAN to:

- establish,
- modify,
- release
one or several RABs with one RAB ASSIGNMENT REQUEST message.
The CN shall include in the RAB ASSIGNMENT REQUEST message at least
one request to either establish/modify or release a RAB.
The procedure uses connection-oriented signalling. The figure below describes

the RAB Assignment procedure.
RNC CN
RAB ASSIGNMENT
REQUEST
RAB ASSIGNMENT
RESPONSE
.
.
.
*
* it can be several responses
Figure 11: RAB Assignment procedure
 Due to Network Layer Service Access Point Identifier (NSAPI)

restrictions (see UMTS 25.413 for details), the Nokia 3G SGSN, Release
2 supports eleven simultaneous RABs per MS.
 QoS parameters are supported according to UMTS 23.107.
30 (161)
Contents
 SDU parameters: one sub-flow is always used, the SDU Information

parameter is never included.
 Queuing RABs is never allowed.
 Pre-emption Capability is always set to _Shall not trigger pre-emption.
 Pre-emption Vulnerability is always set to _Pre-emptable_.
 Relocation Requirement is always set to ‘None’.
 NAS Synchronisation Indicator is never included in a RAB
ASSIGNMENT message.
 Service Handover: RT contexts (traffic class: streaming or
conversational) are always set to 'Shall not be handed over to GSM', NRT
contexts (traffic class: interactive or background) are always set to
'Should not be handed over to GSM'.
 User Plane Mode is always set to 'Transparent Mode'.
 IP addresses from the SGSN side are always IPv4 addresses.
 Data volume reporting is never required.
 Only IP is allowed as the PDP type.
Upon reception of the RAB ASSIGNMENT REQUEST message UTRAN shall

execute the requested RAB configuration.
The same RAB ID shall only be present once in the whole RAB
ASSIGNMENT REQUEST message.
The RAB ID shall identify uniquely the RAB for the specific CN domain for
the particular UE, which makes the RAB ID unique over the Iu connection on
which the RAB ASSIGNMENT REQUEST message is received. When a RAB
ID already in use over that particular Iu instance is used, the procedure is
considered as modification of that RAB.
The RNC shall pass the contents of RAB ID IE to the radio interface protocol
for each RAB requested to establish or modify.
The RNC shall establish or modify the resources according to the values of the
Allocation/Retention Priority IE (priority level, pre-emption indicators,
queuing) and the resource situation as follows:
- The RNC shall consider the priority level of the requested RAB, when
deciding on the resource allocation.
- If the requested RAB is allowed for queuing and the resource situation so
requires, RNC may place the RAB in the establishment queue.
- The priority levels and the pre-emption indicators may (singularly or in
combination) be used to determine whether the RAB assignment has to be
performed unconditionally and immediately. If the requested RAB is
marked as “may trigger pre-emption” and the resource situation so requires,
RNC may trigger the pre-emption procedure, which may then cause the
31 (161)
Iu-PS Interface
forced release of a lower priority RAB which is marked as “pre-emptable”.

Whilst the process and the extent of the pre-emption procedure is operator
dependent, the pre-emption indicators, if given in the RAB ASSIGNMENT
REQUEST message, shall be treated as follows:
1. The values of the last received Pre-emption Vulnerability IE and Priority
Level IE shall prevail.
2. If the Pre-emption Capability IE is set to “may trigger pre-emption”, then
this allocation request may trigger the pre-emption procedure.
3. If the Pre-emption Capability IE is set to “shall not trigger pre-emption”,
then this allocation request shall not trigger the pre-emption procedure.
4. If the Pre-emption Vulnerability IE is set to “pre-emptable”, then this
connection shall be included in the pre-emption process.
5. If the Pre-emption Vulnerability IE is set to “not pre-emptable”, then this
connection shall not be included in the pre-emption process.
6. If the Priority Level IE is set to “no priority” the given values for the Pre-
emption Capability IE and Pre-emption Vulnerability IE shall not be
considered. Instead the values “shall not trigger pre-emption” and “not pre-
emptable” shall prevail.
If the Allocation/Retention Priority IE is not given in the RAB ASSIGNMENT
REQUEST message, the allocation request shall not trigger the pre-emption
process and the connection may be pre-empted and considered to have the value
“lowest” as priority level. Moreover, queuing shall not be allowed.
The UTRAN pre-emption process shall keep the following rules:
1. UTRAN shall only pre-empt RABs with lower priority, in ascending order
of priority.
2. The pre-emption may be done for RABs belonging to the same UE or to
other UEs.
If the NAS Synchronisation Indicator IE is contained in the RAB
ASSIGNMENT REQUEST message, the RNC shall pass it to the radio
interface protocol for the transfer to the UE.
If the RAB ASSIGNMENT REQUEST message includes the PDP Type
Information IE, the UTRAN may use this to configure any compression
algorithms.
If the Service Handover IE is included, this tells if the RAB:
- should be handed over to GSM, i.e. from NAS point of view, the RAB
should be handed over to GSM as soon as possible although the final
decision whether to perform a handover to GSM is still made in UTRAN.
- should not be handed over to GSM, i.e. from NAS point of view, the RAB
should remain in UMTS as long as possible although the final decision
whether to perform a handover to GSM is still made in UTRAN.
32 (161)
Contents
- shall not be handed over to GSM, i.e. the RAB shall never be handed over
to GSM. This means that UTRAN shall not initiate handover to GSM for
the UE unless the RABs with this indication have first been released with
the normal release procedures.
The value of the Service Handover IE is valid throughout the lifetime of the
RAB or until changed by a RAB modification.
The Service Handover IE shall only influence decisions made regarding
UTRAN initiated inter-system handovers.
If the Service Handover IE is not included, the decision whether to perform an
inter-system handover to GSM is only an internal UTRAN matter.
UTRAN shall report to CN, in the first RAB ASSIGNMENT RESPONSE
message, the result for all the requested RABs, such as:
- List of RABs successfully established or modified.
- List of RABs released.
- List of RABs queued.
- List of RABs failed to establish or modify.
- List of RABs failed to release.
The same RAB ID shall only be present once in the whole RAB
ASSIGNMENT RESPONSE message.
For each RAB successfully established towards the PS domain, the RNC shall
include the Transport Layer Address IE and the Iu Transport Association IE in
the RAB ASSIGNMENT RESPONSE message.
For each RAB successfully modified or released towards the PS domain, for
which data volume reporting has been requested, the RNC shall include the DL
Data Volumes IE in the RAB ASSIGNMENT RESPONSE message.
For each RAB successfully released towards the PS domain, the RNC shall
include in the RAB ASSIGNMENT RESPONSE message, if available, the DL
GTP-PDU Sequence Number IE and the UL GTP-PDU Sequence Number IE, if
the release was initiated by UTRAN.
The RNC shall report in the RAB ASSIGNMENT RESPONSE message at least
one RAB:
set-up/modified or;
released or;
queued or;
failed to set-up/modify or;
failed to release.
For each RAB successfully modified towards the PS domain, if the RNC has
changed the Transport Layer Address IE and/or the Iu Transport Association
33 (161)
Iu-PS Interface
IE, it shall include the new value(s) in the RAB ASSIGNMENT RESPONSE
message.
Before reporting the successful outcome of a specific RAB to establish or
modify, the RNC shall have executed the initialisation of the user plane mode as
requested by the CN in the User Plane Mode IE. This initialisation is described
in 3GPP TS 25.415: “UTRAN Iu interface user plane protocols.
In case of establishment of a RAB for the PS domain, the CN must be prepared
to receive user data before the RAB ASSIGNMENT RESPONSE message has
been received.
If none of the RABs have been queued, the CN shall stop timer T RABAssgt. And
the RAB Assignment procedure terminates. In that case, the procedure shall
also be terminated in UTRAN.
When the request to establish or modify one or several RABs is put in the
queue, UTRAN shall start the timer TQUEUING. This timer specifies the maximum
time for queuing of the request of establishment or modification. The same
timer TQUEUING is supervising all RABs being queued.
For each RAB that is queued the following outcomes shall be possible:
- successfully established or modified;
- failed to establish or modify;
- failed due to expiry of the timer TQUEUING.
For the queued RABs, indicated in the first RAB ASSIGNMENT RESPONSE
message, UTRAN shall report the outcome of the queuing for every RAB
individually or for several RABs in subsequent RAB ASSIGNMENT
RESPONSE message(s). This is left to implementation. UTRAN shall stop
TQUEUING when all RABs have been either successfully established or modified
or failed to establish or modify. The RAB Assignment procedure is then
terminated both in CN and UTRAN when all RABs have been responded to.
When CN receives the response that one or several RABs are queued, CN shall
expect UTRAN to provide the outcome of the queuing function for each RAB
before expiry of the T RABAssgt timer. In case the timer T RABAssgt expires, the CN
shall consider the RAB Assignment procedure terminated and the RABs not
reported shall be considered as failed.
In the case the timer TQUEUING expires, the RAB Assignment procedure
terminates in UTRAN for all queued RABs, and UTRAN shall respond for all
of them in one RAB ASSIGNMENT RESPONSE message. The RAB
Assignment procedure shall also be terminated in CN.
In case a request to modify or release a RAB contains the RAB ID of a RAB
being queued, the RAB shall be taken out of the queue and treated according to
the second request. The first request shall be responded to as a RAB failed to
set-up or modify with the cause value “Request superseded”.
When UTRAN reports unsuccessful establishment/modification of a RAB, the
cause value should be precise enough to enable the core network to know the
34 (161)
Contents
reason for unsuccessful establishment/modification. Typical cause values are:

“Requested Traffic Class not Available”, “Invalid RAB Parameters Value”,
“Requested Maximum Bit Rate not Available”, “Requested Maximum Bit Rate
for DL not Available”, “Requested Maximum Bit Rate for UL not Available”,
“Requested Guaranteed Bit Rate not Available”, “Requested Guaranteed Bit
Rate for DL not Available”, “Requested Guaranteed Bit Rate for UL not
Available”, “Requested Transfer Delay not Achievable”, “Invalid RAB
Parameters Combination”, “Condition Violation for SDU Parameters”,
“Condition Violation for Traffic Handling Priority”, “Condition Violation for
Guaranteed Bit Rate”, “User Plane Versions not Supported”, “Iu UP Failure”,
“Iu Transport Connection Failed to Establish”.
If the RAB ID of a RAB requested to be released is unknown in the RNC, this
shall be reported as a RAB failed to release with the cause value “Invalid RAB
ID”.
The RNC may indicate an impending directed retry attempt to GSM by sending
RAB ASSIGNMENT RESPONSE message with a RAB ID included in the list
of RABs failed to set-up and a cause value of “Directed Retry”.
The RNC shall be prepared to receive a RAB ASSIGNMENT REQUEST
message containing a RABs To Be Released IE at any time and shall always
reply to it. If there is an ongoing RAB Assignment procedure for a RAB
indicated within the RABs To Be Released IE, the RNC shall discard the
preceding RAB Assignment procedure for that specific RAB, release any
related resources and report the released RAB within the RAB ASSIGNMENT
RESPONSE message.
After sending RAB ASSIGNMENT RESPONSE message containing RAB ID
within the RABs Released IE, the RNC shall be prepared to receive new
establishment request of a RAB identified by the same RAB ID.
The message shall contain the information required by the UTRAN to build the
new RAB configuration, such as:
- list of RABs to establish or modify with their bearer characteristics;
- list of RABs to release.
For each RAB requested to establish, the message shall contain:
- RAB ID.
- NAS Synchronisation Indicator (only when available).
- RAB parameters (including e.g. Allocation/Retention Priority).
- User Plane Information (i.e. User Plane Mode and UP Mode Versions).
- Transport Layer Information.
- PDP Type Information (only for PS)
- Data Volume Reporting Indication (only for PS).
- DL GTP-PDU sequence number (only when GTP-PDU sequence number is
available in cases of intersystem change from GPRS to UMTS or when
35 (161)
Iu-PS Interface
establishing a RAB for an existing PDP context or in some further cases

described in 3GPP TS 23.060).
- UL GTP-PDU sequence number (only when GTP-PDU sequence number is
available in cases of intersystem change from GPRS to UMTS or when
establishing a RAB for an existing PDP context or in some further cases
described in 3GPP TS 23.060).
- DL N-PDU sequence number (only when N-PDU sequence number is
available in case of intersystem change from GPRS to UMTS or in some
further cases described in 3GPP TS 23.060).
- UL N-PDU sequence number (only when N-PDU sequence number is
available in case of intersystem change from GPRS to UMTS or in some
further cases described in 3GPP TS 23.060).
For each RAB requested to modify, the message may contain:
- RAB ID (mandatory).
- NAS Synchronisation Indicator.
- RAB parameters.
- Transport Layer Information.
- User Plane Information.
The Transport Layer Information IE may be present at a RAB modification
except in the case when the only other present IE, besides the RAB ID IE, is the
NAS Synchronisation Indicator IE.
At a RAB modification, the RAB Parameters IE shall be present in RAB
ASSIGNMENT REQUEST message only when any previously set value for
this IE is requested to be modified.
At a RAB modification, the User Plane Information IE shall be present in RAB
ASSIGNMENT REQUEST message only when any previously set value for
this IE is requested to be modified.
For a RAB set-up, the SDU Format Information Parameter IE in the RAB
Parameters IE shall be present only if the User Plane Mode IE is set to “support
mode for pre-defined SDU sizes” and the Traffic Class IE is set to either
“Conversational” or “Streaming”.
If the RAB Parameters IE is present for a RAB modification, the SDU Format
Information Parameter IE in the RAB Parameters IE shall be present only if the
Traffic Class IE is set to either “Conversational” or “Streaming” and if
- either the User Plane mode is currently “support mode for pre-defined SDU
sizes” and the User Plane Mode IE is not contained in the RAB
ASSIGNMENT REQUEST message
- or if the User Plane Mode IE optionally contained within the RAB
ASSIGNMENT REQUEST message is set to “support mode for pre-
defined SDU sizes”.
36 (161)
Contents
If, for a RAB requested to be modified, one (or more) of these IEs except RAB
ID IE are not present in RAB ASSIGNMENT REQUEST message the RNC
shall continue to use the value(s) currently in use for the not present IEs.
For each RAB request to release, the message shall contain:
- RAB ID.
- Cause.
Example of a RAB Assignment Request Message:
RAB-ASSIGNMENT REQUEST
RANAP-PDU
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 0
- padding: 00000
- contents
- contents (in bits): 01
initiatingMessage
- padding: 000000
- opentype length
RAB-AssignmentRequest
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 54
- contents
- padding: 000000
- opentype length
RAB-SetupOrModifyList
- length
- length
- id: 53
- contents
- firstCriticality: reject
- padding: 000000
- opentype length
firstValue
- extension flag: 0
- preamble: 111100
- rAB-ID: '00000101'B
- nAS-SynchronisationIndicator: '1111'B
37 (161)
Iu-PS Interface
rAB-Parameters
- extension flag: 0
- preamble: 0011010
- trafficClass: interactive
- extension range: 0
- rAB-AsymmetryIndicator: symmetric-bidirectional
maxBitrate
- length (in bits): 0
- MaxBitrate: 64000
- padding: 0000
- contents
- deliveryOrder: delivery-order-not-requested
- maxSDU-Size: 12000
- padding: 0000000
- contents
sDU-Parameters
- extension flag: 0
- preamble: 100
sDU-ErrorRatio
- preamble: 0
- mantissa: 1
- exponent: 4
residualBitErrorRatio
- preamble: 0
- mantissa: 1
- exponent: 5
- deliveryOfErroneousSDU: no
- trafficHandlingPriority: 3
allocationOrRetentionPriority
- extension flag: 0
- preamble: 0
- priorityLevel: 3
- pre-emptionCapability: shall-not-trigger-pre-emption
- pre-emptionVulnerability: not-pre-emptable
- queuingAllowed: queueing-allowed
- relocationRequirement: none
38 (161)
Contents
userPlaneInformation
- extension flag: 0
- preamble: 0
- userPlaneMode: transparent-mode
- uP-ModeVersions: '0000000000000001'B
- contents (in bits): 00000000 0000 0001
transportLayerInformation
- extension flag: 0
- preamble: 0
- transportLayerAddress: '10101100000100100110001011000110'- extension
range: 0
- padding: 0
- contents
iuTransportAssociation
- extension flag: 0
- choice index: 0
- gTP-TEI: '0000011F'H
- padding: 000000
- contents
- secondCriticality: ignore
- padding: 000000
- opentype length
secondValue
- extension flag: 0
- preamble: 1100000
pDP-TypeInformation
- PDP-Type: ipv4
- dataVolumeReportingIndication: do-report
- trailing bits: 00
Example of a RAB Assignment Response Message:
RAB-ASSIGNMENT RESPONSE
RANAP-PDU
- extension flag: 0
- choice index: 11
outcome
- procedureCode: 0
- padding: 00000
- contents
- criticality: reject
outcome
- padding: 000000
- opentype length
39 (161)
Iu-PS Interface
RAB-AssignmentResponse
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 52
- contents
- padding: 000000
- opentype length
RAB-SetupOrModifiedList
- length
- length
- id: 51
- contents
- padding: 000000
- opentype length
RAB-SetupOrModifiedItem
- extension flag: 0
- preamble: 1100
- rAB-ID: '00000101'B
- transportLayerAddress: '10101100000100100110000110000011'B
- padding: 00
- contents
- extension flag: 0
- choice index: 0
- gTP-TEI: '00000000'H
- padding: 000000
- contents
In the RAB Assignment Request and response, the following sub-fields might
be analysed in further detail:
RAB ID
This element uniquely identifies the radio access bearer for a specific CN
domain for a particular UE, which makes the RAB ID unique over one Iu
connection. The RAB ID shall remain the same for the duration of the RAB
even when the RAB is relocated to another Iu connection.
The purpose of the element is to bind data stream from the Non-Access Stratum
point of view (e.g. bearer of call or PDP context) and radio access bearer in
40 (161)
Contents
Access Stratum. The value is also used in the RNC to relate Radio Bearers to a
RAB. The content of this information element is transferred unchanged from the
CN node (i.e., MSC or SGSN) via RNC to UE by RANAP messages and RRC
messages. For RRC messages refer to 3GPP TS 25.331: “Radio Resource
Control (RRC) protocol specification”.
The element contains binary representation of either the Stream Identifier (SI)
for CS domain or the Network Service Access Point Identifier (NSAPI) for PS
domain. These identifiers are coded in the RAB ID element in accordance with
the coding of the Stream Identifier IE and with the coding of the NSAPI IE in
3GPP TS 24.008: “Mobile radio interface layer 3 specification; Core network
protocols; Stage 3”.
RAB Parameters
The purpose of the RAB parameters IE group and other parameters within the
RAB parameters IE group is to indicate all RAB attributes as defined in 3GPP
TS 23.107: “Quality of Service (QoS) concept and architecture” for both
directions. For more details on RAB Parameters refer to Appendix B.
User Plane Information
User Plane Mode

This element indicates the mode of operation of the Iu User plane requested for
realising the RAB. The Iu User plane modes are defined in 3GPP TS 25.415:
“UTRAN Iu interface user plane protocols”.
UP Mode Versions
UP mode versions IE is an information element that is sent by CN to RNC. It is
a bit string that indicates the versions for the selected Iu UP mode that are
supported by the CN. The Iu User plane mode versions shall be defined and
coded as the “Iu UP Mode versions supported” field defined in 3GPP TS
25.415: “UTRAN Iu interface user plane protocols”. This reference is
applicable for both the transparent mode and the support mode for predefined
SDU sizes.
Transport Layer Information
Transport Layer Address

For the PS domain this information element is an IP address to be used for the
user plane transport.
41 (161)
Iu-PS Interface
Iu Transport Association
This element is used to associate the RAB and the corresponding transport
bearer. In PS domain this information element is the GTP Tunnel Endpoint
Identifier.
Service Handover
This IE tells if intersystem handover to GSM should, should not, or shall not be
performed for the RAB in question.
Second Set-up Or Modify Item
PDP Type Information

PDP Type is defined in 3GPP TS 24.008: “Mobile radio interface layer 3
specification; Core network protocols; Stage 3”.
When the IE is repeated then PDP Type for downlink is signalled first, followed
by PDP Type for uplink; when the IE is not repeated, the PDP Type shall apply
to both uplink and downlink.
Data Volume Reporting Indication
This information element indicates whether or not RNC has to calculate the
unsuccessfully transmitted NAS data amount for the RAB and to report the
amount of data when the RAB is released.
DL GTP-PDU Sequence Number
This IE indicates the sequence number of the GTP-PDU which is the next to be
sent to the UE.
UL GTP-PDU Sequence Number
This IE indicates the sequence number of the GTP-PDU which is the next to be
sent to the SGSN.
DL N-PDU Sequence Number
This IE indicates the radio interface sequence number (PDCP) explained in
3GPP TS 25.323: “Packet Data Convergence Protocol (PDCP) specification” of
the next downlink N-PDU (PDCP SDU) that would have been sent to the UE by
a source system.
UL N-PDU Sequence Number
This IE indicates the radio interface sequence number (PDCP) explained
in3GPP TS 25.323: “Packet Data Convergence Protocol (PDCP) specification”
of the next uplink N-PDU (PDCP SDU) that would have been expected from
the UE by a source system.
42 (161)
Contents
RABs To Be Released List
Cause
The purpose of the Cause IE is to indicate the reason for a particular event for
the RANAP protocol.
- Radio Network Layer Cause:
Value Cause
1 RAB preempted
2 Trelocoverall Expiry
3 Trelocprep Expiry
4 Treloccomplete Expiry
5 Tqueing Expiry
6 Relocation Triggered
7 TRELOCalloc Expiry
8 Unable to Establish During Relocation
9 Unknown Target RNC
10 Relocation Cancelled
11 Successful Relocation
12 Requested Ciphering and/or Integrity Protection Algorithms not

Supported
13 Conflict with already existing Integrity protection and/or Ciphering

information
14 Failure in the Radio Interface Procedure
15 Release due to UTRAN Generated Reason
16 User Inactivity
17 Time Critical Relocation
18 Requested Traffic Class not Available
19 Invalid RAB Parameters Value
20 Requested Maximum Bit Rate not Available
21 Requested Guaranteed Bit Rate not Available
22 Requested Transfer Delay not Achievable
23 Invalid RAB Parameters Combination
24 Condition Violation for SDU Parameters
25 Condition Violation for Traffic Handling Priority
26 Condition Violation for Guaranteed Bit Rate
27 User Plane Versions not Supported
43 (161)
Iu-PS Interface
28 Iu UP Failure
29 Relocation Failure in Target CN/RNC or Target System
30 Invalid RAB ID
31 No remaining RAB
32 Interaction with other procedure
33 Requested Maximum Bit Rate for DL not Available
34 Requested Maximum Bit Rate for UL not Available
35 Requested Guaranteed Bit Rate for DL not Available
36 Requested Guaranteed Bit Rate for UL not Available
37 Repeated Integrity Checking Failure
38 Requested Request Type not supported
39 Request superseded
40 Release due to UE generated signalling connection release
41 Resource Optimisation Relocation
42 Requested Information Not Available
43 Relocation desirable for radio reasons
44 Relocation not supported in Target RNC or Target system
45 Directed Retry
46 Radio Connection With UE Lost
- Transport Layer Cause

65 Signalling Transport Resource Failure
66 Iu Transport Connection Failed to Establish
- NAS Cause
81 User Restriction Start Indication
82 User Restriction End Indication
83 Normal Release
- Protocol Cause
113 Transfer Syntax Error
114 Semantic Error
115 Message not compatible with receiver state
116 Abstract Syntax Error (Reject)
117 Abstract Syntax Error (Ignore and Notify)
118 Abstract Syntax Error (Falsely Constructed Message)
44 (161)
Contents
- Miscellaneous Cause
113 O&M Intervention
114 No Resource Available
115 Unspecified Failure

116 Network Optimisation
The meaning of the different cause values is described in Appendix C.

In general, “not supported” cause values indicate that the concerning capability
is missing. On the other hand, “not available” cause values indicate that the
concerning capability is present, but insufficient resources were available to
perform the requested action.
Data Volume List

Unsuccessfully Transmitted Data Volume
This information element indicates the data volume (octets) that is
unsuccessfully transmitted over the radio interface in DL direction for the RAB.
Data Volume Reference
This information element indicates the time when the data volume is counted.
45 (161)
Iu-PS Interface
4.5.2.4 Iu-Release Request

The purpose of the Iu Release Request procedure is to enable the UTRAN to
request the CN to release the Iu connection for a particular UE due to some
UTRAN generated reason. The procedure uses connection-oriented signalling.
The figure below describes the Iu Release Request procedure.
Figure 12: Iu Release Request
Iu-Release Request
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 01
- id: 4
- contents: 00 04
- padding: 000000
- opentype length: 02
Cause
- extension flag: 0
- choice index: 000
- radioNetwork: radio-connection-with-UE-Lost
46 (161)
Contents
4.5.2.5 Iu Release
The purpose of the Iu Release procedure is to enable the CN to release the Iu
connection and all UTRAN resources related only to that Iu connection to be
released. The procedure uses connection-oriented signalling.
The figure below describes the Iu Release procedure.
Figure 13: Iu Release Procedure
Data Volume reporting is never required, so data volume reports are never
accepted on Iu Release Complete.
IU-RELEASE COMMAND
RANAP-PDU
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 1
- padding: 00000
- contents
initiatingMessage
- padding: 000000
- opentype length
Iu-ReleaseCommand
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 4
- contents
- padding: 000000
- opentype length
47 (161)
Iu-PS Interface
Cause
- extension flag: 0
- choice index: 000
- radioNetwork: no-remaining-rab
- contents (in bits):
IU-RELEASE COMPLETE
RANAP-PDU
- extension flag: 0
- choice index: 01
successfulOutcome
- procedureCode: 1
- padding: 00000
- contents
successfulOutcome
- padding: 000000
- opentype length
Iu-ReleaseComplete
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 31
- contents
- padding: 000000
- opentype length
RAB-DataVolumeReportList
- length
- length
- id: 30
- contents
- padding: 000000
- opentype length
RAB-DataVolumeReportItem
- extension flag: 0
- preamble: 10
- rAB-ID: '00000101'B
dl-UnsuccessfullyTransmittedDataVolume
- extension flag: 0
- preamble: 00
- dl-UnsuccessfullyTransmittedDataVolume: 0
- padding: 0000000
- contents
48 (161)
Contents
4.5.2.6 Paging
The purpose of the Paging procedure is to enable the CN to request the UTRAN
to contact an UE. The procedure uses connectionless signalling. The figure
below describes the Paging procedure.
Figure 14: Paging procedure
Paging
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 06
- id: 3
- contents: 00 03
- padding: 000000
CN-DomainIndicator: ps-domain
- trailing bits: 0000000
- id: 23
- contents: 00 17
- padding: 000000
PermanentNAS-UE-ID
- extension flag: 0
- iMSI: '62029903000040F1'H
- padding: 0000
49 (161)
Iu-PS Interface
- contents: 62 02 99 03 00 00 40 F1
- id: 64
- contents: 00 40
- padding: 000000
TemporaryUE-ID
- extension flag: 0
- choice index: 1
- p-TMSI: '09C24B3C'H
- padding: 000000
- contents: 09 C2 4B 3C
- id: 21
- contents: 00 15
- padding: 000000
PagingAreaID
- extension flag: 0
- choice index: 1
rAI
- extension flag: 0
- preamble: 0
lAI
- preamble: 0
- pLMNidentity: '62F290'H
- padding: 000
- contents: 62 F2 90
- lAC: '00C9'H
- contents: 00 C9
- rAC: '17'H
- contents: 17
- id: 22
- contents: 00 16
- padding: 000000
PagingCause: terminating-background-call
- id: 17
- contents: 00 11
- padding: 000000
NonSearchingIndication: searching
50 (161)
Contents
4.5.2.7 Common ID
The purpose of the Common ID procedure is to inform the RNC about the
permanent NAS UE identity (IMSI) of a user. This is used by the RNC, for
example, to create a reference between the permanent NAS UE identity of the
user and the Radio Resource Control (RRC) connection of that user for UTRAN
paging coordination. The procedure uses connection-oriented signalling. The
figure below describes the Common ID procedure.
Figure 15: Common ID procedure
COMMONID
RANAP-PDU
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 15
- padding: 00000
- contents
initiatingMessage
- padding: 000000
- opentype length
CommonID
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 23
- contents
- padding: 000000
- opentype length
PermanentNAS-UE-ID
- extension flag: 0
- iMSI: '32349030037865F9'H
- padding: 0000
- contents
51 (161)
Iu-PS Interface
4.5.2.8 Security Mode Control

The purpose of the Security Mode Control procedure is to
allow the CN to pass cipher and integrity mode information to
the UTRAN. The UTRAN uses this information to select and
load the encryption device for user and signalling data with
the appropriate parameters, and also to store the appropriate
parameters for the integrity algorithm. The procedure uses
Successful Security Mode Control
The figure below describes the successful Security Mode Control procedure.
Figure 16 Successful Security Mode Control
SECURITY MODE COMMAND

RANAP-PDU
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 6
- padding: 00000
- contents
initiatingMessage
- padding: 000000
- opentype length
SecurityModeCommand
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 12
- contents
- padding: 000000
- opentype length
52 (161)
Contents
IntegrityProtectionInformation
- preamble: 0
permittedAlgorithms
- IntegrityProtectionAlgorithm: standard-UMTS-integrity-algorithm--
contents (in bits): 0000
- key:
'01100010111111100000110100110110100000111010111010100101001101101110000101
010000101
010000000000001100010111111100000110100110110'B
- padding: 0000000
- contents
- id: 11
- contents
- padding: 000000
- opentype length
EncryptionInformation
- preamble: 0
permittedAlgorithms
- EncryptionAlgorithm: no-encryption
- key:
'10000011101011101010010100110110111000010101000010101000000000001000001110
101110101
001010011011011100001010100001010100000000000'B
- padding: 0000000
- contents
- id: 75
- contents
- padding: 000000
- opentype length
KeyStatus: old
SECURITY MODE COMPLETE

RANAP-PDU
- extension flag: 0
- choice index: 01
successfulOutcome
- procedureCode: 6
- padding: 00000
- contents
successfulOutcome
- padding: 000000
- opentype length
SecurityModeComplete
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length
- id: 6
53 (161)
Iu-PS Interface
- contents
- padding: 000000
- opentype length
ChosenIntegrityProtectionAlgorithm: standard-UMTS-integrity-algorithm-UIA1
- id: 5
- contents
- padding: 000000
- opentype length
ChosenEncryptionAlgorithm: no-encryption
4.5.2.9 Relocation Preparation

The purpose of the Relocation Preparation procedure is to prepare
relocation of SRNS either with or without involving the UE. The
procedure uses connection-oriented signalling.
The figure below describes the successful Relocation Preparation procedure.
Figure 17: Successful Relocation Preparation procedure
54 (161)
Contents
4.5.2.10 Relocation Resource Allocation

The purpose of the Relocation Resource Allocation procedure is
to allocate resources from the target RNS for a relocation of
SRNS. The procedure uses connection-oriented signalling.
The figure below describes the successful Relocation Resource Allocation

procedures.
Figure 18: Successful Relocation Resource Allocation procedure
4.5.2.11 Relocation Detect

The purpose of the Relocation Detect procedure is to have the RNC
indicate the detection of SRNS relocation execution to the CN. The
The figure below describes the Relocation Detect procedure.
Figure 19: Relocation Detect procedure
55 (161)
Iu-PS Interface
4.5.2.12 Relocation Complete

The purpose of the Relocation Complete procedure is to indicate by
the target RNC the completion of relocation of SRNS to the CN.
The procedure uses connection-oriented signalling.
The figure below describes the Relocation Complete procedure.
Figure 20: Relocation Complete procedure
4.5.2.13 Relocation Cancel

The purpose of the Relocation Cancel procedure is to enable the
source RNC to cancel an ongoing relocation of SRNS. The
The figure below describes the Relocation Cancel procedure.
Figure 21:Relocation Cancel procedure
56 (161)
Contents
4.5.2.14 SRNS Context Transfer

The purpose of the SRNS Context Transfer procedure is to trigger
the transfer of SRNS contexts from the source RNC to the CN (PS
domain) in case of inter-system change. The procedure uses
The figure below describes the SRNS Context Transfer procedure.
Figure 22: SRNS Context Transfer procedure
4.5.2.15 SRNS Data Forwarding Initiation

The purpose of the SRNS Data Forwarding Initiation procedure is to
trigger the transfer of Network Protocol Data Units (N-PDUs) from
the RNC to the CN (PS domain) in case of inter-system change. The
procedure uses connection-oriented signalling. The figure below
describes the SRNS Data Forwarding Initiation procedure.
Figure 23: SRNS Data Forwarding Initiation procedure
57 (161)
Iu-PS Interface
4.5.2.16 SRNS Context Forwarding from Source RNC to CN

The purpose of this procedure is to transfer SRNS contexts from the
source RNC to the CN (PS domain) in case of handover via the CN.
The procedure uses connection-oriented signalling. SRNS contexts
are sent for each RAB concerned, for which at least either the GTP-
PDU or Packet Data Convergence Protocol (PDCP) sequence
numbering is available. The contexts contain the sequence numbers
of the GTP-PDUs to be transmitted next in the uplink and downlink
directions, if available, and the next PDCP sequence numbers that
would have been used to send and receive data from the UE, if
available. The figure below describes the SRNS Context Forwarding
from Source RNC to CN procedure.
Figure 24: SRNS Context Forwarding from Source RNC to CN procedure
58 (161)
Contents
4.5.2.17 SRNS Context Forwarding to Target RNC from CN

The purpose of this procedure is to transfer SRNS contexts from the
CN (PS domain) to the target RNC in case of handover via the CN.
The procedure uses connection-oriented signalling. SRNS contexts
are sent for each referred RAB, for which at least either GTP-PDU
or PDCP sequence numbering is available. The contexts contain the
sequence numbers of the GTP-PDUs to be transmitted next in the
uplink and downlink directions, if available, and the next PDCP
sequence numbers that would have been used to send and receive
data from the UE, if available.
The figure below describes the SRNS Context Forwarding to Target

RNC from CN procedure.
Figure 25: SRNS Context Forwarding to Target RNC from CN procedure
59 (161)
Iu-PS Interface
4.6 Mobility Management Procedures (MM, GSM L3)

GPRS Mobility Management (GMM) supports such Mobility Management
functionalities as Attach, Detach, security, and Routing Area Update. Session
Management (SM) supports PDP Context Activation, Modification, and
Deactivation.
SMS supports the Mobile-Originated and Mobile-Terminated Short Message
Service described in TS 23.040.
The Layer 3 Session and Mobility Management (L3-SMM) signalling between
the UE and the SGSN transports the messages concerning the Mobility
Management and Session Management. Mobility Management and Session
management are described in their own sections. SMS delivery is also
performed via the same signalling.
The procedures are briefly the following:
 Common procedures: P-TMSI reallocation, authentication,

identification and IMSI detach
 Mobility Management procedures: Attach, detach, location updating,

periodic updating, IMSI attach and several connection management
procedures
 Session Management procedures: PDP context activation,

modification and deactivation
 SMS; Short Message Control (SMC) and Short Message Relay

function (SM-RL).
The L3-SMM implementation complies with 3G TS 24.008 and SMS is

according to 3G TS23.040 and 24.011. The protocol stack of the control plane
is shown in the following figure:
60 (161)
Contents
UE Uu RNC Iu-PS SGSN
Figure 26: GMM/SM connection between MS and 3G SGSN
Layer 3 radio interface messages sent from the 3G SGSN are encapsulated into
Radio Access Network Application Protocol (RANAP) protocol messages and
received by the Serving RNC (SRNC). The SRNC forwards the messages
transparently to the UE/MS across the Uu interface by employing the Radio
Resource Control (RRC) protocol.
Mobility Management Procedures use GSM L3 messages. GSM L3 Layer is

using services of the RANAP Layer. Here is a list of these Procedures and
Functions:
- Attach Procedure
- UMTS GPRS Attach Procedure
- Combined GPRS / IMSI Attach Procedure
- MS-Initiated Detach Procedure
- Network-Initiated Detach Procedure
- SGSN-Initiated Detach Procedure
- HLR-Initiated Detach Procedure
- Purge Function
- UMTS Authentication
- User Identity Confidentiality
- P-TMSI Reallocation Procedure
- Data Integrity Procedure
- Routeing Area Update Procedure
61 (161)
Iu-PS Interface
- SRNS Relocation Procedure

- Combined Hard Handover and SRNS Relocation Procedure
- Combined Cell / URA Update and SRNS Relocation Procedure
- SRNS Relocation Cancel Procedure
- Periodic RA and LA Updates
- Insert Subscriber Data Procedure
- Delete Subscriber Data Procedure
- MS Initiated Service Request Procedure
- Network Initiated Service Request Procedure
- Intra SGSN Intersystem Change
- UMTS to GSM Intra SGSN Change
- GSM to UMTS Intra-SGSN Change
- Selective RA Update
- UMTS to GSM Inter-SGSN Change
- GSM to UMTS Inter-SGSN Change
- Service Request
- Paging
4.6.1 The Attach Procedure
4.6.1.1 General idea

An MS shall perform a GPRS Attach to the SGSN in order to obtain access to
the GPRS services. If the MS is connected via a UMTS radio access network, it
shall perform a UMTS GPRS Attach procedure.
In the attach procedure, the MS shall provide its identity and an indication of
which type of attach that is to be executed. The identity provided to the network
shall be the MS's Packet TMSI (P-TMSI) or IMSI. P-TMSI and the RAI
associated with the P-TMSI shall be provided if the MS has a valid P-TMSI. If
the MS does not have a valid P-TMSI, the MS shall provide its IMSI.
A GPRS-attached MS makes an IMSI attach via the SGSN with the combined
RA / LA update procedure if the network operates in mode I (Gs interface is
present.). If the network operates in mode II (Gs interface is not present.), or if
the MS is not GPRS-attached, the MS makes a normal IMSI attach. An IMSI-
attached MS engaged in a CS connection shall use the (non-combined) GPRS
Attach procedure when it performs a GPRS attach.
After having executed the GPRS attach, the MS is in the PMM-CONNECTED
state and MM contexts are established in the MS and the SGSN. The MS may
then activate PDP contexts as described in sub-clause “Activation Procedures”.
62 (161)
Contents
An IMSI-attached MS that cannot operate in CS/PS mode of operation shall

follow the normal IMSI detach procedure before it makes a GPRS attach. A
GPRS-attached MS that cannot operate in CS/PS mode of operation shall
perform a GPRS detach before it makes an IMSI attach.
4.6.1.2 Combined GPRS/ IMSI Attach Procedure in detail

The figure on the next page shows the different messages of a combined
GPRS / IMSI Attach Procedure. Furthers, we will have a closer look at the
procedure to analyse the single steps that need to be performed to complete this
procedure.
63 (161)
Iu-PS Interface
new old
MS UTRAN new SGSN old SGSN GGSN EIR MSC/VLR HLR MSC/VLR
1. Attach Request
2. Identification Request
2. Identification Response
3. Identity Request
3. Identity Response
4. Authentication
5. IMEI Check
6a. Update Location
6b. Cancel Location
6c. Cancel Location Ack
6d. Insert Subscriber Data
6e. Insert Subscriber Data Ack
6f. Update Location Ack
7a. Location Update Request

7b. Update Location
7c. Cancel Location
7d. Cancel Location Ack
7e. Insert Subscriber Data
7f. Insert Subscriber Data
7g. Update Location Ack

7h. Location Update Accept
C1
8. Attach Accept
9. Attach Complete
10. TMSI Reallocation Complete
Figure 27: Combined GPRS / IMSI Attach Procedure
64 (161)
Contents
1. The MS initiates the attach procedure by the transmission of an Attach

Request (IMSI or P-TMSI and old RAI, Core Network Classmark, KSI,
Attach Type, old P-TMSI Signature, Follow On Request, DRX
Parameters) message to the SGSN. IMSI shall be included if the MS does
not have a valid P-TMSI available. If the MS uses P-TMSI for identifying
itself and if it has also stored its old P-TMSI Signature, then the MS shall
include the old P-TMSI Signature in the Attach Request message. If the
MS has a valid P-TMSI, then P-TMSI and the old RAI associated with
P-TMSI shall be included. KSI shall be included if the MS has valid
security parameters. Core Network Classmark is described in sub-clause
“MS Network Capability”. The MS shall set “Follow On Request” if
there is pending uplink traffic (signalling or user data). The SGSN may
use, as an implementation option, the follow on request indication to
release or keep the Iu connection after the completion of the GPRS
Attach procedure. Attach Type indicates which type of attach is to be
performed, i.e., GPRS attach only, GPRS Attach while already IMSI
attached, or combined GPRS / IMSI attach. DRX Parameters indicates
whether or not the MS uses discontinuous reception and the DRX cycle
length.
2. If the MS identifies itself with P-TMSI and the SGSN has changed since
detach, the new SGSN sends an Identification Request (P-TMSI, old
RAI, old P-TMSI Signature) to the old SGSN to request the IMSI. The
old SGSN responds with Identification Response (IMSI, Authentication
Triplets (for GPRS) or Authentication Vectors (for UMTS)). If the MS is
not known in the old SGSN, the old SGSN responds with an appropriate
error cause. The old SGSN also validates the old P-TMSI Signature and
responds with an appropriate error cause if it does not match the value
stored in the old SGSN.
3. If the MS is unknown in both the old and new SGSN, the SGSN sends an
Identity Request (Identity Type = IMSI) to the MS. The MS responds
with Identity Response (IMSI).
4. The authentication functions are defined in the sub-clause “Security
Function”. If no MM context for the MS exists anywhere in the network,
then authentication is mandatory. Ciphering procedures are described in
sub-clause “Security Function”. If P-TMSI allocation is going to be done
and the network supports ciphering, the network shall set the ciphering
mode.
5. The equipment checking functions are defined in the sub-clause “Identity
Check Procedures”. Equipment checking is optional.
6. If the SGSN number has changed since the GPRS detach, or if it is the
very first attach, then the SGSN informs the HLR:
a) The SGSN sends an Update Location (SGSN Number, SGSN Address,
IMSI) to the HLR.
b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old
SGSN with Cancellation Type set to Update Procedure.
65 (161)
Iu-PS Interface
c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If

there are any ongoing procedures for that MS, the old SGSN shall wait
until these procedures are finished before removing the MM and PDP
contexts.
d) The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data)
to the new SGSN.
e) The new SGSN validates the MS's presence in the (new) RA. If due to
regional subscription restrictions the MS is not allowed to attach in the
RA, the SGSN rejects the Attach Request with an appropriate cause,
and may return an Insert Subscriber Data Ack (IMSI, SGSN Area
Restricted) message to the HLR. If subscription checking fails for other
reasons, the SGSN rejects the Attach Request with an appropriate cause
and returns an Insert Subscriber Data Ack (IMSI, Cause) message to the
HLR. If all checks are successful then the SGSN constructs an MM
context for the MS and returns an Insert Subscriber Data Ack (IMSI)
message to the HLR.
f) The HLR acknowledges the Update Location message by sending an
Update Location Ack to the SGSN after the cancelling of old MM
context and insertion of new MM context are finished. If the Update
Location is rejected by the HLR, the SGSN rejects the Attach Request
from the MS with an appropriate cause.
7. If Attach Type in step 1 indicated GPRS Attach while already IMSI
attached, or combined GPRS / IMSI attached, then the VLR shall be
updated if the Gs interface is installed. The VLR number is derived from
the RA information. The SGSN starts the location update procedure
towards the new MSC/VLR upon receipt of the first Insert Subscriber
Data message from the HLR in step 6d). This operation marks the MS as
GPRS-attached in the VLR.
a) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN
Number, Location Update Type) message to the VLR. Location Update
Type shall indicate IMSI attach if Attach Type indicated combined
GPRS / IMSI attach. Otherwise, Location Update Type shall indicate
normal location update. The VLR creates an association with the SGSN
by storing SGSN Number.
b) If the LA update is inter-MSC, the new VLR sends Update Location
(IMSI, new VLR) to the HLR.
c) If the LA update is inter-MSC, the HLR sends a Cancel Location
(IMSI) to the old VLR.
d) The old VLR acknowledges with Cancel Location Ack (IMSI).
e) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data
(IMSI, GSM subscriber data) to the new VLR.
f) The VLR acknowledges with Insert Subscriber Data Ack (IMSI).
66 (161)
Contents
g) After finishing the inter-MSC location update procedures, the HLR

responds with Update Location Ack (IMSI) to the new VLR.
h) The VLR responds with Location Update Accept (VLR TMSI) to the
SGSN.
8. The SGSN selects Radio Priority SMS, and sends an Attach Accept
(P-TMSI, VLR TMSI, P-TMSI Signature, Radio Priority SMS) message
to the MS. P-TMSI is included if the SGSN allocates a new P-TMSI.
9. If P-TMSI or VLR TMSI was changed, the MS acknowledges the
received TMSI(s) by returning an Attach Complete message to the
SGSN.
10. If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-
allocation by sending a TMSI Reallocation Complete message to the
VLR.
If the Attach Request cannot be accepted, the SGSN returns an Attach Reject
(IMSI, Cause) message to the MS.CAMEL procedure call shall be performed,
see referenced procedure in 3G TS 23.078:
C1) CAMEL_GPRS_Attach
4.6.1.3 Example Trace of the Attach procedure

The following trace can be taken as a standard example for a normal attach
procedure on the Iu-Ps interface. It was taken using the Nethawk protocol
analyser and reflects current configurations and settings of the test-bed from
where the trace has been taken.
Attach Request
ATTACH REQUEST (GPRS MM)

MS Network Capability
- Encryption algorithm GEA/1 available
- SM capabilities via dedicated channels supported
- SM capabilities via GPRS channels supported
- Use of default alphabet over UCS2 prefered
- Capab. of ellipsis notation and phase 2 error handling
- The ME does not support SoLSA
- Mobile station supporting R99 or later versions
- Mobile station does not support BSS packet flow procedures
- encryption algorithm GEA/2 not available
Attach Type
- GPRS attach
- Follow-on request pending
GPRS Ciphering Key Seq. Nr
67 (161)
Iu-PS Interface
- value: 7 (07h)
DRX Parameter
- Split PG Cycle value: 7
- DRX cycle length coefficient not specified by the MS
- Split pg cycle on CCCH not supported
- max. 2 sec non-DRX mode after transfer state
Mobile identity
- length: 5 (05h)
- TMSI/P-TMSI: 38A9055A
Routing Area Id.
- Mobile Country Code: 234
- Mobile Network Code: 20
- Location Area Code: 5 (5h)
- Routing Area Code: 2 (02h)
MS Radio Access Capability
GSM 900-E Access Technology Type
- Length: 39 bits
- Radio capability : 4
- Encrypt. algorithm A5/1 available
- Encrypt. algorithm A5/3 not available
- Controlled early Classmark Sending implemented
- PS capability not present
- VGCS capability and notifications not wanted
- VBS capability and notifications not wanted
- HSCSD Multislot Class: 6
- GPRS Multislot Class: 6
- GPRS Ext. Dynamic Alloc. Capability not implemented
- COMPACT Interference Meas. Capab. is not implemented
- The ME is Release '98 onwards
- UMTS FDD supported
- UMTS TDD not supported
- CDMA2000 not supported
GSM 1800 Access Technology Type
- Length: 15 bits
- RF Power class: 1, max 1 W (30 dBm)
- Spare ok
P-TMSI signature
- Value: 63 92 B6
GPRS Timer
- Value: 44 sec
68 (161)
Contents
From the Mobility Management part we can find several more fields in the trace
of an analyser. In the case of the Attach Request message we can see:
MS network capability
The purpose of the MS network capability information element is to provide the
network with information concerning aspects of the mobile station related to
GPRS. The contents might affect the manner in which the network handles the
operation of the mobile station. The MS network capability information
indicates general mobile station characteristics and it shall therefore, except for
fields explicitly indicated, be independent of the frequency band of the channel
it is sent on. For further information about the sub-fields, please refer to 3GPP
TS 24.008, chapter 10.5.5.12.
The Attach Type
The Attach Type indicates which type of attach that is to be performed, i.e.,
GPRS attach only, GPRS Attach while already IMSI attached, or combined
GPRS / IMSI attach.
The Attach Type, 3 bits
value Type of Attach Text
1. GPRS Attach
2. GPRS Attach while IMSI attached
3. Combined GPRS/IMSI attach
Follow-on request, 1 bit
value Follow-on request Text
4. No follow-on request pending
5. Follow-on request pending
Follow-on request pending is applicable only in UMTS
In UMTS, if the MS wishes to prolong the established PS signalling connection
after the GPRS attach procedure, it may set a follow-on request pending.
In a UMTS authentication challenge, the purpose of the Ciphering Key
Sequence Number information element is to make it possible for the network to
identify the ciphering key CK and integrity key IK which are stored in the MS
without invoking the authentication procedure. CK and IK form a Key Set
Identifier (KSI) (see 3GPP TS 33.102) which is encoded the same as the CKSN
and is therefore included in the CKSN field.
GPRS Ciphering Key Seq. Nr, 1 bit
value GPRS Ciphering Key Seq. Nr. Text
0-6 Possible values for the ciphering key
7 No key is available (MS to network)
69 (161)
Iu-PS Interface
DRX Parameter
DRX Parameters indicates whether the MS uses discontinuous reception or not.
For further information about the sub-fields, please refer to 3GPP TS 24.008,
chapter 10.5.5.6.
Mobile Station Identity
This element is used to uniquely identify a mobile station. Identification is done
using International Mobile Subscriber Identity (IMSI), Temporary Mobile
Subscriber Identity (TMSI), International Mobile Equipment Identity (IMEI) or
International Mobile Equipment Identity with Software Version (IMEISV). In
the ciphering mode setting procedure and in the GMM authentication and
ciphering procedure the mobile shall select the IMEISV.
Routing Area Id.
The purpose of the Routing Area Identification information element is to
provide an unambiguous identification of routing areas within the area covered
by the UMTS system.
MS Radio Access Cap.
The purpose of the MS RA capability information element is to provide the
radio part of the network with information concerning radio aspects of the
mobile station. The contents might affect the manner in which the network
handles the operation of the mobile station. For further information about the
sub-fields, please refer to 3GPP TS 24.008, chapter 10.5.5.12a.
Due to shared radio frequency channel numbers between 1800 and 1900, the
mobile should provide MS Radio Access capability for either 900/1800 band(s)
OR 1900 band.
Identity Request
IDENTITY REQUEST (GMM) (GPRS MM)

Identity Type 2
- IMSI
Force to Standby
- not indicated
Identity Request for IMSI
IDENTITY REQUEST (GMM) (GPRS MM)

Identity Type 2
- IMEISV
Force to Standby
- not indicated
Identity Request for IMEISV
70 (161)
Contents
Force to standby
The SGSN indicates an immediate return to PMM-IDLE state before the
READY timer expires.
Identity Response
IDENTITY RESPONSE (GMM) (GPRS MM)

Mobile identity
- length: 8 (08h)
- IMSI: 262099300000041
Identity Response for IMSI
IDENTITY RESPONSE (GMM) (GPRS MM)

Mobile identity
- length: 9 (09h)
- IMEISV: 3509891000263900
Identity Response for IMEISV
Attach Accept
ATTACH ACCEPT (GPRS MM)

Attach Result
- GPRS only attached
Force to Standby
- not indicated
GPRS Timer
- Value: 30 min
Radio Priority
- Priority level 4
Routing Area Id.
- Location Area Code: 5 (5h)
- Routing Area Code: 2 (02h)
P-TMSI signature
- Value: 4E 4C 63
P-TMSI
- length: 5 (05h)
- TMSI/P-TMSI: 1C711B1C
In the Attach accept, the following sub-fields might be analysed in further

detail:
71 (161)
Iu-PS Interface
Attach Result
Here, possible values are either 'GPRS only attached' or 'Combined GPRS/IMSI
attached'
Please note, that in the request message above, a combined attach was
requested. However, the response notifies about a GPRS attach only. A reason
for this might be, that the Gs interface is down or missing.
Force to Standby
The purpose of the Force to Standby information element is to force the MS to
change the GMM stop the READY timer in order to prevent the MS to perform
cell updates. In UMTS, the network shall always indicate force to standby not
indicated in the force to standby information element.
GPRS Timer (Periodic Routing Area Update Timer (T3312))

The purpose of the GPRS Timer information element is to specify GPRS
specific timer values, e.g. for the READY timer. The first entry in the Attach
Accept message will specify the Periodic Routing Area Update Timer.
The READY timer is not applicable for UMTS.
An MS may indicate a READY timer value to the network in the ATTACH
REQUEST and the ROUTING AREA UPDATE REQUEST messages.
If a READY timer value is received by an MS capable of both UMTS and GSM
in the ATTACH ACCEPT or the ROUTING AREA UPDATE ACCEPT
messages, then the received value shall be stored by the MS in order to be used
at an intersystem change from UMTS to GSM.
In UMTS, the timer T3312 is reset and started with its initial value, when the
MS goes from PMM-CONNECTED to PMM-IDLE mode. The timer T3312 is
stopped when the MS enters PMM-CONNECTED mode.
When timer T3312 expires, the periodic routing area updating procedure shall
be started and the timer shall be set to its initial value for the next start.
If the MS is in other state than GMM-REGISTERED.NORMAL-SERVICE
when the timer expires the periodic routing area updating procedure is delayed
until the MS returns to GMM-REGISTERED.NORMAL-SERVICE.
Radio Priority
The purpose of the Radio Priority information element is to specify the priority
level that the MS shall use at the lower layers for transmission of data related to
a PDP context or for mobile originated SMS transmission.
Routing Area Id.

Same as above.
72 (161)
Contents
Attach complete
ATTACH COMPLETE(GPRS MM)
No further Information element is included in this message
4.6.2 Service Request Procedure
The Service Request procedure is used by a 3G-MS in PMM-IDLE state to

request the establishment of a secure connection to a 3G-SGSN. The MS in
PMM-IDLE state initiates this procedure in order to send uplink signalling
messages (e.g. Activate PDP Context Request), user data, or as paging
response, or after the MS has regained radio coverage. This procedure is also
used by an MS in PMM-CONNECTED state to request resource reservation for
active PDP contexts.
4.6.2.1 MS Initiated Service Request Procedure

The MS in PMM-IDLE state sends the Service Request message to the
3G-SGSN in order to establish the PS signalling connection for the upper layer
signalling or for the resource reservation for active PDP context(s). After
receiving the Service Request message, the 3G-SGSN may perform
authentication, and it shall perform the security mode procedure. After the
establishment of the secure PS signalling connection to a 3G-SGSN, the MS
may send signalling messages, e.g. Activate PDP Context Request, to the
3G-SGSN, or the 3G-SGSN may start the resource reservation for the active
PDP contexts depending on the requested service in the Service Request
message. An MS in PMM-CONNECTED state also requests the resource
reservation for the active PDP contexts through this procedure.
73 (161)
Iu-PS Interface
MS RNC SGSN HLR GGSN

1. RRC Connection Request
1. RRC Connection Setup
2. Service Request
3. Security Functions
4. Service Accept
4. Radio Access Bearer Assignment

Request
5. Radio Bearer Setup

Complete
Response
7. SGSN-Initiated PDP Context Modification
8. Uplink PDU
Figure 28: MS Initiated Service Request Procedure
1. The MS establishes an RRC connection, if none exists for CS traffic.

2. The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type)
message to the SGSN. Service Type specifies the requested service.
Service Type shall indicate one of the following: Data or Signalling. At
this point, the SGSN may perform the authentication procedure.
If Service Type indicates Data, a signalling connection is established
between the MS and the SGSN, and resources for active PDP context(s)
are allocated, i.e. RAB establishment for the activated PDP context(s).
If Service Type indicates Signalling, the signalling connection is
established between the MS and the SGSN for sending upper-layer
signalling messages, e.g. Activate PDP Context Request. The resources
for active PDP context(s) are not allocated.
3. The SGSN shall perform the security functions if the MS in PMM-IDLE
state initiated the service request.
4. If the network is in PMM-CONNECTED state and the Service Type
indicates Data, the SGSN shall respond with a Service Accept message
towards the MS, in case the service request can be accepted. In case
Service Type indicates Data, the SGSN sends a Radio Access Bearer
74 (161)
Contents
Assignment Request (NSAPIRAB ID(s), TEID(s), QoS Profile(s), SGSN

IP Address(es)) message to re-establish radio access bearer for every
activated PDP context, except the ones having maximum bit rates for
uplink and downlink of 0 kbit/s.
5. The RNC indicates to the MS the new Radio Bearer Identity established
and the corresponding RAB ID with the RRC radio bearer setup
procedure.
6. SRNC responds with the Radio Access Bearer Assignment Response
(RAB ID(s), TEID(s), QoS Profile(s), RNC IP Address(es)) message. The
GTP tunnel(s) are established on the Iu interface. If the RNC returns a
Radio Access Bearer Assignment Response message with a cause
indicating that the requested QoS profile(s) can not be provided, e.g.
"Requested Maximum Bit Rate not Available", the SGSN may send a
new Radio Access Bearer Assignment Request message with different
QoS profile(s). The number of re-attempts, if any, as well as how the new
QoS profile(s) values are determined is implementation dependent.
7. For each RAB re-established with a modified QoS profile, the SGSN
initiates a PDP Context Modification procedure to inform the MS and the
GGSN of the new negotiated QoS profile for the corresponding PDP
context.
8. The MS sends the uplink packet.
For Service Type = Signalling, the MS knows that the Service Request
message was successfully received in the SGSN when the MS receives
the RRC Security Mode Control Command message.
For Service Type = Data, in PMM-IDLE, the MS knows that the Service
Request was successfully received when the MS receives the RRC
Security Mode Control Command message from the RNC; in PMM-
CONNECTED state, the MS knows that the Service Request was
successfully received when the MS receives the Service Accept message.
NOTE: The reception of the Service Accept message does not imply
the successful re-establishment of the RAB(s).
For any Service Type, in case the service request cannot be accepted, the
network returns a Service Reject message to the MS with an appropriate cause
value.
For Service Type = Data, in case the SGSN fails to re-establish RAB(s) for the
PDP context(s), the SGSN determines if an SM procedure, such as SGSN-
Initiated PDP Context Modification or PDP Context Deactivation, should be
initiated. The appropriate action depends on the QoS profile of the PDP context
and is an operator choice.
For each PDP context using streaming or conversational traffic class with
maximum bit rate for uplink and downlink of 0 kbit/s the MS starts the MS-
Initiated PDP Context Modification procedure or the MS-Initiated PDP Context
Deactivation procedure to inform the SGSN whether to re-activate or to delete
the PDP contexts. If the PDP context has been deactivated locally in the MS,
75 (161)
Iu-PS Interface
the MS shall not perform the PDP context deactivation procedure for this PDP
context because the list of active and inactive PDP contexts is included in the
Service Request Message sent prior to the network.
4.6.2.2 Network Initiated Service Request Procedure

When the 3G-SGSN receives a downlink packet (e.g. Request PDP Context
Activation, MT SMS, user data) for an MS in PMM-IDLE state, the 3G-SGSN
sends a paging request to UTRAN. The paging request triggers the Service
Request procedure in the MS.
MS RNC SGSN HLR GGSN
1. Downlink PDU
2. Paging
2. Paging
3. RRC Connection Request
3. RRC Connection Setup
4. Service Request
5. Security Functions

6. Radio Bearer Setup Request

Complete 6. Radio Access Bearer Assignment
Response
7. SGSN-Initiated PDP Context Modification Procedure
8. Downlink PDU
Figure 29: Network Initiated Service Request Procedure
1. The SGSN receives a downlink PDP PDU for an MS in PMM-IDLE

state.
2. The SGSN sends a Paging message to the RNC. The RNC pages the MS
by sending a Paging message to the MS. See clause "PS Paging Initiated
by 3G-SGSN without RRC Connection for CS" for details.
76 (161)
Contents
3. The MS establishes an RRC connection if none exists for CS traffic.

4. The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type)
message to the SGSN. Service Type specifies Paging Response. The
Service Request is carried over the radio in an RRC Direct Transfer
message and over the Iu interface in the RANAP Initial MS message. At
this point, the SGSN may perform the authentication procedure. The
SGSN knows whether the downlink packet requires RAB establishment
(e.g. downlink PDU) or not (e.g. Request PDP Context Activation or MT
SMS).
5. The SGSN shall perform the security mode procedure.
6. If resources for the PDP contexts are re-established, the SGSN sends a
Radio Access Bearer Assignment Request (RAB ID(s), TEID(s), QoS
Profile(s), SGSN IP Address(es)) message to the RNC. The RNC sends a
Radio Bearer Setup (RAB ID(s)) to the MS. The MS responds by
returning a Radio Bearer Setup Complete message to the RNC. The RNC
sends a Radio Access Bearer Assignment Response (RAB ID(s),
TEID(s), RNC IP Address(es)) message to the SGSN in order to indicate
that GTP tunnels are established on the Iu interface and radio access
bearers are established between the RNC and the MS. If the RNC returns
a Radio Access Bearer Assignment Response message with a cause
indicating that the requested QoS profile(s) can not be provided, e.g.
"Requested Maximum Bit Rate not Available", the SGSN may send a
new Radio Access Bearer Assignment Request message with different
QoS profile(s). The number of re-attempts, if any, as well as how the new
QoS profile(s) values are determined is implementation dependent.
7. For each RAB re-established with a modified QoS profile, the SGSN
initiates a PDP Context Modification procedure to inform the MS and the
GGSN of the new negotiated QoS profile for the corresponding PDP
context.
8. The SGSN sends the downlink packet.
For Service Type = Page Response, the MS knows that the Service
Request message was successfully received in the SGSN when the MS
receives the RRC Security Mode Control Command message.
In the case the SGSN fails to re-establish RAB(s) for the PDP context(s),
the SGSN determines if an SM procedure, such as SGSN-Initiated PDP
Context Modification or PDP Context Deactivation, should be initiated.
The appropriate action depends on the QoS profile of the PDP context and
is an operator choice.
4.6.2.3 Example Trace of the Service Request procedure

The following trace can be taken as an example for a service request procedure
on the Iu-Ps interface. It was taken using the Nethawk protocol analyser and
77 (161)
Iu-PS Interface
reflects current configurations and settings of the test-bed from where the trace
has been taken.
SERVICE REQUEST (GPRS MM)
- Skip Indicator: 00h
- value: 0 (00h)
Signalling
P-TMSI
- length: 5 (05h)
- TMSI/P-TMSI: F0E2E797
PDP context status
- length: 2
- NSAPI(5) context is PDP-INACTIVE
4.7 Session Management Procedures (SM, GSM L3)

Session Management Procedures use GSM L3 messages. GSM L3 Layer is
using the services of the RANAP Layer. Here is a list of these Procedures and
Functions:
- PDP Context Activation Procedure
- Secondary PDP Context Activation Procedure
- Network-Requested PDP Context Activation Procedure
- SGSN-Initiated PDP Context Modification Procedure
- GGSN-Initiated PDP Context Modification Procedure
- MS-Initiated PDP Context Modification Procedure
- RNC-Initiated PDP Context Modification Procedure
- RAB Release-Initiated Local PDP Context Modification Procedure
- MS Initiated PDP Context Deactivation Procedure
- PDP Context Deactivation Initiated by SGSN Procedure
78 (161)
Contents
4.7.1 PDP Context Activation Procedure in detail
The figure on the next Page shows the different messages of a PDP Context
Activation Procedure. Furthers, we will have a closer look at the procedure to
analyse the single steps that need to be performed to complete this procedure.
MS UTRAN 3G-SGSN 3G-GGSN
1. Activate PDP Context Request
C1
2. Create PDP Context Request
2. Create PDP Context Response

3. Radio Access Bearer Set-up
4. Invoke Trace
5. Update PDP Context Request
5. Update PDP Context Response
C2
6. Activate PDP Context Accept
Figure 30: PDP Context Activation Procedure for UMTS
1. The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type,
PDP Address, Access Point Name, QoS Requested, PDP Configuration
Options) message to the SGSN. The MS shall use PDP Address to
indicate whether it requires the use of a static PDP address or whether it
requires the use of a dynamic PDP address. The MS shall leave PDP
Address empty to request a dynamic PDP address. The MS may use
Access Point Name to select a reference point to a certain external
network and/or to select a service. Access Point Name is a logical name
referring to the external packet data network and/or to a service that the
subscriber wishes to connect to. QoS Requested indicates the desired QoS
profile. PDP Configuration Options may be used to request optional PDP
parameters from the GGSN (see GSM 09.60). PDP Configuration
Options is sent transparently through the SGSN.
2. The SGSN validates the Activate PDP Context Request using PDP Type
(optional), PDP Address (optional), and Access Point Name (optional)
provided by the MS and the PDP context subscription records. The
validation criteria, the APN selection criteria, and the mapping from APN
to a GGSN are described in annex A.
79 (161)
Iu-PS Interface
If no GGSN address can be derived or if the SGSN has determined that the
Activate PDP Context Request is not valid according to the rules described in
annex A, the SGSN rejects the PDP context activation request.
If a GGSN address can be derived, the SGSN creates a TEID for the requested
PDP context. If the MS requests a dynamic address, the SGSN lets a GGSN
allocate the dynamic address. The SGSN may restrict the requested QoS
attributes given its capabilities and the current load, and it shall restrict the
requested QoS attributes according to the subscribed QoS profile.
The SGSN sends a Create PDP Context Request (PDP Type, PDP Address,
Access Point Name, QoS Negotiated, TEID, NSAPI, MSISDN, Selection
Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id,
OMC Identity, PDP Configuration Options) message to the affected GGSN.
Access Point Name shall be the APN Network Identifier of the APN selected
according to the procedure described in Annex A. PDP Address shall be empty
if a dynamic address is requested. The GGSN may use Access Point Name to
find an external network and optionally to activate a service for this APN.
Selection Mode indicates whether a subscribed APN was selected, or whether a
non-subscribed APN sent by an MS or a non-subscribed APN chosen by the
SGSN was selected. Selection Mode is set according to Annex A. The GGSN
may use Selection Mode when deciding whether to accept or reject the PDP
context activation. For example, if an APN requires subscription, the GGSN is
configured to accept only the PDP context activation that requests a subscribed
APN as indicated by the SGSN with Selection Mode. Charging Characteristics
indicates which kind of charging the PDP context is liable for. The charging
characteristics on the GPRS subscription and individually subscribed APNs as
well as the way the SGSN handles Charging Characteristics and chooses to send
them or not to the GGSN is defined in 3G TS 32.015 [70]. The SGSN shall
include Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN
trace is activated. The SGSN shall copy Trace Reference, Trace Type, and
OMC Identity from the trace information received from the HLR or OMC.
The GGSN creates a new entry in its PDP context table and generates a
Charging Id. The new entry allows the GGSN to route PDP PDUs between the
SGSN and the external PDP network, and to start charging. The way the GGSN
handles Charging Characteristics that it may have received from the SGSN is
defined in 3G TS 32.015. The GGSN then returns a Create PDP Context
Response (TEID, PDP Address, PDP Configuration Options, QoS Negotiated,
Charging Id, Cause) message to the SGSN. PDP Address is included if the
GGSN allocated a PDP address. If the GGSN has been configured by the
operator to use External PDN Address Allocation for the requested APN, PDP
Address shall be set to 0.0.0.0, indicating that the PDP address shall be
negotiated by the MS with the external PDN after completion of the PDP
Context Activation procedure. The GGSN shall relay, modify and monitor these
negotiations as long as the PDP context is in ACTIVE state, and use the GGSN-
Initiated PDP Context Modification procedure to transfer the currently used
PDP address to the SGSN and the MS. PDP Configuration Options contain
optional PDP parameters that the GGSN may transfer to the MS. These optional
PDP parameters may be requested by the MS in the Activate PDP Context
80 (161)
Contents
Request message, or may be sent unsolicited by the GGSN. PDP Configuration

Options is sent transparently through the SGSN. The Create PDP Context
messages are sent over the backbone network.
If QoS Negotiated received from the SGSN is incompatible with the PDP
context being activated, the GGSN rejects the Create PDP Context Request
message. The GGSN operator configures the compatible QoS profiles.
3. In Iu mode, RAB set-up is done by the RAB Assignment procedure, see
“RAB Assignment Procedure” in RANAP chapter.
4. In Iu mode and if BSS trace is activated, the SGSN shall send an Invoke
Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message
to the UTRAN. Trace Reference, and Trace Type are copied from the
trace information received from the HLR or OMC.
5. In Iu mode and in case the QoS attributes have been downgraded in step
3, the SGSN may inform the GGSN about the downgraded QoS attributes
by sending an Update PDP Context Request to the affected GGSN. The
GGSN confirms the new QoS attributes by sending an Update PDP
Context Response to the SGSN.
6. The SGSN inserts the NSAPI along with the GGSN address in its PDP
context. If the MS has requested a dynamic address, the PDP address
received from the GGSN is inserted in the PDP context. The SGSN
selects Radio Priority and Packet Flow Id based on QoS Negotiated, and
returns an Activate PDP Context Accept (PDP Type, PDP Address, TI,
QoS Negotiated, Radio Priority, Packet Flow Id, PDP Configuration
Options) message to the MS. The SGSN is now able to route PDP PDUs
between the GGSN and the MS, and to start charging.
For each PDP Address a different quality of service (QoS) profile may be
requested. For example, some PDP addresses may be associated with E-mail
that can tolerate lengthy response times. Other applications cannot tolerate
delay and demand a very high level of throughput, interactive applications being
one example. These different requirements are reflected in the QoS profile. The
QoS profile is defined in sub-clause “Quality of Service Profile”. If a QoS
requirement is beyond the capabilities of a PLMN, the PLMN negotiates the
QoS profile as close as possible to the requested QoS profile. The MS either
accepts the negotiated QoS profile, or deactivates the PDP context.
After an SGSN has successfully updated the GGSN, the PDP contexts
associated with an MS is distributed as shown in clause “Information Storage”.
If the PDP Context Activation Procedure fails or if the SGSN returns an
Activate PDP Context Reject (Cause, PDP Configuration Options) message, the
MS may attempt another activation to the same APN up to a maximum number
of attempts.
CAMEL procedure calls shall be performed, see referenced procedures in 3G
TS 23.078:
C1) CAMEL_GPRS_PDP_Context_Establishment.
81 (161)
Iu-PS Interface
C2) CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement.
4.7.1.1 Example Trace of the PDP Context Activation Procedure

In this chapter, we will have a look at 'normal' PDP Context Activation
messages. 'Normal' here means, that the system is configured to provide full
service and we are not expecting extraordinary reactions.
4.7.1.2 PDP Context Activation Request

The first trace shows us a PDP Context Activation message.
ACT. PDP CONTEXT REQUEST (GPRS SM)
Network Serv. Access Point Id
- NSAPI 5
LLC Serv. Access point Id
- SAPI 3
Quality of Service
- length: 11 (0Bh)
- Reliab. class: Subscribed (MS only)
- Delay class: Subscribed
- Precedence class: Subscribed
- Peak throughput: Subscribed
- Mean throughput: Best effort
- Traffic class: Subscribed
- Delivery order: Subscribed
- Delivery of erroneous SDUs: Subscribed
- Maximum SDU size: Subscribed maximum SDU size
- Maximum bit rate for uplink: Subscribed (MS only)
- Maximum bit rate for downlink: Subscribed (MS only)
- Residual BER: Subscribed
- SDU error ratio: Subscribed
- Transfer delay: Subscribed (MS only)
- Traffic handling priority: Subscribed
- Guaranteed bit rate for uplink: Subscribed (MS only)
- Guaranteed bit rate for downlink: Subscribed (MS only)
Packet Data Protocol Address
- Length: 2 (02h)
- Dynamic PDP addressing is applied
- PDP type organisation: IETF allocated address
- PDP type number: IPv4
Protocol Conf. Options
- length: 37 (25h)
- Configuration protocol: IP PDP type
Password Authentic. Protocol (PAP)
Internet Protocol Control Protocol (IPCP)
Contents: 01 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00
In the PDP Context Activation Request message, we again find a list of

parameters, which need further explanation. A basic idea here is, that the mobile
has the chance to request certain features, values or qualities, which might be
82 (161)
Contents
conceded or downgraded or even rejected by the PDP Context Activation

Response.
The PDP Context Activation Request contains:
Network Serv. Access Point Id.
The purpose of the Network Service Access Point Identifier information

element is to identify the service access point that is used for the GPRS data
transfer at layer 3. An NSAPI is assigned when the MS initiates the PDP
Context Activation function.
LLC Service Access point Id
The purpose of the LLC Service Access Point Identifier information element is
to identify the service access point that is used for the GPRS data transfer at
LLC layer.
SAPI identifies a point at which LLC services are provided by a Logical Link
Entity (LLE) to a layer-3 entity. Consequently, SAPI identifies an LLE that
should process an LLC frame and also a layer-3 entity that is to receive
information carried by the LLC frame.
SAPI is a four bit field. Possible values are:
SAPI Related Service
1 GPRS Mobility Management
3 User data 1
5 User data 2
7 SMS
9 User data 3
11 User data 4
Other values are reserved

In UMTS, both the network and the MS shall store the LLC SAPI and the radio
priority in the PDP context. If a UMTS to GSM system change is performed,
the new SGSN shall initiate establishment of the logical link using the
negotiated QoS profile, the negotiated LLC SAPI, and selected radio priority
level stored in the PDP context as in a GSM to GSM Routing Area Update.
An MS, which is capable of operating in both GSM and UMTS, shall use a
valid LLC SAPI, while an MS which is capable of operating only in UMTS
shall indicate the LLC SAPI value as “LLC SAPI not assigned” in order to
avoid unnecessary value range checking and any other possible confusion in the
network. When the MS uses a valid LLC SAPI, the network shall return a valid
LLC SAPI. However, in this version of the protocol, if the network does not
support handover to GSM, it may return the “LLC SAPI not assigned” value.
83 (161)
Iu-PS Interface
NOTE: The radio priority level and the LLC SAPI parameters, though not
used in UMTS, shall be included in the messages, in order to support handover
between UMTS and GSM networks.
Quality of Service
The purpose of the quality of service information element is to specify the QoS
parameters for a PDP context. . The trace shows sub-fields of which possible
values are as follows:
The quality of service is a type 4 information element with a length of 13 octets.
The QoS requested by the MS shall be encoded both in the QoS attributes
specified in octets 3-5 and in the QoS attributes specified in octets 6-13.
A QoS IE received without octets 6-13 shall be accepted by a receiving entity.
NOTE: This behaviour is required for interworking with entities supporting
an earlier version of the protocol.
The quality of service information element is coded as shown in figure below:
8 7 6 5 4 3 2 1
Quality of service IEI Octet 1
Length of quality of service IE Octet 2
0 0 Delay Reliability Octet 3
spare class class
Peak 0 Precedence Octet 4
throughput spare class
0 0 0 Mean Octet 5
spare throughput
Traffic Class Delivery order Delivery of erroneous Octet 6
SDU
Maximum SDU size Octet 7
Maximum bit rate for uplink Octet 8
Maximum bit rate for downlink Octet 9
Residual BER SDU error ratio Octet 10
Transfer delay Traffic Handling Octet 11
priority
Guaranteed bit rate for uplink Octet 12
Guaranteed bit rate for downlink Octet 13
Figure 31: Quality of service information element
84 (161)
Contents
Reliability class, 3 bits
value Reliability class

0 Subscribed
1 Ack. GTP, LLC, and RLC Protected data
2 Unacknowledged GTP Ack. LLC and RLC Protected data
3 Unacknowledged GTP and LLC Ack. RLC Protected data
4 Unacknowledged GTP, LLC and RLC Protected data
5 Unacknowledged GTP, LLC and RLC Unprotected data
Delay class, 3 bits
value Delay class text

0 Subscribed
1 Delay class 1
2 Delay class 2
3 Delay class 3
4 Delay class 4 (best effort)
Precedence class, 3 bits
value Precedence class text

0 Subscribed
1 High priority
2 Normal priority
3 Low priority
Peak throughput, 4 bits
value Peak throughput text

0 Subscribed
1 Up to 1 000 octet/s
85 (161)
Iu-PS Interface
Mean throughput, 5 bits
value Mean throughput text

0 Subscribed mean throughput
1 100 octet/h
2 200 octet/h
3 500 octet/h
4 1 000 octet/h
5 2 000 octet/h
6 5 000 octet/h
7 10 000 octet/h
8 20 000 octet/h
9 50 000 octet/h
10 100 000 octet/h
11 200 000 octet/h
12 500 000 octet/h
13 1 000 000 octet/h
14 2 000 000 octet/h
15 5 000 000 octet/h
16 10 000 000 octet/h
17 20 000 000 octet/h
18 50 000 000 octet/h
31 Best effort, indicates that throughput shall be made available to the
MS on a per need and availability basis.
86 (161)
Contents
Traffic class, 3 bits
value Traffic class text

0 Subscribed
1 Conversational class
2 Streaming class
3 Interactive class
4 Background class
Delivery order, 2 bits
value Delivery order text

0 Subscribed
1 With delivery order ('yes')
2 Without delivery order ('no')
Delivery of erroneous SDUs, 3 bits

0 Subscribed
1 Erroneous SDUs are delivered ('yes')
2 Erroneous SDUs are not delivered ('no')
Maximum SDU size, 8 bits

0 Subscribed
1-150 1*10-150*10 octets
151 1502 octets
152 1510 octets
153 1520 octets
87 (161)
Iu-PS Interface
Maximum bit rate for uplink, 8 bits

0 Subscribed
1-63 1 kbps-63 kbps
64-127 (value-64)*8 kbps+64kbps
128-254 (value-128)*64k bps+576 kbps
255 0 kbps
Maximum bit rate for downlink, 8 bits
Coding is identical to that of Maximum bit rate for uplink
Residual Bit Error Rate (BER), 4 bits
value Residual Bit Error Rate (BER) text

0 Subscribed
1 5*10-2
2 1*10-2
3 5*10-3
4 4*10-3
5 1*10-3
6 1*10-4
7 1*10-5
8 1*10-6
9 6*10-8
SDU error ratio, 4 bits
value SDU error ratio text

0 Subscribed
1 1*10-2
2 7*10-3
3 1*10-3
4 1*10-4
5 1*10-5
6 1*10-6
7 1*10-1
88 (161)
Contents
Traffic handling priority, 2 bits
value Traffic handling priority text

0 Subscribed
1 Priority level 1
2 Priority level 2
3 Priority level 3
The Traffic handling priority value is ignored if the Traffic Class is
Conversation class, Streaming class or Background class.
Transfer delay, 6 bits
value Transfer delay text

1-15 10 ms-150 ms
16-31 200 ms + (value-16)*50
32-62 1000 ms + (value-32)*100 ms
The Transfer delay value is ignored if the Traffic Class is Interactive class or
Background class.
Guaranteed bit rate for uplink, 8 bits

The Guaranteed bit rate for uplink value is ignored if the Traffic Class is
Interactive class or Background class, or Maximum bit rate for uplink is set to
0kbps.
Guaranteed bit rate for downlink, 8 bits

The Guaranteed bit rate for downlink value is ignored if the Traffic Class is
Interactive class or Background class, or Maximum bit rate for uplink is set to
0kbps.
The purpose of the Packet Data Protocol Address information element is to

identify an address associated with a PDP. If no address is transferred, dynamic
addressing applies.
89 (161)
Iu-PS Interface
In case of static addressing, two more sub-fields will be included:
PDP type organisation
value PDP type organisation text

0000 ETSI allocated address
0001 IETF allocated address
PDP type number
If PDP type organisation is ETSI allocated address:

value PDP type number text
any X.121 address
If PDP type organisation is IETF allocated address:
value PDP type number text
21h IPv4 address
57h IPv6 address
Protocol Configuration Options
The purpose of the Protocol Configuration Options information element is to

transfer external network protocol options associated with a PDP context
activation. The only configuration protocol currently used is PPP. For PPP, we
can find a configuration protocol options list:
Each option unit is of variable length and consists of a
1. Protocol Identifier consisting of 2 octets
Value Protocol ID text
C021h Link Control Protocol (LCP)
C023h Password Authentication Protocol (PAP)
C223h Challenge Handshake Authentic. Protocol (CHAP)
8021h Internet Protocol Control Protocol (IPCP)
2. the length of the Protocol Identifier contents of the unit (1 octet)
3. the Protocol Identifier contents itself (n octets)
90 (161)
Contents
4.7.2 PDP Context Activation Response
The following trace shows the response send by the SGSN.

ACT. PDP CONTEXT ACCEPT (GPRS SM)
- SAPI 3
Quality of Service
- length: 11 (0Bh)
- Reliab. class: Unack. GTP and LLC Ack. RLC Protected data
- Delay class: Delay class 4 (best effort)
- Precedence class: Normal priority
- Peak throughput: Up to 16 000 octet/s
- Traffic class: Background class
- Delivery order: Without delivery order ('no')
- Delivery of erroneous SDUs: No detect (‘-‘)
- Maximum SDU size: 1510 Octets
- Maximum bit rate for uplink: 64 kbps
- Maximum bit rate for downlink: 128 kbps
- Residual BER: 1*10-5
- SDU error ratio: 1*10-3
- Traffic handling priority: level 2
Radio Priority
- Priority level 4
- Length: 6 (06h)
- Address: 10.1.1.133
- length: 20 (14h)
Contents: 03 05 00 10 81 06 7F 00 00 01 83 06 7F 5E 00 00 01
The information elements of the PDP Context Response contain information

about the negotiated and conceded values of requested parameters to the mobile.
Please refer to the PDP Context Activation Request chapter for further
information on LLC Service Access Point Identifier, Quality of Service, Packet
Data Protocol Address and Protocol Conf. Options.
91 (161)
Iu-PS Interface
Radio Priority, 3 bits
The purpose of the Radio Priority information element is to specify the priority
level that the MS shall use at the lower layers for transmission of data related to
a PDP context or for mobile originated SMS transmission.
Value Radio Priority text
1. priority level 2
2. priority level3
3. priority level 4 (lowest)
4. priority level 1 (highest)
92 (161)
Contents
5 Iu-PS User Plane

A reference configuration for the Iu interface user plane is given in Figure 25.
Application
E.g., IP, E.g., IP,

PPP PPP
Relay Relay
PDCP PDCP GTP-U GTP-U GTP-U GTP-U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC AAL5 AAL5 L2 L2

L1 L1 ATM ATM L1 L1
Uu Iu-PS Gn Gi
MS UTRAN 3G-SGSN 3G-GGSN
Figure 32: Iu-PS User Plane
Packet Data Convergence Protocol (PDCP): This transmission functionality

maps higher-level characteristics onto the characteristics of the underlying
radio-interface protocols. PDCP provides protocol transparency for higher-layer
protocols. PDCP supports e.g., IPv4, PPP and IPv6. Introduction of new higher-
layer protocols shall be possible without any changes to the radio-interface
protocols. PDCP provides protocol control information compression. PDCP is
specified in 3G TS 25.323.
Unlike in A/Gb mode, user data compression is not supported in Iu mode,
because the data compression efficiency depends on the type of user data, and
because many applications compress data before transmission. It is difficult to
check the type of data in the PDCP layer, and compressing all user data requires
too much processing.
 GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol
tunnels user data between UTRAN and the 3G-SGSN, and between the
GSNs in the backbone network. GTP encapsulates all PDP PDUs. GTP is
 UDP/IP: These are the backbone network protocols used for routeing user
data and control signalling. Though IPv6 can optionally be used, when
GSNs or RNCs can potentially communicate with other GSNs or RNCs
supporting only IPv4 (e.g. at inter SGSN routeing area update or SRNS
relocation), the use of IPv6 is not recommended in this release of the
93 (161)
Iu-PS Interface
standards, as contexts cannot be transferred between GSNs or RNCs

supporting different IP versions.
 Asynchronous Transfer Mode (ATM): The information to be transmitted
is divided into fixed-size cells (53 octets), multiplexed, and transmitted.
ATM is specified in ITU-T Recommendation I.361: “B-ISDN ATM
Layer Specification”.
 ATM Adaptation Layer 5 (AAL5): This adaptation layer protocol
provides support for variable-bit rate connection-oriented or
connectionless data services. AAL5 is specified in ITU-T
Recommendation I.363.5: “B-ISDN ATM Adaptation Layer
Specification: Type 5 AAL”.
 Radio Link Control (RLC): The RLC protocol provides logical link
control over the radio interface. There may be several simultaneous RLC
links per MS. Each link is identified by a Bearer Id. RLC is defined in 3G
TS 25.322.
 Medium Access Control (MAC): The MAC protocol controls the access
signalling (request and grant) procedures for the radio channel. MAC is
94 (161)
Contents
5.1 IuPS User Plane Protocol Stack
Figure 33: User Plane protocol stacks for Iu-PS
5.1.1 UDP/IP
UDP/IP is the only path protocol defined to transfer GTP messages in the
version 1 of GTP. A User Datagram Protocol (UDP) compliant with RFC 768
shall be used.
5.1.1.1 UDP Header
Request Messages
The UDP Destination Port number for GTP-C request messages is 2123. It is
the registered port number for GTP-C.
The UDP Destination Port number for GTP-U request messages is 2152. It is
the registered port number for GTP-U.
95 (161)
Iu-PS Interface
The UDP Source Port is a locally allocated port number at the sending
GSN/RNC.
Response Messages
The UDP Destination Port value shall be the value of the UDP Source Port of
the corresponding request message.
The UDP Source Port shall be the value from the UDP Destination Port of the
corresponding request message.
Encapsulated T-PDUs
The UDP Destination Port number shall be 2152. It is the registered port
number for GTP-U. The UDP Source Port is a locally allocated port number at
the sending GSN/RNC.
Error Indication, Version Not Supported and Supported Extension Headers

Notification
The UDP destination port for the Error Indication shall be the user plane UDP
port (2152).
The UDP destination port for the Version Not Supported message shall be the
control plane UDP port (2123)
The UDP destination port for the Supported Extension Headers Notification
shall be the UDP port for User plane (2152) if the trigger for it was a user plane
message, the control plane port (2123) if the trigger for it was a control plane
message.
The UDP source port shall be locally assigned at the sending node.
5.1.1.2 IP Header
An Internet Protocol (IP) compliant with RFC 791 shall be used.
Request Messages and Encapsulated T-PDUs
The IP Source Address shall be an IP address of the source GSN/RNC from

which the message is originating.
96 (161)
Contents
The IP Destination Address in a GTP request message shall be an IP address of

the destination GSN/RNC. The IP Destination Address in an encapsulated T-
PDU GTP shall be an IP address of the destination GSN/RNC.
Response Messages
The IP Source Address shall be an IP address of the source GSN/RNC from

which the message is originating.
The IP Destination Address shall be copied from the IP Source Address of the
GTP request message to which this GSN/RNC is replying.
Error Indication, Version Not supported and Supported Extension Headers

Notification
The IP source address shall be an address of the source GSN/RNC from which
the message is originated. In particular, the source Address of the “Version Not
Supported” or the “Supported Extension Headers Notification” message, shall
be set to the destination address of the message that triggered the GSN/RNC to
send the “Version Not Supported” or the “Supported Extension Headers
Notification” message.
The IP destination address shall be the source address of the GTP-PDU that is
the cause for the GSN/RNC to send one of these messages.
5.1.2 GTP-U
GTP-U Tunnels are used to carry encapsulated T-PDUs and signalling
messages between a given pair of GTP-U Tunnel Endpoints. The Tunnel
Endpoint ID (TEID), which is present in the GTP header, shall indicate which
tunnel a particular T-PDU belongs to. In this manner, packets are multiplexed
and de-multiplexed by GTP-U between a given pair of Tunnel Endpoints. The
TEID value to be used in the TEID field shall be negotiated for instance during
the GTP-C Create PDP Context and the RAB assignment procedures that take
place on the control plane.
The maximum size of a T-PDU that may be transmitted without fragmentation
by GGSN or the MS is defined in 3GPP TS 23.060. The GGSN shall fragment,
reject or discard T-PDUs, depending on the PDP type and implementation
decisions, directed to the MS if the T-PDU size exceeds the maximum size. The
decision if the T-PDUs shall be fragmented or discarded is dependent on the
external packet data network protocol.
97 (161)
Iu-PS Interface
5.1.2.1 GTP-U Protocol Entity
The GTP-U protocol entity provides packet transmission and reception services
to user plane entities in the GGSN, in the SGSN and, in UMTS systems, in the
RNC. The GTP-U protocol entity receives traffic from a number of GTP-U
tunnel endpoints and transmits traffic to a number of GTP-U tunnel endpoints.
There is a GTP-U protocol entity per IP address.
The TEID in the GTP-U header is used to de-multiplex traffic incoming from
remote tunnel endpoints so that it is delivered to the User plane entities in a way
that allows multiplexing of different users, different packet protocols and
different QoS levels. Therefore no two remote GTP-U endpoints shall send
traffic to a GTP-U protocol entity using the same TEID value except for data
forwarding as part of the SRNS relocation or Intersystem Change procedures.
5.1.2.2 Protocol Stack
The GTP-U protocol is used to transmit T-PDUs between GSN pairs (or
between an SGSN and an RNC in UMTS), encapsulated in G-PDUs. A G-PDU
is a packet including a GTP-U header and a T-PDU. The Path Protocol defines
the path and the GTP-U header defines the tunnel. Several tunnels may be
multiplexed on a single path. The frames have the following general structure.
End user prot. End user prot.
GTP-U GTP-U
Path Protocol Path Protocol
Iu-PS
RNC SGSN
Figure 34: GTP-U over the Iu
Usage of the GTP-U Header

The GTP-U header shall be used as specified in clause 6 with the following
details:
- Version shall be set to decimal 1 ('001').
- Protocol Type flag (PT) shall be set to '1'.
98 (161)
Contents
- If the Sequence Number flag (S) is set to '1' the sequence number field is
present and meaningful otherwise it is set to '0'. For GTP-U messages Echo
Request, Echo Response, Error Indication and Supported Extension
Headers Notification, the S flag shall be set to '1'.
- N-PDU Number flag (PN): the GTP-U header contains a meaningful N-
PDU Number field if the PN flag is set to 1.
- Message Type shall be set according to table 1. The value 255 is used when
T-PDUs are transmitted. The value 1 and 2 are used for “Echo” messages.
The value 26 is used for “Error Indication” message. The value 31 is used
for “Supported Extension Headers Notification” message.
- Length: This field indicates the length in octets of the payload, i.e. the rest
of the packet following the mandatory part of the GTP header (that is the
first 8 octets). The Sequence Number, the N-PDU Number or any Extension
headers shall be considered to be part of the payload, i.e. included in the
length count.
- Sequence Number: This field is meaningful if and only if the S field is set to
1. Its presence is defined in clause 6. The handling of this field is specified
in sub-clause 9.1.1. It shall be used in order to decide whether or not to
discard a received T-PDU, as specified in sub-clause 9.3.1.1 Usage of the
Sequence Number or as a transaction identity for GTP-U signalling
messages having a response message defined for a request message. For
GTP-U message, Supported Extension Headers Notification and Error
Indication, the Sequence Number shall be ignored by the receiver.
- N-PDU Number: This field is meaningful if and only if the PN flag is set to
1. Its presence is defined in clause 6. In this case, the old SGSN (or RNC)
uses it, at the Inter SGSN Routeing Area Update procedure (or SRNS
relocation), to inform the new SGSN (or RNC) of the N-PDU number
assigned to T-PDU. If an N-PDU number was not assigned to the T-PDU
by PDCP, or if the T-PDU is to be transferred using unacknowledged peer-
to-peer LLC operation, then PN shall be set to 0.
- TEID: Contains the Tunnel Endpoint Identifier for the tunnel to which this
T-PDU belongs. The TEID shall be used by the receiving entity to find the
PDP context, except for the following cases.
- The Echo Request/Response and Supported Extension Headers notification
messages, where the Tunnel Endpoint Identifier shall be set to all zeros.
- The Error Indication message where the Tunnel Endpoint Identifier shall be
set to all zeros.
Usage of Sequence Number

The sending GGSN and SRNC shall use 0 for the value of the Sequence
Number of the first G-PDU in a tunnel, only during the PDP context activation,
and shall increment the Sequence Number for each following G-PDU. The
value shall wrap to zero after 65535.
99 (161)
Iu-PS Interface
The receiving GGSN and SRNC shall set the content of a counter to zero, only
during the PDP context activation. When the receiving GGSN and SRNC
receive a valid G-PDU, it shall increment this counter by one. This counter shall
wrap to zero after 65535. It defines the 'Expected Sequence Number'.
Based on the received and Expected Sequence Number values, the receiving
GGSN and SRNC may decide whether or not to discard the received G-PDU.
Annex A (Informative) describes a method to determine whether a received G-
PDU is valid.
The receiving GGSN and SRNC shall reorder the incoming T-PDUs in
sequence if the Reordering Required flag in the PDP context is set. In this case,
if needed, the receiving GGSN and SRNC shall take into account a maximum
number of valid received frames and a maximum elapsed time to assume that a
G-PDU was lost.
The G-PDU sequence numbers allocated by the GGSN (down-link) and SRNC
(uplink) are kept unchanged irrespective of the number of GTP tunnels the PDU
is transferred over. Therefore, SGSN shall use on the Iu interface for down-link
PDUs the G-PDU sequence number received from the GGSN, and shall use on
the Gn interface for uplink PDUs the G-PDU sequence number received from
the SRNC. In case of SRNS relocation and intersystem change, the SRNC and
SGSN shall tunnel PDUs without changing the G-PDU sequence numbers.
5.2 Iu UP Protocol Layer

The Iu UP protocol is located in the User plane of the Radio Network layer over
the Iu interface: the Iu UP protocol layer.
The Iu UP protocol is used to convey user data associated to Radio Access
Bearers.
One Iu UP 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 several Iu UP protocol instances.
Iu UP protocol instances exist at Iu access point as defined [2] i.e. at CN and
UTRAN. Whenever a RAB requires transfer of user data in the Iu UP, an Iu UP
protocol instance exists at each Iu interface access points. These Iu UP protocol
instances are established, relocated and release together with the associated
RAB.
Whether these peer protocol instances perform some RAB related function
depends on the mode of operation of the Iu UP as defined below.
The following figure illustrates the logical placement of the Iu UP protocol
layer and the placement of the Data Streams sources outside of the Access
Stratum.
100 (161)
Contents
NAS Data NAS Data

Streams Non-Access Stratum Streams
Radio Radio Iu UP Iu UP
proto- proto-
cols
cols User plane Transport User plane
Data Layer Data
Bearers Bearers
protocols protocols
Access Stratum
UE UTRAN CN
Radio Iu
(Uu)
Figure 35: Iu UP protocol layer occurrence in UTRAN overall architecture (User

Plane View)
5.2.1 Iu UP protocol modes of operation
The Iu UP protocol operates in mode according to the concept described in

earlier sub-clause.
Modes of operation of the protocol are defined:
1. Transparent mode (TrM);
2. Support mode for predefined SDU size (SMpSDU).
Determination of the Iu UP protocol instance mode of operation is a CN

decision taken at RAB establishment based on e.g. the RAB characteristics. It is
signalled in the Radio Network layer control plane at RAB assignment and
relocation for each RAB. It is internally indicated to the Iu UP protocol layer at
user plane establishment.
The choice of a mode is bound to the nature of the associated RAB and cannot
be changed unless the RAB is changed.
5.2.1.1 Transparent mode (TrM)

The transparent mode is intended for those RABs that do not require any
particular feature from the Iu UP protocol other than transfer of user data.
101 (161)
Iu-PS Interface
The following figure illustrates the transparent mode of operation of the Iu UP

protocol layer.
Iu Interface
UTRAN CN
RNL-SAP Non Access

Stratum
Access Stratum
Iu UP layer in Iu UP layer in
transparent mode transparent mode
Radio Interface
Protocols
TNL-SAP TNL-SAP
Figure 36: Iu UP protocol layer in transparent occurrence over Iu interface
In this mode, the Iu UP protocol instance does not perform any Iu UP protocol
information exchange with its peer over the Iu interface: no Iu frame is sent.
The Iu UP protocol layer is crossed through by PDUs being exchanged between
upper layers and transport network layer.
For instance, the transfer of GTP-U PDUs could utilise the transparent mode of
the Iu UP protocol.
The Iu UP layer in transparent mode is present in the Iu User plane for
transferring data transparently over the Iu interface.
The two strata communicate through a Service Access Point for Non Access
Stratum (NAS) Data Streams transfer.
Interfaces of the Iu UP protocol layer in transparent mode are the transport
network layer and the upper layers. The Iu UP protocol layer in transparent
mode is an empty layer through which NAS Data Streams PDUs are crossing
between the Transport Network Layer and upper layers.
The Iu UP protocol layer in transparent mode is using services of the Transport
layers in order to transfer the Iu UP PDUs over the Iu interface.
102 (161)
Contents
5.2.1.2 Support mode

The support modes are intended for those RABs that do require particular
features from the Iu UP protocol in addition to transfer of user data. When
operating in a support mode, the peer Iu UP protocol instances exchange Iu UP
frames whereas in transparent mode, no Iu UP frames are generated.
The following figure illustrates the functional model of the Iu UP protocol layer
in support mode of operation.
Iu Interface
UTRAN CN
RNL-SAP Non Access

Stratum
Access Stratum
Iu UP layer in Iu UP layer in
support mode support mode
Radio Interface
Support Mode Support Mode

Protocols
Functions Functions
Transfer of Iu
UP protocol
frames
TNL-SAP TNL-SAP
Figure 37: Iu UP protocol layer in support mode occurrence over Iu interface
Some RABs requesting Iu UP protocol support, constrain the Iu UP protocol

and possibly the radio interface protocols in specific ways. For instance, certain
RABs can have variable predefined rates.
The Iu UP support mode is prepared to support variations.
The only support mode defined here is the:
- Support mode for predefined SDU size (SMpSDU).
For instance, the transfer of AMR speech PDUs would utilise the support mode
for predefined SDU size of the Iu UP protocol because it requires some
Procedure Control functions and some NAS Data Streams specific functions
while the sizes of the user data being transferred can vary in a predefined
manner.
103 (161)
Iu-PS Interface
The Iu UP protocol layer in Support mode is present for data streams that need
frame handling in the UP.
The two strata communicate through a Service Access Point for Non Access
Stratum (NAS) Data Streams transfer.
5.3 GTP-U Message

ATM Conn:1 VPI:0 VCI:100 CID:0 Line:1 7983 15:48:22.538714
AAL5
CPCS-PDU
AA AA 03 00 00 00 08 00 45 00 00 60 30 EB 00 00 3F 11 C7 90 0A 0A 0A 1F
0A DE 64 0B 05 27 08 68 00 4C 3D 7A 30 FF 00 3C 00 00 00 00 45 00 00 3C
C2 2E 00 00 FD 01 6A BC C0 A8 03 3C C0 A8 0C 49 00 00 A3 5B 16 00 9C 00
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61
62 63 64 65 66 67 68 69
CIP (Classic IP layer)
- LLC Header: SNAP AAAA03h
SNAP Header
- OUI: Ethertype
- PID: IPv4
CIP Data:
45 00 00 60 30 EB 00 00 3F 11 C7 90 0A 0A 0A 1F 0A DE 64 0B 05 27 08 68
00 4C 3D 7A 30 FF 00 3C 00 00 00 00 45 00 00 3C C2 2E 00 00 FD 01 6A BC
C0 A8 03 3C C0 A8 0C 49 00 00 A3 5B 16 00 9C 00 61 62 63 64 65 66 67 68
69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
IP DATAGRAM
IP version : 4
Internet header length (in octets) : 20
Type of service :
- 000 - Routine
- normal delay (minimize delay)
- normal throughput
- normal reliability
Total length (in octets) : 96
Identification : 12523 (30EB)
Flags:
- May fragment
- Last fragment
Fragment offset (in octets) : 0
Time to live (in seconds) : 63
Next level protocol : UDP
Checksum : 51088 (C790)
Source address : 10.10.10.31
Destination address : 10.222.100.11
data:
05 27 08 68 00 4C 3D 7A 30 FF 00 3C 00 00 00 00 45 00 00 3C C2 2E 00 00
FD 01 6A BC C0 A8 03 3C C0 A8 0C 49 00 00 A3 5B 16 00 9C 00 61 62 63 64
65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65
66 67 68 69
UDP DATAGRAM
104 (161)
Contents
Source port: 1319

Destination port: 2152
Length: 76
Checksum: 15738 (3D7A)
data:
30 FF 00 3C 00 00 00 00 45 00 00 3C C2 2E 00 00 FD 01 6A BC C0 A8 03 3C
C0 A8 0C 49 00 00 A3 5B 16 00 9C 00 61 62 63 64 65 66 67 68 69 6A 6B 6C
6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
G-PDU
- Version number: 1 (1h)
- Protocol type: 1 (1h)
- Extension header flag: 0 (0h)
- Sequence number flag: 0 (0h)
- N-PDU number flag: 0 (0h)
- Message Type: 255 (G-PDU)
- Header Length: 60 (3ch)
- Tunnel endpoint id: 0 (00000000h)
45 00 00 3C C2 2E 00 00 FD 01 6A BC C0 A8 03 3C C0 A8 0C 49 00 00 A3 5B
16 00 9C 00 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74
75 76 77 61 62 63 64 65 66 67 68 69
Transparent Iu UP
IP DATAGRAM
IP version : 4
Internet header length (in octets) : 20
Type of service :
- 000 - Routine
- normal delay (minimize delay)
- normal throughput
- normal reliability
Total length (in octets) : 60
Identification : 49710 (C22E)
Flags:
- May fragment
- Last fragment
Fragment offset (in octets) : 0
Time to live (in seconds) : 253
Next level protocol : ICMP
Checksum : 27324 (6ABC)
Source address : 192.168.3.60
Destination address : 192.168.12.73
data:
00 00 A3 5B 16 00 9C 00 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
105 (161)
Iu-PS Interface
6 SGSN SG6.0 Iu over IP
6.1.1 SGSN SG6.0 Iu over IP Control Plane and User Plane stacks
Figure 38: Iu over IP interface protocol stacks in SGSN SG6.0
RANAP messages from the SGSN (both to the RNC and the MS) are
transferred over IP protocol using SS7 over IP (SIGTRAN) stack.
The user PDP context data, tunnelled over IP, forms the user plane of the Iu
interface. The GPRS Tunnelling Protocol (GTP) has been adopted as the user
plane technology on the Iu interface. The GTP used for the user plane is called
GTP-U. This is to separate it from the GTP control plane protocol – GTP-C –
that is used on the Gn interface. Signalling (tunnel management) on the Iu is
handled by the control plane (RANAP) procedures.
106 (161)
Contents
6.1.2 Iu over IP Control Plane SIGTRAN protocols
The IETF SIGTRAN protocols change the three lowest layers (Message
Transfer Part (MTP) layers 1-3) of narrowband SS7 signalling protocol stacks,
while the upper layers stay the same as with PCM based signalling. The main
enabling protocol for Internet Protocol (IP) -based signalling transfer is the
Stream Control Transmission Protocol (SCTP). This protocol was specifically
designed to support capabilities similar to those found in Message Transfer Part
(MTP), but on an unreliable IP transport.
The IETF SIGTRAN working group has defined multiple ways of integrating
(or adapting) the new SCTP signalling functionality with the existing SS7
architecture. Several user adaptation layers have been defined, for providing an
interface equivalent to Message Transfer Part Level 2 (MTP2), Message
Transfer Part Level 3 (MTP3) and Signalling Connection Control Part (SCCP).
The user adaptations fill in any missing functionality between the SCTP base
and the chosen interface. In Iu over IP Control Plane, MTP3 User Adaptation
Layer (M3UA) is used. M3UA provides an interface that is compatible with
MTP3. In other words, M3UA supports MTP3 applications on top of SCTP and
IP. As integration is done at the SS7 network layer, it is possible to provide
signalling between IP- and PCM-based signalling nodes through Signalling
Gateways.
6.1.3 Stream Control Transmission Protocol (SCTP)
Stream Control Transmission Protocol (SCTP) is an Internet Protocol

(IP)transport protocol which provides transport layer functions to many
Internet-based applications. The SCTP layer is between the SCTP user
adaptation layer(for example M3UA) and a connectionless packet network
service such as IP. SCTP is connection oriented, that is, it establishes a
connection between two endpoints (SCTP association) before transmitting the
user data. SCTP is specified in RFC 2960 and RFC 3309.
Basically, the SCTP offers a reliable transfer of user messages between
peerSCTP users. The following list explains the services the SCTP offers to its
users in more detail:
 Multi-homing: each SCTP endpoint is known by multiple IP
addresses.Routing to one address is independent of all others and, if one
route becomes unavailable, another will be used.
 .Multi-streaming capability: data is split into multiple streams, each
stream with independent sequenced delivery.

 Reliable transport of user data - detecting when data is corrupt or out of
sequence.
 Application-level fragmentation and multiplexing of user datagrams.
 Initialisation procedure: based on cookies and used to prevent denial of
service attacks.
107 (161)
Iu-PS Interface
 Appropriate congestion avoidance behaviour and resistance to flooding

and masquerade attacks.
 Fast retransmission
 Segmentation and bundling
 Selective ACK
 Initialisation procedure: based on cookies and used to prevent denial of
service attacks.
SCTP functions:
Association Start-up and Takedown
An association is initiated by a request from the SCTP user. A cookie

mechanism is employed during the initialization to provide protection against
security attacks. The cookie mechanism uses a four-way handshake, the last
two legs of which are allowed to carry user data for fast setup.
SCTP provides for graceful close (i.e., shutdown) of an active association on
request from the SCTP user. SCTP also allows ungraceful close (i.e., abort),
either on request from the user (ABORT primitive) or as a result of an error
condition detected within the SCTP layer.
Sequenced Delivery within Streams
The term "stream" is used in SCTP to refer to a sequence of user messages that
are to be delivered to the upper-layer protocol in order with respect to other
messages within the same stream. This is in contrast to its usage in TCP, where
it refers to a sequence of bytes.
The SCTP user can specify the number of streams to be supported by the
association at the association start-up time. This number is negotiated with the
remote end. User messages are associated with stream numbers. Internally,
SCTP assigns a stream sequence number to each message passed to it by the
SCTP user. On the receiving side, SCTP ensures that messages are delivered to
the SCTP user in sequence within a given stream. However, while one stream
may be blocked waiting for the next in-sequence user message, delivery from
other streams may proceed.
108 (161)
Contents
User Data Fragmentation
When needed, SCTP fragments user messages to ensure that the SCTP packet
passed to the lower layer conforms to the path MTU. Upon receipt, fragments
are reassembled into complete messages before being passed to the SCTP user.
Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data

fragment or unfragmented message. The TSN is independent of any stream
sequence number assigned at the stream level. The receiving end acknowledges
all TSNs received, even if there are gaps in the sequence. In this way, reliable
delivery is kept functionally separate from sequenced stream delivery.
The acknowledgement and congestion avoidance function is responsible for
packet retransmission when timely acknowledgement has not been received.
Packet retransmission is conditioned by congestion avoidance procedures
similar to those used for TCP.
Chunk Bundling
The SCTP packet delivered to the lower layer consists of a common header
followed by one or more chunks. Each chunk may contain either user data or
SCTP control information. The SCTP user has the option to request bundling
more than one user message into a single SCTP packet. The SCTP chunk
bundling function is responsible for assembling the complete SCTP packet and
disassembling it at the receiving end.
Packet Validation
A mandatory Verification Tag field and a 32-bit checksum field are included in
the SCTP common header. The Verification Tag value is chosen by each end of
the association during the association start-up. Packets received without the
expected Verification Tag value are discarded as protection against blind
masquerade attacks or stale SCTP packets from a previous association. The
checksum should be set by the sender of each SCTP packet to provide
additional protection against data corruption in the network. The receiver of an
SCTP packet with an invalid checksum silently discards the packet.
109 (161)
Iu-PS Interface
6.1.4 MTP3 User Adaptation Layer (M3UA)
MTP3 User Adaptation Layer (M3UA) defines a protocol for supporting the
transport of any Message Transfer Part Level 3 (MTP3) user signalling over
Internet Protocol (IP) using the services of Stream Control Transmission
Protocol (SCTP). It handles the MTP level 3 functions and services in the IP
network.
M3UA sets up associations between signalling endpoints so that when one
association breaks up it does not stop all the traffic between the endpoints.
M3UA does network address translation and mapping for ongoing routing to the
final IP destination.
M3UAwas designed to support fault tolerance and loadsharing. Fault tolerance
is provided using many IP Server Processes (IPSPs) or M3UA instances, which
provide the services at the same time. If a local M3UA instance fails, the
Signalling Connection Control Part (SCCP) service provider and the remote
node (IPSP instance) diverts the traffic to the remaining active instances.
M3UA is specified in RFC 3332.
For further details about SIGTRAN protocols please refer to the “Packet core network
signalling_Sigtran” document of PCNSIG course training documentation.
6.1.5 SGSN SG6.0 Iu over IP Control Plane signalling messages
Example Trace of the Attach procedure in Iu over IP interface

procedure on the Iu over IP interface. It was taken using the Ethereal protocol
Attach Request
110 (161)
Contents
111 (161)
Iu-PS Interface
Identity Request
112 (161)
Contents
Identity Response
113 (161)
Iu-PS Interface
Attach Accept
114 (161)
Contents
Attach complete
115 (161)
Iu-PS Interface
116 (161)
Contents
Example Trace of the PDP Context Activation Procedure in Iu over IP interface

The following trace can be taken as a standard example for a 'normal' PDP
Context Activation procedure on the Iu over IP interface. 'Normal' here means,
that the system is configured to provide full service and we are not expecting
extraordinary reactions.
Activate PDP Context Request
117 (161)
Iu-PS Interface
118 (161)
Contents
119 (161)
Iu-PS Interface
Activate PDP Context Accept
120 (161)
Contents
121 (161)
Iu-PS Interface
7 Iu over ATM signalling messages
7.1.1 Iu-PS interface over ATM Control Plane
Figure 39: Iu-PS interface over ATM Control Plane Protocol Stack
7.1.1.1 Example Trace of the Attach procedure in Iu over ATM interface

procedure on the Iu-Ps interface. It was taken using the Nethawk protocol
122 (161)
Contents
Attach Request

USER PART INFORMATION (MTP-3B Layer)
Service Information Octet
- SCCP
- Reserved
- spare bits: 00
Label
- DPC : 1792 (700h) (3GSGSN SPC)
- OPC : 1536 (600h) (RNC SPC)
- SLS : 9 (9h)
User Data
01 29 30 45 02 02 04 02 42 8E 04 04 43 00 06 8E 0F 5D 00 13 40 59 00 00
07 00 03 40 01 80 00 0F 40 06 00 22 F2 11 D9 03 00 37 40 01 2C 00 3A 40
08 00 22 F2 11 D9 03 D9 03 00 10 40 22 21 08 01 02 E5 40 79 07 02 05 F4
D8 F3 40 12 22 F2 11 D9 03 2C 0A 14 F3 82 33 4C 03 26 3C A0 60 17 16 00
4F 40 03 05 29 00 00 56 40 05 22 F2 11 00 01 00
CR - CONNECTION REQUEST (SCCP Layer)

- 293045h
Protocol Class
- length 2 (02h)
- subsystem: RANAP
Calling Party Address
- length 4 (04h)
- point code : 1536 (600h)
- subsystem: RANAP
SCCP User Data
- length: 93 (5Dh)
- data :
00 13 40 59 00 00 07 00 03 40 01 80 00 0F 40 06 00 22 F2 11 D9 03 00 37
40 01 2C 00 3A 40 08 00 22 F2 11 D9 03 D9 03 00 10 40 22 21 08 01 02 E5
40 79 07 02 05 F4 D8 F3 40 12 22 F2 11 D9 03 2C 0A 14 F3 82 33 4C 03 26
3C A0 60 17 16 00 4F 40 03 05 29 00 00 56 40 05 22 F2 11 00 01
RANAP-PDU (RANAP Layer)

- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 19
- padding: 00000
- contents: 13
123 (161)
Iu-PS Interface
initiatingMessage
- padding: 000000
InitialUE-Message
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 07
- id: 3
- contents: 00 03
- padding: 000000
CN-DomainIndicator: ps-domain (RANAP Layer)
- id: 15
- contents: 00 0F
- padding: 000000
LAI
- preamble: 0
- padding: 0000000
- lAC: 'D903'H
- contents: D9 03
- id: 55
- contents: 00 37
- padding: 000000
RAC: '2C'H (RANAP Layer)
- contents: 2C
- id: 58
- contents: 00 3A
- padding: 000000
SAI
- preamble: 0
- padding: 0000000
- lAC: 'D903'H
- contents: D9 03
- sAC: 'D903'H
- contents: D9 03
124 (161)
Contents
- id: 16
- contents: 00 10
- padding: 000000
NAS-PDU:
'080102E54079070205F4D8F3401222F211D9032C0A14F382334C03263CA0601716'H
- length: 21
- contents
08 01 02 E5 40 79 07 02 05 F4 D8 F3 40 12 22 F2 11 D9 03 2C 0A 14 F3 82
33 4C 03 26 3C A0 60 17 16
- id: 79 (RANAP Layer)
- contents: 00 4F
- padding: 000000
IuSignallingConnectionIdentifier: '000001010010100100000000'B
- contents: 05 29 00
- id: 86
- contents: 00 56
- padding: 000000
GlobalRNC-ID
- rNC-ID: 1
- contents: 00 01
ATTACH REQUEST (GPRS MM) (GSM/3G L3 Layer)

MS Network Capability
- Encryption algorithm GEA/1 available
- SM capabilities via dedicated channels supported
- SM capabilities via GPRS channels supported
- Use of default alphabet over UCS2 prefered
- Capab. of ellipsis notation and phase 2 error handling
- The ME does not support SoLSA
- Mobile station supporting R99 or later versions
- Mobile station does not support BSS packet flow procedures
- encryption algorithm GEA/2 available
Attach Type
- GPRS attach
- Follow-on request pending
- value: 7 (07h)
125 (161)
Iu-PS Interface
DRX Parameter (GSM/3G L3

Layer)
- Split PG Cycle value: 7
- DRX cycle length coefficient not specified by the MS
- Split pg cycle on CCCH not supported
- max. 2 sec non-DRX mode after transfer state
Mobile identity
- length: 5 (05h)
- TMSI/P-TMSI: D8F34012
Routing Area Id.
- Location Area Code: 55555 (D903h)
- Routing Area Code: 44 (2Ch)
MS Radio Access Capability
GSM 900-E Access Technology Type
- Length: 39 bits
- Controlled early Classmark Sending implemented (GSM/3G L3 Layer)
- HSCSD Multislot Class: 6
- GPRS Multislot Class: 6
- GPRS Ext. Dynamic Alloc. Capability not implemented
GSM 1800 Access Technology Type (GSM/3G L3 Layer)
- Length: 15 bits
- Spare ok
GPRS Timer
- Value: 44 sec
126 (161)
Contents
Attach Accept

- SCCP
- Reserved
- spare bits: 01
Label
- DPC : 1536 (600h)
- OPC : 1792 (700h)
- SLS : 2 (2h)
User Data: 02 29 30 45 50 00 00 02 01 03 04 43 00 06 8E 00
CC - CONNECTION CONFIRM (SCCP Layer)
- 293045h
- 500000h
Protocol Class
- length 4 (04h)
- point code : 1536 (600h)
- subsystem: RANAP

- SCCP
- Reserved
- spare bits: 00
Label
- DPC : 1536 (600h)
127 (161)
Iu-PS Interface
- OPC : 1792 (700h)

- SLS : 2 (2h)
User Data
06 29 30 45 00 01 14 00 0F 40 10 00 00 01 00 17 40 09 50 22 12 21 00 00
00 01 F0
DT1 - DATA FORM 1 (SCCP Layer)
- 293045h
Segmenting/Reassembling
- no more data
- the Segment./Reas. octet : 00
SCCP User Data
- length: 20 (14h)
- data : 00 0F 40 10 00 00 01 00 17 40 09 50 22 12 21 00 00 00 01 F0
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 15
- padding: 00000
- contents: 0F
initiatingMessage
- padding: 000000
CommonID
- extension flag: 0
- preamble: 0
protocolIEs (RANAP Layer)
- padding: 000000
- length: 00 01
- id: 23
- contents: 00 17
128 (161)
Contents
- padding: 000000
PermanentNAS-UE-ID
- extension flag: 0
- iMSI: '22122100000001F0'H
- padding: 0000
- contents: 22 12 21 00 00 00 01 F0

- SCCP
- Reserved
- spare bits: 00
Label
- DPC : 1536 (600h)
- OPC : 1792 (700h)
- SLS : 2 (2h)
User Data
06 29 30 45 00 01 27 00 14 40 23 00 00 02 00 10 40 17 16 08 02 01 49 00
22 F2 11 D9 03 2C 19 60 51 43 18 05 F4 E3 05 57 70 00 3B 40 01 00
- 293045h
- no more data
SCCP User Data
- length: 39 (27h)
- data :
00 14 40 23 00 00 02 00 10 40 17 16 08 02 01 49 00 22 F2 11 D9 03 2C 19
60 51 43 18 05 F4 E3 05 57 70 00 3B 40 01 00
- extension flag: 0
- choice index: 00
129 (161)
Iu-PS Interface
initiatingMessage
- procedureCode: 20
- padding: 00000
- contents: 14
initiatingMessage
- padding: 000000
DirectTransfer
- extension flag: 0
preamble: 0
protocolIEs
- padding: 000000
- length: 00 02
- id: 16
- contents: 00 10
- padding: 000000
NAS-PDU: '080201490022F211D9032C196051431805F4E3055770'H (RANAP Layer)
- length: 16
- contents
08 02 01 49 00 22 F2 11 D9 03 2C 19 60 51 43 18 05 F4 E3 05 57 70
- id: 59
- contents: 00 3B
- padding: 000000
SAPI: sapi-0
130 (161)
Contents
ATTACH ACCEPT (GPRS MM) (GSM/3G

L3 Layer)
Attach Result
- GPRS only attached
Force to Standby
- not indicated
GPRS Timer
- Value: 54 min
Radio Priority
- Priority level 4
Routing Area Id.
- Location Area Code: 55555 (D903h)
- Routing Area Code: 44 (2Ch)
P-TMSI signature
- Value: 60 51 43
P-TMSI
- length: 5 (05h)
- TMSI/P-TMSI: E3055770
Attach Complete

- SCCP
- Reserved
- spare bits: 01
Label
131 (161)
Iu-PS Interface
- DPC : 1792 (700h)

- OPC : 1536 (600h)
- SLS : 9 (9h)
User Data
06 50 00 00 00 01 29 00 14 40 25 00 00 04 00 10 40 03 02 08 03 00 0F 40
06 00 22 F2 11 D9 03 00 37 40 01 2C 00 3A 40 08 00 22 F2 11 D9 03 D9 03
- 500000h
- no more data
SCCP User Data
- length: 41 (29h)
- data :
00 14 40 25 00 00 04 00 10 40 03 02 08 03 00 0F 40 06 00 22 F2 11 D9 03
00 37 40 01 2C 00 3A 40 08 00 22 F2 11 D9 03 D9 03
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 20
- padding: 00000
- contents: 14
initiatingMessage
- padding: 000000
DirectTransfer
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 04
- id: 16
132 (161)
Contents
- contents: 00 10
- padding: 000000
NAS-PDU: '0803'H (RANAP Layer)
- length: 02
- contents: 08 03
- id: 15
- contents: 00 0F
- padding: 000000
LAI
- preamble: 0
- padding: 0000000
- lAC: 'D903'H
- contents: D9 03
- id: 55
- contents: 00 37
- padding: 000000
- contents: 2C
- id: 58
- contents: 00 3A
- padding: 000000
SAI
133 (161)
Iu-PS Interface
- preamble: 0
- padding: 0000000
- lAC: 'D903'H
- contents: D9 03
- sAC: 'D903'H
- contents: D9 03
ATTACH COMPLETE (GPRS MM) (GSM/3G L3 Layer)
7.1.1.2 Example Trace of the PDP Context Activation Procedure in Iu over ATM interface
We will have a look at 'normal' PDP Context Activation messages. 'Normal'
here means, that the system is configured to provide full service and we are not
expecting extraordinary reactions. It was taken using the Nethawk protocol
134 (161)
Contents
Activate PDP Context Request

- SCCP
- Reserved
- spare bits: 01
Label
- DPC : 1792 (700h)
- OPC : 1536 (600h)
- SLS : 9 (9h)
User Data
06 50 00 00 00 01 6D 00 14 40 69 00 00 04 00 10 40 47 46 0A 41 05 03 0B
00 00 1F 00 00 00 00 00 00 00 00 02 01 21 28 09 08 69 6E 74 65 72 6E 65
74 27 26 80 C0 23 0F 01 11 00 0F 09 4F 36 34 30 30 30 35 32 5C 00 80 21
10 01 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00 00 0F 40 06 00 22 F2
11 D9 03 00 37 40 01 2C 00 3A 40 08 00 22 F2 11 D9 03 D9 03
- 500000h
- no more data
SCCP User Data
- length: 109 (6Dh)
- data :
00 14 40 69 00 00 04 00 10 40 47 46 0A 41 05 03 0B 00 00 1F 00 00 00 00
00 00 00 00 02 01 21 28 09 08 69 6E 74 65 72 6E 65 74 27 26 80 C0 23 0F
01 11 00 0F 09 4F 36 34 30 30 30 35 32 5C 00 80 21 10 01 05 00 10 81 06
00 00 00 00 83 06 00 00 00 00 00 0F 40 06 00 22 F2 11 D9 03 00 37 40 01
2C 00 3A 40 08 00 22 F2 11 D9 03 D9 03
- extension flag: 0
- choice index: 00
initiatingMessage
135 (161)
Iu-PS Interface
- procedureCode: 20
- padding: 00000
- contents: 14
initiatingMessage
- padding: 000000
DirectTransfer
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 04
- id: 16
- contents: 00 10
- padding: 000000
NAS-PDU:
'0A4105030B00001F0000000000000000020121280908696E7465726E6574272680C0230F0111
000F094
F363430303035325C0080211001050010810600000000830600000000'H
- length: 46
(RANAP Layer)
- contents
0A 41 05 03 0B 00 00 1F 00 00 00 00 00 00 00 00 02 01 21 28 09 08 69 6E
74 65 72 6E 65 74 27 26 80 C0 23 0F 01 11 00 0F 09 4F 36 34 30 30 30 35
32 5C 00 80 21 10 01 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00
- id: 15
- contents: 00 0F
- padding: 000000
LAI
136 (161)
Contents
- preamble: 0
- padding: 0000000
- lAC: 'D903'H
- contents: D9 03
- id: 55
- contents: 00 37
- padding: 000000
- contents: 2C
- id: 58
- contents: 00 3A
- padding: 000000
SAI
- preamble: 0
- padding: 0000000
- lAC: 'D903'H
- contents: D9 03
- sAC: 'D903'H
- contents: D9 03
ACT. PDP CONTEXT REQUEST (GPRS SM) (GSM/3G L3 Layer)
Network Serv. Access Point Id
- NSAPI 5
- SAPI 3
Quality of Service
- length: 11 (0Bh)
137 (161)
Iu-PS Interface
- Reliab. class: Subscribed (MS only)

- Delay class: Subscribed
- Precedence class: Subscribed
- Peak throughput: Subscribed
- Traffic class: Subscribed
- Delivery order: Subscribed
- Delivery of erroneous SDUs: Subscribed
- Maximum SDU size: Subscribed maximum SDU size
- Maximum bit rate for uplink: Subscribed (MS only)
- Maximum bit rate for downlink: Subscribed (MS only)
- Residual BER: Subscribed
- SDU error ratio: Subscribed
Packet Data Protocol Address (GSM/3G L3 Layer)
- Length: 2 (02h)
- Dynamic PDP addressing is applied
Access Point Name
- length : 9 (09h)
- value (hex) : 08 69 6E 74 65 72 6E
65 74
- length: 38 (26h)
Password Authentic. Protocol (PAP)
Contents: 01 11 00 0F 09 4F 36 34 30 30 30 35 32 5C 00
Contents: 01 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00
138 (161)
Contents

- SCCP
- Reserved
- spare bits: 00
Label
- DPC : 1536 (600h)
- OPC : 1792 (700h)
- SLS : 2 (2h)
User Data
06 29 30 45 00 01 34 00 00 00 30 00 00 01 00 36 40 29 00 00 01 00 35 00
1D 3C 0A 14 C2 05 DB FF 80 2E F0 08 06 34 04 90 00 01 03 E0 C0 01 01 03
00 12 00 00 00 20 40 03 60 99 C0
- 293045h
- no more data
SCCP User Data
- length: 52 (34h)
- data :
00 00 00 30 00 00 01 00 36 40 29 00 00 01 00 35 00 1D 3C 0A 14 C2 05 DB
FF 80 2E F0 08 06 34 04 90 00 01 03 E0 C0 01 01 03 00 12 00 00 00 20 40
03 60 99 C0
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 0
- padding: 00000
- contents: 00
139 (161)
Iu-PS Interface

initiatingMessage
- padding: 000000
RAB-AssignmentRequest
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 01
- id: 54
- contents: 00 36
- padding: 000000
RAB-SetupOrModifyList (RANAP Layer)
- length: 00
- length: 00 01
- id: 53
- contents: 00 35
- firstCriticality: reject
- padding: 000000
- opentype length: 1D
firstValue
- extension flag: 0
- preamble: 011110
- rAB-ID: '00000101'B
rAB-Parameters
- extension flag: 0
- preamble: 0001010
- trafficClass: background
140 (161)
Contents
- rAB-AsymmetryIndicator: symmetric-bidirectional
maxBitrate (RANAP Layer)
- MaxBitrate: 384000
- contents: 05 DB FF
- deliveryOrder: delivery-order-not-requested
- maxSDU-Size: 12016
- padding: 0000000
- contents: 2E F0
sDU-Parameters
- extension flag: 0
- preamble: 100
sDU-ErrorRatio
- preamble: 0
- mantissa: 1
- exponent: 4
residualBitErrorRatio
- preamble: 0
- mantissa: 4
- exponent: 3
- deliveryOfErroneousSDU: yes (RANAP Layer)
allocationOrRetentionPriority
- extension flag: 0
- preamble: 0
- priorityLevel: 2
141 (161)
Iu-PS Interface
- pre-emptionCapability: shall-not-trigger-pre-emption
- pre-emptionVulnerability: pre-emptable
- queuingAllowed: queueing-not-allowed
- relocationRequirement: none
userPlaneInformation
- extension flag: 0
- preamble: 0
- userPlaneMode: transparent-mode
- uP-ModeVersions: '0000000000000001'B
- contents: 00 01
transportLayerInformation (RANAP Layer)
- extension flag: 0
- preamble: 0
- padding: 00000
- contents: C0 01 01 03
- extension flag: 0
- choice index: 0
- gTP-TEI: '12000000'H
- padding: 000000
- contents: 12 00 00 00
- service-Handover: handover-to-GSM-should-not-be-performed
- secondCriticality: ignore (RANAP Layer)
142 (161)
Contents

- padding: 000000
secondValue
- extension flag: 0
- preamble: 1100000
pDP-TypeInformation
- PDP-Type: ipv4
- PDP-Type: ipv4
- dataVolumeReportingIndication: do-not-report

- SCCP
- Reserved
- spare bits: 01
Label
- DPC : 1792 (700h)
- OPC : 1536 (600h)
- SLS : 9 (9h)
143 (161)
Iu-PS Interface
User Data
06 50 00 00 00 01 1E 60 00 00 1A 00 00 01 00 34 40 13 00 00 01 00 33 40
0C 60 28 7C 0A 14 14 03 00 00 00 00 00
- 500000h
- no more data
SCCP User Data
- length: 30 (1Eh)
- data :
60 00 00 1A 00 00 01 00 34 40 13 00 00 01 00 33 40 0C 60 28 7C 0A 14 14
03 00 00 00 00 00
RANAP-PDU (RANAP
Layer)
- extension flag: 0
- choice index: 11
outcome
- procedureCode: 0
- padding: 00000
- contents: 00
outcome
- padding: 000000
- opentype length: 1A
RAB-AssignmentResponse
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 01
- id: 52
- contents: 00 34
144 (161)
Contents

- padding: 000000
RAB-SetupOrModifiedList (RANAP Layer)
- length: 00
- length: 00 01
- id: 51
- contents: 00 33
- padding: 000000
- opentype length: 0C
RAB-SetupOrModifiedItem
- extension flag: 0
- preamble: 1100
- rAB-ID: '00000101'B
- padding: 00
- contents: 0A 14 14 03
- extension flag: 0
- choice index: 0
- gTP-TEI: '00000000'H
- padding: 000000
- contents: 00 00 00 00
Activate PDP Context Accept
145 (161)
Iu-PS Interface

- SCCP
- Reserved
- spare bits: 00
Label
- DPC : 1536 (600h)
- OPC : 1792 (700h)
- SLS : 2 (2h)
User Data
06 29 30 45 00 01 3F 00 14 40 3B 00 00 02 00 10 40 2F 2E 8A 42 03 0B 23
62 1F 92 97 68 68 44 00 00 00 02 2B 06 01 21 0A 62 02 0E 27 14 80 80 21
10 04 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00 00 3B 40 01 00
- 293045h
- no more data
SCCP User Data
- length: 63 (3Fh)
- data :
00 14 40 3B 00 00 02 00 10 40 2F 2E 8A 42 03 0B 23 62 1F 92 97 68 68 44
00 00 00 02 2B 06 01 21 0A 62 02 0E 27 14 80 80 21 10 04 05 00 10 81 06
00 00 00 00 83 06 00 00 00 00 00 3B 40 01 00
- extension flag: 0
- choice index: 00
initiatingMessage
- procedureCode: 20
- padding: 00000
- contents: 14
initiatingMessage
- padding: 000000
- opentype length: 3B
DirectTransfer
- extension flag: 0
- preamble: 0
protocolIEs
- padding: 000000
- length: 00 02
- id: 16
- contents: 00 10
- padding: 000000
- opentype length: 2F
NAS-PDU:
'8A42030B23621F9297686844000000022B0601210A62020E271480802110040500108106000000008
30
600000000'H
146 (161)
Contents
- length: 2E
- contents
8A 42 03 0B 23 62 1F 92 97 68 68 44 00 00 00 02 2B 06 01 21 0A 62 02 0E
27 14 80 80 21 10 04 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00
- id: 59
- contents: 00 3B
- padding: 000000
SAPI: sapi-0
ACT. PDP CONTEXT ACCEPT (GPRS SM) (GSM/3G L3 Layer)
- SAPI 3
Quality of Service
- length: 11 (0Bh)
- Reliab. class: Unack. GTP and LLC Ack. RLC Protected data
- Delay class: Delay class 4 (best effort)
- Precedence class: Normal priority
- Peak throughput: Up to 32 000 octet/s
- Traffic class: Background class
- Delivery order: Without delivery order ('no')
- Delivery of erroneous SDUs: delivered
- Maximum SDU size: 1502 Octets
- Maximum bit rate for uplink: 384 kbps
- Maximum bit rate for downlink: 384 kbps
- Residual BER: 4*10-3
- SDU error ratio: 1*10-4
Radio Priority
- Priority level 2
- Length: 6 (06h)
- Address: 10.98.2.14
- length: 20 (14h)
Contents: 04 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00
147 (161)
Iu-PS Interface
Appendix A RANAP Procedures

Elementary Initiating message Successful outcome Unsuccessful outcome
procedure response message response message
Iu Release IU RELEASE COMMAND IU RELEASE COMPLETE
Relocation RELOCATION RELOCATION RELOCATION

Preparation REQUIRED COMMAND PREPARATION FAILURE
Relocation RELOCATION RELOCATION REQUEST RELOCATION FAILURE

Resource REQUEST ACKNOWLEDGE
Allocation
Relocation RELOCATION CANCEL RELOCATION CANCEL

Cancel ACKNOWLEDGE
SRNS Context SRNS CONTEXT SRNS CONTEXT

Transfer REQUEST RESPONSE
Security Mode SECURITY MODE SECURITY MODE SECURITY MODE

Control COMMAND COMPLETE REJECT
Data Volume DATA VOLUME REPORT DATA VOLUME REPORT

Report * REQUEST
Reset RESET RESET ACKNOWLEDGE
Reset Resource RESET RESOURCE RESET RESOURCE

ACKNOWLEDGE
Location Related LOCATION RELATED LOCATION RELATED LOCATION RELATED

Data * DATA REQUEST DATA RESPONSE DATA FAILURE
Table 1: Class 1 Procedures
148 (161)
Contents
Elementary procedure Initiating message
RAB Modification Request RAB MODIFY REQUEST
RAB Release Request RAB RELEASE REQUEST
Iu Release Request IU RELEASE REQUEST
Relocation Detect RELOCATION DETECT
Relocation Complete RELOCATION COMPLETE
SRNS Data Forwarding Initiation SRNS DATA FORWARD COMMAND
SRNS Context Forwarding from FORWARD SRNS CONTEXT

Source RNC to CN
SRNS Context Forwarding to Target FORWARD SRNS CONTEXT

RNC from CN
Paging PAGING
Common ID COMMON ID
CN Invoke Trace CN INVOKE TRACE
CN Deactivate Trace CN DEACTIVATE TRACE
Location Reporting Control LOCATION REPORTING CONTROL
Location Report LOCATION REPORT
Initial UE Message INITIAL UE MESSAGE
Direct Transfer DIRECT TRANSFER
Overload Control OVERLOAD
Error Indication ERROR INDICATION
Table 2: Class 2 Procedure
Elementary procedure Initiating message Outcome
RAB Assignment RAB ASSIGNMENT RAB ASSIGNMENT

REQUEST RESPONSE x N (N>=1)
Table 3: Class 3 Procedure
149 (161)
Iu-PS Interface
Appendix B RAB Parameters

IE/Group Name Presence Range IE type and Semantics description
reference
RAB parameters
>Traffic Class M ENUMERATED Desc.: This IE indicates the type
(conversational, of application for which the
streaming, Radio Access Bearer service is
interactive, optimised
background, ...)
>RAB Asymmetry M ENUMERATED Desc.: This IE indicates
Indicator (Symmetric asymmetry or symmetry of the
bidirectional, RAB and traffic direction
Asymmetric Uni
directional
downlink,
Asymmetric Uni
directional
Uplink,
Asymmetric
Bidirectional, ...)
>Maximum Bit Rate M 1 to <nbr- INTEGER Desc.: This IE indicates the
SeparateTrafficDir (1..16,000,000) maximum number of bits
ections> delivered by UTRAN and to
UTRAN at a SAP within a period
of time, divided by the duration
of the period.
The unit is: bit/s
Usage:
When nbr-
SeparateTrafficDirections is
equal to 2, then Maximum Bit
Rate attribute for downlink is
signalled first, then Maximum Bit
Rate attribute for uplink
>Guaranteed Bit Rate C- 0 to <nbr- INTEGER Desc.: This IE indicates the
iftrafficCon SeparateTrafficDir (0..16,000,000) guaranteed number of bits
v-Stream ections> delivered at a SAP within a
period of time (provided that
there is data to deliver), divided
by the duration of the period.
The unit is: bit/s
Usage:
1. When nbr-
SeparateTrafficDirections is
equal to 2, then
Guaranteed Bit Rate for
downlink is signalled first,
then Guaranteed Bit Rate
for uplink
2. Delay and reliability
attributes only apply up to
the guaranteed bit rate
3. Conditional value for the
case of Support Mode for
pre-defined SDU sizes:
Set to highest not rate
controllable bitrate, where
bitrate is either
– one of the RAB subflow
combination bitrate IEs
(when present)
or
– one of the calculated
values given when dividing
the compound Subflow
150 (161)
Contents

reference
RAB parameters
combination SDU sizes by
the value of the IE
Maximum SDU Size and
then multiplying this result
by the value of the IE
Maximum Bit Rate.
>Delivery Order M ENUMERATED Desc: This IE indicates whether

(delivery order the RAB shall provide in-
requested, sequence SDU delivery or not
delivery order Usage:
not requested) Delivery order requested: in
sequence delivery shall be
guaranteed by UTRAN on all
RAB SDUs
Delivery order not requested: in
sequence delivery is not
required from UTRAN
>Maximum SDU Size M INTEGER Desc.: This IE indicates the
(0..32768) maximum allowed SDU size
The unit is: bit.
Usage:
Conditional value:
Set to largest RAB Subflow
Combination compound SDU
size (when present) among the
different RAB Subflow
Combinations
> SDU parameters 1 to See below Desc.: This IE contains the

<maxRABSubflow parameters characterizing the
s> RAB SDUs
Usage
Given per subflow with first
occurence corresponding to
subflow#1 etc…
>Transfer Delay C- INTEGER Desc.: This IE indicates the
iftrafficCon (0..65535) maximum delay for 95th
v-Stream percentile of the distribution of
delay for all delivered SDUs
during the lifetime of a RAB,
where delay for an SDU is
defined as the time from a
request to transfer an SDU at
one SAP to its delivery at the
other SAP
The unit is: millisecond.
Usage:
-
>Traffic Handling Priority C- INTEGER Desc.: This IE specifies the
iftrafficInter {spare (0), relative importance for handling
activ highest (1), .., of all SDUs belonging to the
lowest (14), no radio access bearer compared
priority (15)} to the SDUs of other bearers
(0..15) Usage:
Values between 1 and 14 are
ordered in decreasing order of
priority, '1' being the highest and
'14' the lowest.
Value 0 shall be treated as a
logical error if received.
>Allocation/Retention O See below Desc.: This IE specifies the
relative importance compared to
151 (161)
Iu-PS Interface

reference
RAB parameters
priority other Radio access bearers for
allocation and retention of the
Radio access bearer.
Usage:
If this IE is not received, the
request is regarded as it cannot
trigger the pre-emption process
and it is vulnerable to the pre-
emption process.
>Source Statistics C- ENUMERATED Desc.: This IE specifies
Descriptor iftrafficCon (speech, characteristics of the source of
v-Stream unknown, …) submitted SDUs
Usage:
-
>Relocation O ENUMERATED This IE shall be present for
Requirement (lossless, none, RABs towards the PS domain,
…) otherwise it shall not be present.
Desc.: This IE is no longer used.
Usage:
It shall always be set to “none”
when sent and it shall always be
ignored when received.
Range Bound Explanation

nbr-SeparateTrafficDirection Number of Traffic Directions being signalled
separately.
Set to 2 if RAB asymmetry indicator is
asymmetric bidirectional.
Set to 1 in all other cases.

maxRABSubflows Maximum number of Subflows per RAB. Value
is 7
Condition Explanation
IftrafficConv-Stream This IE shall be present if the Traffic Class IE is set to
“Conversational” or “Streaming”.
IftrafficInteractiv This IE shall be present if the Traffic Class IE is set to “Interactive”.

reference
SDU parameters
> SDU Error Ratio C- Desc.: This IE indicates the
ifErroneou fraction of SDUs lost or detected
sSDU as erroneous.
This is a Reliability attribute
Usage:
The attribute is coded as follows:
– exponent
Mantissa * 10
>>Mantissa M INTEGER (1..9)
>>Exponent M INTEGER (1..6)
>Residual Bit Error M Desc.: This IE indicates the

Ratio undetected bit error ratio for
each subflow in the delivered
SDU.
152 (161)
Contents
This is a Reliability attribute.

Usage:
The attribute is coded as follows:
– exponent
Mantissa * 10
>>Mantissa M INTEGER (1..9)
>>Exponent M INTEGER (1..8)
>Delivery Of Erroneous M ENUMERATED Desc.: This IE indicates whether

SDU (yes, no, no- SDUs with detected errors shall
error-detection- be delivered or not. In case of
consideration) unequal error protection, the
attribute is set per subflow
This is a Reliability attribute
Usage:
Yes: error detection applied,
erroneous SDU delivered
No. Error detection is applied,
erroneous SDU discarded
no-error-detection-consideration:
SDUs delivered without
considering error detection
If the RNC receives this IE set to
‘Yes’ and the User Plane Mode
IE is set to ‘transparent mode’, it
should consider it as ‘no-error-
detection-consideration’.
>SDU format O 1 to See below Desc.: This IE contains the list
information Parameter <maxRABSubflow of possible exact sizes of SDUs
Combinations> and/or RAB Subflow
Combination bit rates.
Given per RAB Subflow
Combination with first occurence
corresponding to RAB Subflow
Combination number 1.
It shall always be present for
rate controllable RABs.

maxRABSubflowCombinations Maximum number of RAB Subflow
Combinations. Value is 64.
Condition Explanation
IfErroneousSDU This IE shall be present if the Delivery Of Erroneous SDU IE is set
to “Yes” or “No”.
153 (161)
Iu-PS Interface

reference
SDU Format Information At least one of the Subflow SDU
Parameter size IE and the RAB Subflow
Combination bit rate IE shall be
present when SDU format
information Parameter IE is
present.
For the case subflow SDUs are
transmitted at constant time
interval, only one of the two IEs
shall be present.
>Subflow SDU Size O INTEGER Desc.: This IE indicates the exact
(0..4095) size of the SDU.
The unit is: bit.
Usage:
This IE is only used for RABs that
have predefined SDU size(s). It
shall be present for RABs having
more than one subflow.
For RABs having only one
subflow, this IE shall be present
only when the RAB is rate
controllable and the SDU size of
some RAB Subflow combination(s)
is different than the IE Maximum
SDU Size.
When this IE is not present and
SDU format information Parameter
is present, then the Subflow SDU
size for the only existing subflow
takes the value of the IE Maximum
SDU size.
>RAB Subflow O INTEGER Desc.: This IE indicates the RAB

Combination Bit Rate (0..16,000,000 Subflow Combination bit rate.
) The unit is: bit/s.
Usage:
When this IE is not present and
SDU format information parameter
is present then all Subflow SDUs
are transmitted (when there is data
to be transmitted) at a constant
time interval.
The value of this IE shall not
exceed the maximum value of the
IEs ‘Maximum Bit Rate’.
The value 0 of RAB Subflow
Combination bitrate indicates that
the RAB uses discontinuous
transfer of the SDUs.
154 (161)
Contents

reference
Allocation/Retention
Priority
>Priority Level M INTEGER Desc.: This IE indicates the
{spare (0), priority of the request.
highest (1), .., Usage:
lowest (14), no Values between 1 and 14 are
priority (15)} ordered in decreasing order of
(0..15) priority, '1' being the highest and
'14' the lowest.
Value 0 shall be treated as a
logical error if received.
The priority level and the
preemption indicators may be
used to determine whether the
request has to be performed
unconditionally and immediately
>Pre-emption Capability M ENUMERATE Descr.: This IE indicates the pre-
D(shall not emption capability of the request
trigger pre- on other RABs
emption, may Usage:
trigger pre- The RAB shall not pre-empt other
emption) RABs or, the RAB may pre-empt
other RABs
The Pre-emption Capability
indicator applies to the allocation
of resources for a RAB and as
such it provides the trigger to the
pre-emption procedures/processes
of the RNS.
>Pre-emption M ENUMERATE Desc.: This IE indicates the
Vulnerability D(not pre- vulnerability of the RAB to
emptable, preemption of other RABs.
pre-emptable) Usage:
The RAB shall not be pre-empted
by other RABs or the RAB may be
pre-empted by other RABs.
Pre-emption Vulnerability indicator
applies for the entire duration of
the RAB, unless modified and as
such indicates whether the RAB is
a target of the pre-emption
procedures/processes of the RNS
>Queuing Allowed M ENUMERATE Desc.: This IE indicates whether
D(queuing not the request can be placed into a
allowed, resource allocation queue or not.
queuing Usage:
allowed) Queuing of the RAB is allowed
Queuing of the RAB is not allowed
Queuing allowed indicator applies
for the entire duration of the RAB,
unless modified.
155 (161)
Iu-PS Interface
Appendix C RAB Causes

Radio Network Layer cause Meaning
Conflict with already existing Integrity The action was not performed due to that the requested security
protection and/or Ciphering information mode configuration was in conflict with the already existing security
mode configuration.
Condition Violation For Guaranteed Bit The action was not performed due to condition violation for
Rate guaranteed bit rate.
Condition Violation For SDU Parameters The action was not performed due to condition violation for SDU
parameters.
Condition Violation For Traffic Handling The action was not performed due to condition violation for traffic
Priority handling priority.
Directed Retry The reason for action is Directed Retry
Failure In The Radio Interface Procedure Radio interface procedure has failed.
Interaction With Other Procedure Relocation was cancelled due to interaction with other procedure.
Invalid RAB ID The action failed because the RAB ID is unknown in the RNC.
Invalid RAB Parameters Combination The action failed due to invalid RAB parameters combination.
Invalid RAB Parameters Value The action failed due to invalid RAB parameters value.
Iu UP Failure The action failed due to Iu UP failure.
No remaining RAB The reason for the action is no remaining RAB.
RAB Pre-empted The reason for the action is that RAB is pre-empted.
Radio Connection With UE Lost The action is requested due to losing radio connection to the UE
Release Due To UE Generated Release requested due to UE generated signalling connection
Signalling Connection Release release.
Release Due To UTRAN Generated Release is initiated due to UTRAN generated reason.
Reason
Relocation Cancelled The reason for the action is relocation cancellation.
Relocation Desirable for Radio Reasons The reason for requesting relocation is radio related.
Relocation Failure In Target CN/RNC Or Relocation failed due to a failure in target CN/RNC or target system.
Target System
Relocation Not Supported In Target RNC Relocation failed because relocation was not supported in target RNC
Or Target System or target system.
Relocation Triggered The action failed due to relocation.
Repeated Integrity Checking Failure The action is requested due to repeated failure in integrity checking.
Request Superseded The action failed because there was a second request on the same
RAB.
Requested Ciphering And/Or Integrity The UTRAN or the UE is unable to support the requested ciphering
Protection Algorithms Not Supported and/or integrity protection algorithms.
Requested Guaranteed Bit Rate For DL The action failed because requested guaranteed bit rate for DL is not
Not Available available.
Requested Guaranteed Bit Rate For UL The action failed because requested guaranteed bit rate for UL is not
Requested Guaranteed Bit Rate Not The action failed because requested guaranteed bit rate is not
Available available.
Requested Information Not Available The action failed because requested information is not available.
Requested Maximum Bit Rate For DL The action failed because requested maximum bit rate for DL is not
Requested Maximum Bit Rate For UL The action failed because requested maximum bit rate for UL is not
Requested Maximum Bit Rate Not The action failed because requested maximum bit rate is not
Available available.
Requested Request Type Not Supported The RNC is not supporting the requested location request type either
because it doesn't support the requested event or it doesn't support
the requested report area.
Requested Traffic Class Not Available The action failed because requested traffic class is not available.
Requested Transfer Delay Not The action failed because requested transfer delay is not achievable.
Achievable
156 (161)
Contents
Resource Optimisation Relocation The reason for requesting relocation is resource optimisation.
Successful Relocation The reason for the action is completion of successful relocation.
Time Critical Relocation Relocation is requested for time critical reason.
TQUEUING Expiry The action failed due to expiry of the timer TQUEUING.
TRELOCalloc Expiry Relocation Resource Allocation procedure failed due to expiry of the
timer TRELOCalloc.
TRELOCcomplete Expiry The reason for the action is expiry of timer TRELOCcomplete.
TRELOCoverall Expiry The reason for the action is expiry of timer TRELOCoverall.
TRELOCprep Expiry Relocation Preparation procedure is cancelled when timer TRELOCprep
expires.
Unable To Establish During Relocation RAB failed to establish during relocation because it cannot be
supported in the target RNC.
Unknown Target RNC Relocation rejected because the target RNC is not known to the CN.
User Inactivity The action is requested due to user inactivity.
User Plane Versions Not Supported The action failed because requested user plane versions were not
supported.
Transport Layer cause Meaning

Iu Transport Connection Failed to The action failed because the Iu Transport Network Layer connection
Establish could not be established.
Signalling Transport Resource Failure Signalling transport resources have failed (e.g. processor reset).
NAS cause Meaning

Normal Release The release is normal.
User Restriction Start Indication A location report is generated due to entering a classified area set by
O&M.
User Restriction End Indication A location report is generated due to leaving a classified area set by
O&M.
Protocol cause Meaning

Abstract Syntax Error (Reject) The received message included an abstract syntax error and the
concerning criticality indicated “reject”.
Abstract Syntax Error (Ignore And Notify) The received message included an abstract syntax error and the
concerning criticality indicated “ignore and notify”.
Abstract Syntax Error (Falsely The received message contained IEs or IE groups in wrong order or
Constructed Message) with too many occurrences.
Message Not Compatible With Receiver The received message was not compatible with the receiver state.
State
Semantic Error The received message included a semantic error.
Transfer Syntax Error The received message included a transfer syntax error.
Miscellaneous cause Meaning

Network Optimisation The action is performed for network optimisation.
No Resource Available No requested resource is available.
O&M Intervention The action is due to O&M intervention.
Unspecified Failure Sent when none of the specified cause values applies.
157 (161)
Iu-PS Interface
References
3GPP TS 23.060 V3.14.0: 3rd Generation Partnership; General Packet Radio

Service (GPRS); Service description (Release 1999)
3GPP TS 25.415 V3.12.0: 3rd Generation Partnership; Technical Specification
Group Radio Access Network; UTRAN Iu interface user plane protocols
(Release 1999)
3GPP TS 24.008 V3.15.0: Mobile radio interface layer 3 (Release 1999)
3GPP TS 25.412 V3.6: UTRAN Iu Interface Signalling Transport (Release
1999)
3GPP TS 25.413: UTRAN Iu Interface RANAP Signalling (Release 1999)
Iu interface description for 3G SGSN
3GPP TS 29.060 V3.16.0: 3rd Generation Partnership; General Packet Radio

Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp
interface; (Release 1999)
ITU-T Q.712 SERIES Q: SWITCHING AND SIGNALLING Specifications of
Signalling System No. 7 – Signalling connection control part (07/96)
158 (161)
Contents
Glossary
AA Anonymous Access
ABM Asynchronous Balanced Mode
ACK ACKnowledgement
ADM Asynchronous Disconnected Mode
APN Access Point Name
ATM Asynchronous Transfer Mode
BG Border Gateway
BSSAP+ Base Station System Application Part +
BSSGP Base Station System GPRS Protocol
BVCI BSSGP Virtual Connection Identifier
CCU Channel Codec Unit
CGI Cell Global Identification
CNF Confirm
CS Circuit Switched
DCOMP Identifier of the user data compression algorithm used for the N-PDU
DISC DISConnect
DL Downlink
DM Disconnected Mode
DNS Domain Name System
FRMR FRaMe Reject
GGSN Gateway GPRS Support Node
GMM/SM GPRS Mobility Management and Session Management
GRR GPRS Radio Resources service access point
GSN GPRS Support Node
GTP GPRS Tunnelling Protocol
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IHOSS Internet-Hosted Octet Stream Service
IND Indication
IOV Input Offset Value
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPX Internet Packet eXchange
ISP Internet Service Provider
L2TP Layer-2 Tunnelling Protocol
LAPD Link Access Procedure on the D-channel
LL Logical Link
LLC Logical Link Control
LLE Logical Link Entity
LLGMM LLC to GPRS Mobility Management service access point
LLM Logical Link Management
LLME Logical Link Management Entity
LL-PDU LC PDU
M More bit used to indicate the last segment of N-PDU
MAC Medium Access Control
MNRF Mobile station Not Reachable Flag
159 (161)
Iu-PS Interface
MNRG Mobile station Not Reachable for GPRS flag

MNRR Mobile station Not Reachable Reason
MTP2 Message Transfer Part layer 2
MTP3 Message Transfer Part layer 3
NAS Non Access Stratum
NGAF Non-GPRS Alert Flag
N-PDU Network Protocol Data Unit
NS Network Service
NSAPI Network Layer Service Access Point Identifier
NSS Network Sub System
OSP Octet Stream Protocol
PCOMP Identifier of the protocol control information compression algorithm
used for the N-PDU
PCU Packet Control Unit
PDCH Packet Data Channel
PDN Packet Data Network
PDP Packet Data Protocol, e.g., IP or X.25 [34]
PDU Protocol Data Unit
PPF Paging Proceed Flag
PPP Point-to-Point Protocol
PS Packet Switched
PTM Point To Multipoint
P-TMSI Packet TMSI
PTP Point To Point
PVC Permanent Virtual Circuit
QoS Quality of Service
RA Routeing Area
RAC Routeing Area Code
RAI Routeing Area Identity
REQ Request
RES Response
RLC Radio Link Control
RNR Receive Not Ready
RR Receive Ready
S Supervisory
SABM Set Asynchronous Balanced Mode
SACK Selective ACKnowledgement
SAPI Service Access Point Identifier
SDU Service Data Unit
SGSN Serving GPRS Support Node
SM Short Message
SM-SC Short Message service Service Centre
SMS-GMSC Short Message Service Gateway MSC
SMS-IWMSC Short Message Service Interworking MSC
SNDCP Subnetwork Dependent Convergence Protocol
SNDCP SubNetwork Dependent Convergence Protocol
SN-PDU SNDCP PDU
SNSM SNDCP-SM
TCAP Transaction Capabilities Application Part
160 (161)
Contents
TCP Transmission Control Protocol

TIA Telecommunications Industry Association
TID Tunnel Identifier
TEID Tunnel Endpoint Identifier
TLLI Temporary Logical Link Identity
TRAU Transcoder and Rate Adaptor Unit
UA Unnumbered Acknowledgement
UDP User Datagram Protocol
UI Unconfirmed Information
UL Uplink
161 (161)

04 CN3203EN01GLN01 Iu-PS Interface 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 CN3203EN01GLN01 Iu-PS Interface 1

Uploaded by

Copyright:

Available Formats

PCN Signaling

4 Iu-PS Control Plane ....................................................................6

5 Iu-PS User Plane .......................................................................93

6 SGSN SG6.0 Iu over IP ...........................................................106

Figure 1: Protocol stack in Iu-PS Interface

4 Iu-PS Control Plane

Iu-PS Control Plane

4.1.1 Iu-PS Over ATM Control Plane

Figure 3: Iu-PS Over ATM Control Plane Protocol Stacks

3. SAAL-NNI (ITU-T Rec. Q.2100 (07/1994)) consists of the following

4. SAAL-NNI (ITU-T Rec. Q.2100 (07/1994)) consists of the following

5. ATM (ITU-T Rec. I.361 (11/1995)).

4.1.2 Iu-PS Over IP Control Plane

Figure 4: Iu-PS Over IP Control Plane Protocol Stacks

1. SCTP refers to the Stream Control Transmission Protocol ) is an Internet

 Initialisation procedure: based on cookies and used to prevent denial

2. M3UA (RFC3332) M3UA refers to the SCCP adaptation layer ’SS7

3. IP Sub-Network shall use the Internet Protocol (IP) as defined in either

 Packaging transport layer PDUs (T-PDU) into IP packets.

4. L2 Network is built using Ethernet technology.

4.2 3G-SGSN-UE Control Plane

UE Uu RNC Iu-PS 3G SGSN

Figure 5: 3G-SGSN – UE Control Plane Protocol Stack

GMM/SM/SMS The Layer 3 Session and Mobility Management (L3-SMM)

RANAP The Radio Access Network Application Protocol is the signalling

4.3 Examples of the message flow on Iu-PS Control

UE BS RNC SGSN HLR

RRC: INITIAL DIRECT TRANSFER (Attach Request)

SCCP CR: RANAP: INITIAL UE MESSAGE (Attach Request)

Insert Subscriber Data

Update Location Ack

RANAP: DT (Attach Accept)

RRC: DL DT (Attach Accept)

RRC: UL DT (Attach Complete)

RANAP: DT (Attach Complete)

Figure 6: Example of the message flow on Iu-PS Control Plane

Iu-PS over ATM - Attach Procedure message flow:

Iu-PS over ATM - Routing Area Update Procedure message flow:

Iu-PS over ATM - PDP Context Activation Procedure message flow:

Iu-PS over ATM - Service Request Procedure message flow:

4.4.1 Signalling connection control part messages:

There is always an SCCP connection for a user actively transmitting and/or

Services provided by the SCCP

Figure 7: SCCP Services

SCCP provides control of logical signalling connections in a SS7 network.

Reference” parameter value in the Attach Complete Message (from RNC to

4.4.1.1 connection confirm (CC):

4.4.1.2 connection request (CR):

4.4.1.3 connection refused (CREF):

4.4.1.4 data acknowledgement (AK):

4.4.1.5 data form 1 (DT1):

4.4.1.6 data form 2 (DT2):

4.4.1.7 expedited data (ED):

4.4.1.8 expedited data acknowledgement (EA):

4.4.1.9 inactivity test (IT):

4.4.1.10 protocol data unit error (ERR):

4.4.1.11 released (RLSD):

4.4.1.12 release complete (RLC):

4.4.1.13 reset confirm (RSC):

4.4.1.14 reset request (RSR):

4.4.1.15 subsystem-allowed (SSA):

4.4.1.16 subsystem-out-of-service-grant (SOG):

4.4.1.17 subsystem-out-of-service-request (SOR):