LTE NAS: Security Mode Reject

Ø     The UE shall first perform the integrity check of the SECURITY MODE COMMAND message and also check that the received ‘replayed UE security capabilities’ and the received n_onceUE have not been altered as compared to what the UE provided in the initial L3 message

Ø       If the SECURITY MODE COMMAND cannot be accepted by the UE, then it shall send a SECURITY MODE REJECT message

Ø      The IE EMM Cause in the SECURITY MODE REJECT message typically indicates either cause #23 (UE security capabilities mismatch) or #24 (security mode rejected, unspecified)

Ø      After MME receives SECURITY MODE REJECT message, both the UE and the MME shall apply the EPS security context in use before the initiation of this security mode control procedure, if any, to protect the SECURITY MODE REJECT message and any other subsequent messages according to the rules in 3GPP TS 24.301 subclauses 4.4.4 and 4.4.5 

Reference: 3GPP TS 24.301

Example: SECURITY MODE REJECT

LTE NAS: Security Mode Complete

Ø     If the SECURITY MODE COMMAND message can be acceptable to the UE, then the UE shall send a SECURITY MODE COMPLETE message to the network

Ø     If the MME requests IMEISV in the SECURITY MODE COMMAND message then the UE shall include its IMEISV in the SECURITY MODE COMPLETE message

Ø     The SECURITY MODE COMPLETE message shall be integrity protected with the selected NAS integrity algorithm and the EPS NAS integrity key based on the K_ASME/K'_ASME

Ø     Also, the UE shall cipher the SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the EPS NAS ciphering key based on the K_ASME/K'_ASME 

Ø     After sending SECURITY MODE COMPLETE message, the UE shall cipher and integrity protect all the subsequent NAS messages with the selected NAS ciphering and integrity algorithms respectively

Ø     After receiving SECURITY MODE COMPLETE message, the MME shall integrity protect and encipher all signalling messages with the selected NAS integrity and ciphering algorithms respectively

Reference: 3GPP TS 24.301

Example: SECURITY MODE COMPLETE

LTE NAS: Security Mode Command

Ø    The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialize and start NAS signalling security between the UE and the MME. The MME starts this procedure by sending SECURITY MODE COMMAND message

Ø     The MME may send a SECURITY MODE COMMAND in order to change the NAS security algorithms for a current EPS security context already in use

Ø      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" since this message is only integrity protected but not ciphered

Ø     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 etc...)

Ø      The MME shall include the replayed nonce_UE if the UE included it in initial L3 message to the network

Ø       Also, the MME shall send the selected NAS ciphering and integrity algorithms and the NAS Key Set Identifier (eKSI) in the SECURITY MODE COMMAND message

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

Ø        Additionally, the MME may request the UE to send its IMEISV in the SECURITY MODE COMPLETE message

Ø        The UE shall derive K_NASenc and K_NASint keys from the key K_ASME/K'_ASME and the received EPS encryption and integrity algorithms (respectively)

Reference: 3GPP TS 24.301

Example: SECURITY MODE COMMAND

LTE: Authentication Failure

Ø       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. The UE shall send AUTHENTICATION FAILURE message to indicate the EPS authentication failure

Ø       As explained in the post AUTHENTICATION REQUEST, the AUTN parameter is formed by SQN, AK, AMF, and MAC. There could be 3 possible causes for the authentication failure as explained below:

a)      MAC code failure: If the UE finds that the MAC code supplied by the core network in the AUTN parameter is invalid, then the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #20 "MAC failure". The network may initiate an identification procedure to obtain the IMSI from the UE or may also decides to terminate the authentication procedure

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, then the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #26 "non-EPS authentication unacceptable". The network may initiate an identification procedure to obtain the IMSI from the UE or may also decides to terminate the authentication procedure

c)      SQN failure: If the UE finds that the SQN (supplied by the core network in the AUTN parameter) is out of range, then the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #21 "synch failure". In this message, the UE should also include a re-synchronization token AUTS provided by the USIM. By using this AUTS the network starts re-synchronization procedure.  The re-synchronization procedure requires the MME to delete all unused authentication vectors for that IMSI and obtain new vectors from the HSS. Once the re-synchronization is complete, the network shall initiate a new authentication procedure. 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

Ø       The only important IE in the AUTHENTICATION FAILURE message is authentication failure parameter which is sent if and only if the EMM cause is #21 "synch failure". It shall include the response to the authentication challenge from the USIM, which is made up of the AUTS parameter

