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.
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.
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.
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 184.108.40.206 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.
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):
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):
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 220.127.116.11.1, 18.104.22.168.2 and 22.214.171.124.3.
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, clause 126.96.36.199 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.
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.
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.
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.
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.