4.7.1 General

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

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

This subclause describes the basic functions offered by the mobility management (GMM) sublayer at the radio interface (reference point Um/UU). The functionality is described in terms of timers and procedures. During GMM procedures, procedures of CM layer services via the PS domain, e.g. SM, SMS, and SS, are suspended.

4.7.1.1 Lower layer failure

The lower layers shall indicate a logical link failure or an RR sublayer failure or an RRC sublayer failure to the GMM sublayer. The failure indicates an error that cannot be corrected by the lower layers.

4.7.1.2 Ciphering of messages (A/Gb mode only)

If ciphering is to be applied on a GMM context, all GMM messages shall be ciphered except the following messages:

— ATTACH REQUEST;

— ATTACH REJECT;

— AUTHENTICATION AND CIPHERING REQUEST;

— AUTHENTICATION AND CIPHERING RESPONSE;

— AUTHENTICATION AND CIPHERING FAILURE;

— AUTHENTICATION AND CIPHERING REJECT;

— IDENTITY REQUEST;

— IDENTITY RESPONSE;

— ROUTING AREA UPDATE REQUEST; and

— ROUTING AREA UPDATE REJECT.

4.7.1.2a Integrity protection of layer 3 signalling messages (A/Gb mode only and when integrity protection is required)

4.7.1.2a.1 General

The requirements in subclause 4.7.1.2a are only applicable for MSs and networks supporting EC-GSM-IoT (see 3GPP TS 43.064 [159]).

For the MS, integrity protected signalling is mandatory for the GMM messages and SM messagres once a valid UMTS security context exists and has been taken into use. For the network, integrity protected signalling is mandatory for the GMM messages and SM messages once authentication and ciphering procedure is initiated by the network. Integrity protection of all GMM signalling messages and SM messages is the responsibility of the LLC layer. In addition, the GMM layer protects the AUTHENTICATION AND CIPHERING REQUEST message and the AUTHENTICATION AND CIPHERING RESPONSE message by a message authentication code (MAC) calculated at the GMM layer when an authentication takes place in the Authentication and Ciphering procedure. This message authentication code is included in the AUTHENTICATION AND CIPHERING REQUEST message and the AUTHENTICATION AND CIPHERING RESPONSE message. The GMM layer is always using the new UMTS security context derived from the AKA taking place in the Authentication and Ciphering procedure when calculating the message authentication code (MAC) at GMM layer.

The GMM layer activates integrity protection in the LLC layer by providing an indication when integrity protection shall be started.

Integrity protection is initiated in the MS upon request from the network. This is done using the authentication and ciphering procedure at the GMM layer (3GPP TS 43.020 [13] and 3GPP TS 44.064 [78a]).

Details of the integrity protection and verification of GMM signalling messages are specified in 3GPP TS 43.020 [13].

4.7.1.2a.2 Integrity checking of GMM signalling messages in the MS

Except the messages listed below, no GMM signalling messages shall be processed by the receiving GMM entity in the MS or forwarded to the SM entity, unless the use of integrity protection has been successfully negotiated:

– GMM messages:

– IDENTITY REQUEST (only if the requested identification parameter is IMSI)