Reference: 3GPP TS 24.301

Example1: AUTHENTICATION FAILURE – Synch failure

Example2: AUTHENTICATION FAILURE – MAC failure

LTE: Authentication Reject

Ø      Upon receipt of an AUTHENTICATION RESPONSE message the MME compares the received RES value with the XRES (Expected Response) value. If RES == XRES, then the network considers that the UE has successfully authenticated itself to the network

Ø      If the AUTHENTICATION RESPONSE returned by the UE is not valid i.e. RES != XRES, then the network response depends upon the type of identity used by the UE in the initial NAS message as explained below:

·           If the GUTI was used, the network should initiate an identification procedure to obtain IMSI from the UE. 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 sends AUTHENTICATION REJECT message to the UE

·           If the IMSI was used for identification in the initial NAS message, or the network decides not to initiate the identification procedure after an unsuccessful authentication procedure, the network should send an AUTHENTICATION REJECT message to the UE

Ø       Upon receipt of an AUTHENTICATION REJECT message, the UE shall abort any EMM signalling procedure and enter state EMM-DEREGISTERED. Also, 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 as invalid until switching off the UE or the UICC containing the USIM is removed

Ø      Additionally, If A/Gb or Iu mode is supported by the UE, it shall handle MM/GMM states and parameters as explained in 3GPP TS 24.008 section 4.7.4.5

Reference: 3GPP TS 24.301

Example: AUTHENTICATION REJECT

LTE: Authentication Response

Ø   The UE processes the authentication challenge data received in AUTHENTICATION REQUEST message (RAND and AUTN) and responds with an AUTHENTICATION RESPONSE message in order to deliver a calculated authentication response RES to the network

Ø    In an EPS authentication challenge, the response calculated in the USIM (RES) is minimum 4 octets and may be up to 16 octets in length. The RES is included in the IE Authentication response parameter in the AUTHENTICATION RESPONSE message

Ø       Upon receipt of an AUTHENTICATION RESPONSE message the MME compares the received RES value with the XRES (Expected Response) value. If RES == XRES, then the network considers that the UE has successfully authenticated itself to the network

Ø     If the AUTHENTICATION RESPONSE returned by the UE is not valid (RES != XRES), the network response depends upon the type of identity used by the UE in the initial NAS message (if GUTI was used or IMSI was used) as explained below:

·           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 sends AUTHENTICATION REJECT message to the UE

·           If the IMSI was used for identification in the initial NAS message, or the network decides not to initiate the identification procedure after an unsuccessful authentication procedure, the network should send an AUTHENTICATION REJECT message to the UE

Reference: 3GPP TS 24.301

Example: AUTHENTICATION RESPONSE

LTE: Authentication Request

Ø    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

Ø    The EPS AKA procedure is always initiated and controlled by the network. However, the UE can reject the EPS authentication challenge sent by the network. The UE shall proceed with an EPS authentication challenge only if an USIM is present

Ø    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

Ø    The MME sends unciphered AUTHENTICATION REQUEST message to the UE which includes a random number RAND and an authentication parameter AUTN. Now the UE’s job is to compute the authentication response parameter RES and send it back to the MME in AUTHENTICATION RESPONSE message

Ø    The value of RES is computed by the USIM using RAND, AUTN and the secret key ‘K’ which is stored in the USIM.

Ø    The IE Authentication parameter RAND (EPS challenge) will carry the RAND of length 128-bits. It provides the MS with a non-predictable number to be used to calculate the authentication response parameter RES

Ø    The IE Authentication parameter AUTN (EPS challenge) will carry the AUTN of length 128-bits. It provides the MS with a means of authenticating the network. The AUTN consists of (SQN xor AK)||AMF||MAC  = 48 + 16 + 64  = 128-bits. In the AUTHENTICATION REQUEST example below, AUTN value = 6e323b36c46c5555a3df0e6e323b6391 which means that, 

            SQN xor AK = 6e323b36c46c

                        AMF: 5555 
                        MAC: a3df0e6e323b6391

Abbreviations:

 AMF – Authentication Management Field

 AK – Anonymity Key

 ASME – Access Security Management Entity

 AUTN – Authentication Token

 MAC – Message Authentication Code

 RAND – RANDom number

 SQN – Sequence Number

Reference: 3GPP TS 24.301

Example: AUTHENTICATION REQUEST

LTE: Tracking Area Update Complete

