5.4 EMM common procedures

24.3013GPPNon-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)Release 18Stage 3TS

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

5.4.1 GUTI reallocation procedure

5.4.1.1 General

The purpose of the GUTI reallocation procedure is to allocate a GUTI and optionally to provide one or more of the following to a particular UE:

– a new TAI list;

– a new DCN-ID; and

– in WB-S1 mode, if the UE supports RACS, either a UE radio capability ID deletion indication or a UE radio capability ID.

The reallocation of a GUTI is performed by the unique procedure defined in this clause. This procedure can only be initiated by the MME in state EMM-REGISTERED.

The GUTI can also be implicitly reallocated at attach or tracking area updating procedures. The implicit reallocation of a GUTI is described in the clauses which specify these procedures (see clause 5.5.1 and 5.5.3).

The PLMN identity in the GUTI indicates the current registered PLMN.

NOTE 1: The GUTI reallocation procedure is usually performed in ciphered mode.

NOTE 2: Normally, the GUTI reallocation will take place in conjunction with another mobility management procedure, e.g. as part of tracking area updating.

5.4.1.2 GUTI reallocation initiation by the network

The MME shall initiate the GUTI reallocation procedure by sending a GUTI REALLOCATION COMMAND message to the UE and starting the timer T3450 (see example in figure 5.4.1.2.1).

The GUTI REALLOCATION COMMAND message shall include a GUTI and may include one or more of the following:

– a TAI list;

– a DCN-ID; and

– in WB-S1 mode, if the UE supports RACS, either a UE radio capability ID deletion indication or a UE radio capability ID.

Figure 5.4.1.2.1: GUTI reallocation procedure

5.4.1.3 GUTI reallocation completion by the UE

Upon receipt of the GUTI REALLOCATION COMMAND message, the UE shall:

– store the GUTI;

– store the TAI list, if provided;

– store the DCN-ID, if provided;

– in WB-S1 mode, if the UE supports RACS and the GUTI REALLOCATION COMMAND message includes:

a) a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", delete any network-assigned UE radio capability IDs associated with the registered PLMN stored at the UE, then the UE shall, after the completion of the ongoing GUTI reallocation procedure, initiate a tracking area updating procedure as specified in clause 5.5.3. If the UE has an applicable manufacturer-assigned UE radio capability ID for the current UE radio configuration, the UE shall include the UE radio capability ID availability IE set to "UE radio capability ID available" in the TRACKING AREA UPDATE REQUEST message; or

b) a UE radio capability ID IE, store the UE radio capability ID as specified in annex C; and

– send a GUTI REALLOCATION COMPLETE message to the MME.

The UE considers the new GUTI as valid and the old GUTI as invalid. If the UE receives a new TAI list in the GUTI REALLOCATION COMMAND message, the UE shall consider the new TAI list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAI list as valid.

If the GUTI REALLOCATION COMMAND message contains the DCN-ID IE, then the UE shall store the included DCN-ID value together with the PLMN code of the registered PLMN in a DCN-ID list in a non-volatile memory in the ME as specified in annex C.

5.4.1.4 GUTI reallocation completion by the network

Upon receipt of the GUTI REALLOCATION COMPLETE message, the MME shall stop the timer T3450 and consider the new GUTI as valid and the old GUTI as invalid. If a new TAI list is provided in the GUTI REALLOCATION COMMAND message, the MME shall consider the new TAI list as valid and the old TAI list as invalid.

5.4.1.5 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Transmission failure of GUTI REALLOCATION COMPLETE message indication with TAI change from lower layers

If the current TAI is not in the TAI list, the GUTI reallocation procedure shall be aborted and a tracking area updating procedure shall be initiated.

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing procedure that triggered the GUTI reallocation procedure.

b) Transmission failure of GUTI REALLOCATION COMPLETE message indication without TAI change from lower layers

It is up to the UE implementation how to re-run the ongoing procedure that triggered the GUTI reallocation procedure.

5.4.1.6 Abnormal cases on the network side

The following abnormal cases can be identified:

a) Lower layer failure

If a lower layer failure is detected before the GUTI REALLOCATION COMPLETE message is received, the old and the new GUTI shall be considered as valid until the old GUTI can be considered as invalid by the network. If a new TAI list was provided in the GUTI REALLOCATION COMMAND message, the old and new TAI list shall also be considered as valid until the old TAI list can be considered as invalid by the network.

During this period the network:

– may first use the old S-TMSI from the old GUTI for paging within the area defined by the old TAI list for an implementation dependent number of paging attempts for network originated transactions. If a new TAI list was provided with old GUTI in the GUTI REALLOCATION COMMAND message, the new TAI list should also be used for paging. Upon response from the UE, the network may re-initiate the GUTI reallocation. If the response is received from a tracking area within the old and new TAI list, the network shall re-initiate the GUTI reallocation. If no response is received to the paging attempts, the network may use the new S-TMSI from the new GUTI for paging for an implementation dependent number of paging attempts. In this case, if a new TAI list was provided with new GUTI in the GUTI REALLOCATION COMMAND message, the new TAI list shall be used instead of the old TAI list. Upon response from the UE the network shall consider the new GUTI as valid and the old GUTI as invalid. If no response is received to the paging attempts, the network may use the IMSI for paging for an implementation dependent number of paging attempts;

NOTE 1: Paging with IMSI causes the UE to re-attach as described in clause 5.6.2.2.2.

– shall consider the new GUTI as valid if it is used by the UE and, additionally, the new TAI list as valid if it was provided with this GUTI in the GUTI REALLOCATION COMMAND message;

– may use the identification procedure followed by a new GUTI reallocation if the UE uses the old GUTI; and

– if the network accepted to use eDRX for the UE, may determine the next paging window from both old GUTI and new GUTI, and may first use the S-TMSI from the GUTI which led the first eDRX for paging. If no response is received to the paging attempts for the first eDRX, the network may use the other S-TMSI from the other GUTI which led the second eDRX for paging. For this paging procedure, the network shall start timer T3415 long enough to care the paging attempts for both eDRXs.

NOTE 2: If the second eDRX comes during the first eDRX ongoing, the paging attempts for the second eDRX can be initiated with stopping further paging attempts for the first eDRX.

b) Expiry of timer T3450

The GUTI reallocation procedure is supervised by the timer T3450. The network shall, on the first expiry of timer T3450, reset and restart timer T3450 and shall retransmit the GUTI REALLOCATION COMMAND. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3450, the network shall abort the reallocation procedure and shall follow the rules described for case a above.

