6.13 Intersystem Change

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

An intersystem change takes place when an MS changes between Iu mode and A/Gb mode of operation by the Routeing Area Update procedure or by PS handover. A prerequisite for an intersystem change is that the MS is GPRS-attached. The transition of the mobility management states is as specified for the corresponding mobility management procedures.

There is no transition of the session management states at an intersystem change.

6.13.1 Intra SGSN Intersystem Change

An SGSN that supports both the Gb and Iu‑PS interfaces may support an intra-SGSN intersystem change if the radio access technology nodes serving the MS before and after the intersystem change are both served by this SGSN.

6.13.1.1 Iu mode to A/Gb mode Intra SGSN Change

6.13.1.1.1 Iu mode to A/Gb mode Intra SGSN Change using Gn/Gp

The intersystem change from Iu mode to A/Gb mode takes place when an MS changes from UTRAN or GERAN Iu mode to A/Gb mode. Depending on the PMM state before the intersystem change and whether the RA is changed or not, one of the following procedures is initiated by the MS:

– When an MS in PMM‑IDLE state changes to the A/Gb mode without changing the RA, the MS shall follow the selective RA update procedures, see clause "Selective RA Update".

– When an MS in PMM‑IDLE state changes to the A/Gb mode and the RA changes, the MS shall initiate the GPRS RA update procedure, see clause "Intra SGSN Routeing Area Update".

– When an MS in PMM‑CONNECTED state changes to the A/Gb mode, the MS shall initiate the GPRS RA update procedure independent of whether the RA has changed or not. The RA update procedure is either combined RA / LA update or only RA update.

A combined RA / LA update takes place in network operation mode I when the MS enters a new RA or when a GPRS-attached MS performs IMSI attach. The MS sends a Routeing Area Update Request message indicating that an LA update may also need to be performed, in which case the SGSN forwards the LA update to the VLR. This concerns only idle mode (see TS 23.122 [7b]), as no combined RA / LA updates are performed during a CS connection. 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.

Figure 52: Iu mode to A/Gb mode Intra SGSN Change

NOTE: All steps in figure 52 are common for architecture variants using Gn/Gp based interaction with a GGSN and using S4 based interactions with an S‑GW and P‑GW. For S4 based interaction with an S‑GW and P‑GW, procedure step (A) is defined in clause 6.13.1.1.2.

1) The MS or RAN decides to perform an intersystem change which makes the MS switch to a new cell where A/Gb mode has to be used, and stops transmission to the network.

2) The MS sends a Routeing Area Update Request (old RAI, old P‑TMSI Signature, Update Type, Voice domain preference and UE’s usage setting) message to the 2G+3G‑SGSN. Update Type shall indicate RA update or combined RA / LA-update or, if the MS wants to perform an IMSI attach, combined RA / LA update with IMSI attached requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before passing the message to the 2G+3G‑SGSN. The UE sets the voice domain preference and UE’s usage setting according to its configuration, as described in clause 5.3.15.

If there is an ongoing emergency bearer service and a Routing Area Update Request is received the Routing Area Update shall be rejected with a cause code indicating that access to GERAN is not allowed.

3) If the MS is PMM‑CONNECTED state, the 2G+3G‑SGSN sends an SRNS Context Request (IMSI) message to the SRNS.

Upon reception of the SRNS Context Request message, the SRNS starts buffering and stops sending downlink PDUs to the MS. The SRNS responds with an SRNS Context Response (GTP‑SNDs, GTP‑SNUs, PDCP-SNDs, PDCP‑SNUs) message. The GTP sequence numbers are included for each PDP context indicating the next in-sequence downlink GTP-PDU to be sent to the MS and the next in-sequence GTP 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) and the downlink PDCP sequence number (PDCP-SND). PDCP‑SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received from the MS. PDCP-SND is the PDCP sequence number for the first downlink packet for which successful transmission has not been confirmed. The 2G+3G‑SGSN shall strip off the eight most significant bits of the passed PDCP sequence numbers, thus converting them to SNDCP N‑PDU numbers of the respective 2G GPRS PDP contexts.

5) Security functions may be executed.

6) If the MS is PMM‑CONNECTED, the 2G+3G‑SGSN sends an SRNS Data Forward Command (RAB ID, Transport Layer Address, Iu Transport Association) message to the SRNS. This informs the SRNS that the 2G+3G‑SGSN is ready to receive data packets. Upon reception of SRNS Data Forward Command message from the 2G+3G‑SGSN the SRNS shall start the data-forwarding timer.

6a) If Direct Tunnel was established in Iu mode the SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between SGSN and GGSN. The GGSN(s) update the address for User Plane and downlink TEID for data and return an Update PDP Context Response. Otherwise, if there were changes of for example the RAT type that e.g. can be used for charging, the SGSN sends Update PDP Context Request (SGSN Address and TEID, QoS Negotiated, RAT type) message to the GGSN.

7) For each RAB indicated by the SRNS Data Forward Command the SRNS starts duplicating and tunnelling the buffered GTP-PDUs back to the 2G+3G‑SGSN. For each radio bearer which uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged PDCP‑PDUs are duplicated and tunnelled back to the 2G+3G‑SGSN together with their related downlink PDCP sequence numbers. The 2G+3G‑SGSN converts the PDCP sequence numbers to SNDCP sequence number (by stripping off the eight most significant bits of the PDCP sequence numbers).

8) The 2G+3G‑SGSN sends an Iu Release Command message to the SRNS. When the RNC data-forwarding timer has expired, the SRNS responds with an Iu Release Complete message.

