HWI_Protocol and Signaling Analysis

7/24/2019 HWI_Protocol and Signaling Analysis

http://slidepdf.com/reader/full/hwiprotocol-and-signaling-analysis 1/197

Huawei Technologies Proprietary

HUAWEI

HUAWEI UMTS Packet-Switched Core Network

Protocols and Signaling Analysis

V800R003

http://www.docu-track.com/buy/





HUAWEI UMTS Packet-Switched Core Network

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: [email protected]

http://www.huawei.com/



http://www.huawei.com/




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 documentdo not constitute the warranty of any kind, express or implied.






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 Notes

T2-030255-20041020-C-8.30 Initial commercial release






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:






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.





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network 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






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






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






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






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





Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network 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





Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network 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






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





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network Chapter 2 Protocol Interfaces

Chapter 2 Protocol Interfaces

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 thesubsequent chapters.

2.1.1 System Interfaces

The standard interfaces of SGSN9810 are shown in Figure 2-1.

BSS UTRAN

CN

A Iu-PS

MSC

SGSN

GGSN

Gn

E

HLR/AuC

cap cap

Iu-CSGb

VLR

Gp

VLR G

MSC

PSTN

CGFGa

SMSC

C/D

E Gd

scp

PRA

Gs

B B

ISDNPSTN PDN

Other PLMN

GSN

Gi

Gr

AUC: Authentication Center BSS: GSM Base station SubsystemISDN: Integrated Service Digital Network HLR: Home Location RegisterSCP: Service Control Point MSC: Mobile Switching CenterCN: Core Network SGSN: Serving GPRS Support NodeVLR: Visitor Location Register PSTN: Public Switched Telephone NetworkGGSN: Gateway GPRS Support Node CGF: (PS) Charging Gateway Functionality (entity)SMSC: Short Message Service Center UTRAN: UMTS Terrestrial Radio Access NetworkPDN: Packet Data Network

Figure 2-1 SGSN9810 system interfaces


2-1






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






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 encapsulatedin 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






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

Core Network (CN)UTRAN

Node B

Node B

Node B

Node B

RNC

Iu Interface

“Iu-BC”

“Iu-CS”

BC

Domain

CS

Domain

PS

Domain

“Iu-PS”

RNC

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






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

I. Universal protocol model of the UTRAN interface

Figure 2-3 illustrates the overall architecture of UTRAN.

RNS

RNC

RNS

RNC

Core Network

Node B Node B Node B Node B

Iu Iu

Iur

Iub IubIub Iub

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






Application

Protocol

Data

Stream(s)

ALCAP(s)

TransportNetwork

Layer

Physical Layer

SignalingBearer(s)

Transport Network

User Plane

Control Plane User Plane

Transport Network

User Plane

Transport Network

Control Plane

RadioNetwork

Layer

Signaling

Bearer(s)Data

Bearer(s)

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






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 controlleddirectly 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






25.413 25.415

Transport

Network

Layer

25.411

TransportUser

Network Plane


TransportUser

Network Plane

Transport Network Control Plane

Radio

Network

Layer

25.412 25.414

25.411: UTRAN Iu Interface Layer125.412: UTRAN Iu Interface Signaling Transport25.413: UTRAN Iu Interface RANAP Signaling25.414: UTRAN Iu Interface Data Transport & Transport Signaling25.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






SSCF-NNI

SSCOP

AAL5

IP

SCTP

SCCP

SSCF-NNI

MTP3-B

M3UA

RANAPIu UP Protocol

Layer

Transport

Network

Layer

Physical Layer

Transport

User

Network

Plane


Transport

User

Network

PlaneTransport Network

Control Plane

Radio

Network

Layer

ATM

AAL5

IP

UDP

GTP-U

Physical Layer

ATM

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






SSCF-NNI

SSCOP

AAL5

SCCP

SSCF-NNI

MTP3-B

RANAP

Iu UP Protocol

Layer

Transport Network

Layer

Physical Layer

Transport

User

Network

Plane


Transport

User

Network

PlaneTransport Network

Control Plane

Radio

Network

Layer

ATM

AAL5

IP

UDP

GTP-U

Physical Layer

ATM

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






SCCP-SAP

RANAP

Control Plane

MTP3-B

SCCP

SAAL-NNI AAL5

ATM

M3UA

SCTP

IP

25.413

25.412

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.

SCCP-SAP

RANAP

Control Plane

MTP3-B

SCCP

SAAL-NNI

ATM

Figure 2-9 Protocol architecture of SGSN9810 Iu interface control plane


2-11






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 exchangemechanism 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






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.

Relay

Network

Service

GTP-U

Application

IP

SNDCP

LLC

RLC

MAC

GSM RF

SNDCP

LLC

BSSGP

L1bis

RLC

MAC

GSM RF

BSSGP

L1bis

Relay

L2

L1

IP

L2

L1

IP

GTP-U

IP

Um Gb Gn GiMS BSS SGSN GGSN

Network

Service

UDPUDP

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






BSSGP

Relay

GMM/SM

LLC

RLC

MAC

GSM RF

GMM/SM

LLC

BSSGP

L1bis

Um GbMS BSS 2G-SGSN

Network

Service

RLC

MAC

GSM RF L1bis

Network

Service

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.

Sub-Network Service /

Sub-Network Service protocol

Network Service Control /

Network Service Control protocol

Network Service

Figure 2-12 NS internal architecture


2-14






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.

SGSN

(network)

BSS

(user)

Gb

Figure 2-13 Gb interface P2P frame relay mode

BSS

(user)

SGSN

(user)

Frame Relay

network

Gb Gb

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






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 datatransmission 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






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

bearer chan. = 1

