LTE,LTE-A,5G,IMS,OpenFlow,SDN,NFV,Shell,Python etc.: 2016

Saturday, 27 August 2016

Attach procedure

The attach procedure is used to attach to an EPC for packet services in EPS.

The attach procedure is used for three purposes:

- by a UE in PS mode of operation to attach for EPS services only;

- by a UE in CS/PS mode 1 or CS/PS mode 2 of operation to attach for both EPS and non-EPS services; or

- to attach for emergency bearer services.

If the MME does not support an attach for emergency bearer services, the MME shall reject any request to attach with an attach type set to "EPS emergency attach".

Editor's note: The EMM cause code to be used in this case where the MME rejects the attach is FFS.

With a successful attach procedure, a context is established for the UE in the MME, and a default bearer is established between the UE and the PDN GW, thus enabling always-on IP connectivity to the UE. The network may also initiate the activation of dedicated bearers as part of the attach procedure.

During the attach procedure, the UE may also obtain the home agent IPv4 and IPv6 addresses.

In a shared network, the UE shall choose one of the PLMN identities as specified in 3GPP TS 23.122 [6]. The UE shall construct the TAI of the cell from this chosen PLMN identity and the TAC received as part of the broadcast system information. The chosen PLMN identity shall be indicated to the E-UTRAN (see 3GPP TS 36.331 [22]). Whenever an ATTACH REJECT message with the EMM cause #11 "PLMN not allowed" is received by the UE, the chosen PLMN identity shall be stored in the "forbidden PLMN list". Whenever an ATTACH REJECT message with the EMM cause #14 "EPS services not allowed in this PLMN" is received by the UE, the chosen PLMN identity shall be stored in the "forbidden PLMNs for GPRS service". Whenever an ATTACH REJECT message is received by the UE 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", the constructed TAI shall be stored in the suitable list.

An attach attempt counter is used to limit the number of subsequently rejected attach attempts. The attach attempt counter shall be incremented as specified in subclause 5.5.1.2.6. Depending on the value of the attach attempt counter, specific actions shall be performed. The attach attempt counter shall be reset when:

- the UE is powered on;

- a USIM is inserted;

- an attach or combined attach procedure is successfully completed;

- a combined attach procedure is completed for EPS services only with cause #2, #16, #17, #18 or #22;

- an attach or combined attach procedure is rejected with cause #11, #12, #13, #14, #15 or #25; or

- a network initiated detach procedure is completed with cause #11, #12, #13, #14, #15 or #25.

Additionally the attach attempt counter shall be reset when the UE is in substate EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH and:

- a new tracking area is entered; or

- T3402 expires.

Attach procedure for EPS services

This procedure is used by a UE to attach for EPS services only. When the UE initiates the attach procedure,for normal service the UE shall indicate "EPS attach" in the EPS attach type IE.

When the UE initiates the attach procedure for emergency bearer services, the UE shall indicate "EPS emergency attach" in the EPS attach type IE.

Attach procedure initiation

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see example in figure 5.5.1.2.2.1). If timer T3402 is currently running, the UE shall stop timer T3402. If timer T3411 is currently running, the UE shall stop timer T3411.

If the UE supports neither A/Gb mode nor Iu mode, the UE shall handle the EPS mobile identity IE in the ATTACH REQUEST message as follows:

- The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered TAI, if available. If there is no valid GUTI available, the UE shall include the IMSI in the ATTACH REQUEST message.

If the UE supports A/Gb mode or Iu mode, the UE shall handle the EPS mobile identity as follows:

- If the TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and RAI, the UE shall map the P-TMSI and RAI into the EPS mobile identity IE. If a P-TMSI signature is associated with the P-TMSI, the UE shall include it in the Old P-TMSI signature IE. Additionally, if the UE holds a valid GUTI, the UE shall indicate the GUTI in the Additional GUTI IE.

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

- If the TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI, the UE shall indicate the GUTI in the EPS mobile identity IE.

- If the TIN is deleted and

- the UE holds a valid GUTI, the UE shall indicate the GUTI in the EPS mobile identity IE; or

- otherwise, if the UE holds a valid P-TMSI and RAI, the UE shall map the P-TMSI and RAI into the EPS mobile identity IE. If a P-TMSI signature is associated with the P-TMSI, the UE shall include it in the Old P-TMSI signature IE.

- Otherwise,

- if the UE has an IMSI, the UE shall include the IMSI in the EPS mobile identity IE; or

- if the UE has no IMSI and initiates the attach procedure for emergency bearer service, the UE shall include its IMEI in the EPS mobile identity IE.

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message contained in the ESM message container information element to request PDN connectivity.

If UE supports A/Gb mode or Iu mode or if the UE wants to indicate its UE specific DRX parameter to the network, the UE shall include the UE specific DRX parameter in the DRX parameter IE in the ATTACH REQUEST message.

