HWI - Protocol and Signaling Analysis

F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k
HUAWEI
HUAWEI UMTS Packet-Switched Core Network

Protocols and Signaling Analysis
V800R003
Huawei Technologies Proprietary
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Protocols and Signalling Analysis
Manual Version
T2-030255-20041020-C-8.30
Product Version
V800R003
BOM
31026555
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support
and service. Please feel free to contact our local office, customer care center or company
headquarters.
Huawei Technologies Co., Ltd.

Address: Administration Building, Huawei Technologies Co., Ltd.,
Bantian, Longgang District, Shenzhen, P. R. China
Postal Code: 518129
Website: http://www.huawei.com
Email: support@huawei.com
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k
Copyright Huawei Technologies Co., Ltd. 2006. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any

means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co.,

Ltd.
All other trademarks and trade names mentioned in this document are the
property of their respective holders.
Notice
The information in this document is subject to change without notice. Every effort
has been made in the preparation of this document to ensure accuracy of the
contents, but all statements, information, and recommendations in this document
do not constitute the warranty of any kind, express or implied.
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k
Summary of Updates
This section provides the update history of this manual and introduces the contents of
subsequent updates.
Update History
This manual is updated for a major product version to maintain consistency with
system hardware or software versions and to incorporate customer suggestions.
Manual Version
T2-030255-20041020-C-8.30
Notes
Initial commercial release
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k
About This Manual

Release Notes
The product version that corresponds to the manual is HUAWEI SGSN9810 Serving
GPRS Support Node V800R003.
Organization
This manual mainly describes the UMTS packet-switched core network protocols and
signalling analysis, comprising the following contents:
Chapter 1 Overview
Chapter 2 Protocol Interfaces
Chapter 3 Mobility Management Functions
Chapter 4 Session Management Functions
Chapter 5 Analysis Example
Appendix A UMTS specific cause values for mobility management
Appendix B GPRS specific cause values for session management
Appendix C Acronyms and Abbreviations
Intended Audience
The manual is intended for the following readers:
Marketing staff
Installation engineers & technicians
Operation & maintenance personnel
Conventions
This document uses the following conventions:
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k
I. General conventions
Convention
Description
Arial
Normal paragraphs are in Arial.
Arial Narrow
Warnings, cautions, notes and tips are in Arial Narrow.
Bold
Headings, Command, Command Description are in boldface.
II. Symbols
Eye-catching symbols are also used in this document to highlight the points worthy of
special attention during the operation. They are defined as follows:
Note: Means a complementary description.
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Chapter 1 Overview of Interfaces and Protocols ....................................................................... 1-1
1.1 About This Chapter ............................................................................................................ 1-1
1.2 Use of Signaling Trace Tools............................................................................................. 1-1
1.3 Protocols for Reference ..................................................................................................... 1-1
Chapter 2 Protocol Interfaces ...................................................................................................... 2-1
2.1 Overview ............................................................................................................................ 2-1
2.1.1 System Interfaces ................................................................................................... 2-1
2.1.2 Interface Introduction .............................................................................................. 2-2
2.2 Iu Interface ......................................................................................................................... 2-3
2.2.1 Definition and Functions.......................................................................................... 2-4
2.2.2 Protocol Architecture............................................................................................... 2-5
2.2.3 Signaling Bearer.................................................................................................... 2-10
2.3 Gb Interface ..................................................................................................................... 2-13
2.3.1 Overview ............................................................................................................... 2-13
2.3.2 NS ......................................................................................................................... 2-14
2.3.3 BSSGP .................................................................................................................. 2-18
2.3.4 LLC........................................................................................................................ 2-19
2.3.5 SNDCP.................................................................................................................. 2-24
2.4 Gn/Gp Interface ............................................................................................................... 2-27
2.5 Ga Interface ..................................................................................................................... 2-28
2.6 Map Interface ................................................................................................................... 2-30
2.7 Gs Interface ..................................................................................................................... 2-35
2.8 Ge Interface ..................................................................................................................... 2-36
Chapter 3 Mobility Management Functions................................................................................ 3-1
3.1 Definition of Mobility Management States ......................................................................... 3-1
3.1.1 Mobility Management States (GSM Only)............................................................... 3-1
3.1.2 Mobility Management States (UMTS Only)............................................................. 3-2
3.2 Mobility Management Timer Functions.............................................................................. 3-4
3.2.1 READY Timer Function (GSM Only)....................................................................... 3-4
3.2.2 Periodic RA Update Timer Function........................................................................ 3-4
3.2.3 Mobile Reachable Timer Function .......................................................................... 3-5
3.3 Interactions Between SGSN and MSC/VLR...................................................................... 3-5
3.3.1 Administration of the SGSN-MSC/VLR Association ............................................... 3-5
3.3.2 Combined RA/LA Updating ..................................................................................... 3-6
3.3.3 CS Paging (GSM Only) .......................................................................................... 3-6
3.3.4 CS Paging (UMTS Only) ......................................................................................... 3-7
3.3.5 Non-GPRS Alert ...................................................................................................... 3-7
i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
3.3.6 MS Information Procedure ...................................................................................... 3-7

3.3.7 MM Information Procedure...................................................................................... 3-8
3.4 GPRS Attach Function....................................................................................................... 3-8
3.4.1 GSM GPRS Attach Procedure ................................................................................ 3-8
3.4.2 Combined GPRS/IMSI Attach Procedure ............................................................... 3-9
3.5 Detach Function............................................................................................................... 3-12
3.5.1 MS-Initiated Detach Procedure ............................................................................. 3-12
3.5.2 Network-Initiated Detach Procedure ..................................................................... 3-14
3.6 Purge Function................................................................................................................. 3-16
3.7 Security Function ............................................................................................................. 3-16
3.7.1 Authentication........................................................................................................ 3-17
3.7.2 User Identity Confidentiality .................................................................................. 3-18
3.7.3 User Data and GMM/SM Signalling Confidentiality .............................................. 3-19
3.7.4 Identity Check Procedures .................................................................................... 3-20
3.7.5 Data Integrity Procedure (UMTS Only) ................................................................. 3-20
3.8 Location Management Function ...................................................................................... 3-20
3.8.1 Location Management Procedures (GSM Only) ................................................... 3-21
3.8.2 Location Management Procedures (UMTS Only) ................................................ 3-29
3.8.3 Periodic RA/LA Update ......................................................................................... 3-45
3.9 Subscriber Management Function................................................................................... 3-46
3.9.1 Subscriber Management Procedures ................................................................... 3-46
3.10 Service Request Procedure s (UMTS Only).................................................................. 3-47
3.10.1 MS-Initiated Service Request Procedure............................................................ 3-47
3.10.2 Network-Initiated Service Request Procedure .................................................... 3-49
3.11 UMTS-GSM Intersystem Change .................................................................................. 3-51
3.11.1 Intra SGSN Intersystem Change......................................................................... 3-51
3.11.2 Inter SGSN Intersystem Change......................................................................... 3-57
3.12 Classmark Handling....................................................................................................... 3-66
3.12.1 Radio Access Classmark .................................................................................... 3-66
3.12.2 MS Network Capability........................................................................................ 3-66
Chapter 4 Session Management Functions................................................................................ 4-1
4.1 Definition of Packet Data Protocol States.......................................................................... 4-1
4.1.1 INACTIVE State ...................................................................................................... 4-1
4.1.2 ACTIVE State .......................................................................................................... 4-2
4.2 PDP Context Activation, Modification, Deactivation, and Preservation Functions ............ 4-3
4.2.1 Static and Dynamic PDP Addresses....................................................................... 4-3
4.2.2 Activation Procedures ............................................................................................. 4-4
4.2.3 Modification Procedures.......................................................................................... 4-8
4.2.4 Deactivation Procedures ....................................................................................... 4-12
4.2.5 Preservation Procedures and Re-establishment of RABs .................................... 4-14
Chapter 5 Typical Signaling Analysis Cases.............................................................................. 5-1
5.1 Overview of Typical Signaling Analysis ............................................................................. 5-1
ii
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
5.2 GPRS Attach Procedure.................................................................................................... 5-1

5.2.1 Example .................................................................................................................. 5-1
5.2.2 ATTACH REQUEST Message................................................................................ 5-2
5.2.3 AUTHENTICATION AND CIPHERING REQUEST Message................................. 5-5
5.2.4 AUTHENTICATION AND CIPHERING RESPONSE Message .............................. 5-6
5.2.5 MAP_OPEN_REQ Service ..................................................................................... 5-6
5.2.6 MAP_SERVICE_REQ Service................................................................................ 5-7
5.2.7 MAP_SERVICE_IND Service ................................................................................. 5-8
5.2.8 MAP SERVICE CNF Service .................................................................................. 5-9
5.2.9 ATTACH ACCEPT Message................................................................................. 5-10
5.2.10 ATTACH COMPLETE Message ......................................................................... 5-12
5.3 Combined Attach Procedure............................................................................................ 5-12
5.3.1 Example ................................................................................................................ 5-12
5.3.2 BSSAP+-LOCATION-UPDATE-REQUEST Message .......................................... 5-13
5.3.3 BSSAP+-LOCATION-UPDATE-ACCEPT Message ............................................. 5-14
5.4 Combined RA/LA Update Procedure............................................................................... 5-14
5.4.1 Example ................................................................................................................ 5-14
5.4.2 RA UPDATE REQUEST Message........................................................................ 5-15
5.4.3 BSSAP UPDATE LOCATION REQUEST Message ............................................. 5-16
5.4.4 BSSAP UPDATE LOCATION ACCEPT Message................................................ 5-17
5.4.5 RA ACCEPT Message .......................................................................................... 5-18
5.5 PDP Context Activation Procedure.................................................................................. 5-20
5.5.1 Example ................................................................................................................ 5-20
5.5.2 SERVICE REQUEST Message ............................................................................ 5-21
5.5.3 ACTIVATE PDP CONTEXT REQUEST Message................................................ 5-21
5.5.4 CREATE PDP CONTEXT REQUEST Message................................................... 5-22
5.5.5 CREATE PDP CONTEXT RESPONSE Message ................................................ 5-24
5.5.6 ACTIVATE PDP CONTEXT ACCEPT Message................................................... 5-25
5.6 Abnormal Attach Procedure............................................................................................. 5-26
5.6.1 Overview of Abnormal Attach Procedure.............................................................. 5-26
5.6.2 Protocol error, unspecified .................................................................................... 5-26
5.6.3 Illegal MS............................................................................................................... 5-28
5.6.4 Gs Interface Fault.................................................................................................. 5-30
5.7 Abnormal PDP Activation Procedure............................................................................... 5-32
5.7.1 Overview of Abnormal PDP Context Activation Procedure .................................. 5-32
5.7.2 Request Service Option not Subscribed ............................................................... 5-33
5.7.3 Activate Rejected by GGSN.................................................................................. 5-37
Appendix A UMTS Specific Cause Values for Mobility Management ......................................A-1
A.1 Causes related to MS identification...................................................................................A-1
A.1.1 Cause value = 2 IMSI unknown in HLR..................................................................A-1
A.1.2 Cause value = 3 Illegal MS .....................................................................................A-1
A.1.3 Cause value = 4 IMSI unknown in VLR ..................................................................A-1

iii
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
A.1.4 Cause value = 5 IMEI not accepted........................................................................A-1

A.1.5 Cause value = 6 Illegal ME .....................................................................................A-2
A.2 Cause related to subscription options ...............................................................................A-2
A.2.1 Cause value = 11 PLMN not allowed .....................................................................A-2
A.2.2 Cause value = 12 Location Area not allowed .........................................................A-2
A.2.3 Cause value = 13 Roaming not allowed in this location area.................................A-2
A.2.4 Cause value = 15 No Suitable Cells In Location Area............................................A-2
A.3 Causes related to PLMN specific network failures and congestion/Authentication FailuresA-2
A.3.1 Cause value = 20 MAC failure................................................................................A-2
A.3.2 Cause value = 21 Synch failure..............................................................................A-3
A.3.3 Cause value = 17 Network failure...........................................................................A-3
A.3.4 Cause value = 22 Congestion ................................................................................A-3
A.3.5 Cause value = 23 GSM authentication unacceptable ............................................A-3
A.4 Causes related to nature of request ..................................................................................A-3
A.4.1 Cause value = 32 Service option not supported.....................................................A-3
A.4.2 Cause value = 33 Requested service option not subscribed .................................A-3
A.4.3 Cause value = 34 Service option temporarily out of order .....................................A-3
A.4.4 Cause value = 38 Call cannot be identified ............................................................A-4
A.5 Additional cause codes for GMM ......................................................................................A-4
A.5.1 Cause value = 7 GPRS services not allowed .........................................................A-4
A.5.2 Cause value = 8 GPRS services and non-GPRS services not allowed .................A-4
A.5.3 Cause value = 9 MS identity cannot be derived by the network.............................A-4
A.5.4 Cause value = 10 Implicitly detached .....................................................................A-4
A.5.5 Cause value = 14 GPRS services not allowed in this PLMN .................................A-4
A.5.6 Cause value = 16 MSC temporarily not reachable.................................................A-4
A.5.7 Cause value = 40 No PDP context activated..........................................................A-5
Appendix B GPRS Specific Cause Values for Session Management ......................................B-1
B.1 Causes related to nature of request ..................................................................................B-1
B.1.1 Cause value = 8 Operator Determined Barring ......................................................B-1
B.1.2 Cause value = 25 LLC or SNDCP failure (GSM only) ............................................B-1
B.1.3 Cause value = 26 Insufficient resources.................................................................B-1
B.1.4 Cause value = 27 Unknown or missing access point name ...................................B-1
B.1.5 Cause value = 28 Unknown PDP address or PDP type.........................................B-1
B.1.6 Cause value = 29 User authentication failed ..........................................................B-2
B.1.7 Cause value = 30 Activation rejected by GGSN.....................................................B-2
B.1.8 Cause value = 31 Activation rejected, unspecified.................................................B-2
B.1.9 Cause value = 32 Service option not supported.....................................................B-2
B.1.10 Cause value = 33 Requested service option not subscribed ...............................B-2
B.1.11 Cause value = 34 Service option temporarily out of order ...................................B-2
B.1.12 Cause value = 35 NSAPI already used ................................................................B-2
B.1.13 Cause value = 36 Regular PDP context deactivation...........................................B-3
B.1.14 Cause value = 37 QoS not accepted....................................................................B-3

iv
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
B.1.15 Cause value = 38 Network failure.........................................................................B-3

B.1.16 Cause value = 39 Reactivation requested............................................................B-3
B.1.17 Cause value = 40 Feature not supported .............................................................B-3
B.1.18 Cause value = 41 semantic error in the TFT operation. .......................................B-3
B.1.19 Cause value = 42 syntactical error in the TFT operation......................................B-3
B.1.20 Cause value = 43 unknown PDP context .............................................................B-3
B.1.21 Cause value = 44 semantic errors in packet filter(s) ............................................B-4
B.1.22 Cause value = 45 syntactical error in packet filter(s)............................................B-4
B.1.23 Cause value = 46 PDP context without TFT already activated ............................B-4
Appendix C Acronyms and Abbreviations .................................................................................C-1
Index ................................................................................................................................................ i-1

v
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Chapter 1 Overview of Interfaces and Protocols ....................................................................... 1-1
1.1 About This Chapter ............................................................................................................ 1-1
1.2 Use of Signaling Trace Tools............................................................................................. 1-1
1.3 Protocols for Reference ..................................................................................................... 1-1

i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Chapter 1 Overview of Interfaces and Protocols
Chapter 1 Overview of Interfaces and Protocols

1.1 About This Chapter
This manual presents fundamentals about the UMTS PS signaling and protocol
analysis. It helps the maintenance personnel in equipment maintenance and fault
diagnostics and provides protocol and signaling analysis guides to the intended
readers.
This manual only describes the PS signaling and protocols involved in the mobility
management (MM) and session management (SM). It also illustrates the signaling
analysis procedures through typical examples.
1.2 Use of Signaling Trace Tools

The LMT of SGSN9810 provides tools for signaling trace and trace review. Through
these tools, you can:
trace messages of an MS,
trace messages over a protocol interface,
save traced information, and
analyze the saved data after you have exited the LMT.
For the use of these tools, see HUAWEI SGSN9810 Serving GPRS Support Node
Operation Manual Routine Operation and the Online Help for SGSN9810.
1.3 Protocols for Reference

The following documents provide reference for the composition of the present
document:
TS
23.060
General Packet Radio Service (GPRS) Service description;
Stage 2
TS
24.008
Mobile Radio Interface Layer 3 specification; Core Network
Protocols - Stage 3
TS
29.002
Mobile Application Part (MAP)
TS
29.018
Serving GPRS Support Mode SGSN - Visitors Location Register
(VLR); Gs Interface Layer 3 Specification

TS
29.060
GPRS Tunnelling protocol (GTP) across the Gn and Gp
interface
TS
32.105
3G Charging call event data

1-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Chapter 2 Protocol Interfaces ...................................................................................................... 2-1
2.1 Overview ............................................................................................................................ 2-1
2.1.1 System Interfaces ................................................................................................... 2-1
2.1.2 Interface Introduction .............................................................................................. 2-2
2.2 Iu Interface ......................................................................................................................... 2-3
2.2.1 Definition and Functions.......................................................................................... 2-4
2.2.2 Protocol Architecture ............................................................................................... 2-5
2.2.3 Signaling Bearer.................................................................................................... 2-10
2.3 Gb Interface ..................................................................................................................... 2-13
2.3.1 Overview ............................................................................................................... 2-13
2.3.2 NS ......................................................................................................................... 2-14
2.3.3 BSSGP .................................................................................................................. 2-18
2.3.4 LLC........................................................................................................................ 2-19
2.3.5 SNDCP.................................................................................................................. 2-24
2.4 Gn/Gp Interface ............................................................................................................... 2-27
2.5 Ga Interface ..................................................................................................................... 2-29
2.6 Map Interface ................................................................................................................... 2-31
2.7 Gs Interface ..................................................................................................................... 2-36
2.8 Ge Interface ..................................................................................................................... 2-37

i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


2.1 Overview
This chapter introduces various interfaces between SGSN9810 SGSN and other
functional entities in the network, as well as those between system internal functional
entities. The information in this chapter covers the definitions, related protocols and
functions of the interfaces. It gives the reader a general idea of the interfaces of SGSN.
Detailed information about various interfaces (classified by protocol), including the
related protocol architecture, and signaling procedure, will be provided in the
subsequent chapters.
2.1.1 System Interfaces

The standard interfaces of SGSN9810 are shown in Figure 2-1.
ISDN
PSTN
Other PLMN
GSN
PDN
Gi
HLR/AuC
PRA
PSTN
scp
C/D
Gd
Gs
Ga
SGSN
Gn
SMSC
VLR
MSC
Gr
cap
cap
VLR
Gp
GGSN
CGF
MSC
CN
A
Iu-CS
Gb
BSS
Iu-PS
UTRAN
AUC: Authentication Center

ISDN: Integrated Service Digital Network
SCP: Service Control Point
CN: Core Network
VLR: Visitor Location Register
GGSN: Gateway GPRS Support Node
SMSC: Short Message Service Center
PDN: Packet Data Network
BSS: GSM Base station Subsystem

HLR: Home Location Register
MSC: Mobile Switching Center
SGSN: Serving GPRS Support Node
PSTN: Public Switched Telephone Network
CGF: (PS) Charging Gateway Functionality (entity)
UTRAN: UMTS Terrestrial Radio Access Network
Figure 2-1 SGSN9810 system interfaces

2-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

The definitions and related protocols are listed in Table 2-1.

Table 2-1 SGSN interfaces
Interface
Entities related
Signaling and protocol
Iu-PS
SGSN UTRAN
RANAP, IUUP
Gb
SGSN BSS
SNDCP, BSSGP
Gr
SGSN HLR
MAP
Gd
SGSN SMSC
MAP
Gs
SGSN MSC
BSSAP+
Gn/Gp
GSN GSN
GTP
Ga
GSN CGF
GTP'
2.1.2 Interface Introduction

This section introduces the basic functions of various interfaces.
I. Iu interface
The Iu interface connects UMTS CN and UTRAN and can be logically classified into
Iu-CS interface and Iu-PS interface according to different processing domains. The
Iu-CS interface connects UTRAN and MSC, and the Iu-PS interface connects
SGSNs.
The functions of Iu interface are:
Radio Access Bearer (RAB) management
Radio resource management
Rate adaptation
Iu connection management
Iu interface user plane management
Mobility management
Security management
Service and network access
Iu coordinating processing (paging coordination)
II. Gb interface
The Gb interface connects 2.5G BSS and SGSN. SGSN exchanges data and
signaling with BSS/MS via this interface. The Gb interface allows many MSs to be
multiplexed over the same physical resource. This is in contrast to the A interface
where a single MS can be seizing a dedicated physical resource throughout the

2-2
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

lifetime of a call. The Gb interface user plane protocol include NS, BSSGP, LLC and
SNDCP. The LLC layer and lower layers in the control plane protocol are completely
the same as those in the user plane protocol. The control plane protocol also contains
GMM and SM instead of SNDCP.
III. Gr interface
Gr interface connects SGSN and HLR, allowing the exchange of information related
to MS location and user management. SGSN provides the MS location information to
HLR, and HLR sends the mobile subscriber data required for service realization to
SGSN. In addition, by means of GTP protocol SGSN can provide an interface (i.e. Gc
interface) to connect the GGSN not installed with SS7 system with HLR.
IV. Gd interface
The Gd interface connects SGSN and SMSC. It is used for the exchange of short
message information between SGSN and SMS-MSC.
V. Gs interface
The Gs interface connects SGSN and MSC/VLR. SGSN sends location information to
MSC/VLR and receives paging requests from MSC/VLR via Gs interface. On the
other hand, MSC/VLR notifies SGSN that a MS is using the service provided by MSC
via this interface. The signaling of this interface adopts the connectionless function of
SCCP, therefore, TCAP is not needed, and SCCP Global Title (GT) is used for
addressing instead.
VI. Gn/Gp/Ga interface

TheGn interface connects GSNs in the same PLMN. The Gp interface connects
GSNs in different PLMNs, and these GSNs have the same protocol hierarchy. The Ga
interface connects GSN and CG for the transmission of billing information.
The core of Gn/Gp/Ga protocol is GPRS Tunnel Protocol (GTP). The network layer
data packets to be transmitted (e.g. IP packet, X.25 packet) should be encapsulated
in GTP format and be added with information related to the subscriber, such as TEID
or TID/Flowlabel before being encapsulated in TCP/UDP and IP formats with the IP
addresses of originating and destination GSNs attached. The encapsulated data
packet is sent from the originating GSN to destination GSN through "tunnel". The
GPRS tunnel protocol applicable to Ga interface is GTP.
2.2 Iu Interface
This chapter briefly introduces the definition, function and protocol architecture of Iu
interface and then describes the Iu interface radio network control plane, user plane
2-3
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

(involving RANAP and IuUP) in detail. After reading this chapter, the reader will have a
comprehensive idea about Iu interface.
2.2.1 Definition and Functions

The Iu interface connects the UTRAN to the CN. The CN can be composed of CS
(providing circuit-switched services), PS (providing packet-switched services) and BC
(providing broadcast services). The Iu interfaces corresponding to these three
logically independent CN domains are Iu-CS, Iu-PS and Iu-BC. The basic architecture
of Iu interface is shown in Figure 2-2.
UTRAN
Core Network (CN)

CS
Domain
Node B
RNC
Iu-CS
Node B
PS
Domain
Iu-PS
Node B
RNC
BC
Domain
Node B
Iu-BC
Iu Interface
Figure 2-2 Basic architecture of Iu interface
The Iu interfaces between RNC and CN are defined as follows:

1) There is only one Iu-CS interface between an RNC and CS domain.
2) There is only one Iu-PS interface between an RNC and PS domain.
3) There can be multiple Iu-BC interfaces between an RNC and BC domain.
Note:
In the broadcast service, SGSN is in charge of route forwarding only, so this chapter will omit the detailed
information of Iu-BC interface.
The Iu interface realizes the following functions:

Radio Access Bearer (RAB) management
2-4
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Radio resource management

Rate adaptation
Iu connection management
Iu interface user plane management
Mobility management
Security management
Service and network access
Iu co-ordination (paging co-ordination)
2.2.2 Protocol Architecture

The Iu, Iur and Iub interfaces are called UTRAN interfaces. This section describes the
universal protocol model of UTRAN interfaces, and then the general protocol
architecture of the Iu interface, and finally the protocol architecture of the Iu-PS
interface.
I. Universal protocol model of the UTRAN interface

Figure 2-3 illustrates the overall architecture of UTRAN.
Core Network
Iu
Iu
RNS
RNS
Iur
RNC
Iub
Node B
RNC
Iub
Iub
Node B
Node B
Iub
Node B
Figure 2-3 Overall architecture of UTRAN
As shown in Figure 2-3, the UTRAN contains the Iu interface, Iur interface and Iub
interface. They all comply with the universal protocol model of the UTRAN interface,
as shown in Figure 2-4. This architecture is set up following the principle of mutual
independence between layers and planes. However, with the evolution of 3GPP
standards, this architecture may be subject to some changes.

2-5
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Radio
Network
Layer
Transport
Network
Layer
Control Plane
User Plane
Application
Protocol
Data
Stream(s)
Transport Network
User Plane
Transport Network
Control Plane
Transport Network
User Plane
ALCAP(s)
Signaling
Bearer(s)
Signaling
Bearer(s)
Data
Bearer(s)
Physical Layer
Figure 2-4 Universal protocol model of the UTRAN interface
1) Horizontal layer
There are two horizontal layers, Radio Network Layer and Transport Network Layer,
in the protocol model. Such architecture guarantees the independent development of
each layer, and their lowest dependence. All UTRAN technologies are related to radio
network layer only. The transport network layer is only the standard transport
technology adopted for UTRAN interfaces, and has no relation with the functions of
the Iu interface. Physical Layer is adaptable to multiple standard interfaces such as
E1, T1 and STM-1.
2) Vertical plane
Control plane
Control plane includes the application protocol of radio network layer and signaling
bearer for transporting application protocol message. Radio Access Network
Application Protocol (RANAP) serves as the radio network layer of the Iu interface, in
charge of the signaling exchange between CN and RNS.
All the three interfaces adopt ATM technology at transport network layer. 3GPP also
recommends other technologies that support SS7, such as SCCP, MTP and IP.
User plane
User plane consists of data stream and data bearer for the transmission of data
stream. Data stream is the frame protocol defined by various interfaces. The user
plane frame protocol of Iu interface is Iu UP protocol.
Transport network control plane
Transport network control plane exists in transport layer only. It does not contain any
message of radio network control plane. It only contains Access Link Control
Application Protocol (ALCAP) necessary for user plane bearer (data bearer),
including the signaling bearer required for ALCAP.

2-6
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

The application of transport network control plane enables the application protocol of
radio network control plane to be completely independent of user plane data bearer
technology. When the transport network control plane is adopted, the user plane data
bearer is set up in the following way:
The application protocol of control plane initiates the procedure of message
exchange.
The conversation procedure activates the ALCAP protocol to set up user plane
data bearer.
Note:
Transport network user plane: User plane data bearer and signaling bearer of application protocol both
belong to transport network user plane. As mentioned above, the data bearer of user plane is controlled
directly by ALCAP of transport network control plane, but the signaling bearer of application protocol is
set up by O&M.
II. General protocol architecture of Iu interface

The general protocol architecture of the Iu interface complies with the UTRAN
interface universal protocol model shown in Figure 2-3. Its specific architecture is
shown in Figure 2-5.

2-7
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Radio
Network
Layer
Transport
Network
Layer
Control Plane
User Plane
25.413
25.415
Transport Network
User Plane
Transport Network
User Plane
Transport Network
Control Plane
25.414
25.412
25.411
25.411: UTRAN Iu Interface Layer1

25.412: UTRAN Iu Interface Signaling Transport
25.413: UTRAN Iu Interface RANAP Signaling
25.414: UTRAN Iu Interface Data Transport & Transport Signaling
25.415: UTRAN Iu Interface User Plane Protocols
Figure 2-5 Iu interface protocol architecture
Note:
The numerals in the figure, such as 25.413, are the 3GPP specifications of the corresponding functions.
III. PS-oriented Iu interface protocol architecture

According to the different domains of the CN node, the Iu interface protocol stack can
be divided into CS-oriented architecture (Iu-CS) and PS-oriented architecture (Iu-PS).
The PS-oriented Iu interface protocol architecture described in 3GPP 25.410 is shown
in Figure 2-6.

2-8
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Radio
Network
Layer
Control Plane
User Plane
RANAP
Iu UP Protocol
Layer
Transport
Network
Layer
Transport Network
User Plane
Transport Network
Control Plane
Transport Network
User Plane
SCCP
M3UA
MTP3-B
GTP-U
SCTP
SSCF-NNI
SSCF-NNI
UDP
IP
SSCOP
IP
AAL5
AAL5
ATM
ATM
Physical Layer
Physical Layer
Figure 2-6 Iu-PS protocol architecture
As shown in Figure 2-6, 3GPP 25.412 (UTRAN Iu Interface Signaling Transport)

allows two architectures for the transport network layer of PS-oriented control plane.
The user can select any bottom protocol architecture to send SCCP messages.
SGSN9810 adopts the architecture on the left in Figure 2-7.

2-9
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Radio
Network
Layer
Control Plane
User Plane
RANAP
Iu UP Protocol
Layer
Transport
Network
Layer
Transport Network
User Plane
Transport Network
Control Plane
Transport Network
User Plane
SCCP
MTP3-B
GTP-U
SSCF-NNI
SSCF-NNI
UDP
SSCOP
IP
AAL5
AAL5
ATM
ATM
Physical Layer
Physical Layer
Figure 2-7 SGSN9810 PS-oriented Iu interface protocol architecture
Note:
Next section introduces the signaling bearer (TS25.412), control plane signaling RANAP (TS25.413),
data bearer and bearer protocol (TS25.414) of the Iu interface according to Figure 2-7.
The information about Iu interface physical layer (TS25.411) will not be introduced in this manual.
2.2.3 Signaling Bearer

The architecture of Iu interface control plane protocol defined in 3GPP TS25.412 is
shown in Figure 2-8.