bearer chan. = 2

bearer chan. = 3

bearer chan. = 4

DLCI=98

DLCI=21

DLCI=302

DLCI=16

DLCI=511

NS-VCI=a

NS-VCI=b

NS-VCI=c

NS-VCI=e

NS-VCI=f

NS-VCI=c

NS-VCI=d

NS-VCI=f

BVCI=VII

BVCI=VII

BVCI=IV

PTP,

cell 1

PTP,

cell 2

PTP,

cell 3

signalling

signalling

SGSNBSS#1

BSS#2

DLCI=17

NS-VCI=a

NS-VCI=b

NS-VCI=d

NS-VCI=e

BVCI=I

BVCI=II

BVCI=III

BVCI=IV

BVCI=V

BVCI=VI

PTM

BVCI=III

BVCI=II

BVCI=I

PTM BVCI=VI

BVCI=V

Figure 2-15 Gb interface (P2P frame relay connection)


2-17






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 anexisting 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






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.

Network Service

BSSGP

LLC

BSSGP

GMM

GMM

PFM

PFM

NM

NM

GSM 08.16

Service model in an SGSN

Network Service

BSSGP

GMM NMRELAY

GSM 03.64 GMM

PFM

PFM NM

GSM 08.16

Service model in an BSS

RL

RLC/MAC

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






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






Logical

Link

Entity

SAPI=7

Logical

Link

Entity

SAPI=8

SGSNMS

GPRS Mobility Management

Logical

Link

Management

Entity

Multiplex Procedure

LL5 LL9LL3 LL11

SNDCP

LLGMM

SMS

Logical

Link

Entity

SAPI=2

RLC/MAC

Logical

Link

Entity

SAPI=11

Logical

Link

Entity

SAPI=9

Logical

Link

Entity

SAPI=5

Logical

Link

EntitySAPI=3

Logical

Link

Entity

SAPI=1

GRR

LLGMM

RLC/MAC layer

LLC layer

Layer 3

LLC layer

BSSGP

BSSGP

BSSGP layer

Signalling

Signalling and data transfer

TOM

TOM8 LLSMSTOM2

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






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






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 numberedunacknowledged 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






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






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.

SNDCP

Packet DataProtocol

LLC

NSAPI

N-PDU

SAPI

SN-PDU

Packet DataProtocol

Packet DataProtocol

. . .

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






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. Theimplementation sequence of the functions is as follows:

Protocol control information compression

User data compression

Segmentation of compressed information into SN-DATA and

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






N-PDU

header data

SN-UNITDATA.request NETWORK LAYER

SNDCP

compare header to previous

differenceig small

header delta

M=1

M=1

M=0

SNDCP

LLC

.

.

.

M=1

M=1

M=0

M=1

M=0

Segmente

dN-PDU 1

Segmente

dN-PDU 2

#1

#2

#3

#1

#2

LL-DATA.request LL-UNITDATA.request

compressor data

segmentation segmentation

LLC header LLC header

SN-DATA PDU SN-UNITDATA PDU

SN-DATA.request

compressor data

SN-DATA PDU SN-UNITDATA PDU

compressor control

Segmented

N-PDU

compressor control

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






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

UDP

L2

L1

IP

L2

L1

IP

UDP

GnGSN GSN

GTP GTP

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 3GPPTS 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 maintenance, context


2-28






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






L2

L1

IP

GTP’

SGSN

UDP/TCP

L2

L1

IP

GTP’

CGF

UDP/TCP

S-CDRs, M-

CDRs, S-

SMO-CDRs

& S-SMT

CDRs

S-CDRs, M-

CDRs, S-

SMO-CDRs

& S-SMT

CDRs

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.

Bitsbytes

8 7 6 5 4 3 2 1

1 Version PT(0) SPARE("111") "0"

2 Message Type

3-4 Length

5-6 Sequence Number

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






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 fieldsfor 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 Numbersof 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






VLR

MSC

SMSC

HLR

VLR

MSC

SGSN

C/D

Gd

E

E

G

Gr

B B GGSNGn

Gc

CS域 PS域

EIR

GMLC

Gf

Lg

F

SMSC: Short Message Service Center HLR: Home Location RegisterMSC: Mobile Switching Center SCP: Service Control PointSGSN: Serving GPRS Support Node VLR: Visitor Location RegisterGGSN: Gateway GPRS Support Node EIR: Equipment Identity RegisterGMLC: Gateway Mobile Location Center

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






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.

messageSCCP

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






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 fetchand 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

Operationcode

Meaning Description

0x17 updateGPRSLocation

This operation is used for the SGSN to initiate a location update procedure toHLR when the MS is first registered in the network, or when inter-SGSNlocation update occurs, or when the subscriber data has not beenacknowledged by the HLR.

0x03 cancelLocation

This operation is used for the HLR to delete the subscriber information in theold SGSN, or for the location cancellation incurred by subscriber datamodification, or for the operator to delete the location information of the MSduring location update.

0x07 insertSubscriberDataThis operation is used for the HLR to insert MS subscription data in the SGSNduring location update, and to insert the subscription data during subscriberdata modification.

0x08 deleteSubscriberDataThis operation is used for the HLR to delete MS subscription data in the SGSNwhen the operator is deleting the subscriber data.

0x09 sendParametersPhase1 operation, used for the SGSN to get authentication set (authenticationtriplet) from the HLR.

0x38 sendAuthenticationInfoIn Phase3, this operation is used for the SGSN to get authentication set(authentication triplet or quintuplet) from the HLR. In phase2, this operation isused to get authentication triplet from the HLR.

0x0FauthenticationFailureReport

This operation is used to report authentication failure to the HLR when theauthentication fails.

