7.7 Mobility Management messages

09.603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol GPT) across the Gn and Gp InterfaceRelease 1998TS

The Mobility Management messages are the signalling messages, defined in GSM 03.60 and 04.08, that are sent between SGSNs at the GPRS Attach and Inter SGSN Routeing Update procedures. The new SGSN derives the address of the old SGSN from the old routeing area identity. The address translation mechanism is implementation specific. Some possible translation mechanisms are found in Annex A.

Generally, the purpose of the signalling is to transfer data associated with the MS from the old SGSN to the new SGSN.

7.7.1 Identification Request

If the MS, at GPRS Attach, identifies itself with P-TMSI and it has changed SGSN since detach, the new SGSN shall send an Identification Request message to the old SGSN to request the IMSI.

The P-TMSI and RAI is a P-TMSI and an RAI in the old SGSN. The P-TMSI Signature is conditionally provided by the MS to the new SGSN for identification checking purposes as defined in GSM 03.60 and 04.08. If the MS has provided the P-TMSI Signature, the new SGSN shall include this parameter in the Identification Request message.

The optional Private Extension contains vendor or operator specific information.

Table 25: Information elements in an Identification Request

Information element

Presence requirement

Reference

Routeing Area Identity (RAI)

Mandatory

7.9.3

Packet TMSI

Mandatory

7.9.5

P-TMSI Signature

Optional

7.9.10

Private Extension

Optional

7.9.26

7.7.2 Identification Response

The old SGSN shall send an Identification Response to the new SGSN as a response to a previous Identification Request.

Possible Cause values are:

– ‘Request Accepted’

– ‘IMSI not known’

– ‘System failure’

– ‘Mandatory IE incorrect’

– ‘Mandatory IE missing’

– ‘Optional IE incorrect’

– ‘Invalid message format’

– ‘Version not supported’

– ‘P-TMSI Signature mismatch’.

Only the Cause information element shall be included in the response if the Cause contains another value than ‘Request Accepted’.

The IMSI information element is mandatory if the Cause contains the value ‘Request Accepted’.

One or several Authentication Triplet information elements may be included in the message if the Cause contains the value ‘Request accepted’.

The optional Private Extension contains vendor or operator specific information.

Table 26: Information elements in an Identification Response

Information element

Presence requirement

Reference

Cause

Mandatory

7.9.1

IMSI

Conditional

7.9.2

Authentication Triplet

Optional

7.9.8

Private Extension

Optional

7.9.26

7.7.3 SGSN Context Request

The new SGSN shall send an SGSN Context Request to the old SGSN to get the MM and PDP Contexts for the MS. The MS is identified by its old RAI and old TLLI values. The TLLI and RAI is a foreign TLLI and an RAI in the old SGSN.

The old SGSN responds with an SGSN Context Response.

The Flow Label Signalling field specifies a flow label for signalling messages which is chosen by the new SGSN. The old SGSN shall include this flow label in the GTP header of all subsequent signalling messages which are sent from the old SGSN to the new SGSN and related to the PDP context(s) requested.

The MS Validated indicates that the new SGSN has successfully authenticated the MS. . IMSI shall be included if MS Validated indicates ‘Yes’.

The P-TMSI Signature is conditionally provided by the MS to the new SGSN for identification checking purposes as defined in GSM 03.60 and 04.08. If the MS has provided the P-TMSI Signature, the new SGSN shall include this parameter in the SGSN Context Request message.

The optional Private Extension contains vendor or operator specific information.

Table 27: Information elements in a SGSN Context Request

Information element

Presence requirement

Reference

IMSI

Conditional

7.9.2

Routeing Area Identity (RAI)

Mandatory

7.9.3

Temporary Logical Link Identifier (TLLI)

Mandatory

7.9.4

P-TMSI Signature

Optional

7.9.10

MS Validated

Optional

7.9.11

Flow Label Signalling

Mandatory

7.9.15

Private Extension

Optional

7.9.26

7.7.4 SGSN Context Response

The old SGSN shall send an SGSN Context Response to the new SGSN as a response to a previous SGSN Context Request.

Possible Cause values are:

– ‘Request Accepted’

– ‘IMSI not known’

– ‘System failure’

