EMM common procedures

EMM common procedures

GUTI reallocation procedure

The purpose of the GUTI reallocation procedure is to allocate a GUTI and optionally to provide a new TAI list to a particular UE.

The reallocation of a GUTI is performed by the unique procedure defined in this subclause. 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 subclauses which specify these procedures.

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.

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 .

The GUTI REALLOCATION COMMAND message shall include a GUTI and may include a TAI list.

GUTI reallocation completion by the UE

Upon receipt of the GUTI REALLOCATION COMMAND message, the UE shall store the GUTI and the TAI list, 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 GUTIREALLOCATION COMMANDmessage, 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

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.

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.

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 REALLOCAITON 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:      Paging with IMSI causes the UE to re-attach.

-     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; and

-     may use the identification procedure followed by a new GUTI reallocation if the UE uses the old GUTI.

b)   Expiry of timer T3450

      The GUTIreallocation 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)   GUTIreallocation and attach procedure collision

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

d)   GUTIreallocation and UE initiated detach procedure collision

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

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

Authentication procedure

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 support the EPS authentication challenge only if a USIM is present.

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

Authentication initiation by the network

When a NAS signalling connection exists, the network can initiate an authentication procedure at any time. The network initiates the authentication procedure by sending an AUTHENTICATION REQUEST message to the UE and starting the timer T3460 . The AUTHENTICATION REQUEST message contains the parameters necessary to calculate the authentication response (see 3GPP TS 33.401 [19]).

Authentication response by the UE

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in subclause 5.4.2.6, 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 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. 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 UE 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 UE or the stored RAND is different from the new received value in the AUTHENTICATION REQUEST message, the UE 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 UE shall be deleted and timer T3416, if running, shall be stopped:

-     upon receipt of a

-     SECURITY MODE COMMAND,

-     SERVICE REJECT,

-     TRACKING AREA UPDATE ACCEPT, or

-     AUTHENTICATION REJECT message;

-     upon expiry of timer T3416; or

-     if the UE enters the EMM state EMM-DEREGISTERED or EMM-NULL.

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

Authentication not accepted by the network

If the authentication response 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 proceed as described below.

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.

Upon receipt of an AUTHENTICATION REJECT message, 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 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.

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

Depending on local requirements or operator preference for emergency bearer services, if the UE is attached or is attaching to the network for emergency bearer services, the MME need not follow the procedures specified for the authentication failure in the present subclause. The MME may continue a current EMM specific procedure as if the authentication was successful.

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 Abnormal cases procedure , 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" The UE shall then follow the Abnormal cases procedure, 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 Abnormal cases procedure, 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.

Abnormal cases

a)   Lower layer failure:

      Upon detection of lower layer failure before the AUTHENTICATION RESPONSE 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 subclause 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 subclause 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 subclause 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 network is validated successfully (an AUTHENTICATION REQUEST 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 while T3418 is running, and the MAC value cannot be resolved, the UE shall follow the procedure specified in this subclause, 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.

      It can be assumed that the source of the authentication challenge is not genuine (authentication not accepted by the UE) if any of the following occur:

-     after sending the AUTHENTICATION FAILURE message with the EMM cause #20 "MAC failure" the timer T3418 expires;

-     the UE detects any combination of the authentication failures: EMM causes #20 "MAC failure" and #21 "synch failure", 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.

      When it has been deemed by the UE that the source of the authentication challenge is not genuine (i.e. authentication not accepted by the UE), the UE shall proceed as described in item f.

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 subclause 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 subclause 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 terminates the authentication procedure (see subclause 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 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 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 subclause, item e, starting again from the beginning.

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

-     the timer T3420 expires;

-     the UE detects any combination of the authentication failures: EMM cause #20 "MAC failure" or #21 "synch failure", 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.

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.331 [22]). 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 invalid MAC or SQN.

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)

      The UE shall re-initiate the tracking area updating 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)

      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)

      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.

