02 Tm3110eu02tm 0001 Gprs Sign GMM Context PDF

GPRS Signaling Using GMM Context Siemens
GPRS Signaling Using GMM Context
Contents
1 GPRS Mobility Management Overview 3
1.1 Protocol Stack 4
1.2 Functions of the GMM 6
1.3 Storage of GMM related Data in the different Network Entities 8
1.4 GPRS Mobility Management States 16
2 Signaling Procedures Supporting GMM Functionality 23
2.1 Registration Procedures 24
2.2 Security Procedures 34
2.3 Location Management Procedures 42
3 Format of GMM Messages 63
3.1 Format of Standard Layer 3 Messages 64
3.2 Format of the GPRS Attach Request Message 68
3.3 Format of the GPRS Attach Accept Message 75
4 Exercise 77
5 Solution 81
TM3110EU02TM_0001
1
© 2002 Siemens AG
Siemens GPRS Signaling Using GMM Context
2 TM3110EU02TM_0001
© 2002 Siemens AG
1 GPRS Mobility Management Overview
TM3110EU02TM_0001
3
© 2002 Siemens AG
1.1 Protocol Stack

GPRS Mobility Management (GMM) belongs to the signaling plane.
The main task of the mobility management is to keep track of the current location of
an MS within the PLMN. The layer providing the functions used for mobility
management is called Mobility Management (MM) layer. GSM mobile stations
supporting both circuit switched and packet switched services (GPRS) contain two
sub-entities of this MM layer:
The mobility management (MM) sub-entity for non-GPRS services (circuit-
switched GSM services) and
The mobility management (GMM) for GPRS services (packet-switched GSM
services).
This section is focusing on the GMM only.
The Subnetwork Dependent Convergence Protocol (SNDCP) is part of the

transmission plane and responsible for the user data transfer.
The GPRS Mobility Management is defined by the 3GPP Technical Specifications

3GPP TS 04.08 and 03.60 (Release 1998 and earlier) or by 3GPP TS 24.008 and
23.060 (Release 1999 and later).
4 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
IP IP
SMS SNDCP GMM/SM GMM/SM SNDCP SMS
LLC LLC
Relay
RLC RLC BSSGP BSSGP
Network
MAC MAC Network Service
Service
GSM RF GSM RF L1bis L1bis
MS Um BSS Gb SGSN
Fig. 1 Signaling plane MS - SGSN
TM3110EU02TM_0001
5
© 2002 Siemens AG
1.2 Functions of the GMM

The main functions of the GMM are the following:
Registration functions, e.g. GPRS attach/detach.

Security functions, e.g. GPRS authentication and ciphering, P-TMSI reallocation.
Location management functions, e.g. cell update, routing area update.
A further function of the MM sublayer is to provide connection management services

to the different entities of the upper Connection Management (CM) sublayer, i.e. the
Session Management layer in case of GPRS services.
The GMM functions are located in the MS and SGSN.
6 TM3110EU02TM_0001
© 2002 Siemens AG
Functions of GMM
Registration Security Location Management

Functions Functions Functions
Fig. 2 Functions of GPRS Mobility Management Layer
TM3110EU02TM_0001
7
© 2002 Siemens AG
1.3 Storage of GMM related Data in the different

Network Entities
Enhanced information storage structures are required in the different network entities
to support GPRS Mobility Management.
The following network entities contain permanent or temporary GMM/MM related
information:
The HLR.
The SGSN.
The MSC/VLR.
The MS.
The IMSI is the prime key to the GMM/MM related data (GMM/MM context) and
packet domain subscription data (PDP context) stored in the HLR.
8 TM3110EU02TM_0001
© 2002 Siemens AG
HLR Field Description

IMSI IMSI is the main reference key.
MSISDN The basic MSISDN of the MS.
SGSN Number The SS7 number of the SGSN currently serving this MS.
SGSN Address The IP address of the SGSN currently serving this MS.
SMS Parameters SMS-related parameters, e.g., operator-determined barring.
MS PS Purged for Indicates that the MM and PDP contexts of the MS are deleted
GPRS from the SGSN.
MNRG Indicates that the MS is not reachable through an SGSN, and that
the MS is marked as not reachable at the SGSN and possibly at
the GGSN.
GGSN-list The GSN number and optional IP address pair related to the
GGSN that shall be contacted when activity from the MS is
detected and MNRG is set. The GSN number shall be either the
number of the GGSN or the protocol-converting GSN The GSN
number shall be either the number of the GGSN or the protocol-
converting GSN.
Each IMSI contains zero or more PDP context subscription records.
Fig. 3 Storage of GMM related subscription data in the HLR.
TM3110EU02TM_0001
9
© 2002 Siemens AG
The SGSN maintains GMM related information (= GMM/MM context) and - in case
the Gs interface exists - also some MM related information as well as PDP context
related information of a certain MS in the STANDBY, READY states of MM.
The GMM/MM context is created in the SGSN during the GPRS Attach procedure.
10 TM3110EU02TM_0001
© 2002 Siemens AG
Field Description
MM State Mobility management state: IDLE, STANDBY or READY.
P-TMSI Packet Temporary Mobile Subscriber Identity.
P-TMSI Signature A signature used for identification checking purposes.
IMEI International Mobile Equipment Identity
MSISDN The basic MSISDN of the MS.
Routeing Area Current routeing area.
Cell Identity Current cell in READY state, last known cell in STANDBY or
SGSN IDLE state.
Cell Identity Age Time elapsed since the last LLC PDU was received from the
MS at the SGSN.
VLR Number The VLR number of the MSC/VLR currently serving this MS.
New SGSN The IP address of the new SGSN where buffered and not sent
Address N-PDUs should be forwarded to.
Authentication Authentication and ciphering parameters.
Triplets
Kc Currently used ciphering key.
CKSN Ciphering key sequence number of Kc.
Ciphering algorithmSelected ciphering algorithm (GEA).
DRX Parameters Discontinuous reception parameters.
MNRG Indicates whether activity from the MS shall be reported to the
HLR.
NGAF Indicates whether activity from the MS shall be reported to the
MSC/VLR.
PPF Indicates whether paging for PS and CS services can be
initiated.
SMS Parameters SMS-related parameters, e.g., operator-determined barring.
Radio Priority SMS The RLC/MAC radio priority level for uplink SMS transmission.
Each MM context contains zero or more PDP contexts
Fig. 4 Storage of GMM related data in the SGSN.
TM3110EU02TM_0001
11
© 2002 Siemens AG
Depending on the existence of the Gs interface the MSC/VLR stores the SGSN
number of GPRS attached MSs that are also IMSI attached. Figure 4 shows the
MSC/VLR association for one MS.
The association is initiated by the SGSN and created when the VLR stores the SGSN
number and the SGSN stores the VLR number. The association is used for co-
ordinating MSs that are both GPRS attached and IMSI attached.
The SGSN - MSC/VLR association is created at the following occasions:

Combined GPRS / IMSI attach.
GPRS attach when the MS is already IMSI-attached.
Combined RA / LA update when the MS performs IMSI attach and is already
GPRS-attached.
Combined RA / LA update when an IMSI and GPRS-attached MS changes from
an area of network operation mode II or III to an area of network operation mode I.
12 TM3110EU02TM_0001
© 2002 Siemens AG
MSC/VLR
Field Description
SGSN Number The SGSN number of the SGSN currently serving this
MS.
Fig. 5 Storage of GMM related data in the MSC/VLR.
TM3110EU02TM_0001
13
© 2002 Siemens AG
Each packet domain MS maintains GMM/MM and PDP context information in the
states IDLE, STANDBY or READY.
The information marked with an "X" in Fig. 6 has to be stored on the SIM after GPRS
detach.
14 TM3110EU02TM_0001
© 2002 Siemens AG
Field SIM Description

IMSI x International Mobile Subscriber Identity.
MS
MM State Mobility management state: IDLE, STANDBY or
READY.
P-TMSI x Packet Temporary Mobile Subscriber Identity.
P-TMSI x A signature used for identification checking purposes.
Signature
Routeing x Current routeing area.
Area
Cell Identity Current cell.
Kc x Current GPRS ciphering key.
CKSN x Cipher Key Sequence Number to identify Kc.
Ciphering Selected ciphering algorithm.
algorithm
DRX Discontinuous reception parameters.
Parameters
Radio The RLC/MAC radio priority level for uplink SMS
Priority SMS transmission.
Each MM context contains zero or more PDP contexts.
Fig. 6 Storage of GMM related data in the MS.
TM3110EU02TM_0001
15
© 2002 Siemens AG
1.4 GPRS Mobility Management States

In IDLE state, the MS is not attached (i.e. detached) to the PLMN. There is no valid
location or routing information for the MS available in SGSN or GGSN. Only GPRS
subscription information in the HLR is available. User data transfer and paging of the
GPRS MS are not possible. The MS is not seen as reachable from the network.
In READY state, the SGSN knows the RA (Routing Area) as well as the cell selected
by the MS. If the MS enters a new radio cell, it updates the SGSN performing the cell
update procedure. Therefore paging is not necessary if the SGSN wants to transmit
packet data downlink. The MS may send and receive PDP PDUs (protocol data unit)
in this state. However, the ready state does not imply any established physical
connection between MS and SGSN.
In STANDBY state, the MS is attached to the PLMN. The SGSN knows the RA of the
roaming MS, but not the specific cell within that RA. The MS as well as the SGSN
may initiate data transfer at that state by PDP context activation (MS) or paging
(SGSN). As a consequence the MS and the SGSN will change to ready state.
State changes of mobility management

