Content for  TS 23.060  Word version:  18.0.0

The RRC connection is established, if not already done. The MS sends a Routeing Area Update Request message (P-TMSI, old RAI, old P-TMSI Signature, Update Type, follow on request, MS Radio Access Capability, DRX Parameters, extended idle mode DRX parameters, MS Network Capability, additional P-TMSI/RAI, Voice domain preference and UE's usage setting, SMS-only) to the new SGSN. The MS shall set a follow-on request if there is pending uplink traffic (signalling or user data). 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. Update Type shall indicate:

• RA Update if the RA Update is triggered by a change of RA;
• Periodic RA Update if the RA update is triggered by the expiry of the Periodic RA Update timer;
• Combined RA / LA Update if the MS is also IMSI-attached and the LA update shall be performed in network operation mode I (see clause "Interactions Between SGSN and MSC/VLR"); or
• Combined RA / LA Update with IMSI attach requested if the MS wants to perform an IMSI attach in network operation mode I.

The SRNC shall add the Routeing Area Identity before forwarding the message to the 3G SGSN. This RA identity corresponds to the RAI in the MM system information sent by the SRNC to the MS. CSG ID is indicated if the MS sends the RAU Request message via a CSG cell or a hybrid cell. CSG access mode is provided if the MS sends the RAU Request message via a hybrid cell. If the CSG access mode is not provided but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell. For SIPTO at the Local Network with stand-alone GW architecture the new SRNS includes also the Local Home Network ID in the Initial UE Message if the target cell is in a Local Home Network. MS Radio Access Capability is described in clause "MS Network Capability". The DRX Parameters contain information about DRX cycle length for GERAN, UTRAN and possibly other RATs, e.g. E-UTRAN. The extended idle mode DRX parameters information element is included if the MS wants to enable extended idle mode DRX. If the E-UTRAN capable 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.401. In this scenario of Iu mode RAU, the TIN indicates "P-TMSI" or "RAT related TMSI". If the E-UTRAN capable UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as additional P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or parameters mapped from a GUTI. The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in clause 5.3.15. The MS indicates its "SMS-only" capability during a combined RA/LA update when the MS is requesting LA update or IMSI attach only for obtaining SMS and not any other services from CS domain.

If the RA update is an Inter-SGSN Routeing area update and if the MS was in PMM IDLE state, the new SGSN sends an SGSN Context Request message (old P-TMSI, old RAI, old P-TMSI Signature) 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 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 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 (IMSI, old RAI, MS Validated) 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 SGSN (in a network supporting unauthenticated UEs) the old SGSN continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request.

If the MS is PMM CONNECTED state in the old 3G Gn/Gp-SGSN or, in case of an intra-Gn/Gp-SGSN RA update, if the MS is in the PMM CONNECTED state and the RAU was received over another Iu connection than the established one, the old Gn/Gp SGSN sends an SRNS Context Request message to the old SRNS to retrieve the sequence numbers for the PDP context for inclusion in the SGSN Context Response message. Upon reception of this message, the SRNS buffers and stops sending downlink PDUs to the MS and returns an SRNS Context Response (IMSI, GTP SNDs, GTP SNUs, PDCP SNUs) message. The SRNS shall include for each PDP context the next in-sequence GTP sequence number to be sent to the MS and the GTP sequence number of the next uplink PDU to be tunnelled to the GGSN. For each active PDP context which uses lossless PDCP, the SRNS also includes the uplink PDCP sequence number (PDCP SNU). PDCP SNU shall be the next in-sequence PDCP sequence number expected from the MS (per each active radio bearer). No conversion of PDCP sequence numbers to SNDCP sequence numbers shall be done in the 3G-SGSN. SNDCP, GTP and PDCP sequence numbers are not relevant for the S4-SGSN as the network shall not configure usage of "delivery order required", no acknowledged mode NSAPIs (SNDCP) and also not loss less UTRAN PDCP as described in clause "Network Configuration for Interaction with E-UTRAN and S4-SGSNs".

The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts, Negotiated Evolved ARP) 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 Routeing 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). If the UE receives emergency services from the old 3G Gn/Gp-SGSN and the UE is UICCless, IMSI can not be included in the MM and PDP contexts in SGSN Context Response message. For emergency attached UEs if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated. For RAU between two S4-SGSNs, the old SGSN shall include the Change Reporting Action in the Context Response message.