9) If the association has to be established i.e. if Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the routeing area update, then the 2G+3G‑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 VLR creates or updates the association with the 2G+3G‑SGSN by storing the SGSN Number.

10) 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 data in 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.

11) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 2G+3G‑SGSN. VLR TMSI is optional if the VLR has not changed.

12) The 2G+3G‑SGSN validates the MS’s presence in the new RA. If due to roaming restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the 2G+3G‑SGSN rejects the routeing area update with an appropriate cause. If all checks are successful, the 2G+3G‑SGSN updates MM and PDP contexts for the MS. A new P‑TMSI may be allocated. A logical link is established between the new 2G+3G‑SGSN and the MS. 2G+3G-SGSN initiates the establishment procedure. A Routeing Area Update Accept (P‑TMSI, P‑TMSI Signature, Receive N‑PDU Number (= converted PDCP‑SNU), IMS voice over PS Session Supported Indication) message is returned to the MS. Receive N‑PDU Number contains the acknowledgements for each NSAPI which used lossless PDCP before the start of the update procedure, thereby confirming all mobile-originated N‑PDUs successfully transferred before the start of the update procedure. If Receive N‑PDU Number confirms the reception of N‑PDUs, these N‑PDUs shall be discarded by the MS. The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8.

13) The MS acknowledges the new P‑TMSI by returning a Routeing Area Update Complete (Receive N‑PDU Number) message to the SGSN. Receive N‑PDU Number (= converted PDCP‑SND) contains the acknowledgements for each NSAPI which used lossless PDCP before the start of the update procedure, thereby confirming all mobile-terminated N‑PDUs successfully transferred before the start of the update procedure. If Receive N‑PDU Number confirms the reception of N‑PDUs, these N‑PDUs shall be discarded by the 2G+3G-SGSN.The MS deducts Receive N‑PDU Number from PDCP‑SND by stripping off the eight most significant bits. 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. The new 2G-SGSN negotiates with the MS for each NSAPI the use of acknowledged or unacknowledged SNDCP regardless whether the SRNS used lossless PDCP or not.

14) The 2G+3G‑SGSN sends a TMSI Reallocation Complete message to the VLR if the MS confirms the VLR TMSI.

15) The 2G+3G‑SGSN and the BSS may execute the BSS Packet Flow Context procedure.

For some network sharing scenario (e.g. GWCN) if the PLMN-ID of the RAI supplied by the RNC is different from that of the RAI in the UE’s context, then the SGSN shall informs the HLR.

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]:

C1) CAMEL_GPRS_Routeing_Area_Update_Session, CAMEL_PS_Notification and CAMEL_GPRS_Routeing_Area_Update_Context.

– The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called once per session. In Figure 52, the procedure returns as result "Continue".

– Then the procedure CAMEL_PS_Notification is called once per session. The procedure returns as result "Continue".

– Then, the procedure CAMEL_GPRS_Routeing_Area_Update_Context is called once per PDP context. In Figure 52, the procedure returns as result "Continue".

6.13.1.1.2 Iu mode to A/Gb mode Intra SGSN Change using S4

In this case, clause 6.13.1.1.1 applies except for steps 6a and 7, as well as section specific general statements stated below.

Figure 52-2: step 6a for Iu mode to A/Gb mode Intra SGSN Change 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 (A1) is defined in TS 23.402 [90]. Steps b) and c) in Figure 52-2 concern GTP-based S5/S8.

a) In this procedure flow the Serving GW is not relocated. If Direct Tunnel was established in Iu mode or if there were changes of for example the RAT type that e.g. can be used for charging, the SGSN sends Modify Bearer Request (SGSN Address and TEID, serving network identity, CN Operator Selection Entity, RAT type) message to the Serving GW.

b) The Serving GW informs the P‑GW(s) about the change of for example the RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type) to the concerned P‑GW(s). If dynamic PCC is deployed, and RAT type information needs to be conveyed from the P‑GW to the PCRF, then the P‑GW sends RAT type information to the PCRF as defined in TS 23.203 [88].

c) Each P‑GW updates its context field and returns a Modify Bearer Response (MSISDN, P‑GW address and TEID) message to the Serving GW. MSISDN is included if available in the stored UE context.

d) The Serving GW updates the address for User Plane and downlink TEID for data and return a Modify Bearer Response (Serving GW address and TEID, P‑GW address and TEIDs (for GTP‑based S5/S8) or GRE keys (for PMIP‑based S5/S8) at the PDN GW(s) for uplink traffic) message.

e) In case Direct Tunnel in Iu mode was not established, for each RAB indicated by the SRNS Data Forward Command the SRNS starts duplicating and tunnelling the buffered GTP-PDUs back to the 2G+3G SGSN. For each radio bearer which uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged PDCP PDUs are duplicated and tunnelled back to the 2G+3G SGSN together with their related downlink PDCP sequence numbers. The 2G+3G SGSN converts the PDCP sequence numbers to SNDCP sequence number (by stripping off the eight most significant bits of the PDCP sequence numbers).

In case Direct Tunnel in Iu mode was established, the packets are forwarded via the S‑GW.

6.13.1.2 A/Gb mode to Iu mode Intra-SGSN Change

6.13.1.2.1 A/Gb mode to Iu mode Intra-SGSN Change using Gn/Gp