IDLE to READY:
Initiated by GPRS Attach i.e. the MS requests radio resources and a logical link to an
SGSN is set up. MM contexts are established at the MS and SGSN.
STANDBY to IDLE:
1. Implicit Detach: The network detaches the MS without notification on expiration of
the mobile reachable timer. The MM and PDP contexts in the MS and the SGSN
return to IDLE and INACTIVE state. The MM and PDP contexts in the SGSN may be
deleted. The GGSN PDP contexts are deleted.
2. Cancel Location, i.e. the SGSN receives the MAP-message “Cancel Location”
from the HLR and removes the MM and PDP contexts.
STANDBY to READY:
1. PDU transmission (state change at MS side): The MS sends an LLC PDU to the
SGSN, possibly in response to paging.
2. PDU reception (state change at SGSN side): The SGSN receives an LLC PDU
from the MS.
READY to STANDBY:
1. READY timer expiry, i.e. the MS and the SGSN MM contexts return to STANDBY
state after timer expiry.
2. Force to STANDBY, i.e. the MS or the SGSN indicates an immediate return to
STANDBY state. The MS or the SGSN may signal a return to STANDBY state before
the READY timer expires.
16 TM3110EU02TM_0001
© 2002 Siemens AG
IDLE IDLE
GPRS Attach GPRS Attach GPRS Detach

or
GPRS Detach Cancel
Location
READY Implicit Detach READY

or
Cancel Location
READY timer expiry
READY timer expiry PDU
or
or reception
Force to STANDBY PDU
Force to STANDBY
transmission or
Abnormal RLC condition
STANDBY STANDBY
MM State Model of MS MM State Model of SGSN
Fig. 7 Functional mobility management state model
TM3110EU02TM_0001
17
© 2002 Siemens AG
State changes of mobility management (continuation)

3. Abnormal RLC (radio link control) condition, i.e. the SGSN MM context returns to
STANDBY state in case of delivery problems on the radio interface or in case of
irrecoverable disruption of a radio transmission.
READY to IDLE:
1. GPRS Detach, i.e. the MS requests that the MM context in the SGSN return to
IDLE state and that the PDP contexts in the SGSN return to INACTIVE state. The
SGSN may delete the MM and PDP contexts. The PDP contexts in the GGSN are
deleted.
2. Cancel Location, i.e. the SGSN receives the MAP message "Cancel Location"
message from the HLR, and removes the MM and PDP contexts.
GMM Timers related to the different GMM states:

The READY timer controls the time an MS remains in READY state in the MS and
the SGSN. The length of the READY timer is the same in the MS and SGSN. The
initial length of the READY timer is defined by a default value. The SGSN, and
only the SGSN, may change the length of the READY timer by transmitting a new
value in the Attach Accept or Routing Area Update Accept messages.
The Periodic RA Update Timer monitors the periodic RA update procedure in the
MS. The length of the periodic RA update timer is sent by the SGSN in the Routing
Area Update Accept or Attach Accept message. The periodic RA update timer is
unique within an RA. Upon expiry of the periodic RA update timer the MS starts a
periodic routing area update procedure.
The Mobile Reachable Timer 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. If the mobile reachable timer expires, the SGSN
clears PPF (Paging Proceed Flag). Typically, in GPRS, this causes the SGSN to
stop sending GPRS paging or CS paging messages to the MS. PPF is set when
the next activity from the MS is detected. When an MS first registers in an SGSN,
then PPF is set.
18 TM3110EU02TM_0001
© 2002 Siemens AG
TIMER TIMER MS SGSN CAUSE OF NORMAL ON

VALUE side side START STOP EXPIRY
T3312: Default X When READY When Initiation of the
Periodic 54 min state is left. entering Periodic RAU
RAU Timer (Note 1) state IDLE. procedure.
T3314: Default X Transmission of Forced to No cell-updates
READY 44 sec a PDU. Standby. are performed.
Timer (Note 2)
T3314: Default X Reception of a Forced to The network shall
READY 44 sec PDU. Standby. page the MS if a
Timer (Note 2) PDU has to be
sent to the MS.
Mobile Default 4 X Change from PDU Network
Reachable min READY to received. dependent but
Timer greater STANDBY state. typically paging is
than halted on 1st
T3312 expiry.
NOTE 1: The value of this timer is used if the network does not indicate another value in a GMM
signalling procedure.
NOTE 2: The default value of this timer is used if neither the MS nor the Network sends a value in a
GMM signalling procedure.
Fig. 8 GMM timers related to the different GMM states
TM3110EU02TM_0001
19
© 2002 Siemens AG
GSM Area Identifiers

The Routing Area (RA) is defined as an area in which a mobile station moves
freely without updating the SGSN. A Routing Area Identity (RAI) is defined by the
operator and identifies one or several cells. A Routing Area is a subset of one -
and only one - Location Area (LA), i.e. a RA cannot span more than one LA. A RA
is served by only one SGSN. The following rules apply for the Routing Area
Identity:
- RAC is only unique when presented together with LAI.
- CI is only unique when presented together with LAI or RAI.
- LAI = MCC + MNC + LAC.
- RAI = MCC + MNC + LAC + RAC.
- CGI = LAI + CI.
The Location Area (LA) is defined as an area in which a mobile station moves
freely without updating the VLR. A location area may include one or several cells.
The BSC area is an area of radio coverage consisting of one or more cells
controlled by one BSC. The boundaries of a BSC area and a location area are
independent; a location area may span the boundary between BSC area and a
BSC area may span the boundary between location areas.
The MSC area is the part of the network covered by an MSC. An MSC area may
consist of one or several location areas. An MSC area may also consist of one or
several BSC areas.
The VLR area is the part of the network controlled by a VLR. A VLR area may
consist of one or several MSC areas.
The SGSN area is the part of the network served by an SGSN. A SGSN area may
consist of one or several routing areas. An SGSN area may also consist of one or
several BSC areas. There need not be a one to one relationship between SGSN
area and MSC/VLR area.
20 TM3110EU02TM_0001
© 2002 Siemens AG
RA1 BSS
BTS
Abis
s
RA2 BTS Gb
BTS
BSC Gb
BTS SGSN
BTS
LA1
LA2
BTS
Abis
s
BTS A
RA3
s
BTS
BSC
BTS A
RA4 BTS MSC/VLR
Fig. 9 Routing Area Identity
TM3110EU02TM_0001
21
© 2002 Siemens AG
22 TM3110EU02TM_0001
© 2002 Siemens AG
2 Signaling Procedures Supporting GMM

Functionality
TM3110EU02TM_0001
23
© 2002 Siemens AG
2.1 Registration Procedures

2.1.1 GPRS Attach Procedure
The GPRS attach procedure is used to establish a GMM context in the MS and the
SGSN. After a successful GPRS attach the GPRS mobile subscriber data is stored in
the SLR (SGSN location register).
The MS initiates the attach procedure by the transmission of an Attach Request:
The IMSI identifies the MS, if it has no valid P-TMSI. Otherwise, the P-TMSI with
the associated RAI (Routing Area Identity) is sent.
The class mark contains GPRS multislot capabilities and supported GPRS
ciphering algorithms in addition to the standard GSM class mark parameters.
The attach type indicates which type of attach has to be performed: e.g. GPRS
attach, GPRS attach while IMSI attach already done or combined GPRS/IMSI
attach.
If the MS identifies itself with P-TMSI and the SGSN has changed since the last
detach, the new SGSN sends an Identification Request including P-TMSI and old
RAI to the old SGSN. The old SGSN responds with Identification Response
including the IMSI and authentication triplets. If the MS is not known in the old SGSN,
the old SGSN responds with an appropriate error cause.
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 the network supports
ciphering, ciphering mode is set.
If the SGSN number has changed since the last GPRS detach, or if it is the very first
attach, routing area update procedures are executed:
The SGSN sends an Update GPRS Location (SGSN Number, SGSN Address,
IMSI) to the HLR.
The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with
cancellation type set to "update procedure".
The old SGSN acknowledges with Cancel Location Ack (IMSI).
The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the
new SGSN.
The new SGSN validates the MS's presence in the new routing area. If there is no
restriction for that MS in the new routing area the SGSN answers with Insert
Subscriber Data Ack (IMSI).
The HLR acknowledges the Update GPRS Location message by sending an Update
GPRS Location Ack to the new SGSN.
The SGSN selects the radio priority level for uplink SMS, and sends an Attach
Accept (P-TMSI, TMSI, radio priority SMS) to the MS. P-TMSI is included if the
SGSN allocates a new P-TMSI.
24 TM3110EU02TM_0001
© 2002 Siemens AG
old SGSN
BSS
MS GMM new SGSN
Attach Request HLR
(IMSI or P-TMSI, old RAI, attach type)
GTP
Identification Request
(P-TMSI, old RAI)
GTP
Identification Response
(IMSI, Auth. Triples)
Authentication
MAP
Update GPRS Location
(SGSN No., SGSN address, IMSI)
MAP
Cancel Location
(IMSI, Type) MAP
Cancel Location Ack
(IMSI)
MAP
Insert Subscriber Data
(IMSI, GPRS subscription data)
MAP
Insert Subs. Data Ack.
(IMSI) MAP
Update GPRS Location Ack
GMM
Attach Accept
(P-TMSI, radio priority SMS)
GMM
Attach Complete
Fig. 10 GPRS attach procedure
TM3110EU02TM_0001
25
© 2002 Siemens AG
GPRS Attach Procedure to be continued