c) GUTI reallocation and attach procedure collision

If the network receives an ATTACH REQUEST message before the ongoing GUTI reallocation procedure has been completed the network shall proceed with the attach procedure after deletion of the EMM context.

d) GUTI reallocation and UE initiated detach procedure collision

If the network receives a DETACH REQUEST message before the ongoing GUTI reallocation procedure has been completed, the network shall abort the GUTI reallocation procedure and shall progress the detach procedure.

e) GUTI reallocation and tracking area updating procedure collision

If the network receives a TRACKING AREA UPDATE REQUEST message before the ongoing GUTI reallocation procedure has been completed, the network shall abort the GUTI reallocation procedure and shall progress the tracking area updating procedure. The network may then perform a new GUTI reallocation.

f) GUTI reallocation and service request procedure collision

If the network receives an EXTENDED SERVICE REQUEST message for CS fallback or 1xCS fallback before the ongoing GUTI reallocation procedure has been completed, the network shall progress both procedures.

g) Lower layer indication of non-delivered NAS PDU due to handover

If the GUTI REALLOCATION COMMAND message could not be delivered due to an intra MME handover and the target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME shall retransmit the GUTI REALLOCATION COMMAND message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall retransmit the GUTI REALLOCATION COMMAND message.

If there is a different new GUTI and optionally a new TAI list included in a subsequent GUTI REALLOCATION COMMAND message, the UE always regards the newest GUTI and the newest TAI list as valid for the recovery time.

5.4.2 Authentication procedure

5.4.2.1 General

The purpose of the EPS authentication and key agreement (AKA) procedure is to provide mutual authentication between the user and the network and to agree on a key K_ASME (see 3GPP TS 33.401 [19]). The cases when the EPS AKA procedure should be used are defined in 3GPP TS 33.401 [19].

The EPS AKA procedure is always initiated and controlled by the network. However, the UE can reject the EPS authentication challenge sent by the network.

The UE shall proceed with an EPS authentication challenge only if a USIM is present.

A partial native EPS security context is established in the UE and the network when an EPS authentication is successfully performed. During a successful EPS authentication procedure, the CK and IK are computed by the USIM. CK and IK are then used by the ME as key material to compute a new key, K_ASME. K_ASME is stored in the EPS security contexts (see 3GPP TS 33.401 [19]) of both the network and in the volatile memory of the ME while attached to the network, and is the root for the EPS integrity protection and ciphering key hierarchy.

5.4.2.2 Authentication initiation by the network

When a NAS signalling connection exists, the network can initiate an authentication procedure at any time. For restrictions applicable after handover or inter-system handover to S1 mode see clause 5.5.3.2.3.

The network initiates the authentication procedure by sending an AUTHENTICATION REQUEST message to the UE and starting the timer T3460 (see example in figure 5.4.2.2.1). The AUTHENTICATION REQUEST message contains the parameters necessary to calculate the authentication response (see 3GPP TS 33.401 [19]).

If an eKSI is contained in an initial NAS message during an EMM procedure, the network shall include a different eKSI value in the AUTHENTICATION REQUEST message when it initiates an authentication procedure.

Figure 5.4.2.2.1: Authentication procedure

5.4.2.3 Authentication response by the UE

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in clauses 5.4.2.6 and 5.4.2.7 case k, the UE shall process the authentication challenge data and respond with an AUTHENTICATION RESPONSE message to the network.

Upon a successful EPS authentication challenge, the UE shall determine the PLMN identity to be used for the calculation of the new K_ASME from the authentication challenge data according to the following rules:

a) When the UE moves from EMM-IDLE mode to EMM-CONNECTED mode, until the first handover, the UE shall use the PLMN identity of the selected PLMN; and

b) After handover or inter-system handover to S1 mode,

– if the target cell is not a shared network cell, the UE shall use the PLMN identity received as part of the broadcast system information;

– if the target cell is a shared network cell and the UE has a valid GUTI, the UE shall use the PLMN identity that is part of the GUTI; and

– if the target cell is a shared network cell, the UE does not have a valid GUTI and,

– the EPS authentication challenge is performed after inter-system handover from A/Gb mode to S1 mode or from Iu mode to S1 mode and the UE has a valid P-TMSI and RAI, the UE shall use the PLMN identity that is part of the RAI; or

– the EPS authentication challenge is performed after inter-system handover from N1 mode to S1 mode and the UE has a valid 5G-GUTI, the UE shall use the PLMN identity that is part of the 5G-GUTI.

Upon a successful EPS authentication challenge, the new K_ASME calculated from the authentication challenge data shall be stored in a new EPS security context in the volatile memory of the ME.

The USIM will compute the authentication response (RES) using the authentication challenge data received from the ME, and pass RES to the ME.

In order to avoid a synchronisation failure, when the UE receives an AUTHENTICATION REQUEST message, the UE shall store the received RAND together with the RES returned from the USIM in the volatile memory of the ME. When the UE receives a subsequent AUTHENTICATION REQUEST message, if the stored RAND value is equal to the new received value in the AUTHENTICATION REQUEST message, then the ME shall not pass the RAND to the USIM, but shall send the AUTHENTICATION RESPONSE message with the stored RES. If there is no valid stored RAND in the ME or the stored RAND is different from the new received value in the AUTHENTICATION REQUEST message, the ME shall pass the RAND to the USIM, shall override any previously stored RAND and RES with the new ones and start, or reset and restart timer T3416.

The RAND and RES values stored in the ME shall be deleted and timer T3416, if running, shall be stopped:

– upon receipt of a

– SECURITY MODE COMMAND,

– SERVICE REJECT,

– SERVICE ACCEPT,

– TRACKING AREA UPDATE REJECT,

– TRACKING AREA UPDATE ACCEPT, or

– AUTHENTICATION REJECT message;

– upon expiry of timer T3416;

– if the UE enters the EMM state EMM-DEREGISTERED or EMM-NULL; or

– if the UE enters EMM-IDLE mode.

5.4.2.4 Authentication completion by the network

Upon receipt of an AUTHENTICATION RESPONSE message, the network stops the timer T3460 and checks the correctness of RES (see 3GPP TS 33.401 [19]).

If the authentication procedure has been completed successfully and the related eKSI is stored in the EPS security context of the network, the network shall include a different eKSI value in the AUTHENTICATION REQUEST message when it initiates a new authentication procedure.

