SGSN - MS Interface Description, GPRS Mobility and Session Management

SGSN - MS Interface Description,
GPRS Mobility and Session

Management
DN0096954 # Nokia Siemens Networks 1 (73)

Issue 8-0 en
SGSN - MS Interface Description, GPRS Mobility and Session
Management
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted in
any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity, or
performance of the mentioned hardware or software products are given as is and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS
DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,
DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT
NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS
OPPORTUNITY OR DATA, THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE
INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of
Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective owners,
and they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2009. All rights reserved.
2 (73) # Nokia Siemens Networks DN0096954

Issue 8-0 en
Contents
Contents
Contents 3
List of tables 4
1 Main changes in SGSN - MS interface, GPRS mobility and session

management 7
2 Introduction to SGSN - MS interface, GPRS mobility and session

management 9
3 Description of SGSN - MS interface, GPRS mobility and session

management 11
3.1 GPRS mobility management 11
3.1.1 P-TMSI signature 11
3.1.2 P-TMSI handling in GSM 12
3.1.3 P-TMSI handling in UMTS 12
3.1.4 READY timer behaviour 12
3.1.5 GPRS Attach procedure 13
3.1.6 GPRS Detach procedure 20
3.1.7 Routing Area Update procedure 24
3.1.8 P-TMSI re-allocation procedure 33
3.1.9 Authentication and ciphering procedure 36
3.1.10 Identification procedure 43
3.1.11 GMM Status procedure 45
3.1.12 GMM Information procedure 46
3.1.13 Paging procedure 46
3.1.14 Service Request procedure (UMTS only) 47
3.1.15 General message format and information elements for mobility
management 50
3.1.16 GPRS Mobility Management timers 51
3.2 GPRS session management 52
3.2.1 PDP context activation 52
3.2.2 Secondary PDP context activation 56
3.2.3 PDP context modification 60
3.2.4 PDP context deactivation 65
3.2.5 Receiving an SM STATUS message by an SM entity 68
3.2.6 General message format and information elements for GPRS session
management 68
3.2.7 GPRS Session Management timers 69
3.3 Error handling of GPRS mobility and session management 70
3.4 Restrictions 71
4 Support protocol description in SGSN - MS interface, GPRS mobility

and session management 73

Issue 8-0 en
Management
List of tables
Table 1. Information elements in an Attach Request message 15

Table 2. Information elements in an Attach Accept message 16
Table 3. Information elements in an Attach Complete message 17
Table 4. Information elements in an Attach Reject message 18
Table 5. Information elements in a Detach Request message (mobile-terminating
detach) 22
Table 6. Information elements in a Detach Request message (mobile-originating
detach) 22
Table 7. Information elements in a Detach Accept message (mobile-terminating
detach) 23
Table 8. Information elements in a Detach Accept message (mobile-originating
detach) 23
Table 9. Information elements in a Routing Area Update Request message 28
Table 10. Information elements in a Routing Area Update Accept message 29
Table 11. Information elements in a Routing Area Update Complete message 31
Table 12. Information elements in a Routing Area Update Reject message 31
Table 13. Information elements in a P-TMSI Re-allocation Command message 33
Table 14. Information elements in a P-TMSI Re-allocation Complete message 34
Table 15. Information elements in an Authentication and Ciphering Request
message 39
Table 16. Information elements in an Authentication and Ciphering Response
message 40
Table 17. Information elements in an Authentication and Ciphering Failure
message 41
Table 18. Information elements in an Identity Request message 43
Table 19. Information elements in an Identity Response message 43
Table 20. GMM Status message content 46
Table 21. GMM Information message content 46
Table 22. Service Request message content 48
Table 23. Service Accept message content 48
Table 24. Service Reject message content 49

Issue 8-0 en
List of tables
Table 25. GMM timers 51

Table 26. Information elements in an Activate PDP Context Request message 54
Table 27. Information elements in an Activate PDP Context Accept message 54
Table 28. Information elements in an Activate PDP Context Reject message 55
Table 29. Information elements in an Activate Secondary PDP Context Request
message 58
Table 30. Information elements in an Activate Secondary PDP Context Accept
message 58
Table 31. Information elements in an Activate Secondary PDP Context Reject
message 59
Table 32. Information elements in a Modify PDP Context Request message
(network-originating) 62
Table 33. Information elements in a Modify PDP context request message (mobile-
originating) 62
Table 34. Information elements in a Modify PDP Context Accept message (mobile-
originating) 63
Table 35. Information elements in a Modify PDP Context Accept message (network-
originating) 63
Table 36. Information elements in a Modify PDP Context Reject message 64
Table 37. Information elements in a Deactivate PDP Context Request message 66
Table 38. Information elements in a Deactivate PDP Context Accept message 67
Table 39. Information elements in an SM Status message 68
Table 40. GPRS Session Management timers 69

Issue 8-0 en
Management

Issue 8-0 en
Main changes in SGSN - MS interface, GPRS mobility and session
management
1 Main changes in SGSN - MS interface,

GPRS mobility and session management
Changes between releases SG7.0 CD2 and SG7.0
Changes in content
The 3GPP release has been upgraded from Release 5 to Release 7 in all
the references to the 3GPP TS 24.008 Mobile radio interface Layer 3
specification; Core network protocols; Stage 3. The change is the effect of
the new feature SG02198 HSPA+.
Changes in documentation
The Attach Request and Routing Area Update Request are only received
from the MS to the SGSN which means that the SGSN cannot send any
information elements related to these messages. Therefore, the remark on
the PS LCS Capability information element has been corrected to "Not
supported, ignored if received" in the following locations:
. in Table Information elements in an Attach Request message of

Subsection Attach Request of Section GPRS Attach procedure and
. in Table Information elements in a Routing Area Update Request
message of Subsection Routing Area Update Request of Section
Routing Area Update procedure.
The RAB information element has been corrected to uplink data status in
Table Service Request message content of Subsection Service Request
(UMTS only) of Section Service Request procedure (UMTS only).
Changes between releases SG7.0 and SG6.0
Changes in content
Service Request Procedure (UMTS only)

Issue 8-0 en
Management
Optional RAB element has been added to Service request (UMTS only).
Changes between releases SG6.0 and SG5.1
Changes in content
The optional 'PDP Context Status' information element has been added to
the Routing Area Update Accept message.
Handling after SM STATUS message has been updated.
Support for 3G access has been added to Nokia SGSN.
In 3G access supported Service Request procedure has been added.
PTMSI handling in UMTS has been added.
Changes in documentation
Tables GMM cause codes and SM cause codes have been removed
because corresponding information can be found in the SGSN Cause
Description document.
The TFT error descriptions under the PDP context modification have been
removed because the SGSN only transmits the TFT IE and does not check
its validity.

Issue 8-0 en
Introduction to SGSN - MS interface, GPRS mobility and session
management
2 Introduction to SGSN - MS interface,

This interface description describes the GPRS mobility and session
management of the interface between Nokia Siemens Networks SGSN
and the MS. The relevant GSM specification is 3GPP TS 24.008 Mobile
radio interface Layer 3 specification; Core network protocols; Stage 3
(Release 7).
Mobility management handles the subscribers' requests for attaching to or

detaching from the GPRS network. Mobility management also updates the
subscriber's location to the HLR and the VLR.
Session management handles the establishment, modification, and

release of the IP network connections for an attached subscriber.
When subscribers move to another routing area, mobility management

transfers the subscriber information between the Packet Processing Units
(PAPUs) or between the PAPU unit and another SGSN, while session
management re-establishes the IP network connections.
Radio interface protocols provide transparent mobility management (MM)

and session management (SM) message exchange between an MS and
an SGSN for the GSM network in 2G access and for the UMTS network in
3G access. For more information on protocols, see Section Support
protocol description in SGSN - MS interface, GPRS mobility and session
management.

Issue 8-0 en
Management

Issue 8-0 en
Description of SGSN - MS interface, GPRS mobility and session
management
3 Description of SGSN - MS interface,

The mobility and session management protocols are managed with the
commands of the Visiting GPRS Subscriber Data Handling (MM) MML
command group. With these commands you can display subscriber data
from the Visiting GPRS Subscriber Database. You can display the number
of visiting subscribers and the visiting subscriber equipment identity, IMSI,
or subscription.
3.1 GPRS mobility management

GPRS mobility management (GMM) is used in the following cases:
. connecting a subscriber to the general packet radio service (GPRS)

network
.
updating the location of a subscriber to the GPRS network
. disconnecting a subscriber from the GPRS network.
The following Sections describe the basic functions offered by the GPRS
mobility management sublayer. The functionality is described in terms of
timers and procedures. During the GPRS mobility management
procedures, the GPRS session management procedures are suspended.
3.1.1 P-TMSI signature
The network can assign a packet temporary mobile subscriber identity (P-
TMSI) signature to a mobile station (MS) in a GPRS Attach, Routing Area
Update, or P-TMSI re-allocation procedure. In combination with a valid P-
TMSI, the P-TMSI signature is used by the MS for authentication and
identification purposes. If the MS has no valid P-TMSI, it does not use the
P-TMSI signature in the subsequent GPRS Attach, Routing Area Update
(RAU), or Detach procedure.

Issue 8-0 en
Management
3.1.2 P-TMSI handling in GSM
The P-TMSI is used for authentication and identification. If the network has
assigned a new P-TMSI, the MS and the network handle the old and the
new P-TMSI in the following way:
. When the MS receives a GMM message containing a new P-TMSI,

the MS considers the new P-TMSI and the new routing area identity
(RAI), and also the old P-TMSI and the old RAI valid in order to react
to the paging requests and downlink transmission of the logical link
control (LLC) frames. You can use the new P-TMSI for the uplink
transmission of the LLC frames.
. When the network transmits a GMM message containing a new P-
TMSI, the network considers the new P-TMSI and the new RAI and
also the old P-TMSI and the old RAI valid in order to receive LLC
frames from the MS. The network considers the old P-TMSI and the
old RAI invalid as soon as it has received an LLC frame with the
local temporary logical link identity (TLLI) derived from the new P-
TMSI.
3.1.3 P-TMSI handling in UMTS
If a new P-TMSI is assigned by the network the MS and the network

handles the old and the new P-TMSI as follows:
Upon the receipt of a GMM message containing a new P-TMSI the MS

considers the new P-TMSI and the new RAI valid. The old P-TMSI and the
old RAI are regarded as invalid.
The network considers the old P-TMSI and the old RAI invalid as soon as
an acknowledge message (Attach Complete, Routing Area Update
Complete or P-TMSI Re-allocation Complete) is received.
3.1.4 READY timer behaviour
The READY timer, T3314, is used in the MS and in the network for each
assigned P-TMSI to control the cell update procedure. When the READY
timer is running or deactivated, the MS performs a cell update each time a
new cell is selected. If a routing area is crossed, the MS performs a RAU
procedure instead of a cell update.
The READY timer is started in the following cases:

Issue 8-0 en
management
. in the MS when the GMM entity receives an indication from the lower
layers that an LLC frame has been transmitted on the radio interface
. in the network when the GMM entity receives an indication from the
lower layers that an LLC frame has been successfully received by
the network
Within the GMM signalling procedures, the network includes a Force to

standby information element in order to indicate whether the READY timer
has stopped or not.
The value of the READY timer can be negotiated between the MS and the
network using the GPRS Attach or GPRS Routing Area Update procedure.
. If the MS wishes to indicate its preference for a READY timer value,