If P-TMSI or TMSI was changed, the MS acknowledges the received temporary
identities (P-TMSI or TMSI) with the Attach Complete message. If the TMSI was
changed, the SGSN confirms the TMSI reallocation by sending TMSI Reallocation
Complete (IMSI) to the VLR.
Timers and Counters supervising the GPRS Attach Procedure
TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON THE

NUM. VALUE side side st nd rd th
1 ,2 ,3 ,4
EXPIRY Note 2
T3310 15s X ATTACH REQUEST sent ATTACH ACCEPT Retransmission of
received ATTACH REQ
ATTACH REJECT
received
T3311 15s X ATTACH REJECT with: Change of the routing Restart of the Attach
Reject causes not belonging to area procedure with
causes related to MS identification, updating of the
e.g. "Illegal MS" or subscription, e.g. relevant attempt
"GPRS services not allowed" counter
and
attach attempt counter < 5.
T3350 6s X ATTACH ACCEPT ATTACH COMPLETE Retransmission of the
sent with P-TMSI and/or TMSI received ATTACH ACCEPT
message.
TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON

NUM. VALUE side side EXPIRY
T3302 Default X At attach failure and the attempt At successful attach On every expiry,
12 min counter is greater than or equal initiation of the
Note 1 to 5. GPRS attach
procedure
NOTE 1: The value of this timer is used if the network does not indicate another value in a GMM
signaling procedure.
NOTE 2: Typically, the procedures are aborted on the fifth expiry of the relevant timer.
26 TM3110EU02TM_0001
© 2002 Siemens AG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM3110EU02TM_0001
27
© 2002 Siemens AG
2.1.2 Detach Procedure

The detach function allows a MS to inform the network, that it wants to make a GPRS
and/or IMSI detach, and it allows the network to inform a MS that is has been GPRS
or IMSI detached by the network. The following types of detach are defined:
IMSI detach,
GPRS detach,
combined GPRS/IMSI detach (MS initiated only).
Apart from the previous explicit detach procedures, implicit detach by the network
detaches the MS without notifying the former. That happens if the mobile reachable
timer expires or after an irrecoverable radio error causes disconnection of the logical
link.
2.1.2.1 MS-Initiated Detach Procedure

The MS detaches by sending Detach Request (Detach Type, e.g. "Switch Off") to
the SGSN if the MS is switched off, the SIM card is removed from the MS or if the
GPRS or non-GPRS capability of the MS is disabled. Detach Type indicates which
type of detach that is to be performed, i.e. GPRS Detach only, IMSI Detach only or
combined GPRS/IMSI Detach. "Switch Off" indicates whether the detach is due to a
switch off situation or not. After sending the Detach Request the Timer T3321 will be
started in the MS waiting for the Detach Accept.
In case of 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. A tunnel identifier (TEID) identifies each PDP context. The
GGSNs acknowledges with Delete PDP Context Response (TEID).
For Detach Type = IMSI detach, the SGSN sends IMSI Detach Indication (IMSI) to
the VLR. The VLR answers with an IMSI Detach Ack.
If the MS wants to remain IMSI-attached and is doing a GPRS detach, the SGSN
sends a GPRS Detach Indication (IMSI) to the VLR. The VLR removes the
association with the SGSN and sends a GPRS Detach Ack back to the SGSN. Now
the VLR handles paging and location update without going via the SGSN.
If Switch Off indicates that the detach is not due to a switch off situation, the SGSN
sends a Detach Accept to the MS.
28 TM3110EU02TM_0001
© 2002 Siemens AG
GGSN
BSS
MS
SGSN
MSC/VLR
GMM
Detach Request
(Detach Type, Switch off?)
GTP
Delete PDP Context Request
(TEID)
GTP
Delete PDP Context Response
(TEID)
BSSAP+
IMSI Detach Indication
(IMSI)
BSSAP+
IMSI Detach Ack
(IMSI)
or
BSSAP+
GPRS Detach Indication
(IMSI)
BSSAP+
GPRS Detach Ack
GMM (IMSI)
Detach Accept
Fig. 11 MS initiated detach procedure
TM3110EU02TM_0001
29
© 2002 Siemens AG
2.1.2.2 SGSN-Initiated Detach Procedure

SGSN-Initiated Detach Procedure is used by the network to request the release of a
GMM context and in case of a network failure condition to indicate to the MS that a
re-attach with successive activation of previously active PDP contexts shall be
performed.. The SGSN informs the MS that it has been detached by sending Detach
Request (Detach Type) to the MS. The Detach Type indicates if the MS is requested
to make a new attach, e.g. in case of a network failure condition, and PDP context
activation for previously activated PDP contexts. If so, the attach procedure will be
initiated when the detach procedure is completed. After sending the Detach Request
the Timer T3322 will be started in the SGSN waiting for the Detach Accept
The active PDP contexts in the GGSNs regarding this particular MS are deactivated
by the SGSN sending Delete PDP Context Request (TEID) messages to the
GGSNs. The GGSNs acknowledge with Delete PDP Context Response (TEID)
messages.
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.
The MS sends a Detach Accept message to the SGSN any time after the reception
of Detach Request.
Timers and Counters supervising the Detach Procedure

1 ,2 ,3 ,4
EXPIRY Note 1
T3321 15s X DETACH REQ sent DETACH ACCEPT Retransmission of the
received DETACH REQ
T3322 6s X DETACH REQ sent DETACH ACCEPT Retransmission of
received DETACH REQUEST
30 TM3110EU02TM_0001
© 2002 Siemens AG
GGSN
BSS
MS
SGSN
MSC/VLR
GMM
Detach Request
(Detach Type)
GTP
(TEID)
GTP
(TEID)
BSSAP+
(IMSI)
BSSAP+
GPRS Detach Ack
(IMSI)
GMM
Detach Accept
Fig. 12 SGSN-initiated detach procedure
TM3110EU02TM_0001
31
© 2002 Siemens AG
2.1.2.3 HLR-Initiated Detach Procedure

If the HLR wants to request the immediate deletion of a subscriber's MM and PDP
contexts from the SGSN, the HLR sends a MAP message "Cancel Location" (IMSI,
Cancellation Type) to the SGSN with Cancellation Type set to "Subscription
withdrawn".
The SGSN informs the MS that it has been detached by sending Detach Request
(Detach Type) to the MS. The detach type indicates that the MS is not requested to
make a new attach and PDP context activation.
The active PDP contexts in the GGSNs regarding this particular MS are deactivated
by the SGSN sending Delete PDP Context Request messages including the tunnel
identifier (TEID) to the GGSNs. The GGSNs acknowledge with Delete PDP Context
Response messages with the respective TEID.
If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach
Indication (IMSI) to the VLR. The VLR removes the association with the SGSN and
handles paging and location update without going via the SGSN.
The MS sends a Detach Accept message to the SGSN any time after it has received
the Detach Request message.
At the end of the HLR-initiated Detach Procedure, the SGSN confirms the deletion of
the MM and PDP contexts with a Cancel Location Ack (IMSI) towards the HLR.
32 TM3110EU02TM_0001
© 2002 Siemens AG
GGSN
HLR
BSS
MS
SGSN MAP
Cancel Location MSC/VLR
GMM
(IMSI, Type)
Detach Request
(Detach Type)
GTP
(TEID)
GTP
(TEID)
BSSAP+
(IMSI)
GMM
Detach Accept
MAP
Cancel Location Ack
(IMSI)
Fig. 13 HLR-initiated detach procedure
TM3110EU02TM_0001
33
© 2002 Siemens AG
2.2 Security Procedures

2.2.1 Identity Check Procedure
The Identity Check Procedure is optional.
It is used in 2 cases:
A) During Attach Procedure:
If the MS has no valid P-TMSI, or the new SGSN cannot evaluate the old SGSN, or
the MS is not known at both SGSN (old and new) the SGSN initiates the Identity
Check procedure at the Gb interface. The goal is to get the IMSI of the subscriber to
enable the dialog with the corresponding HLR. For that the SGSN sends an Identity
Request (Identity Type = IMSI) to the MS. The MS responds with Identity Response
(IMSI). After the SGSN has received the IMSI, it requests for authentication triplets at
the HLR by Send Authentication Info.
B) For IMEI Check:

If the SGSN decides to check the IMEI against the EIR it starts first the Identity
Check procedure with an Identity Request towards the MS requesting now with
Identity Type = IMEI. With an Identity Response, the MS delivers the IMEI to the
SGSN. After this the SGSN sends the MAP message "Check IMEI" to the EIR. With
Check IMEI Ack the EIR answers towards the SGSN and indicates whether the MS
belongs to the white, gray or black list.
Timer and Counter supervising the Identity Check Procedure

1 ,2 ,3 ,4
EXPIRY Note 1
T3370 6s X IDENTITY REQUEST sent IDENTITY Retransmission of

RESPONSE received IDENTITY REQUEST
34 TM3110EU02TM_0001
© 2002 Siemens AG
HLR
s
BSS
MS
SGSN EIR
GMM
Identity Request
(Identity Type = IMSI or IMEI)
GMM
Identity Response
MAP
(IMSI or IMEI) Send Authentication Info
(IMSI)
A) MAP
Send Authentication Info Ack
(Authentication Triplets)
or
MAP
Check IMEI
(IMEI)
B) MAP
Check IMEI Ack
(equipment status)
Fig. 14 Identity check procedure
TM3110EU02TM_0001
35
© 2002 Siemens AG
2.2.2 Authentication Procedure