The intersystem change from A/Gb mode to Iu mode takes place when a GPRS-attached MS changes from A/Gb mode to GERAN or UTRAN Iu mode. Depending on the GPRS mobility management state before the intersystem change and whether the RA is changed or not, one of the following procedures is initiated by the MS:

– When an MS in STANDBY state changes to Iu mode inside the current RA, the MS shall follow the selective RA update procedures, see clause "Selective RA Update".

– When an MS in STANDBY state changes to Iu mode and the RA changes, the MS shall initiate the Iu mode RA update procedure, see clause "Routeing Area Update Procedure".

– When an MS in READY state changes to Iu mode independent of whether the RA has changed or not, the MS shall initiate the Iu mode RA update procedure and afterwards initiate the RABs by the Service Request procedure, see clause "MS Initiated Service Request Procedure". The RA update procedure is either combined RA / LA update or only RA update.

If the network operates in mode I, an MS that is both PS-attached and CS-attached shall perform the Combined RA / LA Update procedure. This concerns only idle mode (see TS 23.122 [7b]), as no combined RA / LA updates are performed during a CS connection. 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.

Figure 53: A/Gb mode to Iu mode Intra SGSN Change

1) The MS or the RAN decides to perform an intersystem change which makes the MS switch to a new cell where Iu mode has to be used, and stops transmission to the network.

2) The MS initiates an RRC connection establishment and sends a Routeing Area Update Request (P‑TMSI, Old RA, Old P‑TMSI Signature, Update Type, CM, Voice domain preference and UE’s usage setting) message to the combined 2G+3G‑SGSN. Update Type shall indicate RA update or combined RA / LA update or, if the MS wants to perform an IMSI attach, combined RA / LA update with IMSI attach requested and also if the MS has a follow on request, i.e. if there is pending uplink traffic (signalling or 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. The SRNS shall add an identifier of the area where the message was received before passing the message to the 2G+3G‑SGSN. The 2G+3G‑SGSN stops transmission of N‑PDUs to the MS. The UE sets the voice domain preference and UE’s usage setting according to its configuration, as described in clause 5.3.15.

3) Security functions may be executed.

4) If the association has to be established i.e. if Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the routeing area update, the 2G+3G‑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 VLR creates or updates the association with the 2G+3G‑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].

5) 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 data in 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.

6) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 2G+3G‑SGSN. VLR TMSI is optional if the VLR has not changed.

7) The 2G+3G‑SGSN validates the MS’s presence in the new RA. If due to roaming restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the 2G+3G‑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 2G+3G‑SGSN updates MM and PDP contexts for the MS. A new P‑TMSI may be allocated. A Routeing Area Update Accept (P‑TMSI, P‑TMSI Signature, IMS voice over PS Session Supported Indication, Emergency Service Support) message is returned to the MS. The 2G+3G-SGSN derives for this intersystem change the corresponding PDCP sequence numbers from the N‑PDU sequence numbers stored in the SGSN PDP contexts by adding eight most significant bits "1". These PDCP sequence numbers are stored in the SGSN PDP contexts. The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8.

The Emergency Service Support indicator shall be included when going to UTRAN to inform the MS that Emergency PDP contexts are supported, i.e. the MS is allowed to request activation of emergency PDP context when needed.

8) The MS acknowledges the new P‑TMSI by returning a Routeing Area Update Complete message to the SGSN.

9) The 2G+3G‑SGSN sends a TMSI Reallocation Complete message to the VLR if the MS confirms the VLR TMSI.

10) If the MS has pending uplink data or signalling, it shall send a Service Request (P‑TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate one of the following: Data or Signalling.

11) The 2G+3G‑SGSN requests the SRNS to establish a radio access bearer by sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP‑SNDs, GTP‑SNUs, PDCP‑SNUs, UE-AMBR, MSISDN, APN, Charging characteristics) message to the SRNS. If Direct Tunnel is established the SGSN provides to the RNC the GGSN’s Address for User Plane and TEID for uplink data. The PDCP sequence numbers are derived from the N‑PDU sequence numbers and stored in the PDP contexts in step 7). The SRNS sends a Radio Bearer Setup Request (PDCP‑SNUs) message to the MS. The MS responds with a Radio Bearer Setup Complete (PDCP‑SNDs) message. The SRNS responds with a RAB Assignment Response message. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.

NOTE: The NSAPI value is carried in the RAB ID IE.

11a) If the SGSN established Direct Tunnel it shall send Update PDP Context Request to the GGSN(s) concerned and include the RNC’s Address for User Plane, downlink TEID for data and DTI to instruct the GGSN(s) to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. Otherwise, if there were changes of for example the RAT type that e.g. can be used for charging, the SGSN sends Update PDP Context Request (SGSN Address and TEID, QoS Negotiated, RAT type) message to the GGSN.

12) Traffic flow is resumed between the 2G+3G‑SGSN and the SRNS. N-PDUs that were already sent to the MS in acknowledged mode SNDCP and that are not yet acknowledged by the MS are tunnelled by the 2G+3G‑SGSN to the SRNS together with their related N-PDU number (SNDCP sequence number). No PDCP sequence numbers shall be indicated for these N-PDUs. The SRNS shall discard all N‑PDUs with N‑PDU sequence numbers older than the eight least significant bits of PDCP-SND received from the MS. Other N‑PDUs shall be transmitted to the MS. The MS shall discard all N‑PDUs with sequence numbers older than the eight least significant bits of the PDCP‑SNU received from the SRNS. All other N‑PDUs shall be transmitted to the SRNS. The SRNS negotiates with the MS for each radio bearer the use of lossless PDCP or not regardless whether the old 2G-SGSN used acknowledged or unacknowledged SNDCP for the related NSAPI or not.

