7.5 Mobility Management Messages

29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.5.0 General

The Mobility Management messages are the control plane messages, defined in 3GPP TS 23.060 [4] and 3GPP TS 24.008 [5], 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 C in 3GPP TS 23.003 [2].

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

The requirements specified in this clause for SGSN also apply to MME if the MME supports GTP-C (v1) for roaming and inter access mobility between Gn/Gp SGSNs and MMEs as specified in Annex D of 3GPP TS 23.401 [47].

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

For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, where the old SGSN belongs to an SGSN pool, the new SGSN cannot in the general case determine the old SGSN. The new SGSN shall in this case send the Identification Request message to an SGSN based on the old RAI, as usual. If an SGSN within an SGSN pool receives an Identification Request message for an MS that has been attached to another SGSN of the same SGSN pool, the SGSN shall:

a) include the source IP address of the received Identification Request message in the optional parameter "SGSN Address for Control Plane" if the optional parameter "SGSN Address for Control Plane" is not present in the received Identification Request message; and

b) decrement the Hop Counter value if the optional parameter "Hop Counter" is present in the received Identification Request message; otherwise may include a Hop Counter with a value of max-1 where max is the maximum defined value for Hop Counter.

The Identification Request message is then relayed to the old SGSN, keeping the other parts of the message unchanged. Received Identification Request messages with a Hop Counter value of 0 shall not be relayed; instead a system failure indication shall be returned to the new SGSN The SGSN within an SGSN pool can determine if the received Identification Request message was meant for itself or for another SGSN of the SGSN pool by looking at the Network Resource Identifier contained in the P-TMSI parameter. See 3GPP TS 23.003 [2] for details on the coding of the P-TMSI and see 3GPP TS 23.236 [19] for details on SGSN pool.

Note that an SGSN relaying the Identification Request message shall not supervise the Identification Response message.

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 3GPP TS 23.060 [4] and 3GPP TS 24.008 [5]. 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 24: Information Elements in an Identification Request

Information element	Presence requirement	Reference
Routeing Area Identity (RAI)	Mandatory	7.7.3
Packet TMSI	Mandatory	7.7.5
P-TMSI Signature	Conditional	7.7.9
SGSN Address for Control Plane	Optional	7.7.32
Hop Counter	Optional	7.7.63
Private Extension	Optional	7.7.46

7.5.2 Identification Response

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

For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, if an old SGSN within an SGSN pool receives an Identification Request message that contains the optional parameter SGSN Address for Control Plane, the old SGSN shall use this address as destination IP address of the Identification Response message.

Possible Cause values are:

– "Request Accepted".

– "IMSI/IMEI not known".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "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".

The old SGSN shall include the UE Usage Type if the old SGSN supports the Dedicated Core Network feature as specified in 3GPP TS 23.060 [4]. If the UE Usage Type is not available in the old SGSN, the length field of this IE shall be set to 0.

NOTE 1: A UE Usage Type IE with the length field equal to 0 is used for the receiver to differentiate the case where the sender does not support the Dedicated Core Network feature from the case where the sender supports the Dedicated Core Network feature but no UE Usage type was received in UE’s subscription.

The old SGSN shall include the IOV_updates counter if it is supported and available for a UMTS subscriber capable of UMTS AKA.

The optional Private Extension contains vendor or operator specific information.

Table 25: Information Elements in an Identification Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
IMSI	Conditional	7.7.2
Authentication Triplet	Conditional	7.7.7
Authentication Quintuplet	Conditional	7.7.35
UE Usage Type	Optional	7.7.117
IOV_updates counter	Optional	7.7.122

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

For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, where the old SGSN belongs to an SGSN pool, the new SGSN cannot in the general case determine the old SGSN. The new SGSN shall in this case send the SGSN Context Request message to an SGSN based on the old RAI, as usual. If an SGSN within an SGSN pool receives an SGSN Context Request message for an MS that has been attached to another SGSN of the same SGSN pool, the SGSN shall:

if the optional parameter "Hop Counter" is present in the received SGSN Context Request message, decrement the Hop Counter value, otherwise may include a Hop Counter with a value of max-1 where max is the maximum defined value for Hop Counter;
the SGSN Context Request message is then relayed to the old SGSN, keeping the other parts of the message unchanged. Received SGSN Context Request messages with a Hop Counter value of 0 shall not be relayed; instead a system failure indication shall be returned to the new SGSN. The SGSN within an SGSN pool can determine if the received SGSN Context Request message was meant for itself or for another SGSN of the SGSN pool by looking at the Network Resource Identifier contained in the P-TMSI parameter, or alternatively in the TLLI parameter. See 3GPP TS 23.003 [2] for details on the coding of the P-TMSI and see 3GPP TS 23.236 [19] for details on SGSN pool.

Note that an SGSN relaying the SGSN Context Request message shall not supervise the SGSN Context Response message.

The MS is identified in the old SGSN by its old RAI and old TLLI/old P-TMSI values. The TLLI/P-TMSI and RAI is a foreign TLLI/P-TMSI and an RAI in the old SGSN. Exactly one of the TLLI, P-TMSI or IMSI information fields shall be present.

The old SGSN responds with an SGSN Context Response.

The new SGSN shall include a SGSN Address for control plane. If the new SGSN is IPv4/ IPv6 capable, it shall include IPv4 address in the field of SGSN Address for Control Plane and IPv6 address in the field of Alternative SGSN Address for Control Plane. If the old SGSN is IPv6 capable, it shall store and use the IPv6 SGSN address when sending control plane messages for the MS to the new SGSN in the SGSN context transfer procedure. Otherwise if the old SGSN is only IPv4 capable, it shall store and use the IPv4 SGSN address in the SGSN context transfer procedure. The old SGSN shall store this SGSN Address and use it when sending control plane messages for the MS to the new SGSN in the SGSN context transfer procedure

The new SGSN may include its SGSN number. If the old SGSN receives the SGSN number of the new SGSN it shall include this number when informing interworking core network nodes that there is a need to re-route previously sent requests against the new SGSN, e.g. in LCS the GMLC will use this SGSN number to re-activate the Location Request to the new SGSN (3GPP TS 23.271 [24])..

The Tunnel Endpoint Identifier Control Plane field specifies a Tunnel Endpoint Identifier for control plane messages, which is chosen by the new SGSN. The old SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent control plane messages that 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 3GPP TS 23.060 [4] and 3GPP TS 24.008 [5]. If the MS has provided the P-TMSI Signature, the new SGSN shall include this parameter in the SGSN Context Request message.