The TRACKING AREA UPDATE COMPLETE message shall be sent by the UE to the network in response to a TRACKING AREA UPDATE ACCEPT message if a GUTI has been changed or a new TMSI has been assigned

Reference: 3GPP TS 24301

Example: TRACKING AREA UPDATE COMPLETE

LTE: Tracking Area Update Accept

If the TRACKING AREA UPDATE REQUEST has been accepted by the network, the MME shall send a TRACKING AREA UPDATE ACCEPT message to the UE. Some of the IEs included in this message are explained below

If the MME assigns a new GUTI for the UE, a GUTI shall be included in the TRACKING AREA UPDATE ACCEPT message. The UE shall use this GUTI as new temporary identity for EPS services and shall store the new GUTI. If no GUTI was included by the MME in the TRACKING AREA UPDATE ACCEPT message, the old GUTI shall be used. Same is the case with IE TAI list

The purpose of the EPS update result IE is to specify the result of tracking area updating procedure. It could result in ‘TA updated’ or ‘combined TA/LA updated’ or ‘TA updated and ISR activated’ or ‘combined TA/LA updated and ISR activated’

If the EPS bearer context status IE is included in the TRACKING AREA UPDATE REQUEST, the MME shall include an EPS bearer context status IE in the TRACKING AREA UPDATE ACCEPT message, indicating which EPS bearer contexts are active in the MME. The UE shall deactivate all those EPS bearers contexts locally (without peer-to-peer signalling between the UE and the MME) which are active in the UE, but are indicated by the MME as being inactive

The MME may also include of list of equivalent PLMNs in the TRACKING AREA UPDATE ACCEPT message. Each entry in the list contains a PLMN code (MCC+MNC)

The MME includes EMM Cause IE if the combined tracking area updating procedure was successful for EPS services only

The purpose of the EPS network feature support IE is to indicate whether certain features are supported by the network. It can indicate the following features whether supported or not: IMS voice over PS session indicator (IMS VoPS), Emergency bearer services indicator (EMC BS), Location services indicator in EPC (EPC-LCS), Location services indicator in CS (CS-LCS), Support of EXTENDED SERVICE REQUEST for packet services (ESRPS)

The purpose of the Additional update result IE is to provide additional information about the result of a combined tracking area updating procedure. It indicates if the procedure was successful for “EPS services and non-EPS services”, or for “EPS services” and "SMS only"

Reference: 3GPP TS 24301

Example: TRACKING AREA UPDATE ACCEPT

LTE: Tracking Area Update Reject

If the Tracking Area Updating cannot be accepted by the network, the MME sends a TRACKING AREA UPDATE REJECT message to the UE including an appropriate EMM cause

If the MME locally deactivates EPS bearer contexts for the UE and no active EPS bearer contexts remain for the UE, the MME shall send the TRACKING AREA UPDATE REJECT message including the EMM cause value #10 "Implicitly detached"

If the TRACKING AREA UPDATE REQUEST is rejected due to NAS level congestion control, the network shall set the EMM cause value to #22 "congestion" and assign a back-off timer T3346. Refer to 3GPP TS 24.301 for all other EMM cause values

Example: TRACKING AREA UPDATE REJECT - cause: PLMN not allowed

LTE: GUTI

The Globally Unique Temporary UE Identity (GUTI) provides an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the EPS

The GUTI also allows the identification of the MME and the network. It can be used by the network and the UE to establish the UE's identity during signalling between them in the EPS. The GUTI has two main components as explained below:

§  one that uniquely identifies the MME which allocated the GUTI (GUMMEI)
§  one that uniquely identifies the UE within the MME that allocated the GUTI (M-TMSI)

The MME allocates GUTI by initiating GUTI reallocation procedure or it can also be implicitly reallocated during attach or tracking area updating procedures. Normally, the GUTI reallocation will take place in conjunction with another mobility management procedure, e.g. as part of tracking area updating

Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI). The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC). The structure of the GUTI is illustrated in the figure below

Reference: 3GPP TS 23003

LTE: Tracking Area Update Request

The TRACKING AREA UPDATING (TAU) procedure is always initiated by the UE and is used for (some of) the following purposes:

·         Normal TAU: When the UE enters a tracking area that is not in the list of tracking areas that the UE previously registered in the MME

·         Combined TAU: When a UE operating in 'CS/PS mode 1' or 'CS/PS mode 2' enters a tracking area that is not in the list of tracking areas that the UE previously registered in the MME