– ATTACH REJECT (if the cause is not #25)

– AUTHENTICATION AND CIPHERING REJECT

– ROUTING AREA UPDATE REJECT (if the cause is not #25)

– DETACH ACCEPT (for non power-off)

NOTE: These messages are accepted by the MS without integrity protection, as in certain situations they are sent by the network before integrity protection can be activated.

All SM messages shall be integrity protected.

Once the integrity protection has been successfully negotiated, the receiving GMM or SM entity in the MS shall not process any GMM signalling messages unless they have been successfully integrity checked by the LLC layer. If GMM signalling messages, having not successfully passed the integrity check, are received, then the LLC layer in the MS discards that message. The processing of the AUTHENTICATION AND CIPHERING REQUEST message, at authentication, that has not successfully passed the integrity check at GMM layer is specified in subclause 4.7.7.2. If any GMM or SM signalling message is received without integrity protection even though integrity protection has been successfully negotiated, then the GMM layer shall discard this message.

4.7.1.2a.3 Integrity checking of layer 3 signalling messages in the network

Except the messages listed below, no GMM signalling messages shall be processed by the receiving GMM entity in the network or forwarded to the SM entity, unless integrity protection has been successfully negotiated:

– GMM messages:

– ATTACH REQUEST;

– IDENTITY RESPONSE (if requested identification parameter is IMSI);

– AUTHENTICATION AND CIPHERING FAILURE;

– DETACH REQUEST;

– DETACH ACCEPT.

All SM messages are integrity protected.

Once a valid UMTS security context exists, until integrity protection has been successfully negotiated, the receiving GMM entity in the network shall process the following GMM signalling messages, even if the MAC included in the LLC frame carrying the GMM message fails the integrity check or cannot be verified in the LLC layer, as the UMTS security context is not available in the network:

– ATTACH REQUEST;

– IDENTITY RESPONSE (if requested identification parameter is IMSI);

– AUTHENTICATION AND CIPHERING FAILURE;

– DETACH REQUEST (if sent before integrity protection has been activated);

– DETACH ACCEPT;

– ROUTING AREA UPDATE REQUEST;

NOTE: These messages are processed by the GMM layer even when the MAC fails the integrity check or cannot be verified, as in certain situations they can be sent by the MS protected with an UMTS security context that is no longer available in the network.

If an ATTACH REQUEST message fails the integrity check, the network shall authenticate the subscriber before processing the attach request any further.

If a ROUTING AREA UPDATE REQUEST message fails the integrity check, the network shall initiate an re-authentication of the subscriber by initiating an authentication and ciphering procedure.

Once integrity protection has been successfully negotiated, the receiving GMM or SM entity in the network shall not process any GMM or SM signalling messages unless they have been successfully integrity checked by the LLC layer. If any GMM or SM signalling message, having not successfully passed the integrity check, is received, then the LLC layer in the network discards that message. The processing of the AUTHENTICATION AND CIPHERING RESPONSE message when authentication is taking place, that has not successfully passed the integrity check at GMM layer is specified in subclause 4.7.7.3. If any GMM or SM signalling message is received, as not integrity protected even though integrity protection has been successfully negotiated, then the GMM layer shall discard this message.

4.7.1.2a.4 Establishment of integrity protection of layer 3 signalling messages

Establishment of integrity protection of layer 3 signalling messages and optionally user plane data is done during the attach procedure. The MS shall indicate support for integrity protection in the MS network capability IE included in the ATTACH REQUEST message and the ROUTING AREA UPDATE REQUEST message to the network.

When an MS sends an ATTACH REQUEST message or a ROUTING AREA UPDATE REQUEST message, then if the MS has no UMTS security context, it shall send the ATTACH REQUEST or the ROUTING AREA UPDATE REQUEST message without integrity protection to the network. If the network supports integrity protection, then the network activates integrity protection by initiating an authentication and ciphering procedure. The network selects an integrity algorithm among the supported integrity algorithms indicated by the MS in the MS network capability IE. After successful completion of the authentication and ciphering procedure, all layer 3 signalling messages sent between the MS and network are integrity protected in the LLC layer using the new UMTS security context.

When an MS sends an ATTACH REQUEST message or a ROUTING AREA UPDATE REQUEST message, then if the MS has a UMTS security context, it shall send the ATTACH REQUEST or the ROUTING AREA UPDATE REQUEST message integrity protected with the current UMTS security context to the network. The MS shall include the CKSN indicating the current UMTS security context value in the initial ATTACH REQUEST message or a ROUTING AREA UPDATE REQUEST message. The MS shall use the integrity algorithm identified by the stored integrity algorithm identifier. The network shall check whether the CKSN included in the initial ATTACH REQUEST message or the ROUTING AREA UPDATE REQUEST message belongs to an UMTS security context available in the network, and if yes, then the network re-establishes integrity protection of layer 3 signalling messages in the LLC layer:

– by replying with a GMM message (ATTACH ACCEPT or ROUTING AREA UPDATE ACCEPT) that is integrity protected in LLC layer by using the current UMTS security context. From this time onward, all layer 3 signalling messages exchanged between the MS and the network are sent integrity protected, except for the messages specified in subclause 4.7.1.2a; or

– by initiating an authentication and ciphering procedure. This procedure can be used by the network to select a new integrity algorithm different from the one currently used by the MS.

NOTE: Even if the message authentication code protecting the ATTACH REQUEST or the ROUTING AREA UPDATE message in the LLC layer cannot be verified in the network due to the integrity key and the integrity algorithm in the LLC layer at the network not having been configured yet for this MS, the network progresses the attach procedure and the routing atra updating procedure at the GMM layer anyway without having to run a new authentication and ciphering procedure if the network decides to re-use the same encryption- and integrity keys and the same ciphering and integrity algorithms and not run a re-authentication.

4.7.1.2a.5 Optional establishment of integrity protection in the user plane

If an MS supports integrity protection of user plane data, then the MS shall indicate in the MS network capability IE to the network that it supports integrity protection of user plane data when it sends an ATTACH REQUEST message or a ROUTING AREA UPDATE REQUEST message. If the network supports integrity protection of the user plane data, then the network shall indicate in the ATTACH ACCEPT message or the ROUTING AREA UPDATE ACCEPT message to the MS that integrity protection of user plane data shall be used.

4.7.1.2a.6 Change of security keys

When the network initiates a re-authentication to create a new UMTS security context, the AUTHENTICATION AND CIPHERING REQUEST message and AUTHENTICATION AND CIPHERING RESPONSE message exchanged during the authentication and ciphering procedure are integrity protected with the new UMTS security context at GMM layer by including a MAC. The AUTHENTICATION AND CIPHERING REQUEST message and AUTHENTICATION AND CIPHERING RESPONSE message may be also integrity protected at the LLC layer using the current UMTS security context, if any. Both UE and network shall continue to use the current UMTS security context, until the network initiates a re-authentication in the authentication and ciphering procedure. The AUTHENTICATION AND CIPHERING REQUEST message sent by the network includes the CKSN of the new UMTS security context to be used. The SGSN shall send the AUTHENTICATION AND CIPHERING REQUEST message integrity protected with the new UMTS security context at GMM layer by including a MAC, but unciphered. When the UE responds with an AUTHENTICATION AND CIPHERING RESPONSE message, it shall send the message integrity protected with the new UMTS security context at GMM layer by including a MAC, but unciphered.

The UE shall take the new UMTS security context and the indicated integrity algorithm and encryption algorithm received in the AUTHENTICATION AND CIPHERING REQUEST message, into use in the LLC layer after sending the AUTHENTICATION AND CIPHERING RESPONSE message. The network shall take the new UMTS security context and the indicated integrity algorithm and encryption algorithm sent in the AUTHENTICATION AND CIPHERING REQUEST message, into use in the LLC layer in the network after receiving the AUTHENTICATION AND CIPHERING RESPONSE message and a successful check of the RES.

4.7.1.3 P-TMSI signature

The network may assign a P-TMSI signature to an MS in an attach, routing area update, or P-TMSI reallocation procedure. Only in combination with a valid P-TMSI, this P-TMSI signature is used by the MS for authentication and identification purposes in the subsequent attach, routing area update or detach procedure. If the MS has no valid P-TMSI it shall not use the P-TMSI signature in the subsequent attach, routing area update or detach procedure. Upon successful completion of the subsequent attach or routing area update procedure, the used P-TMSI signature shall be deleted. Upon completion of an MS initiated detach procedure, the used P-TMSI signature shall be deleted. Upon completion of a network initiated detach procedure the P-TMSI signature shall be kept, unless explicitly specified otherwise in subclause 4.7.4.2.2.

4.7.1.4 Radio resource sublayer address handling

In A/Gb mode, while a packet TMSI (P-TMSI) is used in the GMM sublayer for identification of an MS, a temporary logical link identity (TLLI) is used for addressing purposes at the RR sublayer.

In Iu mode a Radio Network Temporary Identity (RNTI) identifies a user between the MS and the UTRAN or GERAN. The relationship between RNTI and IMSI is known only in the MS and in the UTRAN, see 3GPP TS 25.301 [128].

4.7.1.4.1 Radio resource sublayer address handling (A/Gb mode only)

This subclause describes how the RR addressing is managed by GMM. For the detailed coding of the different TLLI types and how a TLLI can be derived from a P-TMSI, see 3GPP TS 23.003 [10].

If the MS is configured for "AttachWithIMSI" as specified in 3GPP TS 24.368 [135] or 3GPP TS 31.102 [112] and is entering a new PLMN which is neither the registered PLMN nor in the list of equivalent PLMNs, the MS should proceed as specified for case ii) below and use a randomly selected random TLLI for the transmission of the ATTACH REQUEST message.

For all other cases, the MS shall determine the TLLI as follows:

For an MS not supporting S1 mode, two cases can be distinguished:

– a valid P-TMSI is available in the MS; or

– no valid P-TMSI is available in the MS.

i) valid P-TMSI available