0x43 purgeMS This operation is used for the SGSN to report to the HLR the SGSN subscriberdeletion operation.

0x25 resetThis operation is used to inform the SGSN of the HLR location update initiatedby 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 readyForSMThis operation is used for notification when the short message subscriber getspresent or when the memory is available.

0x18SendRoutingInfoForGp

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


2-34






Operationcode

Meaning Description

MS.

0x19 failureReportThis operation is used for the GGSN to report via the SGSN to the HLR thePDP context activation failure at the network side when the network fails toinitiate a PDP context activation to the MS.

0x1a noteMsPresentForGprsThis operation is used for the HLR to notify the HLR via the SGSN to reattemptthe PDP context activation procedure at the network side after the HLRreceives the MS Presence notification.

0x53provideSubscriberLocation

This operation is used for the GMLC to request for the location information ofthe target MS from the SGSN.

0x56subscriberLocationReport

This operation is used for the SGSN to report the location information of thetarget 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.

L1

MTP2

MTP3

SCCP

TCAP

MAP

L1

MTP2

MTP3

SCCP

TCAP

MAP

Gd/Gr

/Gf/Lg

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






Gn

UDP

L2

IP

GGSN

L1

L2

IP

SGSN

GTP-C

L1

MTP2

MTP3

SCCP

MAP

L1

MTP2

MTP3

SCCP

HLR

TCAP

MAP

L1

GTP-C

Gr

Interworking

TCAP

UDP

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






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.

SCCP

MTP2

MTP3

MTP2

MTP3

SCCP

GsSGSN MSC/VLR

BSSAP+ BSSAP+

L1 L1

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






III. Protocol Structure

L1

MTP2

MTP3

SCCP

TCAP

CAP

L1

MTP2

MTP3

SCCP

TCAP

CAP

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






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






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





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network Chapter 3 Mobility Management Functions

Chapter 3 Mobility Management Functions

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 notreachable 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






PDU transmission

Implicit Detach

or

Cancel Location

GPRS Attach

READY timer expiry

or

Force to STANDBY

GPRS Detach GPRS Attach

PDU reception

GPRS Detach

or

Cancel Location

MM State Model of MS MM State Model of SGSN

IDLE

READY

STANDBY

IDLE

READY

STANDBY

READY timer expiry

or

Force to STANDBY

or Abnormal RLC condition

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






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 thePMM-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






PMM-DETACHED

PS Attach

PS SignallingConnection Release

PS SignallingConnection Establish

PS Detach

PMM-

CONNECTEDPMM-IDLE

Detach,PS Attach Reject,RAUReject

PMM-DETACHED

PS Detach

PMM-

CONNECTED

Serving RNC

relocation

3G-SGSN MM StatesMS MM States

SM-ACTIVE or INACTIVE




Detach,PS Attach Reject,RAURejectPS Attach

PS SignallingConnection Establish

PS SignallingConnection Release

PMM-IDLE

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 LLCPDU 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






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






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 theMS 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 Circuit paging channelGPRS paging

channelPaging co-ordination

Packet paging channelPacket pagingchannel

CCCH paging channelCCCH pagingchannel

I

Packet data channel -

Yes, the SGSN coordinates with theMSC/VLR to execute paging. The Gsinterface is present in this case. The MSneeds only to monitor one paging channel. Itreceives CS paging messages on the packetdata channel when it has been assigned apacket data channel.

II CCCH paging channelCCCH pagingchannel

No, the SGSN does not coordinate with theMSC/VLR to execute paging. The MS needsonly to monitor the CCCH paging channel inthis case. CS paging continues on the CCCHpaging channel even if the MS has beenassigned a packet data channel.

CCCH paging channelPacket pagingchannel

III

CCCH paging channelCCCH pagingchannel

No, the SGSN does not coordinate with theMSC/VLR to execute paging. An MS thatwants to receive pages for bothcircuit-switched and packet-switched servicesshall monitor both the CCCH paging channeland the packet paging channel if the packet

paging channel is allocated in the cell.


3-6






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. Thepaging 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 conf iguration Combined procedur e by MS

I 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






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






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






7d. Cancel Location Ack

7c. Cancel Location

7b. Update Location

7g. Update Location Ack

7e. Insert Subscriber Data

7f. Insert Subscriber Data Ack

6d. Insert Subscriber Data

6c. Cancel Location Ack

6b. Cancel Location

3. Identity Response

2. Identification Response

2. Identification Request

1. Attach Request

5. IMEI Check

3. Identity Request

4. Authentication

6a. Update Location

7a. Location Update Request

7h. Location Update Accept

6f. Update Location Ack

6e. Insert Subscriber Data Ack

MS UTRAN new SGSN old SGSN GGSN HLR EIR

old

MSC/VLR

new

MSC/VLR

9. Attach Complete

8. Attach Accept

10. TMSI Reallocation Complete

C1

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






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 ofattach 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






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 checkingfails 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, GSMsubscriber 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






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.

3. IMSI Detach Indication

2. Delete PDP Context Response

1. Detach Request

2. Delete PDP Context Request

5. Detach Accept

MS BSS/UTRAN GGSNSGSN MSC/VLR

4. GPRS Detach Indication

6. PS Signalling Connection Release

C2

C1

Figure 3-4 MS-initiated detach procedure



3-13






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 aswitch 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 whena 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







1. Detach Request 2. Delete PDP Context Request

4. Detach Accept

MS BSS/UTRAN GGSNSGSN MSC/VLR



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 ContextResponse (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.

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






HLR MS BSS/UTRAN GGSNSGSN MSC/VLR


1. Cancel Location


2. Detach Request

6. Cancel Location Ack


5. Detach Accept


C2

C1

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 requestedto 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) The MS sends a Detach Accept message to the SGSN any time after step 1).

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

