Content for  TS 23.401  Word version:  18.4.0

The UE selects a UTRAN or GERAN cell. This cell is in a Routing Area that the UE not yet registered with the network or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell Change (NACC).

The MS sends a Routing Area Update Request (old P-TMSI, old RAI, old P-TMSI Signature, Update Type, follow on request, Classmark, MS Network Capability, additional P-TMSI/RAI, KSI) to the new SGSN. Update Type shall indicate RA update, periodic RA update, Combined RA / LA Update or Combined RA / LA Update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before passing the message to the SGSN. The SRNC shall add the Routing Area Identity before forwarding the message to the 3G-SGSN. Classmark contains the MS GPRS multislot capabilities and supported GPRS ciphering algorithms as defined in TS 24.008. The SGSN may use, as an implementation option, the follow-on request indication to release or keep the Iu connection after the completion of the RA update procedure. If the UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to a P-TMSI and an RAI is specified in TS 23.003. If the UE holds a valid P-TMSI and related RAI and the old P-TMSI and old RAI indicate a P-TMSI/RAI mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI. The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. The old P-TMSI is indicated in the RAU Request message for Iu-mode only. For Gb mode the TLLI is derived from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT mobility. KSI is mapped from an eKSI identifying a KASME if the UE indicates a P-TMSI mapped from GUTI in the information element "old P-TMSI". KSI identifies a (CK, IK) pair if the UE indicates a P-TMSI in the information element "old P-TMSI".

The new SGSN sends SGSN Context Request (old RAI, TLLI or old P-TMSI, old P-TMSI Signature, New SGSN Address) to the old SGSN to get the MM and PDP contexts for the MS. If the new SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this old SGSN. Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) and relay the message to that actual old SGSN. The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request. If the UE uses power saving functions and the old MME indicates Buffered DL Data Waiting, the new SGSN invokes data forwarding and user plane setup corresponding to clause 5.3.3.1A.

The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each PDP context the old 3G-SGSN shall include the GTP sequence number for the next uplink GTP PDU to be tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to be sent to the MS. Each PDP Context also includes the PDCP sequence numbers if PDCP sequence numbers are received from the old SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context Response only when it has previously received an MS Network Capability in the Routing Area Request. The GTP sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for the PDP context (QoS profile). For UE using CIoT EPS Optimisation without any activated PDN connection, there is no PDP Context(s) included in the SGSN Context Response message. The MME (old SGSN in this step) only transfers the PDP Context(s) that the new SGSN supports. If not supported, PDP Context(s) of non-IP PDN connection are not transferred to the new SGSN. PDP Context(s) of Ethernet PDN connection are not transferred to the new SGSN. If the PDP Context(s) of a PDN connection has not been transferred, the MME shall consider all bearers of that PDN connection as failed and release that PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3.

Security functions may be executed. These procedures are defined in clause "Security Function" in TS 23.060. Ciphering mode shall be set if ciphering is supported. If the SGSN Context Response message did not include IMEISV and ADD is supported by the SGSN, the SGSN retrieves the IMEISV from the MS. If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS with an appropriate cause.

The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old MME (which is the old SGSN from the new SGSN's point of view) marks in its context that the information in the GWs and the HSS are invalid. This triggers the GWs, and the HSS to be updated if the UE initiates a Tracking Area Update procedure back to the old MME before completing the ongoing Routing Area Update procedure. If the security functions do not authenticate the MS correctly, then the routing area update shall be rejected, and the new SGSN shall send a reject indication to the old SGSN. The old MME shall continue as if the SGSN Context Request was never received.

Void.

The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, NRSN) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. NRSN indicates SGSN support of the network requested bearer control. The SGSN shall only indicate that it supports the procedure if it supports it and it is indicated that the MS also supports it in the SGSN Context Response message as described above. If the NRSN is not included in the Update PDP Context Request message the GGSN shall, following this procedure, perform a GGSN-Initiated PDP Context Modification to change the BCM to 'MS-Only' for all PDP-Address/APN-pairs for which the current BCM is 'MS/NW'. The GGSNs update their PDP context fields and return Update PDP Context Response (TEID, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM). The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 6 and 13 are skipped.

