Content for  TS 23.060  Word version:  18.0.0

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.

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.

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

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.

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.

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.

The source SRNC may, according to the QoS profile, begins 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 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.

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.

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

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.

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.

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

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.

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. In Figure 42, 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.