C1) CAMEL-Deactivate-PDP-Context. This procedure is performed every time when


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


3-16






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, deletethe 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.

1. Purge MS

2. Purge MS Ack

SGSN HLR

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






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

1. Send Authentication Info

2. Authentication and Ciphering Request

1. Send Authentication Info Ack

2. Authentication and Ciphering Response

MS BSS/UTRAN HLR SGSN

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






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

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 anIdentification 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 theIntegrity 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






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.

2. P-TMSI Reallocation Complete

1. P-TMSI Reallocation Command

MS BSS/UTRAN SGSN

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






3.7.4 Identity Check Procedures

The Identity Check procedure is illustrated in Figure 3-11.

1. Identity Response

2. Check IMEI

1. Identity Request

2. Check IMEI Ack

MS BSS/UTRAN EIR SGSN

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






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 physicallylocated 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






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.

1. Routeing Area Update Request

3. Routeing Area Update Accept

2. Security Functions

MS BSS SGSN

4. Routeing Area Update CompleteC1

Figure 3-12 Intra SGSN routeing area update procedure


1) The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSISignature, 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






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. Thisprocedure 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 HLR GGSNold SGSN

2. SGSN Context Response



2. SGSN Context Request

6. Update PDP Context Request

6. Update PDP Context Response

7. Update Location

10. Update Location Ack


8. Cancel Location


9. Insert Subscriber Data Ack

9. Insert Subscriber Data

12. Routeing Area Update Complete

5. Forward Packets

4. SGSN Context Acknowledge

C2

C4

C3

C1

Figure 3-13 Inter SGSN routeing area update procedure


3-24







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-TMSISignature, 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 theGTP 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.


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






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 thenew 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






4b. Cancel Location




HLR MS BSS

new

MSC/VLR SGSN

old

MSC/VLR

3. Location Update Request



4a. Update Location




5. Location Update Accept


C1

Figure 3-14 Combined RA/LA update in the case of intra SGSN RA update procedure


1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature,

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



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






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, VLRTMSI, 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 locationupdate between the HLR and the two SGSNs.


3-28






12b. Cancel Location








8. Cancel Location




7. Update Location


12a. Update Location









MS BSS GGSNold SGSNnew SGSN HLR

new

MSC/VLR

old

MSC/VLR

5. Forward Packets


C4

C2

C3

C1

Figure 3-15 Combined RA/LA update in the case of inter SGSN RA update procedure


3-29






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






2. SGSN Context Response3. Security Functions

2. SGSN Context Request1. Routeing Area Update Request

MS UTRAN GGSNold

3G-SGSN

new

3G-SGSN HLR

new

MSC/VLR

old

MSC/VLR

4. SGSN Context Ack

C2

7. Cancel Location




6. Update Location















C3

C2

2a. SRNS Context Request

2a. SRNS Context Response

7a. Iu Release Command

7a. Iu Release Complete

C1

Figure 3-16 UMTS RA update procedure


3-31







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 thenew 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 hasauthenticated 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






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






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

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 anappropriate 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






II. Serving RNS relocation procedures

Soft handover

The Inter SGSN Soft Handover procedure is illustrated in Figure 3-17.

MS TargetRNC

SourceRNC

OldSGSN

NewSGSN

GGSN

3. Forward Relocation Request

4. Relocation Request

2. Relocation Required

6. Relocation Command

5. Forward Relocation Response

4. Relocation Request Acknowledge

9. Relocation Detect

13. Relocation Complete

13. Forward Relocation Complete

10. RNTI Reallocation

12. RNTI Reallocation Complete

Establishment of Radio Access Bearers

15. Routing Area Update


14. Iu Release Command

14. Iu Release Complete

C1

C2

1. Decision to perform SRNS relocation

7. Relocation Commit

8. Forwarding of data


13. Forward Relocation Complete Acknowledge

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






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 intraSGSN 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






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






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 IuRelease 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 and

CAMEL-GPRS-Detach-PDP-Context.


Hard handover

The Inter SGSN Hard Handover procedure is illustrated in Figure 3-18.


3-38






MS TargetRNC

SourceRNC

OldSGSN

NewSGSN

GGSN










8. Forward SRNS Context



7. Physical Channel Reconfiguration

12. Physical Channel Reconfiguration Complete

1. Decision to performSRNS Relocation

MS Involved

MS detected by target RNC






C1



8. Forward SRNS Context Acknowledge


C3

C2

Figure 3-18 Inter SGSN hard handover procedure



3-39






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) The source SRNC initiates the relocation preparation procedure by sending aRelocation 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

SGSN SRNS relocation or inter SGSN SRNS relocation. In case of inter SGSN

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.



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






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 resourcesassociated 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 (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) Upon reception of the Relocation Command message from the PS domain, the

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.


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






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




C2) CAMEL-GPRS-Routeing-Area-Update

Combined cell/URA update and SRNS relocation procedure


3-42






MS TargetRNC

SourceRNC

OldSGSN

NewSGSN

GGSN













7. Physical Channel Reconfiguration

12. Physical Channel Reconfiguration Complete

1. Decision to performSRNS Relocation

MS Involved

MS detected by target RNC






C1



8. Forward SRNS Context Acknowledge


C3

C2

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






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

the target RNC.

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

SGSN SRNS relocation or inter SGSN SRNS relocation. In case of inter SGSN

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.



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






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


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






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.





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






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 isreset 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

1. Delete Subscriber Data

2. Delete Subscriber Data Ack

SGSN HLR

Figure 3-21 Delete subscriber data procedure