For items c, d, and e:

      Depending on local requirements or operator preference for emergency bearer services, if the UE is attached or is attaching to the network for emergency bearer service, the MME need not follow the procedures specified for the authentication failure specified in the present subclause. The MME may respond to the AUTHENTICATION FAILURE message by initiating the security mode control procedure.

      If a UE is attached or is attaching 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.

Security mode control procedure

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 NAS keys and security algorithms.

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 .

If the security mode control procedure is initiated further to a successful execution of the authentication procedure, the MME shall use the reset downlink NAS COUNT to integrity protect 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".

When the security mode control procedure is initiated during an attach for emergency bearer services, and no EPS security context is available, the MME and the UE shall independently create a locally generated K_ASME. The process for creation of the locally generated K_ASMEby the MME and the UE is implementation dependent. In the SECURITY MODE COMMAND message the MME shall set the KSI value in the NAS key set identifier IE to "000".

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 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. The MME shall use the reset downlink NAS COUNT to integrity protect the SECURITY MODE COMMAND message.

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 matches 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, RRC integrity, and other possible target network security capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed nonce_UE if the UE included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set Identifier (eKSI).

When the security mode control procedure is initiated during an attach for emergency bearer services, and no EPS security context is available, the MME shall choose the null algorithms for both integrity protection and ciphering.

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

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

Security mode control procedure:

            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 UE security capabilities and the received nonce_UEhave not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure.

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 during an attach for emergency bearer services.

If the type of security context flag is set to "native security context" and if the KSI matches a valid native EPS security context held in the UE while the UE has a mapped EPS security context as the current security context, the UE shall take the native EPS security context into use. The UE shall store the native EPS security context, as specified in annex C.

If the security mode command can be accepted, the UE shall reset the uplink NAS COUNT and the UE shall take the new EPS security context into use when:

a)   the SECURITY MODE COMMAND message is received further to a successful execution of the authentication procedure; or

b)   the type of security context flag is set to "mapped security context" in the NAS KSI IE included in the SECURITY MODE COMMAND message.

If the security mode command can be accepted, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS integrity algorithm and the 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. If the SECURITY MODE COMMAND message includes the type of security context flag set to "mapped security context" in the NAS KSI IE, nonce_MME and nonce_UE, the UE shall generate K'_ASMEfrom both nonces as indicated in 3GPP TS 33.401 [19] and reset the downlink NAS COUNT to check whether the SECURITY MODE COMMAND can be accepted or not. The UE shall cipher the SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key based on the K_ASMEor 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.

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.

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 and subsequent messages.

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)

      The UE shall re-initiate the tracking area updating 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, 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)

      It is up to the UE implementation how to re-run the ongoing procedure that triggered the security mode control procedure.

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

b)   Expiry of timer T3460

      The network shall, on the first expiry of the timer T3460, retransmit the SECURITY MODE COMMAND 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.

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.

Identification procedure

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 [1B].

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.

Identification procedure

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.

Identification completion by the network

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

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)

      The UE shall re-initiate the tracking area updating procedure.

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

EMM information procedure

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.

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.

EMM information procedure

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

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.

General on elementary EMM procedures

EMM modes and NAS signalling connection

Establishment of the NAS signalling connection

When the UE is in EMM-IDLE mode and needs to transmit an initial NAS message, the UE shall request the lower layer to establish a RRC connection. In this request to the lower layer the NAS shall provide to the lower layer the RRC establishment cause and the call type as specified in annex D of this specification.

Initial NAS messages are:

-     ATTACH REQUEST;

-     DETACH REQUEST;

-     TRACKING AREA UPDATE REQUEST;

-     SERVICE REQUEST; and

-     EXTENDED SERVICE REQUEST.

For the routing of the initial NAS message to the appropriate MME, the UE NAS provides the lower layers with either the S-TMSI or the registered globally unique MME identifier (GUMMEI) that consists of the PLMN ID, the MME group ID, and the MME code (see 3GPP TS 23.003 [2]) according to the following rules:

-     When the UE is registered in the tracking area of the current cellduring the NAS signalling connection establishment, the UE NAS shall provide the lowerlayers with the S-TMSI, but shall not provide the registered MME identifier to the lower layers. Exceptionally, when the UE in EMM-IDLE mode initiates a tracking area updating or combined tracking area updating procedure for load balancing purposes, the UE NAS shall provide the lower layers with neither S-TMSI nor registered MME identifier.

-     When the UE is not registered in the tracking area of the current cell during the NAS signalling connection establishment, the UE NAS does not provide the lower layers with the S-TMSI. Instead,

a)   if the TIN indicates "GUTI" or "RAT-related TMSI", or the TIN is not available, and the UE holds a valid GUTI, the UE NAS shall provide the lower layers with the MME identifier part of the valid GUTI; or

b)   if the TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and RAI, the UE NAS shall provide the lower layers with the MME identifier part of the mapped GUTI, which is generated from the P-TMSI and RAI.

The UE NAS also provides the lower layers with the identity of the selected PLMN (see 3GPP TS 36.331 [22]). In a shared network, the UE shall choose one of the PLMN identities as specified in 3GPP TS 23.122 [6].

In S1 mode, when the RRC connection has been established successfully, the UE shall enter EMM-CONNECTED mode and consider the NAS signalling connection established.

In S101 mode, when the cdma2000^®HRPD access network resources are available for tunnelled NAS signalling, the UE shall enter EMM-CONNECTED mode and consider the S101 mode NAS signalling connection established.

Release of the NAS signalling connection

The signalling procedure for the release of the NAS signalling connection is initiated by the network.

In S1 mode, when the RRC connection has been released, the UE shall enter EMM-IDLE mode and consider the NAS signalling connection released.

To allow the network to release the NAS signalling connection, the UE shall start the timer T3440 in the following cases:

a)   the UE receives any of the EMM cause values #11, #12, #13, #14 (not applicable to the service request procedure) or #15; or

b)   the UE receives a TRACKING AREA UPDATE ACCEPT message and the UE has not set the "active" flag in the TRACKING AREA UPDATE REQUEST message and the tracking area updating or combined tracking area updating procedure has been initiated in EMM-IDLE mode.

Upon expiry of T3440, the UE shall locally release the established NAS signalling connection.

In case b,

-     upon an indication from the lower layers that the user plane radio bearers are set up, the UE shall stop timer T3440 and may send uplink signalling via the existing NAS signalling connection or user data via the user plane bearers; or

-     upon receipt of a DETACH REQUEST message, the UE shall stop timer T3440 and respond to the network initiated detach.

In S101 mode, when the cdma2000^®HRPD radio access connection has been released, the UE shall enter EMM-IDLE mode and consider the S101 mode NAS signalling connection released.

Lists of forbidden tracking areas

The UE shall store a list of "forbidden tracking areas for roaming", as well as a list of "forbidden tracking areas for regional provision of service". These lists shall be erased when the UE is switched off or when the UICC containing the USIM is removed, and periodically (with a period in the range 12 to 24 hours). One or more tracking areas is removed from the list of "forbidden tracking areas for roaming" in the UE, as well as the list of "forbidden tracking areas for regional provision of service" if, after a subsequent procedure e.g. attach procedure, tracking area updating procedure and GUTI reallocation procedure, one or more tracking areas in the lists is received from the network. If the UE has only one PDN connection established which is for emergency bearer services, the tracking areas shall not be removed from these lists if one or more tracking areas in the lists are received from the network.

In S1 mode, the UE shall update the suitable list whenever an ATTACH REJECT, TRACKING AREA UPDATE REJECT, SERVICE REJECT or DETACH REQUEST message is received with the EMM cause #12 "tracking area not allowed", #13 "roaming not allowed in this tracking area", or #15 "no suitable cells in tracking area".