13) The traffic flow is resumed between the SRNS and the MS.

For some network sharing scenario (e.g. GWCN) if the PLMN-ID of the RAI supplied by the RNC is different from that of the RAI in the UE’s context, then the SGSN shall informs the HLR.

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]:

C1) CAMEL_GPRS_Routeing_Area_Update_Session, CAMEL_PS_Notification and CAMEL_GPRS_Routeing_Area_Update_Context.

– The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called once relative to the session. In Figure 53, the procedure returns as result "Continue".

– Then the procedures CAMEL_PS_Notification is called once relative to the session. The procedure returns as result "Continue".

– Then the procedure CAMEL_GPRS_Routeing_Area_Update_Context is called once per PDP context. In Figure 53, the procedure returns as result "Continue".

6.13.1.2.2 A/Gb mode to Iu mode Intra-SGSN Change using S4

In this case, clause 6.13.1.2.1 applies except for step 11, as well as clause-specific general statements stated below.

Figure 53-2: step 11 for A/Gb mode to Iu mode Intra-SGSN Change using S4

a) If the SGSN established Direct Tunnel it shall send Modify Bearer Request (RNC Address and TEID, serving network identity, CN Operator Selection Entity, RAT type) message to the Serving GW and include the RNC’s Address for User Plane, downlink TEID for data and DTI to instruct the Serving GW to apply Direct Tunnel specific error handling as described in clause 13.8. Otherwise, if there were changes of for example the RAT type that e.g. can be used for charging, the SGSN shall send Modify Bearer Request (SGSN Address and TEID, serving network identity, CN Operator Selection Entity, RAT type) message to the Serving GW and include the SGSN’s Address for User Plane, downlink TEID for data.

c) Each P‑GW updates its context field and returns a Modify Bearer Response (MSISDN, P‑GW address and TEID) message to the Serving GW. MSISDN is included if available in the stored UE context.

d) The Serving GW updates the Address for User Plane and TEID for downlink data and return a Modify Bearer Response (Serving GW address and TEID, P‑GW address and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic) message.

6.13.1.3 Selective RA Update

The MS shall use the following procedures when in STANDBY or PMM‑IDLE state.

Note that upon expiry of the periodic RA update timer, the MS shall carry out the periodic routeing area update procedure.

6.13.1.3.1 Uplink Signalling or Data Transmission

In STANDBY or PMM‑IDLE state the MS shall not perform an RA update procedure until uplink data or signalling information is to be sent from the MS.

If the MS is in the same mode (A/Gb mode or Iu mode) as when it last sent data or signalling, the procedures defined for that mode shall be followed. This shall be the sending of an LLC PDU in A/Gb mode, or for example sending of a Service Request message in Iu mode.

If the MS is in a different mode (A/Gb mode or Iu mode) as when it last sent data or signalling, the RA update procedure shall be performed before the sending of data or signalling. The RA update procedure needs not be performed if the signalling message is a power-off detach.

6.13.1.3.2 Downlink Signalling or Data Transmission

If the SGSN receives data for an MS in STANDBY or PMM‑IDLE state or, if the SGSN uses S4 and receives a Downlink Data Notification from the S‑GW, the SGSN shall page in the RA where the MS is located. This may include both A/Gb mode and Iu mode cells.

If the MS receives this page in the same mode (A/Gb mode or Iu mode)as when it last sent data or signalling, the procedures defined for that mode shall be followed. This shall be the sending of an LLC PDU in a cell where the MS has to use A/Gb mode or, for example, sending of a Service Request message in a cell where the MS has to use Iu mode. When receiving such trigger from the RAN, if the S4-SGSN has no S4/S12 downlink user plane TEIDs for the UE, it sends Modify Bearer Request (S4/S12 downlink user plane TEIDs and IP address) to the S‑GW, which establishes the downlink user plane towards the S4-SGSN or S12 RNC.

If the MS receives this page in a different mode (A/Gb mode or Iu mode) as when it last sent data or signalling, the RA update procedure shall be performed. The SGSN shall accept this RAU as a valid response.

6.13.2 Inter-SGSN Inter-system Change

6.13.2.1 Iu mode to A/Gb mode Inter-SGSN Change

6.13.2.1.1 Iu mode to A/Gb mode Inter-SGSN Change using Gn/Gp

An inter-SGSN inter-system change from Iu mode to A/Gb mode takes place when an MS in PMM‑IDLE or PMM‑CONNECTED state changes from UTRAN or GERAN Iu mode to A/Gb mode and the A/Gb mode radio access node serving the MS is served by a different SGSN. In this case, the RA changes. Therefore, the MS shall initiate a A/Gb mode RA update procedure. The RA update procedure is either combined RA / LA update or only RA update. These RA update cases are illustrated in Figure 54. 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.

A combined RA / LA update takes place in network operation mode I when the MS enters a new RA or when a GPRS-attached MS performs IMSI attach. The MS sends a Routeing Area Update Request indicating that an LA update may also need to be performed, in which case the SGSN forwards the LA update to the VLR. This concerns only idle mode (see TS 23.122 [7b]), as no combined RA / LA updates are performed during a CS connection.

NOTE: Direct Tunnel requires no additional functionality.

Figure 54: Iu mode to A/Gb mode Inter-SGSN Change