The RAT Type indicates the Radio Access Technology which is used in the new SGSN or the new MME.

The new SGSN shall include the CIoT Optimizations Support Indication IE if it supports at least one CIoT optimization.

The optional Private Extension contains vendor or operator specific information.

Table 26: Information Elements in a SGSN Context Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
Routeing Area Identity (RAI)	Mandatory	7.7.3
Temporary Logical Link Identifier (TLLI)	Conditional	7.7.4
Packet TMSI (P-TMSI)	Conditional	7.7.5
P-TMSI Signature	Conditional	7.7.9
MS Validated	Optional	7.7.10
Tunnel Endpoint Identifier Control Plane	Mandatory	7.7.14
SGSN Address for Control Plane	Mandatory	7.7.32
Alternative SGSN Address for Control Plane	Optional	7.7.32
SGSN Number	Optional	7.7.47
RAT Type	Optional	7.7.50
Hop Counter	Optional	7.7.63
Private Extension	Optional	7.7.46

7.5.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/IMEI not known".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "P-TMSI Signature mismatch".

– "Target access restricted for the subscriber".

Based on the subscription profile, when the access to the target RAT is prohibited for the subscriber, the old SGSN may reject the SGSN Context Request message with the cause "Target access restricted for the subscriber".

If the Cause contains the value "P-TMSI Signature mismatch" the IMSI information element and, for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, a SGSN Address for control plane shall be included in the response, otherwise only the Cause information element shall be included in the response. The IMSI shall not be included in the message if the MS is emergency attached and the MS is UICCless.

NOTE 1: The rule to include the IMSI when the Cause contains the value "P-TMSI Signature mismatch" also applies to an old MME interoperating with a Gn/Gp SGSN.

The old SGSN shall also include a SGSN Address for control plane if the Cause contains the value "Request Accepted". If the SGSN Context Request received from the new SGSN includes an IPv6 SGSN address, an IPv4/IPv6 capable old SGSN shall include IPv6 address in the field of SGSN address for control plane. Otherwise it shall include IPv4 address in this field. The new SGSN shall store this SGSN Address and use it when sending control plane messages for the MS to the old SGSN in the SGSN context transfer procedure.

The Tunnel Endpoint Identifier Control Plane field specifies a Tunnel Endpoint Identifier, which is chosen by the old SGSN. The new SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent control plane 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 or P-TMSI (for GSM or UMTS respectively) and RAI in the SGSN Context Request.

The MM Context contains necessary mobility management and security parameters. The IMEISV shall, if available, be included in the MM Context from the old SGSN to the new SGSN. If the MS is emergency attached and the MS is UICCless or the IMSI is unauthenticated, the International Mobile Equipment Identity (IMEI) shall be included and used as the MS identity.

All active PDP contexts in the old SGSN shall be included as PDP Context information elements. The PDP contexts are included in an implementation dependant prioritized order, and the most important PDP context is placed first. When the PDP Context Prioritization IE is included, it informs the new SGSN that the PDP contexts are sent prioritized. If the new SGSN is not able to maintain active all the PDP contexts received from the old SGSN when it is indicated that prioritization of the PDP contexts is applied, the new SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts to maintain active and which ones to delete.

The old SGSN shall include the current Evolved Allocation/Retention Priority for each active PDP Context in the Evolved Allocation/Retention Priority II information elements if the information is available.

If available, the old SGSN shall include:

– Subscribed and Authorized UE-AMBRs for Uplink and Downlink into the UE-AMBR IE for all non-GBR PDP Contexts according to the subscription of the user. If Authorized UE-AMBRs are available but no Subscribed UE-AMBR is received from the HLR, the value of the Subscribed UE-AMBR shall be set to "0" by the old SGSN and the new SGSN shall consider that there is no Subscribed UE-AMBR received from the old SGSN.

– Authorized APN-AMBRs for Uplink and Downlink into the APN-AMBR with NSAPI IE(s) for all non-GBR PDP Contexts of the APN. One occurrence of this IE shall be included per PDN connection. The NSAPI shall be the value assigned to any PDP Context that is associated with the PDN connection.

NOTE 2: The old SGSN can receive the authorized APN-AMBRs from GGSN at PDP context activation or PDP context update.

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 an 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 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 clause "Reliable delivery of signalling messages" in case the transmission of a control plane message fails N3‑REQUESTS times.

For each RAB using lossless PDCP context, the old SGSN shall include a RAB Context. If a RAB Context is included in the SGSN Context Response, the new SGSN shall ignore the N-PDU number fields and sequence number fields received in the PDP Context IE.

Radio Priority SMS contains the radio priority level for MO SMS transmission, and shall be included if a valid Radio Priority SMS value exists for the MS in the old SGSN.

Radio Priority LCS contains the radio priority level for MO LCS transmission, and shall be included if a valid Radio Priority LCS value exists for the MS in the old SGSN.

Radio Priority is the radio priority level that the MS uses when accessing the network for the transmission of uplink user data for a particular PDP context. One Radio Priority IE shall be included per PDP context that has a valid radio priority value assigned to it in the old SGSN.

Packet Flow Id is the packet flow identifier assigned to the PDP context. One Packet Flow Id IE shall be included per PDP context that has a valid packet flow identifier value assigned to it in the old SGSN.

Charging Characteristics IE contains the charging characteristics which apply for a PDP context; see 3GPP TS 32.251 [18] and 3GPP TS 32.298 [34]. If the charging characteristics are available for all the active PDP contexts, one Charging Characteristics IE shall be included per PDP context IE; otherwise no Charging Characteristics IE shall be included. If no PDP context is active, this IE shall not be included. The mapping of a Charging Characteristics IE to a PDP Context IE is done according to the sequence of their appearance, e.g. the first Charging Characteristics IE is mapped to the first PDP Context IE.

NOTE 3: The Charging Characteristics applicable for a PDP context may not be available in the source node, e.g. during mobility from E-UTRAN to GERAN/UTRAN if they are not received from the HSS.

All MBMS UE Contexts in the old SGSN shall be included as MBMS UE Context information elements if the new SGSN supports MBMS (i.e. MBMS support indication has been sent from the new SGSN).

Both RFSP Index values shall be forwarded to the new SGSN if at least one RFSP Index is available during inter-SGSN mobility procedures. In this case, when one of the RFSP Indexes is not available, e.g. the Subscribed RFSP Index is not received from the HLR/HSS while the RFSP Index in use is included in the message, the value of the RFSP Index that is not available shall be set to 0.