·         Periodic TAU: Upon the expiry of timer T3412, periodic TAU procedure is initiated to periodically notify the availability of the UE to the network

·         IMSI attach for non-EPS services when the UE is attached for EPS services. This procedure is used by a UE in 'CS/PS mode 1' or 'CS/PS mode 2' of operation

·         In various cases of inter-system change from “Iu mode to S1 mode” or from “A/Gb mode to S1 mode” or from “S101 mode to S1 mode”

·         MME load balancing: When the UE receives RRC CONNECTION RELEASE message with cause ‘load balancing TAU required', it initiates TAU procedure

·         To update certain UE specific parameters in the network (ex:- when the UE changes the “UE network capability information” or the “MS network capability information” or the UE specific DRX parameter etc...)

The UE initiates the TAU procedure by sending TRACKING AREA UPDATE REQUEST message. The IEs (some of them are explained below) in this message include EPS update type, NAS key set identifier, Old GUTI, GPRS ciphering key sequence number, Old P-TMSI signature, Additional GUTI, UE network capability, Last visited registered TAI, DRX parameter, UE radio capability information update needed, EPS bearer context status, MS network capability, Old location area identification, Supported Codecs, Additional update type, Voice domain preference and UE's usage setting, Device properties etc…

In the IE EPS update type the first 3 bits (LSBs) shall be used to indicate update type (ex:- ‘TA updating’ or ‘combined TA/LA updating’ or ‘combined TA/LA updating with IMSI attach’ or ‘periodic updating’). Additionally, if a UE has uplink user data pending when it initiates the TAU procedure or uplink signalling not related to the TAU procedure, it may also set an "active" flag (bit4) in this IE to indicate the request to establish the user plane to the network and to keep the NAS signalling connection after the completion of the TAU procedure

The IE Old GUTI shall be handled as follows:

·         UEs supporting A/Gb mode or Iu mode or both:

-      If TIN = "P-TMSI" and the UE holds a valid P-TMSI and RAI, the UE shall map the P-TMSI and RAI into the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "mapped GUTI". Additionally, if the UE holds a valid GUTI, then it shall be indicated in the IE Additional GUTI

-      If TIN = “GUTI” or “RAT-related TMSI” and the UE holds a valid GUTI, the UE shall indicate the GUTI in the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "native GUTI"

·         UEs not supporting A/Gb mode or Iu mode: The UE shall include a valid GUTI in the Old GUTI IE. In addition, the UE shall include Old GUTI type IE with GUTI type set to "native GUTI"

The IE Additional Update Type provides additional information about the type of request for a TAU procedure. Bit1 value 0 means that there is “no additional information” and 1 means that “SMS only”

Voice domain preference and UE's usage setting IE shall be included if the UE supports CS fallback and SMS over SGs, or if the UE is configured to support IMS voice, but does not support 1xCS fallback. This IE provides the network with the UE's usage setting and the voice domain preference for E-UTRAN. Refer to 3GPP TS 24.008, section 10.5.5.28 for detailed information

The IE Last Visited Registered TAI shall be included if the UE holds a valid last visited registered Tracking Area Identity (TAI)

The purpose of the Device properties IE is to indicate if the MS is configured for NAS signalling low priority. The network uses the Device properties IE for core-network congestion handling and for charging purposes. This IE can indicate “MS is not configured for NAS signalling low priority” or “MS is configured for NAS signalling low priority”

Reference: 3GPP TS 24.301 and 24.008

Example1: TRACKING AREA UPDATE REQUEST message (Normal TA updating)

Example2: TRACKING AREA UPDATE REQUEST message (Periodic TA updating)

LTE: Attach Complete

The ATTACH COMPLETE message is sent by the UE to the network in response to an ATTACH ACCEPT message

When the UE receives the ATTACH ACCEPT message combined with the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, it shall forward the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to the ESM sublayer. Once the ESM sublayer indicates that the default EPS bearer context has been activated, the UE shall send an ATTACH COMPLETE message together with an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message contained in the ESM message container IE to the network

If the ACTIVATE DEFAULT BEARER CONTEXT REQUEST message combined with the ATTACH ACCEPT is not accepted by the UE due to failure in the UE's ESM sublayer, then the UE shall not send ATTACH COMPLETE message. Instead, it shall initiate the detach procedure by sending a DETACH REQUEST message to the network. Further UE's behavior is implementation specific

Reference: 3GPP TS 24.301

Example: ATTACH COMPLETE Message