If the MS has stored a valid P-TMSI, the MS shall derive a foreign TLLI from that P-TMSI and shall use it for transmission of the:

– ATTACH REQUEST message of any GPRS combined/non-combined attach procedure; other GMM messages sent during this procedure shall be transmitted using the same foreign TLLI until the ATTACH ACCEPT message or the ATTACH REJECT message is received; and

– ROUTING AREA UPDATE REQUEST message of a combined/non-combined RAU procedure if the MS has entered a new routing area, or if the GPRS update status is not equal to GU1 UPDATED. Other GMM messages sent during this procedure shall be transmitted using the same foreign TLLI, until the ROUTING AREA UPDATE ACCEPT message or the ROUTING AREA UPDATE REJECT message is received.

After a successful GPRS attach or routing area update procedure, independent of whether a new P-TMSI is assigned, if the MS has stored a valid P-TMSI then the MS shall derive a local TLLI from the stored P-TMSI and shall use it for addressing at lower layers.

NOTE 1: Although the MS derives a local TLLI for addressing at lower layers, the network should not assume that it will receive only LLC frames using a local TLLI. Immediately after the successful GPRS attach or routing area update procedure, the network must be prepared to continue accepting LLC frames from the MS still using the foreign TLLI.

ii) no valid P-TMSI available

When the MS has not stored a valid P-TMSI, i.e. the MS is not attached to GPRS, the MS shall use a randomly selected random TLLI for transmission of the:

– ATTACH REQUEST message of any combined/non-combined GPRS attach procedure.

The same randomly selected random TLLI value shall be used for all message retransmission attempts and for the cell updates within one attach attempt.

Upon receipt of an ATTACH REQUEST message, the network shall assign a P-TMSI to the MS. The network derives a local TLLI from the assigned P-TMSI, and transmits the assigned P-TMSI to the MS.

