6.9 Location Management Function

03.603GPPGeneral Packet Radio Service (GPRS)Release 1998Service descriptionStage 2TS

The Location Management function:

– provides mechanisms for cell and PLMN selection;

– provides a mechanism for the network to know the Routeing Area for MSs in STANDBY and READY states; and

– provides a mechanism for the network to know the cell identity for MSs in READY state.

Routeing Area (RA) is defined in subclause "Routeing Area Identity".

6.9.1 Location Management Procedures

The PLMN shall provide information for the MS to be able to:

– detect when it has entered a new cell or a new RA; and

– determine when to perform periodic RA updates.

The MS detects that a new cell has been entered by comparing the cell’s identity with the cell identity stored in the MS’s MM context. The MS detects that a new RA has been entered by periodically comparing the RAI stored in its MM context with that received from the new cell. The MS shall consider hysteresis in signal strength measurements.

When the MS camps on a new cell, possibly in a new RA, this indicates one of three possible scenarios:

– a cell update is required;

– a routeing area update is required; or

– a combined routeing area and location area update is required.

In all three scenarios the MS stores the cell identity in its MM context.

If the MS enters a new PLMN, the MS shall either perform a routeing area update, or enter IDLE state.

In network mode of operation II and III, whenever an MS determines that it shall perform both an LA update and an RA update, the MS shall perform the LA update first.

Routeing Area Update Request messages shall be sent unciphered, since in the inter SGSN routeing area update case the new SGSN shall be able to process the request.

6.9.1.1 Cell Update Procedure

A cell update takes place when the MS enters a new cell inside the current RA and the MS is in READY state. If the RA has changed, a routeing area update is executed instead of a cell update.

The MS performs the cell update procedure by sending an uplink LLC frame of any type containing the MS’s identity to the SGSN. In the direction towards the SGSN, the BSS shall add the Cell Global Identity including RAC and LAC to all BSSGP frames, see GSM 08.18. A cell update is any correctly received and valid LLC PDU carried inside a BSSGP PDU containing a new identifier of the cell.

The SGSN records this MS’s change of cell, and further traffic directed towards the MS is conveyed over the new cell.

6.9.1.2 Routeing Area Update Procedure

A routeing area update takes place when a GPRS-attached MS detects that it has entered a new RA, when the periodic RA update timer has expired, or when the MS indicates changed access capabilities to the network, or when a suspended MS is not resumed by the BSS (see subclause "Suspension of GPRS Services"). The SGSN detects that it is 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 GGSNs or the HLR about the new MS location. A periodic RA update is always an intra SGSN routeing area update.

An MS in READY state due to anonymous access shall not perform routeing area updates for the AA MM context. If the MS has entered a new routeing area, a new Anonymous Access PDP Context Activation procedure shall be initiated. The old context is implicitly deleted upon expiry of the READY timer.

6.9.1.2.1 Intra SGSN Routeing Area Update

The Intra SGSN Routeing Area Update procedure is illustrated in Figure 27. Each step is explained in the following list.

Figure 27: Intra SGSN Routeing Area Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P‑TMSI Signature, Update Type) to the 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, see GSM 08.18.

2) Security functions may be executed. These procedures are defined in subclause "Security Function".

3) The 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, or if subscription checking fails, then the SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the SGSN updates the MM context for the MS. A new P‑TMSI may be allocated. A Routeing Area Update Accept (P‑TMSI, P‑TMSI Signature) is returned to the MS.

4) If P‑TMSI was reallocated, the MS acknowledges the new P‑TMSI by returning a Routeing Area Update Complete message to the 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.

6.9.1.2.2 Inter SGSN Routeing Area Update

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

Figure 28: Inter SGSN Routeing Area Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P‑TMSI Signature, 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, 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, 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 stops assigning SNDCP N‑PDU numbers to downlink N‑PDUs received, and responds with SGSN Context Response (MM Context, PDP Contexts). 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. Each PDP Context includes the SNDCP Send N‑PDU Number for the next downlink N‑PDU to be sent in acknowledged mode to the MS, the SNDCP Receive N‑PDU Number for the next uplink N‑PDU to be received in acknowledged mode from the MS, 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 sub-clause "Security Function". Ciphering mode shall be set if ciphering is supported. If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS with an appropriate cause.

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 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. If the security functions do not authenticate the MS correctly, then the routeing 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 SNDCP N‑PDU number. 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, 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 HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI) to the HLR.

8) The HLR 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 HLR 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 HLR. 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 HLR.

10) The HLR 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, P‑TMSI Signature, Receive N‑PDU Number). Receive N‑PDU Number contains the acknowledgements for each acknowledged-mode NSAPI 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 by returning a Routeing Area Update Complete (Receive N‑PDU Number) message to the SGSN. Receive N‑PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N‑PDUs successfully transferred before the start of the update procedure. If Receive N‑PDU Number 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, or because the SGSN cannot determine the HLR address to establish the locating updating dialogue, 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 new SGSN is unable to update the PDP context in one or more GGSNs, then the new SGSN shall deactivate the corresponding PDP contexts as described in subclause "PDP Context Deactivation Initiated by SGSN Procedure". This shall not cause the SGSN to reject the routeing area update.

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, 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 subclause "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 HLR, 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.

6.9.1.3 Combined RA / LA Update Procedure

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, or when the MS indicates changed access capabilities to the network, or when a suspended MS is not resumed by the BSS (see subclause "Suspension of GPRS Services"). 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 GSM 03.22), as no combined RA / LA updates are performed during a CS connection.