If a valid NAS security context exists, the UE shall integrity protect the ATTACH REQUEST message combined with the PDN CONNECTIVITY REQUEST message. When the UE does not have a valid NAS security context, the ATTACH REQUEST message combined with the PDN CONNECTIVITY REQUEST message is not integrity protected.

Attach procedure and combined attach procedure

EMM common procedure initiation

The network may initiate EMM common procedures, e.g. the identification, authentication and security mode control procedures during the attach procedure, depending on the information received in the ATTACH REQUEST message (e.g. IMSI, GUTI and KSI).

During an attach for emergency bearer services, the MME may choose to skip the authentication procedure even if no EPS security context is available and proceed directly to the execution of the security mode control procedure as specified in subclause 5.4.3.

Attach accepted by the network

If the attach request is accepted by the network, the MME shall send an ATTACH ACCEPT message to the UE and start timer T3450. The MME shall send the ATTACH ACCEPT message together with an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message contained in the ESM message container information element to activate the default bearer (see subclause 6.4.1). The network may also initiate the activation of dedicated bearers towards the UE by invoking the dedicated EPS bearer context activation procedure (see subclause 6.4.2).

If the attach request is accepted by the network, the MME shall delete the stored UE radio capability information, if any.

If the UE has included the UE network capability IE or the MS network capability IE or both in the ATTACH REQUEST message, the MME shall store all octets received from the UE, up to the maximum length defined for the respective information element.

NOTE: This information is forwarded to the new MME during inter-MME handover or to the new SGSN during inter-system handover to A/Gb mode or Iu mode.

If the UE specific DRX parameter was included in the DRX Parameter IE in the ATTACH REQUEST message, the MME shall replace any stored UE specific DRX parameter with the received parameter and use it for the downlink transfer of signalling and user data.

The MME shall assign and include the TAI list the UE is registered to in the ATTACH ACCEPT message. The UE, upon receiving an ATTACH ACCEPT message, shall delete its old TAI list and store the received TAI list.

Upon receiving the ATTACH ACCEPT message, the UE shall stop timer T3410.

The GUTI reallocation may be part of the attach procedure. When the ATTACH REQUEST message includes the IMSI or IMEI, or the MME considers the GUTI provided by the UE is invalid,or the GUTI provided by the UE was assigned by another MME, the MME shall allocate a new GUTI to the UE. The MME shall include in the ATTACH ACCEPT message the new assigned GUTI together with the assigned TAI list. In this case the MME shall enter state EMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.4.1.

For a shared network, the TAIs included in the TAI list can contain different PLMN identities. The MME indicates the selected core network operator PLMN identity to the UE in the GUTI (see 3GPP TS 23.251 [8B]).

If the ATTACH ACCEPT message contains a GUTI, the UE shall use this GUTI as the new temporary identity. The UE shall delete its old GUTI and store the new assigned GUTI. If no GUTI has been included by the MME in the ATTACH ACCEPT message, the old GUTI, if any available, shall be kept.

If A/Gb mode or Iu mode is supported in the UE, the UE shall set its TIN to "GUTI" when receiving the ATTACH ACCEPT message.

The MME may also include a list of equivalent PLMNs in the ATTACH ACCEPT message. Each entry in the list contains a PLMN code (MCC+MNC). The UE shall store the list as provided by the network, and if the attach procedure is not for emergency bearer services, the UE shall remove from the list any PLMN code that is already in the list of forbidden PLMNs. In addition, the UE shall add to the stored list the PLMN code of the registered PLMN that sent the list. The UE shall replace the stored list on each receipt of the ATTACH ACCEPT message. If the ATTACH ACCEPT message does not contain a list, then the UE shall delete the stored list.

The network informs the UE about the support of specific features, such as IMS voice over PS session or emergency bearer services, in the EPS network feature support information element. In a UE with IMS voice over PS capability, the IMS voice over PS session indicator and the emergency bearer services indicator shall be provided to the upper layers. The upper layers take the IMS voice over PS session indicator into account as specified in 3GPP TS 23.221 [8A], subclause 7.2a, when selecting the access domain for voice sessions or calls. When initiating an emergency call, the upper layers also take the emergency bearer services indicator into account for the access domain selection.

If the UE has initiated the attach procedure due to manual CSG selection and receives an ATTACH ACCEPT message; and the cell where UE has sent the ATTACH REQUEST message provides services only to its associated CSG members, the UE shall check if the CSG ID of the cell is contained in the Allowed CSG list. If not, the UE shall add that CSG ID to the Allowed CSG list.

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. Upon receipt of an indication from the ESM sublayer 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 information element to the network.

Additionally, the UE shall reset the attach attempt counter and tracking area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EU1 UPDATED.