2-10
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Control Plane
25.413
RANAP
SCCP-SAP
SCCP
MTP3-B
SAAL-NNI
M3UA
SCTP
IP
AAL5
25.412
ATM
Figure 2-8 Two architectures of Iu interface control plane defined in protocol
The Iu interface control plane consists of two layers: radio network layer adopting
RANAP (TS25.413) and transport network layer providing signaling bearer. The
interface between these two layers is SCCP-SAP. The signaling bearer mentioned in
this section refers to the part under "SCCP-SAP" in Figure 2-8.
TS25.412 specifies two signaling bearing modes: B-ISDN broadband SS7 system
and SS7 system borne on IP. Both modes are based on ATM.
In SGSN9810, PS adopts B-ISDN. Accordingly, the protocol model of signaling bearer
is as shown in Figure 2-9.
Control Plane
RANAP
SCCP-SAP
SCCP
MTP3-B
SAAL-NNI
ATM
Figure 2-9 Protocol architecture of SGSN9810 Iu interface control plane

2-11
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

As shown in Figure 2-9, the layer signaling bearer contains three layers of protocols:
SCCP, MTP3B and SAAL-NNI.
I. SCCP
Signaling Connection Control Part (SCCP) supports two types of services: Type 0
connectionless service and Type 2 connection-oriented service. These two services
respectively support the universal procedure with no relation to specified UE and the
signaling procedure related to a specified UE.
II. MTP3-B
Message Transfer Part (MTP3-B) supports routing, identification and distribution of
messages, signaling link management, load-sharing, inter-link switching in a link set.
III. SAAL-NNI
Signaling ATM Adaptation Layer - Network Node Interface (SAAL-NNI) consists of
three sub-layers: SSCF, SSCOP and AAL5.
Service Specific Co-ordination Function (SSCF) converts the demands from
upper layer into SSCOP demands, and provides SAAL connection management
as well as link status and remote process status management.
Service Specific Connection Oriented Protocol (SSCOP) sets up and releases
the connection between signaling entities and provides reliable exchange
mechanism of signaling message.
ATM Adaptation Layer 5 (AAL5) adapts the upper layer protocol to the bottom
layer ATM cells.
Note:
For details of SCCP, MTP3-B and SAAL-NNI, please refer to Broadband SS7 System.
The ATM layer on radio network control plane is defined in "B-ISDN ATM layer specification"
recommended by ITU-T I.361 (11/1995).

2-12
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

2.3 Gb Interface
2.3.1 Overview
I. Definition
The Gb interface connects the SGSN and GSM BSS. It transfers GPRS data and
signaling between SGSN and GSM BSS/MS in the packet mode of statistics
multiplexing.
The GSM A interface allocates dedicated physical resource to each subscriber in
conversation. The subscriber seizes the dedicated physical resource throughout the
entire conversation. The resource allocation has nothing to do with the information
volume of this subscriber. While the Gb interface allows multiple subscribers to share
a common physical resource. GPRS signaling and subscriber data are sent by means
of the same physical resource. Besides, the access rate of each subscriber can vary
from 0 to the maximum bandwidth (e.g. the available bit rate of an E1).
II. Protocol Architecture protocol architecture

The Gb interface consists of user plane and control plane. The user plane protocol
stack is composed of Subnetwork Dependent Convergence Protocol (SNDCP),
Logical Link Control (LLC), BSS GRPS Protocol (BSSGP), Network Service (NS) and
L1, as shown in Figure 2-10.
Application
IP
IP
Relay
SNDCP
SNDCP
LLC
GTP-U
GTP-U
UDP
UDP
LLC
Relay
RLC
RLC
BSSGP
BSSGP
IP
IP
MAC
MAC
Network
Service
Network
Service
L2
L2
GSM RF
GSM RF
L1bis
L1bis
L1
L1
Um
MS
Gb
BSS
Gn
SGSN
Gi
GGSN
Figure 2-10 Gb interface protocol stack in user plane
In the user plane, SNDCP, LLC, BSSGP and NS cooperate with each other to transfer
the N-PDU sent from GTP-U to BSS/MS or the data from BSS/MS to GTP-U.
The Gb interface control plane stack is shown in Figure 2-11. LLC, BSSGP and NS
provide unacknowledged transparent signaling transmission channel for GMM/SM.
2-13
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

GMM/SM
GMM/SM
LLC
LLC
Relay
RLC
RLC
MAC
MAC
GSM RF
BSSGP
BSSGP
Network
Service
GSM RF
L1bis
Network
Service
L1bis
Um
MS
Gb
BSS
2G-SGSN
Figure 2-11 Gb protocol stack in control plane
The coming sections focus on the description of NS, BSSGP, LLC and SNDCP.
2.3.2 NS
Network Service (NS) is responsible for the NSSDU transmission between the SGSN
and BSS. The services it provides are:
NS SDU transmission
Network congestion indication
Status indication
NS entity consists of two parts:
Sub-network service related to intermediate transport network used by the Gb
interface.
Network service control which is independent from intermediate network.
There is a layer relationship between the two entities, as shown in Figure 2-12.
Network Service
Network Service Control /

Network Service Control protocol
Sub-Network Service /
Sub-Network Service protocol
Figure 2-12 NS internal architecture

2-14
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

I. NS Sub-NetworkServiceprotocol
The Gb interface uses FrameRelay as the NS Sub-NetworkServiceprotocol. The
FrameRelay module enables the interworking between subnets and realizes the
dedicated connection (P2P) or connection by means of the frame relay network
(intermediate network) between BSS and SGSN, as shown in Figure 2-13 and Figure
2-14.
Gb
BSS
(user)
SGSN
(network)
Figure 2-13 Gb interface P2P frame relay mode
Gb
BSS
(user)
Gb
Frame Relay
network
SGSN
(user)
Figure 2-14 Gb interface frame relay network mode
The major functions of FR are:

LMI
Transmitting and receiving FR frame
Congestion statistics report
FR sub-layer is the lower layer protocol part of the Gb interface. Its function is simpler
than the normal frame relay.
NS follows the addressing principles given below:
Physical link is FR BC.
NS-VC corresponds to a FRPVC.

2-15
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. NS Control Sublayer

The major functions of NS control sublayer are:
NS control Sublayer uses the PVC provided by FR to provide unacknowledged
data transmission and reception for the upper layer between BSS and SGSN.
NS control Sublayer uses the congestion report mechanism provided by FR to
provide link congestion indication for the upper layer. The clearance of link
congestion is realized by FR.
NS control Sublayer provides status indication for the upper layer, such as the
change of link transmission capability.
NS control Sublayer provides load-sharing on valid PVC.
All messages on the Gb interface are transmitted through NS in the format of NSSDU.
NS provides PVC data link for the upper layer to realize the transparent data
transmission for the upper layer in load-sharing mode. In normal cases, NS
guarantees the orderliness of NSSDU. This is realized by Link Selection Parameter
(LSP). But in abnormal cases (e.g. load-sharing), such orderliness may not be 100%
guaranteed.
The status management of NS-VC includes reset, blocking, unblocking and test of
NS-VC.
If BSS or SGSN needs to block a NS-VC, it will send the block message to the peer to
block this NS-VC, and at the same time, change the load-sharing of NS to switch the
service load on this NS-VC to other NS-VCs.
If BSS or SGSN needs to unblock a NS-VC, it will send the unblock message to the
peer to unblock this NS-VC, and at the same time, the load-sharing of NS will be
rearranged to notify the NS users (e.g. BSSGP) about the new transport capability of
NS.
After setting up a new NS-VC between peer NS entities or after system failure has
been cleared, it is necessary to reset the NS-VCs. After successful reset, the NS-VCs
at both sides of the Gb interface are all blocked and activated.
If BSS or SGSN needs to check whether there is P2P communication on a certain
NS-VC, it will send the test message to the peer to implement test operation. Test
operation can be implemented only after a successful reset. In this operation, the test
message will be sent periodically.
When detecting errors or congestion on the lower layer links, NS will notify NS users
about the abnormality by means of congestion indication and status message, and at
the same time, it will notify its new transport capability to NS users so that they make
corresponding changes.

2-16
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

The most important function of NS is load-sharing of subscriber data. When the upper
layer users of NS transmit data to NS, each of them is allocated with an LSP which is
attached to the data packet to be transmitted. NS guarantees the orderliness of data
transmission on the basis of LSP. NS selects one or more available NS-VCs for
transportation of data packets according to LSP and BVCI, so that the load of NS can
be balanced among all unblocked NS-VCs controlled by the same NSE.
III. Load-sharing
Figure 2-15 illustrates the Gb interface addressing principles in case of P2P frame
relay connection.
BSS#1
SGSN
NS-VCI=a
NS-VCI=a
DLCI=98
BVCI=I
PTP,
cell 1
BVCI=I
bearer chan. = 1
NS-VCI=b
NS-VCI=b
DLCI=17
BVCI=II
PTP,
cell 2
BVCI=II
NS-VCI=c
NS-VCI=c
BVCI=III
DLCI=21
BVCI=III
NS-VCI=d
PTM
bearer chan. = 2
NS-VCI=d
DLCI=302
BVCI=IV
BVCI=IV
signalling
NS-VCI=e
NS-VCI=e
BSS#2
BVCI=V
DLCI=16
bearer chan. = 3
PTP,
cell 3
BVCI=VI
BVCI=V
NS-VCI=f
PTM
NS-VCI=f
DLCI=511
BVCI=VI
BVCI=VII
bearer chan. = 4
signalling
BVCI=VII
Figure 2-15 Gb interface (P2P frame relay connection)

2-17
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Both sides of the Gb interface use the same physical link. In Figure 2-15, it is
assumed that a bearer channel is allocated with the same channel ID at both sides. In
practice, it will be OK for a channel to be allocated with different IDs at two sides.
The address mapping relationship is as follows:
The BVCs (each corresponding to a cell) controlled by the same NSE (corresponding
to a BSS) can be identified by NSEI and BVCI. They perform load-sharing between
NS-VCs controlled by the same NSE. Load-sharing is based on BVCI, NSEI and LSP.
The messages with the same LSP are shared on the same NS-VC.
NS-VCs correspond to the PVCs of FR. They are identified by BCI and DLCI.
Basic concepts:
PTP functional entity: For PTP user data transmission. Each one is corresponds to an
existing cell. A cell can be uniquely identified by NSEI and BVCI.
Signaling functional entity: For realization of other functions, such as paging. Each
network service entity corresponds to a signaling entity. Each BSS corresponds to
one or more NSEs.
BVC: Communication path between BSSGP entities, such as point-to-point (PTP)
functional entity, point-to-multipoint (PTM) functional entity and signaling functional
entity. BVC is used to transport BSSGPPDU.
BVCI: Functional entity for routeing BSSGP. BVCI is unique between two peer NSEs.
In SGSN, Gb interface is provided by the UGBI board. The numbers of NSEs and
NS-VCs each UGBI can manage are decided by the number of BVCs (cells). Their
relation is as follows.
The BC bandwidth provided by a UGBI is fixed, so the NSVC bandwidth provided is
also fixed. NS-VCs need to be divided by NSE. Since a BSS can be associated to one
or multiple NSEs while the number of cells UGBI can handle is limited, so the number
of NSEs a UGBI can manage is decided by the number of cells provided by the BSS.
The more cells, the less NSEs, and thus each board might manage only one NSE.
Contrarily, the less cells, the more NSEs, and hence each board might manage
multiple cells, i.e. multiple NSEs. In this case, one NSE corresponds to one BSS.
2.3.3 BSSGP
BSSGP is applied at both sides of the Gb interface. At SGSN, it is between LLC and
NS, providing path for the data and signaling transmission between BSS and SGSN.
The major functions of BSSGP are:

2-18
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

In downlink direction, SGSN BSSGP provides radio-related information

necessary for RLC/MAC to BSS.
In uplink direction, BSS's BSSGP provides radio-related information necessary
for RLC/MAC to CN.
Management and control of the node between SGSN and BSS.
Uplink and downlink data transmission.
Signaling message transmission.
Flow control for upper layer data in downlink direction.
BVC status management.
MS status management.
The function model of BSSGP is shown in Figure 2-16.
Service model in an BSS

RELAY
GSM 03.64
PFM
RL
GMM
PFM
RLC/MAC
GMM
Service model in an SGSN

NM
NM
LLC
BSSGP
BSSGP
PFM
GMM
PFM
GMM
NM
NM
BSSGP
GSM 08.16
GSM 08.16
Network Service
Network Service
Figure 2-16 BSSGP service model
The explanations of the terms in the figure above are listed below:
BSSGP: Control of the LLC frame transmission between SGSN and MS via the Gb
interface.
GMM (GPRS Mobility Management): Mobility management between SGSN and BSS.
NM (Network Management): Management of BSS-SGSN nodes related to the Gb
interface.
PFM (Packet Flow Management): BSS Packet Flow Context (PFC) management.
2.3.4 LLC
Logical Link Control (LLC) provides logical link between SGSN and MS for
transmitting GMM/SMS/SNDCP data or signaling encapsulated as LL-PDU to LLC of
2-19
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS. The logical link of LLC does not correspond to physical connection. Instead,
LL-PDU is sent to BSS, and then to MS, or from MS to SGSN via the same path. The
details of the transmission at the lower layer are shielded for the upper layer by LLC.
The functions of LLC are:
Providing data transmission link between MS and SGSN in Asynchronous
Balanced Mode (ABM).
Providing data transmission link between MS and SGSN in Asynchronous
Disconnected Mode (ADM).
LLC PDU multiplexing, de-multiplexing and CRC.
eXchange IDentification (XID) parameter negotiation.
Secure transmission of user data by means of encryption.
Logical link control.
Error clearance and report.
LLC provides services for GMM, SMS, TOM and SNDCP.
The LLC connection is identified by Data Link Connection Identifier (DLCI). DLCI
consists of Temporary Logical link Identifier (TLLI) of MS and Service Access Point
Identifier (SAPI).
Each LLC frame consists of header, trailer and information field. The header and
trailer fields contain SAPI, frame No. and checksum, which are used to identify the
frame and to provide reliable transmission. The length of information field is variable.
The transmission and reception of each frame are controlled by the LLC layer.
The structure of LLC is shown in Figure 2-17.

2-20
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

GPRS Mobility Management
SNDCP
TOM
SMS
Layer 3
LLGMM
LLGMM
LL3
LL5
LL9
LL11
TOM2
TOM8
LLSMS
LLC layer
Logical
Link
Management
Entity
Logical
Link
Entity
SAPI=1
Logical
Link
Entity
SAPI=3
Logical
Link
Entity
SAPI=5
Logical
Link
Entity
SAPI=9
Logical
Link
Entity
SAPI=11
Logical
Link
Entity
SAPI=2
Logical
Link
Entity
SAPI=8
Logical
Link
Entity
SAPI=7
Multiplex Procedure
LLC layer
GRR
BSSGP
MS
RLC/MAC layer
SGSN
RLC/MAC
BSSGP layer
BSSGP
Signalling
Signalling and data transfer
Figure 2-17 LLC logical structure
I. Logical link entity

The logical link procedure involves multiple logical link entities (LLEs). A LLE controls
the information flow of an independent connection. A TLLI may correspond to multiple
LLEs. The functions of a LLE are:
Data transmission in unacknowledged mode.
Data transmission in acknowledged mode.
Flow control in ABM mode.
Frame error detection.
LLE analyzes the control field of each frame received and provides correct responses
and inter-layer indications. Besides that, LLE analyzes LLC service primitives and
sends proper command and response frames. Each DLCI has a LLE.

2-21
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. Multiplex procedure

During frame transmission, the multiplex procedure generates and inserts Frame
Check Sequence (FCS), implements frame encryption, and provides SAPI-based
logical link control layer contention resolution between LLEs.
During frame reception, the multiplex procedure implements frame decryption and
checks FCS. If the frame passes the FCS check, the multiplex procedure distributes it
to the proper logical link entity according to DLCI.
III. Logical link management

Logical link Management Entity (LLME) manages the resources related to single
connection. One TLLI corresponds to one LLME. LLME provides the following
functions:
Parameter initialization.
Error handling.
Connection flow control.
IV. SAPI
Service Access Point Identifier (SAPI) identifies the access point through which LLC
provides services for the upper layer. Therefore, SAPI identifies a LLE responsible for
LLC frame processing and a L3 entity receiving the information contained in LLC
frame.
There are totally 16 service access points allowed. The values of SAPI are shown in
Table 2-2.
Table 2-2 SAPI values
SAPI
RelatedService
SAPName
0000
Reserved
0001
GPRSMobilityManagement
LLGMM
0010
Tunnellingofmessages2
TOM2
0011
Userdata1
LL3
0100
Reserved
0101
Userdata2
LL5
0110
Reserved
0111
SMS
LLSMS
1000
Tunnellingofmessages8
TOM8
1001
Userdata3
LL9

2-22
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

SAPI
RelatedService
SAPName
1010
Reserved
1011
Userdata4
LL11
1100
Reserved
1101
Reserved
1110
Reserved
1111
Reserved
V. Unacknowledge operation mode

In unacknowledged operation mode, L3 information is sent using numbered
unacknowledged information (UI) frame. UI frames are not acknowledged at LLC
layer. Neither error correction nor out-of-sequence handling mechanisms are defined.
However, the transmission and format errors are detected. Duplicate UI frames are
discarded. No flow control procedures are defined in this mode.
There are two types of unacknowledged modes:
Protected mode, in which FCS protects the frame header and information field.
Unprotected mode, in which FCS protects the frame header and the first N202
bytes in the information field only.
VI. Acknowledged operation mode

In acknowledged operation mode, L3 information is sent using numbered information
frame (I frame) in sequence. I frames are acknowledged at LLC layer. Error correction
and reordering procedure based on retransmission are specified. In case errors that
cannot be cleared occur at the LLC layer, GMM shall receive the corresponding
notification. There is flow control procedure in this mode.
VII. Setup of information transmission mode

1) Data Link Connection Identifier (DLCI)
A logical link is identified by a DLCI. DLCI consists of two parts: SAPI and TLLI.
The SAPI is used to identify the service access point of LLC interface between SGSN
and MS. The address field in each LLC frame contains SAPI.
The TLLI is used to identify a specific MS. It is assigned by GMM. It is not contained in
LLC frame but in BSSGP message.
2) A LLE may be in one of the following states:

2-23
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

TLLI unassigned: In this state, the information cannot be transmitted, but SGSN
can receives UI and XID frames with the SAPIs of 1.
TLLI assigned/ADM: In this state, this link is assigned with a TLLI, and can be
used to transmit unacknowledged information.
ABM: this state shall be established by means of an ABM setup procedure. In this
state, both acknowledged and unacknowledged information can be transmitted.
2.3.5 SNDCP
I. Overview
Based on the indication of SM, SNDCP controls the setup and release of links. It
provides unified interface for various PDPs at the upper layer, enables the upper layer
to introduce different PDP types, and provides acknowledged/unacknowledged data
transmission for the upper layer.
The functions of SNDCP are:
Multiplexing of PDP activations.
Mapping of multiple network layer entities to appropriate LLC connection by
multiplexing N-PDU.
Acknowledged/unacknowledged user data transmission. In acknowledged mode,
N-PDU is buffered until acknowledgement from the peer end is received.
Individual management of the transmission sequence of each NSAPI.
Compression/decompression of user data.
Compression/decompression of user protocol control information.
Segmenting an N-PDU into multiple LL-PDUs, and assembling multiple
LL-PDUs in the same data packet into an N-PDU. These procedures have no
relation with the specific network layer protocol in use.
XID parameter negotiation between peer SNDCP entities of NSS and MS.
Cooperation with GMM, GTP and SM to realize inter-SGSN routeing area
update.
Cooperation with GMM, GTP and SM to realize 2.5G-to-3G handover.
Network layer protocol is assumed to be applicable to the services provided by
different subnets and data links. GPRS supports different network layer protocols, and
realizes the protocol transparency for the service users. It is possible to introduce new
network layer protocol without changing GPRS system. Therefore, the functions
related to transport network layer protocol data unit (N-PDU) should be used in a
transparent way by GPRS NEs. This is the basic function of SNDCP.
SNDCP can improve channel efficiency, which is realized by means of compression
technology.

2-24
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

SNDCP upper layer protocol entity consists of common network protocols. They use
the same SNDCP entity. When using LLC layer service to transmit data, SNDCP
entity multiplexes data from different sources. Network Service Access Point Identifier
(NSAPI) is a PDP context index. A PDP can use several PDP contexts and NSAPIs,
or several PDPs use different NSAPIs. Each activated NSAPI uses the service
provided by SAPI of the LLC layer. An SAPI can be associated to multiple NSAPIs.
Figure 2-18 illustrates the multiplexing procedures of different protocols.
Packet Data
Protocol
Packet Data
Protocol
Packet Data
Protocol
N-PDU
NSAPI
...
SNDCP
SN-PDU
SAPI
LLC
Figure 2-18 Multiplexing of different protocols
II. Protocol Function Model

SNDCP realizes the following functions:
Mapping of SN-DATA primitives to LL-DATA primitives.
Mapping of SN-UNITDATA primitives to LL-UNITDATA primitives.
Multiplexing of N-PDU from one or multiple network layer entities to the
corresponding LLC connection.
Setup, re-setup and release of acknowledged peer-to-peer LLC connection.
Supplementary of the LLC layer in maintaining data integrity by means of
buffering and retransmission of N-PDUs.
Individual management of the transmission sequence of each NSAPI.
Compression of the surplus protocol control information at the transmitting entity
(e.g. TCP/IP header), and decompression of the information at the receiving
entity.
Compression of the surplus user data at the transmitting entity, and
decompression of the data at the receiving entity. Data compression is
individually carried out for each SAPI, as well as for each PDP context. The
compression parameter is decided on the basis of negotiation between MS and
SGSN.

2-25
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Segmentation and reassembly. The output of the compression function is

segmented to the maximum length of LL-PDU. These procedures are
independent of the applied network layer protocol.
Figure 2-19 illustrates the transmission data flow passing SNDCP layer. The
implementation sequence of the functions is as follows:
Protocol control information compression
User data compression
Segmentation
of
compressed
information
SN-UNITDATAPDU
The sequence of receiving data flow is as follows:
Reassembly of N-PDU from SN-PDUs
User data decompression
Protocol control information decompression

2-26
into
SN-DATA
and
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

N-PDU
header
NETWORK
LAYER
data
SN-DATA.request
SN-UNITDATA.request
SNDCP
compare header to previous

difference
big
header
control
compressor
control
compressor
data
compressor
data
compressor
small
delta
#2
#1
M=0
Segmente
dN-PDU 2
M=1
M=0
segmentation
segmentation
#3
M=0
M=1
Segmented
N-PDU
#2
.
.
.
#1
M=1
Segmente
dN-PDU 1
M=1
M=1
SN-DATA PDU
SNDCP
SN-UNITDATA PDU
LL-DATA.request
LL-UNITDATA.request
LLC
LLC header
SN-DATA PDU
LLC header
SN-UNITDATA PDU
Figure 2-19 Functional data flow
2.4 Gn/Gp Interface

I. Definition
The Gn/Gp interface connects GPRS supporting nodes (GSNs) in the UMTS/GPRS
backbone network. The Gn interface connects GSNs within the same PLMN, while
the Gp interface connects GSNs in different PLMNs.

2-27
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. Functions
At the control plane, the Gn/Gp interface complies with the rules for the session
management, mobility management and location management related information
interaction between the GSNs in the backbone network when an MS is associated
with a GPRS network. At the user plane, the Gn/Gp interface provides some
conventions for the user packet data transmission between the GSNs.
III. Protocol Architecture
GTP
GTP
UDP
UDP
IP
IP
L2
L2
L1
L1
Gn
GSN
GSN
Figure 2-20 Gn/Gp interface protocol stack
The Gn/Gp interface complies with 3GPP TS 29.060. Figure 2-20 illustrates its
protocol stack. Each layer of protocol is described below:
GPRS Tunnelling Protocol (GTP): This protocol is used to transfer signaling or
user data between the GSNs in the backbone network. GTP is defined in 3GPP
TS 29.060.
User Datagram Protocol (UDP): This protocol is used to transfer user data
between the GSNs. UDP is defined in RFC 768.
Internet Protocol (IP): This protocol has two versions i.e., IPv4 and IPv6. The
former is defined in RFC 791 and the latter in RFC 1883. The present SGSN9810
supports IPv4.
Data link Layer/physical Layer protocol (L2/L1): The Gn/Gp interface supports
many connection modes e.g., STM-1 (155M optical fiber), STM-4 (622M optical
fiber), Gigabit Ethernet, 10M/100M Ethernet, etc. The operator may select a
connection mode based on the connected equipment.
The functions of the GTP control plane/GTP user plane are described as follows:
(Note: The GTP plane is divided into control plane and user plane in version V1 and
signaling plane and data plane in version V0).
GPRS Tunnelling Protocol-Control plane (GTP-C): This plane utilizes the tunnelling
protocol to transfer signaling associated with path management, tunnel management,
mobility management and location management between the GSNs in the backbone
network
so
as
to
perform
channel

2-28
maintenance,
context
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

establishment/modification/deletion and user information interaction in the backbone

network. Transfer reliability should be guaranteed for the signaling.
GPRS Tunnelling Protocol-User plane (GTP-U): This plane utilizes the tunnelling
protocol to transfer user data between the GSNs in the backbone network regardless
of the upper layer protocol. Moreover, it provides bi-directional and high-speed
transmission channels on a session base. Besides data packet, the GTP-U also
transfers auxiliary signaling e.g., data transmission error indication, handshake
message, supported extension header list, etc.
2.5 Ga Interface
I. Definition
The Ga interface connects a GPRS supporting node (GSN) to a charging gateway
functionality (CGF). The GTP' protocol operates on the Ga interface. It is based on
GTP with enhancements and additional message types. It is applied for the
SGSN-CG communication, GGSN-CG communication and CG-CG communication.
This chapter describes only the GTP' application for the SGSN-CG communication.
II. Functions
The Ga interface is used for the CG to collect original CDRs from SGSNs and
GGSNs.
III. Protocol Architecture

Figure 2-21 illustrates the GTP' protocol stack on the Ga interface.

2-29
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

S-CDRs, MCDRs, SSMO-CDRs

& S-SMT
CDRs
S-CDRs, MCDRs, SSMO-CDRs

& S-SMT
CDRs
GTP
GTP
UDP/TCP
UDP/TCP
IP
IP
L2
L2
L1
L1
SGSN
CGF
Figure 2-21 GTP' protocol stack
As a protocol the CGF uses to collect charging information from SGSNs, the GTP' can
use UDP or TCP as the path protocol (Huawei equipment can use both UDP and TCP
as the path protocol). The UDP Destination Port is usually 3386 (manually
configurable).
A GTP' message is composed of two parts i.e., GTP' header and GTP' information
content. Figure 2-22 illustrates the structure of a GTP' header.
bytes
Bits
8
Version
Message Type
3-4
Length
5-6
Sequence Number
5
PT(0)
SPARE("111")
1
"0"
Figure 2-22 GTP' header
A GTP' header includes the following fields:

PT: The Protocol Type flag, which is '0' if the message is GTP'.
Version: The GTP' protocol version. SGSN9810 supports the GTP' v2.
Message Type: It includes Echo Request, Echo Response, Version Not
Supported, Node Alive Request, Node Alive Response, Redirection Request,
Redirection Response, Data Record Transfer Request and Data Record
Transfer Response. The Echo Request and Echo Response messages are not
included if the path protocol is TCP.