it includes the preferred values in the GPRS Attach Request or
Routing Area Update Request messages. The preferred values can
be smaller, equal to or greater than the default values, or can be
equal to the value requesting the READY timer function to be
deactivated.
.
If the value of the OVERRIDE THE MS READY STATE TIMER VALUE
(ORDY) parameter is TRUE, the value of the READY timer is
overridden on the request of the MS by using the configurable
parameter value (RDY) for the READY timer.
. If the MS does not indicate the READY timer in the GPRS Attach
request, Nokia Siemens Networks SGSN uses the configurable
parameter value (RDY) for the READY timer.
.
If the MS requests the READY timer with 'maximum value' in a
GPRS Attach or RAU request, both the READY and the Periodic
RAU timers are set to the maximum value even if the value of the
ORDY parameter is TRUE.
.
If the MS requests the READY timer with 'maximum value' in a
GPRS Attach or RAU request, the FTS parameter has no effect.
If the negotiated READY timer value indicates that the READY timer
function is deactivated, or if the Force to standby is activated, the READY
timer always runs without expiry. If the negotiated READY timer value is
set to zero, the READY timer stops immediately.
3.1.5 GPRS Attach procedure
The GPRS Attach procedure establishes a GMM context. This procedure

is used for the following two purposes:

Issue 8-0 en
Management
. a normal GPRS Attach, performed by the MS to attach the IMSI for

GPRS services only
. a combined GPRS Attach, performed by the MS to attach the IMSI
for GPRS and non-GPRS services
Description for GPRS Attach procedure
The MS initiates the GPRS Attach procedure by sending an Attach

Request message to the network.
If the network accepts the GPRS Attach Request, it sends an Attach

Accept message to the MS. The P-TMSI to be allocated is then included in
the Attach Accept message together with the routing area identity (RAI).
The network can also assign a P-TMSI signature which is then also
included in the Attach Accept message. The network also includes the
radio priority level to be used by the MS for mobile-originating SMS (MO-
SMS) transfer in the Attach Accept message.
If the network does not accept the request, it sends an Attach Reject
message to the MS.
If the Attach Accept message contains a P-TMSI, the MS uses this P-TMSI
as the new temporary identity for GPRS services. In this case, the MS
returns an Attach Complete message to the network. The MS considers
the old P-TMSI invalid as soon as an LLC frame is received with the local
TLLI derived from the new P-TMSI. The MS deletes its old P-TMSI and
stores the new one. The MS deletes its old P-TMSI signature, if available,
and stores the new one. If the message does not contain a P-TMSI
signature, the old P-TMSI signature, if available, is deleted. The network
receiving an Attach Complete message stops the T3350 timer and
considers the P-TMSI sent in the Attach Accept message valid. The
network can then initiate GMM common procedures, identification
procedure, or authentication and ciphering procedure, for example.
In combination with a valid P-TMSI, the P-TMSI signature is used by the

MS for authentication and identification purposes. If the MS has no valid P-
TMSI, it does not use the P-TMSI signature. P-TMSI re-allocation can be
part of the GPRS Attach procedure. The P-TMSI signatures used
previously are deleted upon a new GPRS Attach procedure. The value of
the READY timer can also be negotiated between the MS and the network
upon the GPRS Attach procedure.
Depending on the value of the Attach Result information element (IE)

received in the Attach Accept message, two different cases exist when the
combined Attach is initiated:

Issue 8-0 en
management
. The Attach Result IE value indicates 'combined GPRS Attach': the

IMSI Attach for GPRS and non-GPRS services has been successful.
. The Attach Result IE value indicates 'GPRS only': the IMSI Attach
for GPRS services has been successful but the IMSI Attach for non-
GPRS services has not been successful.
When the network receives an Attach Complete message, it stops the

T3350 timer, considers the MS to be attached, and considers the new P-
TMSI valid.
If the network can accept the Attach Request neither for GPRS nor for
non-GPRS services, it sends an Attach Reject message to the MS. The
message contains a network reject cause code that typically indicates one
of the following causes:
#3 Illegal MS
#6 Illegal ME
#7 GPRS services not allowed
#8 GPRS services and non-GPRS services not allowed
#11 PLMN not allowed
#12 Location area not allowed
#13 Roaming not allowed in this location area
#14 GPRS services not allowed in this PLMN
#15 No suitable cells in this location area
Attach Request
The MS initiates the GPRS Attach or the combined GPRS Attach

procedure by sending an Attach Request message to the network. In a
normal GPRS Attach, the Attach type IE indicates 'GPRS Attach'. In a
combined GPRS Attach, the Attach type IE indicates 'combined GPRS
Attach'. The Old P-TMSI signature IE is included if a valid P-TMSI and P-
TMSI signature are stored in the MS. The requested READY timer value
IE is included if the MS wants to indicate a preferred value for the READY
timer. The TMSI status IE is included if the MS performs a combined
GPRS Attach and no valid TMSI is available.
Table 1. Information elements in an Attach Request message
Information element Presence Remarks

Protocol discriminator M=
mandatory

Issue 8-0 en
Management
Table 1. Information elements in an Attach Request message (cont.)

Skip indicator M
Attach request message identity M
MS network capability M
Attach type M
GPRS ciphering key sequence number M
DRX parameter M
P-TMSI or IMSI M
Old routing area identification M
MS radio access capability M
Old P-TMSI signature O = optional
Requested READY timer value O
TMSI status O
PS LCS Capability O Not supported,
ignored if received.
Attach Accept
If the network accepts the GPRS Attach request, it sends an Attach Accept
message to the MS. The P-TMSI signature IE assigns an identity to the
MS's GMM context. The Negotiated READY timer IE indicates a value for
the READY timer. The Allocated P-TMSI IE assigns a P-TMSI to an MS in
case of a GPRS or combined GPRS Attach. The MS identity IE assigns or
unassigns a TMSI to an MS in case of a combined GPRS Attach. The
GMM cause IE is included when the IMSI Attach for non-GPRS services is
not successful during a combined GPRS Attach procedure.
Table 2. Information elements in an Attach Accept message

mandatory
Skip indicator M
Attach accept message identity M
Attach result M
Force to standby M

Issue 8-0 en
management
Table 2. Information elements in an Attach Accept message (cont.)

Periodic RA update timer M
Radio priority for SMS M
Spare half octet M
Routing area identification M
P-TMSI signature O = optional
Negotiated READY timer value O
Allocated P-TMSI O
MS identity O
GMM cause O
T3302 value O This field is never
sent by Nokia
Siemens Networks
SGSN.
Cell notification O This field is never
sent by Nokia
Siemens Networks
SGSN.
Equivalent PLMNs O
Network feature support O This field is never
sent by Nokia
Siemens Networks
SGSN.
Emergency Number List O This field is never
sent by Nokia
Siemens Networks
SGSN.
Attach Complete
The MS sends an Attach Complete message to the network if a P-TMSI or

a TMSI has been included in the Attach Accept message. The network
receiving an Attach Complete message stops the T3350 timer and
considers the P-TMSI sent in the Attach Accept message valid.
Table 3. Information elements in an Attach Complete message
Information element Presence

Protocol discriminator M = mandatory

Issue 8-0 en
Management
Table 3. Information elements in an Attach Complete message (cont.)

Skip indicator M
Attach complete message identity M
Attach Reject
If the network cannot accept the Attach Request, it sends an Attach Reject
message to the MS.
Table 4. Information elements in an Attach Reject message

mandatory
Skip indicator M
Attach reject message identity M
GMM cause M
T3302 value O = optional This field is never
sent by Nokia
Siemens Networks
SGSN.
Abnormal cases in GPRS Attach procedure
The following abnormal cases can be identified on the network side:
.
Lower layer failure
If a lower layer failure occurs before receiving an Attach Complete

message from the MS and assigning a new P-TMSI or a new P-
TMSI with a new P-TMSI signature, the network considers both the
old and the new P-TMSI valid, each with its corresponding P-TMSI
signature. The network considers them valid until the old P-TMSI
can be considered invalid, and does not resend the Attach Accept
message. During this period, the network uses the identification
procedure followed by a P-TMSI re-allocation procedure if the MS
uses the old P-TMSI in a subsequent message.
. Protocol error

Issue 8-0 en
management
If the network receives an Attach Request message with a protocol

error, the network returns an Attach Reject message with one of the
following reject causes:
#95 Semantically incorrect message

#96 Mandatory information element error
#99 Information element non-existent or not
implemented
#100 Conditional IE error
#111 Protocol error, unspecified
. T3350 time-out
On the first expiry of the timer, the network retransmits the Attach
Accept message and resets and restarts the T3350 timer. This
retransmission is repeated four times, that is, the GPRS Attach
procedure is aborted on the fifth expiry of the T3350 timer. If a new
P-TMSI or a new P-TMSI with a new P-TMSI signature are allocated
in the Attach Accept message, the network considers both the old
and the new P-TMSI each together with the corresponding P-TMSI
signatures valid until the old P-TMSI can be considered invalid.
. Attach Request message received
If one or more of the information elements in the Attach Request
message differ from the ones received within the previous Attach
Request message, the network aborts the previously initiated GPRS
Attach procedure and progresses with the new GPRS Attach
procedure. If no information elements differ, the Attach Accept
message is resent.
. More than one Attach Request message received and no Attach
Accept or Attach Reject message sent
If one or more of the information elements in the Attach Request
message differ from the ones received within the previous Attach
Request message, the network aborts the previously initiated GPRS
Attach procedure and progresses with the new GPRS Attach
procedures. If no information elements differ, the network continues
with the previous Attach procedure and does not treat the Attach
Request message any further.
. Attach Request received when the MS is attached
If an already attached MS sends an Attach Request message, the
network deletes the MM context and the PDP contexts and
progresses with the new Attach Request.

Issue 8-0 en
Management
. Routing Area Update Request message received before the Attach

Complete message
The T3350 timer stops. The network considers the allocated P-TMSI
valid and progresses with the Routing Area Update procedure.
Error handling in GPRS Attach procedure
For more information, see Section Error handling of GPRS mobility and
session management.
3.1.6 GPRS Detach procedure
The GPRS Detach procedure is used for the following two purposes:
. a normal GPRS Detach

. a combined GPRS Detach
After the completion of a GPRS Detach procedure or combined GPRS

Detach procedure for GPRS and non-GPRS services, the mobility
management context is released. The GPRS Detach procedure marks the
MS as inactive in the network for GPRS services, non-GPRS services or
both. The used P-TMSI signature is deleted when the GPRS Detach
procedure is completed. The MS initiates the GPRS Detach if the MS is
switched off, the SIM card is removed from the MS, or the GPRS or non-
GPRS capability of the MS is disabled. The network initiates the GPRS
Detach in order to detach the IMSI for GPRS services.
MS-initiated GPRS Detach procedure
The MS initiates the GPRS Detach procedure by sending a Detach

Request message. The Detach type information element (IE) indicates
'GPRS Detach with switching off', 'GPRS Detach without switching off',
'IMSI Detach', 'GPRS/IMSI Detach with switching off', or 'GPRS/IMSI
Detach without switching off'. The MS includes the P-TMSI in the Detach
Request message. The MS also includes a valid P-TMSI signature if
available.
When the network receives the Detach Request message, it sends a

Detach Accept message to the MS if the Detach type IE value indicates
that the Detach Request is not sent due to switching off. If switching off has
been indicated, the procedure is completed when the network receives the
Detach Request message. The network and the MS deactivate the PDP
contexts and deactivate any logical links. The MS is marked as inactive in
the network for GPRS services.

Issue 8-0 en
management
When the network receives the Detach Request message from the MS, it
sends a Detach Accept message to the MS if the Detach type IE value
indicates that the Detach Request was not sent due to switching off.
Depending on the value of the Detach type IE, the following applies:
. The MS is marked as inactive in the network for GPRS and for non-
GPRS services. The network and the MS deactivate the PDP
contexts and deactivate any logical links.
.
IMSI Detach: The MS is marked as inactive in the network for non-
GPRS services.
Network-initiated GPRS Detach procedure
The network initiates the GPRS Detach procedure by sending a Detach