3-47






3.10 Service Request Procedure s (UMTS Only)

3.10.1 MS-Initiated Service Request Procedure

SGSNMS

2. Service Request


RNC1. RRC Connection Request

8. Uplink PDU

1. RRC Connection Setup

4. Radio Access Bearer AssignmentRequest

6. Radio Access Bearer Assignment

Response

5. Radio Bearer Setup


Complete

HLR GGSN

7. SGSN-Initiated PDP Context Modification

4. Service Accept

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

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






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






3.10.2 Network-Initiated Service Request Procedure

7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU

SGSNMS


RNC

3. RRC Connection Request

1. Downlink PDU



6. Radio Access Bearer AssignmentResponse


6. Radio Bearer SetupComplete

2. Paging

2. Paging

4. Service Request

HLR GGSN

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.


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






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






3.11 UMTS-GSM Intersystem Change

3.11.1 Intra SGSN Intersystem Change

I. UMTS-to-GSM intra SGSN change


MS SRNS 2G+3G-SGSNBSS



6. SRNS Data Forward Command

7. Forward Packets

1. Intersystem change decision

3. SRNS Context Request

4. SRNS Context Response




15. BSS Packet Flow Context Procedure

C1

new

MSC/VLR

old

MSC/VLR

HLR







10f. Update Location


10c. Cancel Location A

Figure 3-24 UMTS-to-GSM intra SGSN change



3-52






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) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature,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.


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






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


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






II. GSM-to-UMTS intra SGSN change


MS BSS 2G+3G-SGSNSRNS

2. Routing Area Update Request

11. RAB Assignment Request

11. RAB Assignment

13. Packet Transfer Resume

1. Intersystem change decision

12. Packet Transfer Resume

7. Routing Area Update Accept

8. Routing Area Update Complete

Set up RadioResources

C1

new

MSC/VLR

HLR old

MSC/VLR


5a. Update Location

5b. Cancel Location

5c. Cancel Location A


5e. Insert Subscriber Data

5f. Update Location


9. TMSI Reallocation Complete10. Service Request

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






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




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.




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.


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







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






3.11.2 Inter SGSN Intersystem Change

I. UMTS-to-GSM inter SGSN change

MS new

2G-SGSN

HLR GGSNold

3G-SGSN

2. Routing Area Update Request



11. Update GPRS Location

15. Update GPRS Location Ack



19. Routing Area Update Accept

12. Cancel Location





BSS SRNS




8a. Forward Packets

9. Forward Packets

4. SRNS Context Request

4. SRNS Context Response

8. SRNS Data Forward Command

22. BSS Packet Flow Context Procedure

1. Intersystem changedecision

C3

C1

20. Routing Area Update Complete

new

MSC/VLR

old

MSC/VLR







17f. Update Location Ack 18. Location Update Accept


C2

Figure 3-26 UMTS-to-GSM inter SGSN change


3-58







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

stops transmission to the network.2) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature,

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



3-59






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

marks in its context that the MSC/VLR association and the information in theGGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and

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.



area update, then the new 2G-SGSN sends a Location Update Request (new


3-60






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

17) 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:



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






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.For an MS with GPRS-CSI defined, CAMEL interaction may be performed:

C1) CAMEL-GPRS-SGSN-Context-Acknowledge

C2) CAMEL-GPRS-Routeing-Area-Update-Session

C3) CAMEL-GPRS-Routeing-Area-Update-Context


3-62






II. GSM-to-UMTS inter SGSN change

MS new

3G-SGSN

HLR GGSNold

2G-SGSN



9. Update GPRS Location

12. Update GPRS Location Ack





10. Cancel Location






BSS SRNS


20. RAB Assignment Response

7. Forward Packets

1. Intersystemchange decision

C3

C1

new

MSC/VLR

old

MSC/VLR




14b. Cancel Location Ack

14c. Insert Subscriber Data

14d. Insert Subscriber Data Ack

14e. Update Location Ack



Set up RadioResources

19. Service Request

C2

20. RAB Assignment Request

Figure 3-27 GSM-to-UMTS inter SGSN change


3-63







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


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






receive data packets belonging to the activated PDP contexts. The old SGSN

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

14) 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:



3-65







the old VLR.


The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the newVLR.




(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






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






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





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network Chapter 4 Session Management Functions

Chapter 4 Session Management Functions

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






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.

Deactivate PDP Context

or

MM state chan e to IDLE

or PMM-DETACHED

Activate PDP

Context

INACTIVE

ACTIVE

Figure 4-1 SM functional PDP state model


4-2






4.2 PDP Context Activation, Modification, Deactivation, andPreservation 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






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.

2G-GGSN

7. Activate PDP Context Accept

5. Create PDP Context Response

5. Create PDP Context Request

1. Activate PDP Context Request

2G-SGSNBSS


MS

6. BSS Packet Flow Context Procedures

C1

C2

4. Invoke Trace

Figure 4-2 MS-initiated PDP context activation procedure for GSM


4-4






3G-GGSN




1. Activate PDP Context Request

3G-SGSNUTRANMS

3. Radio Access Bearer Setup C1

C2

4. Invoke Trace

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 PDPcontext 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






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

2G-GGSN

6. Activate Secondary PDP Context Accept



1. Activate Secondary PDP Context Request

2G-SGSNBSS


MS

5. BSS Packet Flow Context Procedures

C1

C2

Figure 4-4 Secondary PDP context activation for GSM


4-6






3G-GGSN




1. Activate Secondary PDP Context Request

3G-SGSNUTRANMS

3. Radio Access Bearer SetupC1

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 acharging 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






MS SGSN GGSN

3. PDU Notification Request

HLR

1. PDP PDU

2. Send Routeing Info for GPRS

2. Send Routeing Info for GPRS Ack

4. Request PDP Context Activation

5. PDP Context Activation procedure

3. PDU Notification Response

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 inthe 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






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.

GGSN



SGSNUTRANMS

3. Modify PDP Context Request

4. Modify PDP Context Accept

5. Radio Access Bearer Modification

C1

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






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.

GGSN



SGSNUTRANMS




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) Radio access bearer modification may be performed by the RAB Assignmentprocedure.

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