Each list shall accommodate 40 or more TAIs. When the list is full and a new entry has to be inserted, the oldest entry shall be deleted.

List of forbidden PLMNs for attach in S101 mode

A UE supporting S101 mode shall store a list of "forbidden PLMNs for attach in S101 mode". The UE shall erase this list when the UE is switched off or when the USIM is removed.

In S101 mode, the UE shall add to the "forbidden PLMNs for attach in S101 mode" list the PLMN identity provided with the indication from the lower layers to prepare for an S101 mode to S1 mode handover whenever an ATTACH REJECT message is received with the EMM cause #11 "PLMN not allowed", #13 "roaming not allowed in this tracking area", #12 "tracking area not allowed", or #15 "no suitable cells in tracking area".

The maximum number of possible entries in the "forbidden PLMNs for attach in S101 mode" list is implementation dependent, but the list shall accommodate at least one PLMN identity. When the list is full and a new PLMN identity has to be inserted, the UE shall delete the oldest PLMN identity.

Equivalent PLMNs list

The UE shall store a list of equivalent PLMNs. These PLMNs shall be regarded by the UE as equivalent to each other for PLMN selection and cell selection/re-selection. The same list is used by EMM, GMM and MM.

The UE shall update or delete this list at the end of each attach or combined attach or tracking area updating or combined tracking area updating procedure. The stored list consists of a list of equivalent PLMNs as downloaded by the network plus the PLMN code of the registered PLMN that downloaded the list. When the UE is switched off, it shall keep the stored list so that it can be used for PLMN selection after switch on. The UE shall delete the stored list if the USIM is removed. The maximum number of possible entries in the stored list is 16.

Handling of the periodic tracking area update timer and mobile reachable timer (S1 mode only)

Periodic tracking area updating is used to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic tracking area update timer (timer T3412). The value of timer T3412 is sent by the network to the UE in the ATTACH ACCEPT message and can be sent in the TRACKING AREA UPDATE ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE, until a new value is received.

The timer T3412 is reset and started with its initial value, when the UE goes from EMM-CONNECTED to EMM-IDLE mode. The timer T3412 is stopped when the UE enters EMM-CONNECTED mode or EMM-DEREGISTERED state.

When a UE is not attached for emergency bearer services, and timer T3412 expires, the periodic tracking area updating procedure shall be started and the timer shall be set to its initial value for the next start.

If the UE is not attached for emergency bearer services, and is in another state than EMM-REGISTERED.NORMAL-SERVICE when the timer expires the periodic tracking area updating procedure is delayed until the UE returns to EMM-REGISTERED.NORMAL-SERVICE.

If ISR is activated, the UE shall keep both the periodic tracking area update timer (timer T3412) and the periodic routeing area update timer (timer T3312). The two separate timers run in the UE for updating MME and SGSN independently. If the periodic tracking area update timer expires and the UE cannot initiate the tracking area updating procedure, as it is in state EMM-REGISTERED.NO-CELL-AVAILABLE, the UE shall start the E-UTRAN deactivate ISR timer T3423. The UE shall initiate thetracking area updating procedure and stop the timer T3423 when it enters state EMM-REGISTERED.NORMAL-SERVICE before timer T3423 expires. After expiry of timer T3423 the UE shall set its TIN to "P-TMSI" in order to initiate the tracking area updating procedure when it returns to state EMM-REGISTERED.NORMAL-SERVICE.

If the UE is attached to both EPS and non-EPS services, and if timer T3412 expires or timer T3423 expires when the UE is in EMM-REGISTERED.NO-CELL-AVAILABLE state, then the UE shall initiate the combined tracking area updating procedure indicating "combined TA/LA updating with IMSI attach" when the UE returns to EMM-REGISTERED.NORMAL-SERVICE state.