Upon receipt of the assigned P-TMSI, the MS shall derive the local TLLI from this P-TMSI and shall use it for addressing at lower layers.

NOTE 2: Although the MS derives a local TLLI for addressing at lower layers, the network should not assume that it will receive only LLC frames using a local TLLI. Immediately after the successful GPRS attach, the network must be prepared to continue accepting LLC frames from the MS still using the random TLLI.

In both cases the MS shall acknowledge the reception of the assigned P-TMSI to the network. After receipt of the acknowledgement, the network shall use the local TLLI for addressing at lower layers.

For an MS supporting S1 mode, the following five cases can be distinguished:

a) the TIN indicates "P-TMSI" or "RAT‑related TMSI" and the MS holds a valid P-TMSI and a RAI;

b) the TIN indicates "GUTI" and the MS holds a valid GUTI allocated by an MME;

c) the TIN is deleted and the MS holds a valid P-TMSI and RAI;

d) the TIN is deleted and the MS holds a valid GUTI allocated by an MME, but no valid P-TMSI and RAI; or

e) none of the previous cases is fulfilled.

In case a) the MS shall derive a foreign TLLI from the P-TMSI and proceed as specified for case i) above.

In case b), the MS shall derive a P-TMSI from the GUTI and then a foreign TLLI from this P-TMSI and proceed as specified for case i) above.

NOTE 3: The mapping of the GUTI to the P-TMSI is specified in 3GPP TS 23.003 [10].

In case c) the MS shall derive a foreign TLLI from the P-TMSI and proceed as specified for case i) above.

In case d) the MS shall derive a P-TMSI from the GUTI and then a foreign TLLI from this P-TMSI and proceed as specified for case i) above.

In case e) the MS shall proceed as as specified for case ii) above.

For transmission of an ATTACH REQUEST message, or a ROUTING AREA UPDATE REQUEST message after a routing area change, the MS also provides the lower layers with the DCN-ID according to the following rules:

a) if a DCN-ID for the PLMN code of the selected PLMN is available in the MS, the MS shall provide this DCN-ID to the lower layers; or

b) if no DCN-ID for the PLMN code of the selected PLMN is available but a Default_DCN_ID value is available in the MS, as specified in 3GPP TS 24.368 [135] or in USIM file NAS_CONFIG as specified in 3GPP TS 31.102 [112], the MS shall provide the Default_DCN_ID value to the lower layers.

4.7.1.5 P-TMSI handling

4.7.1.5.1 P-TMSI handling in A/Gb mode

If a new P-TMSI is assigned by the network the MS and the network shall handle the old and the new P-TMSI as follows:

Upon receipt of a GMM message containing a new P-TMSI the MS shall consider the new P-TMSI and new RAI and also the old P-TMSI and old RAI as valid in order to react to paging requests and downlink transmission of LLC frames. For uplink transmission of LLC frames the new P-TMSI shall be used.

NOTE: For the case of multiple consecutive P-TMSI REALLOCATION COMMAND messages, the old P-TMSI is the latest P-TMSI included by the network in a previous message different from the multiple consecutive P-TMSI REALLOCATION COMMAND messages.

The MS shall consider the old P-TMSI and old RAI as invalid as soon as an LLC frame is received with the local TLLI derived from the new P-TMSI.

Upon the transmission of a GMM message containing a new P-TMSI the network shall consider the new P-TMSI and new RAI and also the old P-TMSI and old RAI as valid in order to be able to receive LLC frames from the MS.

The network shall consider the old P-TMSI and old RAI as invalid as soon as an LLC frame is received with the local TLLI derived from the new P-TMSI.

4.7.1.5.2 P-TMSI handling in Iu mode

If a new P-TMSI is assigned by the network the MS and the network shall handle the old and the new P-TMSI as follows:

Upon receipt of a GMM message containing a new P-TMSI the MS shall consider the new P-TMSI and new RAI as valid. Old P-TMSI and old RAI are regarded as invalid.

The network shall consider the old P-TMSI and old RAI as invalid as soon as an acknowledge message (e.g. ATTACH COMPLETE, ROUTING AREA UPDATE COMPLETE and P-TMSI REALLOCATION COMPLETE) is received.

4.7.1.5.3 Void

4.7.1.5.4 Void

4.7.1.6 Change of network mode of operation

In the following tables below the abbreviations ‘A/Gb mode I’ and ‘A/Gb mode II’ are used for network operation mode I and II in A/Gb mode.

In the following tables below the abbreviations ‘Iu mode I’ and ‘Iu mode II’ are used for network operation modes I and II in Iu mode.

4.7.1.6.1 Change of network mode of operation in A/Gb mode (A/Gb mode only)

Whenever an MS moves to a new RA, the procedures executed by the MS depend on the network mode of operation in the old and new routing area.

In case the MS is in state GMM REGISTERED or GMM ROUTING AREA UPDATING INITIATED and is in operation mode A or B, the MS shall execute according to table 4.7.1.6.1-1:

Table 4.7.1.6.1-1/3GPP TS 24.008: Mode A or B