2-30
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Length: The length of payload (number of octets after the GTP' header).
Sequence Number: The Sequence Number of the GTP' frame. The frames
transferring CDRs on the Ga interface are sequentially numbered and their
Sequence Number fields are correspondingly set. The Sequence Number fields
for other frames are always zero.
The GTP' information content follows the GTP' header, with the two kinds of formats,
TLV (Type, Length, Value) and TV (Type, Value). The Type (T) field indicates the
information type. The Length (L) field indicates the information length (of the Value
field only). The Value (V) field indicates the information data. TLV represents Type +
Length + Value and TV represents Type + Value. The T value determines the
encoding format.
The information type includes Address of Recommended Node, Requests
Responded, Data Record Packet, Charging Gateway Address , Sequence Numbers
of Canceled Packets, Sequence Numbers of Released Packets, Charging ID, Packet
Transfer Command.
2.6 Map Interface

MAP interfaces in this chapter refer to the interfaces that transmit MAP messages,
including Gr, Gd, Gf, Lg, etc. The protocol structures of these interfaces are the same.
Functions, protocol structure and signaling procedures of these interfaces are
covered here.
I. Definitions and Functions

Mobile Application Part (MAP) protocol defines how the information is exchanged for
MS roaming between the network entities in the mobile system. The network entities
here include MSC, VLR, SGSN, HLR, EIR, GMLC and SCP. In UMTS, B, C, D, E, G,
Gd, Gr, Lg and Gf interfaces can transmit MAP interfaces and they are collectively
referred to as MAP interfaces. See Figure 2-23 for definitions of these interfaces.

2-31
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

HLR
EIR
C/D
VLR
B
MSC
Gr
Gf
F
VLR
B
MSC
SGSN
Gc
Gn
GGSN
E
E
SMSC
Gd
Lg
CS
PS
GMLC
SMSC: Short Message Service Center

MSC: Mobile Switching Center
SGSN: Serving GPRS Support Node
GGSN: Gateway GPRS Support Node
GMLC: Gateway Mobile Location Center
HLR: Home Location Register

SCP: Service Control Point
VLR: Visitor Location Register
EIR: Equipment Identity Register
Figure 2-23 Map interfaces in UMTS
In the following, MAP interfaces in PS domain are introduced.

The Gr interface connects an SGSN and an HLR, used to exchange MS location
information and subscriber management message. The Gr interface implements the
following functions based on the MAP protocols in SS7 system.
- Authentication
- Routing Area Update (RAU)
- Subscriber data retrieval during session establishment
- SGSN recovery
Data are exchanged between the HLR and the SGSN to support call initiating and call
receiving of the MS in its service area. When Inter-SGSN RAU occurs to the MS, the
new SGSN will notify the HLR of the current location of the MS. And the HLR will send
to SGSN the subscriber data to support service processing. Meanwhile, the HLR will
notify the old SGSN to delete the information of the MS. Data exchange between HLR
and SGSN also occurs when the subscriber updates its subscription services or when
the administrator modifies subscription-related parameters.
The Gd interface connects an SGSN and an SMS-MSC, used to exchange short
message information between the SGSN and the SMS-MSC.
The Gf interface connects an SGSN and an EIR. When the SGSN is to check the
validity of International Mobile Equipment Identify (IMEI), it exchanges IMEI-related
information with the EIR through the Gf interface.
The Lg interface connects an SGSN and a GMLC, used to exchange the location
information between the SGSN and the GMLC.

2-32
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Additionally, with the coordination with GTP protocols, the SGSN also provides
GTP-MAP message conversion function. The SGSN provides the signaling interface
connected to HLR for the GGSN that is not installed with the SS7 system (i.e. Gc
interface). That is to say, when the GGSN does not provide SS7 MAP interface (i.e.
Gc interface), but has to initiate the PDP context activation, it will send requests via
the Gn interface to the SGSN that is able to initiate GTP-MAP conversion. The SGSN
will first convert the message obtained from the HLR via the Gr interface into GTP
message, and then return it to the GGSN.
In the SS7 system, MAP message is transmitted as the component of TCAP message
and it adopts ASN.1 format for coding. Its location in the link messages is illustrated in
Figure 2-24.
MTP
message
SCCP
message
TCAPmessage
MAP message
Figure 2-24 Location of MAP message in link messages
Types of MAP messages and the operation codes in TCAP components are in
one-to-one relationship. During message transfer, one message corresponds to one
Invoke ID that is the unique identifier of the message in the MAP session procedure.
Through different Invoke IDs, a component can be translated to its corresponding
MAP message. The conversion between MAP messages and TCAP messages is
accomplished by MAP Protocol status Machine (MAPPM).
Functions of MAP interfaces in PS domain are described below.
Signaling interworking between SGSN and HLR/SMS-MSC/GMLC is implemented
through MAP protocols. Among these protocols, TCAP, SCCP and MTP protocols are
the same as those bearing MAP signaling in CS network. The design of SGSN takes
the compatibility between 2.5G GPRS MAP version and the UMTS MAP version into
consideration to ensure the SGSN can interwork with the MAP of lower version.
MAP message processing modules strictly comply with 3GPP TS 29.002 and provide
all basic functions specified in 3GPP TS 29.002, including:
Version negotiation.
Mobility management for both 2G and 3G MSs.
Management of subscription data management, including GPRS subscription
data, LCS subscription data and CAMEL subscription data.
Security management, including authentication for both 2G and 3G MSs and
authentication failure report function.
Error recovery. The HLR notifies the SGSN for processing after resetting.

2-33
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Short message function, including Mobile Originated Short Message Service

(MO-SMS), Mobile Terminated Short Message Service (MT-SMS) and short
message alert.
Gc interface message forwarding function, including routing information fetch
and failure report, and MS presence notification.
MS location function, including location report and provision of location
information.
To achieve the above functions, SGSN MAP supports the following operations
specified in 3GPP TS 29.002, as illustrated in Table 2-3.
Table 2-3 Operations supported by SGSN MAP
Operation
code
Meaning
Description
updateGPRSLocation
This operation is used for the SGSN to initiate a location update procedure to
HLR when the MS is first registered in the network, or when inter-SGSN
location update occurs, or when the subscriber data has not been
acknowledged by the HLR.
0x03
cancelLocation
This operation is used for the HLR to delete the subscriber information in the
old SGSN, or for the location cancellation incurred by subscriber data
modification, or for the operator to delete the location information of the MS
during location update.
0x07
insertSubscriberData
This operation is used for the HLR to insert MS subscription data in the SGSN
during location update, and to insert the subscription data during subscriber
data modification.
0x08
deleteSubscriberData
This operation is used for the HLR to delete MS subscription data in the SGSN
when the operator is deleting the subscriber data.
0x09
sendParameters
Phase1 operation, used for the SGSN to get authentication set (authentication
triplet) from the HLR.
0x38
sendAuthenticationInfo
In Phase3, this operation is used for the SGSN to get authentication set
(authentication triplet or quintuplet) from the HLR. In phase2, this operation is
used to get authentication triplet from the HLR.
0x0F
authenticationFailureR
eport
This operation is used to report authentication failure to the HLR when the
authentication fails.
0x43
purgeMS
This operation is used for the SGSN to report to the HLR the SGSN subscriber
deletion operation.
0x25
reset
This operation is used to inform the SGSN of the HLR location update initiated
by a MS when the MS is in active state.
0x2c
mo-forwardSM
This operation is used for the MS to send short messages.
0x2e
mt-forwardSM
This operation is used for the MS to receive short messages.
0x42
readyForSM
This operation is used for notification when the short message subscriber gets
present or when the memory is available.
0x18
SendRoutingInfoForGp
rs
This operation is used for the GGSN to get routing information from the HLR
via the SGSN when the network is initiating a PDP context activation to the
0x17

2-34
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Operation
code
Meaning
Description
MS.
0x19
failureReport
This operation is used for the GGSN to report via the SGSN to the HLR the
PDP context activation failure at the network side when the network fails to
initiate a PDP context activation to the MS.
0x1a
noteMsPresentForGprs
This operation is used for the HLR to notify the HLR via the SGSN to reattempt
the PDP context activation procedure at the network side after the HLR
receives the MS Presence notification.
0x53
provideSubscriberLoca
tion
This operation is used for the GMLC to request for the location information of
the target MS from the SGSN.
0x56
subscriberLocationRep
ort
This operation is used for the SGSN to report the location information of the
target MS to the GMLC.
0x2b
checkIMEI
This operation is used for the SGSN to request EIR to check IMEI.
II. Protocol Structure

The location of MAP in SS7 protocol stack is illustrated in Figure 2-25. The MAP
interfaces such as Gd, Gr, Gf and Lg comply with this protocol stack structure.
MAP
Gd/Gr
/Gf/Lg
MAP
TCAP
TCAP
SCCP
SCCP
MTP3
MTP3
MTP2
MTP2
L1
L1
Figure 2-25 MAP interfaces in the protocol stack
Gc interface message forwarding is a SGSN specific function and its protocol stack is
illustrated in Figure 2-26.

2-35
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Interworking
MAP
MAP
TCAP
TCAP
SCCP
SCCP
IP
MTP3
MTP3
L2
L2
MTP2
MTP2
L1
L1
L1
L1
GTP-C
GTP-C
UDP
UDP
IP
Gn
GGSN
Gr
SGSN
HLR
Figure 2-26 SGSN protocol stack used to forward Gc interface signaling
Through the function of message forwarding, SGSN provides the signaling interface
connected to HLR for the GGSN that is not configured with the SS7 system (i.e. Gc
interface),
2.7 Gs Interface
I. Overview
The Gs interface connects a SGSN and a MSC/VLR. The BSSAP+ protocol defines a
set of signaling procedures on the Gs interface by which messages can be
exchanged between the SGSN and the MSC/VLR.
The Gs interface is an optional interface of the UMTS. Only Class A and Class B MSs
can use the Gs interface under the prerequisite that the network provides the Gs
interface and the MS is a combined MS. Some functions of the PS domain and of the
CS domain can be combined on the Gs interface to effectively save the signaling
resources on radio interfaces, thus to save radio resources. The SGSN and VLR store
the ISDN of each other for an associated MS. A table shall be established in the
SGSN, containing the corresponding relationship between the RAI and VLR. The
SGSN finds the corresponding VLR by the RAI before establishing an association.
The following functions can be implemented on the Gs interface.
Location update for non-GPRS services
Explicit detach from GPRS services
Explicit detach from non-GPRS services
Implicit detach from non-GPRS services
Paging for non-GPRS services
Non-GPRS alert
MS Information request
MM information notification
SGSN reset
VLR reset

2-36
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

HLR reset
The BSSAP+ protocol complies with 3GPP TS 29.018 and 3GPP TS 29.016.
II. Protocol Architecture

A standard Signaling System No 7 (SS7) interface serves as the Gs interface. The
SGSN acts as a signaling point in an SS7 network and is connected with the
MSC/VLR. The BSSAP+ uses the connectionless class 0 SCCP services.
Figure 2-27 illustrates the protocol stack on the Gs interface.
BSSAP+
BSSAP+
SCCP
SCCP
MTP3
MTP3
MTP2
MTP2
L1
L1
Gs
SGSN
MSC/VLR
Figure 2-27 Gs interface protocol stack
The BSSAP+ signaling format is simple. All messages are in the format of message
type + information elements. The TLV format is adopted for the information elements.
The BSSAP+ messages are short, generally equal to or shorter than 100 Bytes.
Figure 2-28 illustrates the position of a BSSAP+ message in the link messages.
MTP message SCCP message
BSSAP+ message
Figure 2-28 Position of BSSAP+ message in link messages
2.8 Ge Interface
I. Definition
The Ge interface connects the SGSN/gprsSSF to the gsmSCF.
II. Functions
The Ge interface defines the rules for all information interaction between the
SGSN/gprsSSF and gsmSCF, used to manage the signaling transmission between
the SGSN/gprsSSF and gsmSCF.

2-37
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

III. Protocol Structure
CAP
CAP
TCAP
TCAP
SCCP
SCCP
MTP3
MTP3
MTP2
MTP2
L1
L1
Ge
Figure 2-29 Ge interface protocol stack
The Ge interface follows 23.078 and 29.078 in 3GPP Specification and its protocol
stack is illustrated in Figure 2-29.
CAMEL Application Part (CAP) is responsible for the operation interaction between
the SGSN and the gsmSCF.

2-38
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Chapter 3 Mobility Management Functions................................................................................ 3-1
3.1 Definition of Mobility Management States ......................................................................... 3-1
3.1.1 Mobility Management States (GSM Only)............................................................... 3-1
3.1.2 Mobility Management States (UMTS Only)............................................................. 3-2
3.2 Mobility Management Timer Functions.............................................................................. 3-4
3.2.1 READY Timer Function (GSM Only)....................................................................... 3-4
3.2.2 Periodic RA Update Timer Function........................................................................ 3-4
3.2.3 Mobile Reachable Timer Function .......................................................................... 3-5
3.3 Interactions Between SGSN and MSC/VLR...................................................................... 3-5
3.3.1 Administration of the SGSN-MSC/VLR Association ............................................... 3-5
3.3.2 Combined RA/LA Updating ..................................................................................... 3-6
3.3.3 CS Paging (GSM Only) .......................................................................................... 3-6
3.3.4 CS Paging (UMTS Only) ......................................................................................... 3-7
3.3.5 Non-GPRS Alert ...................................................................................................... 3-7
3.3.6 MS Information Procedure ...................................................................................... 3-7
3.3.7 MM Information Procedure...................................................................................... 3-8
3.4 GPRS Attach Function....................................................................................................... 3-8
3.4.1 GSM GPRS Attach Procedure ................................................................................ 3-8
3.4.2 Combined GPRS/IMSI Attach Procedure ............................................................... 3-9
3.5 Detach Function............................................................................................................... 3-13
3.5.1 MS-Initiated Detach Procedure ............................................................................. 3-13
3.5.2 Network-Initiated Detach Procedure ..................................................................... 3-14
3.6 Purge Function................................................................................................................. 3-17
3.7 Security Function ............................................................................................................. 3-17
3.7.1 Authentication........................................................................................................ 3-18
3.7.2 User Identity Confidentiality .................................................................................. 3-19
3.7.3 User Data and GMM/SM Signalling Confidentiality .............................................. 3-20
3.7.4 Identity Check Procedures .................................................................................... 3-21
3.7.5 Data Integrity Procedure (UMTS Only) ................................................................. 3-21
3.8 Location Management Function ...................................................................................... 3-21
3.8.1 Location Management Procedures (GSM Only) ................................................... 3-22
3.8.2 Location Management Procedures (UMTS Only) ................................................ 3-30
3.8.3 Periodic RA/LA Update ......................................................................................... 3-46
3.9 Subscriber Management Function................................................................................... 3-47
3.9.1 Subscriber Management Procedures ................................................................... 3-47
3.10 Service Request Procedure s (UMTS Only).................................................................. 3-48
3.10.1 MS-Initiated Service Request Procedure............................................................ 3-48

i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
3.10.2 Network-Initiated Service Request Procedure .................................................... 3-50

3.11 UMTS-GSM Intersystem Change .................................................................................. 3-52
3.11.1 Intra SGSN Intersystem Change......................................................................... 3-52
3.11.2 Inter SGSN Intersystem Change......................................................................... 3-58
3.12 Classmark Handling....................................................................................................... 3-67
3.12.1 Radio Access Classmark .................................................................................... 3-67
3.12.2 MS Network Capability........................................................................................ 3-67

ii
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


3.1 Definition of Mobility Management States
3.1.1 Mobility Management States (GSM Only)
In GSM, the Mobility Management (MM) states for a GPRS subscriber are IDLE,
STANDBY and READY.
In IDLE state, the MS is not attached to the GPRS network. The MS is seen as not
reachable in this case.
In STANDBY state, the MS has been attached to the GPRS network. The MS and
SGSN have established the relatd MM contexts. Data reception and transmission are
not possible for the MS in this state, but it is possible to receive pages for the PS
services and CS services. After receiving a page successfully, the MS moves from the
STANDBY state to the READY state. In STANDBY state, the MS informs the SGSN of
the routeing area update (RAU), but it does not reports the cell update. Therefore, the
SGSN does not contain the accurate cell information of the MS in this case. The MS
may initiate the GPRS detach procedure to move to the IDLE state.
In READY state, the MS can send and receive data units, and the SGSN contains the
accurate cell information of the MS. When it does not perform data reception or
transmission for so long time in this state that the READY Timer expires, the MS
moves to the STANDBY state. The MS can perform GPRS cell selection and
reselection.

3-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IDLE
IDLE
GPRS Attach
GPRS Detach
Implicit Detach
or
Cancel Location
READY
READY timer expiry

or
Force to STANDBY
GPRS Detach
or
Cancel Location
GPRS Attach
READY
READY timer expiry

or
Force to STANDBY
or
Abnormal RLC condition
PDU transmission
PDU reception
STANDBY
STANDBY
MM State Model of MS
MM State Model of SGSN
Figure 3-1 GSM MM state model
3.1.2 Mobility Management States (UMTS Only)

In UMTS, the PMM states for a GPRS subscriber are PMM-DETACHED, PMM-IDLE
and PMM-CONNECTED. The state information held at the MS and the SGSN
performs MM context management through mobility management.
As shown in Figure 3-2, the PMM states are irrelated to the session management SM
states. In both the PMM-CONNECTED and the PMM-IDLE states, the session
management may or may not have ativated a PDP context. State transitions are given
below:
I. Moving from PMM-DETACHED to PMM-CONNECTED

GPRS Attach. The MM context shall move from the PMM-DETACHED state to the
PMM-CONNECTED state when a PS signalling connection is established between
the MS and the 3G-SGSN for performing a GPRS attach.

3-2
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. Moving from PMM-CONNECTED to PMM-IDLE

PS Signalling Connection Release. The MM context shall move from the
PMM-CONNECTED state to the PMM-IDLE state when the PS signalling connection
is released.
III. Moving from PMM-IDLE to PMM-CONNECTED

PS Signalling Connection Establishment. The MM context shall move from the
PMM-IDLE state to the PMM-CONNECTED state when the PS signalling connection
is established between the MS and the 3G-SGSN.
IV. Moving from PMM-CONNECTED to PMM-DETACHED

GPRS Detach. The MM context shall move from the PMM-CONNECTED state to the
PMM-DETACHED state when the PS signalling connection is released between the
MS and the 3G-SGSN after the MS has performed a GPRS detach or after the
network-initiated GPRS detach is performed.
RAU Reject. The MM context shall move from the PMM-CONNECTED state to the
PMM-DETACHED state when the PS signalling connection is released between the
MS and the 3G-SGSN after a RAU is rejected by the 3G-SGSN.
GPRS Attach Reject. The MM context shall move from the PMM-CONNECTED state
to the PMM-DETACHED state when the PS signalling connection is released
between the MS and the 3G-SGSN after a GPRS attach is rejected by the 3G-SGSN.
V. Moving from PMM-IDLE to PMM-DETACHED

Implicit GPRS Detach. The MM context shall move from the PMM-IDLE state to the
PMM-DETACHED state, e.g., in the case of removal of the battery, the USIM, or the
GSIM from the TE.
VI. Moving from PMM-CONNECTED to PMM-CONNECTED

SRNS Relocation. The MM context keeps in the PMM-CONNECTED state when the
PS signalling connection is kept after a SRNS relocation is performed.

3-3
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

PMMDETACHED
PMMDETACHED
Detach,
PS Attach Reject,
RAUReject
PS Detach
PS Attach
PS Signalling
Connection Release
PMM-IDLE
SM-ACTIVE or
INACTIVE
PS Signalling
Connection Establish
PMMCONNECTED
SM-ACTIVE or
INACTIVE
PS Detach
PS Attach
PS Signalling
Connection Release
PMM-IDLE
Detach,
PS Attach Reject,
RAUReject
PMMCONNECTED
SM-ACTIVE or
SM-ACTIVE or
PS Signalling
INACTIVE
INACTIVE
Connection Establish
Serving RNC
relocation
MS MMStates
3G-SGSNMMStates
Figure 3-2 UMTS PMM state model
Note:
In case of an error, the PMM state of the MS and the 3G-SGSN may lose synchronisation. This situation
may be recovered by a successful RAU.
3.2 Mobility Management Timer Functions

3.2.1 READY Timer Function (GSM Only)
The READY Timer function maintains the READY timer in the MS and SGSN. The
READY timer controls the time an MS reamains in READY state in the MS and the
SGSN. The READY timer shall be reset and begin running in the MS when an LLC
PDU is transmitted, and in the SGSN when an LLC PDU is correctly received. When
the READY timer expires, the MS and SGSN MM contexts shall return to STANDBY
state.
The UMTS system does not contain the READY timer.
3.2.2 Periodic RA Update Timer Function

The Periodic RA Update Timer function monitors the periodic RA update procedure in
the MS. The length of the periodic RA update timer is sent in the Routeing Area

3-4
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Update Accept or Attach Accept message. Upon expiry of the periodic RA update
timer, the MS shall start a periodic routeing area update procedure.
3.2.3 Mobile Reachable Timer Function

The Mobile Reachable Timer function monitors the periodic RA update procedure in
the SGSN. The mobile reachable timer shall be slightly longer than the periodic RA
update timer used by an MS.
The mobile reachable timer shall stop when the READY state or PMM-CONNECTED
state is entered. The mobile reachable timer is reset and started when the state
returns to STANDBY or PMM-IDLE.
3.3 Interactions Between SGSN and MSC/VLR

3.3.1 Administration of the SGSN-MSC/VLR Association
The interactions between SGSN and MSC/VLR are performed across the optional Gs
interface. If the Gs interface is present, the SGSN stores the MSC/VLR number and
the MSC/VLR stores the SGSN number, and the association is created. The
association is updated when an IMSI and GPRS-attached MS changes SGSN or
MSC/VLR.
Besides requiring the support of the network operation mode, the interactions
between SGSN and MSC/VLR are also associated with the operation mode of the
MS.
The GSM GPRS MS operation modes are defined as follows:
Class-A mode of operation: The MS is attached to both GPRS and other GSM
services, and the MS supports simultaenous operation of GPRS and other GSM
services.
Class-B mode of operation: The MS is attached to both GPRS and other GSM
services, but the MS can only operate one set of services at a time.
Class-C mode of operation: The MS is exclusively attached to GPRS services.
The UMTS MS operation modes are defined as follows:
CS/PS mode of operation: The MS is attached to both the PS domain and CS
domain, and the MS is capable of simultaneously operating PS services and CS
services.
PS mode of operation: The MS is attached to the PS domain only and may only
operate services of the PS domain.
CS mode of operation: The MS is attached to the CS domain only and may only
operate services of the CS domain.

3-5
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.3.2 Combined RA/LA Updating

The combined RA/LA update procedure is started at the following occasions:
Combined GPRS/IMSI attach
GPRS attach when the MS is already IMSI-attached
IMSI attach when the MS is already GPRS-attached
For details, refer to Section 3.4 GPRS Attach Function and Section 3.8 Location
Management Function.
3.3.3 CS Paging (GSM Only)

When an MS is both IMSI and GPRS-attached in a network that operates in mode I,
then the MSC/VLR executes paging for circuit-switched services via the SGSN. If the
MS is in STANDBY state, then it is paged in the routeing area and in the null routeing
area (Cells that do not support packet-domain services within an LA are grouped into
a null RA). If the MS is in READY state, then it is paged in the cell. The paging
procedure is supervised in the MSC by a paging timer. The SGSN converts the MSC
paging message into an SGSN paging message and sends it to the MS. Upon receipt
of the paging message, the MS makes a paging response directly to the MSC.
Three network operation modes are defined for GSM, and they are described in Table
3-1.
Table 3-1 Network operation modes for GSM
Mode
II
GPRS paging
channel
Circuit paging channel

Packet paging channel
Packet paging
channel
CCCH paging channel
CCCH paging
channel
Packet data channel
CCCH paging channel
CCCH paging
channel
CCCH paging channel
Packet paging
channel
CCCH paging channel
CCCH paging
channel
III
Paging co-ordination
Yes, the SGSN coordinates with the
MSC/VLR to execute paging. The Gs
interface is present in this case. The MS
needs only to monitor one paging channel. It
receives CS paging messages on the packet
data channel when it has been assigned a
packet data channel.
No, the SGSN does not coordinate with the
MSC/VLR to execute paging. The MS needs
only to monitor the CCCH paging channel in
this case. CS paging continues on the CCCH
paging channel even if the MS has been
assigned a packet data channel.
No, the SGSN does not coordinate with the
MSC/VLR to execute paging. An MS that
wants to receive pages for both
circuit-switched and packet-switched services
shall monitor both the CCCH paging channel
and the packet paging channel if the packet
paging channel is allocated in the cell.

3-6
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.3.4 CS Paging (UMTS Only)

When an MS is both IMSI and GPRS-attached in a network that operates in mode I,
then the MSC/VLR executes paging for circuit-switched services via the SGSN. The
paging procedure is supervised in the MSC by a paging timer.
The network operation mode is used to indicate whether the Gs interface is installed
or not. When the Gs interface is present, the MSC/VLR executes paging via the
SGSN. Upon receipt of the paging message, the MS makes a paging response
directly to the MSC/VLR.
Network operation modes for UMTS are described in Table 3-2.
Table 3-2 Network operation modes for UMTS
Mode
Network configuration
Combined procedure by MS
Gs interface is present
Yes
II
Gs interface is not present
No
The network operation mode shall be indicated as system information to the MSs. For
proper operation, the mode of operation should be the same in each cell of a routeing
area.
Based on the mode of operation provided by the network, the MS can then choose,
according to its capabilities, whether it can attach to CS domain services, to PS
domain services, or to both. Furthermore, based on the mode of operation, the MS
can choose whether it can initiate combine update procedures or separate update
procedures, according to its capabilities. Network operation modes I and II for UMTS
correspond to modes I and II, respectively, for GSM. Mode III applies to GSM and not
to UMTS.
3.3.5 Non-GPRS Alert

If the MSC/VLR requests an SGSN to report activity from a specific MS, the SGSN
shall set Non-GPRS Alert Flag (NGAF) for the MS. When the next activity from that
MS is detected, the SGSN shall inform the MSC/VLR and clear NGAF.
3.3.6 MS Information Procedure

If the MSC/VLR requests the identity information and location information of an MS
that is known by the SGSN, the SGSN shall return this information across the Gs
interface. If the information requested is not known by the SGSN but is known by the

3-7
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS, then the MSC/VLR sends an MS information request to the MS via the SGSN and
then gets the information.
3.3.7 MM Information Procedure

The MSC/VLR may send MM information to the SGSN, and then the SGSN may
forward the MM information to the MS.
3.4 GPRS Attach Function

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 GSM radio access network, it shall
perform a GSM GPRS Attach procedure. If the MS is connected via a UMTS radio
access network, it shall perform a UMTS GPRS Attach procedure.
In whatever GPRS 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, then the MS shall provide its IMSI. The MS performs a
GPRS Attach procedure with the P-TMSI when it provides the P-TMSI, and with the
IMSI when it provides its IMSI.
3.4.1 GSM GPRS Attach Procedure

A GPRS-attached MS makes IMSI attach, i.e., attach to CS domain services, via the
SGSN with the combined RA/LA update procedure if the network operation mode is I.
In network operation modes II and III, or if the MS is not GPRS-attached, then the MS
makes IMSI attach across the A interface. An IMSI-attached MS in class-A mode of
operation engaged in a CS connection shall use the (non-combined) GPRS Attach
procedure when it performs a GPRS attach.
At the RLC/MAC layer, the MS shall identify itself with a Local or Foreign TLLI if the
MS is already GPRS-attached and is performing an IMSI attach. Otherwise, the MS
shall identify itself with a Foreign TLLI, or a Random TLLI if a valid P-TMSI is not
available. The Foreign or Random TLLI is used as an identifier during the attach
procedure until a new P-TMSI is allocated.
An IMSI-attached MS that can only operate in class-C mode of operation shall follow
the normal IMSI detach procedure before it makes a GPRS attach. A GPRS-attached
MS in class-C mode of operation shall always perform a GPRS detach before it
makes an IMSI attach.

3-8
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

If the network operates in mode I, then an MS that is both GPRS-attached and

IMSI-attached shall perform the Combined RA/LA Update procedures.
If the network operates in mode II or III, then a GPRS-attached MS that has the
capability to be simultaneously GPRS-attached and IMSI-attached shall perform the
(non-combined) Routeing Area Update procedures.
3.4.2 Combined GPRS/IMSI Attach Procedure

The Combined GPRS/IMSI Attach procedure is illustrated in Figure 3-3.

3-9
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
UTRAN
new SGSN
old SGSN
GGSN
EIR
new
MSC/VLR
HLR
old
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 Ack
7g. Update Location Ack
7h. Location Update Accept
C1
8. Attach Accept
9. Attach Complete
10. TMSI Reallocation Complete
Figure 3-3 Combined GPRS/IMSI attach procedure
Each step is explained in the following list:

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

3-10
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS has a valid P-TMSI, then P-TMSI and the old RAI associated with P-TMSI
shall be included. 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. 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. DRX Parameters
indicate whether the MS uses discontinuous reception or not. If the MS uses
discontinuous reception, then DRX Parameters also indicate when the MS is in a
non-sleep mode able to receive paging requests. Follow on request shall be set
by the MS 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.
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)
If no MM context for the MS exists anywhere in the network, then authentication

is mandatory. If P-TMSI allocation is going to be done, and if ciphering is
supported by the network, ciphering mode shall be set.
5)
The equipment checking functions are optional in Identity Check procedures.

Equipment checking is not supported here.
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 Procedrue.
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.

3-11
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

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.
g) If Attach Type in step 1) indicated GPRS Attach while already IMSI attached, or
combined GPRS/IMSI attach, 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.
h) 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.
i) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR)
to the HLR.
j) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old
VLR.
k) The old VLR acknowledges with Cancel Location Ack (IMSI).
l) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, GSM
subscriber data) to the new VLR.
m) The VLR acknowledges with Insert Subscriber Data Ack (IMSI).
n) After finishing the inter-MSC location update procedures, the HLR responds with
Update Location Ack (IMSI) to the new VLR.
o) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN.
p) 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.
3-12
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

7)
If P-TMSI or VLR TMSI was changed, the MS acknowledges the received

TMSI(s) by returning an Attach Complete message to the SGSN.
8)
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.
C1) CAMEL-GPRS-Attach-Request
3.5 Detach Function

Different from the GPRS Attach procedure that can only be initiated by an MS, the
Detach procedure can be initiated by an MS or by the network. In the network-initiated
Detach procedure, Detach Type indicates if the MS is requested to make a new attach
and PDP context activation for the previously activated PDP contexts. If so, the attach
procedure shall be initiated when the detach procedure is completed. The three
different types of Detach are GPRS Detach, IMSI Detach and GPRS/IMSI Detach.
The network equipment able to initiate the Detach procedure can be an SGSN or an
HLR. The Detach procedure is usually used for operator-determined purposes if it is
initiated by an HLR.
3.5.1 MS-Initiated Detach Procedure

The MS-Initiated Detach Procedure when initiated by the MS is illustrated in Figure
3-4.
MS
BSS/UTRAN
SGSN
GGSN
MSC/VLR
1. Detach Request
2. Delete PDP Context Request
2. Delete PDP Context Response
C1
3. IMSI Detach Indication
4. GPRS Detach Indication
5. Detach Accept
C2
6. PS Signalling Connection Release
Figure 3-4 MS-initiated detach procedure

3-13
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

1)
The MS detaches by sending Detach Request (Detach Type, P-TMSI, P-TMSI

Signature, Switch Off) to the SGSN. Detach Type indicates which type of detach
that is to be performed, i.e., GPRS Detach only, IMSI Detach only or combined
GPRS and IMSI Detach. Switch Off indicates whether the detach is due to a
switch off situation or not. The Detach Request message includes P-TMSI and
P-TMSI Signature. P-TMSI Signature is used to check the validity of the Detach
Request message. If P-TMSI Signature is not valid or is not included, then
authentication procedure should be performed.
2)
If GPRS detach, the active PDP contexts in the GGSNs regarding this particular
MS are deactivated by the SGSN sending Delete PDP Context Request (TEID)
to the GGSNs. The GGSNs acknowledge with Delete PDP Context Response
(TEID).
3)
If IMSI detach, the SGSN sends an IMSI Detach Indication (IMSI) message to
the VLR.
4)
If the MS wants to remain IMSI-attached and is doing a GPRS detach, the SGSN
sends a GPRS Detach Indication (IMSI) message to the VLR. The VLR removes
the association with the SGSN and handles paging and location update without
going via the SGSN.
5)
If Switch Off indicates that the detach is not due to a switch off situation, the
SGSN sends a Detach Accept to the MS.
6)
If the MS was GPRS detached, then the 3G-SGSN releases the PS signalling
connection.
C1) CAMEL-Deactivate-PDP-Context. This procedure is performed every time when

a PDP context is updated and shall be performed for many times.
C2) CAMEL-GPRS-Detach.
3.5.2 Network-Initiated Detach Procedure

The network-initiated detach includes two types of detach: SGSN-initiated detach and
HLR-initiated detach that are described as follows:
I. SGSN-initiated detach procedure

The SGSN-initiated detach procedure when initiated by the SGSN is illustrated in
Figure 3-5.

3-14
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
BSS/UTRAN
SGSN
1. Detach Request
GGSN
MSC/VLR

4. Detach Accept
C1
C2
Figure 3-5 SGSN-initiated detach procedure

