Content for  TS 23.060  Word version:  18.0.0

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)

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

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

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.

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.

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.

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.

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

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

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

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.

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 clause 4.3.8.2 of TS 23.401 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.

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.

Box (B):