Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.060  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   5…   5.3.8…   5.4…   5.4.2…   5.4.9…   5.6…   5.6.2   5.6.3…   5.6.3.7…   5.7…   6…   6.3…   6.5   6.6…   6.8…   6.9…   6.9.1.3   6.9.2…   6.9.2.2…   6.9.2.2.2   6.9.2.2.3…   6.9.2.2.5…   6.9.3…   6.10…   6.12…   6.13…   6.13.1.2…   6.13.2…   6.13.2.2   6.14…   8…   8.2…   9…   9.2.2…   9.2.2.2   9.2.2.3…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.4.2…   9.2.5…   12…   12.5   12.6   12.7…   12.8…   13…   14…   15…   15.3…   16…   16.2…   A…

 

6.9.2  Location Management Procedures (Iu-mode)Word‑p. 129
In the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when serving an MS in Iu mode.
Refer to TS 25.301 for further information on the location management procedures for the UTRAN.
The PLMN shall provide information for the MS to be able to:
  • detect when it has entered a new cell or a new RA; and
  • determine when to perform periodic RA updates.
In this specification, only the Location Management procedures related to the CN are described. These procedures are:
  • a routeing area update procedure; and
  • Serving RNC relocation procedure.
An MS detects entering a new cell by comparing the cell's identity with the cell identity stored in the MS. By comparing the RAI stored in the MS's MM context with the RAI received from the network, the MS detects that an RA update shall be performed. In RRC CONNECTED mode (PMM CONNECTED state or CS MM CONNECTED state), the MS is informed of RAI and Cell Identity by the serving RNC via an "MM information" message at the RRC layer. In RRC IDLE state, the MS is informed of RAI and Cell Identity by the broadcast system information at the RRC layer.
If the MS enters a new PLMN, the MS shall perform a routeing area update, unless it is not allowed to do so for the reasons specified in TS 24.008 and TS 23.122, or it is an MS configured to perform Attach with IMSI at PLMN change.
In network mode of operation II, whenever an MS that needs only PS and NAS based SMS services determines that it shall perform both an LA update/IMSI attach and an RA update/GPRS attach, the MS shall complete the RA update / GPRS attach first before initiating the LA update/ IMSI attach. If the GPRS Attach or RA update procedure indicates that NAS based SMS is supported by the PS domain, such an MS determines that no LA update / IMSI Attach is required.
In network mode of operation II, whenever an MS that needs PS services and CS services other than NAS based SMS determines that it shall perform both an LA update and an RA update, the MS shall start the LA update first. The MS should start the RA update procedure before the LA update is completed.
Up

6.9.2.1  Routeing Area Update ProcedureWord‑p. 130
A Routeing Area Update takes place when an attached MS detects:
  • that it has entered a new RA (except for the case of an MS configured to perform GPRS Attach with IMSI when entering an RA in a new non-equivalent PLMN in RRC-IDLE mode, in which case, a GPRS Attach shall be performed);
  • when the periodic RA update timer has expired;
  • when RRC connection is released with cause "Directed Signalling connection re-establishment";
  • when the MS has to indicate changed access capabilities or new DRX parameters to the network;
  • when a change in conditions in the MS require a change in the extended idle mode DRX parameters previously negotiated with the SGSN.
  • for a UE supporting CS fallback, or configured to support IMS voice, or both, a change of the UE's usage setting or voice domain preference for E-UTRAN;
  • for an SR-VCC capable MS, the MS has changed its MS Classmark 2, or MS Classmark 3, or Supported Codec information;
  • when the MS reselects GERAN/UTRAN with the TIN indicating "GUTI";
  • the RRC layer in an E-UTRAN capable UE informs the UE's NAS layer that an RRC connection failure occurred in E-UTRAN and this led the MS to select a GERAN/UTRAN cell;
  • that it has manually selected a CSG cell whose CSG ID and associated PLMN is absent from both the MS's Allowed CSG list and the MS's Operator CSG list; or
  • that it is registered for IMS voice and has moved from a RAT that supports IMS voice over PS sessions (see clause 5.3.8 for more information) to one that does not, or vice versa. It shall be possible. using Device Management or initial provisioning to configure the UE to apply/not apply this particular exception.
  • MS receives a paging request from the SGSN while the Mobility Management back off timer is running and the MS's TIN indicates "GUTI".
The SGSN detects that it is an intra-SGSN routeing area update by noticing that it also handles the old RA. In this case, the SGSN has the necessary information about the MS and there is no need to inform the GGSNs or the HLR about the new MS location. A periodic RA update is always an intra-SGSN routeing area update. If the network operates in mode I, an MS that is in CS/PS mode of operation shall perform the Combined RA / LA Update procedures except this CS/PS mode MS is engaged in a CS connection, then it shall perform (non combined) RA Update procedures. When a EPS and IMSI attached MS camps on UTRAN/GERAN and the E-UTRAN periodic TAU timer expires and the TIN indicates "RAT Related TMSI", the MS shall perform combined RA/LA update procedure.
In Iu mode, an RA update is either an intra-SGSN or inter-SGSN RA update, either combined RA / LA update or only RA update, either initiated by an MS in PMM CONNECTED or in PMM IDLE state. The SRNC may provide a PMM-CONNECTED state MS with MM information like RAI by dedicated signalling. Typically, the SRNC should not provide a RAI to an MS in PMM-CONNECTED state. An exception is after an SRNS relocation, in which case the new SRNC shall indicate the RAI to the MS.
During the Routeing Area Update procedure, the MS provides its PS Handover capabilities as defined in TS 24.008.
During the Routeing Area Update procedure, if the SGSN supports SRVCC and if the UE SRVCC capability has changed, it notifies the HSS with the UE SRVCC capability via Update Location Request or Notify Request message, and the HSS stores this information e.g. for further IMS registration.
All the RA update cases are contained in the procedure illustrated in Figure 36.
Figure 36 illustrates mobility between two Gn/Gp SGSNs and mobility from S4-SGSN to Gn/Gp SGSN. The Inter SGSN Routeing Area Update procedure between two S4-SGSNs shows differences for the steps in the boxes (A) and (B). The Inter SGSN Routeing Area Update procedure from Gn/Gp SGSN to S4-SGSN shows differences for the steps in the box (B). These different step descriptions of the boxes are described in clause 6.9.2.1a "Routeing Area Update Procedure using S4".
If SIPTO at the local network is allowed for the APN associated with a PDN connection, and in case of stand-alone GW the Local Home Network ID is not the same, the source SGSN shall trigger the re-establishment of the SIPTO at the Local Network PDN connection as follows:
  • For the intra-SGSN mobility, upon completion of the RAU procedure the SGSN checks that the Local Home Network ID has changed and decides whether to deactivate the SIPTO at the local Network PDN connection with the "reactivation requested" cause value according to clause 9.2.4.2.
  • For the Inter-SGSN mobility, as part of the Routing Area Update procedure the new SGSN checks that the Local Home Network ID has changed and decides whether to deactivate the SIPTO at the Local Network PDN connection with the "reactivation requested" cause value according to clause 9.2.4.2.