1)
The SGSN informs the MS that it has been detached by sending Detach Request
(Detach Type) to the MS. Detach Type indicates if the MS is requested to make a
new attach and PDP context activation for the previously activated PDP contexts.
If so, the attach procedure shall be initiated when the detach procedure is
completed.
2)
The active PDP contexts in the GGSNs regarding this particular MS are
deactivated by the SGSN sending Delete PDP Context Request (TEID)
messages to the GGSNs. The GGSNs acknowledge with Delete PDP Context
Response (TEID) messages.
3)
If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach
Indication (IMSI) message to the VLR. The VLR removes the association with
the SGSN and handles paging and location update without going via the SGSN.
4)
The MS sends a Detach Accept message to the SGSN any time after step 1).
5)
After receiving the Detach Accept message, if Detach Type did not request the
MS to make a new attach, then the 3G-SGSN releases the PS signalling
connection.

C2) CAMEL-GPRS-Detach initiated by the SGSN.
II. HLR-initiated detach procedure

The HLR-initiated detach procedure when initiated by the HLR is illustrated in Figure
3-6.

3-15
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
BSS/UTRAN
SGSN
GGSN
HLR
MSC/VLR
1. Cancel Location
2. Detach Request

C1
5. Detach Accept
C2
6. Cancel Location Ack
Figure 3-6 HLR-initiated detach procedure

1)
If the HLR wants to request the immediate deletion of a subscriber's MM and

PDP contexts from the SGSN, the HLR shall send a Cancel Location (IMSI,
Cancellation Type) message to the SGSN with Cancellation Type set to
Subscription Withdrawn.
2)
The SGSN informs the MS that it has been detached by sending Detach Request
(Detach Type) to the MS. Detach Type shall indicate that the MS is not requested
to make a new attach and PDP context activation.
3)
The active PDP contexts in the GGSNs regarding this particular MS are deleted
by the SGSN sending Delete PDP Context Request (TEID) messages to the
GGSNs. The GGSNs acknowledge with Delete PDP Context Response (TEID)
messages.
4)
If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach
Indication (IMSI) message to the VLR. The VLR removes the association with
the SGSN and handles paging and location update without going via the SGSN.
5)
6)
The MS sends a Detach Accept message to the SGSN any time after step 1).
The SGSN shall confirm the deletion of the MM and PDP contexts with a Cancel
Location Ack (IMSI) message.
7)
After receiving the Detach Accept message, if Detach Type did not request the
MS to make a new attach, then the 3G-SGSN releases the PS signalling
connection.

C2) CAMEL-GPRS-Detach initiated by the HLR.

3-16
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.6 Purge Function

The Purge function allows an SGSN to inform the HLR that it has deleted the MM and
PDP contexts of a detached MS. The SGSN may, as an implementation option, delete
the MM and PDP contexts after the implicit or explicit detach of the MS. Alternatively,
the SGSN may keep for some time the MM and PDP contexts and the authentication
triplets of the detached MS, so that the contexts can be reused at a later GPRS attach
without accessing the HLR.
When the SGSN deletes the MM and PDP contexts, it shall initiate the Purge
procedure as illustrated in Figure 3-7.
SGSN
HLR
1. Purge MS
2. Purge MS Ack
Figure 3-7 Purge procedure

1)
After deleting the MM and PDP contexts of a detached MS, the SGSN sends a
Purge MS (IMSI) message to the HLR.
2)
The HLR sets the MS Purged for GPRS flag and acknowledges with a Purge MS
Ack message.
3.7 Security Function

The Security function:
Guards against unauthorised packet-domain service usage (authentication of
the MS by the network and service request validation).
Provides user identity confidentiality (temporary identification and ciphering).
Provides user data and signalling confidentiality (ciphering).
Provides, for UMTS radio access only, data integrity and origin authentication of
signalling data (integrity protection).
Provides, for UMTS subscriber (USIM) only, authentication of the network by the
MS.
Security-related network functions are described in GSM 03.20 and in 3G TS 33.102.

3-17
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.7.1 Authentication
"GSM authentication" is executed from the SGSN and implies authentication of the
MS by the network and establishment of a new GSM ciphering key (Kc) agreement
between the SGSN and the MS.
"UMTS authentication" is executed from the SGSN and implies mutual authentication,
i.e., authentication of the MS by the network and authentication of the network by the
MS. It also implies establishment of a new UMTS ciphering key (CK) and integrity key
(IK) agreement between the SGSN and the MS.
Compared with the GSM authentication procedure, the UMTS authentication
procedure provides two more functions, i.e., integrity check and authentication of the
network by the MS. These functions further enhance the UMTS security.
The Authentication procedure is illustrated in Figure 3-8.
MS
BSS/UTRAN
SGSN
HLR
1. Send Authentication Info

1. Send Authentication Info Ack
2. Authentication and Ciphering Request
2. Authentication and Ciphering Response
Figure 3-8 Authentication procedure
Each step is explained in the following list, with the Authentication of UMTS
Subscriber procedure as an example:
1)
If the SGSN does not have previously stored UMTS Authentication Vectors
(quintuplets), a Send Authentication Info (IMSI) message is sent to the HLR.
Upon receipt of this message for a UMTS user, the HLR/AuC responds with a
Send Authentication Info Ack message including an ordered array of quintuplets
to the SGSN. Each quintuplet contains RAND, XRES, AUTN, CK, and IK. The
generation of quintuplets in HLR/AuC for a UMTS user is performed as specified
in 3G TS 33.102.
2)
At authentication of a UMTS subscriber, the SGSN selects the next in-order

quintuplet and transmits the RAND and AUTN, that belong to this quintuplet, to
the MS in the Authentication and Ciphering Request (RAND, AUTN, CKSN)
message. The SGSN also selects a ciphering key sequence number (CKSN)
and includes this in the message.

3-18
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3)
At reception of this message, the USIM in the MS verifies AUTN and, if accepted,
the USIM computes the signature of RAND, RES, in accordance with 3G TS
33.102. If the USIM considers the authentication being successful the MS
returns an Authentication and Ciphering Response (RES) message to the
SGSN.
If the USIM considers the authentication being unsuccessful, e.g., in case of an

authentication synchronisation failure, the MS returns the Authentication and
Ciphering Failure message to the SGSN. The typical causes of the authentication
failure include two types:
MAC Failure. If the MS detects MAC error in the AUTN in the Authentication and
Ciphering Request message at authentication of the network, it returns an
Authentication and Ciphering Failure message to the SGSN with cause "MAC Failure".
The SGSN determines, according to the identity provided by the MS, if an
Identification procedure is to be initiated. If the currently-provided identity is TMSI or
P-TMSI, the Identification procedure is initiated and the MS is requested to provide its
IMSI. Then the SGSN initiates another Authentication prcedure.
Synch Failure. If the MS detects SQN error in the AUTN in the Authentication and
Ciphering Request message at authentication of the network, it returns an
Authentication and Ciphering Failure message to the SGSN with cause "Synch
Failure". The SGSN deletes all Authentication Vectors (quintuplets) and initiates a
Synchronsation procedure to the HLR, requesting the HLR to reinsert Authentication
Vectors (quintuplets). Then the SGSN initiates another Authentication procedure.
4)
Upon reception of the Authentication and Ciphering Response message, the

SGSN compares the XRES in the message with the XRES in Authentication
Vectors (quintuplets) that are stored in the SGSN database and judges whether
the authentication is successful. If successful, the SGSN continues to execute
the following procedures normally. If unsuccessful, the SGSN sends an
Authentication and Ciphering Reject message, informing the MS of the
authentication failure. Then the SGSN terminates the current procedure and
releases the resource allocated to the MS.
After successful authentication, the MS stores the Ciphering Key (CK) and the
Integrity Key (IK) in the USIM.
3.7.2 User Identity Confidentiality

Usually the network does not directly use an IMSI but uses a P-TMSI allocated by the
SGSN as a temparory MS identity between the MS and the SGSN.
A Temporary Logical Link Identity (TLLI) identifies a GSM user. The relationship
between TLLI and IMSI is known only in the MS and in the SGSN. TLLI is derived from
the P-TMSI allocated by the SGSN or built by the MS.

3-19
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

A Radio Network Temporary Identity (RNTI) identifies a UMTS user between the MS
and the UTRAN. The relationship between RNTI and IMSI is known only in the MS
and in the UTRAN. A P-TMSI identifies a UMTS user between the MS and the SGSN.
The relationship between P-TMSI and IMSI is known only in the MS and in the SGSN.
The reallocation procedure guarantees the randomness of the temporary identity.
This avoids the leakage of the user identity.
The P-TMSI Reallocation procedure is illustrated in Figure 3-9.
MS
BSS/UTRAN
SGSN
1. P-TMSI Reallocation Command

2. P-TMSI Reallocation Complete
Figure 3-9 P-TMSI reallocation procedure

1)
The SGSN sends a P-TMSI Reallocation Command (new P-TMSI, P-TMSI

Signature, RAI) message to the MS. P-TMSI Signature is an optional parameter
that the MS, if received, shall return to the SGSN in the next Attach and Routeing
Area Update procedures.
2)
The MS returns a P-TMSI Reallocation Complete message to the SGSN.
3.7.3 User Data and GMM/SM Signalling Confidentiality

The scope of ciphering is illustrated in Figure 3-10.
MS
BSS/UTRAN
SGSN
Scope of GPRS ciphering
Scope of UMTS ciphering
Figure 3-10 Scope of ciphering
As illustrated in Figure 3-10, the scope of UMTS ciphering is narrower than that the
scope of GPRS ciphering, and it is only from the ciphering function in the UTRAN to
the ciphering function in the MS.

3-20
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.7.4 Identity Check Procedures

The Identity Check procedure is illustrated in Figure 3-11.
MS
BSS/UTRAN
SGSN
EIR
1. Identity Request
1. Identity Response
2. Check IMEI
2. Check IMEI Ack
Figure 3-11 Identity check procedure

1)
The SGSN sends Identity Request (Identity Type) to the MS. The MS responds
with Identity Response (Mobile Identity). In UMTS, the MS may choose to send
its IMSI encrypted (FFS).
2)
If the SGSN decides to check the IMEI against the EIR, it sends Check IMEI
(IMEI) to EIR. The EIR responds with Check IMEI Ack (IMEI). This is an optional
procedure.
3.7.5 Data Integrity Procedure (UMTS Only)

The Data Integrity procedure is performed between the MS and the UTRAN. It is
applicable only to radio signalling. The UMTS integrity check is made with the UMTS
Integrity Algorithm (UIA). The UMTS Integrity Key (IK) is an input to the algorithm. The
start of the data integrity procedure is controlled by the security mode procedure.
3.8 Location Management Function

The Location Management function:
provides mechanisms for cell and PLMN selection;
provides a mechanism for the network to know the Routeing Area for MSs in
STANDBY, PMM-IDLE, READY, and PMM-CONNECTED states;
provides a mechanism for the 2G-SGSN to know the cell identity for MSs in
READY state;
provides a mechanism for the UTRAN to know the URA identity or cell identity for
MSs in PMM-CONNECTED state;
provides a mechanism for the UTRAN to indicate to an MS in RRC Connected
mode when a Routeing Area Update procedure shall be performed by providing
the RAI; and
3-21
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

provides a mechanism for the network to know the address of the serving RNC
handling an MS in PMM-CONNECTED state. This mechanism is the serving
RNC relocation procedure.
The SGSN may not know the Routeing Area where the UMTS MS is physically
located for an MS is in RRC Connected mode. An MS in PMM-CONNECTED state is
necessarily in RRC Connected mode. An MS in PMM-IDLE state is in RRC
Connected mode only if the MS is in CS MM-CONNECTED state.
In UMTS, the tracking of the location of the MS is on three levels (cell, URA, or RA),
see 3G TS 23.121. In GSM, the tracking of the location of the MS is on two levels (cell
or RA).
In GSM:
Cell update
Routeing area update
In UMTS:
Routeing area update
SRNC relocation
3.8.1 Location Management Procedures (GSM Only)

The MS detects that a new cell has been entered by comparing the cell's identity with
the cell identity stored in the MS's MM context. The MS detects that a new RA has
been entered by periodically comparing the RAI stored in its MM context with that
received from the new cell. The MS shall consider hysteresis in signal strength
measurements.
When the MS camps on a new cell, possibly in a new RA, this indicates one of three
possible scenarios:
a cell update is required;
a routeing area update is required; or
a combined routeing area and location area update is required.
In all three scenarios the MS stores the cell identity in its MM context.
If the MS enters a new PLMN, the MS shall either perform a routeing area update, or
enter IDLE state. In network mode of operation II and III, whenever an MS determines
that it shall perform both an LA update and an RA update, the MS shall perform the LA
update first.
I. Cell update procedure

A cell update takes place when the MS enters a new cell inside the current RA and the
MS is in READY state. If the RA has changed, a routeing area update is executed
instead of a cell update. If the network and the MS support the Cell Notification then
3-22
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

the MS shall use the LLC NULL frame, containing the MS's identity, in order to perform
a cell update. The support of Cell Notification is mandatory for MS and network but the
network as well as the MS has to support the Cell Update Procedure, not using the
LLC NULL frame, for backward compatibility reasons.
II. Routeing area update procedure

A routeing area update takes place when a GPRS-attached MS detects that it has
entered a new RA, when the periodic RA update timer has expired, or, for GSM, when
a suspended MS is not resumed by the BSS. If the new RA belongs to an SGSN
different from the SGSN for the old RA, the RA update is an inter SGSN routeing area
update. Otherwise, the RA update is an intra SGSN routeing area update. A periodic
RA update is always an intra SGSN routeing area update.
III. Intra SGSN routeing area update

In an Intra SGSN Routeing Area Update procedure, the GGSN and the HLR are not
included. The Intra SGSN Routeing Area Update procedure is illustrated in Figure
3-12.
MS
BSS
SGSN
1. Routeing Area Update Request

2. Security Functions
3. Routeing Area Update Accept
C1
4. Routeing Area Update Complete
Figure 3-12 Intra SGSN routeing area update procedure

1)
The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSI
Signature, Update Type) to the SGSN. Update Type shall indicate RA update or
periodic RA update. The BSS shall add the Cell Global Identity including the
RAC and LAC of the cell where the message was received before passing the
message to the SGSN.
2)
Security functions may be executed.
3)
If all checks are successful then the SGSN updates the MM context for the MS. A
new P-TMSI may be allocated. A Routeing Area Update Accept (P-TMSI,
P-TMSI Signature) is returned to the MS.
4)
If P-TMSI was reallocated, the MS acknowledges the new P-TMSI by returning a

Routeing Area Update Complete message to the SGSN. If the routeing area
3-23
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

update procedure fails a maximum allowable number of times, or if the SGSN

returns a Routeing Area Update Reject (Cause) message, the MS shall enter
IDLE state.
C1) CAMEL-GPRS-Routeing-Area-Update and CAMEL-Update-PDP-Context. This
procedure is performed every time when a PDP context is updated and shall be
performed for many times.
IV. Inter SGSN routeing area update

The Inter SGSN Routeing Area Update procedure is illustrated in Figure 3-13.
MS
BSS
new SGSN
old SGSN
GGSN

2. SGSN Context Request
2. SGSN Context Response
C1
4. SGSN Context Acknowledge
C2
5. Forward Packets
6. Update PDP Context Request
6. Update PDP Context Response
7. Update Location
8. Cancel Location
9. Insert Subscriber Data
9. Insert Subscriber Data Ack
10. Update Location Ack
C3
C4
Figure 3-13 Inter SGSN routeing area update procedure

3-24
HLR
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


1)
The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature,
Update Type) to the new SGSN.
2)
The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI
Signature, New SGSN Address) to the old SGSN to get the MM and PDP
contexts for the MS. The old SGSN 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. This should initiate the security functions in the new SGSN. If the
security functions authenticate the MS correctly, the new SGSN shall send an
SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address)
message to the old SGSN. The second SGSN Context Request message
includes "MS Validated" instead of "old P-TMSI Signature". If the old P-TMSI
Signature was valid or if the new SGSN indicates that it has authenticated the
MS, the old SGSN stops assigning SNDCP N-PDU numbers to downlink
N-PDUs received, and responds with SGSN Context Response (MM Context,
PDP Contexts). If the MS is not known in the old SGSN, the old SGSN responds
with an appropriate error cause. The old SGSN stores New SGSN Address, to
allow the old SGSN to forward data packets to the new SGSN after it receives an
SGSN Context Acknowledge message from the new SGSN. Each PDP Context
includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be
sent in acknowledged mode to the MS, the SNDCP Receive N-PDU Number for
the next uplink N-PDU to be received in acknowledged mode from the MS, the
GTP sequence number for the next downlink N-PDU to be sent to the MS and the
GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN.
The old SGSN starts a timer and stops the transmission of N-PDUs to the MS.
The data to be transmitted includes the N-PDUs buffered in the old SGSN and
the N-PDUs received from the GGSN before the timer expires. N-PDUs that
were already sent to the MS in acknowledged mode and that are not yet
acknowledged by the MS are tunnelled together with the SNDCP N-PDU
number.
3)
4)
The new SGSN sends an SGSN Context Acknowledge message to the old
SGSN. This informs the old SGSN that the new SGSN is ready to receive data
packets belonging to the activated PDP contexts.
5)
The old SGSN duplicates the buffered N-PDUs and starts tunnelling them to the
new SGSN.
6)
The new SGSN sends Update PDP Context Request (new SGSN Address, TEID,
QoS Negotiated) to the GGSNs concerned.
7)
The new SGSN informs the HLR of the change of SGSN by sending Update
Location (SGSN Number, SGSN Address, IMSI) to the HLR. If the SGSN is
unable to update the PDP context in one or more GGSNs, then the SGSN shall

3-25
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

deactivate the corresponding PDP contexts. This shall not cause the SGSN to
reject the routeing area update.
8)
The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN.
9)
The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the
new SGSN. The new SGSN returnes an Insert Subscriber Data Ack message to
the SGSN.
10) A new P-TMSI may be allocated. The SGSN responds to the MS with a Routeing
Area Update Accept (P-TMSI, P-TMSI Signature).
11) If P-TMSI was reallocated, the MS acknowledges the new P-TMSI by returning a
Routeing Area Update Complete message to the SGSN. If the routeing area
update procedure fails a maximum allowable number of times, or if the SGSN
returns a Routeing Area Update Reject (Cause) message, the MS shall enter
IDLE state.
Compared with the intra SGSN routeing area update procedure, the inter SGSN
routeing area update procedure includes two more processes, i.e., the process of
context request of the new SGSN from the old SGSN and the process of location
update between the HLR and the two SGSNs.
For an MS with GPRS-CSI defined, CAMEL interaction may be performed:
C1) CAMEL-Disconnect-PDP-Context. This procedure is performed every time when
C2) CAMEL-GPRS-Detach
C3) CAMEL-GPRS-Routeing-Area-Update
C4) CAMEL-Update-PDP-Context. This procedure is performed every time when a
PDP context is updated and shall be performed for many times.
V. Combined RA/LA Update Procedure

A combined RA/LA update procedure involves the MSC/VLR.
A combined RA/LA update procedure takes place in network operation mode I:
when the MS enters a new RA;
when a GPRS-attached MS performs IMSI attach; or
when the MS actually enters a new LA.
The Combined RA/LA Update (intra SGSN) procedure is illustrated in Figure 3-14.

3-26
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

BSS
MS
SGSN
new
MSC/VLR
HLR
old
MSC/VLR

3. Location Update Request
4a. Update Location
4b. Cancel Location
5. Location Update Accept
C1
Figure 3-14 Combined RA/LA update in the case of intra SGSN RA update procedure

1)
Update Type) to the SGSN. Update Type shall indicate combined RA/LA update,
or, if the MS wants to perform an IMSI attach, combined RA/LA update with IMSI
attach requested. The BSS shall add the Cell Global Identity including the RAC
and LAC of the cell where the message was received before passing the
2)
3)
When the MS enters a new RA, when a GPRS-attached MS performs IMSI

attach, or when the MS actually enters a new LA, the SGSN sends a Location
Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the
VLR.
4)
The new VLR sends an Update Location (new VLR) to the HLR. The HLR
cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR
and sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.

3-27
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5)
The new VLR allocates a new VLR TMSI and responds with Location Update
Accept (VLR TMSI) to the SGSN. VLR TMSI is optional if the VLR has not
changed.
6)
The SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR
TMSI, P-TMSI Signature).
7)
If a new P-TMSI or VLR TMSI was received, then the MS confirms the
reallocation of the TMSIs by returning a Routeing Area Update Complete
8)
The SGSN sends a TMSI Reallocation Complete message to the VLR if the VLR
TMSI is confirmed by the MS.
If the routeing area update procedure fails a maximum allowable number of times, or
if the SGSN returns a Routeing Area Update Reject (Cause) message, the MS shall
enter IDLE state. If the Location Update Accept message indicates a reject, then this
should be indicated to the MS, and the MS shall not access non-GPRS services until
a successful Location Update is performed.
C1) CAMEL-GPRS-Routeing-Area-Update.
The Combiend RA/LA Update (inter SGSN) procedure is illustrated in Figure 3-15.
Compared with the combined RA/LA update (intra SGSN) procedure, the combined
RA/LA update (inter SGSN) procedure includes two more processes, i.e., the process
of context request of the new SGSN from the old SGSN and the process of location
update between the HLR and the two SGSNs.

3-28
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
BSS
new SGSN
GGSN
old SGSN
new
MSC/VLR
HLR
old
MSC/VLR

C1
C2
5. Forward Packets
7. Update Location
8. Cancel Location
12a. Update Location
12b. Cancel Location
C3
C4
Figure 3-15 Combined RA/LA update in the case of inter SGSN RA update procedure

3-29
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Whether in the intra SGSN routeing area update procedure, in the inter SGSN
routeing area update procedure or in the combined RA/LA update procedure, a new
P-TMSI may be allocated by the SGSN.
3.8.2 Location Management Procedures (UMTS Only)

I. Routeing area update procedure
The UMTS RA Update procedure is illustrated in Figure 3-16.

3-30
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
UTRAN
new
3G-SGSN
old
3G-SGSN
GGSN
new
MSC/VLR
HLR
old
MSC/VLR

C1
2a. SRNS Context Request

2a. SRNS Context Response

4. SGSN Context Ack
C2
6. Update Location
7a. Iu Release Command
7. Cancel Location
7a. Iu Release Complete

C2
C3
Figure 3-16 UMTS RA update procedure

3-31
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


1)
The RRC connection is established, if not already done. The MS sends a

Routeing Area Update Request message (P-TMSI, old RAI, old P-TMSI
Signature, Update Type, follow on request, Classmark, DRX parameters) to the
new SGSN. Follow on request shall be set by MS 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 RA update procedure. Update Type shall indicate:
RA Update if the RA Update is triggered by a change of RA;
Periodic RA Update if the RA update is triggered by the expiry of the Periodic RA
Update timer;
Combined RA/LA Update if the MS is also IMSI-attached and the LA update shall
be performed in network operation mode I; or
Combined RA/LA Update with IMSI attach requested if the MS wants to perform
an IMSI attach in network operation mode I.
The SRNC shall add the Routeing Area Identity including the RAC and LAC of the
area where the MS is located before forwarding the message to the 3G-SGSN. This
RA identity corresponds to the RAI in the MM system information sent by the SRNC to
the MS. ClassMark is described in Section 3.12
Classmark Handling. DRX
Parameters indicate whether the MS uses discontinuous reception or not. If the MS

uses discontinuous reception, then DRX Parameters also indicate when the MS is in a
non-sleep mode able to receive paging requests.
2)
If the RA update is an Inter-SGSN Routeing Area update and if the MS was in

PMM-IDLE state, the new SGSN sends SGSN Context Request message (old
P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to get the MM and PDP
contexts for the MS. The old SGSN validates the old P-TMSI Signature and
the old SGSN. This should initiate the security functions in the new SGSN. If the
security functions authenticate the MS correctly, the new SGSN shall send an
SGSN Context Request (IMSI, old RAI, MS Validated) message to the old SGSN.
MS Validated indicates that the new SGSN has authenticated the MS. If the old
P-TMSI Signature was valid or if the new SGSN indicates that it has
authenticated the MS, the old SGSN responds with SGSN Context Response
(Cause, IMSI, MM Context, PDP contexts). If the MS is not known in the old
SGSN, the old SGSN responds with an appropriate error cause. The old SGSN
starts a timer.
3)
Security functions may be executed. If the security functions do not authenticate

the MS correctly, then the routeing area update shall be rejected, and the new
SGSN shall send a reject indication to the old SGSN. The old SGSN shall
continue as if the SGSN Context Request was never received.
4)
If the RA update is an Inter-SGSN Routeing Area update, the new SGSN sends
an SGSN Context Acknowledge message to the old SGSN. The old SGSN
3-32
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

marks in its context that the MSC/VLR association and the information in the
GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and
the HLR to be updated if the MS initiates a routeing area update procedure back
to the old SGSN before completing the ongoing routeing area update procedure.
5)
If the RA update is an Inter-SGSN RA Update and if the MS was in PMM-IDLE

state, the new SGSN sends Update PDP Context Request (new SGSN Address,
QoS Negotiated, Tunnel Endpoint Identifier) to the GGSNs concerned. The
GGSNs update their PDP context fields and return an Update PDP Context
Response (Tunnel Endpoint Identifier). If the RA update is an Inter-SGSN
routeing area update initiated by an MS in PMM-CONNECTED state, then the
Update PDP Context Request message is sent as described in Section II.
Serving RNS relocation procedures.
6)
If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of
the change of SGSN by sending Update Location (SGSN Number, SGSN
Address, IMSI) to the HLR.
7)
If the RA update is an Inter-SGSN RA Update, the HLR sends Cancel Location

(IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update
Procedure. If the timer described in step 2) is not running, then the old SGSN
removes the MM context. Otherwise, the contexts are removed only when the
timer expires. It also ensures that the MM context is kept in the old SGSN in case
the MS initiates another inter SGSN routeing area update before completing the
ongoing routeing area update to the new SGSN. The old SGSN acknowledges
with Cancel Location Ack (IMSI).
8)
If the RA update is an Inter-SGSN RA Update, the HLR sends Insert Subscriber

Data (IMSI, subscription data) to the new SGSN. The new SGSN validates the
MS's presence in the (new) RA. If due to regional subscription restrictions the MS
is not allowed to be attached in the RA, the SGSN rejects the Routeing Area
Update Request with an appropriate cause, and may return an Insert Subscriber
Data Ack (IMSI, SGSN Area Restricted) 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.
9)
If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the

Update Location by sending Update Location Ack (IMSI) to the new SGSN after
the old MM context is removed and the new MM is inserted.
10) If Update Type indicates combined RA/LA update with IMSI attach requested, or
if the LA changed with the routeing area update, then the association has to be
established, and the new SGSN sends a Location Update Request (new LAI,
IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type
shall indicate IMSI attach if Update Type in step 1) indicated combined RA/LA
update with ISI attach requested. Otherwise, Location Update Type shall
indicate normal location update. The VLR number is translated from the RAI via
a table in the SGSN. The SGSN starts the location update procedure towards the

3-33
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

new MSC/VLR upon receipt of the first Insert Subscriber Data message from the
HLR in step 8). The VLR creates or updates the association with the SGSN by
storing SGSN Number.
11) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new
VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data
in the new VLR (this signalling is not modified from existing GSM signalling and is
included here for illustrative purposes):
a) The new VLR sends an Update Location (new VLR) to the HLR.
b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the
old VLR.
c) The old VLR acknowledges with Cancel Location Ack (IMSI).
d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new
VLR.
e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).
f) The HLR responds with Update Location Ack (IMSI) to the new VLR.
12) The new VLR allocates a new TMSI and responds with Location Update Accept
(VLR TMSI) to the SGSN. VLR TMSI is optional if the VLR has not changed.
13) The new SGSN validates the MS's presence in the new RA. If due to roaming
restrictions the MS is not allowed to be attached in the SGSN, or if subscription
checking fails, then the SGSN rejects the routeing area update with an
appropriate cause. If all checks are successful then the new SGSN establishes
MM context for the MS. The new SGSN responds to the MS with Routeing Area
Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature).
14) The MS confirms the reallocation of the TMSIs by returning a Routeing Area
Update Complete message to the SGSN.
15) The new SGSN sends a TMSI Reallocation Complete message to the new VLR
if the VLR TMSI is confirmed by the MS.
C1) CAMEL-GPRS-Detach.
C2) CAMEL-GPRS-Routeing-Area-Update-Session.
C3) CAMEL-GPRS-Routeing-Area-Update-Context. This procedure is performed
every time when a PDP context is updated and shall be performed for many times.
Note:
Steps 11), 12), and 15), are performed only if step 9) is performed.

3-34
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. Serving RNS relocation procedures

Soft handover
The Inter SGSN Soft Handover procedure is illustrated in Figure 3-17.
MS
Source
RNC
Target
RNC
Old
SGSN
New
SGSN
GGSN
1. Decision to perform
SRNS relocation
2. Relocation Required
3. Forward Relocation Request
4. Relocation Request
Establishment of Radio Access Bearers
4. Relocation Request Acknowledge
5. Forward Relocation Response
C1
6. Relocation Command
7. Relocation Commit
8. Forwarding of data
9. Relocation Detect
10. RNTI Reallocation
12. RNTI Reallocation Complete

13. Relocation Complete
13. Forward Relocation Complete
13. Forward Relocation Complete Acknowledge
14. Iu Release Command

14. Iu Release Complete
C2
15. Routing Area Update
C3
Figure 3-17 Inter SGSN soft handover procedure
Each step is illustrated in the following list:

1)
The source SRNC decides to perform/initiate an SRNS relocation.
2)
The source SRNC initiates the relocation preparation procedure by sending a

Relocation Required message (Relocation Type, Cause, Source ID, Target ID,
Source RNC to target RNC transparent container) to the old SGSN. The source
SRNC shall set the Relocation Type to "UE not involved". The Source RNC to

3-35
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

target RNC transparent container includes the necessary information for