Network operation mode change	Procedure to execute
I → II (***)	Normal Location Update(*), followed by a Normal Routing Area Update
II → I	Combined Routing Area Update with IMSI attach(**)

(*) Intended to remove the Gs association in the MSC/VLR.

(**) Intended to establish the Gs association in the MSC/VLR.

(***) If the MS that needs only GPRS services and "SMS-only service" moves to a new routing area, see subclause 4.1.1.2.2.

Further details are implementation issues.

4.7.1.6.2 Change of network mode of operation in Iu mode (Iu mode only)

Whenever an MS moves to a new RA, the procedures executed by the MS depend on the network mode of operation in the old and new routing area.

In case the MS is in state GMM-REGISTERED or GMM-ROUTING-AREA-UPDATING-INITIATED and is in operation mode A, the MS shall execute:

Table 4.7.1.6.4/3GPP TS 24.008: Mode A

Network operation mode change	Procedure to execute
I → II (***)	Normal Location Update(*), followed by a Normal Routing Area Update
II → I	Combined Routing Area Update with IMSI attach(**)

(*) Intended to remove the Gs association in the MSC/VLR.

(**) Intended to establish the Gs association in the MSC/VLR.

(***) If the MS that needs only GPRS services and "SMS-only service" moves to a new routing area, see subclause 4.1.1.2.2.

Further details are implementation issues.

4.7.1.6.3 Change of network mode of operation at Iu mode to A/Gb mode inter-system change

Whenever an MS moves to a new RA supporting the A/Gb mode radio interface, the procedures executed by the MS depend on the network mode of operation in the old and new routing area.

In case the MS is in state GMM-REGISTERED or GMM-ROUTING-AREA-UPDATING-INITIATED and is in operation mode:

a) A in Iu mode, an MS that changes to GPRS operation mode A or B in A/Gb mode shall execute:

Table 4.7.1.6.5/3GPP TS 24.008: Mode A in Iu mode changing to GPRS mode A or B in A/Gb mode

Network operation mode change	Procedure to execute
Iu mode I → A/Gb mode I	Combined Routing Area Update
Iu mode II → A/Gb mode I	Combined Routing Area Update with IMSI attach(**)
Iu mode I → A/Gb mode II (***)	Normal Location Update(*), followed by a Normal Routing Area Update

b) C in Iu mode, the MS shall change to GPRS operation mode C in A/Gb mode and shall execute the normal Routing Area Update procedure.

c) CS in Iu mode, the MS shall execute the normal Location Update procedure.

(*) Intended to remove the Gs association in the MSC/VLR.

(**) Intended to establish the Gs association in the MSC/VLR.

(***) If the MS that needs only GPRS services and "SMS-only service" moves to a new routing area, see subclause 4.1.1.2.2.

Further details are implementation issues.

4.7.1.6.4 Change of network mode of operation at A/Gb mode to Iu mode inter-system change

Whenever an MS moves to a new RA supporting the Iu mode radio interface, the procedures executed by the MS depend on the network mode of operation in the old and new routing area.

In case the MS is in state GMM-REGISTERED or GMM-ROUTING-AREA-UPDATING-INITIATED and is in operation mode:

a) A or B in A/Gb mode, the MS shall change to operation mode A in Iu mode and shall execute:

Table 4.7.1.6.8/3GPP TS 24.008: Mode A or B in A/Gb mode changing to mode A in Iu mode

Network operation mode change	Procedure to execute
A/Gb mode I → Iu mode I	Combined Routing Area Update
A/Gb mode II → Iu mode I	Combined Routing Area Update with IMSI attach(**)
A/Gb mode I → Iu mode II (***)	Normal Location Update(*), followed by a Normal Routing Area Update
A/Gb mode II → Iu mode II (***)	Normal Location Update if a new LA is entered, followed by a Normal Routing Area Update

b) C in A/Gb mode, an MS that changes to operation mode C in Iu mode shall execute a Normal Routing Area Update.

(*) Intended to remove the Gs association in the MSC/VLR.

(**) Intended to establish the Gs association in the MSC/VLR.

(***) If the MS that needs only GPRS services and "SMS-only service" moves to a new routing area, see subclause 4.1.1.2.2.

Further details are implementation issues.

4.7.1.7 Intersystem change between A/Gb mode and Iu mode

For the Iu mode to A/Gb mode and A/Gb mode to Iu mode intersystem change the following cases can be distinguished:

a) Intersystem change between cells belonging to different RA’s:

The procedures executed by the MS depends on the network mode of operation in the old and new RA. If a change of the network operation mode has occurred in the new RA, then the MS shall behave as specified in subclause 4.7.1.6. If no change of the network operation mode has occurred in the new RA, then the MS shall initiate the normal or combined routing area updating procedure depending on the network operation mode in the current RA.

b) Intersystem change between cells belonging to the same RA:

1) If the READY timer is running in the MS in A/Gb mode before or after the inter-system change occurs,or the MS is in PMM-CONNECTED mode in Iu mode, before the inter-system change occurs then the MS shall perform a normal or combined routing area updating procedure depending on the network mode of operation in the current RA.

