Content for  TS 23.060  Word version:  18.0.0

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.

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).

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

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.

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.

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.

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

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). 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.

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.

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.

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.

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.

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. 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, 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.

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.

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.

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

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

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

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

CAMEL_GPRS_Routeing_Area_Update_Context.

An SRNS Relocation procedure has started, as specified in clause 6.9.2.2.1.

The SRNS Cancel Relocation may be initiated by a timer expiry or by an error event in the source RNC.

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.

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.

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.

The new SGSN acknowledges the cancellation of the ongoing SRNS Relocation by sending a Relocation Cancel Response to the old SGSN.

The old SGSN responds to the source RNC with a Relocation Cancel Ack message.

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".

CAMEL_GPRS_Routeing_Area_Update_Context.

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.

The New S-GW acknowledges with Delete Session Response messages.