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 KASME (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, KASME. KASMEis 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 KASME 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 KSIASME. 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")
#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 KASME 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 KASME. The process for creation of the locally generated KASMEby 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 nonceUE 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 nonceUEhave 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 KASME 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, nonceMME and nonceUE, 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 KASMEor 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.
No comments:
Post a Comment