The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI, IMEISV, Update Type, Homogenous Support of IMS Voice over PS Sessions) to the HLR. IMEISV is sent if the ADD function is supported. Update Type indicates "normal update". For "Homogenous Support of IMS Voice over PS Sessions", see clause 5.3.8A of TS 23.060.

The HLR sends Cancel Location (IMSI, Cancellation Type) to any old SGSN with Cancellation Type set to Update Procedure. The old SGSN removes the MM and EPS bearer contexts. The old SGSN acknowledges with Cancel Location Ack (IMSI).

The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The new SGSN validates the UE's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the MS is not allowed to be attached in the RA, the SGSN rejects the Routing Area Update Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 instead of rejecting the Routing Area Update Request. If all checks are successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.

The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.

If the new SGSN is a 2G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access restrictions the MS, is not allowed to be attached in the SGSN, or if subscription checking fails, the new SGSN rejects the routing area update with an appropriate cause. If all checks are successful, the new SGSN constructs MM and PDP contexts for the MS. A logical link is established between the new SGSN and the MS. The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU Number, PDP context status). Receive N-PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-originated N-PDUs successfully transferred before the start of the update procedure. If the new SGSN is a 3G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the SGSN rejects the routing area update with an appropriate cause. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 instead of rejecting the routing area update. If all checks are successful, the new SGSN establishes MM context for the MS. The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature). For a MS with ongoing emergency bearer services, the new 3G-SGSN accepts the Routing Area Update Request and deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 in TS 23.060. When receiving the RAU Accept message and there is no ISR Activated indication the UE shall set its TIN to "P-TMSI". With the PDP context status information, the MS shall deactivate all those bearers contexts locally which are active in the MS, but are indicated by the SGSN as being inactive.

If the new SGSN is a 2G-SGSN: The MS acknowledges the new P-TMSI by returning a Routing Area Update Complete (Receive N-PDU Number) message to the SGSN. Receive N-PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfully transferred before the start of the update procedure. If Receive N-PDU Number confirms reception of N-PDUs that were forwarded from the old SGSN, these N-PDUs shall be discarded by the new SGSN. LLC and SNDCP in the MS are reset. If the new SGSN is a 3G-SGSN: The MS confirms the reallocation of the TMSIs by returning a Routing Area Update Complete message to the SGSN.

When the timer started in step 2) expires the old MME releases any RAN and Serving-GW resources. If the PLMN has configured Secondary RAT usage data reporting, the MME first releases RAN resource before releasing Serving-GW resources. When the MME receives Secondary RAT usage data from eNodeB in the S1 UE Context Release complete message, the MME continues with the Secondary RAT usage data reporting procedure using change notification message as described in clause 5.7A.3. The reporting procedure in clause 5.7A.3 is only performed if PGW secondary RAT usage reporting is active. The old MME deletes the EPS bearer resources by sending Delete Session Request (Cause; Operation Indication, Secondary RAT usage data) messages to the Serving-GW. The operation Indication flag is not set, that indicates to the old Serving-GW that the old Serving-GW shall not initiate a delete procedure towards the PDN-GW. Secondary RAT usage data is included if it was received from the source eNodeB in the S1 UE Context Release complete message. The old MME derives from the GTPv1 context transfer signalling that the new SGSN is a Gn/Gp SGSN and therefore any old S-GW resources are released by the old MME. A Gn/Gp SGSN does not signal any S-GW change. If the old S-GW has due to ISR a control connection with another CN node (MME or SGSN) the cause indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that other old CN node. If the old MME has an S1-MME association for the UE, the source MME sends a S1-U Release Command to the source eNodeB when receiving the SGSN Context Acknowledge message from the new SGSN. The RRC connection is released by the source eNodeB. The source eNodeB confirms the release of the RRC connection and of the S1-U connection by sending a S1-U Release Complete message to the source MME. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to report, the source eNodeB includes Secondary RAT usage data in this message.

CAMEL_GPRS_Routing_Area_Update_Session and CAMEL_PS_Notification. They are called in the following order:

• The CAMEL_GPRS_Routing_Area_Update_Session procedure is called. The procedure returns as result "Continue".
• Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue".

CAMEL_GPRS_Routing_Area_Update_Context.