2) If the READY timer is not running in the MS in A/Gb mode before the inter-system change occurs, or the MS is in PMM-IDLE mode in Iu mode before the inter-system change and the READY timer is not running in the MS in A/Gb mode after the intersystem change, then, unless a routing area updating procedure is required according to case c) or case b) 3) below or according to subclause 4.7.5.1 and 4.7.5.2.1, the MS shall not perform a routing area updating procedure until uplink user data or signalling information needs to be sent from the MS to the network.

– If the MS is in the same access network(i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling messages, the procedures defined for that access system shall be followed. This shall be sending of an LLC PDU in an A/Gb mode cell or initiating the service request procedure in an Iu mode cell.

– If the MS is in a different access network (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling messages, the normal or combined routing area updating procedure shall be performed depending on the network operation mode in the current RA, before the sending of user data or signalling messages. If the signalling message is a DETACH REQUEST indicating "power off", the routing area updating procedure need not to be performed.

– If the periodic routing area update timer expires the MS shall initiate the periodic routing area updating procedure.

3) If the READY timer is not running in the MS in A/Gb mode or the MS is in PMM-IDLE mode in Iu mode, then the MS shall perform a normal or combined routing area updating procedure depending on the network mode of operation in the current RA if the MS is required to perform routing area updating for IMS voice termination as specified in annex P.3.

4) If the READY timer is not running in the network in A/Gb mode or the network is in PMM-IDLE mode in Iu mode, then the network shall page the MS if downlink user data or signalling information needs to be sent from the network to the MS. This shall include both A/Gb mode and Iu mode cells.

– If the MS receives the paging indication in the same access network (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling information, the MS shall send any LLC PDU in a A/Gb mode cell or shall initiate the service request procedure indicating service type "paging response" in an Iu mode cell.

– If the MS receives the paging indication in a different access network (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling information, the MS shall perform a normal or combined routing area updating procedure depending on the network operation mode in the current RA.

c) Intersystem handover from A/Gb mode to Iu mode during a CS connection:

After the successful completion of the handover from an A/Gb mode cell to an Iu mode cell, an MS which has performed the GPRS suspension procedure in Gb mode (see 3GPP TS 44.018 [84]) (i.e. an MS in MS operation mode B or an DTM MS in a A/Gb mode cell that does not support DTM) shall perform a normal routing area updating procedure in the Iu mode cell in order to resume the GPRS services in the network, before sending any other signalling messages or user data.

4.7.1.7a Intersystem change from S1 mode to A/Gb mode or S1 mode to Iu mode with ISR activated

If ISR is activated and the MS returns from S1 mode to a cell belonging to a RA which is different from the RA where the MS is registered, the MS initiates a normal or combined routing area updating procedure depending on the network operation mode in the current RA.

If ISR is activated and the MS returns from S1 mode to a cell belonging to the RA where the MS is registered, the following cases can be distinguished:

a) Inter-system change due to PS handover:

If the PS handover is to A/Gb mode, the MS initiates a normal or combined routing area updating procedure depending on the network operation mode in the current RA.

b) Inter-system change not due to PS handover:

1) If the READY timer is running in the MS after the inters-ystem change occurs, then the MS shall perform a normal or combined routing area updating procedure depending on the network mode of operation in the current RA.

2) If the READY timer is not running in the MS in A/Gb mode or the MS is in PMM-IDLE mode in Iu mode after the intersystem change occurs, unless a routing area updating procedure is required according to subclause 4.7.5.1 and 4.7.5.2.1, the MS shall not perform a routing area updating procedure until uplink user data or signalling information needs to be sent from the MS to the network.

– If the MS is in the same access network, (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling messages in a cell belonging to the RA where the MS is registered, the procedures defined for that access system shall be followed. This shall be sending of an LLC PDU in a A/Gb mode cell or initiating the SERVICE REQUEST procedure in an Iu mode cell.

– If the MS is in a different access network (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling messages in a cell belonging to the RA where the MS is registered, the normal or combined RA update procedure shall be performed depending on the network operation mode in the current RA, before the sending of user data or signalling messages. If the signalling message is a DETACH REQUEST indicating "power off", the routing area updating procedure need not be performed.

– If the periodic routing area update timer expires the MS shall initiate the periodic RA update procedure.

3) If the READY timer is not running in the network in A/Gb mode or the network is in PMM-IDLE mode in Iu mode, then the network shall page the MS if downlink user data or signalling information needs to be sent from the network to the MS. This shall include both A/Gb mode and Iu mode cells.

– If the MS receives the paging indication in the same access network (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling information in a cell belonging to the RA where the MS is registered, the MS shall send any LLC PDU in a A/Gb mode cell or shall initiate the service request procedure indicating service type "paging response" in an Iu mode cell.

– If the MS receives the paging indication in a different access network (i.e. A/Gb mode or Iu mode), as when it last sent user data or signalling information in a cell belonging to the RA where the MS is registered, the MS shall perform normal or combined routing area updating procedure shall be performed depending on the network operation mode in the current RA.

4.7.1.7b Intersystem change from S1 mode to A/Gb mode or S1 mode to Iu mode for eCall only MS capable of eCall over IMS

If an eCall only MS (as determined by information configured in USIM) capable of eCall over IMS returns from S1 mode to A/Gb or Iu mode, the MS shall:

a) if timer T3444 is running, start timer T3242 with the time left on timer T3444, and stop timer T3444;

b) if timer T3445 is running, start timer T3243 with the time left on timer T3445, and stop timer T3445;