Security functions may be executed. These procedures are defined in clause "Security Function". If the SGSN Context Response message did not include IMEISV and ADD is supported, the SGSN retrieves the IMEISV from the MS. If the security functions do not authenticate the MS correctly, the routeing area update shall be rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN Context Request was never received. If the new SGSN is configured to allow emergency services for unauthenticated MS the new SGSN behave as follows:

• where a MS has only emergency bearer services, the SGSN either skips the authentication and security setup or accepts that the authentication may fail and continues the Routeing area update procedure, or.
• where a MS has both emergency and non emergency bearer services and authentication fails, the SGSN continues the Routing Area Update procedure and deactivates all the non-emergency PDP contexts as specified in clause 9.2.4.2.

If the RA update is an Inter-SGSN Routeing area update, the new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs an old Gn/Gp SGSN that the new SGSN is ready to receive data packets belonging to the activated PDP contexts. Only old Gn/Gp SGSNs may forward data to a new Gn/Gp or S4-SGSN. A new S4-SGSN indicates reserved TEID and IP address parameters from an SGW to an old Gn/Gp SGSN so that the old Gn/Gp SGSN can forward data packets when needed. The SGW discards any packets received from old Gn/Gp SGSN. The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area update procedure back to the old SGSN before completing the ongoing routeing area update procedure.

If the MS is in PMM CONNECTED state in the old 3G-Gn/Gp-SGSN or, in case of an intra-Gn/Gp-SGSN RA update, if the MS is PMM connected and the RAU was received over another Iu connection than the established one, the old 3G Gn/Gp-SGSN sends an SRNS Data Forward Command (RAB ID, Transport Layer Address, Iu Transport Association) message to the SRNS. Upon receipt of the SRNS Data Forward Command message from the 3G SGSN, the SRNS shall start the data-forwarding timer.

For each indicated RAB the SRNS starts duplicating and tunnelling the buffered GTP PDUs to the old 3G-Gn/Gp-SGSN. For each radio bearer which uses lossless PDCP the SRNS shall start tunnelling the partly transmitted and the transmitted but not acknowledged PDCP-PDUs together with their related PDCP sequence numbers and start duplicating and tunnelling the buffered GTP PDUs to the old 3G-Gn/Gp-SGSN. Upon receipt of the SRNS Data Forward Command message from the 3G-Gn/Gp-SGSN, the SRNS shall start the data-forwarding timer.

If the RA update is an Inter-SGSN RA Update, the old 3G SGSN tunnels the GTP PDUs to the new 3G SGSN. No conversion of PDCP sequence numbers to SNDCP sequence numbers shall be done in the 3G-SGSN.

If the RA update is an Inter-SGSN RA Update and if the MS was not in PMM-CONNECTED state in the new 3G-SGSN, the new SGSN sends Update PDP Context Request (new SGSN Address, QoS Negotiated, Negotiated Evolved ARP, Tunnel Endpoint Identifier, serving network identity, CN Operator Selection Entity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN) to the GGSNs concerned. The SGSN shall send the serving network identity and the CN Operator Selection Entity to the GGSN. The CN Operator Selection Entity indicates whether the Serving Network has been selected by the UE or by the network. NRSN indicates SGSN support of the network requested bearer control. The inclusion of the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If the new SGSN did not receive a Negotiated Evolved ARP IE in the SGSN Context Response message from the old SGSN then the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated according to Annex E of TS 23.401. The GGSNs update their PDP context fields and return an Update PDP Context Response (Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP). The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401, Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN.