1) The MS or RAN decides to perform an inter-system change, which makes the MS switch to a new cell where A/Gb mode has to be used, and stops transmission to the network.

2) The MS sends a Routeing Area Update Request (old RAI, old P‑TMSI Signature, Update Type, MS Network Capability, Voice domain preference and UE’s usage setting) message to the new 2G‑SGSN. Update Type shall indicate RA update or combined RA / LA update, or, if the MS wants to perform an IMSI attach, combined RA / LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before passing the message to the new 2G‑SGSN. The UE sets the voice domain preference and UE’s usage setting according to its configuration, as described in clause 5.3.15.

3) The new 2G‑SGSN sends an SGSN Context Request (old RAI, TLLI, old P‑TMSI Signature, New SGSN Address) message to the old 3G‑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 (or TLLI) 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 (or TLLI) and relay the message to that actual old SGSN. The old 3G-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 3G‑SGSN. If the received old P-TMSI Signature does not match the stored value, the security functions in the new 2G-SGSN should be initiated. If the security functions authenticate the MS correctly, the new 2G-SGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old 3G-SGSN. MS Validated indicates that the new 2G-SGSN has authenticated the MS. If the old P‑TMSI Signature was valid or if the new 2G-SGSN indicates that it has authenticated the MS correctly, the old 3G‑SGSN starts a timer. If the MS is not known in the old 3G‑SGSN, the old 3G‑SGSN responds with an appropriate error cause.

4) If the MS is PMM‑CONNECTED the old 3G‑SGSN sends an SRNS Context Request (IMSI) message to the SRNS. Upon receipt of this message the SRNS buffers and stops sending downlink PDUs to the MS and returns an SRNS Context Response (GTP‑SNDs, GTP‑SNUs, PDCP-SNDs, 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) downlink PDCP sequence number (PDCP-SND). PDCP‑SNU shall be the next in-sequence PDCP sequence number expected from the MS. PDCP-SND is the PDCP sequence number for the first downlink packet for which successful transmission has not been confirmed. The 3G‑SGSN shall strip off the eight most significant bits of the passed PDCP sequence numbers, thus converting them to SNDCP N‑PDU numbers and stores the N-PDU numbers in its PDP contexts..

5) 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 in-sequence N‑PDU to be sent to the MS. Each PDP Context also includes the SNDCP Send N‑PDU Number (the value is 0) for the next in-sequence downlink N‑PDU to be sent in SNDCP acknowledged mode to the MS and the SNDCP Receive N‑PDU Number (= converted PDCP‑SNU) for the next in-sequence uplink N‑PDU to be received in SNDCP acknowledged mode from the MS. 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.

6) Security functions may be executed. If the SGSN Context Response message did not include IMEISV and the ADD function is supported by the new 2G-SGSN, then the IMEISV shall be retrieved from the MS.

7) The new 2G‑SGSN sends an SGSN Context Acknowledge message to the old 3G‑SGSN. This informs the old 3G‑SGSN that the new 2G‑SGSN is ready to receive data packets belonging to the activated PDP contexts. 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 RA update procedure back to the old SGSN before completing the ongoing RA update procedure.

8) If the MS is in the PMM‑CONNECTED state, the old 3G‑SGSN sends an SRNS Data Forward Command (RAB ID, Transport Layer Address, Iu Transport Association) message to the SRNS. For each indicated RAB the SRNS starts duplicating and tunnelling the buffered GTP PDUs to the old 3G‑SGSN. For each radio bearer which uses lossless PDCP the SRNS shall start tunnelling the GTP-PDUs related to transmitted but not yet acknowledged PDCP‑PDUs to the old 3G‑SGSN together with their related downlink PDCP sequence numbers. Upon receipt of the SRNS Data Forward Command message from the 3G‑SGSN, the SRNS shall start the data-forwarding timer.

9) The old 3G‑SGSN tunnels the GTP PDUs to the new 2G‑SGSN. For GTPv1, the conversion of PDCP sequence numbers to SNDCP sequence numbers (the eight most significant bits shall be stripped off) shall be done in the new SGSN. No N-PDU sequence numbers shall be indicated for these N-PDUs.

10) The new 2G‑SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, Negotiated Evolved ARP, serving network identity, CN Operator Selection Entity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, NRSN) message to each GGSN 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]. Each GGSN updates its PDP context fields and returns an Update PDP Context Response (TEID, 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.

11) The new 2G‑SGSN informs the HLR of the change of SGSN by sending an Update GPRS Location (SGSN Number, SGSN Address, IMSI, IMEISV, Homogenous Support of IMS Voice over PS Sessions) message to the HLR. IMEISV is sent if the ADD function is supported. For "Homogenous Support of IMS Voice over PS Sessions", see clause 5.3.8A.

12) The HLR sends a Cancel Location (IMSI) message to the old 3G‑SGSN. The old 3G‑SGSN acknowledges with a Cancel Location Ack (IMSI) message. The old 3G‑SGSN removes the MM and PDP contexts if the timer described in step 3 is not running. If the timer is running, the MM and PDP contexts shall be removed when the timer expires.

13) When the MS is PMM‑CONNECTED, the old 3G‑SGSN sends an Iu Release Command message to the SRNS. When the RNC data-forwarding timer has expired, the SRNS responds with an Iu Release Complete message.

14) The HLR sends an Insert Subscriber Data (IMSI, Subscription Data) message to the new 2G‑SGSN. The 2G‑SGSN constructs an MM context and PDP contexts for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 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 15).

