6.9.2 Location Management Procedures (Iu-mode)
23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS
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 [50] 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 [13] and TS 23.122 [7b], 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.
6.9.2.1 Routeing Area Update Procedure
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.
NOTE 1: A UE moving between RATs that both support IMS voice over PS sessions, or, both that do not support IMS voice over PS sessions, is unaffected by the above.
– 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 [13].
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".
NOTE 2: The network may receive an RA update from a UE in PMM-CONNECTED state over a new Iu signalling connection. This could happen when the UE enters PMM-IDLE state on receipt of RRC Connection Release with cause "Directed Signalling connection re-establishment" and initiates an RA or Combined RA update procedure (see clause 6.1.2.4.1).
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.
NOTE 3: The source S4-SGSN may not be able to release the LIPA PDN connection after the Context Response is sent as the SGW will assign the S4 control plane tunnel of the UE to the new S4-SGSN.
Figure 36: Iu mode RA Update Procedure
NOTE 1: All steps in figure 36, except steps 2, 3, 5 and 9, are common for architecture variants using Gn/Gp based and S4 based SGSNs. For specific interactions with S4 based SGSNs, procedure steps (A) and (B) are defined in the clause 6.9.2.1a.
NOTE 2: For Emergency Attach, an MS which is not successfully authenticated, steps 10, 11, 12, 13 and 14 are not performed.
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 [89]. 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.
NOTE 3: Sending the Routeing Area Update Request message to the SGSN triggers the establishment of a signalling connection between RAN and SGSN for the concerned MS.
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.
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".
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.
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.
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.
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.
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.
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.
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 [89]. 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 [89], 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.
NOTE 4: If the RA update is an Inter-SGSN routeing area update initiated by an MS in PMM‑CONNECTED state in the new 3G-SGSN, the Update PDP Context Request message is sent as described in clause "Serving RNS Relocation Procedures".
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.
NOTE 5: At this step, the SGSN may not have all the information needed to determine the setting of the IMS voice over PS Session Supported indication for this MS (see clause 5.3.8). Hence the SGSN can send the "Homogenous Support of IMS Voice over PS Sessions" later on in this procedure.
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.
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).
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.
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 [83] 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.
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.
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 [83].
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.
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:
a) The new VLR sends an Update Location (new VLR) to the HLR.
b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.
c) The old VLR acknowledges with Cancel Location Ack (IMSI).
d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR.
e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).
f) 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.
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.
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 [83] 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 [89]. 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 [89].
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.
NOTE 6: If the UE receives a RAU Accept message via a hybrid cell, the UE does not add the corresponding CSG ID and associated PLMN to its Allowed CSG list. Adding a CSG ID and associated PLMN to the UE’s local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
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.
18) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the SGSN.
19) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR TMSI.
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.
NOTE 7: Steps 15, 16, and 19 are performed only if step 14 is performed.
NOTE 8: The new SGSN may initiate RAB establishment after execution of the security functions (step 4), or wait until completion of the RA update procedure. For the MS, RAB establishment may occur anytime after the RA update request is sent (step 1).
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 [7b]. 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 [83] 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.
NOTE 9: If the 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".
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 [8b]:
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".
6.9.2.1a Routeing Area Update Procedure using S4
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 [89].
NOTE 1: If the RA update is an Inter-SGSN routeing area update initiated by an MS in PMM CONNECTED state in the new 3G-SGSN, step 9 is described as the step 13 in clause 6.9.2.2.1a.
Figure 36a: Step 2, 3 and 5 for Iu Mode Routeing Area Update Procedure between S4-SGSNs
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.
Figure 36b: Step 9 for Iu Mode Routeing Area Update Procedure using S4
NOTE 2: Steps 9A) and 9D) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (B1) is defined in TS 23.402 [90]. Steps 9B) and 9C) concern GTP based S5/S8.
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 [89].
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.
6.9.2.2 Serving RNS Relocation Procedures
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.
Serving RNS relocation procedures move the RAN to CN connection point at the RAN side of the source RNC to the target RNC. The Serving RNS Relocation Procedures, described in the following clauses, may be performed as "Lossless SRNS Relocation", which means packet loss during the SRNS change is eliminated. For this purpose, the RNS and the MS have to provide PDCP layer functionality, which in the subsequent description is referred as the lossless PDCP. The source RNC decides to perform the Serving RNS Relocation Procedure as "Lossless SRNS Relocation" based on capabilities of the UE and the RNS and based on QoS parameters (e.g. SDU error ratio).
For "Lossless SRNS Relocation", both the MS and the source RNS have to support and to use the lossless PDCP. When the SRNS changes, the old RNS forwards all received and not yet transferred downlink GTP-PDUs to the target RNS. GTP-PDUs forwarded to the target RNS indicate a PDCP sequence number if the contained N-PDUs were sent to the MS as a PDCP-SDUs, but are not yet acknowledged by lossless PDCP. The target RNS and the MS exchange respective sequence numbers of next expected PDCP-PDUs. This process indicates PDCP-PDUs that were already successfully transferred between the MS and the source RNS for downlink and uplink directions, respectively. This also confirms all N-PDUs (PDCP-SDUs) successfully transferred before the change of the SRNS. These N-PDUs are discarded by the MS and the target RNS, respectively. The target RNS identifies the forwarded GTP-PDUs containing confirmed N-PDUs by the PDCP sequence number in the GTP-PDU. All other N-PDUs have to be transmitted via the new MS – RNS link.
For inter-PLMN handover to a CSG cell, if the source SGSN has the CSG-ID list of the target PLMN, the source SGSN shall use it to validate the CSG membership of the MS in the target CSG cell. Otherwise, based on configuration the source SGSN may allow the handover by validating the CSG membership of the MS in the target CSG cell using the CSG-ID list of the registered PLMN-ID.If neither the CSG-ID lists of the target PLMN nor the operator’s configuration permission, the source SGSN shall reject the handover due to no CSG membership information of the target PLMN-ID.
NOTE 1: Inter-PLMN handover to a CSG cell in a PLMN which is not an equivalent PLMN for the UE is not supported.
NOTE 2: Inter-PLMN handover to a CSG cell of an equivalent PLMN is only supported if the CSG-ID of the cell is in the CSG-ID list of both equivalent PLMNs.
6.9.2.2.1 Serving RNS Relocation Procedure
This procedure is only performed for an MS in PMM‑CONNECTED state where the Iur interface carries both the control signalling and the user data. This procedure is not applicable for GERAN.
The Serving SRNS Relocation procedure is used to move the RAN to CN connection point at the RAN side from the source SRNC to the target RNC, from a "standing still position". In the procedure, the Iu links are relocated. If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed. If the routeing area is changed, this procedure is followed by an Intra-SGSN Routeing Area Update procedure. The SGSN detects 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 HLR about new location of the MS.
Figure 37 shows user data routing before SRNS relocation when source SRNC and target RNC are connected to different SGSNs. Figure 38 shows the user data routing after SRNS Relocation procedure and Routeing Area Update procedure is completed. In case depicted in Figure 37 and Figure 38, the MS is in state PMM-CONNECTED.
NOTE 1: The figures showing S‑GW/P‑GW instead of GGSN are omitted since they are similar to figures 37 and 38.
Figure 37: Before SRNS Relocation and Routeing Area Update
Before the SRNS Relocation procedure and RA update, the MS is registered in the old SGSN. The source RNC is acting as a serving RNC (SRNC).
Figure 38: After SRNS Relocation and Routeing Area Update
After the SRNS Relocation procedure and RA update, the MS is registered in the new SGSN. The MS is in the state PMM‑CONNECTED towards the new SGSN, and the target RNC is acting as the serving RNC.
The Serving SRNS Relocation procedure is illustrated in Figure 39. The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation.
Figure 39: SRNS Relocation Procedure
NOTE 2: All steps in figure 39, except steps (A) and 13, are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure steps (A) and (B) are defined in the clause 6.9. 2.2.1a.
1) The source SRNC decides to perform/initiate SRNS relocation. At this point both uplink and downlink user data flows via the following tunnel(s): Radio Bearer between MS and source SRNC (data flows via the target RNC, which acts as a drift RNC); GTP-U tunnel(s) between source SRNC and old-SGSN; GTP-U tunnel(s) between old-SGSN and GGSN. (for using S4: GTP‑U tunnel(s) between old‑SGSN and S‑GW; GTP‑U tunnel(s) between S‑GW and P‑GW)
2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container) to the old SGSN. The source SRNC shall set the Relocation Type to "UE not involved". The Source SRNC to Target RNC Transparent Container includes the necessary information for Relocation co-ordination, security functionality and RRC protocol context information (including MS Capabilities).
3) The old SGSN determines from the Target ID if the SRNS Relocation is intra-SGSN SRNS relocation or inter-SGSN SRNS relocation. The old SGSN selects the target SGSN as described in clause 5.3.7.3 on "SGSN selection function". In case of inter-SGSN SRNS relocation, the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context/EPS Bearer Context, Negotiated Evolved ARP, Target Identification, RAN transparent container, RANAP Cause, GCSI) to the new SGSN. If this message is sent between two S4-SGSNs, the old SGSN shall include APN Restriction and Change Reporting Action in this message. MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old SGSN may – if it provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN will select one of them to become the new SGSN, as specified in TS 23.236 [73].
If at least one of the two SGSNs is a Gn/Gp SGSN then PDP context is indicated. An S4-SGSN derives from GTPv1 Forward Relocation signalling that the other SGSN is a Gn/Gp SGSN, which also does not signal any S‑GW change. The PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data the old SGSN and the new SGSN send uplink packets).
At the same time a timer is started on the MM and PDP contexts/EPS Bearer Contexts in the old SGSN (see the Routeing Area Update procedure in clause "Location Management Procedures (Iu mode)"). The Forward Relocation Request message is applicable only in the case of inter-SGSN SRNS relocation. The old SGSN ‘sets’ the GCSI flag if the MM context contains GPRS CAMEL Subscription Information.
If the UE receives only emergency services from the old SGSN and the UE is UICCless, IMSI can not be included in Forward Relocation Request message. For emergency attached UEs if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated.
If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW the old SGSN shall include the Local Home Network ID of the source cell in the EPS Bearer context corresponding to the SIPTO at the Local Network PDN connection.
4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity (if available), MSISDN, Cause, CN Domain Indicator, Source-RNC to target RNC transparent container, RABs to be setup (APN, Charging characteristics), UE-AMBR, Service Handover related info) to the target RNC. Only the Iu Bearers of the RABs are setup between the target RNC and the new-SGSN as the existing Radio Bearers will be reallocated between the MS and the target RNC when the target RNC takes the role of the serving RNC. For each requested RAB, the RABs to be setup information elements shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. SGSN shall not establish RABs for PDP contexts/EPS Bearer Contexts for using S4 with maximum bit rate for uplink and downlink of 0 kbit/s. . The list of RABs requested by the new SGSN may differ from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent container. The target RNC shall not establish the RABs (as identified from the Source-RNC to target RNC transparent container) that did not exist in the source RNC prior to the relocation. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has received a ‘set’ GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the GGSN’s Address for User Plane and TEID for Uplink data. For using S4, if the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the S‑GW’s Address for User Plane and TEID for Uplink data. If the Access Restriction is present in the MM context, the Service Handover related information shall be included by new S4-SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.
After all necessary resources for accepted RABs including the Iu user plane are successfully allocated; the target RNC shall send the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new SGSN. Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC Address for user data, and an Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. For each RAB to be set up, the target RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN.
5) When resources for the transmission of user data between the target RNC and the new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, RANAP Cause, and RAB Setup Information) is sent from the new SGSN to old SGSN. This message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e. the relocation resource allocation procedure is terminated successfully. RANAP Cause is information from the target RNC to be forwarded to the source SRNC. The RAB Setup Information, one information element for each RAB, contains the RNC Tunnel Endpoint Identifier and the RNC IP address for data forwarding from the source SRNC to the target RNC. If the target RNC or the new SGSN failed to allocate resources, the RAB Setup Information element contains only NSAPI indicating that the source SRNC shall release the resources associated with the NSAPI. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation.
6) The old SGSN continues the relocation of SRNS by sending a Relocation Command message (RABs to be released, and RABs subject to data forwarding) to the source SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. These are the same Transport Layer Address and Iu Transport Association that the target RNC had sent to new SGSN in Relocation Request Acknowledge message, and these are used for forwarding of downlink N‑PDU from source SRNC to target RNC. The source SRNC is now ready to forward downlink user data directly to the target RNC over the Iu interface. This forwarding is performed for downlink user data only.
7) The source SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed at IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target RNC together with their related downlink PDCP sequence numbers. The source RNC continues transmitting duplicates of downlink data and receiving uplink data. Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the related QoS profile.
NOTE 3: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For instance, source RNC may start data forwarding (step 7) and send Relocation Commit message (step 8) almost simultaneously except in the delivery order required case where step 7 triggers step 8. Target RNC may send Relocation Detect message (step 9) and RAN Mobility Information message (step 10) at the same time. Hence, target RNC may receive RAN Mobility Information Confirm message (step 10) while data forwarding (step 7) is still underway, and before the new SGSN receives Update PDP Context Response message (step 11).
8) Before sending the Relocation Commit the uplink and downlink data transfer in the source, SRNC shall be suspended for RABs, which require delivery order. The source RNC shall start the data-forwarding timer. When the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the target RNC over the Iur interface. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role from the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP-PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the MS. For PDP context(s) using delivery order not required (QoS profile), the sequence numbers of the GTP-PDUs next to be transmitted are not used by the target RNC. PDCP sequence numbers are only sent by the source RNC for radio bearers, which used lossless PDCP (see TS 25.323 [57]). The use of lossless PDCP is selected by the RNC when the radio bearer is set up or reconfigured.
If delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context for uplink and downlink, respectively.
9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE not involved", the relocation execution trigger is the reception of the Relocation Commit message from the Iur interface. When the Relocation Detect message is sent, the target RNC shall start SRNC operation.
10) The target SRNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements. The UE information elements include among others new SRNC identity and S‑RNTI. The CN information elements contain among others Location Area Identification and Routeing Area Identification. The procedure shall be co-ordinated in all Iu signalling connections existing for the MS.
The target SRNC establishes and/or restarts the RLC, and exchanges the PDCP sequence numbers (PDCP‑SNU, PDCP‑SND) between the target SRNC and the MS. PDCP‑SND is the PDCP sequence number for the next expected in-sequence downlink packet to be received in the MS per radio bearer, which used lossless PDCP in the source RNC. PDCP‑SND confirms all mobile-terminated packets successfully transferred before the SRNC relocation. If PDCP‑SND confirms reception of packets that were forwarded from the source SRNC, the target SRNC shall discard these packets. PDCP‑SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source RNC. PDCP‑SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If PDCP‑SNU confirms reception of packets that were received in the source SRNC, the MS shall discard these packets.
Upon reception of the RAN Mobility Information message the MS may start sending uplink user data to the target SRNC. When the MS has reconfigured itself, it sends the RAN Mobility Information Confirm message to the target SRNC. This indicates that the MS is also ready to receive downlink data from the target SRNC.
If new the SGSN has already received the Update PDP Context Response message from the GGSN, it shall forward the uplink user data to GGSN over this new GTP-U tunnel. Otherwise, the new SGSN shall forward the uplink user data to that GGSN IP address and TEID(s), which the new SGSN had received earlier by the Forward Relocation Request message.
For using S4, if new the SGSN has already received the Modify Bearer Response message from the S‑GW, it shall forward the uplink user data to S‑GW over this new GTP‑U tunnel. Otherwise, the new SGSN shall forward the uplink user data to that S‑GW IP address and TEID(s), which the new SGSN had received earlier by the Forward Relocation Request message.
For all RABs, the target RNC should:
– start uplink reception of data and start transmission of uplink GTP-PDUs towards the new SGSN;
– start processing the already buffered and the arriving downlink GTP-PDUs and start downlink transmission towards the MS.
11) When the target SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNC—ID + S‑RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate the Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN.
For SIPTO at the Local Network with stand-alone GW architecture, the target RNC shall include the Local Home Network ID of the target cell in the Relocation Complete message.
12) Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message.
13) Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation and the new SGSN has received Forward Relocation Complete Acknowledge message from the old SGSN or if Direct Tunnel was established in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN provides to GGSN the RNC’s Address for User Plane and TEID for Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 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 Forward Relocation Request 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 [89]. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, and Negotiated Evolved ARP) message. 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 [89], 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.
14) Upon receiving the Relocation Complete message or if it is an inter-SGSN SRNS relocation; the Forward Relocation Complete message, the old SGSN sends an Iu Release Command message to the source RNC. When the RNC data-forwarding timer has expired the source RNC responds with an Iu Release Complete.
An old S4-SGSN starts a timer to supervise when resources in old Serving GW (in case of Serving GW change or in case of S4 to Gn/Gp SGSN change) shall be released. When this timer expires the old S4-SGSN releases the S‑GW resources. 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.
15) After the MS has finished the RNTI reallocation procedure and if the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update procedure. See clause "Location Management Procedures (Iu mode)". Note that it is only a subset of the RA update procedure that is performed, since the MS is in PMM‑CONNECTED mode.
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 for using S4 and then store the new Maximum APN restriction value.
If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b]):
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".
If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed.
If Routeing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data.
If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b]):
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"".
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow.
6.9.2.2.1a Serving RNS Relocation Procedure, Combined Hard Handover and SRNS Relocation Procedure, and Combined Cell / URA Update and SRNS Relocation Procedure Using S4
The procedures described in figures 39a and 39b shows only the steps (A) and 13, due to use of S4, which are different from the Gn/Gp variant of the procedure given by clauses 6.9.2.2.1, 6.9.2.2.2 and 6.9.2.2.3.
Figure 39a: Steps 9A) for Serving RNS Relocation Procedure, Combined Hard Handover and SRNS Relocation Procedure, and Combined Cell / URA Update and SRNS Relocation Procedure Using S4
A1. The new S4-SGSN determines if the Serving GW is to be allocated or relocated, e.g., due to PLMN change or due to change from Gn/Gp to S4-SGSN. If a new Serving GW is needed or if the Serving GW changes, the new SGSN selects the new Serving GW as described in TS 23.401 [89] under clause 4.3.8.2 on "Serving GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over S5/S8, APN-AMBR, DTI) to the new Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. SGSN User Plane TEID shall not be sent if the SGSN decides to establish the Direct Tunnel between RNC and Serving GW. DTI is used to instruct the Serving GW that the Direct Tunnel shall be established between RNC and Serving GW.
The new S4-SGSN establishes the EPS Bearer Context(s) in the indicated order. The new S4-SGSN deactivates the PDP Contexts/EPS Bearer Contexts which cannot be established.
For relocation from an old Gn/Gp SGSN, the new S4-SGSN provides APN-AMBR to the Serving GW. Details on mapping of MBR to APN-AMBR are specified in Annex E of TS 23.401 [89].
A2. The new Serving GW allocates its local resources and returns a Create Session Response (Serving GW address(es) for user plane, Serving GW UL TEID(s) for user plane, Serving GW Address for control plane, Serving GW TEID for control plane) message to the new SGSN.
13. Box (B):
Figure 39b: Step 13 for Serving RNS Relocation Procedure, Combined Hard Handover and SRNS Relocation Procedure, and Combined Cell / URA Update and SRNS Relocation Procedure Using S4
NOTE: Steps A) and D) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (B1) are defined in TS 23.402 [90]. Steps B) and C) concern GTP based S5/S8.
A) If the SRNS Relocation is an inter‑SGSN SRNS relocation and the new SGSN received Forward Relocation Complete Acknowledge message from the old SGSN or if Direct Tunnel was established in intra‑SGSN SRNS relocation or the Serving GW is changed, 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) (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic (if Direct Tunnel is used), 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, CGI/SAI, RAT type, MS Info Change Reporting support indication, DTI, APN-AMBR). If Direct Tunnel is established the SGSN shall include the DTI to instruct the S‑GW to apply Direct Tunnel specific error handling procedure as described in clause 13.8. The SGSN puts the according NSAPI in the field of EPS Bearer ID.
For relocation from an old Gn/Gp SGSN, the new S4-SGSN provides APN-AMBR to the Serving GW. Details on mapping of MBR to APN-AMBR are specified in Annex E of TS 23.401 [89].
B) If the S‑GW changes, 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, CGI/SAI, RAT type, MS Info Change Reporting support indication, APN-AMBR) messages to the P‑GWs involved.
C) 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) messages to S‑GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context. The default bearer id is included if the UE moves from a Gn/Gp SGSN to an S4-SGSN.
D) The Serving GW acknowledges the user plane switch 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, Protocol Configuration Options, 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). At this stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC, new SGSN in case Direct Tunnel is not used, Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW.
6.9.2.2.2 Combined Hard Handover and SRNS Relocation Procedure
This procedure is only performed for an MS in PMM‑CONNECTED state in case the Iur interface is not available. In the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when serving a mobile in Iu mode.
The Combined Hard Handover and SRNS Relocation procedure is used to move the RAN to CN connection point at the RAN side from the source SRNC to the target RNC, while performing a hard handover decided by the RAN. In the procedure, the Iu links are relocated. If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed. If the routeing area is changed, this procedure is followed by an Intra-SGSN Routeing Area Update procedure. 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 HLR about the new MS location.
If the target RNC is connected to a different SGSN than the source SRNC, an Inter-SGSN SRNS Relocation procedure is performed. This procedure is followed by an Inter-SGSN Routeing Area Update procedure.
Figure 40 shows the situation before a Combined Hard Handover and SRNS Relocation procedure when source and target RNC are connected to different SGSNs. Figure 41 shows the situation after the Combined Hard Handover and SRNS Relocation procedure and RA update procedure have been completed. In the case described in Figure 40 and Figure 41 the MS is in PMM-CONNECTED state. Both figures are also applicable to BSS to RNS relocation and vice-versa, as well as for BSS to BSS relocation.
NOTE 1: The figures showing S‑GW/P‑GW instead of GGSN are omitted since they are similar with Figures 40 and 41.
Figure 40: Before Combined Hard Handover and SRNS Relocation and Routeing Area Update
Before the SRNS Relocation and Routeing Area Update the MS is registered in the old SGSN and in the old MSC/VLR. The source RNC is acting as serving RNC.
Figure 41: After Combined Hard Handover and SRNS Relocation and Routeing Area Update
After the SRNS relocation and RA update, the MS is registered in the new SGSN and in the new MSC/VLR. The MS is in state PMM‑CONNECTED towards the new SGSN and in MM IDLE state towards the new MSC/VLR. The target RNC is acting as serving RNC.
The Combined Hard Handover and SRNS Relocation procedure for the PS domain is illustrated in Figure 42. The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation. Furthermore, this signalling flow is also applicable for BSS to RNS relocation and vice-versa, as well as BSS to BSS relocation.
Figure 42: Combined Hard Handover and SRNS Relocation Procedure
NOTE 2: All steps in figure 42, except steps (A) and 13, are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure steps (A) and (B) are defined in the clause 6.9. 2.2.1a.
1) Based on measurement results and knowledge of the RAN topology, the source SRNC decides to initiate a combined hard handover and SRNS relocation. At this point both uplink and downlink user data flows via the following tunnel(s): Radio Bearer between the MS and the source SRNC (no drift RNC available); GTP-U tunnel(s) between the source SRNC and the old SGSN; GTP-U tunnel(s) between the old SGSN and the GGSN (for using S4: GTP‑U tunnel(s) between old-SGSN and S‑GW; GTP‑U tunnel(s) between S‑GW and P‑GW).
If the UE has an ongoing emergency bearer service the source SRNC shall not initiate relocation from UTRAN to GERAN.
2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, CSG ID, CSG access mode, Source RNC To Target RNC Transparent Container) to the old SGSN. The source SRNC shall set Relocation Type to "UE Involved". Source RNC To Target RNC Transparent Container includes the necessary information for relocation co‑ordination, security functionality and RRC protocol context information (including MS Capabilities). The source SRNC shall include the CSG ID of the target cell when the target cell is a CSG cell or a hybrid cell. The source SRNC shall indicate the CSG access mode of the target cell when the target cell is a hybrid cell.
3) The old SGSN determines from the Target ID if the SRNS relocation is intra-SGSN SRNS relocation or inter-SGSN SRNS relocation. The old SGSN selects the target SGSN as described in clause 5.3.7.3 on "SGSN selection function". In case of inter-SGSN SRNS relocation the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context/EPS Bearer Context, Negotiated Evolved ARP, Target Identification, CSG ID, CSG Membership Indication, RAN Transparent Container, RANAP Cause, GCSI) to the new SGSN. If this message is sent between two S4-SGSNs then the old SGSN shall include APN restriction and Change Reporting Action in this message. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old SGSN may – if it provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN will select one of them to become the new SGSN, as specified in TS 23.236 [73].
If the CSG ID is provided by the source SRNC, the old SGSN shall check whether the CSG ID is contained in the CSG subscription and is not expired. If the CSG ID is not present or is expired and the target cell is a CSG cell, the old SGSN shall reject the handover with an appropriate cause unless the UE has emergency bearer services.
If the CSG ID was received in the Relocation Required message, the old SGSN includes the CSG ID in the Forward Relocation Request message. If the CSG access mode was received in the Relocation Required message indicating the target cell is a hybrid cell, or if there are one or several emergency bearers and the target cell is a CSG cell, the old SGSN shall include the CSG Membership Indication indicating whether the UE is a CSG member in the Forward Relocation Request message.
If at least one of the two SGSNs is a Gn/Gp SGSN then PDP context is indicated. An S4-SGSN derives from GTPv1 Forward Relocation signalling that the other SGSN is a Gn/Gp SGSN, which also does not signal any S‑GW change. PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the old SGSN and the new SGSN send uplink packets).
Between two S4-SGSNs EPS Bearer Context is indicated. The Bearer context contains S‑GW Address for User Plane and Uplink TEID for Data (to this S‑GW Address and Uplink TEID for Data the old SGSN and the new SGSN send uplink packets) and P‑GW Address for User Plane and Uplink TEID for Data.
At the same time a timer is started on the MM and PDP contexts/EPS Bearer Contexts in the old SGSN (see Routeing Area Update procedure in clause "Location Management Procedures (Iu mode)"). The Forward Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. The old SGSN ‘sets’ the GCSI flag if the MM context contains GPRS CAMEL Subscription Information.
If the UE receives only emergency services from the old SGSN and the UE is UICCless, IMSI can not be included in Forward Relocation Request message. For emergency attached UEs if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated.
If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW the old SGSN shall include the Local Home Network ID of the source cell in the EPS Bearer context corresponding to the SIPTO at the Local Network PDN connection.
4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity (if available), MSISDN, Cause, CN Domain Indicator, CSG ID, CSG Membership Indication, Source RNC To Target RNC Transparent Container, RAB To Be Setup (APN, Charging characteristics), UE-AMBR, Service Handover related information) to the target RNC. For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. SGSN shall not establish RABs for PDP contexts with maximum bit rate for uplink and downlink of 0 kbit/s. The list of RABs requested by the new SGSN may differ from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent container. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC transparent container) that did not exist in the source RNC prior to the relocation. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has received a ‘set’ GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the GGSN’s Address for User Plane and TEID for Uplink data. For using S4, if the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the S‑GW’s Address for User Plane and TEID for Uplink data. If the Access Restriction is present in the MM context, the Service Handover related information shall be included by new S4-SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.
The new SGSN shall include the CSG ID and CSG Membership Indication when provided by the old SGSN in the Forward Relocation Request message.
The target RNC shall verify the CSG ID provided by the source SRNC, and reject the handover with an appropriate cause if it does not match the CSG ID and the target cell is a CSG cell. If the target cell is a hybrid cell and differentiated treatment of CSG and non-CSG members is performed then the CSG membership status is used to differentiate CSG and non-CSG members. If the target cell is a CSG cell, and if the CSG Membership Indication is "non member", the target RNC only accepts the emergency bearers.
After all the necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. The transparent container contains all radio-related information that the MS needs for the handover, i.e., a complete RRC message (e.g., Physical Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN Iu mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN.
5) When resources for the transmission of user data between target RNC and new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response (Cause, RAN Transparent Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation.
6) The old SGSN continues the relocation of SRNS by sending a Relocation Command message (Target RNC To Source RNC Transparent Container, RABs To Be Released, RABs Subject To Data Forwarding) to the source SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. These are the same Transport Layer Address and Iu Transport Association that the target RNC had sent to new SGSN in Relocation Request Acknowledge message, and these are used for forwarding of downlink N‑PDU from the source SRNC to the target RNC. The source SRNC is now ready to forward downlink user data directly to the target RNC over the Iu interface. This forwarding is performed for downlink user data only.
7) The source SRNC may, according to the QoS profile, begins the forwarding of data for the RABs to be subject for data forwarding.
NOTE 3: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For instance, source RNC may start data forwarding (step 7), send the RRC message to MS (step 8) and forward SRNS Context message to the old SGSN (step 9) almost simultaneously.
The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the GTP-PDUs exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed at the IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target RNC together with their related downlink PDCP sequence numbers. The source RNC continues transmitting duplicates of downlink data and receiving uplink data.
Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the related QoS profile.
8) Before sending the RRC message the uplink and downlink data transfer shall be suspended in the source SRNC for RABs, which require delivery order. The RRC message is for example Physical Channel Reconfiguration for RNS to RNS relocation, or Intersystem to UTRAN Handover for BSS to RNS relocation, or Handover from UTRAN Command for BSS relocation, or Handover Command for BSS to BSS relocation. When the source SRNC is ready, the source RNC shall trigger the execution of relocation of SRNS by sending to the MS the RRC message provided in the Target RNC to source RNC transparent container, e.g., a Physical Channel Reconfiguration (UE Information Elements, CN Information Elements) message. UE Information Elements include among others new SRNC identity and S‑RNTI. CN Information Elements contain among others Location Area Identification and Routeing Area Identification.
When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration Complete message to the target SRNC. If the Forward SRNS Context message with the sequence numbers is received, the exchange of packets with the MS may start. If this message is not yet received, the target RNC may start the packet transfer for all RABs, which do not require maintaining the delivery order.
9) The source SRNC continues the execution of relocation of SRNS by sending a Forward SRNS Context (RAB Contexts) message to the target RNC via the old and the new SGSN. The Forward SRNS Context message is acknowledged by a Forward SRNS Context Acknowledge message, from new to old SGSN. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role from the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the MS. PDCP sequence numbers are only sent by the source RNC for the radio bearers which used lossless PDCP (see TS 25.323 [57]). The use of lossless PDCP is selected by the RNC when the radio bearer is set up or reconfigured.
When using Gn/Gp, for PDP context(s) using delivery order not required (QoS profile), the sequence numbers of the GTP-PDUs next to be transmitted are not used by the target RNC.
When using Gn/Gp, if delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, respectively.
The target RNC establishes and/or restarts the RLC and exchanges the PDCP sequence numbers (PDCP‑SNU, PDCP‑SND) between the target RNC and the MS. PDCP‑SND is the PDCP sequence number for the next expected in-sequence downlink packet to be received by the MS per radio bearer, which used lossless PDCP in the source RNC. PDCP‑SND confirms all mobile terminated packets successfully transferred before the SRNC relocation. If PDCP‑SND confirms reception of packets that were forwarded from the source SRNC, then the target SRNC shall discard these packets. PDCP‑SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source RNC. PDCP‑SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If PDCP‑SNU confirms reception of packets that were received in the source SRNC, the MS shall discard these packets.
10) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the Uu interface; i.e., when target RNC detects the MS on the lower layers. When the Relocation Detect message is sent, the target RNC shall start SRNC operation.
11) When the target SRNC receives the appropriate RRC message, e.g. Physical Channel Reconfiguration Complete message or the Radio Bearer Release Complete message in UTRAN case, or the Handover To UTRAN Complete message or Handover Complete message in GERAN case, i.e. the new SRNC‑ID + S‑RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate a Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN.
For SIPTO at the Local Network with stand-alone GW architecture, the target RNC shall include the Local Home Network ID of the target cell in the Relocation Complete message.
12) Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message.
13) Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation and the new SGSN received Forward Relocation Complete Acknowledge message from the old SGSN or if Direct Tunnel was established in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN provides to GGSN the RNC’s Address for User Plane and TEID for Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 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 Forward Relocation Request 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 [89]. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. 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 [89], 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.
14) Upon receiving the Relocation Complete message or, if it is an inter-SGSN SRNS relocation, the Forward Relocation Complete message, the old SGSN sends an Iu Release Command message to the source RNC. When the RNC data-forwarding timer has expired, the source RNC responds with an Iu Release Complete message.
An old S4-SGSN starts a timer to supervise when resources in old Serving GW (in case of Serving GW change or in case of S4 to Gn/Gp SGSN change) shall be released. When this timer expires the old S4-SGSN releases the S‑GW resources. 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.
15) After the MS has finished the reconfiguration procedure and if the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update procedure. See clause "Location Management Procedures (Iu mode)". Note that it is only a subset of the RA update procedure that is performed, since the MS is in PMM‑CONNECTED state.
If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b])
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".
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 for using S4 and then store the new Maximum APN restriction value.
If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed.
If Routeing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data.
If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b]):
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. In Figure 42, 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".
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow.
6.9.2.2.3 Combined Cell / URA Update and SRNS Relocation Procedure
This procedure is only performed for an MS in PMM‑CONNECTED state, where the Iur/Iur-g interface carries control signalling but no user data 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.
The Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS Relocation procedure is used to move the RAN to CN connection point at the RAN side from the source SRNC to the target RNC, while performing a cell re-selection in the RAN. In the procedure, the Iu links are relocated. If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed. If the routeing area is changed, this procedure is followed by an Intra-SGSN Routeing Area Update procedure. 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 HLR about the new MS location.
Before the Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS Relocation and before the Routeing Area Update, the MS is registered in the old SGSN. The source RNC is acting as serving RNC or serving BSS.
After the Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS Relocation and after the Routeing Area Update, the MS is registered in the new SGSN. The MS is in state PMM‑CONNECTED towards the new SGSN, and the target RNC is acting as serving RNC.
The Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS relocation procedure for the PS domain is illustrated in Figure 43. The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation. This signalling flow is also applicable to BSS to RNS relocation and vice-versa, as well as for BSS to BSS relocation.
Figure 43: Combined Cell / URA Update and SRNS Relocation Procedure
NOTE 1: All steps in figure 43, except steps (A) and 13, are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure steps (A) and (B) are defined in clause 6.9.2.2.1a.
1) The MS sends a Cell Update / URA Update or a Cell Update / GRA Update message to the source SRNC (if the cell is located under another RNC the message is routed via the DRNC to SRNC over the Iur). The source SRNC decides whether or not to perform a combined cell / URA update and SRNS relocation towards the target RNC. The rest of this clause describes the case where a combined cell / URA update and SRNS relocation applies. In this case no radio bearer is established between the source SRNC and the UE. Nonetheless the following tunnel(s) are established: GTP-U tunnel(s) between source SRNC and old-SGSN; GTP-U tunnel(s) between old-SGSN and GGSN (for using S4: GTP‑U tunnel(s) between old-SGSN and S‑GW; GTP‑U tunnel(s) between S‑GW and P‑GW).
If the UE has an ongoing emergency bearer service the source SRNC shall not initiate relocation from UTRAN to GERAN.
2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to Target RNC Transparent Container) to the old SGSN. The source SRNC shall set Relocation Type to "UE not involved". Source RNC to Target RNC Transparent Container includes the necessary information for Relocation co-ordination, security functionality, and RRC protocol context information (including MS Capabilities).
3) The old SGSN determines from the Target ID if the SRNS Relocation is intra-SGSN SRNS relocation or inter-SGSN SRNS relocation. The old SGSN selects the target SGSN as described in clause 5.3.7.3 on "SGSN selection function". In the case of inter-SGSN SRNS relocation the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context/EPS Bearer Context, Negotiated Evolved ARP, Target Identification, RAN Transparent Container, RANAP Cause, GCSI) message to the new SGSN. If this message is sent between two S4-SGSNs then the old SGSN shall include APN restriction and Change Reporting Action in this message. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old SGSN may – if it provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN will select one of them to become the new SGSN, as specified in TS 23.236 [73].
If at least one of the two SGSNs is a Gn/Gp SGSN then PDP context is indicated. An S4-SGSN derives from GTPv1 Forward Relocation signalling that the other SGSN is a Gn/Gp SGSN, which also does not signal any S‑GW change. PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the old SGSN and the new SGSN send uplink packets).
Between two S4-SGSNs EPS Bearer Context is indicated. The Bearer context contains S‑GW Address for User Plane and Uplink TEID for Data (to this S‑GW Address and Uplink TEID for Data the old SGSN and the new SGSN send uplink packets) and P‑GW Address for User Plane and Uplink TEID for Data.
At the same time a timer is started on the MM and PDP contexts/EPS Bearer Context in the old SGSN, see Routeing Area Update procedure in clause "Location Management Procedures (Iu mode)". The Forward Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. The old SGSN ‘sets’ the GCSI flag if the MM context contains GPRS CAMEL subscription information.
If the UE receives only emergency services from the old SGSN and the UE is UICCless, IMSI can not be included in Forward Relocation Request message. For emergency attached UEs if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated.
If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW the old SGSN shall include the Local Home Network ID of the source cell in the EPS Bearer context corresponding to the SIPTO at the Local Network PDN connection.
4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity (if available), MSISDN, Cause, CN Domain Indicator, Source RNC to Target RNC Transparent Container, RABs To Be Setup (APN, Charging characteristics), UE-AMBR, Service Handover related information) to the target RNC. For each requested RAB, RABs To Be Setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. SGSN shall not establish RABs for PDP contexts with maximum bit rate for uplink and downlink of 0 kbit/s. The list of RABs requested by the SGSN may differ from list of RABs available in the Source RNC. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC transparent container) that did not exist in the source RNC prior to the relocation. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has received a ‘set’ GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the GGSN’s Address for User Plane and TEID for Uplink data. For using S4, if the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the S‑GW’s Address for User Plane and TEID for Uplink data. If the Access Restriction is present in the MM context, the Service Handover related information shall be included by new S4-SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.
After all necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new SGSN. Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC Address for user data, and a Iu Transport Association which corresponds to the downlink Tunnel Endpoint Identifier for user data.
After the new SGSN receives the Relocation Request Acknowledge message, the GTP-U tunnels are established between the target RNC and the new-SGSN.
The target-RNC may simultaneously receive for each RAB to be set up downlink user packets both from the source SRNC and from the new SGSN.
5) When resources for the transmission of user data between the target RNC and the new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, RANAP Cause, and Target RNC Information) is sent from the new SGSN to the old SGSN. This message indicates that the target RNC is ready to receive from the source SRNC the forwarded downlink packets, i.e., the relocation resource allocation procedure is terminated successfully. RANAP Cause is information from the target RNC to be forwarded to the source SRNC. The RAB Setup Information, one information element for each RAB, contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from the source SRNC to the target RNC. If the target RNC or the new SGSN failed to allocate resources, the RAB Setup Information element contains only NSAPI indicating that the source SRNC shall release the resources associated with the NSAPI. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation.
6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs to be released, and RABs subject to data forwarding) message to the source SRNC. The old SGSN decides the RABs subject to data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. These are the same Transport Layer Address and Iu Transport Association that the target RNC had sent to new SGSN in Relocation Request Acknowledge message, and these are used for forwarding of downlink N‑PDU from the source SRNC to the target RNC. The source SRNC is now ready to forward downlink data directly to the target RNC over the Iu interface. This forwarding is performed for downlink user data only.
7) The source SRNC may, according to the QoS profile, begin the forwarding of data for the RABs subject to data forwarding and starts the data-forwarding timer. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed at the IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target RNC together with their related downlink PDCP sequence numbers. The source RNC continues transmitting duplicates of downlink data and receiving uplink data.
NOTE 2: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For instance, source RNC may send data forwarding (step 7) and start Relocation Commit message (step 8) almost simultaneously. Target RNC may send Relocation Detect message (step 9) and Cell Update Confirm/URA Update Confirm (or Cell Update Confirm/GRA Update Confirm) message (step 10) at the same time. Hence, target RNC may receive the UTRAN or GERAN Mobility Information Confirm message from MS (step 10) while data forwarding (step 8) is still underway, and before the new SGSN receives Update PDP Context Response message (step 11).
Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the related QoS profile.
8) Before sending the Relocation Commit the uplink and downlink data transfer in the source, SRNC shall be suspended for RABs, which require delivery order.
When the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the target RNC over the UTRAN Iur interface or over the GERAN Iur-g interface, respectively. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role from the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP‑PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the MS. . PDCP sequence numbers are only sent by the source RNC for radio bearers, which used lossless PDCP (see TS 25.323 [57]). The use of lossless PDCP is selected by the RNC when the radio bearer is set up or reconfigured. For PDP context(s) using delivery order not required (QoS profile), the sequence numbers of the GTP-PDUs next to be transmitted are not used by the target RNC.
If delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context for uplink and downlink respectively.
9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE not involved", the relocation execution trigger is the reception of the Relocation Commit message from the Iur interface. When the Relocation Detect message is sent, the target RNC shall start SRNC operation.
10) The target SRNC sends a Cell Update Confirm / URA Update Confirm or Cell Update Confirm / GRA Update Confirm message. This message contains UE information elements and CN information elements. The UE information elements include among others new SRNC identity and S‑RNTI. The CN information elements contain among others Location Area Identification and Routeing Area Identification. The procedure shall be co-ordinated in all Iu signalling connections existing for the MS.
Upon reception of the Cell Update Confirm / URA Update Confirm or Cell Update Confirm / GRA Update Confirm message the MS may start sending uplink user data to the target SRNC. When the MS has reconfigured itself, it sends the RAN Mobility Information Confirm message to the target SRNC. This indicates that the MS is also ready to receive downlink data from the target SRNC.
If the new SGSN has already received the Update PDP Context Response message from the GGSN, it shall forward the uplink user data to the GGSN over this new GTP-U tunnel. Otherwise, the new SGSN shall forward the uplink user data to that GGSN IP address and TEID(s), which the new SGSN had received earlier by the Forward Relocation Request message.
For using S4, if new the SGSN has already received the Modify Bearer Context Response message from the S‑GW, it shall forward the uplink user data to S‑GW over this new GTP‑U tunnel. Otherwise, the new SGSN shall forward the uplink user data to that S‑GW IP address and TEID(s), which the new SGSN had received earlier by the Forward Relocation Request message.
The target SRNC and the MS exchange the PDCP sequence numbers; PDCP‑SNU and PDCP‑SND. PDCP‑SND is the PDCP sequence number for the next expected in-sequence downlink packet to be received in the MS per radio bearer, which used lossless PDCP in the source RNC. PDCP‑SND confirms all mobile terminated packets successfully transferred before the SRNC relocation procedure. . If PDCP‑SND confirms the reception of packets that were forwarded from the source SRNC, the target SRNC shall discard these packets. PDCP‑SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source RNC. PDCP‑SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If PDCP‑SNU confirms reception of packets that were received in the source SRNC, the target SRNC shall discard these packets.
11) When the target SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNC‑ID + S‑RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate the Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN.
For SIPTO at the Local Network with stand-alone GW architecture, the target RNC shall include the Local Home Network ID of the target cell in the Relocation Complete message.
12) Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message.
13) Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation and the new SGSN received Forward Relocation Complete Acknowledge message from the old SGSN or if Direct Tunnel was established in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN provides to GGSN the RNC’s Address for User Plane and TEID for Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 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 Forward Relocation Request 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 [89]. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. 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 [89], 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.
14) Upon receiving the Relocation Complete message or if it is an inter-SGSN SRNS relocation, the Forward Relocation Complete message, the old SGSN sends an Iu Release Command message to the source RNC. When the RNC data-forwarding timer has expired the source RNC responds with an Iu Release Complete.
An old S4-SGSN starts a timer to supervise when resources in old Serving GW (in case of Serving GW change or in case of S4 to Gn/Gp SGSN change) shall be released. When this timer expires the old S4-SGSN releases the S‑GW resources. 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.
15) After the MS has finished the Cell / URA update or the Cell / GRA update and RNTI reallocation procedure and if the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update procedure. See clause "Location Management Procedures (Iu mode)". Note that it is only a subset of the RA update procedure that is performed, since the MS is in PMM‑CONNECTED state.
If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b])
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".
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 SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed.
If Routeing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received GPRS CAMEL Subscription Information. If Direct Tunnel, can not be maintained the SGSN shall re-establish RABs and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data.
If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b]):
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/EPS Bearer Context for using S4. It returns as result "Continue". For C2 and C3: refer to Routing Area Update procedure description for detailed message flow.
6.9.2.2.4 SRNS Relocation Cancel Procedure
The purpose of the SRNS Relocation Cancel procedure is to cancel an ongoing SRNS relocation. The SRNS Relocation Cancel procedure may be initiated during or after the Relocation Preparation procedure and may be initiated by the source RNC.
The SRNS Relocation Cancel procedure is illustrated in Figure 44. The sequence is valid for cancelling both an intra-SGSN SRNS relocation and an inter-SGSN SRNS relocation.
Figure 44: SRNS Cancel Relocation Procedure
NOTE: All steps in figure 44, except steps (A), are common for architecture variants using Gn/Gp based SGSN and using S4 based interaction with S‑GW. For an S4 based interaction with S‑GW, procedure steps (A) are defined in the clause 6.9.2.2.4a.
1) An SRNS Relocation procedure has started, as specified in clause 6.9.2.2.1.
2a) The SRNS Cancel Relocation may be initiated by a timer expiry or by an error event in the source RNC.
2b) When one of conditions in 2a is satisfied, the source RNC sends a Relocation Cancel (Cause) to the old SGSN. Cause indicates the reason for cancelling the ongoing SRNS relocation.
3) The old SGSN sends a Relocation Cancel Request (RANAP Cause) to the new SGSN to indicate that the ongoing SRNS relocation should be cancelled. RANAP Cause contains the cause value received by the source RNC in the Relocation Cancel message.
4) The new SGSN sends an Iu Release Command (Cause) to request from the target RNC to release the Iu resources already allocated for the SRNS relocation, or to cancel the ongoing allocation of Iu resources for the SRNS relocation. Cause is set equal to RANAP Cause, i.e. to whatever cause value was included in the Relocation Cancel Request received from old SGSN. The target RNC releases the requested Iu resources and responds with an Iu Release Complete.
5) The new SGSN acknowledges the cancellation of the ongoing SRNS Relocation by sending a Relocation Cancel Response to the old SGSN.
6) The old SGSN responds to the source RNC with a Relocation Cancel Ack message.
If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced procedures in TS 23.078 [8b]):
C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification.
They are called in the following order:
– The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called. The procedure returns as result "Continue".
– Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue".
C3) CAMEL_GPRS_Routeing_Area_Update_Context.
The procedure is called several times: once per PDP context. It returns as result "Continue".
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow.
6.9.2.2.4a SRNS Relocation Cancel Procedure Using S4
The procedures described in figures 44a shows only the steps (A) due to use of S4, which are different from the Gn/Gp variant of the procedure given by clauses 6.9.2.2.4.
Figure 44a1: A) for SRNS Relocation Cancel Procedure Using S4
A1. This step is only performed in case of handover from S4-SGSN to S4-SGSN with Serving GW relocation or handover from Gn/Gp SGSN to S4-SGSN. The New S4-SGSN deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the New S‑GW.
A2. The New S‑GW acknowledges with Delete Session Response messages.
6.9.2.2.5 Enhanced Serving RNS Relocation Procedure
The procedure can be used for relocation when source SRNC and target RNC are connected to same SGSN.
NOTE 1: If the MS is both MM-CONNECTED and PMM-CONNECTED, then this procedure can only be used if the source RNC and target RNC are connected to same MSC.
This procedure is only performed for an MS in PMM CONNECTED state where the Iur interface is available between a serving RNC and a drifting RNC. This procedure is not applicable for GERAN.
In Enhanced Serving RNS Relocation the SRNS functionality is prepared at RAN side and the SGSN is not informed until the preparation and execution of the relocation has taken place, the preparation and execution phases are performed as specified in TS 25.423 [95]. The completion phase is illustrated in Figure 44a below.
Figure 44a2: Enhanced Serving RNS Relocation
NOTE 2: The figure shows the user plane connections when Direct Tunnel is established. If Direct Tunnel is not established only the user plane between RNC and SGSN is impacted due relocation.
There are three phases for the Enhanced Serving RNS Relocation.
Preparation Phase:
– The Source RNC decides to relocate the UE to a neighbouring RNC (Target RNC).
– The Source RNC triggers the RNSAP: Enhanced Relocation procedure.
Execution Phase:
– The RNC triggers the relocation to MS.
– The Source RNC may start data forwarding.
Completion Phase:
1. The MS has been relocated to the Target RNC.
2. The Target RNC sends Enhanced Relocation Complete Request message to the SGSN to indicate that the MS was relocated to the Target RNC. The Target RNC indicates successfully relocated, modified or released RABs to the SGSN.
For SIPTO at the Local Network with stand-alone GW architecture, the target RNC shall include the Local Home Network ID of the target cell in the Enhanced Relocation Complete Request message.
3. Upon receipt of the enhanced Relocation Complete message, the SGSN shall switch the user plane from the source RNC to the target SRNC. If Direct Tunnel was established, the SGSN sends Update PDP Context Request messages (SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN provides to GGSN the RNC’s Address for User Plane and TEID for Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. NRSN indicates SGSN support of the network requested bearer control. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. 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 [89], 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.
For an S4 based interaction with S‑GW and P‑GW procedure step (A) is defined in clause 6.9.2.2.5A.
4. The SGSN configures the necessary Iu resources for the Target RNC and responds with Enhanced Relocation Complete Response.
5. After sending the Enhanced Relocation Complete Response message to the Target RNC the SGSN sends an Iu Release Command message to the source RNC and the source RNC responds with an Iu Release Complete.
6. If the Routeing Area Identification is different from the old one the MS initiates the Routeing Update procedure. See clause 6.9.2. Like after the relocation procedures described in clauses above e.g. clause 6.9.2.2.1, only a subset of the RA update is performed, since the MS is in PMM-CONNECTED state.
6.9.2.2.5A Enhanced Serving RNS Relocation Procedure using S4
Two procedures are defined depending on whether the Serving GW is unchanged or relocated, figures 44b and 44c show only the steps 3 and 4 due to use of S4, which is different from the Gn/Gp variant defined in clause 6.9.2.2.5.
A1) Procedure using S4 without Serving GW relocation
Figure 44b1: Step 3 for Enhanced Serving RNS Relocation without Serving GW relocation using S4
NOTE 1: Steps A) and B) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8.
A) If Direct Tunnel was established the 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) (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic (if Direct Tunnel is used), 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, CGI/SAI, RAT type, MS Info Change Reporting support indication, DTI). If Direct Tunnel is established the SGSN shall include the DTI to instruct the S‑GW to apply Direct Tunnel specific error handling procedure as described in clause 13.8. The SGSN puts the according NSAPI in the field of EPS Bearer ID.
B) If MS Info Change Reporting is started, the S‑GW sends Modify Bearer Request (EPS Bearer ID(s), serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication) messages to the P‑GWs involved.
C) The P‑GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) messages to S‑GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context.
D) The Serving GW acknowledges the user plane switch to the SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, 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). At this stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC, SGSN in case Direct Tunnel is not used, Serving GW and PDN GW.
A2) Procedure using S4 with Serving GW relocation and Direct Tunnel
This procedure is used if the SGSN determines the Serving Gateway is to be relocated.
Figure 44b2: Step 3 for Enhanced Serving RNS Relocation with Serving GW relocation using S4
NOTE 2: Steps A) and B) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8.
A) The SGSN selects the new Serving GW as described in TS 23.401 [89] under clause 4.3.8.2 on "Serving GW selection function", and sends a Create Session Request message (SGSN Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control Plane, SGSN Address(es) and TEID(s) (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic (if Direct Tunnel is used), 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, CGI/SAI, RAT type, MS Info Change Reporting support indication, DTI). If Direct Tunnel is established the SGSN shall include the DTI to instruct the S‑GW to apply Direct Tunnel specific error handling procedure as described in clause 13.8.
B) The new S‑GW sends Modify Bearer Request (EPS Bearer ID(s), serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication) messages to the P‑GWs involved.
C) The P‑GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) messages to new S‑GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context.
D) The new Serving GW acknowledges the user plane switch to the SGSN via the message Create Session Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, 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). The SGSN starts timer, to be used in step F.
E) The SGSN configures the necessary Iu resources for the Target RNC and responds with Enhanced Relocation Complete Response. The SGSN provides to the target RNC the new S‑GW’s Address for user Plane and TEID(s) for Uplink data. The target RNC starts using the new Serving GW address and TEID(s) for forwarding subsequent uplink packets.
F) When the timer has expired after step D, the SGSN releases the bearer(s) in old S‑GW by sending a Delete Session Request message.
G) The old S‑GW acknowledge bearer deletion.