GGSN



SGSNUTRANMS




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) Radio access bearer modification may be performed by the RAB Assignmentprocedure.

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






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.

2G-GGSN

4. Deactivate PDP Context Accept



1. Deactivate PDP Context Request

2G-SGSNMS


C1

Figure 4-10 MS-initiated PDP context deactivation procedure for GSM

3G-GGSN



3G-SGSNUTRANMS



5. Radio Access Bearer Release

C1

Figure 4-11 MS-initiated PDP context deactivation procedure for UMTS



4-12






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.

GGSN



SGSNUTRANMS




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






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

SGSN.


access bearer.

III. GGSN-initiated PDP context deactivation

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

GGSN



SGSNUTRANMS

2. Deactivate PDP Context Request2. Deactivate PDP Context Accept


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 fromthe MS before sending the Delete PDP Context Response message.


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






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.

SGSNMS

2. Service Request


RNC1. RRC Connection Request

8. Uplink PDU



6. Radio Access Bearer Assignment

Response



Complete

HLR GGSN

7. SGSN-Initiated PDP Context Modification

4. Service Accept

Figure 4-14 Re-establishment procedure of RABs initiated by MS by using Service Request


1) An RRC connection is established, if none exists.


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






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.

7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU

SGSNMS


RNC

3. RRC Connection Request

1. Downlink PDU



6. Radio Access Bearer AssignmentResponse


6. Radio Bearer SetupComplete

2. Paging

2. Paging

4. Service Request

HLR GGSN

Figure 4-15 Re-establishment procedure of RABs initiated by SGSN by using Service Request


4-16






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






5.7.2 Request Service Option not Subscribed ............................................................... 5-33

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


ii





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network Chapter 5 Typical Signaling Analysis Cases

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






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






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 3message 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 LSBas follows:

1: encryption algorithm GEA/1 available

1: Mobile station supports mobile terminated point to point SMS viadedicated signalling channels

1: Mobile station supports mobile terminated point to point SMS viaGPRS packet data channels

1: the ME has no preference between the use of the defaultalphabet and the use of UCS2

00: SS Screening Indicator

0: The ME does not support SoLSA


5-3






IE Description

1: used by an MS supporting R99 or later versions of the protocol

Attach type The purpose of theattach type information element is to indicate

the type of the requested attach, i.e. whether the MS wants toperform 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 ofthe 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-onrequest pending.

GPRS ciphering keysequence number

In a GSM authentication challenge, the purpose of the CipheringKey Sequence Number information element is to make it possiblefor the network to identify the ciphering key Kc that is stored in themobile station without invoking the authentication procedure.

The CKSN information element is coded as follows:

Key sequence (octet 1)

Bits210

000–101: Possible values for the ciphering key sequence number

111: No key is available (MS to network); Reserved (network toMS)

In this example, no key is available.

DRX parameter The purpose of the DRX parameter information element is toindicate whether the MS uses DRX mode or not.

In this example, the MS uses DRX mode.


5-4






IE Description

MS identity In the example, the IMSI is 460001932076709.

Note: The IMSI consists of Identity1 and Identity left.

Old routing areaidentification

The OLD RAI in this example is invalid, that is, there is no OLDRAI.

MS Radio Accesscapability

The purpose of the MS RA capability information element is toprovide the radio part of the network with information concerningradio aspects of the mobile station. The contents might affect themanner in which the network handles the operation of the mobilestation.

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 thatthe IMEISV shall be included by the MS in the authentication andciphering response message.

IMEISV is the international mobile equipment identity together with thesoftware version number.

Force to standby The purpose of the force to standby information element is to force theMS to stop the READY timer in order to prevent the MS to perform cellupdates.

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


5-5






IE Description

RESPONSE message which AUTHENTICATION AND CIPHERINGREQUEST 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






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.

SupportedCAMEL Phases

0520


5-7






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


MSISDN In this example, the MSISDN is 8613803211853.

Subscriber Status To apply, remove or update Operator Determined Barring Categoriesthe Subscriber Status is set to Operator Determined Barring. In thiscase ODB General Data shall also be present. If the OperatorDetermined Barring applies and the subscriber is registered in theHPLMN and HPLMN specific Operator Determined Barring appliesthen ODB HPLMN Specific Data shall also be present.

To remove all Operator Determined Barring Categories the


5-8







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 SubscriptionData

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 fieldshall be empty if dynamic addressing is allowed.

Access Point Name: A label according to DNS naming conventionsdescribing the access point to the packet data network.

QoS Profile Subscribed: Quality of service profile subscribed. It is thedefault level if a particular QoS profile is not requested. QoS ProfileSubscribed is also the maximum QoS per PDP context to theassociated APN.

VPLMN Address Allowed: Specifies whether the MS is allowed to usethe APN in the domain of the HPLMN only, or additionally the APN inthe domain of the VPLMN.

PDP context Charging Characteristics: The charging characteristicsof this PDP context, for example, normal, prepaid, flat-rate, and/or hotbilling.

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






Figure 5-9 MAP_SERVICE_CNF

Table 5-3 Parameter for the MAP_SERVICE_CNF service


HLR number 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