15) The HLR acknowledges the Update GPRS Location by returning an Update GPRS Location Ack (IMSI, GPRS Subscriber Data (only if S6d interface is used)) message to the new 2G‑SGSN.

16) If the association has to be established i.e. if Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the routeing area update, the new 2G‑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 2G‑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 14). The VLR creates or updates the association with the 2G‑SGSN by storing SGSN Number.

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

18) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the 2G‑SGSN. VLR TMSI is optional if the VLR has not changed.

19) The new 2G‑SGSN validates the MS’s presence in the new RA. If due to roaming restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the new 2G‑SGSN rejects the routeing area update with an appropriate cause. If all checks are successful, the new 2G‑SGSN constructs MM and PDP contexts for the MS. A logical link is established between the new 2G‑SGSN and the MS. 2G-SGSN initiates the establishment procedure. The new 2G‑SGSN responds to the MS with a Routeing Area Update Accept (P‑TMSI, P‑TMSI Signature, Receive N‑PDU Number (= converted PDCP‑SNU), IMS voice over PS Session Supported Indication) message. Receive N‑PDU Number contains the acknowledgements for each NSAPI which used lossless PDCP before the start of the update procedure, thereby confirming all mobile-originated N‑PDUs successfully transferred before the start of the update procedure. If Receive N‑PDU Number confirms the reception of N‑PDUs, the MS shall discard these N‑PDUs. The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8.

20) The MS acknowledges the new P‑TMSI by returning a Routeing Area Update Complete (Receive N‑PDU Number (= converted PDCP‑SND)) message to the SGSN. Receive N‑PDU Number contains the acknowledgements for each lossless PDCP used by the MS before the start of the update procedure, thereby confirming all mobile-terminated N‑PDUs successfully transferred before the start of the update procedure. If Receive N‑PDU Number confirms the reception of N‑PDUs that were forwarded from the old 3G-SGSN, the new 2G-SGSN shall discard these N‑PDUs. The MS deducts Receive N‑PDU number from PDCP‑SND by stripping off the eight most significant bits. 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. The new 2G-SGSN negotiates with the MS for each NSAPI the use of acknowledged or unacknowledged SNDCP regardless whether the SRNS used lossless PDCP or not.

21) The new 2G‑SGSN sends TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR TMSI.

22) The 2G‑SGSN and the BSS may execute the BSS Packet Flow Context procedure.

If the new SGSN is unable to update the PDP context in one or more GGSN(s), the new SGSN shall deactivate the corresponding PDP 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 shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP 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 from the GGSN and then store the new Maximum APN restriction value.

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP 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 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.

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.13.2.1.2 Iu mode to A/Gb mode Inter-SGSN Change using S4

In this case, clause 6.13.2.1.1 applies except for steps 3, 5, 7, 9 and 10, as well as clause-specific general statements stated below.

Figure 54-2: steps 3, 5, 7, 9 for Iu mode to A/Gb mode Inter-SGSN Change using S4

Steps 3, 5 and 7 are identical to the Gn/Gp case in clause 6.13.2.2.1, except that:

– Message SGSN Context Request is replaced by message Context Request;

– Parameter PDP Contexts is replaced by parameter EPS Bearer Contexts.

MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. For RAU between two S4-SGSNs, the old SGSN shall include the APN Restriction, CGI/SAI/RAI change support indication and Change Reporting Action in the Context Response message.

9) In case Direct Tunnel in Iu mode was not established, the old 3G SGSN tunnels the GTP PDUs to the new 2G‑SGSN. For GTPv2 or GTPv1 user plane, the conversion of PDCP sequence numbers to SNDCP sequence numbers (the eight most significant bits shall be stripped off) shall be done in the new SGSN. No N‑PDU sequence numbers shall be indicated for these N‑PDUs.

In case Direct Tunnel in Iu mode was established, the packets are forwarded via the S‑GW.

10) Box (B)

Figure 54-3: step 10 for Iu mode to A/Gb mode Inter-SGSN Change using S4

a) The new 2G‑SGSN sends a Modify Bearer Request (new SGSN Address, TEID, serving network identity, CN Operator Selection Entity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication) message to the Serving GW. The SGSN shall send the serving network identity and the CN Operator Selection Entity to the Serving GW.

b) The Serving GW informs the P‑GW(s) about the change of Serving GW Address and TEID, as well as about RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type) to the concerned P‑GW(s). If dynamic PCC is deployed, and RAT type information needs to be conveyed from the P‑GW to the PCRF, then the P‑GW shall send RAT type information to the PCRF as defined in TS 23.203 [88].

c) Each P‑GW updates its context fields and returns a Modify Bearer Response (MSISDN, P‑GW address and TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) message. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context. MSISDN is included if available in the stored UE context.

d) The Serving GW updates the Address for User Plane and TEID for downlink data and return a Modify Bearer Response (Serving GW address and TEID, P‑GW address and TEIDs (for GTP‑based S5/S8) or GRE keys (for PMIP‑based S5/S8) at the PDN GW(s) for uplink traffic, CSG Information Reporting Action) message.

If the new SGSN is unable to update the Bearer context in the S‑GW or in one or more P‑GW(s), the new SGSN shall deactivate the corresponding 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 Bearer Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important Bearer Context first in the 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 Bearer context from the P‑GW(s) or old S4-SGSN and then store the new Maximum APN restriction value.