The Co-located GGSN-PGW FQDN may be included which applies for a PDP context. One Co-located GGSN-PGW FQDN shall be included per PDP context IE. The mapping of a Co-located GGSN-PGW FQDN IE to a PDP Context IE is done according to the sequence of their appearance, e.g. the first Co-located GGSN-PGW FQDN IE is mapped to the first PDP Context IE. If the activated PDP Contexts of the PDP address and APN do not have the Co-located GGSN-PGW FQDN Information, the length field of the Co-located GGSN-PGW FQDN IE shall be set to 0. If all the activated PDP Contexts of the UE do not have the Co-located GGSN-PGW FQDN Information, the FQDN IE shall not be present in this message.

The presence of the Extended Common Flags IE is optional.

– The Unauthenticated IMSI bit field shall be set to 1 if the IMSI present in the message is not authenticated and is for an emergency attached MS.

– The Buffered DL Data Waiting Indication bit field shall be set to 1 when it is required to forward to the UE DL data buffered in the old SGW or in the old Gn/Gp SGSN, i.e. when the DL Data Buffer Expiration Time has not expired yet in the old MME or SGSN, as specified in the clause 5.3.13.7 of 3GPP TS 23.060 [4].

UE network capability provides the network with information concerning aspects of the UE related to EPS or interworking with GPRS.

The old SGSN shall include the Signalling Priority Indication with NSAPI IE if the UE indicated low access priority when establishing the PDP Context. Only one occurrence of this IE may be included per PDN connection. Any of the NSAPI values may be used that are associated with the given PDN connection.

The SGSN shall include the Higher bitrates than 16 Mbps flag if it is received from the RNC or stored (received from an SGSN via the SGSN Context Response or Forward Relocation Request during earlier procedures) and if the SGSN support it.

The old SGSN shall include the Selection Mode with NSAPI IE. The Selection Mode indicates the origin of the APN used while activating the PDN connection, which is identified by the NSAPI. Only one occurrence of this IE may be included per PDN connection. Any of the NSAPI values may be used that are associated with the given PDN connection.

The old SGSN shall include the Local Home Network ID with NSAPI IE per PDN connection if SIPTO at the Local Network is supported and is active for the PDN connection in the SIPTO at Local Network architecture with stand-alone GW. Only one occurrence of this IE may be included per PDN connection. Any of the NSAPI values may be used that are associated with the given PDN connection.

NOTE 4: A UE Usage Type IE with the length field equal to 0 is used for the receiver to differentiate the case where the sender does not support the Dedicated Core Network feature from the case where the sender supports the Dedicated Core Network feature but no UE Usage type was received in UE’s subscription. The optional Private Extension contains vendor or operator specific information.

The presence of the Extended Common Flags II IE is optional.

– The Pending Network Initiated PDN Connection Signalling Indication) bit field shall be set to 1 when there is pending network initiated PDN connection signalling for this PDN connection.

– The Delay Tolerant Connection Indication shall be set to 1 if the GGSN indicated that the PDN connection is delay tolerant.

– The Pending MT Short Message Indication shall be set to 1 if the source SGSN/MME knows that there is one (or more) pending MT Short Message(s) in the SMS-GMSC for the UE as specified in clause 10.1 of 3GPP TS 23.040 [28], Figure 17c).

The old SGSN shall include the UE SCEF PDN Connection(s), if there is at least one SCEF PDN connection for this UE at the old SGSN and if the target SGSN has set the SCNIPDN bit of the CIoT Optimizations Support Indication IE to 1 in the SGSN Context Request, as specified in clause 7.7.120. Several IEs with this type value shall be included as necessary to represent a list of SCEF PDN Connections.

If the MS has a PDP context of "Non-IP" PDP type at the old SGSN, then in the following cases the old SGSN shall release the PDP context with PDP Type "Non-IP" and shall continue with the SGSN Context Request procedure:

– For a PDP context established through a GGSN, if the target SGSN does not include the CIoT Optimizations Support Indication, or if it includes it but with the SGNIPDN (Gi Non IP PDN Support Indication) bit not set;

– For a PDP context established through a SCEF, if the target SGSN does not include the CIoT Optimizations Support Indication, or if it includes it but with the SCNIPDN (SCEF Non IP PDN Support Indication) bit not set.

The old SGSN shall include the IOV_updates counter if it is supported and available for a UMTS subscriber capable of UMTS AKA.

If the Cause contains the value "Request Accepted" and the old SGSN has IPv4 and IPv6 control plane addresses of the GGSN available, the old IPv4/IPv6 capable SGSN shall include one of the GGSN control plane addresses in the PDP Context IE as specified in clause 7.7.29 and the other GGSN control plane address in the Alternative GGSN Address for control plane.

If the Cause contains the value "Request Accepted" and the old SGSN has IPv4 and IPv6 user traffic addresses of the GGSN available, the old IPv4/IPv6 capable SGSN shall include one of the GGSN user traffic addresses in the PDP Context IE as specified in clause 7.7.29 and the other GGSN user traffic address in the Alternative GGSN Address for user traffic.

One Alternative GGSN Address for control Plane IE and one Alternative GGSN Address for user traffic IE shall be included per PDP context IE, as follows:

– The Alternative GGSN Address for control Plane IE and the Alternative GGSN Address for user traffic IE shall be encoded in pairs, one after the other, per PDP context. The mapping of the Alternative GGSN Address for control Plane IE and the Alternative GGSN Address for user traffic IE to a PDP Context IE shall be done according to the sequence of their appearance in the message.

– The Alternative GGSN Address for control Plane IE for a secondary PDP context shall be the same as for the primary PDP context.

– If multiple PDP contexts exist with a mix of PDP contexts with both IPv4/IPv6 addresses and PDP contexts with only an IPv4 or IPv6 address, the PDP contexts with both IPv4/IPv6 addresses shall be encoded first in the message, followed by PDP contexts without alternative GGSN addresses.

– The Alternative GGSN Address for control Plane IEs and Alternative GGSN Address for user traffic IEs shall be encoded after the SGSN Address for Control Plane IE.

– If an alternative IP address is available either for the control plane or for the user plane (but not both), a pair of Alternative GGSN Address for control plane IE and Alternative GGSN Address for user traffic IE shall be encoded, where one of these IEs includes the alternative address and the other IE is set to a null IPv4 or IPv6 address (i.e. 4 or 16 octets set all to zero).