Relocation, security functionality and RRC protocol context information
(including UE Capabilities).
3)
The old SGSN determines from the Target ID if the SRNS Relocation is intra
SGSN SRNS relocation or inter SGSN SRNS relocation. In case of inter SGSN
relocation the old SGSN initiates the relocation resource allocation procedure by
sending a Forward Relocation Request message (IMSI, Tunnel Endpoint
Identifier Signalling, MM Context, PDP Context, Target Identification, UTRAN
transparent container, RANAP Cause) to the new SGSN. At the same time a
timer is started on the MM and PDP contexts in the old SGSN. The Forward
Relocation Request message is applicable only in case of inter SGSN SRNS
relocation.
4)
The new SGSN sends a Relocation Request message (Permanent NAS UE

Identity, Cause, CN Domain Indicator, Source RNC to target RNC transparent
container, RABs to be setup) to the target RNC. For each RAB requested to be
established, the RABs to be setup information elements shall contain information
such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport
Association. The RAB ID information element contains the NSAPI value, and the
RAB parameters information element gives the QoS profile. The Transport Layer
Address is the SGSN Address for user data, and the Iu Transport Association
corresponds to Tunnel Endpoint Identifier Data. After all necessary resources for
accepted RABs including the Iu user plane are successfully allocated, the target
RNC shall send the Relocation Request Acknowledge message (RABs setup,
RABs failed to setup) to the new SGSN.
5)
When resources for the transmission of user data between target RNC and new
SGSN have been allocated and the new SGSN is ready for relocation of SRNS,
the Forward Relocation Response message (Cause, RANAP Cause, and RAB
Setup Information) is sent from new SGSN to old SGSN. This message indicates
that the target RNC is ready to receive from source SRNC the downstream
packets not yet acknowledged by the MS, i.e. the relocation resource allocation
procedure is terminated successfully. RANAP Cause is information from the
target RNC to be forwarded to the source RNC. The RAB Setup Information, one
information element for each RAB, contains the RNC Tunnel Endpoint Identifier
and RNC IP address for data forwarding from source SRNC to target RNC. If the
target RNC or the new SGSN failed to allocate resources the RAB Setup
Information element contains only NSAPI indicating that the source RNC shall
release the resources associated with the NSAPI. The Forward Relocation
Response message is applicable only in case of inter SGSN SRNS relocation.
6)
The old SGSN continues the relocation of SRNS by sending a Relocation

Command message (RABs to be released, and RABs subject to data forwarding)
to the source SRNC. The old SGSN decides the RABs to be subject to data
forwarding based on QoS, and those RABs shall be contained in RABs subject to

3-36
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

data forwarding. For each RAB subject to data forwarding, the information
element shall contain RAB ID, Transport Layer Address, and Iu Transport
Association. The Transport Layer Address and Iu Transport Association are
used for forwarding of DL N-PDU from source RNC to target RNC.
7)
Upon reception of the Relocation Command message from the PS domain, the
source RNC shall start the data-forwarding timer. When the relocation
preparation procedure is terminated successfully and when the source SRNC is
ready, the source SRNC shall trigger the execution of relocation of SRNS by
sending a Relocation Commit message (SRNS Contexts) to the target RNC. The
purpose of this procedure is to transfer SRNS contexts from the source RNC to
the target RNC.
8)
After having sent the Relocation Commit message, source SRNC begins the
forwarding of data for the RABs to be subject for data forwarding. The data
forwarding at SRNS relocation shall be carried out through the Iu interface,
meaning that the data exchanged between source SRNC and target RNC are
duplicated in the source SRNC and routed at IP layer towards the target RNC.
9)
The target RNC shall send a Relocation Detect message to the new SGSN when
the relocation execution trigger is received. For SRNS relocation type "UE not
involved", the relocation execution trigger is the reception of the Relocation
Commit message from the Iur interface. When the Relocation Detect message is
sent, the target RNC shall start SRNC operation.
10) After having sent the Relocation Detect message, target SRNC responds to the
MS by sending a RNTI Reallocation message. Both messages contain UE
information elements and CN information elements. The UE information
elements include among others new SRNC identity. The CN information
elements contain among others Location Area Identification and Routeing Area
Identification.
11) Upon reception of the Relocation Detect message, the CN may switch the user
plane from source RNC to target SRNC. If the SRNS Relocation is an inter
SGSN SRNS relocation, the new SGSN sends Update PDP Context Request
messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS
Negotiated) to the GGSNs concerned. The GGSNs update their PDP context
fields and return an Update PDP Context Response (GGSN Tunnel Endpoint
Identifier).
12) When the MS has reconfigured itself, it sends the RNTI Reallocation Complete
message to the target SRNC. From now on the exchange of packets with the MS
can start.
13) When the target SRNC receives the RNTI Reallocation Complete message, the
target SRNC shall initiate the Relocation Complete procedure by sending the
Relocation Complete message to the new SGSN. If the SRNS Relocation is an
inter SGSN SRNS relocation, the new SGSN shall signal to the old SGSN the
completion of the SRNS relocation procedure by sending a Forward Relocation

3-37
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Complete message. Upon reception of the message, the old SGSN returns a
response to the new SGSN.
14) After having received the Forward Relocation Complete message from the new
SGSN and returned a response to the new SGSN, the old SGSN sends an Iu
Release
Command
message
to
the source RNC.
When the
RNC
data-forwarding timer has expired the source RNC responds with an Iu Release
CMP message.
15) If the new Routeing Area Identification is different from the old one, the MS
initiates the Routeing Area Update procedure. The relocation procedure is only a
subset of the RA update procedure.
C1)
CAMEL-GPRS-Deactivate-PDP-Context
CAMEL-GPRS-Detach-PDP-Context.
Hard handover
The Inter SGSN Hard Handover procedure is illustrated in Figure 3-18.

3-38
and
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
Source
RNC
Target
RNC
Old
SGSN
New
SGSN
GGSN
SRNS Relocation
MS Involved
C1
7. Physical Channel Reconfiguration
8. Forward SRNS Context
8. Forward SRNS Context Acknowledge
MS detected by target RNC

12. Physical Channel Reconfiguration Complete
C2
C3
Figure 3-18 Inter SGSN hard handover procedure

3-39
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

1)
Based on measurement results and knowledge of the UTRAN topology, the

source SRNC decides to initiate a combined hard handover and SRNS
relocation.
2)

Relocation Required (Relocation Type, Cause, Source ID, Target ID, Source
RNC to target RNC transparent container) message to the old SGSN. The
source SRNC shall set Relocation Type to "UE Involved". Source RNC to target
RNC transparent container includes the necessary information for relocation,
security functionality and RRC protocol context information (including UE
Capabilities).
3)
The old SGSN determines from the Target ID if the SRNS relocation is intra
SRNS relocation the old SGSN initiates the relocation resource allocation
procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint
Transparent Container, RANAP Cause) message to the new SGSN. At the same
time a timer is started on the MM and PDP contexts in the old SGSN. The
Forward Relocation Request message is applicable only in case of inter SGSN
SRNS relocation.
4)
The new SGSN sends a Relocation Request (Permanent NAS UE Identity,

Cause, CN Domain Indicator, Source RNC to target RNC transparent container,
RABs to be setup) message to the target RNC. For each RAB requested to be
established, RABs to be setup shall contain information such as RAB ID, RAB
parameters, Transport Layer Address, and Iu Transport Association. The RAB
ID information element contains the NSAPI value, and the RAB parameters
information element gives the QoS profile. The Transport Layer Address is the
SGSN Address for user data, and the Iu Transport Association corresponds to
Tunnel Endpoint Identifier Data. After all the necessary resources for accepted
RABs including the Iu user plane are successfully allocated, the target RNC shall
send the Relocation Request Acknowledge (RABs setup, RABs failed to setup)
message to the new SGSN. The target RNC will for each RAB to be setup
(defined by an IP Address and a Tunnel Endpoint Identifier) receive both
forwarded downstream PDUs from the source SRNC as well as downstream
PDUs from the new SGSN.
5)
the Forward Relocation Response (Cause, RANAP Cause, RAB Setup
Information) message is sent from the new SGSN to the old SGSN. This
message indicates that the target RNC is ready to receive from source SRNC the
downstream packets not yet acknowledged by the MS, i.e., the relocation
resource allocation procedure is terminated successfully. RANAP Cause is
information from the target RNC to be forwarded to the source RNC. RAB Setup

3-40
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Information contains the RNC Tunnel Endpoint Identifier and RNC IP address for
data forwarding from source SRNC to target RNC. If the target RNC or the new
SGSN failed to allocate resources the RAB Setup Information element contains
only NSAPI indicating that the source RNC shall release the resources
associated with the NSAPI. The Forward Relocation Response message is
applicable only in case of inter-SGSN SRNS relocation.
6)

Command (RABs to be released, RABs subject to data forwarding) message to
the source SRNC. The old SGSN decides the RABs to be subject for data
Association. Transport Layer Address and Iu Transport Association are used for
forwarding of DL N-PDU from source RNC to target RNC.
7)
source RNC shall start the data-forwarding timer. The source SRNC triggers the
execution of relocation of SRNS by sending to the MS a Physical Channel
Reconfiguration (UE Information Elements, CN Information Elements) message.
8)
The source SRNC continues the execution of relocation of SRNS by sending a

Forward SRNS Context (RAB Contexts) message to the target RNC via the old
and the new SGSNs, which is acknowledged by a Forward SRNS Context
Acknowledge message.
9)
After having sent the Forward SRNS Context message, source SRNC begins the
forwarding of data for the RABs to be subject for data forwarding. The data
forwarding at SRNS relocation shall be carried out through the Iu interface,
meaning that the data exchanged between source SRNC and target RNC are
duplicated in the source SRNC and routed at IP layer towards the target RNC.
10) The target RNC shall send a Relocation Detect message to the new SGSN when
the relocation execution trigger is received. For SRNS relocation type "UE
Involved", the relocation execution trigger may be received from the Uu interface.
When the Relocation Detect message is sent, the target RNC shall start SRNC
operation.
plane from source RNC to target SRNC. If the SRNS relocation is an inter SGSN
SRNS relocation, the new SGSN sends Update PDP Context Request (New
SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated) message to
the GGSNs concerned. The GGSNs update their PDP context fields and return
an Update PDP Context Response (GGSN Tunnel Endpoint Identifier) message.
12) When the MS has reconfigured itself, it sends an RNTI Reallocation Complete
can start.

3-41
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

13) When the target SRNC receives the RNTI Reallocation Complete message, the
target SRNC shall initiate Relocation Complete procedure by sending the
Relocation Complete message to the new SGSN. If the SRNS Relocation is an
inter SGSN SRNS relocation, then the new SGSN signals to the old SGSN the
completion of the SRNS relocation procedure by sending a Forward Relocation
Complete message. Upon reception of the message, the old SGSN returns a
response to the new SGSN.
14) After having received the Forward Relocation Complete message from the new
SGSN and returned a response to the new SGSN, the old SGSN sends an Iu
Release CMD message to the source RNC. When the RNC data-forwarding
timer has expired the source RNC responds with an Iu Release CMP message.
15) If the new Routeing Area Identification is different from the old one, the MS
initiates the Routeing Area Update procedure. The relocation procedure is only a
subset of the RA update procedure.
C1)
C2) CAMEL-GPRS-Routeing-Area-Update
Combined cell/URA update and SRNS relocation procedure

3-42
and
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
Source
RNC
Target
RNC
Old
SGSN
New
SGSN
GGSN
SRNS Relocation
MS Involved
C1
7. Physical Channel Reconfiguration
8. Forward SRNS Context Acknowledge
MS detected by target RNC

12. Physical Channel Reconfiguration Complete
C2
C3
Figure 3-19 Combined cell/URA update and SRNS relocation procedure

1)
The MS sends a Cell Update/URA Update message to the UTRAN, after having
made cell re-selection. Upon reception of the message, the source SRNC

3-43
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

decides to perform a combined cell/URA update and SRNS relocation towards

the target RNC.
2)

Relocation Required message (Relocation Type, Cause, Source ID, Target ID,
Source RNC to target RNC transparent container) to the old SGSN. The source
SRNC shall set Relocation Type to "UE not involved". Source RNC to target RNC
transparent container includes the necessary information for Relocation, security
functionality, and RRC protocol context information (including UE Capabilities).
3)
The old SGSN determines from the Target ID if the SRNS Relocation is intra
SRNS relocation the old SGSN initiates the relocation resource allocation
procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint
transparent container, RANAP Cause) message to the new SGSN. At the same
time a timer is started on the MM and PDP contexts in the old SGSN. The
Forward Relocation Request message is applicable only in case of inter SGSN
SRNS relocation.
4)
The new SGSN sends a Relocation Request message (Permanent NAS UE

Identity, Cause, CN Domain Indicator, Source RNC to target RNC transparent
container, RABs to be setup) to the target RNC. For each RAB requested to be
established, RABs to be setup shall contain information such as RAB ID, RAB
parameters, Transport Layer Address, and Iu Transport Association. The RAB
ID information element contains the NSAPI value, and the RAB parameters
information element gives the QoS profile. The Transport Layer Address is the
SGSN Address for user data, and the Iu Transport Association corresponds to
Tunnel Endpoint Identifier Data. After all necessary resources for accepted
RABs including the Iu user plane are successfully allocated, the target RNC shall
send the Relocation Request Acknowledge (RABs setup, RABs failed to setup)
message to the new SGSN. The target RNC will for each RAB to be setup
(defined by an IP Address and a Tunnel Endpoint Identifier) receive both
forwarded downstream PDUs from the source SRNC as well as downstream
PDUs from the new SGSN.
5)
the Forward Relocation Response message (Cause, RANAP Cause, and RAB
Setup Information) is sent from new SGSN to old SGSN. This message indicates
that the target RNC is ready to receive from source SRNC the downstream
packets not yet acknowledged by MS, i.e., the relocation resource allocation
procedure is terminated successfully. RANAP Cause is information from the
target RNC to be forwarded to the source RNC. The RAB Setup Information
contains the RNC Tunnel Endpoint Identifier and RNC IP address for data
forwarding from source SRNC to target RNC. If the target RNC or the new SGSN

3-44
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

failed to allocate resources the RAB Setup Information element contains only
NSAPI indicating that the source RNC shall release the resources associated
with the NSAPI. The Forward Relocation Response message is applicable only
in case of inter SGSN SRNS relocation.
6)

Command (RABs to be released, and RABs subject to data forwarding)
message to the source SRNC. The old SGSN decides the RABs subject to data
Association. The Transport Layer Address and Iu Transport Association are
used for forwarding of DL N-PDU from source RNC to target RNC.
7)
source RNC shall start the data-forwarding timer. When the relocation
preparation procedure is terminated successfully and when the source SRNC is
ready, the source SRNC shall trigger the execution of relocation of SRNS by
sending a Relocation Commit (SRNS Contexts) message to the target RNC. The
purpose of this procedure is to transfer SRNS contexts from the source RNC to
the target RNC.
8)
After having sent the Relocation Commit message, source SRNC begins the
forwarding of data for the RABs subject to data forwarding. The data forwarding
at SRNS relocation shall be carried out through the Iu interface, meaning that the
data exchanged between source SRNC and target RNC are duplicated in the
source SRNC and routed at IP layer towards the target RNC.
9)
The target RNC shall send a Relocation Detect message to the new SGSN when
the relocation execution trigger is received. For SRNS relocation type "UE not
involved", the relocation execution trigger is the reception of the Relocation
Commit message from the Iur interface. When the Relocation Detect message is
sent, the target RNC shall start SRNC operation.
10) After having sent the Relocation Detect message, target SRNC responds to the
MS by sending a Cell Update Confirm/URA Update Confirm message. Both
messages contain UE information elements and CN information elements. The
UE information elements include among others new SRNC identity and S-RNTI.
The CN information elements contain among others Location Area Identification
and Routeing Area Identification.
plane from source RNC to target SRNC. If the SRNS Relocation is an inter
SGSN SRNS relocation, the new SGSN sends Update PDP Context Request
messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS
Negotiated) to the GGSNs concerned. The GGSNs update their PDP context
fields and return an Update PDP Context Response (GGSN Tunnel Endpoint
Identifier) message.

3-45
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

12) When the MS has reconfigured itself, it sends the RNTI Reallocation Complete
can start.
13) When the target SRNC receives the RNTI Reallocation Complete message, i.e.
the new SRNC-ID+S-RNTI are successfully exchanged with the UE by the radio
protocols, the target SRNC shall initiate the Relocation Complete procedure by
sending the Relocation Complete message to the new SGSN. If the SRNS
Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old
SGSN the completion of the SRNS relocation procedure by sending a Forward
Relocation Complete message. Upon reception of the message, the old SGSN
returns a response to the new SGSN.
14) The old SGSN sends an Iu Release Command message to the source RNC.
When the RNC data-forwarding timer has expired the source RNC responds with
an Iu Release Complete.
15) After the MS has finished the Cell/URA update and RNTI reallocation procedure
and if the new Routeing Area Identification is different from the old one, the MS
initiates the Routeing Area Update procedure. The Relocation procedure is only
a subset of the RA update procedure that is performed, since the MS is in
PMM-CONNECTED state.
C1)
and
3.8.3 Periodic RA/LA Update

All GPRS-attached MSs, except GSM MSs in class-B mode of operation engaged in
CS communication, shall perform periodic RA updates. MSs that are IMSI-attached
and not GPRS-attached shall perform periodic LA updates. Periodic RA updates are
equivalent to intra SGSN routeing area updates, with Update Type indicating periodic
RA update. For MSs that are both IMSI-attached and GPRS-attached, the periodic
updates depend on the mode of operation of the network:
If the network operates in mode I, periodic RA updates shall be performed, and
periodic LA updates shall not be performed. In this case, the MSC/VLR shall
disable implicit detach for GPRS-attached MSs and instead rely on the SGSN to
receive periodic RA updates. If periodic RA updates are not received in the
SGSN and the SGSN detaches the MS, the SGSN shall notify the MSC/VLR by
sending an IMSI Detach Indication message.
If the network operates in mode II or mode III, both periodic RA updates and
periodic LA updates shall be performed independently. RA updates are

3-46
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

performed towards the SGSN, and LA updates are performed towards the
MSC/VLR.
In the mode involving A/Gb interface, the periodic RA update timer in the MS is
stopped when the MM context state enters to READY. The periodic RA update timer is
reset and started when the state returns to STANDBY.
In the mode involving Iu interfce, the periodic RA update timer in the MS is stopped
when the MM context state enters to the PMM-CONNECTED state. The periodic RA
update timer is reset and started when the state returns to the PMM-IDLE state.
3.9 Subscriber Management Function

The Subscriber Management function provides a mechanism to inform the nodes
about changes of the PS subscription data for a specific PS subscriber.
3.9.1 Subscriber Management Procedures

The HLR performs management over the subscriber data stored in the SGSN by
means of the following procedures:
Insert Subscriber Data procedure
SGSN
HLR

Figure 3-20 Insert subscriber data procedure

Delete Subscriber Data procedure
SGSN
HLR
1. Delete Subscriber Data

2. Delete Subscriber Data Ack
Figure 3-21 Delete subscriber data procedure

3-47
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.10 Service Request Procedure s (UMTS Only)

3.10.1 MS-Initiated Service Request Procedure
MS
SGSN
RNC
HLR
GGSN
1. RRC Connection Request

1. RRC Connection Setup
2. Service Request
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 3-22 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 Data or Signalling. At this time, the SGSN may perform the
authentication procedure.
If Service Type indicates Data then a signalling connection is established
between the MS and the SGSN, and resources for active PDP context(s) are
allocated.
If Service Type indicates Signalling then the signalling connection is established
between the MS and the SGSN for sending upper-layer signalling messages
3)
The SGSN shall perform the security functions if the service request was initiated
by an MS in PMM-IDLE state.
4)
When the network is in the PMM-CONNECTED state and when Service Type
indicates Data, the SGSN responds with a Service Accept message to the MS if
it accepts the service request. In case Service Type indicates Data, the SGSN
sends a Radio Access Bearer Assignment Request (NSAPIRAB ID(s), TEID(s),

3-48
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

QoS Profile(s), SGSN IP Address(es)) message to re-establish radio access

bearer for every activated PDP context.
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 "Requested Maximum
Bit Rate not Available", then 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, if it is in the PMM-IDLE state, the MS knows that the Service
Request was successfully received when the MS receives the RRC Security Mode
Control Command message. If it is in the PMM-IDLE state, the MS knows that the
Service Request was successfully received when the MS receives the Service Accept
message.
The Service Accept message does not mean successful re-establishment of 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 SGSN-Initiated PDP Context Modification or
PDP Context Deactivation procedure should be initiated. The appropriate action
depends on the QoS profile of the PDP context.

3-49
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.10.2 Network-Initiated Service Request Procedure

MS
RNC
SGSN
HLR
GGSN
1. Downlink PDU
2. Paging
2. Paging
4. Service Request

Complete

Request

Response
7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU
Figure 3-23 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.
3)
The MS establishes an RRC connection if none exists for CS traffic.
4)
to the SGSN. Service Type specifies Paging Response. At this time, the SGSN
may perform the authentication procedure. The SGSN knows whether the
downlink packet requires RAB establishment or not.
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

3-50
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

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) cannot be provided, e.g.,
"Requested Maximum Bit Rate not Available", then 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
shall initiates a Modification procedure.

3-51
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.11 UMTS-GSM Intersystem Change

3.11.1 Intra SGSN Intersystem Change
I. UMTS-to-GSM intra SGSN change
MS
BSS
SRNS
2G+3G-SGSN
new
MSC/VLR
HLR
old
MSC/VLR
1. Intersystem change decision

3. SRNS Context Request
4. SRNS Context Response
6. SRNS Data Forward Command
7. Forward Packets
10c. Cancel Location Ac
10f. Update Location
C1
15. BSS Packet Flow Context Procedure
Figure 3-24 UMTS-to-GSM intra SGSN change

3-52
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

1)
When the MS roams to a new cell that supports GSM radio technology, the MS or
BSS or UTRAN decides to perform an intersystem change and stops
transmission to the network.
2)
Update Type) message to the 2G+3G-SGSN. Update Type shall indicate RA
update or combined RA/LA update or, if the MS wants to perform an IMSI attach,
combined RA/LA update with IMSI attached requested. The BSS shall add the
Cell Global Identity (CGI) including the RAC and LAC of the cell where the
message was received before passing the message to the 2G+3G-SGSN.
3)
The 2G+3G-SGSN sends an SRNS Context Request (IMSI) message to the

SRNS.
4)
Upon receiving the SRNS Context Request message, the SRNS stops
transmission of downlink PDUs to the MS, buffers the downlink PDUs and
responds with an SRNS Context Response (GTP-SND, GTP-SNU, PDCP-SND,
PDCP-SNU) message to the 2G+3G-SGSN. The GTP sequence numbers are
included for each PDP context indicating the next in-sequence downlink PDU to
be sent to the MS and the next in-sequence GTP PDU to be tunnelled to the
GGSN. For each active PDP context using acknowledged mode, the SRNS also
includes the uplink PDCP sequence number (PDCP-SNU). PDCP-SNU is the
PDCP sequence number for the next expected in-sequence uplink packet to be
received in acknowledged mode from the MS for each radio bearer, which
requires lossless relocation, thus converting them to SNDCP N-PDU numbers of
the respective 2G GPRS PDP contexts.
5)
6)
The 2G+3G-SGSN sends an SRNS Data Forward Command (RAB ID,

Transport Layer Address, Iu Transport Association) message to the SRNS. This
informs the SRNS that the 2G+3G-SGSN is ready to receive data packets. Upon
reception of SRNS Data Forward Command message from the 2G+3G-SGSN
the SRNS shall start the data-forwarding timer.
7)
The transmitted but not acknowledged PDCP-PDUs together with the downlink
PDCP sequence number and the buffered downlink GTP PDUs are tunnelled
back to the 2G+3G-SGSN. The 2G+3G-SGSN shall strip off the eight most
significant bits of the PDCP sequence numbers accompanying the received
N-PDUs before sending them to the MS.
8)
When the RNC data forwarding timer has expired, the 2G+3G-SGSN sends an
Iu Release Command message to the SRNS and the SRNS responds with an Iu
Release Complete message.
9)
If the association has to be established i.e., if Update Type indicates combined

RA/LA update with IMSI attach requested, or if the LA changed with the routeing
area update, then the 2G+3G-SGSN sends a Location Update Request (new LAI,
shall indicate normal location update. The VLR number is translated from the

3-53
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

RAI by the 2G+3G-SGSN. The VLR creates or updates the association with the
2G+3G-SGSN by storing SGSN Number.
10) If the subscriber data in the VLR is marked as not confirmed by the HLR, then the
new VLR informs the HLR. The HLR cancels the data in the old VLR and inserts
subscriber data in the new VLR:
The new VLR sends an Update Location (new VLR) to the HLR.
The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to
the old VLR.
The old VLR acknowledges with Cancel Location Ack (IMSI).
The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new
VLR.
The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).
The HLR responds with Update Location Ack (IMSI) to the new VLR.
11) The new VLR allocates a new VLR TMSI and responds with Location Update
Accept (VLR TMSI) to the 2G+3G-SGSN. VLR TMSI is optional if the VLR has
not changed.
12) The 2G+3G-SGSN validates the MS's presence in the new RA. If due to roaming
restrictions the MS is not allowed to be attached in the RA, or if subscription
checking fails, then the 2G+3G-SGSN rejects the routeing area update with an
appropriate cause. If all checks are successful then the 2G+3G-SGSN updates
MM and PDP contexts for the MS. A new P-TMSI may be allocated. A logical link
is established between the new 2G+3G-SGSN and the MS. The establishment
procedure is initiated by 2G+3G-SGSN. A Routeing Area Update Accept
(P-TMSI, P-TMSI Signature, Receive N-PDU Number (=converted PDCP-SNU))
message is returned to the MS. Receive N-PDU Number contains the
acknowledgements for each acknowledged-mode NSAPI used by the MS,
thereby confirming all mobile-originated N-PDUs successfully transferred before
the start of the update procedure.
13) The MS acknowledges the new P-TMSI by returning a Routeing Area Update
Complete (Receive N-PDU Number) message to the SGSN. Receive N-PDU
Number (=converted PDCP-SND) contains the acknowledgements for each
acknowledged-mode NSAPI used by the MS, thereby confirming all
mobile-terminated N-PDUs successfully transferred before the start of the
update procedure. The MS deducts Receive N-PDU Number from PDCP-SND
by stripping off the eight most significant bits.
14) The 2G+3G-SGSN sends a TMSI Reallocation Complete message to the VLR if
the VLR TMSI is confirmed by the MS.
15) The 2G+3G-SGSN and the BSS may execute the BSS Packet Flow Context
procedure.
C1) If CAMEL is supported, CAMEL-GPRS-Routeing-Area-Update shall be
performed at C1.

3-54
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. GSM-to-UMTS intra SGSN change
MS
BSS
SRNS
2G+3G-SGSN
new
MSC/VLR
HLR
old
MSC/VLR
1. Intersystem change decision
2. Routing Area Update Request

5a. Update Location
5b. Cancel Location
5c. Cancel Location Ac
5e. Insert Subscriber Data
5f. Update Location
7. Routing Area Update Accept
C1
8. Routing Area Update Complete
10. Service Request
Set up Radio
Resources
11. RAB Assignment Request

11. RAB Assignment
12. Packet Transfer Resume
13. Packet Transfer Resume
Figure 3-25 GSM-to-UMTS intra SGSN change

1)
The MS or BSS or UTRAN decides to perform an intersystem change which

makes the MS switch to a new cell that supports UMTS radio technology, and
stops transmission to the network.
2)
The MS initiates an RRC connection establishment and sends Routeing Area

Update Request (P-TMSI, Old RA, Old P-TMSI Signature, Update Type, CM)
message to the combined 2G+3G-SGSN. Update Type shall indicate RA update
or combined RA/LA update or, if the MS wants to perform an IMSI attach,
3-55
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

combined RA/LA update with IMSI attach requested. The message may also
contain the follow on request indication i.e., 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 RAU procedure. The SRNS shall add an identifier of the area
where the message was received before passing the message to the
2G+3G-SGSN. The 2G+3G-SGSN stops transmission of N-PDUs to the MS.
3)
4)
If the association has to be established i.e., if Update Type indicates combined

area update, then the 2G+3G-SGSN sends a Location Update Request (new LAI,
update with IMSI attach requested. Otherwise, Location Update Type shall
indicate normal location update. The VLR number is translated from the RAI by
the 2G+3G-SGSN. The VLR creates or updates the association with the
2G+3G-SGSN by storing SGSN Number.
5)
If the subscriber data in the VLR is marked as not confirmed by the HLR, then the
new VLR informs the HLR. The HLR cancels the data in the old VLR and inserts
subscriber data in the new VLR:
the old VLR.
VLR.
6)
The new VLR allocates a new VLR TMSI and responds with Location Update
Accept (VLR TMSI) to the 2G+3G-SGSN.
7)
The 2G+3G-SGSN validates the MS's presence in the new RA. If due to roaming
restrictions the MS is not allowed to be attached in the RA, or if subscription
checking fails, then the 2G+3G-SGSN rejects the routeing area update with an
appropriate cause. If all checks are successful then the 2G+3G-SGSN updates
MM and PDP contexts for the MS. A new P-TMSI may be allocated. A Routeing
Area Update Accept (P-TMSI, P-TMSI Signature) message is returned to the
MS.
8)
The MS acknowledges the new P-TMSI by returning a Routeing Area Update

Complete message to the SGSN.
9)
The 2G+3G-SGSN sends a TMSI Reallocation Complete message to the VLR if

the VLR TMSI is confirmed by the MS.

3-56
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

10) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message
to the SGSN. Service Type specifies the requested service (data or signalling).
11) The 2G+3G-SGSN requests the SRNS to establish a radio access bearer by
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP-SNDs,
GTP-SNUs, PDCP-SNUs) message to the SRNS. The PDCP-SNU shall be
derived from the N-PDU sequence numbers stored in the PDP contexts. The
SRNS sends a Radio Bearer Setup Request (PDCP-SNUs) message to the MS.
The MS responds with a Radio Bearer Setup Complete (PDCP-SNDs) message.
The SRNS responds with a RAB Assignment Response message.
12) Traffic flow is resumed between the 2G+3G-SGSN and the SRNS. The SRNS
shall discard all N-PDUs with N-PDU sequence numbers older than the downlink
N-PDU sequence number received from the MS. Other N-PDUs shall be
transmitted to the MS. The MS shall discard all N-PDUs with sequence numbers
older than the GTP-SNU received from the SRNS. If this is not the case the
N-PDU shall be transmitted to the SRNS.
13) The traffic flow is resumed between the SRNS and the MS.

3-57
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.11.2 Inter SGSN Intersystem Change

I. UMTS-to-GSM inter SGSN change
MS
BSS
SRNS
new
2G-SGSN
old
3G-SGSN
GGSN
new
MSC/VLR
HLR
old
MSC/VLR
1. Intersystem change
decision
2. Routing Area Update Request

4. SRNS Context Request
4. SRNS Context Response

C1
8. SRNS Data Forward Command
8a. Forward Packets

9. Forward Packets

11. Update GPRS Location
12. Cancel Location