Request message to the MS. The Detach Request message includes a
Detach type IE. In addition, the network can include a Cause IE to specify
the reason for the Detach Request. The network starts the T3322 timer. If
the Detach type IE indicates 're-attach not required' or 're-attach required',
the network deactivates the PDP contexts and deactivates any logical
links.
When the network receives the Detach Accept message, it stops the
T3322 timer. The MS is now considered detached.
If the network assigns a cause value to the Detach Request, the cause
value is one of the following:
#2 IMSI unknown in the HLR

#3 Illegal MS
#6 Illegal ME
Detach Request (mobile-terminating detach)
The network sends a Detach Request message to the MS to request the

release of a GMM context. The GMM cause IE is included if the Detach
reason has to be indicated to the MS, for example, due to a failed IMEI
check.

Issue 8-0 en
Management
Table 5. Information elements in a Detach Request message (mobile-

terminating detach)

Skip indicator M
Detach request message identity M
Detach type M
Force to standby M
GMM cause O = optional
Detach Request (mobile-originating detach)
In a mobile-originating Detach, the Detach Request message is sent by

the MS to request the release of a GMM context. The P-TMSI IE is
included by the MS. The P-TMSI signature IE is included if the MS has a
valid P-TMSI signature.
Table 6. Information elements in a Detach Request message (mobile-

originating detach)

Skip indicator M
Spare half octet M
P-TMSI O = optional
P-TMSI signature O
Detach Accept (mobile-terminating detach)
In a mobile-terminating Detach, the Detach Accept message is sent by the

MS to indicate that the Detach procedure is completed.

Issue 8-0 en
management
Table 7. Information elements in a Detach Accept message (mobile-

terminating detach)

Skip indicator M
Detach accept (mobile-originating detach)
In a mobile-originating Detach, the Detach Accept message is sent by the

network to indicate that the Detach procedure is completed.
Table 8. Information elements in a Detach Accept message (mobile-

originating detach)

Skip indicator M
Force to standby M
Spare half octet M
Abnormal cases in GPRS Detach procedure
. T3322 time-out
On the first expiry of the timer, the network retransmits the Detach
Request message and starts the T3322 timer. This retransmission is
repeated four times, that is, the GPRS Detach procedure is aborted
on the fifth expiry of the T3322 timer and the network changes to the
GMM-DEREGISTERED state.
. Lower layer failure
The network aborts the GPRS Detach procedure.
. GPRS Detach procedure collision

Issue 8-0 en
Management
If the network receives a Detach Request message indicating 'with

switching off' before the network-initiated GPRS Detach procedure is
completed, both procedures are considered completed. If the
network receives a Detach Request message indicating 'without
switching off' before the network-initiated GPRS Detach procedure is
completed, the network sends a Detach Accept message to the MS.
. GPRS Detach and GPRS Attach procedure collision
If the network receives an Attach Request message with Detach
type 're-attach not required' before the initiated GPRS Detach
procedure is completed, the network ignores the Attach Request
message. If the Detach type IE value, sent in the Detach Request
message, indicates 're-attach required', the network aborts the
Detach procedure and progresses with the GPRS Attach procedure
after deleting the PDP contexts. If the Detach type IE value, sent in
the Detach Request message, indicates 're-attach not required', the
network aborts the Detach procedure and progresses with the
GPRS Attach procedure.
. GPRS Detach and Routing Area Update procedure collision
.
GPRS Detach containing Detach type 're-attach required' or
're-attach not required':
If the network receives a Routing Area Update Request
message before the network-initiated GPRS Detach
procedure is completed, the network progresses with the
Detach procedure, that is, ignores the Routing Area Update
Request message.
.
GPRS Detach containing Detach type 'IMSI Detach':
If the network receives a Routing Area Update Request
message before the network-initiated GPRS Detach
procedure is completed, the network aborts the Detach
procedure, stops the T3322 timer and progresses with the
Error handling in GPRS Detach procedure
session management.
3.1.7 Routing Area Update procedure
The Routing Area Update procedure is used for the following cases:

Issue 8-0 en
management
. a normal Routing Area Update
Updates the registration of the actual routing area of an MS in the

network.
.
a combined Routing Area Update
Updates the registration of the actual routing and location area of an
MS in the network.
. a periodic Routing Area Update
Notifies periodically the availability of the MS to the network.
. an IMSI Attach for non-GPRS services when the MS is IMSI-
attached for GPRS services.
Description for Routing Area Update procedure
The Routing Area Update procedure is always initiated by the MS. The
network can assign a P-TMSI signature to an MS in the Routing Area
Update procedure. In combination with a valid P-TMSI, the P-TMSI
signature is used by the MS for authentication and identification purposes.
The P-TMSI signatures used previously are deleted in the Routing Area
Update procedure. The value of the READY timer can be negotiated
between the MS and the network in the Routing Area Update procedure.
To initiate the Routing Area Update procedure, the MS sends the Routing
Area Update Request message to the network. This message contains the
P-TMSI signature when received within a previous Attach Accept or
Routing Area Update Accept message. The network then initiates the
GMM common procedures, for example, the authentication and ciphering
procedure.
If the PDP context status IE is included in the Routing Area Update

Request message, the network deactivates all those PDP contexts locally
(without peer-to-peer signalling between the MS and the network), which
are not in the PDP-INACTIVE SM state on the network side but are
indicated by the MS as being in the PDP-INACTIVE state.
If the network accepts the Routing Area Update request, it sends a

Routing Area Update Accept message to the MS. The network can assign
a new P-TMSI or a new P-TMSI signature for the MS. If a new P-TMSI or
P-TMSI signature are assigned to the MS, they are included in the Routing
Area Update Accept message together with the Routing Area Identity
(RAI). A Routing Area Update Complete message is returned to the
network if the Routing Area Update Accept message contains one or both
of the following:

Issue 8-0 en
Management
. a P-TMSI
. Receive N-PDU Numbers
In this case the values of the Receive N-PDU Numbers valid in the MS are
included in the Routing Area Update Complete message.
In case of a periodic GPRS Routing Area Update, the procedure is

controlled in the MS by the Periodic RAU T3312 timer. The network
supervises the procedure with the Mobile Reachable timer which is longer
than the RA update timer. When the Mobile Reachable timer expires, the
network stops sending paging messages to the MS and starts a Standby
timer. After the timer expires, the network performs an implicit Detach. If a
Routing Area Update Request message is received during the Standby
timer, the Mobile Reachable timer is started and the Standby timer is reset.
In GSM, the Mobile Reachable timer is reset and started with its initial
value when the READY timer stops or expires. The Mobile Reachable
timer is stopped and set to its initial value for the next time the READY
timer is started. If the READY timer value is set to zero after a READY
timer negotiation, the Mobile Reachable timer is reset and started with its
initial value. If the initial READY timer value is zero, the Mobile Reachable
timer is reset and started with its initial value when the Routing Area
Update Request message is received.
If the Routing Area Update cannot be accepted, the network sends a

Routing Area Update Reject message to the MS. The message contains a
network reject cause code that typically indicates one of the following
causes:
#3 Illegal MS
#6 Illegal ME
#9 MS identity cannot be derived by the network
#10 Implicitly detached
The combined Routing Area Update procedure is initiated by the MS when

it enters, in idle mode, a new RA, when a GPRS-attached MS performs
IMSI attach or when the periodic RA update timer expires while the MS
remains IMSI- and GPRS-attached. The network can initiate MM common
procedures, such as the authentication and ciphering procedure.

Issue 8-0 en
management
Depending on the value of the Update result IE received in the Routing

Area Update Accept message, two different cases exist when the
combined Routing Area Update is initiated:
.
The update result IE value indicates 'combined RA/LA': Routing and
location area update is successful.
.
The update result IE value indicates 'RA only': Routing area update
is successful, but the location area update is not successful.
A Routing Area Update Complete message is returned to the network if

the Routing Area Update Accept message contains one or both of the
following:
. a P-TMSI or a TMSI
. Receive N-PDU Numbers
The Receive N-PDU Numbers that are valid in the MS are included
in the Routing Area Update Complete message.
If the combined Routing Area Update cannot be accepted, the network

sends a Routing Area Update Reject message to the MS. The message
contains a network reject cause code that typically indicates one of the
following causes:
#3 Illegal MS
#6 Illegal ME
#9 MS identity cannot be derived by the network
#10 Implicitly detached
The combined Routing Area Update procedure continues the same way
as the normal Routing Area Update procedure but it also includes the
location area update actions:

Issue 8-0 en
Management
The handling at the receipt of the Routing Area Update Accept depends on
the value received in the Update result IE as specified below. The TMSI re-
allocation can be part of the combined Routing Area Update procedure.
The allocated TMSI is then included in the Routing Area Update Accept
message together with the location area identity (LAI). In this case the
network starts the T3350 timer. The network receiving a Routing Area
Update Complete message stops the T3350 timer and considers the new
TMSI valid.
The combined GPRS Routing Area Update procedures are accepted for
GPRS services only: the description for normal Routing Area Update.
In addition, the following description for location area update applies: the
message contains a network reject cause code that typically indicates one
of the following causes:
#2 IMSI unknown in the HLR

#16 MSC temporarily not reachable
#17 Network failure
#22 Congestion
Routing Area Update Request
The MS sends a Routing Area Update request to the network to request an

update of its location file or to request an IMSI Attach for non-GPRS
services. The old P-TMSI signature IE is included by the MS if it has been
received from the network in an Attach Accept or Routing Area Update
Accept message. The Requested READY timer value IE is included if the
MS wants to indicate a preferred value for the READY timer. The DRX
parameter IE is included if the MS wants to indicate new DRX parameters.
The TMSI status IE is included if the MS performs a combined Routing
Area Update and no valid TMSI is available.
Table 9. Information elements in a Routing Area Update Request message

mandatory
Skip indicator M
Routing area update request message M
identity
Update type M
GPRS ciphering key sequence number M

Issue 8-0 en
management
Table 9. Information elements in a Routing Area Update Request message

(cont.)

Old routing area identification M
MS radio access capability M
Old P-TMSI signature O = optional
Requested READY timer value O
DRX parameter O
TMSI status O
P-TMSI O
MS network capability O
PDP context status O
PS LCS Capability O Not supported,
ignored if received.
Routing Area Update Accept
The network sends a Routing Area Update Accept message to the MS to

provide the MS with GPRS mobility management-related data in response
to a Routing Area Update Request message. The P-TMSI signature IE can
be included to assign an identity to the GMM context of the MS. The
Allocated P-TMSI IE can be included to assign a P-TMSI to an MS in case
of a GPRS or combined Routing Area Update procedure. The MS identity
IE can be included to assign or unassign a TMSI to an MS in case of a
combined Routing Area Update procedure. The List of Receive N-PDU
Numbers IE is included in case of an Inter-SGSN Routing Area Update if
there are PDP contexts that have been activated in the acknowledged
transfer mode. The negotiated READY timer value IE can be included to
indicate a value for the READY timer. The GMM cause IE is included if the
IMSI Attach has not been successful for non-GPRS services during the
combined GPRS Routing Area Update procedure. The T3302 value IE can
be included to indicate a value for the T3302 timer.
Table 10. Information elements in a Routing Area Update Accept message

mandatory
Skip indicator M

Issue 8-0 en
Management
Table 10. Information elements in a Routing Area Update Accept message

(cont.)