– ‘Mandatory IE incorrect’

– ‘Mandatory IE missing’

– ‘Optional IE incorrect’

– ‘Invalid message format’

– ‘Version not supported’

– ‘P-TMSI Signature mismatch’.

Only the Cause information element shall be included in the response if the Cause contains another value than ‘Request accepted’.

All information elements are mandatory, except PDP Context, and Private Extension, if the Cause contains the value ‘Request accepted’.

The Flow Label Signalling field specifies a flow label which is chosen by the old SGSN. The new SGSN shall include this flow label in the GTP header of all subsequent signalling messages which are sent from the new SGSN to the old SGSN and related to the PDP context(s) requested.

The IMSI information element contains the IMSI matching the TLLI and RAI in the SGSN Context Request.

The MM Context contains necessary mobility management and security parameters.

All active PDP contexts in the old SGSN shall be included as PDP Context information elements.

If there is at least one active PDP context, the old SGSN shall start the T3-TUNNEL timer and store the address of the new SGSN in the "New SGSN Address" field of the MM context. The old SGSN shall wait for SGSN Context Acknowledge before sending T-PDUs to the new SGSN. If the old SGSN has one or more active PDP contexts for the subscriber and SGSN Context Acknowledge message is not received within a time defined by T3-RESPONSE, the old SGSN shall retransmit the SGSN Context Response to the new SGSN for as long as the total number of attempts is less than N3-REQUESTS. After N3-REQUESTS unsuccessfully attempts, the old SGSN shall proceed as described in section ‘Reliable delivery of signalling messages’ in case the transmission of a signalling message fails N3-REQUESTS times.

The optional Private Extension contains vendor or operator specific information.

Table 28: Information elements in a SGSN Context Response

Information element

Presence requirement

Reference

Cause

Mandatory

7.9.1

IMSI

Conditional

7.9.2

Flow Label Signalling

Conditional

7.9.15

MM Context

Conditional

7.9.19

PDP Context

Conditional

7.9.20

Private Extension

Optional

7.9.26

7.7.5 SGSN Context Acknowledge

The new SGSN shall send an SGSN Context Acknowledge message to the old SGSN as a response to the SGSN Context Response message. Only after receiving the SGSN Context Acknowledge message, shall the old SGSN start to forward user data packets. SGSN Context Acknowledge indicates to the old SGSN that the new SGSN is ready to receive user data packets identified by the corresponding TID values.

Possible cause values are:

– ‘Request accepted’

– ‘System failure’

– ‘Mandatory IE incorrect’

– ‘Mandatory IE missing’

– ‘Optional IE incorrect’

– ‘No resources available’

– ‘Invalid message format’

– ‘Version not supported’

– ‘Authentication failure’.

Only the Cause information element shall be included in the acknowledge if the Cause contains a value other than ‘Request accepted’.

For each active PDP context the new SGSN shall include a Flow Label Data II information element. The Flow Label Data II field specifies a flow label which is chosen by the new SGSN for a particular PDP context. The old SGSN shall include this flow label in the GTP header of all subsequent G-PDUs which are sent from the old SGSN to the new SGSN and related to the particular PDP context.

If any of the PDP contexts has a QoS reliability class which indicates that a reliable connection-oriented path should be used to forward T-PDUs coming via the old route and no connection has already been established, the old SGSN shall set-up a connection to the new SGSN after receiving SGSN Context Acknowledge message.

T-PDUs associated with PDP contexts that require a reliable link shall be sent over the reliable connection-oriented path and the other T-PDUs shall be sent over the connection-less path. T-PDUs shall be sent over a connectionless path if connection-oriented resources are exhausted.

The new SGSN shall include an SGSN Address for user traffic, which may differ from that provided by the underlying network service (e.g. IP). The old SGSN shall store this SGSN Address and use it when sending G-PDUs to the new SGSN for the MS.

The optional Private Extension contains vendor or operator specific information.

Table 29: Information elements in a SGSN Context Acknowledge

Information element

Presence requirement

Reference

Cause

Mandatory

7.9.1

Flow Label Data II

Conditional

7.9.16

SGSN Address for user traffic

Conditional

GSN Address 7.9.23

Private Extension

Optional

7.9.26