6.9.1.3.1 Combined Intra SGSN RA / LA Update

The Combined RA / LA Update (intra SGSN) procedure is illustrated in Figure 29. Each step is explained in the following list.

Figure 29: Combined RA / LA Update in the Case of Intra SGSN RA Update Procedure

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

2) Security functions may be executed. This procedure is defined in sub-clause "Security Function". If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS with an appropriate cause.

3) 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, then the 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. The VLR number is translated from the RAI via a table in the SGSN. The VLR creates or updates the association with the SGSN by storing SGSN Number.

4) If the subscriber data in the VLR is marked as not confirmed by the HLR, then the new VLR informs the HLR. The HLR cancels the data in the old VLR and inserts subscriber data in the new VLR (this signalling is not modified from existing GSM signalling and is included here for illustrative purposes):

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

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

6) The 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, or if subscription checking fails, then the SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the SGSN updates the MM context for the MS. A new P‑TMSI may be allocated. The SGSN responds to the MS with Routeing Area Update Accept (P‑TMSI, VLR TMSI, P‑TMSI Signature).

7) If a new P-TMSI or VLR TMSI was received, then the MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the SGSN.

8) The SGSN sends a TMSI Reallocation Complete message to the VLR if the VLR TMSI is confirmed by the MS.

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.

If the Location Update Accept message indicates a reject, then this should be indicated to the MS, and the MS shall not access non-GPRS services until a successful Location Update is performed.

6.9.1.3.2 Combined Inter SGSN RA / LA Update

The Combined RA / LA Update (inter SGSN) procedure is illustrated in Figure 30. Each step is explained in the following list.

Figure 30: Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure

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

2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P‑TMSI Signature, 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, 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 stops assigning SNDCP N‑PDU numbers to downlink N‑PDUs received, and responds with SGSN Context Response (MM Context, PDP Contexts). 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 until the old MM context is cancelled, to allow the old SGSN to forward data packets to the new SGSN. Each PDP Context includes the SNDCP Send N‑PDU Number for the next downlink N‑PDU to be sent in acknowledged mode to the MS, the SNDCP Receive N‑PDU Number for the next uplink N‑PDU to be received in acknowledged mode from the MS, 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 downlink transfer.

3) Security functions may be executed. These procedures are defined in subclause "Security Function". Ciphering mode shall be set if ciphering is supported. If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS with an appropriate cause.

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 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. If the security functions do not authenticate the MS correctly, then the routeing 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 SNDCP N‑PDU number. 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, QoS Negotiated) to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (TID).

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

8) The HLR 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 HLR 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 HLR. 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 HLR.

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

11) 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, then 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. The VLR number is translated from the RAI via a table in the SGSN. The 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 9). The VLR creates or updates the association with the SGSN by storing SGSN Number.

12) 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 (this signalling is not modified from existing GSM signalling and is included here for illustrative purposes):

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

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

14) 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 SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the new SGSN establishes 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, VLR TMSI, P‑TMSI Signature, Receive N‑PDU Number). Receive N‑PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-originated N‑PDUs successfully transferred before the start of the update procedure.

15) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete (Receive N‑PDU Number) message to the SGSN. Receive N‑PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N‑PDUs successfully transferred before the start of the update procedure. If Receive N‑PDU Number 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.

16) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the VLR TMSI is confirmed by the MS.

In the case of a rejected routeing area update operation, due to regional subscription or roaming restrictions, or because the SGSN cannot determine the HLR address to establish the locating updating dialogue, 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 new SGSN is unable to update the PDP context in one or more GGSNs, then the new SGSN shall deactivate the corresponding PDP contexts as described in subclause "PDP Context Deactivation Initiated by SGSN Procedure". This shall not cause the SGSN to reject the routeing area update.

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, 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 subclause "PDP Context Deactivation Initiated by SGSN Procedure". This shall not cause the SGSN to reject the routeing area update.

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.

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

If the Location Update Accept message indicates a reject, then this should be indicated to the MS, and the MS shall not access non-GPRS services until a successful location update is performed.

6.9.1.4 Periodic RA and LA Updates

All GPRS-attached MSs, except MSs in class-B mode of operation engaged in CS communication, shall perform periodic RA updates. MSs that are IMSI-attached and not GPRS-attached shall perform periodic LA updates. Periodic RA updates are equivalent to intra SGSN routeing area updates as described in subclause "Intra SGSN Routeing Area Update", with Update Type indicating periodic RA update. For MSs that are both IMSI-attached and GPRS-attached, the periodic updates depend on the mode of operation of the network.

– If the network operates in mode I, periodic RA updates shall be performed, and periodic LA updates shall not be performed. In this case, the MSC/VLR shall disable implicit detach for GPRS-attached MSs and instead rely on the SGSN to receive periodic RA updates. If periodic RA updates are not received in the SGSN and the SGSN detaches the MS, the SGSN shall notify the MSC/VLR by sending an IMSI Detach Indication message.

– If the network operates in mode II or mode III, both periodic RA updates and periodic LA updates shall be performed independently. RA updates are performed via the Gb interface, and LA updates are performed via the A interface.

The periodic RA update timer in the MS is stopped when an LLC PDU is sent since all sent LLC PDUs set the MM context state to READY. The periodic RA update timer is reset and started when the state returns to STANDBY.

If the MS could not successfully complete the periodic RA update procedure after a retry scheme while the MS was in GPRS coverage, then the MS shall wait a backoff time equal to the periodic LA update timer broadcast by the network before re-starting the periodic RA update procedure.