Routing area update accept message M
identity
Force to standby M
Update result M
Periodic RA update timer M
Allocated P-TMSI O
MS identity O
List of Receive N-PDU Numbers O
Negotiated READY timer value O
GMM cause O
T3302 value O This field is never
sent by Nokia
Siemens Networks
SGSN.
Cell notification O This field is never
sent by Nokia
Siemens Networks
SGSN.
Equivalent PLMNs O
Network feature support O This field is never
sent by Nokia
Siemens Networks
SGSN.
Emergency Number List O This field is never
sent by Nokia
Siemens Networks
SGSN.

Issue 8-0 en
management
Routing Area Update Complete
The MS sends a Routing Area Update Complete message to the network

in response to a Routing Area Update Accept message if a P-TMSI or a
TMSI is assigned, or if N-PDU numbers are included in the Routing Area
Update Accept message. The List of Receive N-PDU Numbers IE is
included in the Routing Area Update Complete message if the Routing
Area Update Accept message contains this IE.
Table 11. Information elements in a Routing Area Update Complete message

Skip indicator M
Routing area update complete message M
identity
List of Receive N-PDU Numbers O = optional
Routing Area Update Reject
Table 12. Information elements in a Routing Area Update Reject message

mandatory
Skip indicator M
Routing area update reject message M
identity
GMM cause M
Force to standby M
Spare half octet M
T3302 value O = optional This field is never
sent by Nokia
Siemens Networks
SGSN.
Abnormal cases in Routing Area Update procedure
The following abnormal cases can be identified on the network side with
normal and periodic Routing Area Updates:

Issue 8-0 en
Management
If a lower layer failure occurs before receiving the Routing Area

Update Complete message from the MS and assigning a P-TMSI or
P-TMSI signature, the network aborts the procedure and considers
both the old and the new P-TMSI and the corresponding P-TMSI
signatures valid until the old P-TMSI can be considered invalid.
During this period the network can use the identification procedure
followed by a P-TMSI re-allocation procedure if the old P-TMSI is
used by the MS in a subsequent message.
.
Protocol error
If the Routing Area Update Request message is received with a
protocol error, the network returns a Routing Area Update Reject
message with one of the following reject causes:
#95 Semantically incorrect message

implemented
. T3350 time-out
On the first expiry of the timer, the network retransmits the Routing
Area Update Accept message, resets and restarts the T3350 timer.
The retransmission is performed four times, that is, the Routing Area
Update procedure is aborted on the fifth expiry of the T3350 timer.
The network considers both the old and the new P-TMSI and the
corresponding P-TMSI signatures valid until the old P-TMSI can be
considered invalid.
Abnormal cases with combined Routing Area Update: the abnormal cases
specified with normal and periodic Routing Area Updates apply with the
exceptions for lower layer failure and T3350 time-out, in which, in addition
to the P-TMSI and P-TMSI signature, the old TMSI is considered occupied
until the MS uses the new TMSI in a subsequent message.
Error handling in Routing Area Update procedure
session management.

Issue 8-0 en
management
3.1.8 P-TMSI re-allocation procedure
Description for P-TMSI re-allocation procedure
The network initiates the P-TMSI re-allocation procedure by sending a P-

TMSI re-allocation Command message to the MS and starting the T3350
timer. The P-TMSI re-allocation Command message contains a new
combination of P-TMSI, RAI, and optionally a P-TMSI signature allocated
by the network. The network must not send any user data during the P-
TMSI re-allocation procedure.
The P-TMSI re-allocation procedure can be completed by the MS or by the

network. The network can also assign a P-TMSI signature to an MS in the
P-TMSI re-allocation procedure. Upon the receipt of the P-TMSI re-
allocation Command message, the MS stores the RAI and the P-TMSI and
sends a P-TMSI Re-allocation Complete message to the network. If a P-
TMSI signature is present in the P-TMSI re-allocation Command message,
the MS stores the new P-TMSI signature and, if available, deletes the old
P-TMSI signature. If no P-TMSI signature is present in the P-TMSI re-
allocation Command message, the old P-TMSI signature, if available, is
kept.
When receiving the P-TMSI re-allocation Complete message, the network

stops the T3350 timer and considers the new P-TMSI valid and the old one
invalid. The GMM layer notifies the LLC layer that the P-TMSI has
changed.
A temporary mobile station identity for GPRS services, the P-TMSI, is

used for authentication and identification. The purpose of the P-TMSI re-
allocation procedure is to provide identity confidentiality, that is, to protect a
user against being identified and located by an intruder. The P-TMSI re-
allocation is either part of the GPRS Attach procedure or the GPRS
P-TMSI Re-allocation Command
The network sends a P-TMSI re-allocation command to the MS to re-

allocate a P-TMSI. The P-TMSI signature IE assigns an identity to the
GMM context of the MS.
Table 13. Information elements in a P-TMSI Re-allocation Command message

Skip indicator M

Issue 8-0 en
Management
Table 13. Information elements in a P-TMSI Re-allocation Command message

(cont.)

P-TMSI re-allocation command M
message identity
Allocated P-TMSI M
Force to standby M
Spare half octet M
P-TMSI Re-allocation Complete
The MS sends a P-TMSI Re-allocation Complete message to the network

to indicate that the re-allocation of a P-TMSI has taken place.
Table 14. Information elements in a P-TMSI Re-allocation Complete message

Skip indicator M
P-TMSI re-allocation complete message M
identity
Abnormal cases in P-TMSI re-allocation procedure
If a lower layer failure is detected before receiving the P-TMSI re-

allocation Complete message, the old and the new P-TMSI are
considered occupied until the network can consider the old P-TMSI
invalid. During this period, the network can first use the old P-TMSI
for paging for an implementation-dependent number of paging
attempts in case of network-originated transactions. When the
network receives a response from the MS, the network can re-initiate
the P-TMSI re-allocation. If no response is received to the paging

Issue 8-0 en
management
attempts, the network can use the new P-TMSI for paging for an
implementation-dependent number of paging attempts. When the
network receives a response from the MS, the network considers the
new P-TMSI valid and the old P-TMSI invalid.
. Expiry of the T3350 timer
The T3350 timer supervises the P-TMSI re-allocation procedure. On
the first expiry of the T3350 timer, the network resets and restarts the
T3350 timer and retransmits the P-TMSI re-allocation Command.
This retransmission is repeated four times, that is, the network
aborts the re-allocation procedure on the fifth expiry of the T3350
timer, and follows the rules for the case described above.
. P-TMSI re-allocation and GPRS Attach procedure collision
If the network receives an Attach Request message before the
ongoing P-TMSI re-allocation procedure is completed, the network
proceeds with the GPRS Attach procedure after deleting the GMM
context.
.
P-TMSI re-allocation and an MS-initiated GPRS Detach procedure
collision
If the network receives a Detach Request message before the
ongoing P-TMSI re-allocation procedure is completed, the network
aborts the P-TMSI re-allocation procedure and progresses with the
GPRS Detach procedure.
. P-TMSI re-allocation and a Routing Area Update procedure collision
If the network receives a Routing Area Update Request message
before the ongoing P-TMSI re-allocation procedure is completed, the
network aborts the P-TMSI re-allocation procedure and progresses
with the Routing Area Update procedure. The network then performs
a new P-TMSI re-allocation during the Routing Area Update
procedure.
Note
If there are different new P-TMSIs included in the subsequent P-TMSI

re-allocation Command messages due to an aborted or repeated P-
TMSI re-allocation procedure, the MS always considers the latest and
its existing P-TMSI valid for the recovery time.

Issue 8-0 en
Management
3.1.9 Authentication and ciphering procedure
Description for authentication and ciphering procedure
The network initiates the authentication and ciphering procedure by

sending an Authentication and Ciphering Request message to the MS and
starts the T3360 timer. The Authentication and Ciphering Request
message contains all the parameters that are necessary to calculate the
response parameters when authentication is performed.
If authentication is requested, the Authentication and Ciphering Request

message contains one of the following alternatives:
. In a GSM authentication challenge:
the GPRS ciphering key sequence number, allocated to the GPRS

GSM ciphering key and the Random Number (RAND).
.
In a UMTS authentication challenge:
the GPRS ciphering key sequence number, allocated to the GPRS
UMTS ciphering and GPRS UMTS integrity keys, the RAND and the
Authentication Token (AUTN).
In the GSM, if authentication is not requested, the Authentication and

Ciphering Request message does not contain the GPRS ciphering key
sequence number, the RAND or the AUTN.
In the GSM, if ciphering is requested, in a GSM authentication challenge or

in a UMTS authentication challenge, the Authentication and Ciphering
Request message indicates the GPRS GSM ciphering algorithm.
The network includes the A&C reference number information element in

the Authentication and Ciphering Request in an RA with its Response
message. The A&C reference number value can be based on the RA
Colour Code value. Additionally, the network can request the MS to include
its IMEISV in the Authentication and Ciphering Response message.
In the GSM, an MS that is attached to the GPRS is ready to respond to an

Authentication and Ciphering Request any time.
In the UMTS, an MS that is attached to the GPRS is ready to respond

upon an Authentication and Ciphering Request message any time while a
PS signalling connection exists.

Issue 8-0 en
management
An MS, which does not support the UMTS authentication algorithm,

ignores the AUTN IE Authentication Parameter if included in the
Authentication and Ciphering Request message, and performs the GSM
authentication challenge.
When the network receives the Authentication and Ciphering Response

message, it stops the T3360 timer and checks the validity of the response.
For this, it can use the A&C reference number information element within
the Authentication and Ciphering Response message to determine
whether the response correlates to the last request sent.
In the GSM, the GMM layer notifies the LLC sublayer whether ciphering is
used or not, and if it is, also which algorithm and GPRS GSM ciphering key
is used.
If authentication and ciphering fails, that is, if the response is not valid, the
network checks if the MS used the P-TMSI or the IMSI for identification.
.
If the P-TMSI is used, the network can decide to initiate the
identification procedure. If the IMSI given by the MS differs from the
one that the network associated with the P-TMSI, the authentication
is restarted with the correct parameters. If the IMSI provided by the
MS is the expected one (authentication failed), the network proceeds
as described below.
. If the IMSI is used, or the network decides not to try the identification
procedure, an Authentication and Ciphering Reject message is sent
to the MS.
Nokia Siemens Networks SGSN does not send a Reject message

because authentication is always done in connection with other MM/SM/
SMS procedures and the whole MM/SM/SMS procedure is rejected if
authentication fails.
If ciphering is to be applied in a mobility management context, all

messages are ciphered except for the following: Attach Request, Attach
Reject, Authentication and Ciphering Request, Authentication and
Ciphering Response, Authentication and Ciphering Reject, Identity
Request, Identity Response, Routing Area Update Request, and Routing
Area Update Reject.
The security parameters for authentication and ciphering are tied together
in sets. In a GSM authentication challenge both the authentication
response parameter SRES and the GPRS GSM ciphering key Kc can be
computed from the RAND challenge parameter, given the secret key

Issue 8-0 en
Management
associated with the IMSI. In a UMTS authentication challenge the

authentication response parameter XRES, the GPRS UMTS ciphering key
CK, and the integrity key IK can be computed from the RAND challenge
parameter, given the secret key associated with the IMSI.
In order to allow the start of ciphering on a logical link without

authentication, GPRS ciphering key sequence numbers are introduced.
The GPRS ciphering key sequence number is managed by the network so
that the Authentication and Ciphering Request message contains the
GPRS ciphering key sequence number allocated to the GPRS GSM
ciphering key (in case of a GSM authentication challenge) or the GPRS
UMTS ciphering key and the GPRS UMTS integrity key (in case of a
UMTS authentication challenge) which can be computed from the RAND
parameter carried in that message.
The MS stores the GPRS ciphering key sequence number with the GPRS
GSM ciphering key (in case of a GSM authentication challenge), the
GPRS UMTS ciphering key and the GPRS UMTS integrity key (in case of
a UMTS authentication challenge), and includes the corresponding GPRS
ciphering key sequence number in the Routing Area Update Request and
Attach Request messages.
If the GPRS ciphering key sequence number is deleted, the associated