The bearer contexts shall be prioritized by the new SGSN. If the new SGSN is unable to support the same number of active Bearer contexts as received from old SGSN, the new SGSN should use the prioritisation when deciding which Bearer contexts to maintain active and which ones to delete. In any case, the new SGSN shall first update all contexts in the S‑GW and in one or more P‑GW(s) 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.

6.13.2.2 A/Gb mode to Iu mode Inter-SGSN Change

6.13.2.2.1 A/Gb mode to Iu mode Inter-SGSN Change using Gn/Gp

The inter-system change from A/Gb mode to Iu mode takes place when a GPRS-attached MS changes from A/Gb mode to UTRAN or GERAN Iu mode and the new RAN node serving the MS is served by a different SGSN. In this case the RA changes. Therefore, the MS shall initiate a Iu mode RA update procedure by establishing an RRC connection and initiating the RA update procedure. The RA update procedure is either combined RA / LA update or only RA update, these RA update cases are illustrated in Figure 55. 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.

If the network operates in mode I, then an MS, that is both PS-attached and CS-attached, shall perform the Combined RA / LA Update procedures. This concerns only idle mode (see TS 23.122 [7b]), as no combined RA / LA updates are performed during a CS connection.

Figure 55: A/Gb mode to Iu mode Inter SGSN Change

1) The MS or RAN decides to perform an inter-system change, which makes the MS switch to a new cell where Iu mode has to be used, and stops transmission to the network.

2) The MS sends a Routeing Area Update Request (P‑TMSI, old RAI, old P‑TMSI Signature, Update Type, CM, MS Network Capability, Voice domain preference and UE’s usage setting) message to the new 3G‑SGSN. Update Type shall indicate RA update or combined RA / LA update, or, if the MS wants to perform an IMSI attach, combined RA / LA update with IMSI attach requested, and also if the MS has a follow-on request, i.e. if there is pending uplink traffic (signalling or 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. 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. The UE sets the voice domain preference and UE’s usage setting according to its configuration, as described in clause 5.3.15.

3) The new 3G‑SGSN uses the old RAI received from the MS to derive the old 2G‑SGSN address, and sends an SGSN Context Request (old RAI, old P‑TMSI, New SGSN Address) message to the old 2G‑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 2G-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 2G‑SGSN. If the received old P-TMSI Signature does not match the stored value, the old 2G-SGSN should initiate the security functions in the new 3G-SGSN. If the security functions authenticate the MS correctly, the new 3G-SGSN shall send an SGSN Context Request (old RAI, IMSI, MS Validated, New SGSN Address) message to the old 2G-SGSN. MS Validated indicates that the new 3G-SGSN has authenticated the MS. If the old P‑TMSI Signature was valid or if the new 3G-SGSN indicates that it has authenticated the MS correctly, the old 2G‑SGSN starts a timer and stops the transmission of N‑PDUs to the MS.

4) The old 2G‑SGSN responds with an SGSN Context Response (MM Context, PDP Contexts, Negotiated Evolved ARP) message. Each PDP Context includes the GTP sequence number for the next downlink N‑PDU to be sent to the MS and the GTP sequence number for the next uplink N‑PDU to be tunnelled to the GGSN. Each PDP Context also includes the SNDCP Send N‑PDU Number for the next downlink N‑PDU to be sent in acknowledged mode SNDCP to the MS and the SNDCP Receive N‑PDU Number for the next uplink N‑PDU to be received in acknowledged mode SNDCP from the MS. The new 3G-SGSN derives the corresponding PDCP sequence numbers from these N‑PDU sequence numbers by adding eight most significant bits "1". These PDCP sequence numbers are stored in the 3G-SGSN PDP contexts. 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.

5) Security functions may be executed. If the SGSN Context Response message did not include IMEISV and the ADD function is supported by the new 3G-SGSN, then the IMEISV shall be retrieved from the MS.

6) The new 3G‑SGSN sends an SGSN Context Acknowledge message to the old 2G‑SGSN. This informs the old 2G‑SGSN that the new 3G‑SGSN is ready to receive data packets belonging to the activated PDP contexts. 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.

7) The old 2G‑SGSN duplicates the buffered N‑PDUs and starts tunnelling them to the new 3G‑SGSN. Additional N‑PDUs received from the GGSN before the timer described in step 3 expires are also duplicated and tunnelled to the new 3G‑SGSN. N-PDUs that were already sent to the MS in acknowledged mode SNDCP and that are not yet acknowledged by the MS are tunnelled together with their related SNDCP N-PDU sequence number. No PDCP sequence numbers shall be indicated for these N-PDUs. No N‑PDUs shall be forwarded to the new 3G‑SGSN after expiry of the timer described in step 3.

8) The new 3G‑SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, Negotiated Evolved ARP, serving network identity, CN Operator Selection Entity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, NRSN) message to each GGSN 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]. Each GGSN updates its PDP context fields and returns an Update PDP Context Response (TEID, 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.

9) The new 3G‑SGSN informs the HLR of the change of SGSN by sending an Update GPRS Location (SGSN Number, SGSN Address, IMSI, IMEISV, Homogenous Support of IMS Voice over PS Sessions) message to the HLR. IMEISV is sent if the ADD function is supported. For "Homogenous Support of IMS Voice over PS Sessions", see clause 5.3.8A.

10) The HLR sends a Cancel Location (IMSI, Cancellation Type) message to the old 2G‑SGSN. The old 2G‑SGSN removes the MM and PDP contexts if the timer described in step 3 is not running. If the timer is running, the MM and PDP contexts are removed when the timer expires. The old 2G‑SGSN acknowledges with a Cancel Location Ack (IMSI) message.