15. Update GPRS Location Ack


C2
19. Routing Area Update Accept

C3
20. Routing Area Update Complete
22. BSS Packet Flow Context Procedure
Figure 3-26 UMTS-to-GSM inter SGSN change

3-58
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


1)
The MS or BSS or UTRAN decides to perform an intersystem change, which

makes the MS switch to a new cell that supports GSM radio technology, and
2)
Update Type) message to the new 2G-SGSN. Update Type shall indicate RA
update or combined RA/LA update, or, if the MS wants to perform an IMSI attach,
combined RA/LA update with IMSI attach requested. The BSS shall add the Cell
Global Identity including the RAC and LAC of the cell where the message was
received before passing the message to the new 2G-SGSN.
3)
The new 2G-SGSN sends an SGSN Context Request (old RAI, TLLI, old P-TMSI
Signature, New SGSN Address) message to the old 3G-SGSN to get the MM
and PDP contexts for the MS. The old SGSN validates the old P-TMSI Signature
and responds with an appropriate error cause if it does not match the value
stored in the old 3G-SGSN. The old 3G-SGSN starts a timer. If the MS is not
known in the old 3G-SGSN, the old 3G-SGSN responds with an appropriate
error cause.
4)
If the MS is PMM-CONNECTED the old 3G-SGSN sends an SRNS Context

Request (IMSI) message to the SRNS. Upon reception of this message the
SRNS buffers and stops sending downlink PDUs to the MS and returns an SRNS
Context Response (IMSI, GTP-SNDs, GTP-SNUs, PDCP-SNUs) message. The
SRNS shall include for each PDP context the next in-sequence GTP sequence
number to be sent to the MS and the GTP sequence number of the next uplink
PDU to be tunnelled to the GGSN. For each active PDP context using
acknowledged mode, the SRNS also includes the uplink PDCP sequence
number (PDCP-SNU). PDCP-SNU shall be the next in-sequence PDCP
sequence number expected from the MS per active radio bearer. The 3G-SGSN
shall strip off the eight most significant bits of the passed PDCP sequence
numbers, thus converting them to SNDCP N-PDU numbers.
5)
The old 3G-SGSN responds with an SGSN Context Response (MM Context,
PDP Contexts) message. For each PDP context the old 3G-SGSN shall include
the GTP sequence number for the next uplink GTP PDU to be tunnelled to the
GGSN and the next donwlink GTP sequence number for the next in-sequence
N-PDU to be sent to the MS. Each PDP Context also includes the SNDCP Send
N-PDU Number (the value is 0) for the next in-sequence downlink N-PDU to be
sent in acknowledged mode to the MS and the SNDCP Receive N-PDU Number
(=converted PDCP-SNU) for the next in-sequence uplink N-PDU to be received
in acknowledged mode from the MS. The new 3G-SGSN shall neglect the MS
network capability that is included in the MM context in the SGSN Context
Response message received during the previous routeing area update
procedure.
6)

3-59
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

7)
The new 2G-SGSN sends an SGSN Context Acknowledge message to the old
3G-SGSN. This informs the old 3G-SGSN that the new 2G-SGSN is ready to
receive data packets belonging to the activated PDP contexts. The old SGSN
the HLR to be updated if the MS initiates a RA update procedure back to the old
SGSN before completing the ongoing RA update procedure.
8)
If the MS is PMM-CONNECTED the old 3G-SGSN sends an SRNS Data

Forward Command (RAB ID, Transport Layer Address, Iu Transport Association)
message to the SRNS. The SRNS shall start tunnelling the partly transmitted
and the transmitted but not acknowledged PDCP-PDUs together with the PDCP
downlink sequence number (the eight most significant bits shall be stripped off),
and start duplicating and tunnelling the buffered GTP PDUs to the old 3G-SGSN.
Upon reception of SRNS Data Forward Command message from the 3G-SGSN
the SRNS shall start the data-forwarding timer.
9)
The old 3G-SGSN tunnels the GTP PDUs to the new 2G-SGSN. The sequence
numbers (=converted PDCP sequence numbers) shall not be modified in the
GTP header of the tunnelled PDUs.
10) The new 2G-SGSN sends an Update PDP Context Request (new SGSN
Address, TEID, QoS Negotiated) message to each GGSN concerned. Each
GGSN updates its PDP context fields and returns an Update PDP Context
Response (TEID) message.
11) The new 2G-SGSN informs the HLR of the change of SGSN by sending an
Update GPRS Location (SGSN Number, SGSN Address, IMSI) message to the
HLR.
12) The HLR sends a Cancel Location (IMSI) message to the old 3G-SGSN. The old
3G-SGSN acknowledges with a Cancel Location Ack (IMSI) message. The old
3G-SGSN removes the MM and PDP contexts when the timer described in step
3) expires.
13) When the MS is PMM-CONNECTED the old 3G-SGSN sends an Iu Release
Command message to the SRNS. When the RNC data-forwarding timer has
expired the SRNS responds with an Iu Release Complete message.
14) The HLR sends an Insert Subscriber Data (IMSI, GPRS Subscription Data)
message to the new 2G-SGSN. The 2G-SGSN inserts subscriber data in the MM
and PDP contexts for the MS and returns an Insert Subscriber Data Ack (IMSI)
message to the HLR.
15) The HLR acknowledges the Update GPRS Location by returning an Update
GPRS Location Ack (IMSI) message to the new 2G-SGSN if the modification is
confirmed to be completed.
16) If the association has to be established i.e., if Update Type indicates combined
area update, then the new 2G-SGSN sends a Location Update Request (new

3-60
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update
Type shall indicate IMSI attach if Update Type in step 1) indicated combined
RA/LA update with IMSI attach requested. Otherwise, Location Update Type
shall indicate normal location update. The VLR number is translated from the
RAI by the 2G-SGSN. The 2G-SGSN starts the location update procedure
towards the new MSC/VLR upon receipt of the Insert Subscriber Data message
from the HLR. The VLR creates or updates the association with the 2G-SGSN by
storing SGSN Number.
in the new VLR:
the old VLR.
VLR.
(VLR TMSI) to the 2G-SGSN. VLR TMSI is optional if the VLR has not changed.
19) The new 2G-SGSN validates the MS's presence in the new RA. If due to roaming
restrictions the MS is not allowed to be attached in the 2G-SGSN, or if
subscription checking fails, then the new 2G-SGSN rejects the routeing area
update with an appropriate cause. If all checks are successful then the new
2G-SGSN constructs MM and PDP contexts for the MS. A logical link is
established between the new 2G-SGSN and the MS. The establishment
procedure is initiated by 2G-SGSN. The new 2G-SGSN responds to the MS with
a Routeing Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU
Number (=converted PDCP-SNU)) message. Receive N-PDU Number contains
the acknowledgements for each acknowledged-mode NSAPI used by the MS,
thereby confirming all mobile-originated N-PDUs successfully transferred before
the start of the update procedure.
Complete (Receive N-PDU Number (=converted PDCP-SND)) message to the
SGSN. Receive N-PDU Number contains the acknowledgements for each
acknowledged-mode NSAPI used by the MS, thereby confirming all
mobile-terminated N-PDUs successfully transferred before the start of the
update procedure. The MS deducts Receive N-PDU number from PDCP-SND
by stripping off the eight most significant bits. PDCP-SND is the PDCP sequence
number for the next expected in-sequence downlink packet to be received in
acknowledged mode in the MS per radio bearer.

3-61
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

21) The new 2G-SGSN sends TMSI Reallocation Complete message to the new
VLR if the VLR TMSI is confirmed by the MS.
22) The 2G-SGSN and the BSS may execute the BSS Packet Flow Context
procedure.
C1) CAMEL-GPRS-SGSN-Context-Acknowledge
C2) CAMEL-GPRS-Routeing-Area-Update-Session
C3) CAMEL-GPRS-Routeing-Area-Update-Context

3-62
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. GSM-to-UMTS inter SGSN change
MS
BSS
SRNS
new
3G-SGSN
old
2G-SGSN
GGSN
new
MSC/VLR
HLR
old
MSC/VLR
1. Intersystem
change decision

C1
7. Forward Packets
9. Update GPRS Location
10. Cancel Location

12. Update GPRS Location Ack

14b. Cancel Location Ack
14c. Insert Subscriber Data
14d. Insert Subscriber Data Ack
14e. Update Location Ack
C2
C3
19. Service Request

Set up Radio
Resources
20. RAB Assignment Request

20. RAB Assignment Response
Figure 3-27 GSM-to-UMTS inter SGSN change

3-63
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


1)
The MS or BSS or UTRAN decides to perform an intersystem change, which

makes the MS switch to a new cell that supports UMTS radio technology, and
2)
The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSI
Signature, Update Type, CM, MS Network Capability) message to the new
3G-SGSN. Update Type shall indicate RA update or combined RA/LA update, or,
if the MS wants to perform an IMSI attach, combined RA/LA update with IMSI
attach requested. The message may also contain the follow on request
indication i.e., 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 RAU procedure. The SRNC
shall add the Routeing Area Identity including the RAC and LAC of the area
where the MS is located before forwarding the message to the 3G-SGSN. This
RA identity corresponds to the RAI in the MM system information sent by the
SRNC to the MS.
3)
The new 3G-SGSN uses the old RAI received from the MS to derive the old
2G-SGSN address, and sends an SGSN Context Request (old RAI, old P-TMSI,
New SGSN Address) message to the 2G-SGSN to get the MM and PDP
contexts for the MS. The old 2G-SGSN validates the old P-TMSI Signature and
the old 2G-SGSN. If the unmatch error is received the 3G-SGSN shall initiate an
Authenticate procedure. If the MS is authenticated correctly, the new 3G-SGSN
shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN
Address) message to the old 2G-SGSN. MS Validated indicates that the new
3G-SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if
the new 3G-SGSN indicates that it has authenticated the MS, the old 2G-SGSN
starts a timer and stops the transmission of N-PDUs to the MS.
4)
The old 2G-SGSN responds with an SGSN Context Response (MM Context,
PDP Contexts) message. Each PDP Context includes the GTP sequence
number for the next downlink N-PDU to be sent to the MS and the GTP sequence
number for the next uplink N-PDU to be tunnelled to the GGSN. Each PDP
Context also includes the SNDCP Send N-PDU Number for the next downlink
N-PDU to be sent in acknowledged mode to the MS and the SNDCP Receive
N-PDU Number for the next uplink N-PDU to be received in acknowledged mode
from the MS. The new 3G-SGSN shall use the GTP sequence numbers for
in-sequence delivery over the Iu interface. The new 3G-SGSN shall neglect the
MS network capability included in the MM context that is obtained through the
routeing area update procedure.
5)
6)

The new 3G-SGSN sends an SGSN Context Acknowledge message to the old
2G-SGSN. This informs the old 2G-SGSN that the new 3G-SGSN is ready to

3-64
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

receive data packets belonging to the activated PDP contexts. The old SGSN
the HLR to be updated if the MS initiates a routeing area update procedure back
to the old SGSN before completing the ongoing routeing area update procedure.
7)
The old 2G-SGSN duplicates the buffered N-PDUs and starts tunnelling them to
the new 3G-SGSN. Additional N-PDUs received from the GGSN before the timer
described in step 3) expires are also duplicated and tunnelled to the new
3G-SGSN. No N-PDUs shall be forwarded to the new 3G-SGSN after expiry of
the timer described in step 3).
8)
The new 3G-SGSN sends an Update PDP Context Request (new SGSN
Address, TEID, QoS Negotiated) message to each GGSN concerned. Each
GGSN updates its PDP context fields and return an Update PDP Context
Response (TEID) message.
9)
The new 3G-SGSN informs the HLR of the change of SGSN by sending an
Update GPRS Location (SGSN Number, SGSN Address, IMSI) message to the
HLR.
10) The HLR sends a Cancel Location (IMSI, Cancellation Type) message to the old
2G-SGSN. The old 2G-SGSN removes the MM and PDP contexts when the
timer described in step 3) expires. The old 2G-SGSN acknowledges with a
Cancel Location Ack (IMSI) message.
11) The HLR sends an Insert Subscriber Data (IMSI, GPRS Subscription Data)
message to the new 3G-SGSN. The 3G-SGSN constructs an MM context for the
MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.
12) The HLR acknowledges the Update GPRS Location by returning an Update
GPRS Location Ack (IMSI) message to the new 3G-SGSN.
13) If the association has to be established, if Update Type indicates combined
area update, then the new SGSN sends a Location Update Request (new LAI,
update with IMSI attach requested. Otherwise, Location Update Type shall
indicate normal location update. The VLR number is translated from the RAI by
the 3G-SGSN. The 3G-SGSN starts the location update procedure towards the
new MSC/VLR upon receipt of the Insert Subscriber Data message from the
HLR. The VLR creates or updates the association with the 3G-SGSN by storing
SGSN Number.
in the new VLR:

3-65
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

the old VLR.
VLR.
(VLR TMSI) to the 3G-SGSN. VLR TMSI is optional if the VLR has not changed.
16) The new 3G-SGSN validates the MS's presence in the new RA. If due to roaming
restrictions the MS is not allowed to be attached in the 3G-SGSN, or if
subscription checking fails, then the new 3G-SGSN rejects the routeing area
update with an appropriate cause. If all checks are successful then the new
3G-SGSN constructs MM and PDP contexts for the MS. The new 3G-SGSN
responds to the MS with a Routeing Area Update Accept (P-TMSI, P-TMSI
signature ) message.
Complete message to the SGSN.
18) The new 3G-SGSN sends TMSI Reallocation Complete message to the new
VLR if the VLR TMSI is confirmed by the MS.
19) If the MS is to send any uplink data or signalling it sends a Service Request
(P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type
specifies the requested service Service Type shall indicate Data or Signalling.
20) If the MS has sent the Service Request the new 3G-SGSN requests the SRNS to
establish a radio access bearer by sending a RAB Assignment Request (RAB
ID(s), QoS Profile(s), GTP-SNDs, GTP-SNUs, PDCP-SNUs) message to the
SRNS. The PDCP sequence numbers shall be derived from the N-PDU
sequence numbers stored in the PDP contexts. The SRNS sends a Radio
Bearer Setup Request (PDCP-SNUs) message to the MS. The MS responds
with a Radio Bearer Setup Complete (PDCP-SNDs) message. The SRNS
responds with a RAB Assignment Response message. The SRNS shall discard
all N-PDUs tunnelled from the SGSN with N-PDU sequence numbers older than
the PDCP-SNDs received from the MS. Other N-PDUs shall be transmitted to the
MS. The MS shall discard all N-PDUs with sequence numbers older than the
PDCP-SNUs received from the SRNS.
C1) CAMEL-GPRS-SGSN-Context-Acknowledge
C2) CAMEL-GPRS-Routeing-Area-Update-Session
C3) CAMEL-GPRS-Routeing-Area-Update-Context

3-66
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

3.12 Classmark Handling

3.12.1 Radio Access Classmark
I. MS radio access capability (GSM only)
The MS radio access capability information element contains all the GSM radio
capabilities of the MS, e.g., multislot capability, power class.
II. UE capability (UMTS only)

The UE capability information element contains all the UMTS radio capabilities of the
MS, e.g., power control, code resource, UE mode, ciphering, PDCP capabilities, etc.
3.12.2 MS Network Capability

The MS network capability contains non radio-related capabilities, e.g., the GSM
GPRS ciphering, UMTS authentication, and TI extension capabilities.

3-67
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Chapter 4 Session Management Functions................................................................................ 4-1
4.1 Definition of Packet Data Protocol States.......................................................................... 4-1
4.1.1 INACTIVE State ...................................................................................................... 4-1
4.1.2 ACTIVE State .......................................................................................................... 4-2
4.2 PDP Context Activation, Modification, Deactivation, and Preservation Functions ............ 4-3
4.2.1 Static and Dynamic PDP Addresses....................................................................... 4-3
4.2.2 Activation Procedures ............................................................................................. 4-4
4.2.3 Modification Procedures.......................................................................................... 4-8
4.2.4 Deactivation Procedures ....................................................................................... 4-12
4.2.5 Preservation Procedures and Re-establishment of RABs .................................... 4-14

i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


This chapter describes the concepts and procedures related to Session management.
4.1 Definition of Packet Data Protocol States

A GPRS subscription contains the subscription of one or more Packet Data Protocol
(PDP) addresses. Each PDP address is described by one or more PDP contexts in
the MS, the SGSN, and the GGSN. Each PDP context may be associated with a
Traffic Flow Template (TFT). At most one PDP context associated with the same PDP
address may exist at any time with no TFT assigned to it. Every PDP context exists
independently in one of the following two PDP states: INACTIVE state and ACTIVE
state. The PDP state indicates whether data transfer is enabled for that PDP address
and TFT or not. In case all PDP contexts associated with the same PDP address are
deactivated, data transfer for that PDP address is disabled. All PDP contexts of a
subscriber are associated with the same MM context for the IMSI of that subscriber.
The TFT contains attributes that specify an IP header filter that is used to direct data
packets received from the interconnected external packet data network to the newly
activated PDP context.
Note:
The TFT contains IP header filters. An IP headr filter is used to identify a traffic flow among the traffic
flows associated with the same PDP address.
4.1.1 INACTIVE State

The INACTIVE state characterizes the data service for a certain PDP address of the
subscriber as not activated. The PDP context contains no routeing or mapping
information to process PDP Protocol Data Units (PDUs) related to that PDP address.
No data can be transferred. A changing location of a subscriber causes no update for
the PDP context in INACTIVE state even if the subscriber is GPRS-attached.
Mobile-terminated PDP PDUs received in INACTIVE state by the GGSN may initiate
the Network-Requested PDP Context Activation procedure if the GGSN is allowed to
initiate the activation of the PDP context for that PDP address. Otherwise,
mobile-terminated PDP PDUs received in INACTIVE state invoke error procedures by
4-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

the PDP, for example, an IP packet is discarded and an ICMP packet is returned to
the source of the received packet.
The MS initiates the movement from INACTIVE to ACTIVE state by initiating the PDP
Context Activation procedure.
4.1.2 ACTIVE State

In ACTIVE state, the PDP context for the PDP address in use is activated in MS,
SGSN and GGSN. The PDP context contains mapping and routeing information for
transferring PDP PDUs for that particular PDP address between MS and GGSN. The
PDP state ACTIVE is permitted only when the mobility management state of the
subscriber is STANDBY, READY, PMM-IDLE, or PMM-CONNECTED. The Iu interface
radio access bearer may or may not be established for an active PDP context.
An active PDP context for an MS is moved to INACTIVE state when the deactivation
procedure is initiated.
All active PDP contexts for an MS are moved to INACTIVE state when the MM state
changes to IDLE or PMM-DETACHED.
Figure 4-1 illustrates the SM functional PDP state model.
INACTIVE
Activate PDP
Context
Deactivate PDP Context

or
MM state change to IDLE
or PMM-DETACHED
ACTIVE
Figure 4-1 SM functional PDP state model

4-2
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

4.2 PDP Context Activation, Modification, Deactivation, and

Preservation Functions
The session management (SM) supports PDP context processing for an MS,
including procedures of PDP context activation, modification, deactivation, etc. The
SM procedure to confirm access is permitted only when a MM context has been
established between the MS and the network.
The main functions of session management are:
I. PDP context activation

MS-initiated PDP context activation
MS-initiated secondary PDP context activation
Network-initiated PDP context activation
II. PDP context modification

GGSN-initiated PDP context modification
SGSN-initiated PDP context modification
MS-initiated PDP context modification
RNC-initiated PDP context modification
RAB release-initiated local PDP context modification
III. PDP context deactivation

SGSN-initiated PDP context deactivation
GGSN-initiated PDP context deactivation
MS-initiated PDP context deactivation
IV. PDP context preservation

Re-establishment of RABs initiated by MS by using Service Request
Re-establishment of RABs initiated by SGSN by using Service Request
Iu release-initiated PDP context preservation and RAB release-initiated PDP
context preservation
4.2.1 Static and Dynamic PDP Addresses

PDP addresses can be allocated to an MS in four different ways:
1)
the HPLMN operator assigns a PDP address permanently to the MS (static PDP
address);
2)
the HPLMN operator assigns a PDP address to the MS when a PDP context is
activated (dynamic HPLMN PDP address);
3)
the VPLMN operator assigns a PDP address to the MS when a PDP context is
activated (dynamic VPLMN PDP address); or

4-3
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

4)
the PDN operator or administrator assigns an IP address to the MS after a PDP

context has been activated (External PDN Address Allocation).
It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN
or VPLMN PDP address can be used.
For every IMSI, zero, one, or more dynamic or static PDP addresses per PDP type
can be assigned.
When dynamic addressing from the HPLMN or the VPLMN is used, it is the
responsibility of the GGSN to allocate and release the dynamic PDP address. When
External PDN Address Allocation is used, it is the responsibility of the MS and the
PDN to allocate and release the dynamic PDP address by means of protocols such
as DHCP or MIP. In case of DHCP, the GGSN provides the function of a DHCP Relay
Agent. In case of MIP, the GGSN provides the function of a Foreign Agent.
Only static PDP addressing is applicable in the network-requested PDP context
activation case.
4.2.2 Activation Procedures

PDP context activation procedures include MS-initiated PDP context activation
procedure, secondary PDP context activation procedure and network-initiated PDP
context activation procedure.
I. MS-initiated PDP context activation procedure

Figure 4-2 and Figure 4-3 illustrate the MS-initiated PDP context activation procedure.
MS
BSS
2G-SGSN
2G-GGSN
1. Activate PDP Context Request

C1
4. Invoke Trace
5. Create PDP Context Request
5. Create PDP Context Response
6. BSS Packet Flow Context Procedures
C2
7. Activate PDP Context Accept
Figure 4-2 MS-initiated PDP context activation procedure for GSM

4-4
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
UTRAN
3G-SGSN
3G-GGSN
1. Activate PDP Context Request

C1
3. Radio Access Bearer Setup

4. Invoke Trace

C2
Figure 4-3 MS-initiated PDP context activation procedure for UMTS
Note:
C1 and C2 indicate two CAMEL related procedures. They are outside the scope of this manual.

1)
The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP
Address, Access Point Name, QoS Requested) 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.
2)
In GSM, security functions may be executed.
3)
In UMTS, RAB setup is done by the RAB Assignment procedure.
4)
If BSS trace is activated, then the SGSN shall send an Invoke Trace message to
the BSS or RNC.
5)
The SGSN validates the Activate PDP Context Request using PDP Type
(optional), PDP Address (optional), Access Point Name (optional), and the PDP
context subscription records.
The SGSN creates a TEID for the requested PDP context. If the MS requests a
dynamic address, then the SGSN lets a GGSN allocate the dynamic address. The
SGSN selects an APN according to a certain algorithm and 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) to the affected
GGSN.

4-5
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

The GGSN then returns a Create PDP Context Response message, allocating a
dynamic PDP address, charging ID, negotiated QoS. If the MS requests External
PDN Address Allocation, then PDP Address shall be set to 0.0.0.0. The
GGSN-initiated PDP context modification procedure shall be executed after the later
External PDN Address Allocation.
6)
In GSM R99 system, BSS packet flow context procedures may be executed for
QoS negotiation with BSS.
7)
Upon reception of the Create PDP Context Response message (NSAPI, PDP
ADDR, GGSN ADDR, TEID, QoS) from the GGSN, the SGSN returns an
Activate PDP Context Accept message to the MS, including PDP Address, QoS,
etc.
II. Secondary PDP context activation procedure

One PDP address may be used by multiple PDP contexts. The Secondary PDP
Context Activation procedure may only be initiated after a PDP context is already
activated for the same PDP address and APN. The newly activated PDP context
reuses the PDP address and other PDP context information from the already active
PDP context, but with a different QoS profile. Each PDP context sharing the same
PDP address and APN shall be identified by a unique TI and a unique NSAPI. The
secondary PDP context activation procedure is similar to the PDP context activation
procedure, except that procedures for APN selection and PDP address negotiation
are not executed.
Only one PDP context without associated TFT is allowed among the PDP contexts.
The GGSN chooses an appropriate PDP context to route downlink N-PDUs based on
TFT match. The MS chooses a PDP context for data transmission based on QoS.
Figure 4-4 and Figure 4-5 illustrate the secondary PDP context activation procedure.
MS
BSS
2G-SGSN
2G-GGSN
1. Activate Secondary PDP Context Request

C1
5. BSS Packet Flow Context Procedures
C2
6. Activate Secondary PDP Context Accept
Figure 4-4 Secondary PDP context activation for GSM

4-6
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
UTRAN

3G-SGSN
3G-GGSN
1. Activate Secondary PDP Context Request

C1
3. Radio Access Bearer Setup
C2
Figure 4-5 Secondary PDP context activation for UMTS

1)
The MS sends an Activate Secondary PDP Context Request (Linked TI, NSAPI,
TI, QoS Requested, TFT) message to the SGSN.
2)
In GSM, security functions may be executed.
3)
In UMTS, RAB setup is done by the RAB Assignment procedure.
4)
The SGSN allocates a user plane TEID to the requested PDP context. The same
GGSN address is used by the SGSN as for the already-activated PDP context(s)
for that PDP address. The SGSN sends a Create PDP Context Request (QoS
Negotiated, TEID, NSAPI, Primary NSAPI, TFT) message to the affected GGSN.
The GGSN then returns a Create PDP Context Response message, allocating a
charging ID and negotiated QoS.
5)
In GSM R99 system, BSS packet flow context procedures may be executed for
QoS negotiation with BSS.
6)
Upon reception of the Create PDP Context Response message (NSAPI, PDP
ADDR, GGSN ADDR, TEID, QoS) from the GGSN, the SGSN returns an
Activate PDP Context Accept message to the MS, including PDP Address, QoS,
etc.
III. Network-initiated PDP context activation procedure

Figure 4-6 illustrates the network-initiated PDP context activation procedure.

4-7
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
SGSN
HLR
GGSN
1. PDP PDU
2. Send Routeing Info for GPRS

2. Send Routeing Info for GPRS Ack
3. PDU Notification Request
3. PDU Notification Response
4. Request PDP Context Activation
5. PDP Context Activation procedure
Figure 4-6 Network-initiated PDP context activation procedure

1)
The GGSN receives a PDP PDU.
2)
The GGSN sends a Send Routeing Information for GPRS (IMSI) message to the
HLR to request the SGSN address. If the MS is reachable, the HLR returns the
SGSN address by returning a Send Routeing Information for GPRS Ack (IMSI,
SGSN Address, Mobile Station Not Reachable Reason) message to the GGSN.
Otherwise, the Mobile Station Not Reachable Reason (MNRR) parameter
indicates error together with a reason. If the MNRR record indicates a reason
other than "No Paging Response", the HLR shall include the GGSN number in
the GGSN-list of the subscriber.
3)
If the SGSN address is present or Mobile Station Not Reachable Reason

indicates "No Paging Response", the GGSN shall send a PDU Notification
Request (IMSI, PDP Type, PDP Address, APN) message to the SGSN. The
SGSN returns a PDU Notification Response (Cause) message to the GGSN in
order to acknowledge that it shall request the MS to activate the PDP context.
4)
The SGSN sends a Request PDP Context Activation (TI, PDP Type, PDP
Address, APN) message to request the MS to activate the PDP context.
5)
The MS initiates the PDP context activation procedure.
4.2.3 Modification Procedures

PDP context modification procedures include MS-initiated PDP context modification
procedure, SGSN-initiated PDP context modification procedure, GGSN-initiated PDP
context modification and RAB/Iu release-initiated PDP context modification procedure.
The main procedures of the PDP context modification procedures initiated by the MS,
SGSN and GGSN are QoS negotiation and route re-establishment.
The following parameters can be modified:
QoS Negotiated;
4-8
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Radio Priority;
Packet Flow Id;
PDP Address (in case of the GGSN-initiated modification procedure); and
TFT (in case of MS-initiated modification procedure).
I. SGSN-initiated PDP context modification procedure

The SGSN may initiate a PDP context modification procedure in three cases:
1)
if the HLR inserts subscriber data to the SGSN while the session is active;
2)
if the RAB is re-established and QoS changes; or
3)
if an inter-SGSN routeing area update procedure is implemented while the

session is active.
Figure 4-7 illustrates the SGSN-initiated PDP context modification procedure.

MS
UTRAN
SGSN
GGSN

3. Modify PDP Context Request
4. Modify PDP Context Accept
C1
5. Radio Access Bearer Modification
6. Invoke Trace
Figure 4-7 SGSN-initiated PDP context modification procedure

1)
The SGSN sends an Update PDP Context Request (TEID, NSAPI, QoS
Negotiated, Trace Reference, Trace Type, Trigger Id, OMC Identity) message to
the GGSN for QoS negotiation.
2)
The GGSN performs QoS negotiation, stores QoS Negotiated and returns an
Update PDP Context Response (TEID, QoS Negotiated, Cause) message to the
SGSN.
3)
The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated,
and sends a Modify PDP Context Request (TI, QoS Negotiated, Radio Priority,
Packet Flow Id) message to the MS.
4)
The MS acknowledges by returning a Modify PDP Context Accept message. If

the MS does not accept the new QoS Negotiated it shall instead de-activate the
PDP context with the PDP Context Deactivation Initiated by MS procedure.

4-9
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5)
Radio access bearer modification may be performed by the RAB Assignment

procedure.
6)
If BSS trace is activated, then the SGSN shall send an Invoke Trace (Trace
Reference, Trace Type, Trigger Id, OMC Identity) message.
II. MS-initiated PDP context modification procedure

An MS may initiate a PDP context modification procedure to change the QoS or TFT
of the PDP context. Figure 4-8 illustrates the MS-initiated PDP context modification
procedure.
MS
UTRAN
SGSN
GGSN

C1
Figure 4-8 MS-initiated PDP context modification procedure

1)
The MS sends a Modify PDP Context Request (TI, QoS Requested, TFT)
2)
The SGSN performs QoS negotiation and sends an Update PDP Context
Request (TEID, NSAPI, QoS Negotiated, Trace Reference, Trace Type, Trigger
Id, OMC Identity) message to the GGSN for QoS negotiation.
3)
The GGSN performs QoS negotiation and returns an Update PDP Context
Response (TEID, QoS Negotiated, Cause) message to the SGSN.
4)

procedure.
5)
The SGSN returns a Modify PDP Context Accept message to the MS.
III. GGSN-initiated PDP context modification procedure

The GGSN may initiate a PDP context modification procedure in two cases:
if the GGSN, as a DHCP relay agent, receives an IP address allocated by the
external PDN to an MS; or
if the QoS of the session in the GGSN changes.
Figure 4-9 illustrates the GGSN-initiated PDP context modification procedure.
4-10
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