GPRS GSM ciphering key, GPRS UMTS ciphering key and GPRS UMTS
integrity key are also deleted. In other words, the established GSM
security context or the UMTS security context is no longer valid.
In the GSM, the network can decide to start ciphering with the stored
GPRS ciphering key if the stored GPRS ciphering key sequence number
and the one sent by the MS are the same and the previously negotiated
ciphering algorithm is known and supported in the network. When
ciphering is requested at a GPRS Attach, the authentication and ciphering
procedure is performed since the MS does not store the ciphering
algorithm at Detach.
Upon a GPRS Attach, if ciphering is to be used, an Authentication and

Ciphering Request message is sent to the MS to start ciphering.
If the GPRS ciphering key sequence number stored in the network does
not match the GPRS ciphering key sequence number received from the
MS in the Attach Request message, the network authenticates the MS.
In the GSM the MS starts ciphering after sending the Authentication and
Ciphering Response message. The network starts ciphering when a valid
Authentication and Ciphering Response is received from the MS.

Issue 8-0 en
management
In the GSM the network can decide to continue ciphering without sending
an Authentication and Ciphering Request message after receiving a
Routing Area Update Request message with a valid GPRS ciphering key
sequence number. Both the MS and the network use the latest ciphering
parameters. The network starts ciphering when sending the ciphered
Routing Area Update Accept message to the MS. The MS starts ciphering
after receiving a valid ciphered Routing Area Update Accept message
from the network.
Note
In some specifications, the term key set identifier (KSI) is used instead
of the term GPRS ciphering key sequence number.
Authentication and Ciphering Request
The network sends an Authentication and Ciphering Request message to

the MS to initiate the authentication of the MS identity. Additionally, the
ciphering mode is set, indicating whether ciphering is performed or not.
The RAND IE authentication parameter is included only if authentication is
performed. The GPRS ciphering key sequence number IE is included only
if the RAND authentication parameter is contained in the message. The
AUTN IE authentication parameter is present only if the authentication
challenge is a UMTS authentication challenge.
Table 15. Information elements in an Authentication and Ciphering Request

message

Skip indicator M
Authentication and ciphering request M
message identity
Ciphering algorithm M
IMEISV request M
Force to standby M
A&C reference number M
RAND authentication parameter O = optional
GPRS ciphering key sequence number C
AUTN authentication parameter O

Issue 8-0 en
Management
Authentication and Ciphering Response
The MS sends an Authentication and Ciphering Response message to the

network in response to an Authentication and Ciphering Request
message.
The IE Authentication Response parameter is included if authentication is

requested in the corresponding Authentication and Ciphering Request
message. This IE contains a signed response (SRES) if the authentication
challenge is for GSM, or a resume message (RES) if it is for a UMTS
authentication challenge.
The IMEISV IE is included if requested within the corresponding

Authentication and Ciphering Request message.
The IE Authentication Response parameter (extension) is included only if

the authentication challenge is a UMTS authentication challenge.
Table 16. Information elements in an Authentication and Ciphering Response

message

Skip indicator M
Authentication and ciphering response M
message identity
A&C reference number M
Spare half octet M
Authentication Response parameter O = optional
IMEISV O
Authentication Response parameter O
(extension)
Authentication and Ciphering Failure
The MS sends an Authentication and Ciphering Failure message to the

network in response to an Authentication and Ciphering Request message
to indicate that the authentication of the network failed. The IE
Authentication Failure parameter is included only if the GMM cause is
'Synch failure'. It includes a response to the authentication challenge from
the SIM. This response is made up of the AUTS parameter.

Issue 8-0 en
management
Table 17. Information elements in an Authentication and Ciphering Failure

message

Mobility Management M = mandatory
Skip indicator M
Authentication and Ciphering Failure M
Message type M
GMM Cause M
Authentication Failure parameter O = optional
Authentication and Ciphering Reject
Nokia Siemens Networks SGSN does not send the Authentication and
Ciphering Reject message since the authentication procedure is always
done as part of another GMM operation, not as a standalone operation.
Abnormal cases in Authentication and ciphering procedure
If the network detects a lower layer failure before receiving the

Authentication and Ciphering Response, the network aborts the
procedure.
. Expiry of the T3360 timer
On the first expiry of the T3360 timer, the network retransmits the
Authentication and Ciphering Request, resets and restarts the
T3360 timer. This retransmission is repeated four times, that is, the
procedure is aborted on the fifth expiry of the T3360 timer.
. Collision of an authentication and ciphering procedure with a GPRS
Attach procedure
ongoing authentication procedure is completed and no GPRS Attach
procedure is pending in the network (no Attach Accept or Attach
Reject message has to be sent as an answer to an Attach Request
message), the network aborts the authentication and ciphering
procedure and progresses with the new GPRS Attach procedure.

Issue 8-0 en
Management

Attach procedure when a previous GPRS Attach procedure has
caused the authentication and ciphering procedure
ongoing authentication procedure is completed and a GPRS Attach
procedure is pending (in other words, an Attach Accept or Attach
Reject message has still to be sent as an answer to an earlier Attach
Request message), the following can happen:
. If one or more of the information elements in the Attach
Request message differ from the ones received within the
previous Attach Request message, the network does not treat
the authentication any further and progresses with the GPRS
Attach procedure.
. If the information elements do not differ, the network does not
treat this new Attach Request any further.
Detach procedure
. GPRS Detach containing cause 'power off':
ongoing authentication and ciphering procedure is completed,
the network aborts the authentication and ciphering procedure
and progresses with the GPRS Detach procedure.
. GPRS Detach containing other causes than 'power off':
ongoing authentication and ciphering procedure is completed,
the network completes the authentication and ciphering
procedure and responds to the GPRS Detach procedure.
.
Collision of an authentication and ciphering procedure with a
Routing Area Update procedure
before the ongoing authentication procedure is completed, the
network progresses with both procedures.
Error handling in Authentication and ciphering procedure
session management.

Issue 8-0 en
management
3.1.10 Identification procedure
The identification procedure is used by the network to request an MS to

provide specific identification parameters to the network, for example,
international mobile subscriber identity (IMSI) or international mobile
equipment identity (IMEI).
The network initiates the identification procedure by sending an Identity

Request message to the MS and starting the T3370 timer. The Identity
Request message specifies the requested identification parameters in the
identity type IE. A GPRS-attached MS is ready to respond to an Identity
Request message any time. When the MS receives the Identity Request
message, the MS sends back an Identity Response message. The Identity
Response message contains the identification parameters as requested
by the network.
When the network receives an Identity Response, it stops the T3370 timer.
Identity Request
The network sends an Identity Request message to the MS to request the

submission of the MS identity according to the specified identity type.
Table 18. Information elements in an Identity Request message

Skip indicator M
Identity request message identity M
Identity type M
Force to standby M
Identity Response
The MS sends an Identity Response message to the network in response

to an Identity Request message providing the requested identity.
Table 19. Information elements in an Identity Response message


Issue 8-0 en
Management
Table 19. Information elements in an Identity Response message (cont.)

Skip indicator M
Identity response message identity M
Mobile identity M
Abnormal cases in Identification procedure
.
Lower layer failure
If the network detects a lower layer failure before receiving the

Identity Response, it aborts any ongoing mobility management
procedures.
.
Expiry of the T3370 timer
The network supervises the identification procedure with the T3370
timer. On the first expiry of the T3370 timer, the network retransmits
the Identity Request message, resets and restarts the T3370 timer.
This retransmission is repeated four times, that is, the network
aborts the identification procedure and any ongoing mobility
management procedures on the fifth expiry of the T3370 timer.
.
Collision of an identification procedure with a GPRS Attach
procedure
ongoing identification procedure is completed and no GPRS Attach
procedure is pending in the network (no Attach Accept or Attach
Reject message has still to be sent as an answer to an Attach
Request message), the network progresses with the GPRS Attach
procedure.
. Collision of an identification procedure with a GPRS Attach
procedure when the identification procedure is caused by a GPRS
Attach procedure
ongoing identification procedure is completed and a GPRS Attach
procedure is pending (an Attach Accept or Attach Reject message
has to be sent as an answer to an earlier Attach Request message),
the following can happen:

Issue 8-0 en
management
. If one or more of the information elements in the Attach

Request message differ from the ones received in the previous
Attach Request message, the network progresses with the
GPRS Attach procedure.
. If the information elements do not differ, the network does not
treat this new Attach Request any further.
. Collision of an identification procedure with an MS-initiated GPRS
Detach procedure
. GPRS Detach containing cause 'power off':
ongoing identification procedure is completed, the network
aborts the identification procedure and progresses with the
. GPRS Detach containing other causes than 'power off':
ongoing identification procedure is completed, the network
completes the identification procedure and responds to the
.
Collision of an identification procedure with a Routing Area Update
procedure
before the ongoing identification procedure is completed, the
network progresses with both procedures.
Error handling in Identification procedure
session management.
3.1.11 GMM Status procedure
GMM status
This message is sent by the MS or by the network at any time to report the
following error conditions:
. The network received a GPRS Mobility Management (GMM)

