7.3.4 Inter SGSN Routeing Area Update Procedure

23.1193GPPGateway Location Register (GLR)Release 17Stage 2TS

[Editor’s note] This procedure may be replaced with inter SGSN SRNS relocation procedure.

[Editor’s note] This procedure may not need to be detailed, because the part of this procedure between SGSN and HLR is the same as the part of Attach procedure.

The Inter SGSN Routeing Area Update procedure is illustrated in Figure 7.3/12. Each step is explained in the following list.

Figure 7.3/12: Inter SGSN Routeing Area Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P‑TMSI Signature, and Update Type) to the new SGSN. Update Type shall indicate RA update or periodic RA update. 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 SGSN.

2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P‑TMSI Signature, and New SGSN Address) to the old SGSN to get the MM and PDP contexts for the MS. The old 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 SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, and New SGSN Address) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P‑TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN responds with SGSN Context Response (MM Context, PDP Contexts, and LLC Ack). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN. LLC Ack contains the acknowledgements for each LLC connection used by the MS. 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. The old SGSN starts a timer and stops the transmission of N-PDUs to the MS.

3) Security functions may be executed. These procedures are defined in clause "Security Function". Ciphering mode shall be set if ciphering is supported.

4) The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSN that the new 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 GLR are invalid. This triggers the MSC/VLR, the GGSNs, and the GLR 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. If the security functions do not authenticate the MS correctly, then the routing area update shall be rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN Context Request was never received.

5) The old SGSN duplicates the buffered N‑PDUs and starts tunnelling them to the new SGSN. Additional N‑PDUs received from the GGSN before the timer described in step 2 expires are also duplicated and tunnelled to the new SGSN. N‑PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with the number of the LLC frame that transferred the last segment of the N‑PDU. No N‑PDUs shall be forwarded to the new SGSN after expiry of the timer described in step 2.

6) The new SGSN sends Update PDP Context Request (new SGSN Address, TID, and QoS Negotiated) to the GGSNs concerned. The GGSNs update their PDP context fields and return Update PDP Context Response (TID).

7) The new SGSN informs the GLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, and IMSI) to the GLR.

8) The GLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure. If the timer described in step 2 is not running, then the old SGSN removes the MM and PDP contexts. Otherwise, the contexts are removed only when the timer expires. This allows the old SGSN to complete the forwarding of N‑PDUs. It also ensures that the MM and PDP contexts are kept in the old SGSN in case the MS initiates another inter SGSN routeing area update before completing the ongoing routeing area update to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI).

9) The GLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new SGSN. The new SGSN validates the MS’s presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the GLR. If all checks are successful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the GLR.

10) The GLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.

11) The new SGSN validates the MS’s presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the SGSN, or if subscription checking fails, then the new SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the new SGSN constructs MM and PDP contexts for the MS. A logical link is established between the new SGSN and the MS. The new SGSN responds to the MS with Routeing Area Update Accept (P‑TMSI, LLC Ack, and P‑TMSI Signature). LLC Ack contains the acknowledgements for each LLC connection used by the MS, thereby confirming all mobile-originated N‑PDUs successfully transferred before the start of the update procedure.

12) The MS acknowledges the new P‑TMSI with a Routeing Area Update Complete (P‑TMSI, LLC Ack). LLC Ack contains the acknowledgements for each LLC connection used by the MS, thereby confirming all mobile-terminated N‑PDUs successfully transferred before the start of the update procedure. If LLC Ack confirms reception of N‑PDUs that were forwarded from the old SGSN, then these N‑PDUs shall be discarded by the new SGSN. LLC and SNDCP in the MS are reset.

In the case of a rejected routeing area update operation, due to regional subscription or roaming restrictions, the new SGSN shall not construct an MM context. A reject shall be returned to the MS with an appropriate cause. The MS shall not re-attempt a routeing area update to that RA. The RAI value shall be deleted when the MS is powered-up.

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

If the timer described in step 2 expires and no Cancel Location (IMSI) was received from the GLR, then the old SGSN shall stop forwarding N-PDUs to the new SGSN.

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing Area Update Reject (Cause) message, the MS shall enter IDLE state.