EXAMPLE 1: Assuming 2 PDP contexts (primary and/or secondary PDP contexts) having both IPv4 and IPv6 GGSN addresses for control plane and user traffic, the message encodes the IEs in the following order:
– Alternative GGSN Address for control Plane IE (first PDP context);
– Alternative GGSN Address for user traffic IE (first PDP context);
– Alternative GGSN Address for control Plane IE (second PDP context);
– Alternative GGSN Address for user traffic IE (second PDP context).

EXAMPLE 2: Assuming 1 PDP context having an IPv4 GGSN address for control plane and IPv4 and IPv6 GGSN addresses for user traffic, the message encodes the IEs as follows:
– Alternative GGSN Address for control Plane IE (null IP address);
– Alternative GGSN Address for user traffic IE (alternative IPv4 or IPv6 address to the one encoded in PDP Context IE).

EXAMPLE 3: Assuming 1 PDP context having IPv4 and IPv6 GGSN addresses for control plane and an IPv4 GGSN address for user traffic, the message encodes the IEs as follows:
– Alternative GGSN Address for control Plane IE (alternative IPv4 or IPv6 address to the one encoded in PDP Context IE);
– Alternative GGSN Address for user traffic IE (null IP address).

Table 27: Information Elements in a SGSN Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
IMSI	Conditional	7.7.2
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
RAB Context	Conditional	7.7.19
Radio Priority SMS	Optional	7.7.20
Radio Priority	Optional	7.7.21
Packet Flow Id	Optional	7.7.22
Charging Characteristics	Optional	7.7.23
Radio Priority LCS	Optional	7.7.25B
MM Context	Conditional	7.7.28
PDP Context	Conditional	7.7.29
SGSN Address for Control Plane	Conditional	7.7.32
Alternative GGSN Address for control Plane	Optional	7.7.32
Alternative GGSN Address for user traffic	Optional	7.7.32
PDP Context Prioritization	Optional	7.7.45
MBMS UE Context	Optional	7.7.55
Subscribed RFSP Index	Optional	7.7.88
RFSP Index in use	Optional	7.7.88
Co-located GGSN-PGW FQDN	Optional	7.7.90
Evolved Allocation/Retention Priority II	Optional	7.7.92
Extended Common Flags	Optional	7.7.93
UE Network Capability	Optional	7.7.99
UE-AMBR	Optional	7.7.100
APN-AMBR with NSAPI	Optional	7.7.101
Signalling Priority Indication with NSAPI	Optional	7.7.104
Higher bitrates than 16 Mbps flag	Optional	7.7.105
Selection Mode with NSAPI	Optional	7.7.113
Local Home Network ID with NSAPI	Optional	7.7.115
UE Usage Type	Optional	7.7.117
Extended Common Flags II	Optional	7.7.118
UE SCEF PDN Connection	Optional	7.7.121
IOV_updates counter	Optional	7.7.122
Private Extension	Optional	7.7.46

7.5.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 has correctly received PDP Context information and is ready to receive user data packets identified by the corresponding Tunnel Endpoint Identifier values. This message shall not be sent if the SGSN Context Request was rejected.

Possible cause values are:

– "Request accepted".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "No resources available".

– "Invalid message format".

– "Authentication failure".

– "Relocation failure due to NAS message redirection".

Only the Cause information element shall be included in the acknowledgement if the Cause contains a value other than "Request accepted".

Upon receiving cause value other than the request was accepted, the old SGSN shall continue as if the SGSN Context Request was never received.

For each active PDP context (i.e. those which have a tunnel established between the old SGSN and the GGSN) the new SGSN shall include a Tunnel Endpoint Identifier Data II information element. The Tunnel Endpoint Identifier Data II field specifies a Tunnel Endpoint Identifier which is chosen by the new SGSN for a particular PDP context. The old SGSN shall include this Tunnel Endpoint Identifier 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. When active PDP context(s) exist, this information element shall be included if the Cause contains the value "Request accepted".

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

If High latency communication (see clause 5.3.13.7 of 3GPP TS 23.060 [4]) is not supported, during a Gn/Gp SGSN to S4-SGSN RAU procedure (see clause 6.9.2.1 of 3GPP TS 23.060 [4]) when a Direct Tunnel is established by the S4-SGSN, or during a Gn/Gp SGSN to MME TAU procedure (see annex D.3.6 in 3GPP TS 23.401 [47]), the S4-SGSN or MME, acting as a new SGSN, shall send the following values in the SGSN Context Acknowledge message in order to discard the packets received from the old SGSN (because the MME and the S4-SGSN do not have user plane):

– any reserved TEID (e.g. all 0’s, or all 1’s) for Tunnel Endpoint Identifier Data II value;

– any reserved (implementation dependent) IP address for SGSN Address for user traffic value.