If SIPTO at the local network is allowed for the APN associated with a PDN connection, and in case of collocated LGW, the source SGSN shall trigger the re-establishment of the SIPTO at the Local Network PDN connection as follows:
  • For the intra-SGSN mobility, upon completion of the RAU procedure the SGSN shall deactivate the SIPTO at the local Network PDN connection with the "reactivation requested" cause value according to clause 9.2.4.2.
  • For the Inter-SGSN mobility, as part of the Routing Area Update procedure the source SGSN shall not include the bearer(s) corresponding to the SIPTO at the local Network PDN connection into the PDP context and shall release the core network resources associated to the SIPTO at the local network PDN conection by performing the SGSN-initiated PDP Context Deactivation before sending the Context Response.
If LIPA is active for a PDN connection of the MS, the source Gn-SGSN shall not include LIPA bearer(s) in the PDP context during Routing Area Update procedure and shall release the core network resources of the LIPA PDN connections by performing the SGSN-initiated PDP Context Deactivation according to step A of clause 9.2.4.2 subsequent to the completion of the routing area update procedure. If LIPA is active for a PDN connection of the MS, the source S4-SGSN shall release the core network resources of the LIPA PDN connection by performing the SGSN-initiated PDP Context Deactivation according to step A of clause 9.2.4.2 before sending the Context Response.
Reproduction of 3GPP TS 23.060, Figure 36: Iu mode RA Update Procedure
Up
Step 1.
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.
Up

Step 2.
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.
Up

Step 2a.
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".
Up

Step 3.
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.
Up

Step 4.
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.
Up

Step 5.
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.
Up

Step 6.
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.
Up

Step 7.
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.
Up

Step 8.
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.
Up

Step 9.
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.
Up

Step 10.
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.
Up

Step 11.
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).
Up

Step 11a.
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.
Up

Step 12.
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.
Up

Step 13.
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.
Up

Step 14.
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.
Up

Step 15.
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.
Up

Step 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.
Up

Step 17.
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.
Up

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

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

Step 20.
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.
Up

For of a rejected routeing area update operation, due to regional subscription, roaming restrictions, or access restrictions (see clause 5.3.19) the new SGSN should not construct an MM context. In the case of receiving the subscriber data from HLR, the new SGSN may construct an MM context and store the subscriber data for the MS to optimize signalling between the SGSN and the HLR. 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. 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 the new SGSN is unable to update the PDP context/EPS Bearer Context in one or more GGSNs/P-GWs, the new SGSN shall deactivate the corresponding PDP contexts/EPS Bearer Contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update.
The PDP Contexts/EPS Bearer Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context/EPS Bearer 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/EPS Bearer Context for using S4 from the GGSN/P-GW or old S4-SGSN and then store the new Maximum APN restriction value.
If the new SGSN is unable to support the same number of active PDP contexts/EPS Bearer Contexts as received from old SGSN, the new SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts/EPS Bearer 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/P-GWs 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 routeing area update.
If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing Area Update Reject (Cause) message, the MS shall enter PMM DETACHED state.
If the Location Update Accept message indicates a reject, this should be indicated to the MS, and the MS shall not access non-PS services until a successful location update is performed. If SMS-Supported is indicated to the MS the MS should not initiate Location Update or IMSI attach with the MSC for only obtaining SMS services as SMS services via NAS are provided by the SGSN.
The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078:
C1)
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".
C2)
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".
C3)
CAMEL_GPRS_Routeing_Area_Update_Context.
This procedure is called several times: once per PDP context. It returns as result "Continue".
Up

6.9.2.1a  Routeing Area Update Procedure using S4 |R8|Word‑p. 140
The procedures described in figures 36a and 36b show only the steps 2, 3, 5 and 9, due to use of S4, which are different from the Gn/Gp variant of the procedure given by clause 6.9.2.1. The ISR function is deactivated in Inter-SGSN Routeing Area Update Procedures as defined in TS 23.401.
Reproduction of 3GPP TS 23.060, Figure 36a: Step 2, 3 and 5 for Iu Mode Routeing Area Update Procedure between S4-SGSNs
Up
2)
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.
3)
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.
5)
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.
Reproduction of 3GPP TS 23.060, Figure 36b: Step 9 for Iu Mode Routeing Area Update Procedure using S4
Up
9A)
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.
9B)
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.
9C)
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.
9D)
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.
Up


Up   Top   ToC