Section: D.3.5 Routing Area Update
Content: The Routing Area Update procedure takes place when a UE that is registered with an MME selects a UTRAN or GERAN cell served by a Gn/Gp SGSN. In this case, the UE changes to a Routing Area that the UE has not yet registered with the network. This procedure is initiated by an idle state or by a connected state UE. The Routing Area Update procedure is illustrated in Figure D.3.5-1. Any step descriptions that are taken from TS 23.060[ General Packet Radio Service (GPRS); Service description; Stage 2 ]  [7] for a Gn/Gp SGSN are shown as italic text and remain unmodified. In that step descriptions an MS stands for UE, old SGSN for old MME and GGSN for P-GW. The old MME behaves towards the new Gn/Gp SGSN always like an old Gn/Gp 3G-SGSN, regardless of whether the new Gn/Gp SGSN is a 2G-SGSN or a 3G-SGSN. Figure D.3.5-1: Routing Area Update procedure 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). 1. 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[ Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 ]  [47]. 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[ Numbering, addressing and identification ]  [9]. 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". 2. 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. NOTE 2: A GUTI mapped to a P-TMSI/RAI provides an old RAI that uniquely identifies an old MME then there is no need to relay between MME in the old pool, regardless whether the new SGSN supports such functionality or not. Mapping a GUTI to a P-TMSI and an RAI is specified in Annex H. 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. NOTE 3: For the new SGSN, this step is unmodified compared to pre-Rel-8. The MME (called old SGSN in above description) needs to provide SGSN functionality. 2b. 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). NOTE 4: This step is for the Gn/Gp SGSN unmodified compared to pre-Rel-8. The MME (old SGSN in this step) maps EPS bearers one-to-one to PDP contexts and provides the Release 99 parameters of the bearer QoS profile to the new SGSN. The Gn signalling between the new Gn/Gp SGSN and the old CN node has no capabilities to indicate ISR Activated or ISR Supported. The GTP and PDCP sequence numbers are not relevant as the network does not configure usage of "delivery order required" and does not configure loss less UTRAN PDCP as described in clause "compatibility issues". 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. 3. Security functions may be executed. These procedures are defined in clause "Security Function" in TS 23.060[ General Packet Radio Service (GPRS); Service description; Stage 2 ]  [7]. 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. NOTE 5: This step is unmodified compared to pre-Rel-8. 4. 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. NOTE 6: The new SGSN's operation is unmodified compared to pre-Rel-8. The old MME/S-GW (old SGSN from the new SGSN's point of view) does not forward any data towards the new SGSN. 5. Void. 6. 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. NOTE 9: This step is unmodified compared to pre-Rel-8. For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 6 and 13 are skipped. 7. 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[ General Packet Radio Service (GPRS); Service description; Stage 2 ]  [7]. NOTE 10: This step is unmodified compared to pre-Rel-8. Clarification about update type added to show that this is the trigger for the HSS to cancel only an old SGSN and not also an old MME. 8. 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). NOTE 11: For the Gn/Gp SGSN the HSS interoperation is unmodified compared to earlier standards Releases. 9. 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[ Network sharing; Architecture and functional description ]  [24] 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. NOTE 12: This step is unmodified compared to pre-Rel-8. 10. The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN. NOTE 13: This step is unmodified compared to pre-Rel-8. 11. 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[ Network sharing; Architecture and functional description ]  [24] 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[ General Packet Radio Service (GPRS); Service description; Stage 2 ]  [7]. 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. NOTE 13a: A Gn/Gp SGSN never indicates ISR Activated as it does not support ISR. NOTE 14: For the SGSN this step is unmodified compared earlier standards Releases. N-PDU numbers are not relevant as the network does not configure usage of acknowledged mode NSAPIs as described in clause "compatibility issues". 12. 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. NOTE 15: This step is unmodified compared to pre-Rel-8. N-PDU numbers are not relevant as the network does not configure usage of acknowledged mode NSAPIs as described in clause "compatibility issues". 13. 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. NOTE 16: The new SGSN may initiate RAB establishment after execution of the security functions, or wait until completion of the RA update procedure. For the MS, RAB establishment may occur any time after the Routing Area Update Request is sent. In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions, access restrictions (see TS 23.221[ Architectural requirements ]  [27] and TS 23.008[ Organization of subscriber data ]  [28]) or because the SGSN cannot determine the HLR address to establish the locating updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to the MS with an appropriate cause and the PS signalling connection shall be released. Upon return to idle, the MS shall act according to TS 23.122[ Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode ]  [10]. 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[ Network sharing; Architecture and functional description ]  [24] instead of rejecting the routing area update. If the new SGSN is unable to update the PDP context in one or more GGSNs, the new SGSN shall deactivate the corresponding PDP contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routing area update. The PDP Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context first in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based on the current activity). The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP context from the GGSN and then store the new Maximum APN restriction value. If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, 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. In any case, the new SGSN shall first update all contexts in one or more GGSNs and then deactivate the context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routing area update. NOTE 17: If MS was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward Relocation Request message as described in clause "Serving RNS relocation procedures" of TS 23.060[ General Packet Radio Service (GPRS); Service description; Stage 2 ]  [7]. If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing Area Update Reject (Cause) message, the MS shall enter IDLE state. NOTE 18: The C1 CAMEL procedure call was omitted intentionally from this procedure since EPS does not support CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8. The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078[ Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2 ]  [29]: C2) 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". C3) CAMEL_GPRS_Routing_Area_Update_Context.