Upon receipt of an AUTHENTICATION FAILURE message, the network stops the timer T3460. In the case where the EMM cause #21 "synch failure" is received, the core network may renegotiate with the HSS/AuC and provide the UE with new authentication parameters.

5.4.2.5 Authentication not accepted by the network

If the authentication response (RES) returned by the UE is not valid, the network response depends upon the type of identity used by the UE in the initial NAS message, that is:

– if the GUTI was used; or

– if the IMSI was used.

If the GUTI was used, the network should initiate an identification procedure. If the IMSI given by the UE during the identification procedure differs from the IMSI the network had associated with the GUTI, the authentication should be restarted with the correct parameters. Otherwise, if the IMSI provided by the UE is the same as the IMSI stored in the network (i.e. authentication has really failed), the network should send an AUTHENTICATION REJECT message to the UE.

If the IMSI was used for identification in the initial NAS message, or the network decides not to initiate the identification procedure after an unsuccessful authentication procedure, the network should send an AUTHENTICATION REJECT message to the UE. The network shall maintain, if any, the EMM-context and EPS security context unchanged.

Upon receipt of an AUTHENTICATION REJECT message,

a) if the message has been successfully integrity checked by the NAS, the UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSI_ASME. The USIM shall be considered invalid until switching off the UE or the UICC containing the USIM is removed. If the UE maintains a counter for "SIM/USIM considered invalid for GPRS services", then the UE shall set this counter to UE implementation-specific maximum value. If the UE maintains a counter for "SIM/USIM considered invalid for non-GPRS services", then the UE shall set this counter to UE implementation-specific maximum value.

If A/Gb or Iu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number and the MM parameters update status, TMSI, LAI and ciphering key sequence number as specified in 3GPP TS 24.008 [13] for the case when the authentication and ciphering procedure is not accepted by the network; and

if the UE is operating in single-registration mode, the UE shall in addition handle the 5GMM parameters 5GMM state, 5GS update status, 5G-GUTI, last visited registered TAI, TAI list and ngKSI as specified in 3GPP TS 24.501 [54] for the case when the authentication procedure performed over 3GPP access is not accepted by the network; and

b) if the message is received without integrity protection and if timer T3416, T3418 or T3420 is running, the UE shall start timer T3247 (see 3GPP TS 24.008 [13]) with a random value uniformly drawn from the range between 30 minutes and 60 minutes, if the timer is not running (see clause 5.3.7b). Additionally, the UE shall:

– if the UE maintains a counter for "SIM/USIM considered invalid for GPRS services" events and the counter has a value less than a UE implementation-specific maximum value, proceed as specified in clause 5.3.7b, list item 1a for the case that the EMM cause value received is #3; and

– otherwise proceed as specified under list item a above for the case that the message has been successfully integrity checked.

If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any EMM signalling procedure, stop any of the timers T3410, T3416, T3417, T3430, T3421, T3418 or T3420 (if they were running) and enter state EMM-DEREGISTERED.

Depending on local requirements or operator preference for emergency bearer services, if the UE has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services, the MME need not follow the procedures specified for the authentication failure in the present clause. The MME may continue a current EMM specific procedure or PDN connectivity request procedure. Upon completion of the authentication procedure, if not initiated as part of another procedure, or upon completion of the EMM procedure or PDN connectivity request procedure, the MME shall deactivate all non-emergency EPS bearers, if any, by initiating an EPS bearer context deactivation procedure. The network shall consider the UE to be attached for emergency bearer services only.

Depending on local regulation and operator policy, if the UE is requesting attach for access to RLOS, the MME need not follow the procedures specified for the authentication failure in the present clause. The MME may continue a current EMM specific procedure.

5.4.2.6 Authentication not accepted by the UE

In an EPS authentication challenge, the UE shall check the authenticity of the core network by means of the AUTN parameter received in the AUTHENTICATION REQUEST message. This enables the UE to detect a false network.

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 3GPP TS 33.401 [19]). This parameter contains three possible causes for authentication failure:

a) MAC code failure:

If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #20 "MAC failure". The UE shall then follow the procedure described in clause 5.4.2.7, item c.

b) Non-EPS authentication unacceptable:

If the UE finds that the "separation bit" in the AMF field of AUTN supplied by the core network is 0, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #26 "non-EPS authentication unacceptable" (see clause 6.1.1 in 3GPP TS 33.401 [19]). The UE shall then follow the procedure described in clause 5.4.2.7, item d.

c) SQN failure:

If the UE finds the SQN (supplied by the core network in the AUTN parameter) to be out of range, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #21 "synch failure" and a re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [18]). The UE shall then follow the procedure described in clause 5.4.2.7, item e.

If the UE returns an AUTHENTICATION FAILURE message to the network, the UE shall delete any previously stored RAND and RES and shall stop timer T3416, if running.

If the UE has a PDN connection for emergency bearer services established or is establishing such a PDN connection, additional UE requirements are specified in clause 5.4.2.7, under "for items c, d, e".

If the UE is attached for access to RLOS and has a PDN connection for RLOS established or is establishing such a PDN connection, additional UE requirements are specified in clause 5.4.2.7, under "for items c, d, e".

5.4.2.7 Abnormal cases

a) Lower layer failure:

Upon detection of lower layer failure before the AUTHENTICATION RESPONSE message is received, the network shall abort the procedure.

b) Expiry of timer T3460:

The network shall, on the first expiry of the timer T3460, retransmit the AUTHENTICATION REQUEST message and shall reset and start timer T3460. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3460, the network shall abort the authentication procedure and any ongoing EMM specific procedure and release the NAS signalling connection.

c) Authentication failure (EMM cause #20 "MAC failure"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #20 "MAC failure" according to clause 5.4.2.6, to the network and start timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #20 "MAC failure", the network may initiate the identification procedure described in clause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message.

NOTE 1: Upon receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #20 "MAC failure", the network may also terminate the authentication procedure (see clause 5.4.2.5).

If the GUTI/IMSI mapping in the network was incorrect, the network should respond by sending a new AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST message from the network, the UE shall stop the timer T3418, if running, and then process the challenge information as normal. If the GUTI/IMSI mapping in the network was correct, the network should terminate the authentication procedure by sending an AUTHENTICATION REJECT message (see clause 5.4.2.5).

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid SQN and MAC is received), the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430) if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.