When the UE receives any ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST messages during the attach procedure, the UE shall forward the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message(s) to the ESM sublayer. The UE shall send a response to the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message(s) after successful completion of the attach procedure.

If the attach procedure was initiated in S101 mode, the lower layers are informed about the successful completion of the procedure.

Upon receiving an ATTACH COMPLETE message, the MME shall stop timer T3450, enter state EMM-REGISTERED and consider the GUTI sent in the ATTACH ACCEPT message as valid.

Attach not accepted by the network

If the attach request cannot be accepted by the network, the MME shall send an ATTACH REJECT message to the UE including an appropriate EMM cause value. If the attach procedure fails due to a default EPS bearer setup failure, an ESM procedure failure, or operator determined barring is applied on default EPS bearer context activation during attach procedure, the MME shall combine the ATTACH REJECT message with a PDN CONNECTIVITY REJECT message contained in the ESM message container information element. In this case the EMM cause value in the ATTACH REJECT message shall be set to #19 "ESM failure".

Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions depending on the EMM cause value received.

#3 (Illegal UE); or

#6 (Illegal ME);

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM-DEREGISTERED.

If A/Gb mode or Iu mode is supported by the UE, the UE shall in addition handle the MM parameters update status, TMSI, LAI and ciphering key sequence number, and the GMM parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the same value.

NOTE: The possibility to configure a UE so that the radio transceiver for a specific RAT is not active, although it is implemented in the UE, is out of scope of the present specification.

#5 (IMEI not accepted);

The UE shall enter the state EMM-DEREGISTERED.NO-IMSI.

#7 (EPS services not allowed);

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM-DEREGISTERED.

If A/Gb mode 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 as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the same value.

#8 (EPS services and non-EPS services not allowed);

#11 (PLMN not allowed);

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally, the UE shall delete the list of equivalent PLMNs and reset the attach attempt counter, and enter state EMM-DEREGISTERED.PLMN-SEARCH.

In S1 mode, the UE shall store the PLMN identity in the "forbidden PLMN list" and enter state EMM-DEREGISTERED.PLMN-SEARCH. The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6].

In S101 mode, the UE shall store the PLMN identity provided with the indication from the lower layers to prepare for an S101 mode to S1 mode handover in the list of "forbidden PLMNs for attach in S101 mode" and enter the state EMM-DEREGISTERED.NO-CELL-AVAILABLE.

If A/Gb mode or Iu mode is supported by the UE, the UE shall in addition handle the MM parameters update status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the same value and no RR connection exists.

#12 (Tracking area not allowed);

In S1 mode, the UE shall store the current TAI in the list of "forbidden tracking areas for regional provision of service" and enter the state EMM-DEREGISTERED.LIMITED-SERVICE.

If A/Gb mode 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, GPRS ciphering key sequence number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the same value.

#13 (Roaming not allowed in this tracking area);

In S1 mode, the UE shall store the current TAI in the list of "forbidden tracking areas for roaming". Additionally, the UE shall enter the state EMM-DEREGISTERED.LIMITED-SERVICE or optionally EMM-DEREGISTERED.PLMN-SEARCH. The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6].

#14 (EPS services not allowed in this PLMN);

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI.

In S1 mode, the UE shall store the PLMN identity in the "forbidden PLMNs for GPRS service" list. Additionally, the UE shall enter state EMM-DEREGISTERED.PLMN-SEARCH. The UE shall perform a PLMN selection according to 3GPP TS 23.122 [6].

#15 (No suitable cells in tracking area);

In S1 mode, the UE shall store the current TAI in the list of "forbidden tracking areas for roaming" and enter the state EMM-DEREGISTERED.LIMITED-SERVICE. The UE shall search for a suitable cell in another tracking area or in another location area in the same PLMN according to 3GPP TS 36.304 [21].

#25 (Not authorized for this CSG);

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3). Additionally, the UE shall reset the attach attempt counter and shall enter the state EMM-DEREGISTERED.LIMITED-SERVICE.

The UE shall remove the CSG ID of the cell where the UE has sent the ATTACH REQUEST message from the Allowed CSG list.

The UE shall search for a suitable cell in the same PLMN according to 3GPP TS 36.304 [21].

If A/Gb mode or Iu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM state, GPRS update status and GPRS attach attempt counter as specified in 3GPP TS 24.008 [13] for the case when the normal attach procedure is rejected with the GMM cause with the same value.

Detach procedure

The detach procedure is used:

- by the UE to detach for EPS services only;

- by the UE to disconnect from the last PDN it is connected to;

- by the UE in CS/PS mode 1 or CS/PS mode 2 of operation to detach for both EPS services and non-EPS services or for non-EPS services only via a combined detach procedure;

- by the network to inform the UE that it is detached for EPS services or non-EPS services or both; and