11) The HLR sends an Insert Subscriber Data (IMSI, Subscription Data) message to the new 3G‑SGSN. The 3G‑SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 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 15).

12) The HLR acknowledges the Update GPRS Location by returning an Update GPRS Location Ack (IMSI, GPRS Subscriber Data (only if S6d interface is used)) message to the new 3G‑SGSN.

13) If the association has to be established, if Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the routeing area update, 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 3G‑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 12). The VLR creates or updates the association with the 3G‑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 new 3G-SGSN has received this information from the RNS, as described in TS 23.251 [83].

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

15) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the 3G‑SGSN. VLR TMSI is optional if the VLR has not changed.

16) The new 3G‑SGSN validate the MS’s presence in the new RA. If due to roaming restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the new 3G‑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 3G‑SGSN constructs MM and PDP contexts for the MS. The new 3G‑SGSN responds to the MS with a Routeing Area Update Accept (P‑TMSI, P‑TMSI signature, IMS voice over PS Session Supported Indication, Emergency Service Support) message. The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8.

If after step 8 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.

17) The MS acknowledges the new P‑TMSI by returning a Routeing Area Update Complete message to the SGSN.

18) The new 3G‑SGSN sends TMSI Reallocation Complete message to the new VLR, if the MS confirms the VLR TMSI.

19) If the MS has uplink data or signalling pending it shall send a Service Request (P‑TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate one of the following: Data or Signalling.

20) If the MS has sent the Service Request, the new 3G‑SGSN requests the SRNS to establish a radio access bearer by sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP‑SNDs, GTP‑SNUs, PDCP‑SNUs, UE-AMBR, MSISDN, APN, Charging characteristics) message to the SRNS. If Direct Tunnel is established the SGSN provides to the RNC the GGSN’s Address for User Plane and TEID for uplink data. The PDCP sequence numbers are derived from the N‑PDU sequence numbers in step 4) and stored in the SGSN PDP contexts. The SRNS sends a Radio Bearer Setup Request (PDCP‑SNUs) message to the MS. The MS responds with a Radio Bearer Setup Complete (PDCP‑SNDs) message. The MS deducts PDCP-SND from its Receive N‑PDU Number by adding eight most significant bits "1". The SRNS responds with a RAB Assignment Response message. The SRNS shall discard all N‑PDUs tunnelled from the SGSN with N‑PDU sequence numbers older than the eight least significant bits of the PDCP‑SNDs received from the MS. Other N‑PDUs shall be transmitted to the MS. The MS shall discard all N‑PDUs with SNDCP sequence numbers older than the eight least significant bits of the PDCP‑SNUs received from the SRNS. Other N‑PDUs shall be transmitted to the SRNS. The SRNS negotiates with the MS for each radio bearer the use of lossless PDCP or not regardless whether the old 2G-SGSN used acknowledged or unacknowledged SNDCP for the related NSAPI or not. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.

20a) If the SGSN established Direct Tunnel in step 20) it shall send Update PDP Context Request to the GGSN(s) concerned and include the RNC’s Address for User Plane, downlink TEID for data and DTI to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response.

NOTE 1: The NSAPI value is carried in the RAB ID IE.

NOTE 2: The new SGSN may initiate RAB establishment after execution of the security functions (step 5), 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 2).

If the new SGSN is unable to update the PDP context in one or more GGSNs, the new SGSN shall deactivate the corresponding PDP contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update.

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP context from the GGSN and then store the new Maximum APN restriction value.

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. It returns as result "Continue".

– Then the CAMEL_PS_Notification procedure is called once. It 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.13.2.2.2 A/Gb mode to Iu mode Inter-SGSN Change using S4

In this case, clause 6.13.2.2.1 applies except for steps 3, 4, 6, 7, 8 and 20, as well as clause-specific general statements stated below.

Figure 55-2: steps 3, 4, 6, 7 for A/Gb mode to Iu mode Inter-SGSN Change using S4

Steps 3, 4, 6 and 7 are identical to the Gn/Gp case in clause 6.13.2.2.1, except that:

– Message SGSN Context Request is replaced by message Context Request;

– Parameter PDP Contexts is replaced by parameter EPS Bearer Contexts.

– MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. For RAU between two S4-SGSNs, the old SGSN shall include the APN Restriction, CGI/SAI/RAI change support indication and Change Reporting Action in the Context Response message.

8. Box (B).

Figure 55-3: step 8 for A/Gb mode to Iu mode Inter-SGSN Change using S4

a) The new 3G SGSN sends a Modify Bearer Request (new SGSN Address, TEID, serving network identity, CN Operator Selection Entity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication) message to the Serving GW. The SGSN shall send the serving network identity and the CN Operator Selection Entity to the Serving GW.

b) The Serving GW informs the P‑GW(s) about the change of Serving GW Address and TEID, as well as about the RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type) to the concerned P‑GW(s). If dynamic PCC is deployed, and RAT type information needs to be conveyed from the P‑GW to the PCRF, then the P‑GW shall send RAT type information to the PCRF as defined in TS 23.203 [88].

20. Box (C).

Figure 55-4: step 10 for A/Gb mode to Iu mode Inter-SGSN Change using S4

Step 10 is identical to the Gn/Gp case in clause 6.13.2.2.1, except that:

– Message SGSN Context Request is replaced by message Context Request;

– Parameter PDP Contexts is replaced by parameter EPS Bearer Contexts.

MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2.