Table 5-4 Content in the L3 message

IE Description

Attach result The purpose of theattach result information element is to specify the resultof a GPRS attach procedure.

Force to standby The purpose of the force to standby information element is to force the MSto stop the READY timer in order to prevent the MS to perform cellupdates.

Periodic RAupdate timer

In this example, the value of periodic RA update timer is 9 hours.

Radio priority forSMS

The purpose of the radio priority information element is to specify thepriority level that the MS shall use at the lower layers for transmission ofdata related to a PDP context or for mobile originated SMS transmission.

Routing areaidentification

In this example, the RAI is 46000311400.

P-TMSIsignature

The purpose of the P-TMSI signature information element is to identify aGMM context of an MS.


5-11






IE Description

NegotiatedREADY timervalue

In this example, the value of negotiated READY timer is 44 seconds.

AllocatedP-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






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 updatehas been performed by the MS.

In this example, the update type is an IMSI attach.

New Cell globalidentity

In this example, CGI is 460185241000000.

Mobile stationclassmark

The purpose of the Mobile Station Classmark 1 information element isto provide the network with information concerning aspects of highpriority of the mobile station equipment.

Old location areaidentifier

In this example, the old LAI is 460185241.


5-13






IE Description

New service areaidentification

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-14shows 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






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






Figure 5-16 RA UPDATE REQUEST message

Table 5-8 Content in the RA UPDATE REQUEST message

IE Description

PDP contextstatus

The purpose of the PDP context status information element is to indicatethe state of each PDP context that can be identified by NSAPI.

0000 sequentially indicates the state of the PDP context identified by theNSAPI (0–15).

0: indicates that the SM state of the corresponding PDP context isPDP-INACTIVE.

1: indicates that the SM state of the corresponding PDP context is notPDP-INACTIVE.

5.4.3 BSSAP UPDATE LOCATION REQUEST Message



5-16






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






Figure 5-18 BSSAP UPDATE LOCATION ACCEPT message

5.4.5 RA ACCEPT Message



5-18






Figure 5-19 RA ACCEPT message


5-19






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






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 Description

Service type The purpose of the service type information element is to specify thepurpose 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






Figure 5-23 ACTIVATE PDP CONTEXT REQUEST message content

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

IE Description

Requested NSAPI The purpose of the network service access point identifier informationelement is to identify the service access point that is used for the GPRSdata transfer at layer 3.

The value range of NSAPI is 5-15.

Requested LLCSAPI

The purpose of the LLC service access point identifier informationelement 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 theQoS parameters for a PDP context.

Requested PDPaddress

The purpose of the packet data protocol address information element is toidentify an address associated with a PDP.

In this example, no PDP address is included in this information element;and dynamic addressing is applicable.

Access pointname

The purpose of the access point name information element is to identifythe packet data network to which the GPRS user wishes to connect andto notify the access point of the packet data network that wishes to

connect to the MS.

Protocolconfigurationoptions

The purpose of the protocol configuration options information element isto transfer external network protocol options associated with a PDPcontext 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







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 inthe 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 receiverof the flow.

Tunnel EndpointIdentifier ControlPlane

The Tunnel Endpoint Identifier Control Plane information element containsthe Tunnel Endpoint Identifier for the control plane; it is assigned by thereceiver of the flow. It distinguishes the tunnel from other tunnels betweenthe same pair of entities.

ChargingCharacteristics

The charging characteristics information element is a way of informing boththe SGSN and GGSN of the rules for producing charging information basedon operator configured triggers.

Bits 0–3 in the first byte of the charging characteristics are described asfollows: charging by hot billing, flat-rate charging, prepaid charging, normal


5-23






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 networkaccessed by the GPRS subscriber

SGSN Addressfor signalling

217.164.95.67

SGSN Addressfor 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






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.

Reorderingrequired

The Reordering Required information element states whether reordering byGTP 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 PDPcontext

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.

ChargingGateway Address

The Charging Gateway Address is the IP address of the recommendedCharging Gateway Functionality to which the SGSN should transfer theCharging 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






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






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






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






Figure 5-33 ATTACH REJECT message

Figure 5-34 MAP_SERVICE_CNF service


5-29






5.6.4 Gs Interface Fault

Figure 5-35 Gs interface fault


5-30






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






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






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






Figure 5-41 Subscription data

Figure 5-42 Requested data


5-34






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






Figure 5-45 Subscription data

Figure 5-46 Requested data


5-36






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






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






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





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network

Appendix A UMTS Specific Cause Values for MobilityManagement

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







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 ofthe 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 andcongestion/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







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







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







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 REQUESTmessage indicating "data" to the network, but the SGSN does not have any active

PDP context(s).


A-5