The authentication procedure already used for GSM networks is used at the SGSN
for authentication. The GPRS authentication procedure performs subscriber
authentication, or selection of the ciphering algorithm and the synchronization of the
ciphering start, or both. The authentication triplets are stored in the SGSN database.
If the SGSN doesn't have previously stored authentication triplets, the MAP message
Send Authentication Info (IMSI) is send to the HLR. The HLR responds with the
MAP message Send Authentication Info Ack (Authentication Triplets). Each
Authentication Triplet includes RAND, SRES and Kc. As a result the triplets are
stored in the SGSN.
The SGSN sends Authentication and Ciphering Request containing the RAND,
CKSN and the ciphering algorithm to the MS. After sending Authentication and
Ciphering Request timer T3360 is started in the SGSN waiting for the Authentication
and Ciphering Response.
The MS responds with the Authentication and Ciphering Response containing the
calculated SRES.
Additionally, the authentication procedure performs the selection of the ciphering
algorithm and the synchronization for the start of ciphering. The MS starts ciphering
after sending the Authentication and Ciphering Response message. The SGSN starts
ciphering when a valid Authentication and Ciphering Response is received from the
MS.
Timers and Counters supervising the Authentication Procedure

1 ,2 ,3 ,4
EXPIRY Note 1
T3360 6s X AUTH AND CIPH REQUEST AUTH AND CIPH Retransmission of

sent RESPONSE received AUTH AND CIPH
AUTHENT- AND REQUEST
CIPHER- FAILURE
received
36 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
MS
HLR
SGSN
MAP
Send Authentication Info

(IMSI)
MAP
Send Authentication Info Ack
(Authentication Triplets)
GMM
Authentication and Ciphering Request
(RAND, CKSN, Ciphering Algorithm)
GMM
Authentication and Ciphering Response
(SRES)
Fig. 15 Authentication procedure
TM3110EU02TM_0001
37
© 2002 Siemens AG
2.2.3 P-TMSI Reallocation Procedure

The purpose of the P-TMSI reallocation procedure is to provide identity
confidentiality, i.e. to protect a user against being identified and located by an
intruder.
The structure of the P-TMSI is specified in 3GPP TS 03.03 (Release 1998 and
earlier) or by 3GPP TS 23.003 (Release 1999 and later). The P-TMSI has
significance only within a routing area. Outside the routing area it has to be combined
with the routing area identification (RAI) to provide unambiguous identity.
Usually, P-TMSI reallocation is performed at least at each change of a routing area.
(such choices are left to the network operator).
P-TMSI can also be implicitly reallocated in the attach or routing area updating
procedures.
The network initiates the P-TMSI reallocation procedure by sending a P-TMSI
reallocation command message to the MS and starts the timer T3350.The P-TMSI
reallocation command message contains a new combination of P-TMSI, RAI and
optionally a P-TMSI signature allocated by the network.
No user data transfer occurs during the P-TMSI reallocation procedure.
Upon reception of the P-TMSI reallocation command message, the MS stores the
Routing Area Identifier (RAI) and the P-TMSI and sends a P-TMSI reallocation
complete message to the network. If a P-TMSI signature is present in the P-TMSI
reallocation command message, the MS stores the new P-TMSI signature and - if
available - deletes the old P-TMSI signature. The P-TMSI Signature is an optional
parameter which is used only during one single signaling procedure and if received
by the MS will be returned to the SGSN in the next Attach and Routing Area Update
procedure.
Upon reception of the P-TMSI reallocation complete message, the network stops the
timer T3350 and considers the new P-TMSI as valid and the old one as invalid.
The GMM layer has to notify the LLC layer that the P-TMSI has been changed.
Timer and Counter supervising the P-TMSI Reallocation Procedure

1 ,2 ,3 ,4
EXPIRY Note 1
T3350 6s X P-TMSI REALLOC COMMAND P-TMSI REALLOC Retransmission of P-
sent COMPLETE received TMSI REALLOC
COMMAND
38 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
MS
SGSN
GMM
P-TMSI reallocation command
(new P-TMSI, P-TMSI Signature, RAI)
GMM
P-TMSI reallocation complete
Fig. 16 P-TMSI reallocation procedure
TM3110EU02TM_0001
39
© 2002 Siemens AG
2.2.4 MS Information Procedure

When the MS is marked at the VLR as both IMSI- and GPRS-attached, the VLR may
perform the MS Information procedure via the SGSN. Typically, the requested
information type is the IMEI, i.e. the SGSN will interrogate the MS for that identity not
known by the SGSN itself. If the information requested by the VLR in the MS
Information procedure is known by the SGSN, then the SGSN returns the information
to the VLR without interrogating the MS.
The MSC/VLR sends an MS Information Request message (IMSI, Information
Type) to the SGSN. The parameter Information Type indicates the information that
the MSC/VLR is requesting for that IMSI. The requested information could be the
IMSI.
If the information requested is not known by the SGSN but known by the MS, the
SGSN interrogates the MS in a similar manner to that described in the subclause
"Identity Check Procedure". The SGSN sends an Identity Request (Identity Type) to
the MS.
The MS answers with an Identity Response (Mobile Identity) to the SGSN.
The SGSN sends now the MAP message MS Information Response (IMSI,
Information) to the MSC/VLR. Information contains the information requested by the
MSC/VLR.
Timer and Counter supervising the Identity Check Procedure

1 ,2 ,3 ,4
EXPIRY Note 1
T3370 6s X IDENTITY REQUEST sent IDENTITY Retransmission of

RESPONSE received IDENTITY REQUEST
40 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
MS
SGSN MSC/VLR
BSSAP+
MS Information Request
(IMSI, Information Type)
GMM
Identity Request
(Identity Type)
GMM
Identity Response
(Mobile Identity)
BSSAP+
MS Information Response
(IMSI, Information)
Fig. 17 MS information procedure
TM3110EU02TM_0001
41
© 2002 Siemens AG
2.3 Location Management Procedures

The Location Management of the GMM provides tracking of the location of the MS on
two levels: On cell or routing area (RA) level.
Therefore the PLMN has to provide information for the MS to be able to:
detect when it has entered a new cell or a new RA; and
determine when to perform periodic RA updates.
The MS detects that a new cell has been entered by comparing the cell's identity
broadcasted on BCCH (Broadcast Control Channel) with the cell identity stored in the
MS's MM context. The MS detects that a new RA has been entered by comparing the
RAI stored in its MM context with that received from the new cell on BCCH.
When the MS camps on a new cell or RA respectively this indicates one of three
possible scenarios:
1. a cell update is required;
2. a routing area update is required; or
3. a combined routing area and location area update is required.
In all three scenarios the MS stores the new cell identity in its MM context.
Whenever an MS determines that it has to perform both an LA update and an RA
update the MS:
initiates a combined RA and LA update if the Gs interface exists or
initiates the LA update first and then initiates the RA update in case no Gs
interface exists.
If the MS enters a new PLMN, the MS shall either perform a routing area update or
enter IDLE state.
42 TM3110EU02TM_0001
© 2002 Siemens AG
RA1 BSS s
D
A Gs
BTS
Abis MSC/VLRold
s
RA2 BTS
Gb
Gr s
BTS
BSC SGSNold
BTS
HLR
LA1
BTS
Gn
Gn
LA2
BTS
s GGSN
BTS
RA3
BTS
BSC SGSNnew s
BTS
RA4 BTS
MSC/VLRnew
Fig. 18 Update scenarios: Cell change, RA change or combined RA/LA change.
TM3110EU02TM_0001
43
© 2002 Siemens AG
2.3.1 GPRS Paging Procedure

An MS in STANDBY state is paged by the SGSN before a downlink data transfer to
that MS. The paging procedure moves the MM state to READY to allow the SGSN to
forward downlink data via the radio resource. Therefore any uplink data from the MS
that moves the MM context at the SGSN to READY state is a valid response to
paging.
The SGSN supervises the paging procedure with a timer. If the SGSN receives no
response from the MS to the Paging Request message, it repeats the paging.
The MS accepts paging also in READY state if no radio resource is assigned. This
supports e.g. recovery from inconsistent MM states in MS and SGSN.
At the beginning of Paging, the SGSN receives a downlink PDP PDU or a SMS MT
(PS) for a MS in STANDBY state. Another possibility would be any downlink signaling
to a STANDBY MS. That leads to an initiation of paging as well.
The SGSN sends a BSSGP Paging PS PDU (IMSI, P-TMSI, Area, QoS, DRX
parameters) to the BSS serving the MS. The IMSI is necessary for the BSS in order
to calculate the MS paging group. The P-TMSI is the identifier by which the MS is
paged. Area indicates the area (cell, RA, LA level or whole BSS area) in which the
MS should be paged. Quality of Service (QoS) is the negotiated QoS for the PDP
context that initiates the paging procedure and assigns the priority to this Paging
Request relatively to other Paging Request messages buffered in the BSS. DRX
parameters indicate whether the MS uses discontinuous reception or not.
The BSS pages now the MS with Packet Paging Request (P-TMSI, Channel
Needed) on PCCH or Paging Request (P-TMSI, Channel Needed) on PCH in each
cell belonging to the addressed area.
Upon receipt of a GPRS Packet Paging Request message, the MS responds with
any single valid LLC frame (e.g. a Receive Ready or an NULL frame according to
Rel99 and later) implicitly interpreted as a paging response message by the SGSN.
When responding, the MS changes the MM state to READY. The response is
preceded by the Packet Channel Request and Packet Immediate Assignment
procedures as described in GSM 03.64.
Upon reception of the LLC frame, the BSS adds the Cell Global Identity including the
RAC (routing area code) and LAC (location area code) of the cell and sends the LLC
frame to the SGSN. The SGSN considers the LLC frame to be an implicit paging
response message and stops the paging response timer.
Timer supervising the GPRS Paging Procedure

TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON
NUM. VALUE side side EXPIRY
T3313 Network X Paging procedure initiated Paging procedure Network dependent
depende completed
nt
44 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
MS
SGSN
PDP PDU or MT SMS
BSSGP
Paging PS
(IMSI, opt.P-TMSI, Area, DRX Parameters...)
GRR
Packet Paging Request or
RR
Paging Request
(P-TMSI)
LLC Frame
LLC Frame
Fig. 19 GPRS paging
TM3110EU02TM_0001
45
© 2002 Siemens AG
2.3.2 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 routing area update is executed
instead of a cell update.
If the network does not support the Cell Notification which is an optimized Cell
Update Procedure the MS performs the cell update procedure by sending an uplink
LLC frame of any type except the LLC NULL frame to the SGSN. If the network and
the MS support the Cell Notification, then the MS uses 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 and the MS have to
support the Cell Update Procedure without using the LLC NULL frame for backward
compatibility reasons.
In the direction towards the SGSN, the BSS adds the Cell Global Identity including
RAC and LAC to all BSSGP frames. A cell update is any correctly received and valid
LLC PDU carried inside a BSSGP PDU containing a new identifier of the cell.
The SGSN records this MS's change of cell and further traffic towards the MS is
conveyed over the new cell.
46 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
MS
SGSN
LLC Frame
BSSGP UL-UNITDATA PDU
CGI LLC Frame
MCC MNC LAC RAC CI
Fig. 20 Cell update procedure
TM3110EU02TM_0001
47
© 2002 Siemens AG
2.3.3 SGSN Routing Area Update Procedures

A routing area update takes place when a GPRS-attached MS detects that it has
entered a new RA (routing area), when the periodic RA update timer has expired, or
when a suspended MS is not resumed by the BSS.
A combined routing area / location area update takes place when the MS is both
GPRS attached and IMSI attached and enters a new RA (network in network
operation mode I) or when a GPRS attached MS performs IMSI attach. The MS
sends a Routing Area Update Request indicating that a location area update may
also need to be performed in which case the SGSN forwards the location area
update to the VLR. This concerns only idle mode for circuit switched (CS), as no
combined RA/LA updates are performed during a CS connection.
2.3.3.1 Intra SGSN Routing Area Update Procedure

The SGSN detects that it is an intra SGSN routing area update by noticing that it also
handles the old RA. In this case, the SGSN has the necessary information about the
MS and there is no need to inform the GGSNs or the HLR about the new MS
location. A periodic RA update is always an intra SGSN routing area update.
The MS sends a Routing Area Update Request (old RAI, old P-TMSI Signature,
Update Type) to the SGSN. Update Type indicates RA update or periodic RA update.
The BSS adds an identifier of the cell (Cell Global Identity), where the message was
received from, before passing the message to the SGSN. The SGSN is able to derive
the new RAI from the added cell identifier.
Security functions are possibly executed, e.g. authentication or P-TMSI reallocation.
The SGSN validates the MS's presence in the new RA. If due to regional, national or
international restrictions the MS is not allowed to attach in the RA or subscription
checking fails, then the SGSN rejects the routing area update with an appropriate
cause. If all checks are successful then the SGSN updates the MM context for the
MS. A new P-TMSI may be allocated. Now Routing Area Update Accept (P-TMSI,
P-TMSI Signature (optional)) is returned to the MS.
If P-TMSI was reallocated, the MS acknowledges the new P-TMSI with Routing
Area Update Complete (P-TMSI).
If the routing area update procedure fails a maximum allowable number of times, or if
the SGSN returns a Routing Area Update Reject (Cause) message, the MS moves to
IDLE state.
48 TM3110EU02TM_0001
© 2002 Siemens AG
BSS
MS SGSN
GMM
Routing Area Update Request
(old RAI, Update Type)
Security Functions
GMM
Routing Area Update Accept
(P-TMSI)
GMM
Routing Area Update Complete
Fig. 21 Intra SGSN routing area update
TM3110EU02TM_0001
49
© 2002 Siemens AG
2.3.3.2 Inter SGSN Routing Area Update Procedure

Update Type) to the new SGSN. Update Type indicates RA update or periodic RA
update. The BSS adds an identifier of the cell where the message was received from
before passing the message to the SGSN. The SGSN is able to derive the new RAI
and LAI from the added Cell Global Identity.
The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI
Signature, new SGSN Address) to the old SGSN to get the MM and PDP contexts for
the MS. The old SGSN validates the old P-TMSI Signature and responds with an
appropriate error cause if it does not match the value stored in the old SGSN. If so, it
initiates the security functions in the new SGSN. If the security functions authenticate
the MS correctly, the new SGSN sends an SGSN Context Request (old RAI, TLLI,
MS validated, new SGSN Address) message to the old SGSN. MS validated
indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature
was valid or if the new SGSN indicates that it has authenticated the MS, the old
SGSN responds with SGSN Context Response (MM Context, PDP Contexts). The
old SGSN stores the new SGSN Address, to allow the old SGSN to forward data
packets to the new SGSN. Each PDP Context includes the SNDCP Sequence
number (Send N-PDU Number) number for the next downlink N-PDU to be sent to
and the SNDCP Sequence number (Receive N-PDU Number) for the next uplink N-
PDU to be expected from the MS. Each PDP Context also 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 tunneled to the GGSN. The old
SGSN starts a timer and stops the transmission of N-PDUs to the MS.
Security functions, e.g. authentication, may be executed.
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. If the security functions do not authenticate
the MS correctly, then the routing area update is rejected, and the new SGSN sends
a reject indication to the old SGSN. The old SGSN continues as if the SGSN Context
Request was never received.
The old SGSN starts tunneling of buffered N-PDUs to the new SGSN. Additional N-
PDUs received from the GGSN are also tunneled to the new SGSN. N-PDUs that
were already sent to the MS in acknowledged mode and that are not yet
acknowledged by the MS are tunneled together with the SNDCP N-PDU sequence
number. No N-PDUs are forwarded to the new SGSN after expiry of the timer
described above.
The new SGSN sends Update PDP Context Request (new SGSN Address, TEID,
QoS Negotiated) to the GGSNs concerned. The GGSNs update their PDP context
fields and return Update PDP Context Response (TEID).
50 TM3110EU02TM_0001
© 2002 Siemens AG
old SGSN
HLR
BSS
MS
new SGSN
GMM
GGSN
(old RAI, Type)
GTP
SGSN Context Request
(old RAI, TLLI,
new SGSN address)
GTP
SGSN Context Response
(MM Context, PDP context)
Security Functions
GTP
SGSN Context Ack
Forward Packets
GTP
Update PDP Context Request
(new SGSN address, TEID, QoS neg.)
GTP
Update PDP Context Response
(TEID)
Fig. 22 Inter SGSN routing area update (part 1)
TM3110EU02TM_0001
51
© 2002 Siemens AG
The new SGSN informs the HLR of the SGSN change by sending Update GPRS
Location (SGSN Number, SGSN Address, IMSI) to the HLR.
Cancellation Type set to Update Procedure. If the timer described above is not
running, then the old SGSN removes the MM and PDP contexts. Otherwise, the
contexts are removed only when the timer expires. This allows the old SGSN to
complete the forwarding of N-PDUs. It also ensures that the MM and PDP contexts
are kept in the old SGSN in case the MS initiates another inter SGSN routing area
update before completing the ongoing routing area update to the new SGSN. The old
SGSN acknowledges with Cancel Location Ack (IMSI).
The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new
SGSN. The new SGSN validates the MS's presence in the (new) RA. If due to
regional subscription the MS is rejected the SGSN rejects the Routing Area Update
Request with an appropriate cause and returns an Insert Subscriber Data Ack (IMSI,
SGSN Area Restricted due to regional subscription) 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.
The HLR acknowledges the Update Location by sending Update GPRS Location
Ack (IMSI) to the new SGSN.
The new SGSN validates the MS's presence in the new RA. If all checks are
successful then the new SGSN constructs MM and PDP contexts for the MS. A
logical link is established between the new SGSN and the MS. The new SGSN
responds to the MS with Routing Area Update Accept (P-TMSI, Receive N-PDU
Number, P-TMSI Signature). 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.
The MS acknowledges the new P-TMSI with a Routing Area Update Complete
(Receive N-PDU Numbers). Receive N-PDU Number contains the
confirming all mobile-terminated N-PDUs successfully transferred before the start of
the update procedure. If Receive N-PDU Number confirms reception of N-PDUs that
were forwarded from the old SGSN then these N-PDUs are discarded by the new
SGSN. LLC and SNDCP in the MS are reset.
In the case of a rejected routing area update operation, due to regional subscription
or roaming restrictions, the new SGSN does not construct an MM context. A reject
will be returned to the MS with an appropriate cause. The MS shall not re-attempt a
routing area update to that RA. The RAI value will be deleted when the MS is
powered-up.
If the SGSN is unable to update the PDP context in one or more GGSNs, then the
SGSN deactivates the corresponding PDP contexts using the Procedure “PDP
Context Deactivation Initiated by SGSN" indicating an appropriate cause. This shall
not cause the SGSN to reject the routing area update.
52 TM3110EU02TM_0001
© 2002 Siemens AG
old SGSN
HLR
BSS
MS GGSN
new SGSN
MAP
(SGSN number, SGSN address., IMSI)
MAP
Cancel Location
(IMSI, Cancellation Type)
MAP
Cancel Location Ack
(IMSI)
MAP
MAP
Insert Subscriber Data Ack
(IMSI, SGSN area restricted)
MAP
GMM (IMSI)
(P-TMSI, Receive N-PDU Number list)
GMM
(Receive N-PDU Number list)
Fig. 23 Inter SGSN routing area update (part 2)
TM3110EU02TM_0001
53
© 2002 Siemens AG
Inter SGSN Routing Area Update Procedure (continuation)