c) if the MS is attached for GPRS services only and timer T3444 or timer T3445 is running:

– perform a combined routing area updating procedure with IMSI attach if the network operates in network operation mode I; and

– perform a routing area updating procedure and a location area updating procedure if the network operates in network operation mode II; and

d) if the MS is attached for both GPRS services and non-GPRS services and timer T3444 or timer T3445 is running:

– perform a combined routing area updating procedure if the network operates in network operation mode I; and

– perform a routing area updating procedure and a location are updating procedure if the network operates in network operation mode II.

NOTE: Timers T3444 and T3445 are specified in 3GPP TS 24.301 [120].

4.7.1.7c Return to packet idle mode for eCall only MS capable of eCall over IMS

If an eCall only MS (as determined by information configured in USIM) capable of eCall over IMS returns to packet idle mode following the release of a call to an HPLMN designated non-emergency MSISDN or URI for test or terminal reconfiguration service which was handed over from S1 mode and timer T3243 is not running, the MS shall start timer T3243.

4.7.1.8 List of forbidden PLMNs for GPRS service

The Mobile Equipment shall contain a list of "forbidden PLMNs for GPRS service". This lists shall be erased when the MS is switched off or when the SIM/USIM is removed or upon the expiry of the timer T3245 as described in subclause 4.1.1.6. The PLMN identification received on the BCCH shall be added to the list whenever a GPRS attach or routing area update is rejected by the network with the cause "GPRS services not allowed in this PLMN" or whenever a GPRS detach is initiated by the network with the cause "GPRS services not allowed in this PLMN".

In a shared network, the MS shall choose one of the PLMN identities as specified in 3GPP TS 23.122 [14]. The PLMN identity selected for a GPRS attach procedure, or the PLMN identity used to construct the RAI that triggered the routing area updating procedure shall be added to the list of "forbidden PLMNs for GPRS service" whenever such a procedure is rejected by the network with the cause "GPRS services not allowed in this PLMN". Whenever a GPRS detach is initiated by the network with the cause "GPRS services not allowed in this PLMN", the PLMN identity that was selected for GPRS attach procedure or routing area update procedure shall be added to the list of "forbidden PLMNs for GPRS service".

The maximum number of possible entries in this list is implementation dependent, but must be at least one entry. When the list is full and a new entry has to be inserted, the oldest entry shall be deleted.

4.7.1.8a Establishment of the PS signalling connection (Iu mode only)

In order to route the NAS message to an appropriate SGSN, the MS NAS provides the lower layers with the routing parameter according to the following rules:

a) if the TIN indicates "P-TMSI" or "RAT-related TMSI", and the MS holds a valid P-TMSI, the MS NAS shall provide the lower layers with the P-TMSI;

b) if the TIN indicates "GUTI" and the MS holds a valid GUTI allocated by an MME, the MS NAS shall provide the lower layers with the P-TMSI mapped from the GUTI (see 3GPP TS 23.003 [10]);

c) if the TIN is not available and the MS holds a valid P-TMSI, the MS NAS shall provide the lower layers with the P-TMSI; or

d) if the TIN is not available and the MS holds a valid GUTI allocated by an MME, but no valid P-TMSI, the MS NAS shall provide the lower layers with the P-TMSI mapped from the GUTI (see 3GPP TS 23.003 [10]).

When an ATTACH REQUEST message, or a ROUTING AREA UPDATE REQUEST message after a routing area change, is sent to establish a PS signalling connection, the MS NAS also provides the lower layers with the DCN-ID according to the following rules:

a) if a DCN-ID for the PLMN code of the selected PLMN is available in the MS, this DCN-ID the MS NAS shall provide this DCN-ID to the lower layers; or

b) if no DCN-ID for the PLMN code of the selected PLMN is available but a Default_DCN_ID value is available in the MS, as specified in 3GPP TS 24.368 [135] or in USIM file NAS_CONFIG as specified in 3GPP TS 31.102 [112], the Default_DCN_ID value MS NAS shall provide the Default_DCN_ID value to the lower layers.

4.7.1.9 Release of the PS signalling connection (Iu mode only)

In Iu mode, to allow the network to release the PS signalling connection (see 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]) the MS:

a) shall start the timer T3340 if the MS receives any of the reject cause values #11, #12, #13, #15 or #25;

b) shall start the timer T3340 if the network indicates "no follow-on proceed" in the ROUTING AREA UPDATE ACCEPT or ATTACH ACCEPT message and user plane radio access bearers have not been setup;