MS
UTRAN
SGSN
GGSN

C1
Figure 4-9 GGSN-initiated PDP context modification procedure

1)
The GGSN sends an Update PDP Context Request (TEID, NSAPI, PDP Address,
QoS Requested) message to the SGSN.
2)
The SGSN performs QoS negotiation and sends a Modify PDP Context Request
(TI, PDP Address, QoS Negotiated, Radio Priority, Packet Flow Id) message to
the MS.
3)
The MS acknowledges by returning a Modify PDP Context Accept message. If

the MS does not accept the new QoS Negotiated it shall instead de-activate the
PDP context with the PDP Context Deactivation Initiated by MS procedure.
4)

procedure.
5)
Upon receipt of the Modify PDP Context Accept message, the SGSN returns an
Update PDP Context Response (TEID, QoS Negotiated) message to the GGSN.
IV. RAB/Iu release-initiated PDP context modification procedure

The RNC may send an Iu Release Request or RAB Release Request message to the
SGSN. After successful RAB/Iu release the PDP contexts are modified as follows:
In the SGSN, for a PDP context using background or interactive traffic class, the
PDP context is preserved with no modifications.
In the SGSN, for a PDP context using streaming or conversational traffic class,
the PDP context is preserved, but the maximum bit rate is downgraded to 0 kbit/s.
The SGSN also advises the GGSN to change the maximum bit rate in the GGSN
to 0 kbit/s.
The following procedures shall be performed in the MS when the radio coverage is
lost:
For a PDP context using background or interactive traffic class, the PDP context
is preserved even if RRC re-establishment procedures have failed.

4-11
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

For a PDP context using streaming or conversational traffic class, the PDP
context is preserved, but the maximum bit rate is downgraded to 0 kbit/s when
the RRC re-establishment procedure has failed. After coverage is regained, the
MS shall re-activate the PDP context and re-establish the RAB.
4.2.4 Deactivation Procedures

PDP context deactivation procedures include MS-initiated PDP context deactivation
procedure, SGSN-initiated PDP context deactivation procedure and GGSN-initiated
PDP context deactivation procedure.
I. MS-initiated PDP context deactivation procedure

Figure 4-10 and Figure 4-11 illustrate the MS-initiated PDP context deactivation
procedures.
MS
2G-SGSN
2G-GGSN
1. Deactivate PDP Context Request

C1
4. Deactivate PDP Context Accept
Figure 4-10 MS-initiated PDP context deactivation procedure for GSM
MS
UTRAN
3G-SGSN
3G-GGSN

C1
5. Radio Access Bearer Release
Figure 4-11 MS-initiated PDP context deactivation procedure for UMTS

4-12
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

1)
The MS sends a Deactivate PDP Context Request (TI, Teardown Ind) message
to the SGSN. Teardown Ind indicates whether or not all active PDP contexts
sharing the same address with this TI shall be deactivated.
2)
In GSM security functions may be executed.
3)
After receiving the Deactivate PDP Context Request message from the MS, the
SGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind)
message to the GGSN.
4)
The GGSN returns a Delete PDP Context Response (TEID) message to the
SGSN.
5)
Upon reception of the Delete PDP Context Response message from the GGSN,
the SGSN returns a Deactivate PDP Context Accept (TI) message to the MS.
6)
In UMTS, the SGSN uses the RAB Assignment procedure to release the radio
access bearer.
II. SGSN-initiated PDP context deactivation procedure

SGSN-initiated PDP context deactivation generally occurs in the case of MM release
or in the abnormal cases e.g., inconsistent PDP contexts in the MS, SGSN and
GGSN, failed re-establishment of RABs, insufficient resources, etc.
Figure 4-12 illustrates the SGSN-initiated PDP context deactivation procedure.
MS
UTRAN
SGSN
GGSN
C1
Figure 4-12 SGSN-initiated PDP context deactivation procedure

1)
The SGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind)
message to the GGSN. Teardown Ind indicates whether or not all active PDP
contexts sharing the same address with this TI shall be deactivated. The GGSN
returns a Delete PDP Context Response (TEID) message to the SGSN.
2)
Upon reception of the Delete PDP Context Response message from the GGSN,
the SGSN sends a Deactivate PDP Context Request message to the MS. If it is
MS Detach-initiated PDP context deactivation, the SGSN does not send that
4-13
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

message. The MS returns a Deactivate PDP Context Accept message to the

SGSN.
3)
access bearer.
III. GGSN-initiated PDP context deactivation

Figure 4-13 illustrates the GGSN-initiated PDP context deactivation procedure.
MS
UTRAN
SGSN
GGSN

C1
Figure 4-13 GGSN-initiated PDP context deactivation procedure

1)
The GGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind)
message to the SGSN. Teardown Ind indicates whether or not all active PDP
contexts sharing the same address with this TI shall be deactivated.
2)
The SGSN sends a Deactivate PDP Context Request (TI, Teardown Ind)
message to the MS. The MS removes the PDP context(s) and returns a
Deactivate PDP Context Accept (TI, Teardown Ind) message to the SGSN.
3)
The SGSN returns a Delete PDP Context Response (TEID) message to the
GGSN. If the MS was using a dynamic PDP address allocated by the GGSN,
then the GGSN releases this PDP address and makes it available for
subsequent activation by other MSs. The Delete PDP Context messages are
sent over the backbone network. The SGSN may not wait for the response from
the MS before sending the Delete PDP Context Response message.
4)
access bearer.
4.2.5 Preservation Procedures and Re-establishment of RABs

When the RNC initiates the RAB release or Iu release procedure, the active PDP
contexts associated with the released RABs can be preserved without modification by
using the PDP context preservation procedures, and the RABs can then be
re-established in a later Service Request procedure.
4-14
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

I. Re-establishment procedure of RABs initiated by MS by using Service

Request
When an MS wants to send an uplink packet and when the corresponding PDP
contexts are active while have no associated RABs, the MS initiates the
re-establishment of RABs for the active PDP contexts by using the Service Request
procedure. Figure 4-14 illustrates the re-establishment procedure of RABs initiated by
the MS.
MS
SGSN
RNC
HLR
GGSN

2. Service Request
4. Service Accept

Request
Complete
Response
7. SGSN-Initiated PDP Context Modification
8. Uplink PDU
Figure 4-14 Re-establishment procedure of RABs initiated by MS by using Service Request

1)
An RRC connection is established, if none exists.
2)
to the SGSN. Service Type = Data.
3)
The security functions shall be performed.
4)
The SGSN returns a Service Accept message to the MS and re-establishes a

RAB for each active PDP context that has no associated RAB.
5)
If the QoS of a re-established RAB changes, the SGSN initiates a PDP context
modification procedure to inform the MS and GGSN of the new QoS.
6)
The MS sends the uplink packet.
II. Re-establishment procedure of RABs initiated by SGSN by using Service

Request
When the SGSN receives a downlink signalling message or packet for an MS in
PMM-IDLE state, the SGSN sends a paging request. Upon reception of the paging
request, the MS sends a Service Request with service type set as "Paging response".

4-15
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

For the Service Request procedure initiated by SGSN's receiving packet,

re-establishment of RABs shall be initiated by the RAB Assignment procedure.
Figure 4-15 illustrates the re-establishment procedure initiated by the SGSN by using
Service Request.
MS
RNC
SGSN
HLR
GGSN
1. Downlink PDU
2. Paging
2. Paging
4. Service Request

Complete

Request

Response
7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU
Figure 4-15 Re-establishment procedure of RABs initiated by SGSN by using Service Request

4-16
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Chapter 5 Typical Signaling Analysis Cases.............................................................................. 5-1
5.1 Overview of Typical Signaling Analysis ............................................................................. 5-1
5.2 GPRS Attach Procedure.................................................................................................... 5-1
5.2.1 Example .................................................................................................................. 5-1
5.2.2 ATTACH REQUEST Message................................................................................ 5-2
5.2.3 AUTHENTICATION AND CIPHERING REQUEST Message................................. 5-5
5.2.4 AUTHENTICATION AND CIPHERING RESPONSE Message .............................. 5-6
5.2.5 MAP_OPEN_REQ Service ..................................................................................... 5-6
5.2.6 MAP_SERVICE_REQ Service................................................................................ 5-7
5.2.7 MAP_SERVICE_IND Service ................................................................................. 5-8
5.2.8 MAP SERVICE CNF Service .................................................................................. 5-9
5.2.9 ATTACH ACCEPT Message................................................................................. 5-10
5.2.10 ATTACH COMPLETE Message ......................................................................... 5-12
5.3 Combined Attach Procedure............................................................................................ 5-12
5.3.1 Example ................................................................................................................ 5-12
5.3.2 BSSAP+-LOCATION-UPDATE-REQUEST Message .......................................... 5-13
5.3.3 BSSAP+-LOCATION-UPDATE-ACCEPT Message ............................................. 5-14
5.4 Combined RA/LA Update Procedure............................................................................... 5-15
5.4.1 Example ................................................................................................................ 5-15
5.4.2 RA UPDATE REQUEST Message........................................................................ 5-15
5.4.3 BSSAP UPDATE LOCATION REQUEST Message ............................................. 5-16
5.4.4 BSSAP UPDATE LOCATION ACCEPT Message................................................ 5-17
5.4.5 RA ACCEPT Message .......................................................................................... 5-18
5.5 PDP Context Activation Procedure.................................................................................. 5-20
5.5.1 Example ................................................................................................................ 5-20
5.5.2 SERVICE REQUEST Message ............................................................................ 5-21
5.5.3 ACTIVATE PDP CONTEXT REQUEST Message................................................ 5-21
5.5.4 CREATE PDP CONTEXT REQUEST Message................................................... 5-22
5.5.5 CREATE PDP CONTEXT RESPONSE Message ................................................ 5-24
5.5.6 ACTIVATE PDP CONTEXT ACCEPT Message................................................... 5-25
5.6 Abnormal Attach Procedure............................................................................................. 5-26
5.6.1 Overview of Abnormal Attach Procedure.............................................................. 5-26
5.6.2 Protocol error, unspecified .................................................................................... 5-26
5.6.3 Illegal MS............................................................................................................... 5-28
5.6.4 Gs Interface Fault.................................................................................................. 5-30
5.7 Abnormal PDP Activation Procedure............................................................................... 5-32
5.7.1 Overview of Abnormal PDP Context Activation Procedure .................................. 5-32

i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
5.7.2 Request Service Option not Subscribed ............................................................... 5-33

5.7.3 Activate Rejected by GGSN.................................................................................. 5-37

ii
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Chapter 5 Typical Signaling Analysis Cases

5.1 Overview of Typical Signaling Analysis
This chapter presents the analysis of several typical normal and abnormal signaling
trace procedures. It helps the intended readers to know how to read signaling trace
messages and further obtain the useful information for fault diagnostics. This
chapter covers the following procedures:
GPRS attach procedure
Combined attach procedure
Combined RA/LA update procedure
PDP context activation procedure
Abnormal attach procedure
Abnormal PDP context activation procedure
5.2 GPRS Attach Procedure

5.2.1 Example
Figure 5-1 MS-initiated GRPS attach procedure

5-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-1 shows the results traced in an MS-initiated GRPS attach procedure.
If there is no data of the MS in the SGSN, for example, the MS is attached to the
SGSN for the first time, then the first three messages of the MS cannot be traced
through the user trace. You can start the Gb interface trace function to trace the
three messages, as shown in Figure 5-2.
Figure 5-2 MS-initiated GRPS attach procedure
To facilitate fault diagnostics, messages shall not are not filtered during user trace.
Therefore, the traced results include the messages between various protocol layers.
Generally, you can locate faults by analyzing the messages at the highest protocol
level because the lower level messages only assist the diagnostics.
In this example, only the nine messages highlighted in Figure 5-1 are analyzed.
5.2.2 ATTACH REQUEST Message

This message is sent by the MS to the network in order to perform a GPRS or
combined GPRS attach.
Figure 5-3 shows the message content.

5-2
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-3 L3 message content

IE
Description
TI
This IE is a spare field.
Protocol discriminator
The PD identifies the L3 protocol to which the standard layer 3

message belongs.
In this example, the PD is GPRS mobility management messages.
MS network capability
The bits in F4 (11110010) are described from the MSB to the LSB
as follows:
1: encryption algorithm GEA/1 available
1: Mobile station supports mobile terminated point to point SMS via
dedicated signalling channels
1: Mobile station supports mobile terminated point to point SMS via
GPRS packet data channels
1: the ME has no preference between the use of the default
alphabet and the use of UCS2
00: SS Screening Indicator
0: The ME does not support SoLSA

5-3
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
1: used by an MS supporting R99 or later versions of the protocol
Attach type
The purpose of the attach type information element is to indicate

the type of the requested attach, i.e. whether the MS wants to
perform a GPRS or combined GPRS attach.
The attach type information element is coded as follows:
Type of attach (octet 1, bit 1 to 3)
Bits
321
001: GPRS attach
010: GPRS attach while IMSI attached
011: Combined GPRS/IMSI attach
All other values are interpreted as GPRS attach in this version of
the protocol.
Follow-on request (octet 1, bit 4)
Bits
4
0: No follow-on request pending
1: Follow-on request pending
Follow-on request pending is applicable only in UMTS.
In this example, attach type is GPRS attach and no follow-on
request pending.
GPRS ciphering key

sequence number
In a GSM 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 Kc that is stored in the
mobile station without invoking the authentication procedure.
The CKSN information element is coded as follows:
Key sequence (octet 1)
Bits
210
000101: Possible values for the ciphering key sequence number
111: No key is available (MS to network); Reserved (network to
MS)
In this example, no key is available.
DRX parameter
The purpose of the DRX parameter information element is to

indicate whether the MS uses DRX mode or not.
In this example, the MS uses DRX mode.

5-4
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
MS identity
In the example, the IMSI is 460001932076709.

Note: The IMSI consists of Identity1 and Identity left.
Old routing area

identification
The OLD RAI in this example is invalid, that is, there is no OLD
RAI.
MS Radio Access
capability
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.
5.2.3 AUTHENTICATION AND CIPHERING REQUEST Message

This message is sent by the network to the MS to initiate authentication of the MS
identity.
Figure 5-4 L3 message

IE
Description
Ciphering
algorithm
The purpose of the ciphering algorithm information element is to specify

which ciphering algorithm shall be used.
IMEISV request
The purpose of the IMEISV request information element is to indicate that

the IMEISV shall be included by the MS in the authentication and
ciphering response message.
IMEISV is the international mobile equipment identity together with the
software version number.
Force to standby
The purpose of the force to standby information element is to force the

MS to stop the READY timer in order to prevent the MS to perform cell
updates.
A&C reference
number
The purpose of the A&C reference number information element is to

indicate to the network in the AUTHENTICATION AND CIPHERING
RESPONSE message which AUTHENTICATION AND CIPHERING
5-5
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
RESPONSE message which AUTHENTICATION AND CIPHERING
REQUEST message the MS is replying to.
5.2.4 AUTHENTICATION AND CIPHERING RESPONSE Message

This message is sent by the MS to the network in response to an Authentication and
ciphering request message.
Figure 5-5 L3 message content
5.2.5 MAP_OPEN_REQ Service

This service is used for establishing a MAP dialogue between two MAP
service-users.
Figure 5-6 shows parameters for the MAP_OPEN_REQ service.
Figure 5-6 Parameters for the MAP_OPEN_REQ service

5-6
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
Application context name
Identifies the type of application context being established
Destination address
A valid SCCP address identifying the destination peer entity.
5.2.6 MAP_SERVICE_REQ Service

This service is used by the SGSN to update the location information stored in the
HLR.
Figure 5-7 shows the parameters for the MAP_SERVICE_REQ service.
Figure 5-7 MAP_SERVICE_REQ
Table 5-1 Parameters for the MAP_SERVICE_REQ service

Parameter
Description
IMSI
In this example, the IMSI is 46000321907679.
SGSN number
In this example, the SGSN number is 8613741330.
SGSN address
In this example, the SGSN address is 211.138.1.1.
Supported
CAMEL Phases
0520

5-7
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.2.7 MAP_SERVICE_IND Service

This service is used by an HLR to update an SGSN with certain subscriber data.
Figure 5-8 shows the parameters for the MAP_SERVICE_IND service.
Figure 5-8 MAP_SERVICE_IND
Table 5-2 Parameters for the MAP_SERVICE_IND service

Parameter
Description
MSISDN
In this example, the MSISDN is 8613803211853.
Subscriber Status
To apply, remove or update Operator Determined Barring Categories

the Subscriber Status is set to Operator Determined Barring. In this
case ODB General Data shall also be present. If the Operator
Determined Barring applies and the subscriber is registered in the
HPLMN and HPLMN specific Operator Determined Barring applies
then ODB HPLMN Specific Data shall also be present.
To remove all Operator Determined Barring Categories the

5-8
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Parameter
Description
Subscriber Status shall be set to "Service Granted".
Teleservice List
A list of Extensible Teleservice parameters

In this example, there are two teleservices, as shown below:
Teleservice 21, Short Message MT point-to-point
Teleservice 22, Short Message MO point-to-point
GPRS Subscription
Data
Contains a list of PDP-contexts a user has subscribed to.

The content of the PDP context includes:
PDP Context Identifier: Index of the PDP context.
PDP Type: PDP type, for example, PPP or IP.
PDP Address: PDP address, for example, an IP address. This field
shall be empty if dynamic addressing is allowed.
Access Point Name: A label according to DNS naming conventions
describing the access point to the packet data network.
QoS Profile Subscribed: Quality of service profile subscribed. It is the
default level if a particular QoS profile is not requested. QoS Profile
Subscribed is also the maximum QoS per PDP context to the
associated APN.
VPLMN Address Allowed: Specifies whether the MS is allowed to use
the APN in the domain of the HPLMN only, or additionally the APN in
the domain of the VPLMN.
PDP context Charging Characteristics: The charging characteristics
of this PDP context, for example, normal, prepaid, flat-rate, and/or hot
billing.
Network access mode
Defines if the subscriber has accessed to MSC/VLR and/or to SGSN
5.2.8 MAP SERVICE CNF Service

This service is used by the SGSN to update the location information stored in the
HLR.
Figure 5-9 shows the parameter for the MAP SERVICE CNF service.

5-9
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-9 MAP_SERVICE_CNF
Table 5-3 Parameter for the MAP_SERVICE_CNF service

Parameter
HLR number
Description
In this example, the HLR number is 861390331000.
5.2.9 ATTACH ACCEPT Message

This message is sent by the network to the MS to indicate that the corresponding
attach request has been accepted.

5-10
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table 5-4 Content in the L3 message

IE
Description
Attach result
The purpose of the attach result information element is to specify the result
of a GPRS attach procedure.
Force to standby
The purpose of the force to standby information element is to force the MS

to stop the READY timer in order to prevent the MS to perform cell
updates.
Periodic RA
update timer
In this example, the value of periodic RA update timer is 9 hours.
Radio priority for

SMS
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
identification
In this example, the RAI is 46000311400.
P-TMSI
signature
The purpose of the P-TMSI signature information element is to identify a

GMM context of an MS.

5-11
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
Negotiated
READY timer
value
In this example, the value of negotiated READY timer is 44 seconds.
Allocated
P-TMSI
In this example, the Allocated P-TMSI is 2D0973B4.
5.2.10 ATTACH COMPLETE Message

This message is sent by the MS to the network if a P-TMSI and/or a TMSI was
included within the attach accept message.
5.3 Combined Attach Procedure

5.3.1 Example
Figure 5-12 Combined attach procedure

5-12
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Compared to the GPRS attach procedure, the combined attach procedures involves
two messages including interaction with the VLR. Figure 5-12 shows the two
messages (marked in yellow).
5.3.2 BSSAP+-LOCATION-UPDATE-REQUEST Message

This message is sent by the SGSN to the VLR either to request update of its
location file (normal update) or to request IMSI attach.
Figure 5-13 Message content
Table 5-5 Content in the BSSAP+-LOCATION-UPDATE-REQUEST message

IE
Description
IMSI
In this example, IMSI is 46008123456789
SGSN number
In this example, SGSN number is 861392902018
Update type
The purpose of the GPRS location update type information element is to

indicate to the VLR whether an IMSI attach or a normal location update
has been performed by the MS.
In this example, the update type is an IMSI attach.
New Cell global

identity
In this example, CGI is 460185241000000.
Mobile station
classmark
The purpose of the Mobile Station Classmark 1 information element is

to provide the network with information concerning aspects of high
priority of the mobile station equipment.
Old location area

identifier
In this example, the old LAI is 460185241.

5-13
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
New service area

identification
In this example, New SAI is 4601852410000.
5.3.3 BSSAP+-LOCATION-UPDATE-ACCEPT Message

This message is sent by the VLR to the SGSN to indicate that update or IMSI attach
in the VLR has been completed.
Table 5-6 Figure 5-14 shows the message content.
Figure 5-14 Content in the BSSAP+-LOCATION-UPDATE-ACCEPT message
Table 5-7 Content in the BSSAP+-LOCATION-UPDATE-ACCEPT message

IE
Description
IMSI
In this example, the IMSI is 460081234567895.
location area identifier
In this example, the CGI is 460185241.
TMSI or IMSI
In this example, the TMSI is 50870000.

5-14
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.4 Combined RA/LA Update Procedure

5.4.1 Example
Figure 5-15 shows the messages involved in the combined RA/LA update
procedure.
Figure 5-15 messages involved in the combined RA/LA updating procedure
5.4.2 RA UPDATE REQUEST Message

This message is sent by the MS to the network either to request an update of its
location file or to request an IMSI attach for non-GPRS services.

5-15
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-16 RA UPDATE REQUEST message
Table 5-8 Content in the RA UPDATE REQUEST message

IE
PDP context
status
Description
The purpose of the PDP context status information element is to indicate
the state of each PDP context that can be identified by NSAPI.
0000 sequentially indicates the state of the PDP context identified by the
NSAPI (015).
0: indicates that the SM state of the corresponding PDP context is
PDP-INACTIVE.
1: indicates that the SM state of the corresponding PDP context is not
PDP-INACTIVE.
5.4.3 BSSAP UPDATE LOCATION REQUEST Message


5-16
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-17 BSSAP UPDATE LOCATION REQUEST message
Compared to the message in the combined GPRS/IMSI attach procedure, the

UPDATE TYPE value in the BSSAP UPDATE LOCATION REQUEST message is
NORMAL LOCAITON UPDATE.
5.4.4 BSSAP UPDATE LOCATION ACCEPT Message


5-17
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-18 BSSAP UPDATE LOCATION ACCEPT message
5.4.5 RA ACCEPT Message


5-18
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-19 RA ACCEPT message

5-19
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.5 PDP Context Activation Procedure

5.5.1 Example
Figure 5-20 PDP context activation procedure (3G)
Figure 5-21 PDP context activation procedure (3G) (to be continued)
Figure 5-20 and Figure 5-21 show a PDP context activation procedure.

5-20
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.5.2 SERVICE REQUEST Message

This message is sent by the MS to transfer to establish logical association between
the MS and the network.
Figure 5-22 Service Request

IE
Service type
Description
The purpose of the service type information element is to specify the
purpose of the Service request procedure.
Service type value:
Bits
321
000: Signalling
001: Data
010: Paging Response
5.5.3 ACTIVATE PDP CONTEXT REQUEST Message

This message is sent by the MS to the network to request activation of a PDP
context.

5-21
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-23 ACTIVATE PDP CONTEXT REQUEST message content
Table 5-9 IEs in the ACTIVATE PDP CONTEXT REQUEST message

IE
Requested NSAPI
Description
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.
The value range of NSAPI is 5-15.
Requested LLC
SAPI
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.
Requested QoS
The purpose of the quality of service information element is to specify the

QoS parameters for a PDP context.
Requested PDP
address
The purpose of the packet data protocol address information element is to

identify an address associated with a PDP.
In this example, no PDP address is included in this information element;
and dynamic addressing is applicable.
Access point
name
The purpose of the access point name information element is to identify

the packet data network to which the GPRS user wishes to connect and
to notify the access point of the packet data network that wishes to
connect to the MS.
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.
5.5.4 CREATE PDP CONTEXT REQUEST Message

A Create PDP Context Request shall be sent from a SGSN node to a GGSN node
as a part of the GPRS PDP Context Activation procedure.

5-22
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-24 Content in the CREATE PDP CONTEXT REQUEST message
Table 5-10 Content in the CREATE PDP CONTEXT REQUEST message

IE
Description
Selection mode
The Selection mode information element indicates the origin of the APN in
the message.
Tunnel Endpoint
Identifier Data I
The Tunnel Endpoint Identifier Data I information element contains the

Tunnel Endpoint Identifier for data transmission requested by the receiver
of the flow.
Tunnel Endpoint
Identifier Control
Plane
The Tunnel Endpoint Identifier Control Plane information element contains

the Tunnel Endpoint Identifier for the control plane; it is assigned by the
receiver of the flow. It distinguishes the tunnel from other tunnels between
the same pair of entities.
Charging
Characteristics
The charging characteristics information element is a way of informing both

the SGSN and GGSN of the rules for producing charging information based
on operator configured triggers.
Bits 03 in the first byte of the charging characteristics are described as
follows: charging by hot billing, flat-rate charging, prepaid charging, normal

5-23
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IE
Description
charging.
The other bits may be used by the operator for non-standardized
behaviours.
In this example, the charging characteristic is charging by hot billing.
End User
Address
Supplies protocol specific information of the external packet data network

accessed by the GPRS subscriber
SGSN Address
for signalling
217.164.95.67
SGSN Address
for user traffic
217.164.95.65
5.5.5 CREATE PDP CONTEXT RESPONSE Message

The message shall be sent from a GGSN node to a SGSN node as a response to
the CREATE PDP CONTEXT REQUEST message.
Figure 5-25 Content in the CREATE PDP CONTEXT RESPONSE message

5-24
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table 5-11 Content in the CREATE PDP CONTEXT RESPONSE message

IE
Description
Cause
In a response, the Cause Value indicates the acceptance or rejection of the

corresponding request.
Reordering
required
The Reordering Required information element states whether reordering by

GTP is required or not.
Recovery
Indicates if the peer GSN has restarted.
Charging ID
Identifies all the CDRs produced in SGSN(s) and the GGSN for this PDP
context
End User
Address
The End User Address information element contains the dynamic PDP
Address allocated by the GGSN.
In this example, end user address is 217.165.202.115.
Charging
Gateway
Address
The Charging Gateway Address is the IP address of the recommended

Charging Gateway Functionality to which the SGSN should transfer the
Charging Detail Records (CDR) for this PDP Context.
5.5.6 ACTIVATE PDP CONTEXT ACCEPT Message

This message is sent by the network to the MS to acknowledge activation of a PDP
context.
Figure 5-26 Content in the CREATE PDP CONTEXT ACCEPT message

5-25
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.6 Abnormal Attach Procedure

5.6.1 Overview of Abnormal Attach Procedure
The attach procedure may fail due to many causes. This section describes only
three typical causes. Appendix A lists the meanings of the cause values in detail.
You can refer to them during the failure analysis.
5.6.2 Protocol error, unspecified

I. Example 1
Figure 5-27 Abnormal attach procedure Protocol error, unspecified (1)
Figure 5-27 shows the traced result. After analyzing the PMM_ATTACH_REJ
message, you can see that the gmm cause is "Protocol error unspecified", as shown
in Figure 5-28. Because this cause is not clear, you need to analyze the earlier
messages further. The analysis result shows that the RNC rejects the encryption
request from the SGSN. After analyzing the SECURITY MODE REJECT message,
you can see that the specific cause is "Failure in the radio interface procedure", as
shown in Figure 5-29. Therefore, the attach procedure failure is not due to the cause
at the SGSN but to be defined at the RNC.
Figure 5-28 PMM_ATTACH_REJ message

5-26
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-29 SECURITY MODE REJECT message
II. Example 2
Figure 5-30 shows the messages traced in an abnormal attach procedure.
Figure 5-30 Abnormal attach procedure Protocol error, unspecified (2)
Figure 5-30 shows the traced messages. After analyzing the PMM_ATTACH_REJ
message, you can see that the gmm cause is "Protocol error unspecified", as shown
in Figure 5-31. Further analyze the earlier messages and you can see that the MAP
has received a MAP_P_ABOUT_IND message, indicating that there are errors in
the communications between the lower layer and the HLR. You can locate the
specific failure cause through the SS7 interface trace.

5-27
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-31 ATTACH_REJ message
5.6.3 Illegal MS
Figure 5-32 Illegal MS
Figure 5-32 shows the traced messages. After analyzing the ATTACH_REJ
message, you can see that the reject cause is "Illegal MS", as shown in Figure 5-33.
Analyze the MAP_SERVICE_CNF message and you can see that the cause
returned from the HLR is "Unknown Subscriber", as shown in Figure 5-34. Therefore,
the attach reject cause is that the MS is not registered in the HLR.

5-28
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-33 ATTACH REJECT message
Figure 5-34 MAP_SERVICE_CNF service

5-29
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.6.4 Gs Interface Fault
Figure 5-35 Gs interface fault

5-30
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-36 Gs interface fault (continued)
Figure 5-35 and Figure 5-36 show the abnormal combined attach procedure.
Compared with the normal procedure, the MS in the abnormal procedure
retransmits the ATTACH REQUEST message and there is no response to the
BSSAP UPDATE LOCATION REQ message.
Observe the ATTACH ACCEPT message and you can see that the "attach result" is
"GPRS attach only", as shown in Figure 5-37. This result is not consistent with that
in the "Combined gprs imsi attach" type in the ATTACH REQUEST message, as
shown in Figure 5-38. The "attach result" also carries a cause value "msc
temporarily not reachable". This indicates that the attach procedure fails due to Gs
interface communication failure.

5-31
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-37 Attach accept
Figure 5-38 Attach request
5.7 Abnormal PDP Activation Procedure

5.7.1 Overview of Abnormal PDP Context Activation Procedure
There are many causes for the activation procedure. This section only presents the
analysis of two typical cases through examples. Appendix A lists the meanings of
the cause values in detail. You can refer to them when analyzing the PDP activation
failure.
5-32
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.7.2 Request Service Option not Subscribed