If the UE receives the second AUTHENTICATION REQUEST message while T3418 is running, and the MAC value cannot be resolved, the UE shall follow the procedure specified in this clause, item c, starting again from the beginning, or if the message contains a UMTS authentication challenge, the UE shall follow the procedure specified in item d. If the SQN is invalid, the UE shall proceed as specified in item e.

Figure 5.4.2.7.1: Authentication failure procedure (EMM cause #20 "MAC failure" or
#26 "non-EPS authentication unacceptable")

d) Authentication failure (EMM cause #26 "non-EPS authentication unacceptable"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #26 "non-EPS authentication unacceptable", to the network and start the timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #26 "non-EPS authentication unacceptable", the network may initiate the identification procedure described in clause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message.

NOTE 2: Upon receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #26 "non-EPS authentication unacceptable", the network may also terminate the authentication procedure (see clause 5.4.2.5).

e) Authentication failure (EMM cause #21 "synch failure"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #21 "synch failure", to the network and start the timer T3420 (see example in figure 5.4.2.7.2). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with the EMM cause #21 "synch failure", the network shall use the returned AUTS parameter from the authentication failure parameter IE in the AUTHENTICATION FAILURE message, to re-synchronise. The re-synchronisation procedure requires the MME to delete all unused authentication vectors for that IMSI and obtain new vectors from the HSS. When re-synchronisation is complete, the network shall initiate the authentication procedure. Upon receipt of the AUTHENTICATION REQUEST message, the UE shall stop the timer T3420, if running.

NOTE 3: Upon receipt of two consecutive AUTHENTICATION FAILURE messages from the UE with EMM cause #21 "synch failure", the network may terminate the authentication procedure by sending an AUTHENTICATION REJECT message.

If the network is validated successfully (a new AUTHENTICATION REQUEST message is received which contains a valid SQN and MAC) while T3420 is running, the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.

If the UE receives the second AUTHENTICATION REQUEST message while T3420 is running, and the MAC value cannot be resolved, the UE shall follow the procedure specified in item c or if the message contains a UMTS authentication challenge, the UE shall proceed as specified in item d; if the SQN is invalid, the UE shall follow the procedure specified in this clause, item e, starting again from the beginning.

Figure 5.4.2.7.2: Authentication failure procedure (EMM cause #21 "synch failure")

Upon receipt of an AUTHENTICATION REJECT message, the UE shall perform the actions as specified in clause 5.4.2.5.

f) Network failing the authentication check:

If the UE deems that the network has failed the authentication check, then it shall request RRC to locally release the RRC connection and treat the active cell as barred (see 3GPP TS 36.304 [21]). The UE shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE received the first AUTHENTICATION REQUEST message containing an incorrect authentication challenge data causing the authentication failure.

g) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication from lower layers (if the authentication procedure is triggered by a tracking area updating procedure or an attach procedure)

The UE shall stop any of the timers T3418 and T3420, if running, and re-initiate the tracking area updating procedure if the authentication procedure is triggered by a tracking area updating procedure.

The UE shall stop any of the timers T3418 and T3420, if running, and re-initiate the attach procedure if the authentication procedure is triggered by an attach procedure.

h) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication with TAI change from lower layers (if the authentication procedure is triggered by a service request procedure)

The UE shall stop any of the timers T3418 and T3420, if running.

If the current TAI is not in the TAI list, the authentication procedure shall be aborted and a tracking area updating procedure shall be initiated.

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing procedure that triggered the authentication procedure.

i) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication without TAI change from lower layers (if the authentication procedure is triggered by a service request procedure)

The UE shall stop any of the timers T3418 and T3420, if running. It is up to the UE implementation how to re-run the ongoing procedure that triggered the authentication procedure.

j) Lower layers indication of non-delivered NAS PDU due to handover

If the AUTHENTICATION REQUEST message could not be delivered due to an intra MME handover and the target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME shall retransmit the AUTHENTICATION REQUEST message. If a failure of handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall retransmit the AUTHENTICATION REQUEST message.

k) Change of cell into a new tracking area

If the UE detects the current TAI is not in the TAI list occurs before the AUTHENTICATION RESPONSE message is sent, the UE may discard sending the AUTHENTICATION RESPONSE message to the network and continue with the initiation of tracking area updating procedure as described in clause 5.5.3.

l) AUTHENTICATION REJECT message is received without integrity protection and none of the timers T3416, T3418 and T3420 is running

If an AUTHENTICATION REJECT message is received and if none of the timers T3416, T3418 and T3420 is running, then the UE shall discard the AUTHENTICATION REJECT message. Additionally, the UE may request RRC to locally release the RRC connection and treat the active cell as barred (see 3GPP TS 36.304 [21]).

For items c, d, and e if the UE does not have a PDN connection for emergency bearer services established, is not establishing a PDN connection for emergency bearer services, does not have a PDN connection for RLOS established and is not establishing a PDN connection for RLOS:

The UE shall stop any of the timers T3418 and T3420, if running, and the UE enters EMM-IDLE mode, e.g. upon detection of a lower layer failure, release of the NAS signalling connection, or as the result of an inter-system handover to A/Gb mode, Iu mode or N1 mode.

The UE shall deem that the network has failed the authentication check or that the source of the authentication challenge is not genuine and proceed as described in item f if any of the following occurs:

– the timer T3418 or T3420 expires;

– the UE detects any combination of the authentication failures: EMM cause #20 "MAC failure", #21 "synch failure", or #26 "non-EPS authentication unacceptable", during three consecutive authentication challenges. The authentication challenges shall be considered as consecutive only if the authentication challenges causing the second and third authentication failure are received by the UE while the timer T3418 or T3420 started after the previous authentication failure is running.

For items c, d, and e if the UE has a PDN connection for emergency bearer services established, is establishing a PDN connection for emergency bearer services, has a PDN connection for RLOS established, or is establishing a PDN connection for RLOS:

1) The UE shall stop any of the timers T3418 and T3420, if running, and the UE enters EMM-IDLE mode, e.g. upon detection of a lower layer failure, release of the NAS signalling connection, or as the result of an inter-system handover to A/Gb mode, Iu mode or N1 mode.

