Content for  TS 23.060  Word version:  18.0.0

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.

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

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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:

1. The new VLR sends an Update Location (new VLR) to the HLR.
2. The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.
3. The old VLR acknowledges with Cancel Location Ack (IMSI).
4. The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR.
5. The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).
6. The HLR responds with Update Location Ack (IMSI) to the new VLR.

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.

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.

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.

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

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

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

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

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

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

CAMEL_GPRS_Routeing_Area_Update_Context.

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.

Box (B)