c) shall start the timer T3340 if the MS receives a DETACH ACCEPT message and the MS has set the detach type to "IMSI detach" in the DETACH REQUEST message and user plane radio access bearers have not been set up; or

d) may start the timer T3340 if the MS receives any of the reject cause values #3, #6, #7 or #8 or if it receives an AUTHENTICATION AND CIPHERING REJECT message.

Upon expiry of T3340, the MS shall release the established PS signalling connection (see 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]).

Upon release of the established PS signalling connection, if timer T3243 is not running, the MS shall start timer T3243 when:

– the MS is an eCall only MS (as determined by information configured in USIM);

– the MS is capable of eCall over IMS; and

– the PS signalling connection that was released had been established for a call to an HPLMN designated non-emergency MSISDN or URI for test or terminal reconfiguration service which was handed over from S1 mode.

In case b, if the MS has signalling pending, then it shall request a new PS signalling connection for further signalling.

In case b and c,

– upon an indication from the lower layers that radio accesss bearer(s) is set up, the MS shall stop timer T3340 and may send uplink signalling via the existing PS signalling connection or user data via radio access bearer(s). If the MS is establishing a PDN connection for emergency bearer services or the MS is initiating a service request procedure to send user data for emergency bearer services, the MS shall send the uplink signalling via the existing PS signalling connection;

– upon receipt of a REQUEST PDP CONTEXT ACTIVATION message, MODIFY PDP CONTEXT REQUEST message, DEACTIVATE PDP CONTEXT REQUEST message, REQUEST SECONDARY PDP CONTEXT ACTIVATION message or REQUEST MBMS CONTEXT ACTIVATION message, the MS shall stop timer T3340 and may send uplink signalling via the existing PS signalling connection. If the MS is establishing a PDN connection for emergency bearer services or the MS is initiating a service request procedure to send user data for emergency bearer services, the MS shall send the uplink signalling via the existing PS signalling connection; or

– upon receipt of a DETACH REQUEST message, the MS shall stop timer T3340 and respond to the network initiated GPRS detach as specified in subclause 4.7.4.2.

If the MS receives the "Extended wait time" for PS domain from the lower layers when no attach, routing area updating or service request procedure is ongoing, the MS shall ignore the "Extended wait time".

If the MS needs to perform PLMN selection, the MS may release the established PS signalling connection (see 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]).

4.7.1.10 Handling of 3GPP PS data off

An MS, which supports 3GPP PS data off (see 3GPP TS 23.060 [74]), can be configured with up to two lists of 3GPP PS data off exempt services as specified in 3GPP TS 24.368 [135] or in the EF_{3GPPPSDATAOFF} USIM file as specified in 3GPP TS 31.102 [112]:

– a list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN (if the EHPLMN list is present); and

– a list of 3GPP PS data off exempt services to be used in the VPLMN.

If only the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN (if the EHPLMN list is present) is configured at the MS, this list shall be also used in the VPLMN.

If the MS supports 3GPP PS data off, the MS shall provide the 3GPP PS data off UE status in the protocol configuration options IE during PDP context activation procedure (see subclause 6.1.3.1).

The network informs the MS about the support of 3GPP PS data off during PDP context activation procedure as specified in subclause 6.1.3.1. If 3GPP data off support is not indicated in the protocol configuration options IE in the ACTIVATE PDP CONTEXT ACCEPT message, the MS shall not indicate any change of 3GPP PS data off UE status for the PDN connection established by the PDP context activation procedure; otherwise the MS shall indicate change of the 3GPP PS data off UE status for the PDN connection by using the PDP context modification procedure as specified in subclause 6.1.3.3. If the network does not provide indication of support of 3GPP PS data off during PDP context activation procedure, the MS behaviour for non-exempt service requests from the network is implementation dependent.

When the 3GPP PS data off UE status is "activated":

a) the MS does not send uplink IP packets except:

– for those services indicated in the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN (if the EHPLMN list is present) as specified in 3GPP TS 24.368 [135] when the MS is in its HPLMN or EHPLMN (if the EHPLMN list is present);

– for those services indicated in the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN (if the EHPLMN list is present) when the MS is in the VPLMN, if only the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN (if the EHPLMN list is present) is configured to the MS as specified in 3GPP TS 24.368 [135];

– for those services indicated in the list of 3GPP PS data off exempt services to be used in the VPLMN when the MS is in the VPLMN, if the list of 3GPP PS data off exempt services to be used in the VPLMN is configured to the MS as specified in 3GPP TS 24.368 [135];

– for those services indicated in the EF_{3GPPPSDATAOFF} USIM file as specified in 3GPP TS 31.102 [112]; and

– any uplink traffic due to procedures specified in 3GPP TS 24.229 [13D]; and

b) the MS does not send uplink non-IP user data packets.

Otherwise the MS sends uplink user data packets without restriction.

NOTE: If the MS supports 3GPP PS data off, uplink IP packets are filtered as specified in 3GPP TS 24.229 [13D] in subclause B.3.1.5.