NOTE: An implementation may provide the mentioned reserved IP address e.g. from one of the reserved IP address ranges (see RFC5735 [54] or http://www.iana.net/assignments/ipv4-address-space/ipv4-address-space.xml), or the IP address may be provisioned by a configuration.

The S4-SGSN, acting as a new SGSN, may send an S4-U F-TEID or the above reserved values in the SGSN Context Acknowledge message during a Gn/Gp SGSN to S4-SGSN RAU procedure (see clause 6.9.2.1 of 3GPP TS 23.060 [4]) when no Direct Tunnel is used.

If High latency communication (see clause 5.3.13.7 of 3GPP TS 23.060 [4]) is supported, and if the old Gn/Gp SGSN has indicated in the SGSN Context Response message that forwarding of DL data buffered in the old Gn/Gp SGSN to the UE is required, the new S4-SGSN or the new MME shall set the SGSN Address for user traffic and Tunnel Endpoint Identifier Data II to either:

– the F-TEID allocated by a forwarding SGW for indirect data forwarding;

– the target S4-U SGSN F-TEID, or

– the target eNB F-TEID, or target S12 RNC F-TEID (when Direct Tunnel is established by the new S4-SGSN), if the eNB or RNC supports such forwarding.

If the SGSN Context Response received from the old SGSN includes an IPv6 SGSN address, an IPv4/IPv6 capable new SGSN shall include an IPv6 address in the field of SGSN Address for user traffic, Otherwise it shall include IPv4 address in this field. The old SGSN shall store this SGSN Address and use it when sending G-PDUs to the new SGSN for the MS. When active PDP context(s) exist, this information element shall be included if the Cause contains the value "Request accepted".

If the PMTSMI flag in the SGSN Context Response message is set to 1, the target SGSN/MME shall include its E.164 number in the SGSN Number IE and, if available, its Diameter Identity in the Node Identifier IE, for retransmission of pending MT-SMS to the UE.

The optional Private Extension contains vendor or operator specific information.

Table 28: Information Elements in a SGSN Context Acknowledge

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Tunnel Endpoint Identifier Data II	Conditional	7.7.15
SGSN Address for user traffic	Conditional	GSN Address 7.7.32
SGSN Number	Optional	7.7.47
Node Identifier	Optional	7.7.119
Private Extension	Optional	7.7.46

7.5.6 Forward Relocation Request

The old SGSN shall send a Forward Relocation Request to the new SGSN to convey necessary information to perform the SRNS Relocation procedure between new SGSN and Target RNC or to perform the PS handover procedure between new SGSN and Target BSS.

The IMSI information element contains the IMSI of the target MS for SRNS Relocation or PS handover procedure. The IMSI shall not be included in the message if the MS is emergency attached and the MS is UICCless.

The old SGSN shall include a SGSN Address for control plane. The new SGSN shall store this SGSN Address and use it when sending control plane messages for the MS to the old SGSN in the SRNS Relocation procedure. If the new SGSN is IPv6 capable, an IPv4/IPv6 capable old SGSN shall include an IPv6 address in the field SGSN Address for Control Plane, otherwise it shall include an IPv4 address in this field.

The Tunnel Endpoint Identifier Control Plane field specifies a tunnel endpoint identifier, which is chosen by the old SGSN. The new SGSN shall include this Tunnel Endpoint Identifier Control Plane in the GTP header of all subsequent control plane messages, which are sent from the new SGSN to the old SGSN.

The old SGSN shall include the current Evolved Allocation/Retention Priority for each active PDP Context in the Allocation/Retention Priority II information elements if the information is available.

If available, the old SGSN shall include:

NOTE 1: The old SGSN can receive the authorized APN-AMBRs from GGSN at PDP context activation or PDP context update.

The old SGSN or MME shall include in the Forward Relocation Request message:

– the Packet Flow ID IE, BSS Container IE and Cell Identification IE when this message is used for PS handover from A/Gb mode to A/Gb mode, from Iu mode to A/Gb mode or from S1 mode to A/Gb mode.

– the PS Handover XID Parameters IE when this message is used for PS Handover to or from A/Gb mode. The old SGSN or MME may not be able to provide the XID parameters in the PS Handover XID Parameters IE for PS handover from Iu or S1 mode to A/Gb mode, see clause 7.7.79.

The old SGSN should include in the Forward Relocation Request message the "Reliable INTER RAT HANDOVER INFO" if received in a PS Handover Required message from the BSS.

The new SGSN receiving the PS Handover XID Parameters IE shall proceed with the PS Handover procedure. The PS Handover XID Parameters IE shall be included for each SAPI included in the Forward Relocation Request. The Packet Flow ID IE shall be included for each PDP Context included in the Forward Relocation Request.

BSS Container IE and Cell Identification IE are the IEs sent from the source BSS/RNC/eNB to the old SGSN/MME. These IEs will be included in the Forward Relocation Request message to the new SGSN only if the PS Handover XID Parameter IE and the Packet Flow ID IEare present. BSS Container IE contains the radio-related network information for the PS handover procedure. Cell Identification IE contains the identification of a source cell (for PS handover from A/Gb mode to A/Gb mode) or an RNC-ID (for PS handover from Iu mode to A/Gb mode) and the identification of the target cell.

All MBMS UE Contexts in the old SGSN shall be included as MBMS UE Context information elements.

UTRAN transparent container, Target identification and RANAP Cause are information from the source RNC/BSS in the old SGSN. The old SGSN shall include in the Forward Relocation Request message the RANAP Cause IE, UTRAN transparent container IE and Target Identification IE when this message is used for the SRNS relocation procedure. For PS handover from A/Gb mode to A/Gb mode, or PS handover from S1 mode to A/Gb mode, the old SGSN or old MME shall set the value part of UTRAN transparent container IE and Target Identification IE to empty, according to their defined minimum length and set the RANAP Cause to cause #43 "Relocation desirable for radio reasons" as defined in 3GPP TS25.413 [7]. For PS handover from A/Gb mode to Iu mode, the old SGSN shall set the RANAP Cause to cause #43 "Relocation desirable for radio reasons" as defined in 3GPP TS25.413 [7]. For PS handover from Iu mode to A/Gb mode, the old SGSN shall set the value part of UTRAN transparent container IE and Target Identification IE to empty, according to their defined minimum length and set the RANAP Cause to the value received from the source RNC/BSS.

During the inter RAT handover from UTRAN/GERAN to E-UTRAN, if the old SGSN receives the target eNodeB ID from the source RNC/BSS, it may include this information in the eNodeB IE in the Forward Relocation Request message to the target MME. The old SGSN shall also include the Target Identification IE, which is mapped from the target eNodeB ID received.

NOTE 2: There are multiple and not always consistent ways for mapping the target eNodeB ID (RANAP "Target ID") to the GTPv1-C "Target Identification" IE in the old SGSN. Therefore, if MME receives also the optional eNodeB ID IE from the old SGSN, the MME can ignore the Target Identification IE and use eNodeB ID IE.

When the old SGSN receives RANAP Cause value higher than 255 from source RNC, the RANAP Cause IE shall be included and may be set to implementation dependant value. Please refer to 3GPP TS 25.413 [7] for possible cause values which are relevant to the procedure in progress. When the old SGSN receives RANAP Cause value higher than 255 from source RNC, the old SGSN shall also copy it to Extended RANAP Cause IE, if it supports this IE.

If the new SGSN supports Extended Cause IE and if it receives the same from old SGSN, it should ignore the RANAP Cause IE.

The old SGSN shall include the CSG ID if the CSG ID is received from the source RNC. The old SGSN shall include the CSG Membership Indication if the source RNC indicates the target cell is a hybrid cell, or if the UE has emergency PDP context(s) and the target cell is a CSG cell.

For PS handover from A/Gb mode the BSSGP Cause IE shall be included and shall be set to the cause value received from the source BSC.

NOTE 3: The Charging Characteristics applicable for a PDP context may not be available in the source node, e.g. during mobility from E-UTRAN to GERAN/UTRAN if they are not received from the HSS.

The Selected PLMN ID IE indicates the core network operator selected for the MS in a shared network. The old SGSN shall include this IE if the selected PLMN identity is available; see 3GPP TS 23.251 [35] and 3GPP TS 25.413 [7] for details.

The presence of the Extended Common Flags IE is optional. The Unauthenticated IMSI bit field shall be set to 1 if the IMSI present in the message is not authenticated and is for an emergency attached MS.

If the Direct Tunnel Flags IE is included and if the GCSI bit of the Direct Tunnel Flags IE is set to 1, this indicates to the new SGSN that a GPRS‑CSI was present in the subscriber’s profile in the old SGSN and hence, a direct GTP‑U tunnel was prohibited. If the GCSI bit of the Direct Tunnel Flags IE is set to 0, this indicates to the new SGSN that a GPRS‑CSI was absent from the subscriber’s profile in the old SGSN and the new SGSN may or may not wait for the subscriber’s profile from HLR before establishing a direct tunnel between the RNC and GGSN. All other fields of the Direct Tunnel Flags IE shall be ignored.

NOTE 4: If the Direct Tunnel Flags IE is absent, then the new SGSN cannot know if a GPRS‑CSI was present in the subscriber’s profile in the old SGSN. Hence, the new SGSN has to wait for the subscriber’s profile from the HLR before the direct tunnel decisions are made. Therefore, sending the Direct Tunnel Flags IE allows the new SGSN to make the direct tunnel decisions before the subscriber’s profile is received from HLR.

The Co-located GGSN-PGW FQDN which applies for a PDP context may be included. One Co-located GGSN-PGW FQDN shall be included per PDP context IE. The mapping of a Co-located GGSN-PGW FQDN IE to a PDP Context IE is done according to the sequence of their appearance, e.g. the first Co-located GGSN-PGW FQDN IE is mapped to the first PDP Context IE. If the activated PDP Contexts of the PDP address and APN do not have the Co-located GGSN-PGW FQDN Information, the length field of the Co-located GGSN-PGW FQDN IE shall be set to 0. If all the activated PDP Contexts of the UE do not have the Co-located GGSN-PGW FQDN Information, the FQDN IE shall not be present in this message.

UE network capability provides the network with information concerning aspects of the UE related to EPS or interworking with GPRS.

To enable the target SGSN to initiate an SRVCC handover if required just after the PS handover, the source SGSN shall also include:

– the Additional MM context for SRVCC IE if the MS Classmark2, MS Classmark3 and the Supported Codec are available;

– the Additional flags for SRVCC IE if the ICS Indicator is available;

– the STN-SR IE if the STN-SR is available;

– the C-MSISDN IE if the C-MSISDN is available.

NOTE 5: A UE Usage Type IE with the length field equal to 0 is used for the receiver to differentiate the case where the sender does not support the Dedicated Core Network feature from the case where the sender supports the Dedicated Core Network feature but no UE Usage type was received in UE’s subscription.

The presence of the Extended Common Flags II IE is optional.

– The Delay Tolerant Connection Indication shall be set to 1 if the GGSN indicated that the PDN connection is delay tolerant.

NOTE 6: There may be a pending MT Short Message at the SMS-GMSC during a handover scenario, when the UE performs a Service Request towards the source MME/SGSN and a handover procedure occurs shortly afterward, before the SMS-GMSC is alerted to retransmit the pending MT Short Message.

The optional Private Extension contains vendor or operator specific information.

For an MS using a "Non-IP" connection to a GGSN/PGW, or a PDP context at SCEF, the source SGSN shall ensure that the target SGSN supports this kind of connection based on local configuration before sending the Forward Relocation Request, else it shall release them.

If the target SGSN supports it then the old SGSN shall include UE SCEF PDN Connection or PDP Context IE with PDP Type set to "Non-IP". Several IEs with the type UE SCEF PDN Connection value shall be included as necessary to represent a list of SCEF PDN Connections.

If the old SGSN has IPv4 and IPv6 control plane addresses of the GGSN available, the old IPv4/IPv6 capable SGSN shall include one of the GGSN control plane addresses in the PDP Context IE as specified in clause 7.7.29 and the other GGSN control plane address in the Alternative GGSN Address for control plane.

If the old SGSN has IPv4 and IPv6 user traffic addresses of the GGSN available, the old IPv4/IPv6 capable SGSN shall include one of the GGSN user traffic addresses in the PDP Context IE as specified in clause 7.7.29 and the other GGSN user traffic address in the Alternative GGSN Address for user traffic.

One Alternative GGSN Address for control Plane IE and one Alternative GGSN Address for user traffic IE shall be included per PDP context IE, as follows:

– The Alternative GGSN Address for control Plane IE for a secondary PDP context shall be the same as for the primary PDP context.

– The Alternative GGSN Address for control Plane IEs and Alternative GGSN Address for user traffic IEs shall be encoded after the SGSN Address for Control plane IE.

Table 29: Information Elements in a Forward Relocation Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
Tunnel Endpoint Identifier Control Plane	Mandatory	7.7.14
RANAP Cause	Mandatory	7.7.18
Packet Flow ID	Optional	7.7.22
Charging Characteristics	Optional	7.7.23
MM Context	Mandatory	7.7.28
PDP Context	Conditional	7.7.29
SGSN Address for Control plane	Mandatory	7.7.32
Alternative GGSN Address for control Plane	Optional	7.7.32
Alternative GGSN Address for user traffic	Optional	7.7.32
Target Identification	Mandatory	7.7.37
UTRAN transparent container	Mandatory	7.7.38
PDP Context Prioritization	Optional	7.7.45
MBMS UE Context	Optional	7.7.55
Selected PLMN ID	Optional	7.7.64
BSS Container	Optional	7.7.72
Cell Identification	Optional	7.7.73
BSSGP Cause	Optional	7.7.75
PS Handover XID Parameters	Optional	7.7.79
Direct Tunnel Flags	Optional	7.7.81
Reliable INTER RAT HANDOVER INFO	Optional	7.7.87
Subscribed RFSP Index	Optional	7.7.88
RFSP Index in use	Optional	7.7.88
Co-located GGSN-PGW FQDN	Optional	7.7.90
Evolved Allocation/Retention Priority II	Optional	7.7.92
Extended Common Flags	Optional	7.7.93
CSG ID	Optional	7.7.96
CSG Membership Indication	Optional	7.7.97
UE Network Capability	Optional	7.7.99
UE-AMBR	Optional	7.7.100
APN-AMBR with NSAPI	Optional	7.7.101
Signalling Priority Indication with NSAPI	Optional	7.7.104
Higher bitrates than 16 Mbps flag	Optional	7.7.105
Additional MM context for SRVCC	Optional	7.7.107
Additional flags for SRVCC	Optional	7.7.108
STN-SR	Optional	7.7.109
C-MSISDN	Optional	7.7.110
Extended RANAP Cause	Optional	7.7.111
eNodeB ID	Optional	7.7.112
Selection Mode with NSAPI	Optional	7.7.113
UE Usage Type	Optional	7.7.117
Extended Common Flags II	Optional	7.7.118
UE SCEF PDN Connection	Optional	7.7.121
Private Extension	Optional	7.7.46

7.5.7 Forward Relocation Response

The new SGSN shall send a Forward Relocation Response to the old SGSN as a response to a previous Forward Relocation Request.

Possible Cause values is:

– "Request Accepted".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "No resources available".

– "Invalid message format".

– "Relocation failure".

RANAP Cause is mandatory if cause value is contained in RANAP message.

RAB Setup Information, UTRAN transparent container and RANAP Cause are information from the target RNC in the new SGSN.

One or more RAB Setup Information parameters may be sent in this message. This information element shall be included if the Cause contains the value "Request accepted" and there is at least one RAB assigned in the new SGSN. During an inter RAT handover to E-UTRAN, the MME may provide reserved TEID/IP address values (see clause 7.5.5) within the RAB Setup Information, if the MME has determined that no Data forwarding is performed for a RAB.

The new SGSN shall include a SGSN Address for control plane. The old SGSN shall store this SGSN Address and use it when sending control plane messages for the MS to the new SGSN in the SRNS Relocation Procedure. If the Forward Relocation Request received from the old SGSN includes an IPv6 SGSN address, an IPv4/IPv6 capable SGSN shall include an IPv6 address in the field SGSN Address for Control Plane, otherwise, it shall include an IPv4 address in this field.

The Tunnel Endpoint Identifier Control Plane field specifies a Tunnel Endpoint Identifier that is chosen by the new SGSN. The old SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent signalling messages that are sent from the old SGSN to the new SGSN. This information element shall be included if the Cause contains the value "Request accepted".

One or more Additional RAB Setup Information parameters may be sent in this message for IPv6. This information element shall be included if the Cause contains the value "Request accepted" and there is at least one RAB assigned in the new SGSN. During an inter RAT handover to E-UTRAN the MME may provide reserved TEID/ IP address values within the RAB Setup Information, if the MME has determined that no Data forwarding is performed for a RAB.

For PS handover to A/Gb mode, if a cause value is received from the Target BSC, the BSSGP Cause IE shall be included and shall be set to the cause value received from the target BSC.

If the new SGSN has received the Cell Identification IE in the Forward Relocation Request message and the PS handover continues for at least one PDP Context, the NSAPI for each of the active PDP Contexts received in the Forward Relocation Request for which the PS handover continues are indicated in their priority order, highest priority first. One instance of the NSAPI IE will be inserted for each of these PDP Contexts.

The BSS Container information element contains the radio-related and core network information for the PS handover to A/Gb mode. For PS handover to Iu mode, the UTRAN transparent container shall be used. This information element shall be included if the Cause contains the value "Request accepted" .

The Tunnel Endpoint Identifier Data II IE, one information for each PDP context, contains the tunnel endpoint of the new SGSN. The SGSN Address for User Traffic contains the IP address of the new SGSN for data forwarding to the new SGSN during the PS handover procedure. The List of set-up PFCs IE contains the Packet Flow Identifiers of the PFCs that were successfully allocated in the target system during a PS handover.

The new SGSN receiving a Forward Relocation Request with the optional PS Handover XID Parameters, Packet Flow ID IE, BSS Container, Cell Identification IEs mandatory UTRAN transparent container, Target identification IEs having their value part empty according to their minimum defined length and RANAP Cause IEs set to cause #43 shall not reject this message if it supports the PS handover.

When the new SGSN receives RANAP Cause value higher than 255 from target RNC, the RANAP Cause IE shall be included and may be set to implementation dependant value. Please refer to 3GPP TS 25.413 [7] for possible cause values which are relevant to the procedure in progress. When the new SGSN receives RANAP Cause value higher than 255 from target RNC, the new SGSN shall also copy it to Extended RANAP Cause IE, if it supports this IE.

If the old SGSN supports Extended Cause IE and if it receives the same from new SGSN, it should ignore the RANAP Cause IE.

If the PMTSMI flag in the Forward Relocation Request message is set to 1, the target SGSN/MME shall include its E.164 Number in the SGSN Number IE and, if available, its Diameter Identity in the Node Identifier IE, for retransmission of pending MT-SMS to the UE.

The optional Private Extension contains vendor or operator specific information.

Table 30: Information Elements in a Forward Relocation Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
Tunnel Endpoint Identifier Data II	Optional	7.7.15
RANAP Cause	Conditional	7.7.18
SGSN Address for Control plane	Conditional	7.7.32
SGSN Address for User Traffic	Optional	7.7.32
UTRAN transparent container	Optional	7.7.38
RAB Setup Information	Conditional	7.7.39
Additional RAB Setup Information	Conditional	7.7.45A
SGSN Number	Optional	7.7.47
BSS Container	Optional	7.7.72
BSSGP Cause	Optional	7.7.75
List of set-up PFCs	Optional	7.7.78
Extended RANAP Cause	Optional	7.7.111
Node Identfiier	Optional	7.7.119
Private Extension	Optional	7.7.46

7.5.8 Forward Relocation Complete

The new SGSN shall send a Forward Relocation Complete to the old SGSN to indicate that the SRNS relocation procedure or the PS Handover procedure has been successfully finished.

The optional Private Extension contains vendor or operator specific information.

Table 31: Information Elements in a Forward Relocation Complete

Information element	Presence requirement	Reference
Private Extension	Optional	7.7.46

7.5.9 Relocation Cancel Request

The Relocation Cancel Request message is sent from the old SGSN to the new SGSN either when the old SGSN is requested to cancel the relocation procedure by the source RNC by means of a RANAP message or is requested to cancel the PS Handover procedure by the source BSS by means of a BSSGP message.

If the MS is emergency attached and the MS is UICCless (i.e. the mobile terminal cannot obtain IMSI at all) or the IMSI is unauthenticated, the International Mobile Equipment Identity (IMEI) shall be included by the SGSN.

If the MS is emergency attached and the MS is UICCless, the IMSI cannot not be included in the message. In all the other cases, the IMSI shall be included by the SGSN.

The Unauthenticated IMSI bit field shall be set to 1 if the IMSI present in the message is not authenticated and is for an emergency attached MS.

The old SGSN shall include the Extended RANAP Cause in the case of SRNS relocation cancel procedure. It shall contain the cause value received from the source RNC in the Relocation Cancel message received over the Iu interface.

The old SGSN terminates the PS Handover towards the target cell by sending a Relocation Cancel Request message to the new SGSN.

The optional Private Extension contains vendor or operator specific information.

Table 32: Information Elements in a Relocation Cancel Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
IMEI(SV)	Conditional	7.7.53
Extended Common Flags	Optional	7.7.93
Extended RANAP Cause	Optional	7.7.111
Private Extension	Optional	7.7.46

7.5.10 Relocation Cancel Response

The Relocation Cancel Response message is sent from the new SGSN to the old SGSN either when the relocation procedure has been cancelled in the old SGSN or when the PS handover procedure has been cancelled in the old SGSN. This message is used as the response to the Relocation Cancel Request message.

Possible Cause values are:

– "Request Accepted".

– "IMSI/IMEI not known".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

The optional Private Extension contains vendor or operator specific information.

Table 33: Information Elements in a Relocation Cancel Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.5.11 Forward Relocation Complete Acknowledge

The old SGSN sends a Forward Relocation Complete Acknowledge message to the new SGSN as a response to Forward Relocation Complete.

Possible Cause Values are:

– "Request Accepted".

– "Optional IE incorrect".

– "Invalid message format".

The optional Private Extension contains vendor or operator specific information.

Table 34: Information elements in a Forward Relocation Complete Acknowledge

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.26

7.5.12 Forward SRNS Context Acknowledge

The new SGSN sends a Forward SRNS Context Acknowledge message to the old SGSN as a response to Forward SRNS Context.

Possible Cause values are:

– "Request Accepted".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

Table 35: Information elements in a Forward SRNS Context Acknowledge

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.26

7.5.13 Forward SRNS Context

The Forward SRNS Context message is used for hard handover with switch in CN. When the old SGSN receives the RANAP message Forward SRNS Context, the old SGSN shall send a Forward SRNS Context message to the new SGSN. The new SGSN shall forward the message to the target RNC using the corresponding RANAP message.

When the old SGSN receives a BSSGP message PS Handover Required and the acknowledged peer-to-peer LLC operation is used for the PDP context or when "delivery order" is set in the PDP Context QoS profile, the old SGSN shall send a Forward SRNS Context message with the PDU Numbers IE to the new SGSN. The new SGSN shall forward the Forward SRNS Context message to the target RNC / target BSS using the corresponding RANAP message only for PS handover to Iu mode.

For each RAB context in the received RANAP message, the old SGSN shall include a RAB Context IE in the GTP-C Forward SRNS Context message.

If available, the old SGSN shall include a Source RNC PDCP context info in the Forward SRNS Context message.

When the old SGSN receives a BSSGP message PS Handover Required from source BSS/RNC for PS handover to A/Gb mode, the value part of RAB Context IE shall be empty according to its defined minimum length.

Table 36: Information Elements in a Forward SRNS Context

Information element	Presence requirement	Reference
RAB Context	Mandatory	7.7.19
Source RNC PDCP context info	Optional	7.7.61
PDU Numbers	Optional	7.7.74
Private Extension	Optional	7.7.46

7.5.14 RAN Information Management Messages

7.5.14.0 General

The RAN Information Relay is used over the Gn interface to tunnel RAN INFORMATION messages received by an SGSN from a BSS or from RNS. The procedures are specified in 3GPP TS 23.060 [4] and the RAN INFORMATION messages are specified in 3GPP TS 48.018 [20].

7.5.14.1 RAN Information Relay

All information elements from the RAN INFORMATION messages, starting from and including the BSSGP "PDU type", shall be contained within the RAN Transparent Container and forwarded to the destination SGSN or MME in the RAN Information Relay message. For handling of protocol errors the RAN Information Relay message is treated as a Response message.

The RIM Routing Address contains:

– the destination RNC Identity when the target is UTRAN or GERAN operating in GERAN Iu mode;

– the destination Cell Identifier when the target is GERAN;

– the Target eNodeB ID when the target is E-UTRAN.

The RIM Routing Address Discriminator indicates which type of address is provided in the RIM Routing Address. If RIM Routing Address Discriminator IE is not included, the RIM Routing Address shall be processed as an RNC identifier, or as if "RIM Routing Address discriminator = 0001".

The optional Private Extension contains vendor or operator specific information.

Table 7.5.14.1: Information Elements in a RAN Information Relay

Information element	Presence requirement	Reference
RAN Transparent Container	Mandatory	7.7.43
RIM Routing Address	Optional	7.7.57
RIM Routing Address Discriminator	Optional	7.7.77
Private Extension	Optional	7.7.46

7.5.15 UE Registration Query Request

This message is sent by an SGSN to an MME to support CS/PS coordination for shared UTRAN and GERAN access. When an SGSN receives a UE Registration Query from a RAN node, including an indication to also query MMEs, and if the UE (identified by IMSI) is not registered in the SGSN, the SGSN shall send a UE Registration Query Request message to all MMEs that may hold the UE’s context, as specified in the clause 7.1.6 of 3GPP TS 23.251 [55].

NOTE: How the SGSN determines which MME it will query, is based on local configuration.

Table 7.5.15-1 specifies the presence of IEs in this message.Table 7.5.15-1: Information Elements in UE Registration Query Request

Information element	Presence requirement	Reference
IMSI	Mandatory	7.7.2
Private Extension	Optional	7.7.46

7.5.16 UE Registration Query Response

The UE Registration Query Response message shall be sent as a response to UE Registration Query Request, to report whether the inquired UE is registered in the MME and if so, with which Core Network Operator, as specified in the clause 7.1.6 of 3GPP TS 23.251 [55].

Possible Cause values are:

– "Request Accepted", to be used when the UE is registered in the MME

– "IMSI/IMEI not known", to be used when the UE is not registered in the MME

– "Mandatory IE incorrect"

– "Mandatory IE missing"

– "Optional IE incorrect"

– "Invalid message format"

The IMSI shall be included even when the UE is not registered in the MME, to enable the SGSN to correlate the received response with a sent request.

The Selected PLMN ID identifies the core network operator currently serving the UE, and shall be included if the inquired UE is registered in the MME.

The optional Private Extension contains vendor or operator specific information.

Table 7.5.16-1 specifies the presence of IEs in this message.

Table 7.5.16-1: Information Elements in UE Registration Query Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
IMSI	Mandatory	7.7.2
Selected PLMN ID	Conditional	7.7.64
Private Extension	Optional	7.7.46