If the timer described above expires and no Cancel Location (IMSI) was received
from the HLR, then the old SGSN stops forwarding N-PDUs to the new SGSN and
proceed as if the SGSN Context Request message was not received.
the SGSN returns a Routing Area Update Reject (Cause) message, the MS enters
IDLE state.
54 TM3110EU02TM_0001
© 2002 Siemens AG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM3110EU02TM_0001
55
© 2002 Siemens AG
2.3.3.3 Combined Intra SGSN RA/LA Update Procedure

Update Type) to the SGSN. Update Type indicates combined RA/LA update or - if the
MS wants to perform an IMSI attach - combined RA/LA update with IMSI attach
requested. The BSS adds an identifier of the cell identifier (CGI) where the message
was received before passing the message to the SGSN. The SGSN derives the new
RAI and LAI from the added cell identifier.
Security functions, e.g. authentication may be executed.
If the association between SGSN and VLR has to be established, if Update Type
indicates combined RA/LA update with IMSI attach requested, or if the LA changed
with the routing area update, then the SGSN sends a Location Update Request
(new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update
Type indicates IMSI attach if Update Type indicated combined RA / LA update with
IMSI attach requested. Otherwise, Location Update Type indicates normal location
update. The VLR number is translated from the RAI via a table in the SGSN. The
VLR creates or updates the association with the SGSN by storing SGSN Number.
If the LA update is an inter-MSC location update, the new VLR informs the HLR. The
HLR cancels the data in the old VLR and inserts subscriber data in the new VLR (this
signaling is not modified from existing GSM signaling and is included here just for
illustrative purposes):
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).
The old VLR acknowledges with Cancel Location Ack (IMSI).
The HLR sends Insert Subscriber Data (IMSI, GSM sub. 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.
The new VLR allocates a new TMSI and responds with Location Updating Accept
(TMSI) to the SGSN.
The SGSN validates the MS's presence in the new RA. If there are no regional,
national or international restrictions for GPRS attachment and all checks are
successful then the SGSN updates the MM context for the MS. A new P-TMSI may
be allocated. The SGSN responds to the MS with Routing Area Update Accept (P-
TMSI, TMSI, P-TMSI Signature).
The MS confirms the reallocation of the temporary MS identities (P-TMSI/IMSI) by
sending Routing Area Update Complete to the SGSN.
The SGSN sends TMSI Reallocation Complete (TMSI) to the VLR.
If the Location Updating Accept message indicates a reject, then this is indicated to
the MS, and the MS is not allowed to access non-GPRS services until a successful
Location Update is performed.
56 TM3110EU02TM_0001
© 2002 Siemens AG
s s s
BSS
MS SGSN new MSC/VLR HLR old MSC/VLR
GMM
(old RAI, Update Type)
Security Functions
BSSAP+
Location Update Request
(new LAI, IMSI, SGSN Number, Type) MAP
Update Location
MAP
(new VLR) Cancel Location
(IMSI)
MAP
Cancel Location Ack
MAP (IMSI)
Insert Sub Data
(IMSI, GSM subscriber data)
MAP
Insert Sub Data Ack
(IMSI)
MAP
Update Location Ack
(IMSI)
Location Update Accept BSSAP+
GMM (TMSI)
(P-TMSI, TMSI)
GMM
BSSAP+
TMSI Reallocation Complete
(TMSI)
Fig. 24 Combined intra SGSN RA/LA update
TM3110EU02TM_0001
57
© 2002 Siemens AG
2.3.3.4 Combined Inter SGSN RA/LA Update Procedure

Update Type) to the new SGSN. Update Type indicates combined routing area (RA) /
location area (LA) update, or, if the MS wants to perform an IMSI attach, combined
RA / LA update with IMSI attach requested. The BSS adds an identifier of the cell
where the message was received from before passing the message to the SGSN.
The SGSN derives the new RAI and LAI from the added cell identifier.
The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI
Signature, new SGSN Address) to the old SGSN to get the MM and PDP contexts for
the MS. The old SGSN validates the old P-TMSI signature and responds with an
appropriate error cause if it does not match the value stored in the old SGSN. This
initiates as well the security functions in the new SGSN. If the security functions
authenticate the MS correctly, the new SGSN sends an SGSN Context Request (old
RAI, TLLI, MS validated, new SGSN Address) message to the old SGSN. “MS
validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI
signature was valid or if the new SGSN indicates that it has authenticated the MS,
the old SGSN responds with SGSN Context Response (MM Context, PDP
Contexts). The old SGSN stores the new SGSN Address until the old MM context is
cancelled, to allow the old SGSN to forward data packets to the new SGSN. Each
PDP Context includes the SNDCP Sequence number (Send N-PDU Number)
number for the next downlink N-PDU to be sent to and the SNDCP Sequence
number (Receive N-PDU Number) for the next uplink N-PDU to be expected from the
MS. Each PDP Context also 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 tunneled to the GGSN. The old SGSN starts a timer and stops
the transmission of N-PDUs to the MS.
Security functions may be executed. Ciphering mode is set if ciphering is supported.
The new SGSN sends a 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. If the security functions do not authenticate
the MS correctly, then the routing area update is rejected, and the new SGSN sends
a reject indication to the old SGSN. The old SGSN continues as if the SGSN Context
Request was never received.
The old SGSN starts tunneling of buffered N-PDUs to the new SGSN. Additional N-
PDUs received from the GGSN are also tunneled to the new SGSN. N-PDUs that
were already sent to the MS in acknowledged mode and that are not yet
acknowledged by the MS are tunneled together with the SNDCP N-PDU sequence
number. No N-PDUs are forwarded to the new SGSN after expiry of the timer
described above.
The new SGSN sends Update PDP Context Request (new SGSN Address, TEID,
QoS negotiated) to the GGSNs concerned. The GGSNs update their PDP context
fields and return an Update PDP Context Response (TEID).
The new SGSN informs the HLR of the change of SGSN by sending Update
Location (SGSN Number, SGSN Address, IMSI) to the HLR.
58 TM3110EU02TM_0001
© 2002 Siemens AG
s s s
old SGSN
BSS
MS
new SGSN new MSC/VLR GGSN HLR old MSC/VLR
GMM
(old RAI, UpdateType)
GTP
SGSN Context Request
(old RAI, TLLI, new SGSN address)
SGSN Context Response GTP
(MM context, PDP contexts)
Security Functions
GTP
SGSN Context Ack
Forwarding Packets
GTP
Update PDP Context Request
(new SGSN address, TEID, QoS neg.)
Update PDP Context Response GTP
(TEID)
MAP
(SGSN number, SGSN address, IMSI)
MAP
Cancel Location
(IMSI, Cancellation Type)
MAP
Cancel Location Ack
(IMSI)
MAP
Fig. 25 Combined inter SGSN RA/LA update (part 1)
TM3110EU02TM_0001
59
© 2002 Siemens AG
Cancellation Type set to Update Procedure. If the timer described above is not
running, then the old SGSN removes the MM and PDP contexts. Otherwise, the
contexts are removed only when the timer expires. This allows the old SGSN to
complete the forwarding of N-PDUs. It also ensures that the MM and PDP contexts
are kept in the old SGSN in case the MS initiates another inter SGSN routing area
update before completing the ongoing routing area update to the new SGSN. The old
SGSN acknowledges with Cancel Location Ack (IMSI).
Now, the HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the
new SGSN. The new SGSN validates the MS's presence in the (new) RA. 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.
The HLR acknowledges the Update Location by sending Update Location Ack
(IMSI) to the new SGSN.
The new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number,
Location Update Type) to the VLR. Location Update Type indicates IMSI attach if
Update Type in step 1 indicated combined RA / LA update with IMSI attach
requested. Otherwise, Location Update Type indicates 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 new MSC/VLR upon receipt of the first Insert
Subscriber Data message from the HLR. The VLR creates or updates the association
with the SGSN by storing the SGSN Number.
If the LA update is inter-MSC, the new VLR informs the HLR. The HLR cancels the
old VLR and inserts subscriber data in the new VLR (this signaling is not modified
from existing GSM signaling and is included here for illustrative purposes):
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).
The old VLR acknowledges with Cancel Location Ack (IMSI).
The HLR sends Insert Subscriber Data (IMSI, GSM sub. 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.
The new VLR allocates a new TMSI and responds with Location Update Accept
(TMSI) to the SGSN.
The new SGSN validates the MS's presence in the new RA. If all checks are
successful then the new SGSN establishes MM and PDP contexts for the MS. A
logical link is established between the new SGSN and the MS. The new SGSN
responds to the MS with Routing Area Update Accept (P-TMSI, TMSI, Receive
N-PDU Number, P-TMSI Signature). Receive N-PDU Number contains the
confirming all mobile-originated N-PDUs successfully transferred before the start of
the update procedure.
60 TM3110EU02TM_0001
© 2002 Siemens AG
s s s
old SGSN
BSS
MS
new SGSN new MSC/VLR GGSN HLR old MSC/VLR
MAP
(IMSI, SGSN area restricted) MAP
(IMSI)
Location Update Request BSSAP+
MAP
(IMSI, SGSN area restricted) Update Location
MAP
(new VLR) Cancel Location
(IMSI) MAP
Cancel Location Ack
MAP (IMSI)
(IMSI, GSM Subscriber Data)
MAP
(IMSI) MAP
Update Location Ack
Location Update Accept BSSAP+ (IMSI)
GMM (TMSI)
(P-TMSI, TMSI, Receive N-PDU Number list)
GMM
(Receive N-PDU Number list)
BSSAP+
TMSI Reallocation Complete
(TMSI)
Fig. 26 Combined inter SGSN RA/LA update (part 2)
TM3110EU02TM_0001
61
© 2002 Siemens AG
The MS acknowledges the new P-TMSI with a Routing Area Update Complete
(Receive N-PDU Numbers). Receive N-PDU Number contains the
confirming all mobile-terminated N-PDUs successfully transferred before the start of
the update procedure. If Receive N-PDU Number confirms reception of N-PDUs that
were forwarded from the old SGSN, then these N-PDUs are discarded by the new
SGSN. LLC and SNDCP in the MS are reset.
The new SGSN sends TMSI Reallocation Complete (TMSI) to the new VLR.
In the case of a rejected routing area update operation, due to regional subscription
or roaming restrictions, the new SGSN does not construct an MM context. A reject
will be returned to the MS with an appropriate cause. The MS shall not re-attempt a
routing area update to that RA. The RAI value will be deleted when the MS is
powered-up.
If the SGSN is unable to update the PDP context in one or more GGSNs, then the
SGSN deactivates the corresponding PDP contexts using the Procedure “PDP
Context Deactivation Initiated by SGSN" indicating an appropriate cause. This shall
not cause the SGSN to reject the routing area update.
If the timer described above expires and no Cancel Location (IMSI) was received
from the HLR, then the old SGSN stops forwarding N-PDUs to the new SGSN and
proceed as if the SGSN Context Request message was not received.
the SGSN returns a Routing Area Update Reject (Cause) message, the MS enters
IDLE state.
If the Location Updating Accept message indicates a reject, then this is forwarded to
the MS, and the MS does not access non-GPRS services until a successful location
update is performed.
62 TM3110EU02TM_0001
© 2002 Siemens AG
3 Format of GMM Messages
TM3110EU02TM_0001
63
© 2002 Siemens AG
3.1 Format of Standard Layer 3 Messages

The description of formatting rules will be confined to layer 3 contents according to
3GPP TS 04.08 or 3GPP TS 24.008. The same formatting rules are used for the
definition of messages between a GSM mobile station and a MSC.
Every standard layer 3 message is comprised of several parameters also known as
information elements. Section 9 of 3GPP TS 04.08 or 3GPP TS 24.008 resp. defines
the mandatory and optional parameters for every message. The same parameter
may be mandatory for one message and optional for another. Optional parameters
bear an identifier (IEI) to designate their presence. The identifier is always located at
the beginning of the parameter. Mandatory parameters, by contrast, include
sometimes - dependent on the position - an identifier.
The parameters are sub-divided into 5 parameter formats (described in 3GPP TS
04.07 or 3GPP TS 24.007 resp.):
V (value only) parameters have neither an identifier (IEI) nor a length indicator;
they are mandatory parameters of fixed length. The length is either an integer
amount of bytes or 1/2 byte. In the last case, V-parameters of 1/2 byte length
are combined to form pairs whenever possible. The first parameter in the
combination encompasses the 4 least significant bits, the second parameter
the 4 most significant bits. If the total number of V-parameters of 1/2 byte is
odd, the 4 most significant bits of the last byte are filled with 0000.
TV (type and value) parameters have an identifier (IEI) but no length indicator. If
the length of the contents is an integer amount of bytes, then the IEI is 1 byte in
length, and the most significant IEI bit is 0. If the length of the contents is 1/2
byte, then the IEI is likewise 1/2 byte in length. The most significant bit is 1, and
the succeeding bits must not be 010 (to distinguish them from T-parameters,
see below).
T (type only) parameters have 0 byte content. The communicated information
consists solely in the presence or absence of the parameter. Obviously, such
parameters can only be considered as optional. The identifier (IEI) is 1 byte in
length and begins with 1010 (so that no confusion with TV-parameters is
possible). One example of a type-2 parameter is the authorization given in
"Location Update Accept" for the Mobile Station to set up a MM connection
directly after the location update (i.e. in the same RR connection). This
authorization may, or may not, be present.
LV (length and value) parameters have a length indicator but no identifier (IEI);
they are mandatory parameters of variable length. The length indicator is the
first byte and indicates how many bytes of contents follow.
TLV (type, length and value) parameters have an identifier (IEI) and a length
indicator. The IEI is the first byte of the parameter; its most significant bit is 0.
The length indicator is the second byte of the parameter and indicates how
many bytes of contents follow.
64 TM3110EU02TM_0001
© 2002 Siemens AG
Layer 3 parameters (in 3GPP TS 04.07 or 3GPP TS 24.007 resp.)
Parameter Format Length integer amount of Bytes Length of 1/2 Byte
Example: 5 parameters
V alue content 2 content 1

content content 4 content 3
0 0 0 0 content 5
0 IEI
T ype,
V alue content
1 IEI content
#0 1 0
T ype 1 0 1 0 IEI
Length indicator
L ength,
V alue
content
T ype, 0 IEI
L ength, Length indicator
V alue
content
Fig. 27 Parameter formats
TM3110EU02TM_0001
65
© 2002 Siemens AG
Each message starts with the same three V-parameters:

The protocol discriminator specifies the layer 3 part to which the message belongs.
It is a parameter of 1/2 byte length. Its possible values are given in the next figure.
The transaction identifier (TI) characterizes the transaction (= logical connection
between MS and SGSN for Session Management). It is a V-parameter of 1/2 byte,
too; in conformity with the rules, the protocol discriminator and the TI together fill 1
byte. For GMM messages (protocol discriminator = 1000), no logical connection is
established; for this reason, the TI is replaced by the skip indicator whose value is
0000.
With a proper TI, the most significant bit serves as TI flag in messages for other TI
parts; it is 0 in messages from the side, which set up the transaction, and 1 in
messages to the side, which set up the transaction. The three remaining bits form the
TI value are freely selected by the initiating side in a transaction set up; the value 111
is not permissible.
The message type identifies the nature of the message (e.g. "Attach Request",
"Routing Area Update Request", "Activate PDP Context Request" and many other
examples from section 2). It is a V-parameter with a length of 1 byte.
For the remaining parameters, the protocol may define three different presence
requirements: M (mandatory), C (conditional) or O (optional). An M-parameter must
always be included in a message of a given type; its absence is reason enough for
the receiver to reject the whole message. A C-parameter must be present under
certain conditions, but can be absent under other conditions. An O-parameter, finally,
is never bound to be present; its absence is never sufficient reason for the receiver to
reject the message.
66 TM3110EU02TM_0001
© 2002 Siemens AG
Transaction identifier
or Skip indicator Protocol discriminator
TI-
TI-value Protocol discriminator
flag
Message type
Message Type
Fig. 28 Layer 3 message header (GSM 04.07)
Value Layer 3 part
0011 Call Control (CC)
0101 Mobility Management (MM) non GPRS
0110 Radio Resource Management (RR)
1000 Mobility Management (GMM) for GPRS
1010 Session Management (SM)
Fig. 29 Protocol discriminator
TM3110EU02TM_0001
67
© 2002 Siemens AG
3.2 Format of the GPRS Attach Request Message

An example of a layer 3 message will now be examined. The GPRS Mobility
Management message the "Attach Request" from Mobile Station to the SGSN will be
considered. Apart from the parameters in the message header (transaction identifier,
protocol discriminator and message type), the mandatory parameters are the general
mobile station characteristics related to GPRS (MS Network Capability), the type of
the requested attach (Attach Type), the index to the actual Kc (GPRS Ciphering Key
Sequence Number), the indication whether the MS uses DRX mode (DRX-
parameter), the mobile identity (IMSI or P-TMSI), the value for the routing area (old
routing area identification) and information concerning the radio aspects of the mobile
station (MS Radio Access Capability). Three optional parameters exist which are the
P-TMSI signature, the READY timer value and the TMSI status.
The length specifications for the parameters in the message descriptions indicate the
total parameter lengths, i.e. inclusive of identifier and length indicator, where
applicable. Thus, V-parameters have the length 1/2 or an integer value. With TV-
parameters, the length is 1 if they have 1/2 byte contents and 1/2 byte identifier;
otherwise, the length of the contents is 1 byte less than the indicated length (because
the first byte is the IEI). T-parameters always have a length of 1 byte. LV-parameters
have a length of the contents which is 1 byte less than the indicated length (here, the
first byte is the length indicator). Finally, with TLV-parameters, the length of the
contents is 2 bytes less than the indicated length, since the first byte is the IEI and
the second byte is the length indicator.
68 TM3110EU02TM_0001
© 2002 Siemens AG
IEI Information Element Presence Format Length
Protocol Discriminator M V ½
Skip Indicator M V ½
Message Type M V 1
MS Network Capability M LV 2
Attach Type M V ½
GPRS Ciphering Key Sequence M V ½
Number
DRX parameter M V 2
Mobile Identity M LV 6-9
Old Routing Area Identification M V 6
MS Radio Access Capability M LV 6-14
19 Old P-TMSI Signature O TV 4
17 Requested READY timer value O TV 2
9- TMSI status O TV 1
Fig. 30 GPRS Attach request message MS -> SGSN
TM3110EU02TM_0001
69
© 2002 Siemens AG
The adjacent example shows a "GPRS Attach Request". The protocol discriminator
specifies "GPRS Mobility Management"; accordingly, there is no transaction identifier
but a skip indicator. The subsequent message type 00000001 identifies the message
as a "GPRS Attach Request".
The mandatory parameters follow. The parameter "MS network capability" provides
the network with information concerning aspects of the mobile station related to
GPRS, e.g. GPRS Encryption Algorithm, Short message capabilities, etc. The "Attach
Type" indicates if it is GPRS attach, GPRS attach while IMSI attached or Combined
GPRS/IMSI attach. In this case, shown by the bit combination 001, the type is GPRS
attach. "Ciphering key sequence number (CKSN)" tells the network, which Kc is used
by the MS for ciphering. These are followed by the "DRX-parameter", which
indicates, whether the MS uses DRX mode or not and the "Mobile Identity", in our
case represented by the P-TMSI. "Old routing area Identification" contains the value
of the RAI.
For the continuation of the "GPRS Attach Request" message, please refer to the next
figure.
70 TM3110EU02TM_0001
© 2002 Siemens AG
7 6 5 4 3 2 1 0
0 0 0 0 1 0 0 0 PD=GMM, Skip indicator

0 0 0 0 0 0 0 1 Message Type = Attach Request
0 0 0 0 0 0 0 1 MS Network Capability
Length 1 Byte
0 0 0 0 0 1 1 0 MS Network Capabilty value
CKSN 0 0 0 1 Attach Type = GPRS Attach

0 0 0 0 0 0 0 1
DRX parameter
0 0 0 0 1 1 1 1 non DRX timer, split on CCCH
0 0 0 0 1 0 0 0
1. digit 1 0 0 1
3. digit 2. digit
Mobile Identity
Length 8 Byte
Type of Identity = IMSI
odd number of digits
n - digit
MCC
DUMMY Old Routing Area Identification
MNC
Fig. 31 Example of a ”GPRS attach request part 1”
TM3110EU02TM_0001
71
© 2002 Siemens AG
The last mandatory parameter of the "GPRS Attach Request-message" is the "MS
Radio Access Capability". The purpose of this parameter is to provide the radio part
of the network with information concerning radio aspects of the mobile station. The
contents might affect the manner in which the network handles the operation of the
mobile station.
Regarding the optional parameters, the "Old P-TMSI Signature" is present. The
former is recognizable by identifier 00011001 (19 Hex); after the identifier the 3-byte
value of the "Old P-TMSI Signature" follows.
72 TM3110EU02TM_0001
© 2002 Siemens AG
7 6 5 4 3 2 1 0
LAC Old Routing Area Identification
RAC
0 0 0 0 1 0 0 1
MS Radio Access Capability

MS Radio Access
Length 9 Byte
Capability
0 0 0 1 1 0 0 1
Old P-TMSI Signature
IEI = 19Hex
Old P-TMSI Signature Lenght 4 Bytes
Fig. 32 Example of a ”GPRS attach request part 2
TM3110EU02TM_0001
73
© 2002 Siemens AG
74 TM3110EU02TM_0001
© 2002 Siemens AG
3.3 Format of the GPRS Attach Accept Message
IEI Information Element Presence Format Length

Protocol discriminator M V 1/2
Skip indicator M V 1/2
Attach accept message identity M V 1
Attach result M V 1/2
Force to standby M V 1/2
Periodic RA update timer M V 1
Radio priority for SMS M V 1/2
Spare half octet M V 1/2
Routing area identification M V 6
19 P-TMSI signature O TV 4
17 Negotiated READY timer O TV 2
value
18 Allocated P-TMSI O TLV 7
23 MS identity O TLV 7-10
25 GMM cause O TV 2
2A T3302 value O TLV 3
8C Cell Notification O T 1
4A Equivalent PLMNs O TLV 5-17
Fig. 33 GPRS Attach request message SGSN -> MS
TM3110EU02TM_0001
75
© 2002 Siemens AG
76 TM3110EU02TM_0001
© 2002 Siemens AG
4 Exercise
TM3110EU02TM_0001
77
© 2002 Siemens AG
78 TM3110EU02TM_0001
© 2002 Siemens AG
Exercise
Title: GPRS Mobility Management
Pre-requisite: none
Query
1. Explain the difference between Mobility Management State Ready and

Standby.
2. Which information does the protocol discriminator identify?
TM3110EU02TM_0001
79
© 2002 Siemens AG
80 TM3110EU02TM_0001
© 2002 Siemens AG
5 Solution
TM3110EU02TM_0001
81
© 2002 Siemens AG
82 TM3110EU02TM_0001
© 2002 Siemens AG
Solution
Title: GPRS Mobility Management
Pre-requisite: none
Query
1. Explain the difference between Mobility Management State Ready and

Standby.
Ready: In the Ready state the MS is attached an the cell of the mobile station is
known.
Standby: In Standby state the MS is attached and the SGSN knows the routing area
identity (RAI) of the roaming mobile station.
2. Which information does the protocol discriminator identify?

The protocol discriminator identifies the layer 3 part to which the message belongs. In
case of GPRS protocol discriminator H´8 identifies Mobility Management (GMM) for
GPRS.
TM3110EU02TM_0001
83
© 2002 Siemens AG
84 TM3110EU02TM_0001
© 2002 Siemens AG

02 Tm3110eu02tm 0001 Gprs Sign GMM Context PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 Tm3110eu02tm 0001 Gprs Sign GMM Context PDF

Uploaded by

Copyright:

Available Formats

GPRS Signaling Using GMM Context Siemens

GPRS Signaling Using GMM Context

1 GPRS Mobility Management Overview

1.1 Protocol Stack

This section is focusing on the GMM only.

The Subnetwork Dependent Convergence Protocol (SNDCP) is part of the

The GPRS Mobility Management is defined by the 3GPP Technical Specifications

SMS SNDCP GMM/SM GMM/SM SNDCP SMS

RLC RLC BSSGP BSSGP

GSM RF GSM RF L1bis L1bis

Fig. 1 Signaling plane MS - SGSN

1.2 Functions of the GMM

Registration functions, e.g. GPRS attach/detach.

A further function of the MM sublayer is to provide connection management services

Registration Security Location Management

Fig. 2 Functions of GPRS Mobility Management Layer

1.3 Storage of GMM related Data in the different

HLR Field Description

Fig. 3 Storage of GMM related subscription data in the HLR.

Fig. 4 Storage of GMM related data in the SGSN.

The SGSN - MSC/VLR association is created at the following occasions:

Fig. 5 Storage of GMM related data in the MSC/VLR.

Field SIM Description

Fig. 6 Storage of GMM related data in the MS.

1.4 GPRS Mobility Management States

State changes of mobility management

GPRS Attach GPRS Attach GPRS Detach

READY Implicit Detach READY

MM State Model of MS MM State Model of SGSN

Fig. 7 Functional mobility management state model

State changes of mobility management (continuation)

GMM Timers related to the different GMM states:

TIMER TIMER MS SGSN CAUSE OF NORMAL ON

Fig. 8 GMM timers related to the different GMM states

GSM Area Identifiers

Fig. 9 Routing Area Identity

2 Signaling Procedures Supporting GMM

2.1 Registration Procedures

Fig. 10 GPRS attach procedure

GPRS Attach Procedure to be continued

Timers and Counters supervising the GPRS Attach Procedure

TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON THE

TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON

2.1.2 Detach Procedure

2.1.2.1 MS-Initiated Detach Procedure

Fig. 11 MS initiated detach procedure

2.1.2.2 SGSN-Initiated Detach Procedure

Timers and Counters supervising the Detach Procedure

TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON THE

Fig. 12 SGSN-initiated detach procedure

2.1.2.3 HLR-Initiated Detach Procedure

Fig. 13 HLR-initiated detach procedure

2.2 Security Procedures

B) For IMEI Check:

Timer and Counter supervising the Identity Check Procedure

TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON THE

T3370 6s X IDENTITY REQUEST sent IDENTITY Retransmission of

Fig. 14 Identity check procedure

2.2.2 Authentication Procedure

Timers and Counters supervising the Authentication Procedure

TIMER TIMER MS SGSN CAUSE OF START NORMAL STOP ON THE

T3360 6s X AUTH AND CIPH REQUEST AUTH AND CIPH Retransmission of

Send Authentication Info