If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI, IMEISV, Homogenous Support of IMS Voice over PS Sessions, UE SRVCC capability, Registration For SMS Request) to the HLR. IMEISV is sent if the ADD function is supported. The "Homogenous Support of IMS Voice over PS Sessions" indication (see clause 5.3.8A) shall not be included unless the SGSN has completed its evaluation of the support of "IMS voice over PS Session" as specified in clause 5.3.8. If the S6d interface is used between S4-SGSN and HSS, a parameter "SMS in SGSN offered" is included in the Update Location message, otherwise this parameter is included in the Insert Subscriber Data Ack (Step 12). "SMS in SGSN offered" indicates that the SGSN supports SMS services via SGSN. If the MS performs the Routeing Area Update procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the SGSN needs to retrieve the CSG subscription information of the MS from the CSS, the SGSN initiates the Update CSG Location Procedure with CSS as described in clause 6.16.

If the RA update is an Inter-SGSN RA Update, the HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure. If the timer described in step 2 is not running, the old SGSN removes the MM and PDP context/EPS Bearer Contexts and an old S4-SGSN releases in addition the S-GW resources when the new SGSN is a Gn/Gp SGSN or when an S-GW change is performed. GTPv1 SGSN context transfer signalling indicates to the old S4-SGSN that the new SGSN is a Gn/Gp SGSN, which does not signal any S-GW change. When the timer described in step 2 is running the MM and PDP/EPS Bearer Contexts and any affected S-GW resources are removed when the timer expires and the SGSN received a Cancel Location. The old S4-SGSN deletes S-GW bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the SGW. If ISR is activated the Cause indicates that the old S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message to the other CN node. The Operation Indication flag is not set by the old S4-SGSN. This indicates to the S-GW that the S-GW shall not initiate a delete procedure towards the PDN-GW. When the timer described in step 2 expires and no Cancel Location was received the S4-SGSN removes the PDP contexts/EPS Bearer Contexts but preserves the MM context. The timer started in step 2 ensures that the MM and PDP contexts/EPS Bearer Contexts are kept in the old SGSN in case the MS initiates another inter SGSN routeing area update before completing the ongoing routeing area update to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI).

On receipt of Cancel Location, if the MS is PMM CONNECTED in the old 3G SGSN, the old 3G SGSN sends an Iu Release Command message to the old SRNC. When the data-forwarding timer has expired, the SRNS responds with an Iu Release Complete message.

If the RA update is an inter-SGSN RA Update, the HLR sends Insert Subscriber Data (IMSI, subscription data) to the new SGSN. The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the MS is not allowed to be attached in the RA, the SGSN rejects the Routeing 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 Routeing 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, SMS in SGSN offered) message to the HLR. The "SMS in SGSN offered" indicates that the SGSN supports SMS services via NAS. If the S6d interface is used between S4-SGSN and HSS the messages "Insert Subscriber Data" and "Insert Subscriber Data Ack" are not used. Instead the Subscription Data is sent by HSS in the message Update Location Ack (Step 13). The subscription data may contain the CSG subscription data for the PLMN. If the MS initiates the RAU procedure at a CSG cell, the new SGSN shall check whether the CSG ID and associated PLMN and associated PLMN is contained in the CSG subscription and is not expired. If the CSG ID and associated PLMN is not present or expired, the SGSN shall send a RAU reject message to the MS with an appropriate cause value. The MS shall remove the CSG ID and associated PLMN from its Allowed CSG list, if present.

If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the Update Location by sending Update Location Ack (IMSI, GPRS Subscriber Data (only if S6d interface is used)) to the new SGSN. If the HLR accepts to register the SGSN identity for terminating SMS services, then the HLR cancels the serving MSC if there is a serving MSC.

If Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the routeing area update, the association has to be established, and the new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. Otherwise, Location Update Type shall indicate normal location update. When the SGSN does not provide functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived from the RAI. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HLR in step 8). The VLR creates or updates the association with the SGSN by storing SGSN Number. In networks that support network sharing, the Location Update Request includes the identity of the selected core network operator if the SGSN has received this information from the RNS, as described in TS 23.251. This step is not performed if:

• Subscription Data indicate by the Network Access Mode information that the subscription has no CS subscriber data; or
• Subscription Data have an HSS indication of "SMS in SGSN Support" and the subscription allows SMS services and the MS indicated SMS-only and the SGSN provides SMS services via PS domain NAS.