message with a message type which is not defined for the protocol
discriminator or not implemented by the receiver (cause # 97:
'Message type non-existent or not implemented').
.
The network received a message not compatible with the protocol
state (cause # 98: 'Message type not compatible with protocol
state').

Issue 8-0 en
Management
Table 20. GMM Status message content

Skip indicator M
GMM Status message identity M
GMM cause M
3.1.12 GMM Information procedure
GMM information
This message is sent by the network any time to send certain pieces of
information to the MS.
Table 21. GMM Information message content

Skip indicator M
GMM Information message identity M
Full name for network O = optional
Short name for network O
Local time zone O
Universal time and local time zone O
LSA Identity O
Network Daylight Saving Time O
3.1.13 Paging procedure
The network uses paging in the following cases:
.
to identify the cell the MS currently selected
. to prompt the mobile to re-attach after a network failure

Issue 8-0 en
management
Description for paging procedure
The network initiates the paging procedure by using P-TMSI when GMM
signalling messages or user data is pending to be sent to the MS while the
Mobile Reachable timer is running. The network can page only GPRS
mobile stations that are GMM-REGISTERED and identified by a local P-
TMSI. The network requests the RR sublayer to start paging, and starts
the T3313 timer. If the MS is not GPRS-Attached when it receives a page
for GPRS services, the MS ignores the paging. The network stops the
T3313 timer when it receives a response from the MS. When the T3313
timer expires, the network can re-initiate paging. The network starts the
READY timer when it receives a response from the MS.
Paging for GPRS services using IMSI is not supported.
The network can initiate the paging procedure for non-GPRS services
when the MS is IMSI-Attached for non-GPRS services. To initiate the
procedure, the GMM entity requests the RR sublayer to start paging for
non-GPRS services. The MS identity used for paging is the allocated TMSI
if acknowledged by the MS, otherwise it is the IMSI.
Error handling in Paging procedure
session management.
3.1.14 Service Request procedure (UMTS only)
The purpose of this procedure is to transfer the PMM mode from the PMM-
IDLE to the PMM-CONNECTED mode, and/or to assign the radio access
bearer (RAB) if PDP contexts are activated without RAB assigned. In the
latter case, the PMM mode may be either the PMM-IDLE mode or the
PMM-CONNECTED mode if the MS requires RAB re-establishment. This
procedure is used for:
.
The initiation of the CM layer service (SM or SMS, for example)
procedure from the MS in the PMM-IDLE mode.
.
The network to transfer downlink signalling.
. The uplink (in the PMM-IDLE or PMM CONNECTED mode) and
downlink (only in the PMM-IDLE mode) of user data.

Issue 8-0 en
Management
After receiving a Service Request message the network may initiate GMM
common procedures, for example the GMM identification or the GMM
authentication and ciphering procedure, depending on the received
information, such as the GPRS ciphering key sequence number and the P-
TMSI.
Service Request (UMTS only)
This message is sent by the MS to establish a logical association between

the MS and the network.
Table 22. Service Request message content

Skip indicator M
Service request message identity M
Ciphering key sequence number M
Service type M
P-TMSI M
Uplink data status O
Service Accept (UMTS only)
This message is sent by the network as a response to a Service Request

message.
Table 23. Service Accept message content

Skip indicator M
Service accept message identity M

Issue 8-0 en
management
Service Reject (UMTS only)
This message is sent by the network to the UE in order to reject the

Service request procedure.
Table 24. Service Reject message content

Skip indicator M
Service reject message identity M
GMM cause M
Abnormal cases in Service Request procedure (UMTS only)
If a lower layer failure occurs before the security mode control

procedure is completed or a Service Accept or Service Reject
message has been sent to the MS, the network enters/stays in the
PMM-IDLE mode.
. Protocol error
If the Service Request message is received with a protocol error, the
network returns a Service Reject message with one of the following
reject causes:

implemented
The network stays in the PMM-IDLE mode.

. More than one Service Request received and the procedure has not
been completed (that is, the security mode control procedure has not
been completed, or a Service Accept or Service Reject message
has not been sent)

Issue 8-0 en
Management
. If one or more of the information elements in the Service

Request message differs from the ones received within the
previous Service Request message, the previously initiated
Service request procedure is aborted and the new Service
request procedure is progressed.
.
If the information elements do not differ, the network continues
with the previous Service request procedure and does not
treat any further this Service Request message.
. Attach Request received before the security mode control procedure
has been completed, or a Service Accept or Service Reject
message has been sent
If an Attach Request message is received and the security mode
control procedure has not been completed, or a Service Accept or
Service Reject message has not been sent, the network may initiate
the GMM common procedures, for example the GMM authentication
and ciphering procedure. The network may abort the Service
request procedure after a successful GMM authentication and
ciphering procedure execution, for example; the GMM context and
the PDP contexts, if any, are deleted and the new Attach Request is
progressed.
. Routing Area Update Request message received before the security
mode control procedure has been completed, or a Service Accept or
Service Reject message has been sent
If a Routing Area Update Request message is received and the
security mode control procedure has not been completed, or a
Service Accept or Service Reject message has not been sent, the
network may initiate the GMM common procedures, for example the
GMM authentication and ciphering procedure. The network may
abort the Service request procedure and progress with the routing
area update procedure after a successful GMM authentication and
ciphering procedure execution, for example.
Error handling in Service Request procedure (UMTS only)
session management.
3.1.15 General message format and information elements for mobility

management
The Protocol Discriminator (PD) and its use are defined in 3GPP TS
24.007 Mobile radio interface signalling layer 3; General Aspects.

Issue 8-0 en
management
Bits 5 to 8 of the first octet of every Mobility Management message and

GPRS Mobility Management message contain the skip indicator. A
message received with a skip indicator different from 0000 is ignored. A
message received with a skip indicator encoded as 0000 is not ignored
unless it is ignored for other reasons. A protocol entity sending a Mobility
Management message or a GPRS Mobility Management message
encodes the skip indicator as 0000.
The message type IE and its use are defined in 3GPP TS 24.007 Mobile
radio interface signalling layer 3; General Aspects. Table 11.2 of this
specification defines the value part of the message type IE used in the
mobility management protocol and the call control protocol.
When the radio connection starts with a core network node of earlier than
3GPP R99, bit 8 is set to 0 and bit 7 is reserved for the sequence number
sent in messages from the MS. In messages sent from the network, bits 7
and 8 are coded with a '0'. When the radio connection starts with a core
network node of 3GPP R99 or later, bits 7 and 8 are reserved for the
sequence number sent in messages from the MS. In messages sent from
the network, bits 7 and 8 are coded with a '0'.
3.1.16 GPRS Mobility Management timers
There are four GPRS Mobility Management timers on the network side:
T3322, T3350, T3360, and T3370. The table below summarises their
causes of start and stop, and the timer values.
Table 25. GMM timers
Timer Number Timer Value Cause of Start Normal Stop

T3322 6s DETACH REQ sent DETACH ACCEPT received
T3350 6s ATTACH ACCEPT sent with ATTACH COMPLETE
P-TMSI or TMSI received
RAU ACCEPT sent with P- RAU COMPLETE received
TMSI or TMSI
P-TMSI REALLOC
P-TMSI REALLOC COMPLETE received
COMMAND sent
T3360 6s AUTH AND CIPH REQUEST AUTH AND CIPH
sent RESPONSE received
AUTH AND CIPH FAILURE
received
T3370 6s IDENTITY REQUEST sent IDENTITY RESPONSE
received

Issue 8-0 en
Management
3.2 GPRS session management

The main function of the session management (SM) is to support the PDP
context handling of the mobile station (MS).
GPRS session management states
The SM states are described for one SM entity. Each SM entity is

associated with one PDP context.
GPRS Session Management procedures
The SM comprises of procedures for identified PDP context activation,

modification, and deactivation. SM procedures for identified access can
only be performed if a GPRS mobility management (GMM) context is
established between the MS and the network. If no GMM context is
established, the GMM sublayer has to initiate the establishment of a GMM
context using the GMM procedures. After the GMM context establishment,
the SM uses the services offered by the GMM. The ongoing SM
procedures are suspended during the execution of GMM procedures.
3.2.1 PDP context activation
The purpose of this procedure is to establish a PDP context between the

MS and the network for a specific quality of service (QoS) on a specific
NSAPI. Each PDP address can be described by one or more PDP
contexts in the MS or the network. The PDP Context Activation procedure
is used to activate the first PDP context for a given PDP address and
access point name (APN), whereas all additional contexts associated with
the same PDP address and APN are activated with the secondary PDP
context activation procedure. When more than one PDP contexts are
associated with a PDP address, there must be a traffic flow template (TFT)
for each or all but one context. The TFT is sent transparently through
Nokia Siemens Networks SGSN to the GGSN to enable packet
classification and policing for downlink data transfer.
Network-requested PDP context activation procedure
In Nokia Siemens Networks SGSN, only the MS can initiate the PDP
context activation.

Issue 8-0 en
management
Mobile-originating PDP context activation procedure
In order to request a PDP context activation, the MS sends an Activate

PDP Context Request message to the network. The message contains the
selected NSAPI, PDP type, requested QoS, and, if the MS requests a
static address, the PDP address. The MS ensures that the selected NSAPI
is not being used currently by another session management entity in the
MS.
When the network receives an Activate PDP Context Request message, it

selects a radio priority level based on the negotiated QoS and can reply
with an Activate PDP Context Accept message. When the MS receives the
Activate PDP Context Accept message, it stops the T3380 timer and
enters the PDP-ACTIVE state. If the offered QoS parameters received
from the network differ from the QoS requested by the MS, the MS either
accepts the negotiated QoS or initiates the PDP Context Deactivation
procedure.
The MS initiates the establishment of the logical link for the LLC SAPI
indicated by the network with the offered QoS and selected radio priority
level if no logical link was already established for that SAPI. If the offered
QoS parameters received from the network differ from the QoS requested
by the MS, the MS either accepts the negotiated QoS or initiates the PDP
context deactivation procedure. If the LLC SAPI indicated by the network
cannot be supported by the MS, the MS initiates the PDP Context
Deactivation procedure.
When the network receives an Activate PDP Context Request message, it

can reject the MS-initiated PDP context activation by sending an Activate
PDP Context Reject message to the MS. The message contains a cause
code that typically indicates one of the following causes:
# 26 Insufficient resources
# 27 Missing or unknown APN
# 28 Unknown PDP address or PDP type
# 29 User authentication failed
# 30 Activation rejected by GGSN
# 31 Activation rejected, unspecified
# 32 Service option not supported
# 33 Requested service option not subscribed
# 34 Service option temporarily out of order
# 95 - 111 Protocol errors
When the MS receives an Activate PDP Context Reject message, it stops

the T3380 timer and enters or remains in the PDP-INACTIVE state.

Issue 8-0 en
Management
Activate PDP Context Request
The MS sends an Activate PDP Context Request message to the network

to request the activation of a PDP context. The Access point name IE is
included in the message when the MS selects a specific external network
to be connected to. The Protocol configuration options IE is included in the
message when the MS provides protocol configuration options for the
external PDN.
Table 26. Information elements in an Activate PDP Context Request message

Transaction identifier M
Activate PDP context request message M
identity
Requested NSAPI M
Requested LLC SAPI M
Requested QoS M
Requested PDP address M
Access point name O = optional
Protocol configuration options O
Activate PDP Context Accept
The network sends an Activate PDP Context Accept message to the MS to

acknowledge the activation of a PDP context. If the MS has not requested
a static address in the corresponding Activate PDP Context Request
message, the network includes the PDP address IE in this message. If the
MS has requested a static address in the corresponding Activate PDP
Context Request message, the network does not include the PDP address
IE in this message. The Protocol configuration options IE is included in the
message when the network wishes to transmit protocol configuration
options to the external PDN. PFI IE is included if the network wants to
indicate the packet flow identifier associated with the PDP context.
Table 27. Information elements in an Activate PDP Context Accept message


Issue 8-0 en
management
Table 27. Information elements in an Activate PDP Context Accept message

(cont.)

Activate PDP context accept message M
identity
Negotiated LLC SAPI M
Negotiated QoS M
Radio priority M
Spare half octet M
PDP address O = optional
Packet Flow identifier O
Activate PDP Context Reject
The network sends an Activate PDP Context Reject message to the MS to

reject the activation of a PDP context. The Protocol configuration options
IE can only be inserted by the network if the SM Cause indicates
'Activation rejected by GGSN'.
Table 28. Information elements in an Activate PDP Context Reject message

Activate PDP context reject message M
identity
SM cause M
Protocol configuration options O = optional
Abnormal cases in PDP context activation

Issue 8-0 en
Management
. Expiry of timers
On the first expiry of the T3385 timer, the network resends the
Request PDP Context Activation message, resets and restarts the
network releases the resources possibly allocated to this activation
and aborts the procedure on the fifth expiry of the T3385 timer.
Note
In general, the MS is unable to test if the PDP type, PDP address, and
APN in the Request PDP Context Activation message are the same as
those for the PDN to which the MS is attempting to activate a context.
This is because the MS could omit one or more of the parameters in the
Activate PDP Context Request message since it is relying on the
default values to be provided by the network.
.
MS-initiated PDP context activation request for an already activated
PDP context
.
If the combination of PDP type, PDP address, and APN
matches those of an already activated PDP context(s), the
network locally deactivates all existing PDP contexts that
match the combination of APN, PDP type and PDP address
without notifying the MS and proceeds with the requested PDP
context activation.
. Otherwise, if the NSAPI matches one of an already activated
PDP context(s), the network locally deactivates this PDP
context and all the PDP contexts linked to this one without
notifying the MS and proceeds with the activation of the
requested PDP context.
Error handling in PDP context activation
session management.
3.2.2 Secondary PDP context activation
The purpose of this procedure is to establish an additional PDP context

between the MS and the network for a specific traffic flow template (TFT)
and QoS profile on a specific NSAPI, when one or more PDP contexts are
already associated with that particular PDP address. There must be a TFT
for each or all but one context. Secondary PDP context activation can only
be initiated by the MS.

Issue 8-0 en
management
In order to request a PDP context activation with the same PDP address
and APN as an already active PDP context, the MS sends an Activate
Secondary PDP Context Request message to the network. The message
contains the selected NSAPI. The MS ensures that the selected NSAPI is
not being used currently by another SM entity in the MS. The message
also includes a QoS profile, a requested LLC SAPI, and the Linked TI. The
QoS profile is the requested QoS. If present, the TFT is sent transparently
through Nokia Siemens Networks SGSN to the GGSN to enable packet
classification and policing for downlink data transfer. When the network
receives an Activate Secondary PDP Context Request, it validates the
message by verifying the TI given in the Linked TI IE to be any of the active
PDP context(s). The same GGSN address is used by Nokia Siemens
Networks SGSN for the already established PDP context(s) for that PDP
address. The network selects a radio priority level based on the negotiated
QoS and replies with an Activate Secondary PDP Context Accept
message, if the request can be accepted. If the offered QoS parameters
received from the network differ from the QoS requested by the MS, the
MS either accepts the negotiated QoS or initiates the PDP context
deactivation procedure. The MS initiates the establishment of a logical link
for the LLC SAPI indicated by the network with the offered QoS and the
selected radio priority level if no logical link is already established for that
SAPI. If the MS cannot support the LLC SAPI indicated by the network, the
MS initiates the PDP context deactivation procedure.
When the network receives an Activate Secondary PDP Context Request

message, it can reject the MS-initiated PDP context activation by sending
an Activate Secondary PDP Context Reject message to the MS. The
message contains a cause code that typically indicates one of the
following:
#26 Insufficient resources

#30 Activation rejected by GGSN
#31 Activation rejected by, unspecified
#32 Service option not supported
#33 Requested service option not supported
#34 Service option temporarily out of order
#41 Semantic error in the TFT operation
#42 Syntactical error in the TFT operation
#43 Unknown PDP context
#44 Semantic errors in packet filter(s)
#45 Syntactical errors in packet filter(s)
#46 PDP context without TFT already activated
#95 111 Protocol errors

Issue 8-0 en
Management
Activate Secondary PDP Context Request
The MS sends an Activate Secondary PDP Context Request message to

the network to request the activation of an additional PDP context
associated with the same PDP address and APN as an already active
PDP context. The TFT IE is included if a PDP context without TFT is
already activated.
Table 29. Information elements in an Activate Secondary PDP Context

Request message

Activate secondary PDP context request M
message identity
Requested NSAPI M
Requested QoS M
Linked TI M
TFT O = optional
Activate Secondary PDP Context Accept
The network sends an Activate Secondary PDP Context Accept message

to the MS to acknowledge the activation of an additional PDP context
associated with the same PDP address and APN as an already active
PDP context. PFI IE is included if the network wants to indicate the Packet
Flow Identifier associated with the PDP context.

message

Activate secondary PDP context accept M
message identity

Issue 8-0 en
management

message (cont.)

Negotiated LLC SAPI M
Negotiated QoS M
Radio priority M
Spare half octet M
Packet Flow identifier O = optional
Activate Secondary PDP Context Reject
The network sends an Activate Secondary PDP Context Reject message

to the MS to reject the activation of an additional PDP context associated
with the same PDP address and APN as an already active PDP context.
The Reject message is also sent if the linked TI indicated by the MS does
not point to a valid primary context in Nokia Siemens Networks SGSN.
Table 31. Information elements in an Activate Secondary PDP Context Reject

message

Activate secondary PDP context reject M
message identity
SM cause M
Abnormal cases in secondary PDP context activation
The following abnormal case can be identified:
. MS-initiated secondary PDP context activation procedure for an

already activated PDP context:

Issue 8-0 en
Management
If the NSAPI matches one of an already activated PDP context, the

network deactivates the existing one locally without notifying the MS
and proceeds with the requested PDP context activation.
Error handling in secondary PDP context activation
session management.
3.2.3 PDP context modification
The PDP context modification procedure is initiated in order to change the

QoS, the radio priority level, or the TFT negotiated during the PDP context
activation procedure, the secondary PDP context activation procedure, or
previously performed PDP context modification procedures. The PDP
context modification procedure can be invoked either by the network or the
MS any time when the PDP context is active. The MS can also create and
delete a TFT in an active PDP context.
Network-initiated procedure
In order to initiate the procedure, the network sends the Modify PDP
Context Request message to the MS and starts the T3386 timer. The
message contains the new QoS, the radio priority level and the LLC SAPI
that are used by the MS at the lower layers for the transmission of data
related to the PDP context. When the MS receives this message, it replies
with the Modify PDP Context Accept message if the MS accepts the new
QoS and the indicated LLC SAPI. If the MS does not accept the new QoS
or the indicated LLC SAPI, the MS initiates the PDP context deactivation
procedure for the PDP context - the reject cause IE value of the Deactivate
PDP Context Request message indicates 'QoS not accepted'. When the
network receives the Modify PDP Context Accept message, it stops the
T3386 timer. The network establishes, reconfigures or continues using the
logical link to the new QoS for the LLC SAPI indicated in the Modify PDP
Context Request message.
MS-initiated procedure
In order to initiate the procedure, the MS sends the Modify PDP Context
Request message to the network. The message can contain the requested
new QoS or the TFT and the requested LLC SAPI. When the network
receives the Modify PDP Context Request message, it can reply with the
Modify PDP Context Accept message in order to accept the context
modification. The reply message can contain the negotiated QoS and the
radio priority level based on the new QoS profile and the negotiated LLC
SAPI that is used by the logical link. When the MS receives the Modify

Issue 8-0 en
management
PDP Context Accept message, if the offered QoS parameters received

from the network differ from the QoS requested by the MS, the MS either
accepts the negotiated QoS or initiates the PDP context deactivation
procedure.
Note
When the MS requests the QoS modification, and the network does not
accept the MS request and is unable to provide the requested QoS, the
network maintains the QoS as previously negotiated or proposes a new
QoS. Therefore, the network does not reject the MS-initiated PDP
context modification request due to the unavailability of the required
QoS.
When the network receives a Modify PDP Context Request message, it

can reject the MS-initiated PDP context modification request by sending a
Modify PDP Context Reject message to the MS. The message contains a
cause code that typically indicates one of the following:
# 26 Insufficient resources
# 32 Service option not supported
# 41 Semantic error in the TFT operation
# 42 Syntactical error in the TFT operation
# 44 Semantic errors in packet filter(s)
# 45 Syntactical errors in packet filter(s)
# 95 - 111 Protocol errors
Modify PDP Context Request (network to MS direction)
The network sends a Modify PDP Context Request message to the MS to

request the modification of an active PDP context. If the MS has requested
an external PDN address allocation at the PDP context activation through
an APN and this is confirmed by the network in the Activate PDP Context
Accept message, the network includes the PDP address IE in the Modify
PDP Context Request message once the address is actually allocated in
order to update the PDP context in the MS. The PFI IE is included if the
network wants to indicate the packet flow identifier associated with the
PDP context.

Issue 8-0 en
Management
Table 32. Information elements in a Modify PDP Context Request message

(network-originating)

Modify PDP context request message M
identity
Radio priority M
Spare half octet M
New QoS M
PDP address O = optional
Packet Flow identifier O
Modify PDP Context Request (MS to network direction)
The MS sends a Modify PDP Context Request message to the network to

request the modification of an active PDP context. The Requested LLC
SAPI IE is included in the message to request a new LLC SAPI if a new
QoS is requested. The Requested new QoS IE is included in the message
to request a modification of the QoS. The New TFT IE is included in the
message only when multiple PDP contexts with the same PDP address
and APN are active to request the modification of the TFT.
Table 33. Information elements in a Modify PDP context request message

(mobile-originating)

Modify PDP context request message M
identity
Requested LLC SAPI O = optional
Requested new QoS O
New TFT O

Issue 8-0 en
management
Modify PDP Context Accept (MS to network direction)
The MS sends a Modify PDP Context Accept message to the network to

acknowledge the modification of an active PDP context.
Table 34. Information elements in a Modify PDP Context Accept message

(mobile-originating)

Modify PDP context accept message M
identity
Modify PDP Context Accept (network to MS direction)
The network sends a Modify PDP Context Accept message to the MS to

acknowledge the modification of an active PDP context. The Negotiated
QoS IE is included in the message if the network assigns a new QoS. The
Negotiated LLC SAPI IE is included in the message if the network assigns
a new LLC SAPI. The new radio priority IE is included in the message only
if the network modifies the radio priority. The PFI IE is included if the
network wants to indicate the Packet Flow Identifier associated with the
PDP context.
Table 35. Information elements in a Modify PDP Context Accept message

(network-originating)

Modify PDP context accept message M
identity
Negotiated QoS O = optional
Negotiated LLC SAPI O
New radio priority O
Packet Flow Identifier O

Issue 8-0 en
Management
Modify PDP Context Reject
The network sends a Modify PDP Context Reject message to the MS to

reject the requested modification of the TFT. The network does not send a
Modify PDP Context Reject message only if the requested QoS is not
available.
Table 36. Information elements in a Modify PDP Context Reject message

Modify PDP Context Reject M
SM cause M
Abnormal cases in PDP context modification
. Expiry of timers
Modify PDP Context Request message, resets and restarts the
network can continue to use the previously negotiated QoS or it can
initiate the PDP context deactivation procedure on the fifth expiry of
the T3386 timer.
. Collision of MS- and network-initiated PDP context modification
procedure
The MS detects the collision of an MS- and network-initiated PDP
context modification procedure if a Modify PDP Context Request
message is received from the network after the MS sent a Modify
PDP Context Request message itself, and both messages contain
the same TI, and the MS did not receive a Modify PDP Context
Accept message from the network. The network detects a collision if
it received a Modify PDP Context Request message from the MS
with the same TI as in the Modify PDP Context Request message
sent to the MS. In case of such a collision, the network-initiated PDP
context modification takes precedence over the MS-initiated PDP
context modification. The MS internally terminates the MS-initiated
PDP context modification procedure, enters the PDP Active state

Issue 8-0 en
management
and progresses with the network-initiated PDP context modification

procedure by sending a Modify PDP Context Accept message. The
network ignores the Modify PDP Context Request message
received in the PDP-MODIFY-PENDING state. The network
progresses with the network-initiated PDP context modification
procedure as if no Modify PDP Context Request message was
received from the MS.
Error handling in PDP context modification
session management.
3.2.4 PDP context deactivation
The purpose of this procedure is to deactivate an existing PDP context

between the MS and the network. PDP context deactivation can be
initiated either by the MS or by the network. The Tear down indicator IE is
included in the Deactivate PDP Context Request message in order to
indicate whether only the PDP context associated with this specific TI or all
active PDP contexts sharing the same PDP address as the PDP context
associated with this specific TI should be deactivated. If the Tear down
indicator IE is not included in the Deactivate PDP Context Request
message, only the PDP context associated with this specific TI is
deactivated.
MS-initiated PDP context deactivation
In order to deactivate a PDP context, the MS sends a Deactivate PDP

Context Request message to the network. The message contains the
transaction identifier (TI) in use for the PDP context to be deactivated and
a cause code that typically indicates one of the following causes:
#25 LLC or SNDCP failure

#26 Insufficient resources
#36 Regular PDP context deactivation
#37 QoS not accepted
The network replies with a Deactivate PDP Context Accept message.

Then both the MS and the network initiates a local release of the logical
link if it is not used by another PDP context.

Issue 8-0 en
Management
Network-requested PDP context deactivation
In order to deactivate a PDP context, the network sends a Deactivate PDP

Context Request message to the MS and starts the T3395 timer. The
message contains the transaction identifier (TI) in use for the PDP context
to be deactivated and a cause code that typically indicates one of the
following causes:
#25 LLC or SNDCP failure

#36 Regular PDP context deactivation
#38 Network failure
#39 Reactivation requested
When the MS receives this message, it replies with a Deactivate PDP

Context Accept message. When the network receives the Deactivate PDP
Context Accept message, it stops the T3395 timer. Both the MS and the
network initiates a local release of the logical link if it is not used by another
PDP context.
Deactivate PDP Context Request
The Deactivate PDP Context Request message is sent to request the

deactivation of an active PDP context. The Tear down indicator IE is
included in the message in order to indicate whether only the PDP context
associated with this specific TI or all active PDP contexts sharing the same
PDP address as the PDP context associated with this specific TI should be
deactivated.
Table 37. Information elements in a Deactivate PDP Context Request

message

Deactivate PDP context request M
message identity
SM cause M
Tear down indicator O = optional

Issue 8-0 en
management
Deactivate PDP Context Accept
The Deactivate PDP Context Accept message is sent to acknowledge the

deactivation of the PDP context requested in the corresponding Deactivate
PDP Context Request message.
Table 38. Information elements in a Deactivate PDP Context Accept message

Deactivate PDP context accept M
message identity
Abnormal cases in PDP context deactivation
.
Expiry of timers
message Deactivate PDP Context Request, resets and restarts the
network erases the PDP context-related data for that MS on the fifth
expiry of the T3395 timer.
. Collision of MS- and network-initiated PDP context deactivation
requests
If the MS- and the network-initiated PDP context deactivation
requests collide, both the MS and the network replies with the
Deactivate PDP Context Accept message and stops the T3390 and
T3395 timers.
Error handling in PDP context deactivation
session management.

Issue 8-0 en
Management
3.2.5 Receiving an SM STATUS message by an SM entity
When an SM STATUS message is received from the MS as a response to

the Modify PDP Context Request or Deactivate PDP Context Request with
cause #81 (Invalid transaction identifier value), the corresponding PDP
context is deactivated locally (without peer-to-peer signalling between the
MS and the network).

the Modify PDP Context Request with cause #97 (Message type non-
existent or not implemented), the network aborts the ongoing modification
procedure related to the received TI.