2) Depending on local requirements or operator preference for emergency bearer services, if the UE has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services, the MME need not follow the procedures specified for the authentication failure specified in the present clause. The MME may respond to the AUTHENTICATION FAILURE message by initiating the security mode control procedure selecting the "null integrity protection algorithm" EIA0, "null ciphering algorithm" EEA0 or may abort the authentication procedure and continue using the current security context, if any. The MME shall deactivate all non-emergency EPS bearer contexts, if any, by initiating an EPS bearer context deactivation procedure. If there is an ongoing PDN connectivity procedure, the MME shall deactivate all non-emergency EPS bearer contexts upon completion of the PDN connectivity procedure. The network shall consider the UE to be attached for emergency bearer services only.

If a UE has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services and sends an AUTHENTICATION FAILURE message to the MME with the EMM cause appropriate for these cases (#20, #21, or #26, respectively) and receives the SECURITY MODE COMMAND message before the timeout of timer T3418 or T3420, the UE shall deem that the network has passed the authentication check successfully, stop timer T3418 or T3420, respectively, and execute the security mode control procedure.

If a UE has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services when timer T3418 or T3420 expires, the UE shall not deem that the network has failed the authentication check and not behave as described in item f. Instead the UE shall continue using the current security context, if any, deactivate all non-emergency EPS bearer contexts, if any, by initiating UE requested PDN disconnect procedure. If there is an ongoing PDN connectivity procedure, the UE shall deactivate all non-emergency EPS bearer contexts upon completion of the PDN connectivity procedure.

The UE shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430) if:

– they were running and stopped when the UE received the AUTHENTICATION REQUEST message and detected an authentication failure; and

– the procedures associated with these timers have not yet been completed.

The UE shall consider itself to be attached for emergency bearer services only.

3) Depending on local regulation and operator policy, if the UE has a PDN connection for RLOS established or is establishing a PDN connection for RLOS, the MME need not follow the procedures specified for the authentication failure specified in the present clause. The MME may respond to the AUTHENTICATION FAILURE message by initiating the security mode control procedure selecting the "null integrity protection algorithm" EIA0, "null ciphering algorithm" EEA0 or may abort the authentication procedure and continue using the current security context, if any. The network shall consider the UE to be attached for access to RLOS.

If a UE has a PDN connection for RLOS established or is establishing a PDN connection for RLOS and sends an AUTHENTICATION FAILURE message to the MME with the EMM cause appropriate for these cases (#20, #21, or #26, respectively) and receives the SECURITY MODE COMMAND message before the timeout of timer T3418 or T3420, the UE shall deem that the network has passed the authentication check successfully, stop timer T3418 or T3420, respectively, and execute the security mode control procedure.

If a UE has a PDN connection for RLOS established or is establishing a PDN connection for RLOS when timer T3418 or T3420 expires, the UE shall not deem that the network has failed the authentication check and not behave as described in item f. Instead the UE shall continue using the current security context, if any.

The UE shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430) if:

– they were running and stopped when the UE received the AUTHENTICATION REQUEST message and detected an authentication failure; and

– the procedures associated with these timers have not yet been completed.

The UE shall consider itself to be attached for access to RLOS.

5.4.3 Security mode control procedure

5.4.3.1 General

The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialise and start NAS signalling security between the UE and the MME with the corresponding EPS NAS keys and EPS security algorithms.

Furthermore, the network may also initiate the security mode control procedure in the following cases:

– in order to change the NAS security algorithms for a current EPS security context already in use;

– in order to change the value of uplink NAS COUNT used in the latest SECURITY MODE COMPLETE message as described in 3GPP TS 33.401 [19], clause 7.2.9.2; and

– in order to request the UE radio capability ID from the UE.

For restrictions concerning the concurrent running of a security mode control procedure with other security related procedures in the AS or inside the core network see 3GPP TS 33.401 [19], clause 7.2.10.

5.4.3.2 NAS security mode control initiation by the network

The MME initiates the NAS security mode control procedure by sending a SECURITY MODE COMMAND message to the UE and starting timer T3460 (see example in figure 5.4.3.2.1).

The MME shall reset the downlink NAS COUNT counter and use it to integrity protect the initial SECURITY MODE COMMAND message if the security mode control procedure is initiated:

– to take into use the EPS security context created after a successful execution of the EPS authentication procedure;

– upon receipt of TRACKING AREA UPDATE REQUEST message including a GPRS ciphering key sequence number IE, if the MME wishes to create a mapped EPS security context (i.e. the type of security context flag is set to "mapped security context" in the NAS key set identifier IE included in the SECURITY MODE COMMAND message).

The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the NAS integrity key based on K_ASME or mapped K’_ASME indicated by the eKSI included in the message. The MME shall set the security header type of the message to "integrity protected with new EPS security context".

The MME shall create a locally generated K_ASME and send the SECURITY MODE COMMAND message including a KSI value in the NAS key set identifier IE set to "000" and EIA0 and EEA0 as the selected NAS security algorithms only when the security mode control procedure is initiated:

– during an attach procedure for emergency bearer services if no shared EPS security context is available;

– during an attach procedure for access to RLOS if no valid EPS security context is available;

– during a tracking area updating procedure for a UE that has a PDN connection for emergency bearer services if no shared EPS security context is available;

– during a tracking area updating procedure for a UE that has a PDN connection for access to RLOS if no valid EPS security context is available;

– during a service request procedure for a UE that has a PDN connection for emergency bearer services if no shared EPS security context is available;

– during a service request procedure for a UE that has a PDN connection for access to RLOS if no valid EPS security context is available;

– after a failed authentication procedure for a UE that has a PDN connection for emergency bearer services or that is establishing a PDN connection for emergency bearer services, if continued usage of a shared security context is not possible; or

– after a failed authentication procedure for a UE that has a PDN connection for access to RLOS or that is establishing a PDN connection for access to RLOS, if continued usage of a valid security context is not possible.

The UE shall process a SECURITY MODE COMMAND message including a KSI value in the NAS key set identifier IE set to "000" and EIA0 and EEA0 as the selected NAS security algorithms and, if accepted, create a locally generated K_ASME when the security mode control procedure is initiated:

– during an attach procedure for emergency bearer services;

– during an attach procedure for access to RLOS;

– during a tracking area updating procedure when the UE has a PDN connection for emergency bearer services;

– during a tracking area updating procedure when the UE has a PDN connection for access to RLOS;

– during a service request procedure when the UE has a PDN connection for emergency bearer services;

– during a service request procedure when the UE has a PDN connection for access to RLOS;

– after an authentication procedure when the UE has a PDN connection for emergency bearer services or is establishing a PDN connection for emergency bearer services; or