I. Example 1
Figure 5-39 Request Service Option not Subscribed cause
Figure 5-39 shows an abnormal PDP context activation procedure. Analyze the ACT
PDP CONTEXT REJECT message and you can see that the cause is "Request
Service Option not Subscribed", as shown in Figure 5-40.
Figure 5-40 ACT PDP CONTEXT REJECT cause
Compare the subscription data (shown in Figure 5-41) inserted in the SGSN by the
HLR and that requested by the MS (shown in Figure 5-42). The comparison result
shows that the subscribed data contains a dynamic PDP address while the
requested data contains a PDP static address. The inconsistency in the PDP
addresses leads to the activation reject.

5-33
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-41 Subscription data
Figure 5-42 Requested data

5-34
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

II. Example 2
Figure 5-43 ACT PDP CONTEXT REJECT message
Figure 5-43 shows another abnormal PDP context activation procedure. Analyze the
ACT PDP CONTEXT REJECT message and you can see that the cause is
"Request Service Option not Subscribed", as shown in Figure 5-44.
Figure 5-44 ACT PDP CONTEXT REJECT message
Compare the subscription data (shown in Figure 5-45) inserted in the SGSN by the
HLR and that requested by the MS (as shown in Figure 5-46). The comparison
result shows that the APN in the subscription data is not consistent with that
requested by the MS. This inconsistency leads to the activation reject.

5-35
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Figure 5-45 Subscription data
Figure 5-46 Requested data

5-36
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

5.7.3 Activate Rejected by GGSN
Figure 5-47 Activate Rejected by GGSN
Figure 5-47 shows a third abnormal PDP context activation procedure. Analyze the
ACT PDP CONTEXT REJECT message and you can see the cause is "Activate
Rejected by GGSN", as shown in Figure 5-48. Observe the PDP context activation
procedure
and
you
can
see
there
is
not
response
to
two
MT_CREATE_PDP_CONTEXT_REQ messages. Therefore, the activation is

rejected because the IP route to the destination GGSN is not reachable.
Figure 5-48 ACT PDP CONTEXT REJECT

5-37
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
Table of Contents
Appendix A UMTS Specific Cause Values for Mobility Management ......................................A-1
A.1 Causes related to MS identification...................................................................................A-1
A.1.1 Cause value = 2 IMSI unknown in HLR..................................................................A-1
A.1.2 Cause value = 3 Illegal MS .....................................................................................A-1
A.1.3 Cause value = 4 IMSI unknown in VLR ..................................................................A-1
A.1.4 Cause value = 5 IMEI not accepted........................................................................A-1
A.1.5 Cause value = 6 Illegal ME .....................................................................................A-2
A.2 Cause related to subscription options ...............................................................................A-2
A.2.1 Cause value = 11 PLMN not allowed .....................................................................A-2
A.2.2 Cause value = 12 Location Area not allowed .........................................................A-2
A.2.3 Cause value = 13 Roaming not allowed in this location area.................................A-2
A.2.4 Cause value = 15 No Suitable Cells In Location Area............................................A-2
A.3 Causes related to PLMN specific network failures and congestion/Authentication
Failures ....................................................................................................................................A-2
A.3.1 Cause value = 20 MAC failure................................................................................A-2
A.3.2 Cause value = 21 Synch failure..............................................................................A-3
A.3.3 Cause value = 17 Network failure...........................................................................A-3
A.3.4 Cause value = 22 Congestion ................................................................................A-3
A.3.5 Cause value = 23 GSM authentication unacceptable ............................................A-3
A.4 Causes related to nature of request ..................................................................................A-3
A.4.1 Cause value = 32 Service option not supported.....................................................A-3
A.4.2 Cause value = 33 Requested service option not subscribed .................................A-3
A.4.3 Cause value = 34 Service option temporarily out of order .....................................A-3
A.4.4 Cause value = 38 Call cannot be identified ............................................................A-4
A.5 Additional cause codes for GMM ......................................................................................A-4
A.5.1 Cause value = 7 GPRS services not allowed .........................................................A-4
A.5.2 Cause value = 8 GPRS services and non-GPRS services not allowed .................A-4
A.5.3 Cause value = 9 MS identity cannot be derived by the network.............................A-4
A.5.4 Cause value = 10 Implicitly detached .....................................................................A-4
A.5.5 Cause value = 14 GPRS services not allowed in this PLMN .................................A-4
A.5.6 Cause value = 16 MSC temporarily not reachable.................................................A-4
A.5.7 Cause value = 40 No PDP context activated..........................................................A-5
Appendix B GPRS Specific Cause Values for Session Management ......................................B-1
B.1 Causes related to nature of request ..................................................................................B-1
B.1.1 Cause value = 8 Operator Determined Barring ......................................................B-1
B.1.2 Cause value = 25 LLC or SNDCP failure (GSM only) ............................................B-1
B.1.3 Cause value = 26 Insufficient resources.................................................................B-1
i
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Table of Contents
B.1.4 Cause value = 27 Unknown or missing access point name ...................................B-1

B.1.5 Cause value = 28 Unknown PDP address or PDP type.........................................B-1
B.1.6 Cause value = 29 User authentication failed ..........................................................B-2
B.1.7 Cause value = 30 Activation rejected by GGSN.....................................................B-2
B.1.8 Cause value = 31 Activation rejected, unspecified.................................................B-2
B.1.9 Cause value = 32 Service option not supported.....................................................B-2
B.1.10 Cause value = 33 Requested service option not subscribed ...............................B-2
B.1.11 Cause value = 34 Service option temporarily out of order ...................................B-2
B.1.12 Cause value = 35 NSAPI already used ................................................................B-2
B.1.13 Cause value = 36 Regular PDP context deactivation...........................................B-3
B.1.14 Cause value = 37 QoS not accepted....................................................................B-3
B.1.15 Cause value = 38 Network failure.........................................................................B-3
B.1.16 Cause value = 39 Reactivation requested............................................................B-3
B.1.17 Cause value = 40 Feature not supported .............................................................B-3
B.1.18 Cause value = 41 semantic error in the TFT operation. .......................................B-3
B.1.19 Cause value = 42 syntactical error in the TFT operation......................................B-3
B.1.20 Cause value = 43 unknown PDP context .............................................................B-3
B.1.21 Cause value = 44 semantic errors in packet filter(s) ............................................B-4
B.1.22 Cause value = 45 syntactical error in packet filter(s)............................................B-4
B.1.23 Cause value = 46 PDP context without TFT already activated ............................B-4
Appendix C Acronyms and Abbreviations .................................................................................C-1

ii
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Appendix A UMTS Specific Cause Values for Mobility

Management
Appendix A UMTS Specific Cause Values for

Mobility Management
This annex describes the cause values for the mobility management procedures for
non-GPRS services (MM) and GPRS services (GMM). Clauses G1 to G5 are valid
for both MM and GMM. However, the following codes are applicable for non-GPRS
services only:
#38 Call cannot be identified
Clause G.6 applies only for GMM procedures.
A.1 Causes related to MS identification

A.1.1 Cause value = 2 IMSI unknown in HLR
This cause is sent to the MS if the MS is not known (registered) in the HLR. This
cause code does not affect operation of the GPRS service, although is may be used
by a GMM procedure.
A.1.2 Cause value = 3 Illegal MS

This cause is sent to the MS when the network refuses service to the MS either
because an identity of the MS is not acceptable to the network or because the MS
does not pass the authentication check, i.e. the SRES received from the MS is
different from that generated by the network. When used by an MM procedure,
except the authentication procedure, this cause does not affect operation of the
GPRS service.
A.1.3 Cause value = 4 IMSI unknown in VLR

This cause is sent to the MS when the given IMSI is not known at the VLR.
A.1.4 Cause value = 5 IMEI not accepted

This cause is sent to the MS if the network does not accept emergency call
establishment using an IMEI.

A-1
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
A.1.5 Cause value = 6 Illegal ME

This cause is sent to the MS if the ME used is not acceptable to the network, e.g.
blacklisted. When used by an MM procedure, this cause does not affect operation of
the GPRS service.
A.2 Cause related to subscription options

A.2.1 Cause value = 11 PLMN not allowed
This cause is sent to the MS if it requests location updating in a PLMN where the
MS, by subscription or due to operator determined barring is not allowed to operate.
A.2.2 Cause value = 12 Location Area not allowed

This cause is sent to the MS if it requests location updating in a location area where
the MS, by subscription, is not allowed to operate.
A.2.3 Cause value = 13 Roaming not allowed in this location area

This cause is sent to an MS which requests location updating in a location area of a
PLMN which offers roaming to that MS in that Location Area, by subscription.
A.2.4 Cause value = 15 No Suitable Cells In Location Area

This cause is sent to the MS if it requests location updating in a location area where
the MS, by subscription, is not allowed to operate, but when it should find another
allowed location area in the same PLMN.
NOTE:
Cause #15 and cause #12 differ in the fact that cause #12 does not
trigger the MS to search for another allowed location area on the same PLMN.
A.3 Causes related to PLMN specific network failures and

congestion/Authentication Failures
A.3.1 Cause value = 20 MAC failure
This cause is sent to the network if the SIM detects that the MAC in the
authentication request message is not fresh (see 3GPP TS 33.102).

A-2
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
A.3.2 Cause value = 21 Synch failure

This cause is sent to the network if the SIM detects that the SQN in the
authentication request message is out of range (see 3GPP TS 33.102).
A.3.3 Cause value = 17 Network failure

This cause is sent to the MS if the MSC cannot service an MS generated request
because of PLMN failures, e.g. problems in MAP.
A.3.4 Cause value = 22 Congestion

This cause is sent if the service request cannot be actioned because of congestion
(e.g. no channel, facility busy/congested etc.).
A.3.5 Cause value = 23 GSM authentication unacceptable

This cause is sent to the network in UMTS if the MS supports the UMTS
authentication algorithm and there is no Authentication Parameter AUTN IE present
in the AUTHENTICATION REQUEST message.
A.4 Causes related to nature of request

A.4.1 Cause value = 32 Service option not supported
This cause is sent when the MS requests a service/facility in the CM SERVICE
REQUEST message which is not supported by the PLMN.
A.4.2 Cause value = 33 Requested service option not subscribed

This cause is sent when the MS requests a service option for which it has no
subscription.
A.4.3 Cause value = 34 Service option temporarily out of order

This cause is sent when the MSC cannot service the request because of temporary
outage of one or more functions required for supporting the service.

A-3
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
A.4.4 Cause value = 38 Call cannot be identified

This cause is sent when the network cannot identify the call associated with a call
re-establishment request.
A.5 Additional cause codes for GMM

A.5.1 Cause value = 7 GPRS services not allowed
This cause is sent to the MS if it requests an IMSI attach for GPRS services, but is
not allowed to operate GPRS services.
A.5.2 Cause value = 8 GPRS services and non-GPRS services not allowed
This cause is sent to the MS if it requests a combined IMSI attach for GPRS and
non-GPRS services, but is not allowed to operate either of them.
A.5.3 Cause value = 9 MS identity cannot be derived by the network

This cause is sent to the MS when the network cannot derive the MS's identity from
the P-TMSI in case of inter-SGSN routing area update.
A.5.4 Cause value = 10 Implicitly detached

This cause is sent to the MS either if the network has implicitly detached the MS, e.g.
some while after the Mobile reachable timer has expired, or if the GMM context data
related to the subscription dose not exist in the SGSN e.g. because of a SGSN
restart.
A.5.5 Cause value = 14 GPRS services not allowed in this PLMN

This cause is sent to the MS which requests GPRS service in a PLMN which does
not offer roaming for GPRS services to that MS.
A.5.6 Cause value = 16 MSC temporarily not reachable

This cause is sent to the MS if it requests a combined GPRS attach or routing are
updating in a PLMN where the MSC is temporarily not reachable via the GPRS part
of the GSM network.

A-4
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
A.5.7 Cause value = 40 No PDP context activated

This cause is sent to the MS if the MS requests an establishment of the radio
access bearers for all active PDP contexts by sending a SERVICE REQUEST
message indicating "data" to the network, but the SGSN does not have any active
PDP context(s).

A-5
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Appendix B GPRS Specific Cause Values for Session

Management
Appendix B GPRS Specific Cause Values for

Session Management
B.1 Causes related to nature of request
B.1.1 Cause value = 8 Operator Determined Barring
This cause code is used by the network to indicate that the requested service was
rejected by the SGSN due to Operator Determined Barring.
B.1.2 Cause value = 25 LLC or SNDCP failure (GSM only)

This cause code is used by the MS indicate that a PDP context is deactivated
because
of
LLC
or
SNDCP
failure
(e.g.
if
the
SM
receives
SNSM-STATUS.request message with cause "DM received " or " invalid XID
response ", see 3GPP TS 44.065 [78])
B.1.3 Cause value = 26 Insufficient resources

This cause code is used by the MS or by the network to indicate that a PDP context
activation request, secondary PDP context activation request or PDP context
modification request cannot be accepted due to insufficient resources.
B.1.4 Cause value = 27 Unknown or missing access point name

rejected by the external packet data network because the access point name was
not included although required or if the access point name could not be resolved.
B.1.5 Cause value = 28 Unknown PDP address or PDP type

rejected by the external packet data network because the PDP address or type
could not be recognised.

B-1
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
B.1.6 Cause value = 29 User authentication failed

rejected by the external packet data network due to a failed user authentication.
B.1.7 Cause value = 30 Activation rejected by GGSN

rejected by the GGSN.
B.1.8 Cause value = 31 Activation rejected, unspecified

rejected due to unspecified reasons.
B.1.9 Cause value = 32 Service option not supported

This cause code is used by the network when the MS requests a service which is
not supported by the PLMN.
B.1.10 Cause value = 33 Requested service option not subscribed

This cause is sent when the MS requests a service option for which it has no
subscription.
B.1.11 Cause value = 34 Service option temporarily out of order

This cause is sent when the MSC cannot service the request because of temporary
outage of one or more functions required for supporting the service.
B.1.12 Cause value = 35 NSAPI already used

This cause code may be used by a network to indicate that the NSAPI requested by
the MS in the PDP context activation request is already used by another active PDP
context of this MS.
Never to be sent, but can be received from a R97/R98 network at PDP context
activation

B-2
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
B.1.13 Cause value = 36 Regular PDP context deactivation

This cause code is used to indicate a regular MS or network initiated PDP context
deactivation.
B.1.14 Cause value = 37 QoS not accepted

This cause code is used by the MS if the new QoS cannot be accepted that were
indicated by the network in the PDP Context Modification procedure.
B.1.15 Cause value = 38 Network failure

This cause code is used by the network to indicate that the PDP context
deactivation is caused by an error situation in the network.
B.1.16 Cause value = 39 Reactivation requested

This cause code is used by the network to request a PDP context reactivation after
a GGSN restart.
B.1.17 Cause value = 40 Feature not supported

This cause code is used by the MS to indicate that the PDP context activation
initiated by the network is not supported by the MS.
B.1.18 Cause value = 41 semantic error in the TFT operation.

This cause code is used by the network to indicate that the there is a semantic error
in the TFT operation included in a secondary PDP context activation request or an
MS-initiated PDP context modification.
B.1.19 Cause value = 42 syntactical error in the TFT operation.

This cause code is used by the network to indicate that there is a syntactical error in
the TFT operation included in a secondary PDP context activation request or an
MS-initiated PDP context modification.
B.1.20 Cause value = 43 unknown PDP context

This cause code is used by the network to indicate that the PDP context identified
by the Linked TI IE the secondary PDP context activation request is not active.

B-3
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


Management
B.1.21 Cause value = 44 semantic errors in packet filter(s)

This cause code is used by the network to indicate that there is one or more
semantic errors in packet filter(s) of the TFT included in a secondary PDP context
activation request or an MS-initiated PDP context modification.
B.1.22 Cause value = 45 syntactical error in packet filter(s)

This cause code is used by the network to indicate that there is one or more
syntactical errors in packet filter(s) of the TFT included in a secondary PDP context
activation request or an MS-initiated PDP context modification.
B.1.23 Cause value = 46 PDP context without TFT already activated

This cause code is used by the network to indicate that the network has already
activated a PDP context without TFT.

B-4
.d o
.c
m
o
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k


3
3GPP
3rd Generation Partnership Project
A
AAL5
ATM Adaptation Layer 5
ADMF
Administration Function
ANSI
American National Standards Institute
APN
Access Point Name
ATM
Asynchronous Transfer Mode
AUC
Authentication Center
B
BC
Bearer Channel
BER
Bit Error Ratio
BITS
Building Integrated Timing Supply system
BNET
Broadband Network subrack
BSC
Base Station Controller
BSS
Base Station Subsystem
BSSAP
Base Station Subsystem Application Part
BSSGP
Base Station System Application GPRS Protocol
BVC
BSSGP Virtual Connection
C
CAMEL
Customized Applications for Mobile network Enhanced Logic
CAP
CAMEL Application Part
CC
Content of Communication
CDR
Call Detail Record
CG
Charging Gateway
CGF
Charging Gateway Functionality
CGI
Cell Global Identification
CN
Core Network
CPU
Central Processing Unit
CRC
Cyclic Redundancy Code

C-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

D
DF
Delivery Function
DHCP
Dynamic Host Configuration Protocol
DLCI
Data Link Control Identifier
DNS
Domain Name Server
DPC
Destination Point Code
DTE
Data Terminal Equipment
E
EIR
Equipment Identification Register
ESP
Encapsulating Security Payload
ETSI
European Telecommunications Standards Institute
F
FA
Foreign Agent
FE
Fast Ethernet
FR
Frame Relay
FTP
File Transfer Protocol
G
GE
Gigabit Ethernet
GGSN
Gateway GPRS Support Node
GMLC
Gateway Mobile Location Center
GMM
GPRS Mobility Management
GPRS
General Packet Radio Service
GSM
Global System for Mobile Communications
GSN
GPRS Support Node
GTP
GPRS Tunneling Protocol
GTP-C
Control plane part of GPRS tunneling protocol
GTP-U
User plane part of GPRS tunneling protocol
GUI
Graphic User Interface
H
HLR
Home Location Register
HPLMN
Home PLMN
I
ICMP
Internet Control Message Protocol
IETF
Internet Engineering Task Force

C-2
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

IMEI
International Mobile Equipment Identity
IMSI
International Mobile Subscriber Identity
INAP
Intelligent Network Application Protocol
IP
Internet Protocol
IPoA
IP over ATM
IPX
Internet Packet Exchange
IRI
Intercept Related Information
ITEF
Internet Engineering Task Force
ITU-T
International Telecommunication Union - Telecommunication Standardization

Sector
L
LAC
Location Area Code
LCS
Location Services
LEA
Law Enforcement Agency
LLC
Logical Link Control
LMT
Local Maintenance Terminal
M
MAC
Media Access Control
MAP
Mobile Application Part
MCC
Mobile Country Code
MIP
Mobile IP
MM
Mobility Management
MML
Man Machine Language
MNC
Mobile Network Code
MO
Mobile Origination
MS
Mobile Station
MSC
Mobile Service Switching Center
MSISDN
Mobile Station International ISDN Number
MT
Mobile Termination
MTP3
Message Transfer Part Layer 3
MTP3B
Message transfer part (broadband)
N
NS
Network Service
NSAPI
Network layer Service Access Point Identifier

C-3
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

NSEI
Network Service Entity Identifier
NTP
Network Time Protocol
O
ODB
Operator Determined Barring
OPC
Originating Point Code
P
PCM
Pulse Code Modulation
PCU
Packet Control Unit
PDN
Public Data Network
PDP
Packet data protocol
PDU
Protocol Data Unit
PFC
Packet Flow Context
PFS
Perfect Forward Secrecy
PLMN
Public Land Mobile Network
PMC
PCI Mezzanine Card
PMM
Packet Mobility Management
POS
Packet Over SDH
PPP
Point-to-Point Protocol
PS
Packet Switched
PSM
Packet Service Module subrack
PTM
Point To Multipoint
P-TMSI
Packet-TMSI
PTP
Point To Point
PVC
Permanent Virtual Connection
PVP
Permanent Virtual Path
Q
QoS
Quality of Service
R
RAB
Radio Access Bearer
RAC
Routing Area Code
RAI
Routing Area Identifier
RANAP
Radio Access Network Application Part
RAU
Routing Area Update
RLC
Radio Link Control

C-4
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

RNC
Radio Network Controller
S
SAAL
Signaling ATM Adaptation Layer
SAC
Service Area Code
SCCP
Signaling Connection Control Part
SCMG
SCCP Management
SCP
Service Control Point
SDH
Synchronous Digital Hierarchy
SGSN
Serving GPRS Support Node
SIG
Signaling functional entity
SLC
Signaling Link Code
SLS
Signaling Link Selection
SM
Session Management
SME
Short Message Entity
SMMO
Short Message Mobile Originated
SMMT
Short Message Mobile Terminated
SM-SC
Short Message Service Center
SMS-GMSC
Short Message Service Gateway MSC
SMS-IWMSC
Short Message Service Interworking MSC
SNDCP
SubNetwork Dependent Convergence Protocol
SNMP
Simple Network Management Protocol
SS7
Signalling System No.7
SSN
Sub-System Number
STP
Signaling Transfer Point
T
TCAP
Transaction Capabilities Application Part
TCP
Transmission Control Protocol
TEID
Tunnel End ID
U
UDP
User Datagram Protocol
UE
User Equipment
UTRAN
UMTS Terrestrial Radio Access Network
V
VLR
Visitor Location Register

C-5
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

VMSC
Visited Mobile Switching Center
VPI
Virtual Path Identifier
VPN
Virtual Private Network
W
WCDMA
Wideband Code Division Multiple Access

C-6
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Index
Index
Ga interface protocol architecture, 2-28
Gb interface, 2-2
abnormal attach procedure, 5-26
BSSGP, 2-18
Gs interface fault, 5-30
Logical Link Control (LLC), 2-19
Illegal MS, 5-28
Network Service (NS), 2-14
protocol error, unspecified, 5-26
SNDCP, 2-24
abnormal PDP activation procedure, 5-32
Gb interface definition, 2-13
activate rejected by GGSN, 5-37
Gb interface protocol architecture, 2-13
request service option not subscribe, 5-33
Gd interface, 2-3
aditional cause code for GMM, A-4
Ge interface definition, 2-36

Ge interface function, 2-36
Ge interface protocol structure, 2-37
classmark handling, 3-66
GMM/SM signalling confidentiality, 3-19
MS Network capability, 3-66
Gn/Gp interface definition, 2-27
radio access, 3-66
Gn/Gp interface function, 2-27

Gn/Gp interface protocol architecture, 2-27
combine attach message type

BSSAP+-LOCATION-UPDATE-ACCEPT, 5-14
Gn/Gp/Ga interface, 2-3
BSSAP+-LOCATION-UPDATE-REQUEST,
GPRS attach function, 3-8
5-13
GPRS attach message type
combine GPRS/IMSI attach procedure, 3-9
ATTACH ACCEP, 5-10
combine RA/LA update procedure, 5-14
ATTACH ACCEPLETE, 5-12
combined attach procedure, 5-12
ATTACH REQUEST, 5-2
combined RA/LA update message type
AUTHENTICATION AND CIPHERING
BSSAP UPDATE LOCATION ACCEPT, 5-17
REQUEST, 5-5
BSSAP UPDATE LOCATION REQUEST, 5-16
AUTHENTICATION AND CIPHERING
RA ACCEPT, 5-18
RESPONSE, 5-6
GPRS attach procedure, 5-1
RA UPDATE REQUEST, 5-15
GPRS attach service type
congestion/Authentication failures cause relate,
MAP SERVICE CNF, 5-9
A-2
MAP_OPEN_REQ, 5-6
MAP_SERVICE_IND, 5-8
detach function, 3-12
MAP_SERVICE_REQ, 5-7
Gr interface, 2-3
dynamic PDP addresse, 4-3
Gs interface, 2-3
Gs interface protocol architecture, 2-36

GSM authentication, 3-17
Ga interface definition, 2-28
GSM CS paging, 3-6
Ga interface function, 2-28
GSM GPRS attach procedure, 3-8

i-1
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Index
GSM location management procedure, 3-21
timer, 3-4
GSM-to-UMTS inter SGSN change, 3-62
UMTS-GSM intersystem change, 3-51

mobility management state
GSM-to-UMTS intra SGSN change, 3-54
GSM, 3-1
UMTS, 3-2
identity check procedure, 3-20
mobility management timer function, 3-4
inter SGSN intersystem change, 3-57
mobility management UMTS specific cause value,
GSM-to-UMTS, 3-62
A-1
UMTS-to-GSM, 3-57
MS identification cause relate, A-1

2 IMSI unknown in HLR, A-1
interface introduction
Gb interface, 2-2
3 Illegal MS, A-1
Gd interface, 2-3
4 IMSI unknown in VLR, A-1
Gn/Gp/Ga interface, 2-3
5 IMEI not accepted, A-1
Gr interface, 2-3
6 Illegal ME, A-2
Gs interface, 2-3
MS information procedure, 3-7
Iu interface, 2-2
MS-Initiated detach procedure, 3-12

MS-Initiated service request procedure, 3-47
intra SGSN intersystem change, 3-51

GSM-to-UMTS, 3-54
UMTS-to-GSM, 3-51
Iu interface, 2-2, 2-3
nature of request cause relate, A-3
Iu interface definition, 2-4
Network-Initiated detach procedure, 3-14
Iu interface function, 2-4
HLR-initiated, 3-15
Iu interface protocol architecture, 2-5
SGSN-initiated, 3-14
Network-Initiated service request procedure, 3-49
Non-GPRS alert, 3-7
location management function, 3-20
P
M
packet data protocol definition, 4-1
Map interface definition, 2-30
packet data protocol state
Map interface function, 2-30
ACTIVE, 4-2
Map interface protocol structure, 2-34
INACTIVE, 4-1
PDP Activation message type
MM information procedure, 3-8

mobile reachable timer function, 3-5
ACTIVATE PDP CONTEXT ACCEPT, 5-25
mobility management definition, 3-1
ACTIVATE PDP CONTEXT REQUEST, 5-21
mobility management function, 3-1
CREATE PDP CONTEXT REQUEST, 5-22
classmark handling, 3-66
CREATE PDP CONTEXT RESPONSE, 5-24
detach, 3-12
SERVICE REQUEST, 5-21
GPRS attach, 3-8
PDP context activation, 4-3
location management, 3-20
PDP context activation procedure, 4-4, 5-20
purge, 3-16
PDP context deactivation, 4-3
security function, 3-16
PDP context deactivation procedure, 4-12
subscriber, 3-46
PDP context modification, 4-3

i-2
.d o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c
F -T O O L S
F -T O O L S
W
N
O
y
bu
to
k
lic
c u -tr a c k

Index
PDP context modification procedure, 4-8
11 PLMN not allowed11 PLMN not allowed, A-2
PDP context preservation, 4-3
12 Location Area not allowed, A-2
PDP context preservation procedure, 4-14
13 Roaming not allowed in this location area,
periodic RA update timer function, 3-4
A-2
periodic RA/LA update, 3-45
15 No Suitable Cells In Location Area, A-2
PLMN specific network failures cause relate, A-2

protocol interface, 2-1
purge function, 3-16
the SGSN-MSC/VLR sssociation administration,

3-5
timer function
RABs Re-establishment procedure, 4-14
mobile reachable, 3-5
READY timer function
periodic RA update, 3-4
GSM, 3-4
typical signaling analysis, 5-1
reference protocol, 1-1
U
S
UMTS CS paging, 3-7
security function, 3-16
UMTS data integrity procedure, 3-20
session management function, 4-1
UMTS location management procedure, 3-29
SGSN9810 system interface, 2-1
UMTS service request procedure, 3-47
signaling trace tool use, 1-1
UMTS-GSM intersystem change, 3-51
Static PDP addresse, 4-3
UMTS-to-GSM inter SGSN change, 3-57
subscriber management function, 3-46
UMTS-to-GSM intra SGSN change, 3-51
subscriber management procedure, 3-46
user data, 3-19
subscription option cause relate, A-2
user identity confidentiality, 3-18
i.

i-3
.d o
m
o
.c
.d o
lic
to
bu
N
O
PD
PD
c u -tr a c k
.c

HWI - Protocol and Signaling Analysis

Uploaded by

Copyright:

Available Formats

HWI - Protocol and Signaling Analysis

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

HWI - Protocol and Signaling Analysis

Uploaded by

Copyright:

Available Formats

What are the main interfaces and protocols discussed in the document?

What are the main interfaces and protocols discussed in the document?

What are the main mobility management functions described?

What are the main mobility management functions described?

F -T O O L S

HUAWEI UMTS Packet-Switched Core Network

Huawei Technologies Proprietary

HUAWEI UMTS Packet-Switched Core Network

Huawei Technologies Co., Ltd.

Huawei Technologies Proprietary

Copyright Huawei Technologies Co., Ltd. 2006. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co.,

Huawei Technologies Proprietary

Huawei Technologies Proprietary

About This Manual

Huawei Technologies Proprietary

Normal paragraphs are in Arial.

Warnings, cautions, notes and tips are in Arial Narrow.

Headings, Command, Command Description are in boldface.

Huawei Technologies Proprietary

Protocols and Signaling Analysis

Protocols and Signaling Analysis

3.3.6 MS Information Procedure ...................................................................................... 3-7

Protocols and Signaling Analysis

5.2 GPRS Attach Procedure.................................................................................................... 5-1

Huawei Technologies Proprietary

Protocols and Signaling Analysis

A.1.4 Cause value = 5 IMEI not accepted........................................................................A-1

Huawei Technologies Proprietary

Protocols and Signaling Analysis

B.1.15 Cause value = 38 Network failure.........................................................................B-3

Huawei Technologies Proprietary

Protocols and Signaling Analysis

Huawei Technologies Proprietary

Protocols and Signaling Analysis

Chapter 1 Overview of Interfaces and Protocols

Chapter 1 Overview of Interfaces and Protocols

1.2 Use of Signaling Trace Tools

1.3 Protocols for Reference

General Packet Radio Service (GPRS) Service description;

Mobile Radio Interface Layer 3 specification; Core Network

Mobile Application Part (MAP)

Serving GPRS Support Mode SGSN - Visitors Location Register

(VLR); Gs Interface Layer 3 Specification

GPRS Tunnelling protocol (GTP) across the Gn and Gp

3G Charging call event data

Huawei Technologies Proprietary

Protocols and Signaling Analysis

Huawei Technologies Proprietary

Protocols and Signaling Analysis

Chapter 2 Protocol Interfaces

Chapter 2 Protocol Interfaces

2.1.1 System Interfaces

AUC: Authentication Center

BSS: GSM Base station Subsystem

Figure 2-1 SGSN9810 system interfaces

Huawei Technologies Proprietary