the Deactivate PDP Context Request with cause #97 (Message type non-
existent or not implemented), the corresponding PDP context is
deactivated locally (without peer-to-peer signalling between the MS and
the network).
An SM STATUS message with any other cause is discarded.
SM Status
The SM Status message is sent by the network or the MS to pass

information on the status of the indicated context and report certain error
conditions.
Table 39. Information elements in an SM Status message

SM Status message identity M
SM Cause M
3.2.6 General message format and information elements for GPRS

session management
TRANSACTION IDENTIFIER: bits 5 to 8 of the first octet of every

message belonging to the session management protocol contain the
transaction identifier (TI). The transaction identifier and its use are defined
in 3GPP TS 24.007 Mobile radio interface signalling layer 3; General

Issue 8-0 en
management
Aspects. For the session management protocol, the extended TI

mechanism can be used. For the call control protocol, the extended TI
mechanism is supported for the purpose of protocol error handling. Nokia
Siemens Networks SGSN handles the originating side in TI in an Inter-
SGSN Routing Area Update as follows:
.
TI flag = 0 received in the new Nokia Siemens Networks SGSN
indicates to the new Nokia Siemens Networks SGSN that the MS
originated the TI
. TI flag = 1 received in the new Nokia Siemens Networks SGSN
indicates to the new Nokia Siemens Networks SGSN that the NW
originated the TI
The Message type IE and its use are defined in 3GPP TS 24.007 Mobile
radio interface signalling layer 3; General Aspects where Table 11.2 and
Figure 11.2 define the value part of the message type IE used in the
session management protocol.
3.2.7 GPRS Session Management timers
There are two Session Management timers on the network side: T3386
and T3395. The table below summarises their causes of start and normal
stop, and the timer values.
Table 40. GPRS Session Management timers
Timer Number Timer Value Cause of Start Normal Stop