The network supervises the periodic tracking area updating procedure of the UE by means of the mobile reachable timer. The mobile reachable timer shall be longer than T3412. When the UE does not have bearers for emergency services, by default, the mobile reachable timer is 4 minutes greater than T3412. If ISR is not activated, the network behaviour upon expiry of the mobile reachable timer is network dependent, but typically the network stops sending paging messages to the UE on the first expiry, and may take other appropriate actions.

If the UE has bearers for emergency services, the MME shall set the mobile reachable timer with a value equal toT3412. When timer T3412 expires, the UE shall not initiate a periodic TAU procedure and shall locally detach from the network. When the mobile reachable timer expires, the MME shall locally detach the UE.

The mobile reachable timer shall be reset and started with its initial value, when the MME releases the NAS signalling connection for the UE. The mobile reachable timer shall be stopped when a NAS signalling connection is established for the UE.

Upon expiry of the mobile reachable timer the network shall start the implicit detach timer. The value of the implicit detach timer is network dependent. If ISR is activated, the default value of the implicit detach timer is 4 minutes greater than T3423. If the implicit detach timer expires before the UE contacts the network, the network shall implicitly detach the UE.

The implicit detach timer shall be stopped when a NAS signalling connection is established for the UE.

Handling of timer T3402

The value of timer T3402 can be sent by the network to the UE in the ATTACH ACCEPT message and TRACKING AREA UPDATE ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE, until a new value is received, or until one of the above messages is received without a value specified, in which case the default value applies.

Handling of the Local Emergency Numbers List

The Local Emergency Numbers List contains additional emergency numbers used by the serving network. The list can be downloaded by the network to the UE at successful registration and subsequent registration updates. There is only one Local Emergency Numbers List in the UE, and it can be updated with EMM procedures if the UE is in S1 mode and with GMM and MM procedures if the the UE is in A/Gb or Iu mode.

The UE shall use the stored Local Emergency Numbers List received from the network in addition to the emergency numbers stored on the USIM or user equipment to detect that the number dialled is an emergency number.

NOTE:      The user equipment may use the emergency numbers list to assist the end user in determining whether the dialled number is intended for an emergency service or for another destination, e.g. a local directory service. The possible interactions with the end user are implementation specific.

The network may send a Local Emergency Numbers List in the ATTACH ACCEPT or in the TRACKING AREA UPDATE ACCEPT messages, by including the Emergency Number List IE. The user equipment shall store the Local Emergency Numbers List, as provided by the network, except that any emergency number that is already stored in the USIM shall be removed from the Local Emergency Numbers List before it is stored by the user equipment. If there are no emergency numbers stored on the USIM, then before storing the received Local Emergency Numbers List, the user equipment shall remove from the Local Emergency Numbers List any emergency number stored permanently in the user equipment for use in this case (see 3GPP TS 22.101 [8]). The Local Emergency Numbers List stored in the user equipment shall be replaced on each receipt of a new Emergency Number List IE.

The emergency number(s) received in the Emergency Number List IE are valid only in networks with the same MCC as in the cell on which this IE is received. If no Local Emergency Numbers List is contained in the ATTACH ACCEPT or in the TRACKING AREA UPDATE ACCEPT message, then the stored Local Emergency Numbers List in the user equipment shall be kept, except if the user equipment has successfully registered to a PLMN with an MCC different from that of the last registered PLMN.

The Local Emergency Numbers List shall be deleted at switch off and removal of the USIM. The user equipment shall be able to store up to ten local emergency numbers received from the network.

Abnormal cases in the UE

The following abnormal case can be identified:

a)   EMM uplink message transmission failure indication by lower layers

      When it is specified in the relevant procedure that it is up to the UE implementation to rerun the ongoing procedure that triggered that procedure, the procedure can typically be re-initiated using a retransmission mechanism of the uplink message (the one that has previously failed to be transmitted) with new sequence number and message authentication code information thus avoiding to restart the whole procedure.