- by the network to disconnect the UE from the last PDN to which it is connected.

NOTE: After a successful completion of an inter-system change of the UE from S1 mode to non-3GPP access, if the non-3GPP network provides PDN connectivity to the same EPC, the MME performs a local detach of the UE.

The detach procedure shall be invoked by the UE if the UE is switched off, the USIM card is removed from the UE or the EPS capability or CS Fallback capability of the UE is disabled.

If a detach is requested by the HSS for a UE that has bearers for emergency services, the MME shall not send a DETACH REQUEST message to the UE, and shall follow the procedures in subclause 6.4.4.1 for a UE that has bearers for emergency services.

If the detach procedure for EPS services is performed, the EPS bearer context(s) for this particular UE are deactivated locally without peer-to-peer signalling between the UE and the MME.

Upon successful completion of the detach procedure, the UE and the MME shall delete the EPS mapped security context if any.

If the UE supports A/Gb mode or Iu mode, the UE shall store the TIN in the non-volatile memory in the ME, as described in annex C, for a subsequent attach procedure.

UE initiated detach procedure

UE initiated detach procedure initiation

The detach procedure is initiated by the UE by sending a DETACH REQUEST message (see example in figure 5.5.2.2.1.1). The Detach type IE included in the message indicates whether detach is due to a "switch off" or not. The Detach type IE also indicates whether the detach is for EPS services only, for non-EPS services only, or for both. If the UE has a mapped EPS security context as the current EPS security context, the UE shall set the type of security context flag to "mapped security context". Otherwise, the UE shall set the type of security context flag to "native security context".

If the UE has a valid GUTI, the UE shall populate the GUTI or IMSI IE with the valid GUTI. If the UE does not have a valid GUTI, the UE populates the GUTI or IMSI IE with its IMSI.

If the detach is not due to switch off and the UE is in the state EMM-REGISTERED or EMM-REGISTERED-INITIATED, timer T3421 shall be started in the UE after the DETACH REQUEST message has been sent. The UE shall store the native EPS security context, if valid, as specified in annex C.If the detach type indicates that the detach is for non-EPS services only the UE shall enter the state EMM-REGISTERED.IMSI-DETACH-INITIATED, otherwise the UE shall enter the state EMM-DEREGISTERED-INITIATED. If the detach type indicates that the detach is for non-EPS services or both EPS and non-EPS services, the UE shall enter the state MM IMSI DETACH PENDING.

If the UE is to be switched off, the UE shall:

- delete the current EPS security context stored in the UE as specified in annex C, if it is a mapped EPS security context;

- store the native EPS security context (if it is valid), as specified in annex C; and

- try for a period of 5 seconds to send the DETACH REQUEST message. During this period, the UE may be switched off as soon as the DETACH REQUEST message has been sent.

UE initiated detach procedure

UE initiated detach procedure completion for EPS services only

When the DETACH REQUEST message is received by the network, the network shall send a DETACH ACCEPT message to the UE and store the current EPS security context, if the Detach type IE does not indicate "switch off". Otherwise, the procedure is completed when the network receives the DETACH REQUEST message. On reception of a DETACH REQUEST message indicating "switch off", the MME shall delete the current EPS security context if it is a mapped EPS security context.

The network and the UE shall deactivate the EPS bearer context(s) for this UE locally without peer-to-peer signalling between the UE and the MME.

The UE, when receiving the DETACH ACCEPT message, shall stop timer T3421.

The UE is marked as inactive in the network for EPS services. State EMM-DEREGISTERED is entered in the network.

The UE in PS mode of operation shall enter the EMM-DEREGISTERED state.

The UE in CS/PS mode 1 or CS/PS mode 2 of operation shall set the update status to U2 NOT UPDATED, disable E‑UTRAN and select GERAN or UTRAN access technology and enter the EMM-NULL state.

UE initiated combined detach procedure completion

When the DETACH REQUEST message is received by the network, a DETACH ACCEPT message shall be sent to the UE, if the Detach type IE value indicates that the detach request has not been sent due to switching off. Depending on the value of the Detach type IE the following applies:

- combined EPS/IMSIdetach:

The UE is marked as inactive in the network for EPS and for non-EPS services. The states EMM-DEREGISTERED and MM-NULL are entered in both the UE and the network.

- IMSI detach:

The UE is marked as inactive in the network for non-EPS services. The states MM-NULL and EMM-REGISTERED are entered in both the UE and the network.

Tuesday, 19 July 2016

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

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.

Saturday, 27 August 2016

EMM specific procedures

This procedure is used by a UE to attach for EPS services only. When the UE initiates the attach procedure,for normal service the UE shall indicate "EPS attach" in the EPS attach type IE.

Detach procedure

The detach procedure is used:

Tuesday, 19 July 2016

EMM common procedures