T3386 8s MODIFY PDP CONTEXT MODIFY PDP CONTEXT
REQUEST sent by Nokia ACC received by Nokia
Siemens Networks SGSN. Siemens Networks SGSN.
T3395 8s DEACTIVATE PDP DEACTIVATE PDP
CONTEXT REQUEST sent by CONTEXT ACC received by
Nokia Siemens Networks Nokia Siemens Networks
SGSN. SGSN.

Issue 8-0 en
Management
3.3 Error handling of GPRS mobility and session

management
This Section describes the handling of unknown, unforeseen, and
erroneous protocol data by the receiving entity during MM or SM
procedures. The error handling procedures provide recovery mechanisms
for error situations. The procedures also define a compatibility mechanism
for future extensions of the protocols.
. Message too short
When a message is too short to contain a complete message type

information element, that message is ignored. If the message is an
Attach Request, Routing Area Update Request, or Activate PDP
Context Request, the network returns an Attach Reject, Routing
Area Update Reject, or Activate PDP Context Reject message with
cause value #96: 'Invalid mandatory information'.
. Unknown or unforeseen transaction identifier
Whenever the network receives any session management
messages except for the Activate PDP Context Request, or the SM
STATUS specifying a transaction identifier which does not relate to
an active context or to a context that is in the process of activation or
deactivation or was recently deactivated, the network sends an SM
STATUS message with cause #81: 'Invalid transaction identifier
value' using the received transaction identifier value including the
extension octet, and remains in the PDP inactive state.
. Unknown or unforeseen message type
If the network receives a message not compatible with the protocol
state, the network ignores the message except for the fact that, if an
RR connection exists, it returns a status message (SM STATUS,
GMM STATUS depending on the protocol discriminator) with cause
#98: 'Message type not compatible with protocol state'. If the
message is a GMM message, the GMM STATUS message with
cause #98: 'Message type not compatible with protocol state' is
returned. If the message is an SM message, the SM STATUS
message with cause #98: 'Message type not compatible with
protocol state' is returned. If the network receives a message not
compatible with the protocol state, it is ignored.
. Unknown and unforeseen IEs in the non-imperative message part
The MS and the network ignore all unknown or syntactically incorrect
IEs in a message that are not encoded as 'comprehension required'.
. Messages with semantically incorrect contents

Issue 8-0 en
management
When a message with semantically incorrect contents is received,

the foreseen reactions of the procedural part of 3GPP TS 24.008
Mobile radio interface Layer 3 specification; Core network protocols;
Stage 3 (Release 7) (that is, of sections 3, 4, 5) are performed. If,
however, no such reactions are specified, the MS ignores the
message except for the fact that if an RR connection exists, it returns
a status message (SM STATUS, or GMM STATUS depending on the
PD) with cause value #95: 'Semantically incorrect message'.
When a message with semantically incorrect contents is received,
the foreseen reactions of the procedural part of 3GPP TS 24.008
Mobile radio interface Layer 3 specification; Core network protocols;
Stage 3 (Release 7) (that is, of sections 3, 4, 5) are performed. If,
however, no such reactions are specified, the network ignores the
message. If the message is an Attach Request, Routing Area
Update Request, or Activate PDP Context Request, the network
returns an Attach Reject, Routing Area Update Reject, or Activate
PDP Context Reject message with cause value #95: 'Semantically
incorrect message'.
3.4 Restrictions
The following GMM and SM procedures are not supported:
.
Network-requested PDP Context Activation
. Acknowledged mode data transfer is not supported in GTP. This
affects the use of the QoS parameter.
Configuration and capacity information can be found in Nokia Siemens

Networks SGSN Product Description.

Issue 8-0 en
Management

Issue 8-0 en
Support protocol description in SGSN - MS interface, GPRS mobility
and session management
4 Support protocol description in SGSN -

MS interface, GPRS mobility and session
management
Information on protocols in the 2G access between Nokia Siemens
Networks SGSN and the MS can be found in
.
SGSN - MS Interface Description, Subnetwork Dependent
Convergence Protocol (SNDCP) and
. SGSN - MS Interface Description, Logical Link Control (LLC).
Information on protocols in the 3G access between Nokia Siemens

Networks SGSN and the MS can be found in SGSN - RNC Interface
Description.

Issue 8-0 en

SGSN - MS Interface Description, GPRS Mobility and Session Management

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SGSN - MS Interface Description, GPRS Mobility and Session Management

Hochgeladen von

Copyright:

Verfügbare Formate

SGSN - MS Interface Description,

GPRS Mobility and Session

DN0096954 # Nokia Siemens Networks 1 (73)

2 (73) # Nokia Siemens Networks DN0096954

1 Main changes in SGSN - MS interface, GPRS mobility and session

2 Introduction to SGSN - MS interface, GPRS mobility and session

3 Description of SGSN - MS interface, GPRS mobility and session

4 Support protocol description in SGSN - MS interface, GPRS mobility

DN0096954 # Nokia Siemens Networks 3 (73)

Table 1. Information elements in an Attach Request message 15

4 (73) # Nokia Siemens Networks DN0096954

Table 25. GMM timers 51

DN0096954 # Nokia Siemens Networks 5 (73)

6 (73) # Nokia Siemens Networks DN0096954

1 Main changes in SGSN - MS interface,

. in Table Information elements in an Attach Request message of

Changes between releases SG7.0 and SG6.0

Service Request Procedure (UMTS only)

DN0096954 # Nokia Siemens Networks 7 (73)

Changes between releases SG6.0 and SG5.1

Handling after SM STATUS message has been updated.

Support for 3G access has been added to Nokia SGSN.

In 3G access supported Service Request procedure has been added.

PTMSI handling in UMTS has been added.

8 (73) # Nokia Siemens Networks DN0096954

2 Introduction to SGSN - MS interface,

Mobility management handles the subscribers' requests for attaching to or

Session management handles the establishment, modification, and

When subscribers move to another routing area, mobility management

Radio interface protocols provide transparent mobility management (MM)

DN0096954 # Nokia Siemens Networks 9 (73)

10 (73) # Nokia Siemens Networks DN0096954

3 Description of SGSN - MS interface,

3.1 GPRS mobility management

. connecting a subscriber to the general packet radio service (GPRS)

3.1.1 P-TMSI signature

DN0096954 # Nokia Siemens Networks 11 (73)

3.1.2 P-TMSI handling in GSM

. When the MS receives a GMM message containing a new P-TMSI,

3.1.3 P-TMSI handling in UMTS

If a new P-TMSI is assigned by the network the MS and the network

Upon the receipt of a GMM message containing a new P-TMSI the MS

3.1.4 READY timer behaviour

The READY timer is started in the following cases:

12 (73) # Nokia Siemens Networks DN0096954

Within the GMM signalling procedures, the network includes a Force to

. If the MS wishes to indicate its preference for a READY timer value,

3.1.5 GPRS Attach procedure

The GPRS Attach procedure establishes a GMM context. This procedure

DN0096954 # Nokia Siemens Networks 13 (73)

. a normal GPRS Attach, performed by the MS to attach the IMSI for

Description for GPRS Attach procedure

The MS initiates the GPRS Attach procedure by sending an Attach

If the network accepts the GPRS Attach Request, it sends an Attach

In combination with a valid P-TMSI, the P-TMSI signature is used by the

Depending on the value of the Attach Result information element (IE)

14 (73) # Nokia Siemens Networks DN0096954

. The Attach Result IE value indicates 'combined GPRS Attach': the

When the network receives an Attach Complete message, it stops the

The MS initiates the GPRS Attach or the combined GPRS Attach

Table 1. Information elements in an Attach Request message

Information element Presence Remarks

DN0096954 # Nokia Siemens Networks 15 (73)

Table 1. Information elements in an Attach Request message (cont.)