– after an authentication procedure when the UE has a PDN connection for access to RLOS or is establishing a PDN connection for access to RLOS.

NOTE 1: The process for creation of the locally generated K_ASME by the MME and the UE is implementation dependent.

Upon receipt of a TRACKING AREA UPDATE REQUEST message including a GPRS ciphering key sequence number IE, if the MME does not have the valid current EPS security context indicated by the UE, the MME shall either:

– indicate the use of the new mapped EPS security context to the UE by setting the type of security context flag in the NAS key set identifier IE to "mapped security context" and the KSI value related to the security context of the source system; or

– set the KSI value "000" in the NAS key set identifier IE if the MME sets EIA0 and EEA0 as the selected NAS security algorithms for a UE that has a PDN connection for emergency bearer services.

While having a current mapped EPS security context with the UE, if the MME wants to take the native EPS security context into use, the MME shall include the eKSI that indicates the native EPS security context in the SECURITY MODE COMMAND message.

The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to NAS, RRC and UP (user plane) ciphering as well as NAS and RRC integrity, and other possible target network security capabilities, i.e. UTRAN/GERAN if the UE included them in the message to network), the replayed nonce_UE when creating a mapped EPS security context and if the UE included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set Identifier (eKSI). If the MME supports handling of UE additional security capabilities and the UE included a UE additional security capability IE in the message to the network, the MME shall include the replayed additional security capabilities of the UE.

The MME shall include both the nonce_MME and the nonce_UE when creating a mapped EPS security context during inter-system change from A/Gb mode to S1 mode or Iu mode to S1 mode in EMM-IDLE mode.

The MME may initiate a SECURITY MODE COMMAND in order to change the NAS security algorithms for a current EPS security context already in use. The MME re-derives the NAS keys from K_ASME with the new NAS algorithm identities as input and provides the new NAS algorithm identities within the SECURITY MODE COMMAND message. The MME shall set the security header type of the message to "integrity protected with new EPS security context".

If, during an ongoing attach or tracking area updating procedure, the MME is initiating a SECURITY MODE COMMAND (i.e. after receiving the ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message, but before sending a response to that message) and the ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message is received without integrity protection or does not successfully pass the integrity check at the MME, the MME shall calculate the HASH_MME of the entire plain ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message as described in 3GPP TS 33.401 [19] and shall include the HASH_MME in the SECURITY MODE COMMAND message.

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message.

NOTE 2: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS, the same algorithm is also supported for AS.

If:

– the NAS security mode control procedure is initiated during an ongoing attach procedure in WB-S1 mode;

– the network supports RACS;

– the UE has set the RACS bit to "RACS supported" in the UE network capability IE of the ATTACH REQUEST message; and

– the UE has set the URCIDA bit to "UE radio capability ID available" in the UE radio capability ID availability IE of the ATTACH REQUEST message,

then the MME shall request the UE to include its UE radio capability ID in the SECURITY MODE COMPLETE message.

If:

– the NAS security mode control procedure is initiated during an ongoing tracking area updating procedure in WB-S1 mode;

– the network supports RACS;

– the UE has set the RACS bit to "RACS supported" in the UE network capability IE of the TRACKING AREA UPDATE REQUEST message; and

– the UE has set the URCIDA bit to "UE radio capability ID available" in the UE radio capability ID availability IE of the TRACKING AREA UPDATE REQUEST message,

then the MME may request the UE to include its UE radio capability ID in the SECURITY MODE COMPLETE message.

If:

– the NAS security mode control procedure is initiated during an ongoing tracking area updating procedure in WB-S1 mode;

– the network supports RACS;

– the UE has set the RACS bit to "RACS supported" in the UE network capability IE of the TRACKING AREA UPDATE REQUEST message;

– the UE has set the URCIDA bit to "UE radio capability ID available" in the UE radio capability ID availability IE of the TRACKING AREA UPDATE REQUEST message; and

– no UE radio capability ID is available in the UE context in the MME,

then the MME shall request the UE to include its UE radio capability ID in the SECURITY MODE COMPLETE message.

Figure 5.4.3.2.1: Security mode control procedure

5.4.3.3 NAS security mode command accepted by the UE

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received replayed UE security capabilities, the received replayed UE additional security capabilities, if included in the SECURITY MODE COMMAND message, and the received nonce_UE have not been altered compared to the latest values that the UE sent to the network. However, the UE is not required to perform the checking of the received nonce_UE if the UE does not want to re-generate the K’_ASME (i.e. the SECURITY MODE COMMAND message is to derive and take into use a mapped EPS security context and the eKSI matches the current EPS security context, if it is a mapped EPS security context). When the UE has a PDN connection for emergency bearer services established or the UE is establishing a PDN connection for emergency bearer services or the UE is requesting attach for access to RLOS, the UE is not required to locally re-generate the K_ASME (i.e. the SECURITY MODE COMMAND message is used to derive and take into use a native EPS security context where the KSI value "000" is included in the NAS key set identifier IE and the EIA0 and EEA0 are included as the selected NAS security algorithms).

The UE shall accept a SECURITY MODE COMMAND message indicating the "null integrity protection algorithm" EIA0 as the selected NAS integrity algorithm only if the message is received for a UE that has a PDN connection for emergency bearer services established, or a UE that is attached for access to RLOS, or a UE that is establishing a PDN connection for emergency bearer services or a UE that is requesting attach for access to RLOS.

If the type of security context flag included in the SECURITY MODE COMMAND message is set to "native security context" and if the KSI matches a valid non-current native EPS security context held in the UE while the UE has a mapped EPS security context as the current EPS security context, the UE shall take the non-current native EPS security context into use which then becomes the current native EPS security context and delete the mapped EPS security context.

If the SECURITY MODE COMMAND message can be accepted, the UE shall take the EPS security context indicated in the message into use. The UE shall in addition reset the uplink NAS COUNT counter if:

– the SECURITY MODE COMMAND message is received in order to take an EPS security context into use created after a successful execution of the EPS authentication procedure;

– the SECURITY MODE COMMAND message received includes the type of security context flag set to "mapped security context" in the NAS key set identifier IE the eKSI does not match the current EPS security context, if it is a mapped EPS security context.

If the SECURITY MODE COMMAND message can be accepted and a new EPS security context is taken into use and SECURITY MODE COMMAND message does not indicate the "null integrity protection algorithm" EIA0 as the selected NAS integrity algorithm, the UE shall:

– if the SECURITY MODE COMMAND message has been successfully integrity checked using an estimated downlink NAS COUNT equal 0, then the UE shall set the downlink NAS COUNT of this new EPS security context to 0;

– otherwise the UE shall set the downlink NAS COUNT of this new EPS security context to the downlink NAS COUNT that has been used for the successful integrity checking of the SECURITY MODE COMMAND message.

If the SECURITY MODE COMMAND message can be accepted, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS integrity algorithm and the EPS NAS integrity key based on the K_ASME or mapped K’_ASME if the type of security context flag is set to "mapped security context" indicated by the eKSI. When the SECURITY MODE COMMAND message includes the type of security context flag set to "mapped security context" in the NAS key set identifier IE, the nonce_MME and the nonce_UE, then the UE shall either:

– generate K’_ASME from both the nonce_MME and the nonce_UE as indicated in 3GPP TS 33.401 [19]; or

– check whether the SECURITY MODE COMMAND message indicates the eKSI of the current EPS security context, if it is a mapped EPS security context, in order not to re-generate the K’_ASME.

Furthermore, if the SECURITY MODE COMMAND message can be accepted, the UE shall cipher the SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the EPS NAS ciphering key based on the K_ASME or mapped K’_ASME indicated by the eKSI. The UE shall set the security header type of the message to "integrity protected and ciphered with new EPS security context".

From this time onward the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering and NAS integrity algorithms.

If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall include its IMEISV in the SECURITY MODE COMPLETE message.

In WB-S1 mode, if the MME indicated in the SECURITY MODE COMMAND message that the UE radio capability ID is requested, the UE shall:

– if the UE has an applicable network-assigned UE radio capability ID for the current UE radio configuration in the selected PLMN, include the applicable network-assigned UE radio capability ID in the UE radio capability ID IE of the SECURITY MODE COMPLETE message; and

– if the UE:

a) does not have an applicable network-assigned UE radio capability ID for the current UE radio configuration in the selected PLMN; and

b) has an applicable manufacturer-assigned UE radio capability ID for the current UE radio configuration,

include the applicable manufacturer-assigned UE radio capability ID in the UE radio capability ID IE of the SECURITY MODE COMPLETE message.

If, during an ongoing attach or tracking area updating procedure, the SECURITY MODE COMMAND message includes a HASH_MME, the UE shall compare HASH_MME with a hash value locally calculated as described in 3GPP TS 33.401 [19] from the entire plain ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message that the UE had sent to initiate the procedure. If HASH_MME and the locally calculated hash value are different, the UE shall include the complete ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message which the UE had previously sent in the Replayed NAS message container IE of the SECURITY MODE COMPLETE message.

5.4.3.4 NAS security mode control completion by the network

The MME shall, upon receipt of the SECURITY MODE COMPLETE message, stop timer T3460. From this time onward the MME shall integrity protect and encipher all signalling messages with the selected NAS integrity and ciphering algorithms.

If the SECURITY MODE COMPLETE message contains a Replayed NAS container message IE with an ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message, the MME shall complete the ongoing attach or tracking area updating procedure by considering the ATTACH REQUEST or TRACKING AREA UPDATE REQUEST message contained in the Replayed NAS message container IE as the message that triggered the procedure.

5.4.3.5 NAS security mode command not accepted by the UE

If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message. The SECURITY MODE REJECT message contains an EMM cause that typically indicates one of the following cause values:

#23: UE security capabilities mismatch;

#24: security mode rejected, unspecified.

Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort the ongoing procedure that triggered the initiation of the NAS security mode control procedure.

Both the UE and the MME shall apply the EPS security context in use before the initiation of the security mode control procedure, if any, to protect the SECURITY MODE REJECT message and any other subsequent messages according to the rules in clauses 4.4.4 and 4.4.5.

5.4.3.6 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Transmission failure of SECURITY MODE COMPLETE message or SECURITY MODE REJECT message indication from lower layers (if the security mode control procedure is triggered by a tracking area updating procedure or an attach procedure)

The UE shall abort the security mode control procedure and re-initiate the tracking area updating procedure if the security mode control procedure is triggered by a tracking area updating procedure.

The UE shall abort the security mode control procedure and re-initiate the attach procedure if the security mode control procedure is triggered by an attach procedure.

b) Transmission failure of SECURITY MODE COMPLETE message or SECURITY MODE REJECT message indication with TAI change from lower layers (if the security mode control procedure is triggered by a service request procedure)

If the current TAI is not in the TAI list, the security mode control procedure shall be aborted and a tracking area updating procedure shall be initiated.

If the current TAI is still part of the TAI list, the security mode control procedure shall be aborted and it is up to the UE implementation how to re-run the ongoing procedure that triggered the security mode control procedure.

c) Transmission failure of SECURITY MODE COMPLETE message or SECURITY MODE REJECT message indication without TAI change from lower layers (if the security mode control procedure is triggered by a service request procedure)

The security mode control procedure shall be aborted and it is up to the UE implementation how to re-run the ongoing procedure that triggered the security mode control procedure.

5.4.3.7 Abnormal cases on the network side

The following abnormal cases can be identified:

a) Lower layer failure before the SECURITY MODE COMPLETE or SECURITY MODE REJECT message is received

The network shall abort the security mode control procedure.

b) Expiry of timer T3460

The network shall, on the first expiry of the timer T3460, retransmit the SECURITY MODE COMMAND message and shall reset and start timer T3460. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3460, the procedure shall be aborted.

NOTE: If the SECURITY MODE COMMAND message was sent to create a mapped EPS security context during inter-system change from A/Gb mode to S1 mode or Iu mode to S1 mode, then the network does not generate new values for the nonce_MME and the nonce_UE, but includes the same values in the SECURITY MODE COMMAND message (see the clause 7.2.4.4 in 3GPP TS 33.401 [19]).

c) Collision between security mode control procedure and attach, service request, tracking area updating procedure or detach procedure not indicating switch off

The network shall abort the security mode control procedure and proceed with the UE initiated procedure.

d) Collision between security mode control procedure and other EMM procedures than in item c

The network shall progress both procedures.

e) Lower layers indication of non-delivered NAS PDU due to handover

If the SECURITY MODE COMMAND message could not be delivered due to an intra MME handover and the target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME shall retransmit the SECURITY MODE COMMAND message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall retransmit the SECURITY MODE COMMAND message.

5.4.4 Identification procedure