If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data in the new VLR:

1. The new VLR sends an Update Location (new VLR) to the HLR.
2. The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.
3. The old VLR acknowledges with Cancel Location Ack (IMSI).
4. The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR.
5. The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).
6. The HLR responds with Update Location Ack (IMSI) to the new VLR.

If the MS performs the Routing Area Update procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the VLR needs to retrieve the CSG subscription information of the MS from the CSS, the VLR initiates the Update CSG Location Procedure with CSS as described in clause 6.16.

The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN. VLR TMSI is optional if the VLR has not changed.

The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access restrictions (e.g. CSG restrictions) the MS is not allowed to be attached in the RA, or if subscription checking fails, the SGSN rejects the routeing 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 routeing area update. If all checks are successful, the new SGSN establishes MM and PDP contexts/EPS Bearer Contexts for the MS. The new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature, IMS voice over PS Session Supported Indication, Emergency Service Support, SMS-Supported, Cause). The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8. If the SGSN did not receive the Voice Support Match Indicator in the MM Context, then the SGSN sends a UE Radio Capability Match Request to the RAN as described in clause 6.9.5. If the SGSN has not received Voice Support Match Indicator from the RAN then, based on implementation, SGSN may set IMS Voice over PS session supported Indication and update it at a later stage. ISR Activated is never indicated in case of inter SGSN RAU as described in TS 23.401. The E-UTRAN capable UE sets its TIN to "P-TMSI" or "RAT related TMSI" as described for Routing Area Update procedures in TS 23.401. If ISR is activated for the MS when the S4-SGSN receives the Routeing Area Update Request in the intra SGSN scenario, the S4-SGSN should maintain ISR by indicating ISR Activated in the Routeing Area Update Accept message. If RAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the MS upon receiving the RAU Accept message shall add the CSG ID and associated PLMN to its Allowed CSG list if it is not already present. Manual CSG selection is not supported if the MS has emergency bearers established. If the user plane setup is performed in conjunction with the RAU Accept message and the RAU is performed via a hybrid cell, then the SGSN shall send an indication whether the UE is a CSG member to the RAN along with the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members. The Emergency Service Support indicator informs the MS that Emergency PDP contexts are supported, i.e. the MS is allowed to request activation of emergency PDP context when needed. If due to regional subscription restrictions, or not allowed CSG, an MS with ongoing emergency bearer service is not allowed to access the RA or CSG cell the SGSN shall accept the Routing Area Update Request and deactivate the non-emergency PDP context as specified in clause 9.2.4.2. If the Routing Area Update procedure is initiated in PMM-IDLE/STANDBY state, all non-emergency PDP Contexts are deactivated by the Routing Area Update procedure without PDP Context deactivation signalling between the SGSN and the MS. The MS shall be prevented from accessing GERAN in case of emergency bearer services. "SMS-Supported" is indicated to the MS when the HSS has indicated "SMS in SGSN Support". It indicates to the MS that it can obtain SMS services via PS domain NAS from the SGSN. An MS that needs only PS and SMS services via NAS should not perform any procedures via CS domain when it can obtain SMS services via PS domain NAS from SGSN. If step 14 was not performed, e.g. due to Subscription Data indicate by the Network Access Mode information that the subscription has no CS subscriber data, then SGSN indicates that the Attach was successful for GPRS only and a Cause indicates why the IMSI attach was not performed. In Iu mode, if after step 9 the new SGSN receives a Downlink Data Notification message or any other downlink signalling message while the MS is still connected, the new SGSN may prolong the PS signalling connection with the MS. If the SGSN decides to enable extended idle mode DRX for an MS that had included the extended idle mode DRX paremeters information element, it includes the extended idle mode DRX parameters information element.

The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the SGSN.

The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR TMSI.

After step 10, and in parallel to any of the preceding steps, the SGSN shall send either a GPRS Update Location (Homogeneous Support of IMS Voice over PS Sessions) to the HLR or, when the S6d interface is used, a Notify Request (Homogeneous Support of IMS Voice over PS Sessions) message to the HSS:

• if the SGSN has evaluated the support of IMS Voice over PS Sessions, see clause 5.3.8, and
• if the SGSN determines that it needs to update the Homogeneous Support of IMS Voice over PS Sessions, see clause 5.3.8A.

CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification. They are called in the following order:

• The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The procedure returns as result "Continue".
• Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue".
• Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue".

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

• The CAMEL_GPRS_Routeing_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_Routeing_Area_Update_Context.

If the RA update is an Inter SGSN Routeing area update and if the MS was in PMM IDLE state, the new SGSN sends a Context Request message (old P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to get the MM and EPS Bearer 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 and send the 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 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 a Context Request (IMSI, old RAI, MS Validated) 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.

The old 3G SGSN responds with a Context Response (MM Context, EPS Bearer Contexts) message. MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. The new 3G SGSN shall ignore the MS Network Capability contained in MM Context of Context Response only when it has previously received an MS Network Capability in the Routeing Area Request. If the UE receives only emergency services from the old S4-SGSN and the UE is UICCless, IMSI can not be included in the MM and PDP contexts in SGSN Context Response message. For emergency attached UEs if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated. For RAU between two S4-SGSNs, the old SGSN shall include the Change Reporting Action and CGI/SAI/RAI change support indication in the Context Response message. If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW, the old S4 SGSN shall include the Local Home Network ID of the old cell in the EPS Bearer context corresponding to the SIPTO at the Local Network PDN connection.

If the RA update is an Inter SGSN Routeing area update, the new SGSN sends a Context Acknowledge message to the old SGSN. The old SGSN marks in its context that the MSC/VLR association and the information in the S-GW and the HLR are invalid. This triggers the MSC/VLR, the S-GWs, and the HLR to be updated if the MS initiates a routeing area update procedure back to the old SGSN before completing the ongoing routeing area update procedure.

If the S-GW does not change, the new SGSN update these EPS Bearer contexts by sending Modify Bearer Request (SGSN Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control Plane, SGSN Address(es) and TEID(s), PDN-GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for PMIP based S5/S8) at the PDN-GW(s) for uplink traffic, serving network identity, CN Operator Selection Entity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication). The SGSN puts the according NSAPI in the field of EPS Bearer ID. If ISR is activated on the S-GW that is updated by a new SGSN then this S-GW deletes the bearer resources on the other old CN node by sending Delete Session Request message(s) to that CN node. If ISR Activated is indicated or SGSN and SGW are configured to release S4 U-Plane when EPS Bearer Contexts associated with the released RABs are to be preserved, the SGSN does not send SGSN address and TEID for U-Plane in Modify Bearer Request. If the S-GW changes or if an S-GW needs to be allocated (Gn/Gp to S4-SGSN RAU) the SGSN selects an S-GW and sends a Create Session Request message (APN-AMBR) with the content as described for the Modify Bearer Request message to the S-GW. For Gn/Gp to S4-SGSN RAU, the new S4-SGSN provides APN-AMBR to the Serving GW. Details on mapping MBR to APN-AMBR are specified in Annex E of TS 23.401.

If the S-GW has changed, or if an S-GW needs to be allocated (Gn/Gp to S4-SGSN RAU), or the RAT type has changed, or the S-GW received CGI/SAI from the S4-SGSN, the S-GW sends Modify Bearer Request (EPS Bearer ID(s), serving network identity, CN Operator Selection Entity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, APN-AMBR) messages to the P-GWs involved.

The P-GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, Default Bearer id, APN-AMBR) messages to S-GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. The default bearer id is included if the UE moves from a Gn/Gp SGSN to an S4-SGSN.

The S-GW acknowledges the connection establishment to the new SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, PDN-GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for PMIP based S5/S8) at the PDN-GW(s) for uplink traffic, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, Default Bearer id, APN-AMBR). If the SGSN sent a Create Session Request message the S-GW sends a Create Session Response message with the content as described for the Modify Bearer Response message to the SGSN.