Appendix B GPRS Specific Cause Values for SessionManagement

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 a LLC or SNDCP failure (e.g. if the SM receives a

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







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

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







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 activationinitiated 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







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 contextactivation 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





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network Appendix C Acronyms and Abbreviations

Appendix C Acronyms and Abbreviations

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

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






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-TInternational Telecommunication Union - Telecommunication StandardizationSector

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 PartMCC 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






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






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






VMSC Visited Mobile Switching Center

VPI Virtual Path Identifier

VPN Virtual Private Network

W

WCDMA Wideband Code Division Multiple Access


C-6





Protocols and Signaling AnalysisHUAWEI UMTS Packet-Switched Core Network Index

Index

A

abnormal attach procedure, 5-26

Gs interface fault, 5-30

Illegal MS, 5-28

protocol error, unspecified, 5-26

abnormal PDP activation procedure, 5-32

activate rejected by GGSN, 5-37

request service option not subscribe, 5-33 aditional cause code for GMM, A-4

C

classmark handling, 3-66

MS Network capability, 3-66

radio access, 3-66

combine attach message type

BSSAP+-LOCATION-UPDATE-ACCEPT, 5-14

BSSAP+-LOCATION-UPDATE-REQUEST,

5-13

combine GPRS/IMSI attach procedure, 3-9

combine RA/LA update procedure, 5-14

combined attach procedure, 5-12

combined RA/LA update message type

BSSAP UPDATE LOCATION ACCEPT, 5-17

BSSAP UPDATE LOCATION REQUEST, 5-16

RA ACCEPT, 5-18

RA UPDATE REQUEST, 5-15

congestion/Authentication failures cause relate, A-2

D

detach function, 3-12

dynamic PDP addresse, 4-3

G

Ga interface definition, 2-28

Ga interface function, 2-28

Ga interface protocol architecture, 2-28

Gb interface, 2-2

BSSGP, 2-18

Logical Link Control (LLC), 2-19

Network Service (NS), 2-14

SNDCP, 2-24

Gb interface definition, 2-13

Gb interface protocol architecture, 2-13

Gd interface, 2-3 Ge interface definition, 2-36

Ge interface function, 2-36

Ge interface protocol structure, 2-37

GMM/SM signalling confidentiality, 3-19

Gn/Gp interface definition, 2-27

Gn/Gp interface function, 2-27

Gn/Gp interface protocol architecture, 2-27

Gn/Gp/Ga interface, 2-3

GPRS attach function, 3-8

GPRS attach message type

ATTACH ACCEP, 5-10

ATTACH ACCEPLETE, 5-12

ATTACH REQUEST, 5-2

AUTHENTICATION AND CIPHERING

REQUEST, 5-5

AUTHENTICATION AND CIPHERING

RESPONSE, 5-6

GPRS attach procedure, 5-1

GPRS attach service typeMAP SERVICE CNF, 5-9

MAP_OPEN_REQ, 5-6

MAP_SERVICE_IND, 5-8

MAP_SERVICE_REQ, 5-7

Gr interface, 2-3

Gs interface, 2-3

Gs interface protocol architecture, 2-36

GSM authentication, 3-17

GSM CS paging, 3-6

GSM GPRS attach procedure, 3-8


i-1






GSM location management procedure, 3-21

GSM-to-UMTS inter SGSN change, 3-62

GSM-to-UMTS intra SGSN change, 3-54

I

identity check procedure, 3-20

inter SGSN intersystem change, 3-57

GSM-to-UMTS, 3-62

UMTS-to-GSM, 3-57

interface introduction

Gb interface, 2-2

Gd interface, 2-3

Gn/Gp/Ga interface, 2-3

Gr interface, 2-3

Gs interface, 2-3

Iu interface, 2-2

intra SGSN intersystem change, 3-51

GSM-to-UMTS, 3-54

UMTS-to-GSM, 3-51

Iu interface, 2-2 , 2-3

Iu interface definition, 2-4

Iu interface function, 2-4

Iu interface protocol architecture, 2-5

L

location management function, 3-20

M

Map interface definition, 2-30

Map interface function, 2-30

Map interface protocol structure, 2-34

MM information procedure, 3-8

mobile reachable timer function, 3-5

mobility management definition, 3-1

mobility management function, 3-1

classmark handling, 3-66

detach, 3-12

GPRS attach, 3-8

location management, 3-20

purge, 3-16

security function, 3-16

subscriber, 3-46

timer, 3-4

UMTS-GSM intersystem change, 3-51

mobility management state

GSM, 3-1

UMTS, 3-2

mobility management timer function, 3-4

mobility management UMTS specific cause value,

A-1

MS identification cause relate, A-1

2 IMSI unknown in HLR, A-1

3 Illegal MS, A-1

4 IMSI unknown in VLR, A-1

5 IMEI not accepted, A-1

6 Illegal ME, A-2

MS information procedure, 3-7

MS-Initiated detach procedure, 3-12

MS-Initiated service request procedure, 3-47

N

nature of request cause relate, A-3

Network-Initiated detach procedure, 3-14

HLR-initiated, 3-15

SGSN-initiated, 3-14 Network-Initiated service request procedure, 3-49

Non-GPRS alert, 3-7

P

packet data protocol definition, 4-1

packet data protocol state

ACTIVE, 4-2

INACTIVE, 4-1

PDP Activation message type

ACTIVATE PDP CONTEXT ACCEPT, 5-25

ACTIVATE PDP CONTEXT REQUEST, 5-21

CREATE PDP CONTEXT REQUEST, 5-22

CREATE PDP CONTEXT RESPONSE, 5-24

SERVICE REQUEST, 5-21

PDP context activation, 4-3

PDP context activation procedure, 4-4, 5-20

PDP context deactivation, 4-3

PDP context deactivation procedure, 4-12

PDP context modification, 4-3


i-2






11 PLMN not allowed11 PLMN not allowed, A-2 PDP context modification procedure, 4-8

12 Location Area not allowed, A-2 PDP context preservation, 4-3

PDP context preservation procedure, 4-14 13 Roaming not allowed in this location area,

A-2 periodic RA update timer function, 3-4

15 No Suitable Cells In Location Area, A-2 periodic RA/LA update, 3-45

PLMN specific network failures cause relate, A-2

T protocol interface, 2-1

purge function, 3-16 the SGSN-MSC/VLR sssociation administration,

3-5

R timer function

RABs Re-establishment procedure, 4-14 mobile reachable, 3-5

periodic RA update, 3-4 READY timer function

GSM, 3-4 typical signaling analysis, 5-1

reference protocol, 1-1

U

S



Documents

HWI_Protocol and Signaling Analysis