5.4.4.1 General

The identification procedure is used by the network to request a particular UE to provide specific identification parameters, e.g. the International Mobile Subscriber Identity (IMSI) or the International Mobile Equipment Identity (IMEI). IMEI and IMSI definition and structure are specified in 3GPP TS 23.003 [2].

For mobile device supporting both 3GPP access and cdma2000^®access a single IMEI is used to identify the device as specified in 3GPP TS 22.278 [1C]. If the UE is a MUSIM UE, the UE uses a separate IMEI for each USIM the UE operates.

5.4.4.2 Identification initiation by the network

The network initiates the identification procedure by sending an IDENTITY REQUEST message to the UE and starting the timer T3470 (see example in figure 5.4.4.2.1). The IDENTITY REQUEST message specifies the requested identification parameters in the Identity type information element.

Figure 5.4.4.2.1: Identification procedure

5.4.4.3 Identification response by the UE

A UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED mode.

Upon receipt of the IDENTITY REQUEST message the UE shall send an IDENTITY RESPONSE message to the network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network.

5.4.4.4 Identification completion by the network

Upon receipt of the IDENTITY RESPONSE the network shall stop the timer T3470.

5.4.4.5 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Requested identity is not available

If the UE cannot encode the requested identity in the IDENTITY RESPONSE message, e.g. because no valid USIM is available, then it shall encode the identity type as "no identity".

b) Transmission failure of IDENTITY RESPONSE message indication from lower layers (if the identification procedure is triggered by a tracking area updating procedure or an attach procedure)

The UE shall abort the identification procedure and re-initiate the tracking area updating procedure if the identification procedure is triggered by a tracking area updating procedure.

The UE shall abort the identification procedure and re-initiate the attach procedure if the identification procedure is triggered by an attach procedure.

c) Transmission failure of IDENTITY RESPONSE message indication with TAI change from lower layers (if the identification procedure is triggered by a service request procedure)

If the current TAI is not in the TAI list, the identification procedure shall be aborted and a tracking area updating procedure shall be initiated.

If the current TAI is still part of the TAI list, the identification procedure shall be aborted and it is up to the UE implementation how to re-run the ongoing procedure that triggered the identification procedure.

d) Transmission failure of IDENTITY RESPONSE message indication without TAI change from lower layers (if the identification procedure is triggered by a service request procedure)

The identification procedure shall be aborted and it is up to the UE implementation how to re-run the ongoing procedure that triggered the identification procedure.

5.4.4.6 Abnormal cases on the network side

The following abnormal cases can be identified:

a) Lower layer failure

Upon detection of a lower layer failure before the IDENTITY RESPONSE is received, the network shall abort any ongoing EMM procedure.

b) Expiry of timer T3470

The identification procedure is supervised by the network by the timer T3470. The network shall, on the first expiry of the timer T3470, retransmit the IDENTITY REQUEST message and reset and restart the timer T3470. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3470, the network shall abort the identification procedure and any ongoing EMM procedure.

c) Collision of an identification procedure with an attach procedure

If the network receives an ATTACH REQUEST message before the ongoing identification procedure has been completed and no attach procedure is pending on the network (i.e. no ATTACH ACCEPT/REJECT message has still to be sent as an answer to an ATTACH REQUEST message), the network shall proceed with the attach procedure.

d) Collision of an identification procedure with an attach procedure when the identification procedure has been caused by an attach procedure

If the network receives an ATTACH REQUEST message before the ongoing identification procedure has been completed and an attach procedure is pending (i.e. an ATTACH ACCEPT/REJECT message has to be sent as an answer to an earlier ATTACH REQUEST message), then:

– If one or more of the information elements in the ATTACH REQUEST message differ from the ones received within the previous ATTACH REQUEST message, the network shall proceed with the new attach procedure; or

– If the information elements do not differ, then the network shall not treat any further this new ATTACH REQUEST.

e) Collision of an identification procedure with a UE initiated detach procedure

Detach containing cause "switch off" within the Detach type IE:

If the network receives a DETACH REQUEST message before the ongoing identification procedure has been completed, the network shall abort the identification procedure and shall progress the detach procedure.

Detach containing other causes than "switch off" within the Detach type IE:

If the network receives a DETACH REQUEST message before the ongoing identification procedure has been completed, the network shall complete the identification procedure and shall respond to the detach procedure as described in clause 5.5.2.

f) Collision of an identification procedure with a tracking area updating procedure

If the network receives a TRACKING AREA UPDATE REQUEST message before the ongoing identification procedure has been completed, the network shall progress both procedures.

g) Collision of an identification procedure with a service request procedure

If the network receives an EXTENDED SERVICE REQUEST message for CS fallback or 1xCS fallback before the ongoing identification procedure has been completed, the network shall progress both procedures.

h) Lower layers indication of non-delivered NAS PDU due to handover

If the IDENTITY REQUEST message could not be delivered due to an intra MME handover and the target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME shall retransmit the IDENTITY REQUEST message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall retransmit the IDENTITY REQUEST message.

5.4.5 EMM information procedure

5.4.5.1 General

The purpose of sending the EMM INFORMATION message is to allow the network to provide information to the UE. The message implementation is optional in the network. The UE may use the received information if the UE supports implementing this message.

The EMM information procedure may be invoked by the network at any time during an established EMM context.

5.4.5.2 EMM information procedure initiation by the network

The EMM information procedure consists only of the EMM INFORMATION message sent from the network to the UE (see example in figure 5.4.5.2.1). During an established EMM context, the network may send none, one, or more EMM INFORMATION messages to the UE. If more than one EMM INFORMATION message is sent, the messages need not have the same content.

Figure 5.4.5.2.1: EMM information procedure

5.4.5.3 EMM information procedure in the UE

When the UE (supporting the EMM information message) receives an EMM INFORMATION message, it shall accept the message and optionally use the contents to update appropriate information stored within the UE.

If the UE does not support the EMM information message the UE shall ignore the contents of the message and return an EMM STATUS message with EMM cause #97 "message type non-existent or not implemented".

5.4.5.4 Abnormal cases on the network side

The following abnormal case can be identified:

a) Lower layers indication of non-delivered NAS PDU due to handover

If the EMM INFORMATION message could not be delivered due to an intra MME handover and the target TA is included in the TAI list, then upon successful completion of the intra MME handover the MME shall retransmit the EMM INFORMATION message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall retransmit the EMM INFORMATION message.