4 General

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

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

4.1 Overview

The non-access stratum (NAS) described in the present document forms the highest stratum of the control plane between UE and MME at the radio interface (reference point "LTE-Uu"; see 3GPP TS 23.401 [10]).

Main functions of the protocols that are part of the NAS are:

– the support of mobility of the user equipment (UE); and

– the support of session management procedures to establish and maintain IP connectivity between the UE and a packet data network gateway (PDN GW).

NAS security is an additional function of the NAS providing services to the NAS protocols, e.g. integrity protection and ciphering of NAS signalling messages.

For the support of the above functions, the following procedures are supplied within this specification:

– elementary procedures for EPS mobility management in clause 5; and

– elementary procedures for EPS session management in clause 6.

Complete NAS transactions consist of specific sequences of elementary procedures. Examples of such specific sequences can be found in 3GPP TS 23.401 [10].

The NAS for EPS follows the protocol architecture model for layer 3 as described in 3GPP TS 24.007 [12]; however, due to the objective of EPS to provide the subscriber with a "ready-to-use" IP connectivity and an "always-on" experience, the protocol supports a linkage between mobility management and session management procedures during the attach procedure (see clause 4.2).

Signalling procedures for the control of NAS security are described as part of the EPS mobility management in clause 5. In addition to that, principles for the handing of EPS security contexts and for the activation of ciphering and integrity protection, when a NAS signalling connection is established, are provided in clause 4.4.

4.2 Linkage between the protocols for EPS mobility management and EPS session management

During the EPS attach procedure, the network can activate a default EPS bearer context (i.e. if the UE requests PDN connectivity in the attach request). Additionally, the network can activate one or several dedicated EPS bearer contexts in parallel for PDN connections of IP or Ethernet PDN type. To this purpose the EPS session management messages for the default EPS bearer context activation can be transmitted in an information element in the EPS mobility management messages. In this case, the UE and the network execute the attach procedure, the default EPS bearer context activation procedure, and the dedicated EPS bearer context activation procedure in parallel. The UE and network shall complete the combined default EPS bearer context activation procedure and the attach procedure before the dedicated EPS bearer context activation procedure is completed. If EMM-REGISTERED without PDN connection is not supported by the UE or the MME, then the success of the attach procedure is dependent on the success of the default EPS bearer context activation procedure. If the attach procedure fails, then the ESM procedures also fail.

A UE using EPS services with control plane CIoT EPS optimization can initiate transport of user data via the control plane. For this purpose a UE in EMM-IDLE mode can initiate the service request procedure and transmit the ESM DATA TRANSPORT message in an information element in the CONTROL PLANE SERVICE REQUEST message.

Except for the attach procedure and the service request procedure, during EMM procedures the MME shall suspend the transmission of ESM messages. During the service request procedure the MME may suspend the transmission of ESM messages.

Except for the attach procedure and the service request procedure for UE initiated transport of user data via the control plane, during EMM procedures the UE shall suspend the transmission of ESM messages.

4.2A Handling of NAS signalling low priority indication

A UE configured for NAS signalling low priority (see 3GPP TS 24.368 [15A], 3GPP TS 31.102 [17]) indicates this by including the Device properties IE in the appropriate NAS message and setting the low priority indicator to "MS is configured for NAS signalling low priority", except for the following cases in which the UE shall set the low priority indicator to "MS is not configured for NAS signalling low priority":

– the UE is performing an attach for emergency bearer services;

– the UE has a PDN connection for emergency bearer services established and is performing EPS mobility management procedures, or is establishing a PDN connection for emergency bearer services;

– the UE configured for dual priority is requested by the upper layers to establish a PDN connection with the low priority indicator set to "MS is not configured for NAS signalling low priority";

– the UE configured for dual priority is performing EPS session management procedures related to the PDN connection established with low priority indicator set to "MS is not configured for NAS signalling low priority";

– the UE configured for dual priority has a PDN connection established by setting the low priority indicator to "MS is not configured for NAS signalling low priority" and is performing EPS mobility management procedures;

– the UE is performing a service request procedure for a CS fallback emergency call or 1xCS fallback emergency call;

– the UE is a UE configured to use AC11 – 15 in selected PLMN; or

– the UE is responding to paging.

The network may use the NAS signalling low priority indication for NAS level mobility management congestion control and APN based congestion control.

If the NAS signalling low priority indication is provided in a PDN CONNECTIVITY REQUEST message, the MME stores the NAS signalling low priority indication within the default EPS bearer context activated due to the PDN connectivity request procedure.

4.3 UE mode of operation

4.3.1 General

A UE attached for EPS services shall operate in one of the following operation modes:

– PS mode 1 of operation: the UE registers only to EPS services, and UE’s usage setting is "voice centric";

– PS mode 2 of operation: the UE registers only to EPS services, and UE’s usage setting is "data centric";

– CS/PS mode 1 of operation: the UE registers to both EPS and non-EPS services, and UE’s usage setting is "voice centric"; and

– CS/PS mode 2 of operation: the UE registers to both EPS and non-EPS services, and UE’s usage setting is "data centric".

A UE configured to use CS fallback, shall operate in CS/PS mode 1 or CS/PS mode 2. Such UE may also be configured to use IMS, in which case the voice domain preference for E-UTRAN as defined in 3GPP TS 24.167 [13B] shall be used for the selection of the domain for originating voice communication services.

NOTE 1: The domain selected for originating voice communication services can be ignored by attempting a CS emergency call.

Upon request from upper layers to establish a CS emergency call:

– if the UE needs to initiate a CS fallback emergency call but it is unable to perform CS fallback, the UE shall attempt to select GERAN or UTRAN radio access technology, and a UE with "IMS voice not available" should disable the E-UTRA capability (see clause 4.5) to allow a potential callback, and then progress the CS emergency call establishment;

– if the UE needs to initiate a 1xCS fallback emergency call but it is unable to perform 1xCS fallback, the UE shall attempt to select cdma2000® 1x radio access technology to establish the call.

NOTE 2: Unable to perform CS fallback or 1xCS fallback means that either the UE was not allowed to attempt CS fallback or 1xCS fallback, or CS fallback or 1xCS fallback attempt failed.

A UE configured to use SMS over SGs shall operate in CS/PS mode 1 or CS/PS mode 2.

The behaviour of the UE in CS/PS mode 1 of operation, upon failure to access the CS domain or upon reception of a "CS fallback not preferred" or "SMS only" indication, will depend on the availability of voice over IMS. In the present document, "IMS voice not available" refers to one of the following conditions:

a) the UE is not configured to use IMS;

b) the UE is not configured to use IMS voice, i.e. when the voice domain preference for E-UTRAN, as defined in 3GPP TS 24.167 [13B], indicates that voice communication services are allowed to be invoked only over the CS domain;

c) the UE is configured to use IMS voice, but the network indicates in the ATTACH ACCEPT message or the TRACKING AREA UPDATE ACCEPT message that IMS voice over PS sessions are not supported; or

d) the UE is configured to use IMS voice, the network indicates in the ATTACH ACCEPT message or the TRACKING AREA UPDATE ACCEPT message that IMS voice over PS sessions are supported, but the upper layers:

– provide no indication that the UE is available for voice call in the IMS within a manufacturer determined period of time; or

– indicate that the UE is not available for voice calls in the IMS.

NOTE 3: If conditions a, b and c evaluate to false, the upper layers need time to attempt IMS registration. In the event an indication from the upper layers that the UE is available for voice calls in the IMS takes longer than the manufacturer determined period of time (e.g. due to delay when attempting IMS registration or due to delay obtaining an EPS bearer context for SIP signalling), the NAS layer assumes the UE is not available for voice calls in the IMS.

Other conditions may exist but these are implementation specific.

In the present document, "IMS voice available" refers to the conditions a, b, c and d, and other implementation specific conditions for "IMS voice not available" evaluate to false.

4.3.2 Change of UE mode of operation

4.3.2.1 General

The UE mode of operation can change as a result of e.g.:

– a change of UE’s usage setting for a CS voice capable UE;

– a change of voice domain preference for E-UTRAN as defined in 3GPP TS 24.167 [13B] for a CS voice capable UE;

– a change in the UE’s availability for voice calls in the IMS; or

– a change in UE configuration regarding the use of SMS as defined in 3GPP TS 24.167 [13B].

Figure 4.3.2.1.1 and figure 4.3.2.1.2 illustrate the transitions between different UE mode of operations when UE’s usage settings, voice domain preference for E-UTRAN or configuration regarding SMS changes.

NOTE 1: The UE may transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2 if "CS domain not available" is received. After the transition to PS mode 1 or PS mode 2 due to "CS domain not available", the UE can transit back to CS/PS mode 1 or CS/PS mode 2, e.g. due to change of PLMN which is not in the list of the equivalent PLMNs.

NOTE 2: Not all possible transitions are shown in this figure.

Figure 4.3.2.1.1: Change of UE mode of operation for a CS voice capable UE

NOTE: Not all possible transitions are shown in this figure.

Figure 4.3.2.1.2: Change of UE mode of operation for a UE with no CS voice capability

4.3.2.2 Change of UE’s usage setting

Whenever the UE’s usage setting changes, the UE dependent on its mode of operation shall execute procedures according to table 4.3.2.2.1 and table 4.3.2.2.2:

a) The UE is operating in PS mode 1 or PS mode 2

Table 4.3.2.2.1: Change of UE’s usage setting for a UE in PS mode 1 or PS mode 2

UE’s usage setting change	Procedure to execute
From data centric to voice centric and "IMS voice not available"	Disable the E-UTRA capability if voice domain selection results in a selection to a different RAT (see clause 4.5), or combined tracking area update with IMSI attach if voice domain selection results in attempt to stay in E-UTRAN.
From voice centric to data centric and E-UTRA is disabled	Re-enable the E-UTRA capability (see clause 4.5)

b) The UE is operating in CS/PS mode 1 or CS/PS mode 2

Table 4.3.2.2.2: Change of UE’s usage setting for a UE in CS/PS mode 1 or CS/PS mode 2

UE’s usage setting change	Procedure to execute
From data centric to voice centric, "CS fallback is not available" and "IMS voice not available" (NOTE 1)	Disable the E-UTRA capability (see clause 4.5)
From data centric to voice centric, "IMS voice not available" and the UE received a "CS fallback not preferred" or "SMS only" indication during the last successful combined attach or combined tracking area updating procedure	Disable the E-UTRA capability (see clause 4.5)
From voice centric to data centric and E-UTRA is disabled	Re-enable the E-UTRA capability (see clause 4.5)
NOTE 1: "CS fallback is not available" includes EMM causes #16, #17, and #18

4.3.2.3 Change of voice domain preference for E-UTRAN

Whenever the voice domain preference for E-UTRAN changes, the UE dependent on its mode of operation shall execute procedures according to table 4.3.2.3.1 and table 4.3.2.3.2:

a) The UE is operating in PS mode 1 or PS mode 2

Table 4.3.2.3.1: Change of voice domain preference for E-UTRAN for a UE in PS mode 1 or PS mode 2

Voice domain preference for E-UTRAN change	Procedure to execute
From "IMS PS voice only" to "CS voice only" or "CS voice preferred, IMS PS Voice as secondary"	Transit from PS mode 1 to CS/PS mode 1 or from PS mode 2 to CS/PS mode 2. Combined tracking area update with IMSI attach
From "IMS PS voice preferred, CS Voice as secondary" to "CS voice only" or "CS voice preferred, IMS PS Voice as secondary"	Transit from PS mode 1 to CS/PS mode 1 or from PS mode 2 to CS/PS mode 2. Combined tracking area update with IMSI attach

b) The UE is operating in CS/PS mode 1 or CS/PS mode 2

Table 4.3.2.3.2: Change of voice domain preference for E-UTRAN for a UE in CS/PS mode 1 or CS/PS mode 2

Voice domain preference for E-UTRAN change	Procedure to execute
From any configuration to "IMS PS voice only", UE is configured to prefer SMS over IP networks and the UE is available for voice calls in the IMS.	May: – transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2; and – detach for non-EPS services
From any configuration to "CS voice only", UE is in CS/PS mode 1 of operation and "CS fallback is not available"(NOTE 1)	Disable the E-UTRA capability (see clause 4.5)
From any configuration to "CS voice only", UE is in CS/PS mode 1 of operation and the UE received a "CS fallback not preferred" or "SMS only" indication during the last successful combined attach or combined tracking area updating procedure.	Disable the E-UTRA capability (see clause 4.5)
From "CS voice only" to any configuration and E-UTRA capability was disabled due to change of voice domain preference for E-UTRAN.	Re-enable the E-UTRA capability (see clause 4.5). If an RR or RRC connection exists, the UE shall delay re-enabling the E-UTRA capability until the RR or RRC connection is released.
NOTE 1: "CS fallback is not available" includes EMM causes #16, #17, and #18

4.3.2.4 Change or determination of IMS registration status

Whenever the UE’s availability for voice calls in the IMS is determined or changes (e.g. whenever the IMS registration status is determined or changes), the UE dependent on its mode of operation shall execute procedures according to table 4.3.2.4.1, 4.3.2.4.2 or 4.3.2.4.3:

a) The UE is operating in PS mode 1

Table 4.3.2.4.1: Change of IMS registration status for a UE in PS mode 1

Change of IMS registration status	Procedure to execute
UE is not available for voice calls in the IMS indication and voice domain preference for E-UTRAN is "IMS PS voice preferred, CS Voice as secondary"	Transit to CS/PS mode 1. Combined tracking area update with IMSI attach
UE is not available for voice calls in the IMS indication, SMS configuration is set to prefer to use SMS over IP networks, and voice domain preference for E-UTRAN is "IMS PS voice only"	Disable the E-UTRA capability (see clause 4.5)
UE is not available for voice calls in the IMS indication, SMS configuration is set to prefer to use SMS over IP networks, and UE is not CS voice capable	May disable the E-UTRA capability (see clause 4.5)

NOTE 1: If the UE in PS mode 1 transits to CS/PS mode 1 according to table 4.3.2.4.1, then the UE can return to PS mode 1 when the upper layer indicates the status of being available for voice over PS.

b) The UE is operating in PS mode 2

Table 4.3.2.4.2: Change of IMS registration status for a UE in PS mode 2

Change of IMS registration status	Procedure to execute
UE is not available for voice calls in the IMS indication and voice domain preference for E-UTRAN is "IMS PS voice preferred, CS Voice as secondary"	Transit to CS/PS mode 2. Combined tracking area update with IMSI attach
Unsuccessful IMS registration indication from upper layers, SMS configuration is set to prefer to use SMS over IP networks, and voice domain preference for E-UTRAN is "IMS PS voice only"	Transit to CS/PS mode 2. Combined tracking area update with "SMS only"
Unsuccessful IMS registration indication from upper layers, SMS configuration is set to prefer to use SMS over IP networks, and UE is not CS voice capable	Transit to CS/PS mode 2. Combined tracking area update with "SMS only"

NOTE 2: If the UE in PS mode 2 transits to CS/PS mode 2 according to table 4.3.2.4.2, then the UE can return to PS mode 2 when the upper layer indicates the status of being available for voice over PS.

c) The UE is operating in CS/PS mode 1

Table 4.3.2.4.3: Change of IMS registration status for a UE in CS/PS mode 1

Change of IMS registration status	Procedure to execute
UE is not available for voice calls in the IMS indication, and any of: – "CS fallback is not available" (NOTE 1); or – the UE received a "CS fallback not preferred" or "SMS only" indication during the last successful combined attach or combined tracking area updating procedure	Disable the E-UTRA capability (see clause 4.5)
UE is not available for voice calls in the IMS indication, UE is in state EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM and timer T3402 is running	May disable the E-UTRA capability (see clause 4.5)
NOTE 1: "CS fallback is not available" includes EMM causes #16, #17, and #18

4.3.2.5 Change of configuration regarding the use of SMS.

Whenever the UE’s configuration on use of SMS changes, the UE dependent on its mode of operation shall execute procedures according to table 4.3.2.5.1 and table 4.3.2.5.2:

a) The UE is operating in PS mode 1 or PS mode 2

Table 4.3.2.5.1: Change of configuration regarding the use of SMS in PS mode 1 or PS mode 2

SMS configuration change	Procedure to execute
Change to "SMS service is not preferred to be invoked over IP networks" or the UE is unable to use SMS using IMS (see 3GPP TS 24.229 [13D]).	Transit from PS mode 1 to CS/PS mode 1 or from PS mode 2 to CS/PS mode 2. Combined tracking area update with IMSI attach, (with or without "SMS only")

b) The UE is operating in CS/PS mode 1 or CS/PS mode 2

Table 4.3.2.5.2: Change of configuration regarding the use of SMS in CS/PS mode 1 or CS/PS mode 2

SMS configuration change

Procedure to execute

Change to "SMS service is preferred to be invoked over IP networks", the UE is able to use SMS using IMS (see 3GPP TS 24.229 [13D]), and UE has no CS voice capability

May:

– transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2; and

– detach for non-EPS services

Change to "SMS service is preferred to be invoked over IP networks", UE is able to use SMS using IMS (see 3GPP TS 24.229 [13D]), and the voice domain preference for E-UTRAN is "IMS PS voice only"

May:

– transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2; and

– detach for non-EPS services

4.4 NAS security

4.4.1 General

This clause describes the principles for the handling of EPS security contexts in the UE and in the MME and the procedures used for the security protection of EPS NAS messages between UE and MME. Security protection involves integrity protection and ciphering of the EMM and ESM NAS messages.

The signalling procedures for the control of NAS security are part of the EMM protocol and are described in detail in clause 5.

NOTE: The use of ciphering in a network is an operator option. In this clause, for the ease of description, it is assumed that ciphering is used, unless explicitly indicated otherwise. Operation of a network without ciphering is achieved by configuring the MME so that it always selects the "null ciphering algorithm", EEA0.

4.4.2 Handling of EPS security contexts

4.4.2.1 General

The security parameters for authentication, integrity protection and ciphering are tied together in an EPS security context and identified by a key set identifier for E-UTRAN (eKSI). The relationship between the security parameters is defined in 3GPP TS 33.401 [19].

Before security can be activated, the MME and the UE need to establish an EPS security context. Usually, the EPS security context is created as the result of an EPS authentication procedure between MME and UE. Alternatively:

– during inter-system handover from A/Gb mode to S1 mode or from Iu mode to S1 mode, the MME and the UE derive a mapped EPS security context from a UMTS security context that has been established while the UE was in A/Gb mode or Iu mode; or

– during CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode, the MME and the UE derive a mapped EPS security context from a CS UMTS security context that has been established while the UE was in A/Gb mode or Iu mode.

The EPS security context is taken into use by the UE and the MME, when the MME initiates a security mode control procedure or during the inter-system handover procedure from A/Gb mode to S1 mode or Iu mode to S1 mode. The EPS security context which has been taken into use by the network most recently is called current EPS security context. This current EPS security context can be of type native or mapped, i.e. originating from a native EPS security context or mapped EPS security context.

The key set identifier eKSI is assigned by the MME either during the EPS authentication procedure or, for the mapped EPS security context, during the inter-system handover procedure. The eKSI consists of a value and a type of security context parameter indicating whether an EPS security context is a native EPS security context or a mapped EPS security context. When the EPS security context is a native EPS security context, the eKSI has the value of KSI_ASME, and when the current EPS security context is of type mapped, the eKSI has the value of KSI_SGSN.

The EPS security context which is indicated by an eKSI can be taken into use to establish the secure exchange of NAS messages when a new NAS signalling connection is established without executing a new EPS authentication procedure (see clause 4.4.2.3) or when the MME initiates a security mode control procedure. For this purpose the initial NAS messages (i.e. ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST, EXTENDED SERVICE REQUEST, and CONTROL PLANE SERVICE REQUEST) and the SECURITY MODE COMMAND message contain an eKSI in the NAS key set identifier IE or the value part of eKSI in the KSI and sequence number IE indicating the current EPS security context used to integrity protect the NAS message.

In the present document, when the UE is required to delete an eKSI, the UE shall set the eKSI to the value "no key is available" and consider also the associated keys K_ASME or K’_ASME, EPS NAS ciphering key and EPS NAS integrity key invalid (i.e. the EPS security context associated with the eKSI as no longer valid).

NOTE: In some specifications the term ciphering key sequence number might be used instead of the term Key Set Identifier (KSI).

The UE and the MME need to be able to maintain two EPS security contexts simultaneously, i.e. a current EPS security context and a non-current EPS security context, since:

– after an EPS re-authentication, the UE and the MME can have both a current EPS security context and a non-current EPS security context which has not yet been taken into use (i.e. a partial native EPS security context); and

– after an inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the UE and the MME can have both a mapped EPS security context, which is the current EPS security context, and a non-current native EPS security context that was created during a previous access in S1 mode or S101 mode.

The number of EPS security contexts that need to be maintained simultaneously by the UE and the MME is limited by the following requirements:

– After a successful EPS (re-)authentication, which creates a new partial native EPS security context, the MME and the UE shall delete the non-current EPS security context, if any.

– When a partial native EPS security context is taken into use through a security mode control procedure, the MME and the UE shall delete the previously current EPS security context.

– When the MME and the UE create an EPS security context using null integrity and null ciphering algorithm during an attach procedure for emergency bearer services, or a tracking area updating procedure for a UE that has a PDN connection for emergency bearer services (see clause 5.4.3.2), the MME and the UE shall delete the previous current EPS security context.

– When a new mapped EPS security context or EPS security context created using null integrity and null ciphering algorithm is taken into use during the inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE shall not delete the previously current native EPS security context, if any. Instead, the previously current native EPS security context shall become a non-current native EPS security context, and the MME and the UE shall delete any partial native EPS security context.

If no previously current native EPS security context exists, the MME and the UE shall not delete the partial native EPS security context, if any.

– When the MME and the UE derive a new mapped EPS security context during inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE shall delete any existing current mapped EPS security context.

– When a non-current full native EPS security context is taken into use by a security mode control procedure, then the MME and the UE shall delete the previously current mapped EPS security context.

– When the UE or the MME moves from EMM-REGISTERED to EMM-DEREGISTERED state, if the current EPS security context is a mapped EPS security context and a non-current full native EPS security context exists, then the non-current EPS security context shall become the current EPS security context. Furthermore, the UE and the MME shall delete any mapped EPS security context or partial native EPS security context.

The UE shall mark the EPS security context on the USIM or in the non-volatile memory as invalid when the UE initiates an attach procedure as described in clause 5.5.1 or when the UE leaves state EMM-DEREGISTERED for any other state except EMM-NULL.

The UE shall store the current native EPS security context as specified in annex C and mark it as valid only when the UE enters state EMM-DEREGISTERED from any other state except EMM-NULL or when the UE aborts the attach procedure without having left EMM-DEREGISTERED.

4.4.2.2 Establishment of a mapped EPS security context during intersystem handover

In order for the UE to derive a mapped EPS security context for an inter-system change from A/Gb mode or Iu mode to S1 mode in EMM-CONNECTED mode, the MME shall generate a KSI_SGSN, create a nonce_MME and generate the K’_ASME using the created nonce_MME as indicated in 3GPP TS 33.401 [19]. The MME shall include the selected NAS algorithms, nonce_MME and generated KSI_SGSN (associated with the K’_ASME) in the NAS security transparent container for handover to E-UTRAN. The MME shall derive the EPS NAS keys from K’_ASME.

When the UE receives the command to perform handover to E-UTRAN, the UE shall derive K’_ASME,as indicated in 3GPP TS 33.401 [19], using the nonce_MME received in the NAS security transparent container. Furthermore, the UE shall associate the derived K’_ASME with the received KSI_SGSN and derive the EPS NAS keys from K’_ASME.

When the UE has a PDN connection for emergency bearer services and has no current UMTS security context, the MME shall set EIA0 and EEA0 as the selected NAS security algorithms in the NAS security transparent container for handover to E-UTRAN. The MME shall create a locally generated K’_ASME. The MME shall set the KSI value of the associated security context to "000" and the type of security context flag to "mapped security context" in the NAS security transparent container for handover to E-UTRAN.

When the UE receives the command to perform handover to E-UTRAN and has a PDN connection for emergency bearer services, if EIA0 and EEA0 as the selected NAS security algorithms are included in the NAS security transparent container for handover to E-UTRAN, the UE shall create a locally generated K’_ASME. The UE shall set the KSI value of the associated security context to the KSI value received.

If the inter-system change from A/Gb mode or Iu mode to S1 mode in EMM-CONNECTED mode is not completed successfully, the MME and the UE shall delete the new mapped EPS security context.

The establishment of a mapped EPS security context during inter-system change from N1 mode to S1 mode in EMM-CONNECTED mode is specified in 3GPP TS 24.501 [54] clause 4.4.2.4.

4.4.2.3 Establishment of secure exchange of NAS messages

Secure exchange of NAS messages via a NAS signalling connection is usually established by the MME during the attach procedure by initiating a security mode control procedure. After successful completion of the security mode control procedure, all NAS messages exchanged between the UE and the MME are sent integrity protected using the current EPS security algorithms, and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered using the current EPS security algorithms.

During inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, secure exchange of NAS messages is established between the MME and the UE by:

– the transmission of NAS security related parameters encapsulated in the AS signalling from the MME to the UE triggering the inter-system handover (see 3GPP TS 33.401 [19]). The UE uses these parameters to generate the mapped EPS security context; and,

– after the handover, the transmission of a TRACKING AREA UPDATE REQUEST message from the UE to the MME. The UE shall send this message integrity protected using the mapped EPS security context, but unciphered. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected using the mapped EPS security context, and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered using the mapped EPS security context.

During inter-system change from N1 mode to S1 mode in EMM-CONNECTED mode, secure exchange of NAS messages is established between the MME and the UE by:

– the transmission of NAS security related parameters encapsulated in the AS signalling from the AMF to the UE triggering the inter-system handover (see 3GPP TS 33.501 [56]). The UE uses these parameters to generate the mapped EPS security context (see clause 8.6.1 of 3GPP TS 33.501 [56]); and

During inter-system change from N1 mode to S1 mode in EMM-IDLE mode, if the UE is operating in the single-registration mode and:

1) if the tracking area updating procedure is initiated as specified in 3GPP TS 24.501 [54], the UE shall transmit a TRACKING AREA UPDATE REQUEST message integrity protected with the current 5G NAS security context and the UE shall derive a mapped EPS security context (see clause 8.6.1 of 3GPP TS 33.501 [56]). The UE shall set the uplink and downlink NAS COUNT counters to the uplink and downlink NAS COUNT counters of the current 5G NAS security context respectively. The UE shall include the eKSI indicating the 5G NAS security context value in the TRACKING AREA UPDATE REQUEST message.

After receiving the TRACKING AREA UPDATE REQUEST message including the eKSI, the MME forwards the TRACKING AREA UPDATE REQUEST message to the source AMF, if possible, to obtain the mapped EPS security context from the AMF as specified in 3GPP TS 33.501 [56]. The MME shall store the mapped EPS NAS security context with the uplink and downlink NAS COUNT counters associated with the derived K’ASME key set to the uplink and downlink NAS COUNT counters of the mapped EPS NAS security context respectively. The MME re-establishes the secure exchange of NAS messages by either:

– replying with a TRACKING AREA UPDATE ACCEPT message that is integrity protected and ciphered using the mapped EPS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or

– initiating a security mode control procedure. This can be used by the MME to take a non-current EPS security context into use or to modify the current EPS security context by selecting new NAS security algorithms; or

2) if the attach procedure is initiated as specified in 3GPP TS 24.501 [54] and:

a) if the UE has received an "interworking without N26 interface not supported" indication from the network and the UE has a valid 5G NAS security context, the UE shall send an ATTACH REQUEST message integrity protected with the current 5G NAS security context and the UE shall derive a mapped EPS security context (see clause 8.6.1 of 3GPP TS 33.501 [56]). The UE shall set the uplink and downlink NAS COUNT counters to the uplink and downlink NAS COUNT counters of the current 5G NAS security context respectively. The UE shall include the eKSI indicating the 5G NAS security context value in the ATTACH REQUEST message.

After receiving the ATTACH REQUEST message including the eKSI, the MME forwards the ATTACH REQUEST message to the source AMF, if possible, to obtain the mapped EPS security context from the AMF as specified in 3GPP TS 33.501 [56]. The MME shall store the mapped EPS NAS security context with the uplink and downlink NAS COUNT counters associated with the derived K’ASME key set to the uplink and downlink NAS COUNT counters of the mapped EPS NAS security context respectively. The MME re-establishes the secure exchange of NAS messages by either:

– replying with an ATTACH ACCEPT message that is integrity protected and ciphered using the mapped EPS NAS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or

– initiating a security mode control procedure. This can be used by the MME to modify the current EPS security context by selecting new NAS security algorithms; or

b) otherwise:

i) if the UE has a valid native EPS security context, the UE shall send an ATTACH REQUEST message integrity protected with the native EPS security context. The UE shall include the eKSI indicating the native EPS security context value in the ATTACH REQUEST message.

After receiving the ATTACH REQUEST message including the eKSI, the MME shall check whether the eKSI included in the initial NAS message belongs to an EPS security context available in the MME, and shall verify the MAC of the NAS message. If the verification is successful, the MME re-establishes the secure exchange of NAS messages by either:

– replying with an ATTACH ACCEPT message that is integrity protected and ciphered using the current EPS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or

– initiating a security mode control procedure. This can be used by the MME to modify the current EPS security context by selecting new NAS security algorithms; or

ii) if the UE has no valid native EPS security context, the UE shall send an ATTACH REQUEST message without integrity protection and encryption.

The secure exchange of NAS messages shall be continued after S1 mode to S1 mode handover. It is terminated after inter-system handover from S1 mode to A/Gb mode or Iu mode or when the NAS signalling connection is released.

When a UE in EMM-IDLE mode establishes a new NAS signalling connection and has a valid current EPS security context, secure exchange of NAS messages can be re-established in the following ways:

1) Except for the cases described in items 3 and 4 below, the UE shall transmit the initial NAS message integrity protected with the current EPS security context, but unciphered. The UE shall include the eKSI indicating the current EPS security context value in the initial NAS message. The MME shall check whether the eKSI included in the initial NAS message belongs to an EPS security context available in the MME, and shall verify the MAC of the NAS message. If the verification is successful, the MME may re-establish the secure exchange of NAS messages:

– by replying with a NAS message that is integrity protected and ciphered using the current EPS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or

– by initiating a security mode control procedure. This can be used by the MME to take a non-current EPS security context into use or to modify the current EPS security context by selecting new NAS security algorithms; or

2) If the initial NAS message was a SERVICE REQUEST message or EXTENDED SERVICE REQUEST message, secure exchange of NAS messages is triggered by the indication from the lower layers that the user plane radio bearers are successfully set up. After successful completion of the procedure, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in clause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered.

3) If the UE has no current EPS security context and performs a tracking area updating procedure after an inter-system change in idle mode from A/Gb mode to S1 mode or Iu mode to S1 mode, the UE shall send the TRACKING AREA UPDATE REQUEST message without integrity protection and encryption. The UE shall include a nonce and a GPRS ciphering key sequence number for creation of a mapped EPS security context. The MME creates a fresh mapped EPS security context and takes this context into use by initiating a security mode control procedure and this context becomes the current EPS security context in both the UE and the MME. This re-establishes the secure exchange of NAS messages.

4) If the initial NAS message is a CONTROL PLANE SERVICE REQUEST message, the UE shall send the message integrity protected. If an ESM message container information element or a NAS message container information element is included the message shall be sent partially ciphered (see clause 4.4.5), otherwise the message shall be sent unciphered. Secure exchange of NAS messages is re-established in the UE:

– by the indication from the lower layers that the user plane radio bearers are successfully set up;

– upon receipt of a NAS message (e.g. a SERVICE ACCEPT message or ESM DATA TRANSPORT message) that is integrity protected and ciphered using the current EPS security context; or

– upon receipt of a SECURITY MODE COMMAND message that has successfully passed the integrity check.

4.4.2.4 Change of security keys

When the MME initiates a re-authentication to create a new EPS security context, the messages exchanged during the authentication procedure are integrity protected and ciphered using the current EPS security context, if any.

Both UE and MME shall continue to use the current EPS security context, until the MME initiates a security mode control procedure. The SECURITY MODE COMMAND message sent by the MME includes the eKSI of the new EPS security context to be used. The MME shall send the SECURITY MODE COMMAND message integrity protected with the new EPS security context, but unciphered. When the UE responds with a SECURITY MODE COMPLETE, it shall send the message integrity protected and ciphered with the new EPS security context.

The MME can also modify the current EPS security context or take the non-current native EPS security context, if any, into use, by sending a SECURITY MODE COMMAND message including the eKSI of the EPS security context to be modified and including a new set of selected NAS security algorithms. In this case the MME shall send the SECURITY MODE COMMAND message integrity protected with the modified EPS security context, but unciphered. When the UE replies with a SECURITY MODE COMPLETE message, it shall send the message integrity protected and ciphered with the modified EPS security context.

4.4.2.5 Derivation of keys at CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode

At change from A/Gb mode to S1 mode or from Iu mode to S1 mode due to CS to PS SRVCC handover (see 3GPP TS 23.216 [8]), the UE shall derive a mapped EPS security context for the PS domain from the UMTS security context for the CS domain.

At change from A/Gb mode to S1 mode due to CS to PS SRVCC handover, ciphering may be started and integrity protection shall be started (see 3GPP TS 36.331 [22]) without any new authentication procedure.

NOTE 1: CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode is not supported if the current CS security context is a GSM security context.

NOTE 2: For emergency calls, CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode is not supported.

In order to derive a mapped EPS security context for a CS to PS SRVCC handover from A/Gb mode or Iu mode to S1 mode, the MSC creates a NONCE_MSC and generates the CK’_PS and IK’_PS using the CS UMTS integrity key, the CS UMTS ciphering key and the created NONCE_MSC as specified in annex B.6 in 3GPP TS 33.102 [18]. The MSC associates the CK’_PS and IK’_PS with a KSI’_PS. The KSI’_PS is set to the value of the KSI_CS associated with the CS UMTS integrity key and the CS UMTS ciphering key. The MSC transfers the CK’_PS, IK’_PS and the KSI’_PSto the MME. The MME shall create a mapped EPS security context by setting the K’_ASMEto the concatenation of the CK’_PS and IK’_PS received from the MSC (i.e. CK’_PS || IK’_PS). The MME shall associate the K’_ASME with a KSI_SGSN. The MME shall set KSI_SGSN to the value of the KSI’_PS received from the MSC. The MME shall include the selected NAS algorithms, NONCE_MME and generated KSI_SGSN (associated with the K’_ASME) in the NAS security transparent container for the handover to E-UTRAN. The MME shall derive the EPS NAS keys from K’_ASME.

When the UE receives the command to perform CS to PS SRVCC handover to S1 mode, the ME shall generate the CK’_PS and IK’_PS using the CS UMTS integrity key, the CS UMTS ciphering key and the received NONCE_MSC value in the transparent container in the CS to PS SRVCC handover command as specified in annex B.6 in 3GPP TS 33.102 [18]. The ME shall ignore the NONCE_MME value received in the NAS Security Transparent Container in the CS to PS SRVCC handover command.

NOTE 3: The NONCE_MME value received in the NAS Security Transparent Container for the handover to E-UTRAN is not used by the ME or MME in any key derivation in this handover.

The ME shall create the key K’_ASME by concatenating the derived CK’_PS and IK’_PS (i.e. CK’_PS || IK’_PS.). The ME shall associate the derived key K’_ASME with a KSI_SGSN. The ME shall set the KSI_SGSN associated to K’_ASME to the KSI_SGSN value received in the NAS Security Transparent Container from the network.

NOTE 4: Although this case is related to the MSC server enhanced for SRVCC, the name KSI_SGSN is kept to avoid introducing a new name for the same domain.

The ME shall derive the EPS NAS keys (CK’ and IK’) from the K’_ASME as specified in 3GPP TS 33.401 [19]. The ME shall apply these derived EPS NAS security keys (CK’ and IK’), reset the uplink and downlink NAS COUNT values for the mapped EPS security context (i.e. to the value 0), and replace an already established mapped EPS security context for the PS domain, if any, in the ME, when the CS to PS SRVCC handover from A/Gb mode or Iu mode has been completed successfully. If the already established current EPS security context is of type native, then it shall become the non-current native EPS security context and overwrite any existing non-current native EPS security context in the ME.

The network shall replace an already established mapped EPS security context for the PS domain, if any, when the CS to PS SRVCC handover from A/Gb mode or Iu mode has been completed successfully. If the already established current EPS security context is of type native, then it shall become the non-current native EPS security context and overwrite any existing non-current native EPS security context in the MME.

If the CS to PS SRVCC handover from A/Gb mode or Iu mode has not been completed successfully, the UE and the network shall delete the new derived mapped EPS security context for the PS domain. Additionally, the network shall delete an already established mapped EPS security context for the PS domain, if any, if the eKSI of the already established EPS security context is equal to the KSI_SGSN of the new derived EPS security context for the PS domain.

4.4.3 Handling of NAS COUNT and NAS sequence number

4.4.3.1 General

Each EPS security context shall be associated with two separate counters NAS COUNT: one related to uplink NAS messages and one related to downlink NAS messages. The NAS COUNT counters use 24 bit internal representation and are independently maintained by UE and MME. The NAS COUNT shall be constructed as a NAS sequence number (8 least significant bits) concatenated with a NAS overflow counter (16 most significant bits).

When NAS COUNT is input to NAS ciphering or NAS integrity algorithms it shall be considered to be a 32-bit entity which shall be constructed by padding the 24-bit internal representation with 8 zeros in the most significant bits.

The value of the uplink NAS COUNT that is stored or read out of the USIM or non-volatile memory as described in annex C, is the value that shall be used in the next NAS message.

The value of the downlink NAS COUNT that is stored or read out of the USIM or non-volatile memory as described in annex C, is the largest downlink NAS COUNT used in a successfully integrity checked NAS message.

The value of the uplink NAS COUNT stored in the MME is the largest uplink NAS COUNT used in a successfully integrity checked NAS message.

The value of the downlink NAS COUNT stored in the MME is the value that shall be used in the next NAS message.

The NAS sequence number part of the NAS COUNT shall be exchanged between the UE and the MME as part of the NAS signalling. After each new or retransmitted outbound security protected NAS message, the sender shall increase the NAS COUNT number by one, except for the initial NAS messages if the lower layers indicated the failure to establish the RRC connection (see 3GPP TS 36.331 [22]). Specifically, on the sender side, the NAS sequence number shall be increased by one, and if the result is zero (due to wrap around), the NAS overflow counter shall also be incremented by one (see clause 4.4.3.5). The receiving side shall estimate the NAS COUNT used by the sending side. Specifically, if the estimated NAS sequence number wraps around, the NAS overflow counter shall be incremented by one.

NOTE 0: When estimating a NAS COUNT, the receiver is required to ensure that a given NAS COUNT value is accepted at most one time, as specified in clause 4.4.3.2.

After the derivation of a NAS token due to an inter-system change from S1mode to A/Gb mode or Iu mode in idle mode as specified in 3GPP TS 24.008 [13], the UE shall increase the uplink NAS COUNT by one.

When the MME receives a NAS token via SGSN during an idle mode inter-system change from S1 mode to A/Gb mode or Iu mode, the MME shall check the NAS token as specified in 3GPP TS 33.401 [19], clause 9.1.1, and update its uplink NAS COUNT with the uplink NAS COUNT value used for the successful check of the NAS token.

NOTE 1: The MME does not check the NAS token if it is received via SGSN during a connected mode inter-system change from S1 mode to A/Gb mode or Iu mode.

During the handover from UTRAN/GERAN to E-UTRAN, when a mapped EPS security context is derived and taken into use, the MME shall set both the uplink and downlink NAS COUNT counters of this EPS security context to zero. The UE shall set both the uplink and downlink NAS COUNT counters to zero.

When a mapped EPS security context is derived as specified in 3GPP TS 33.501 [56] and taken into use in the following cases:

– during the inter-system change from N1 mode to S1 mode in 5GMM-CONNECTED mode; or

– during the inter-system change from N1 mode to S1 mode in EMM-IDLE mode for the UE operating in single-registration mode in a network supporting N26 interface,

the MME shall store the mapped EPS NAS security context with the uplink and downlink NAS COUNT counters associated with the derived K’_ASME key set to the uplink and downlink NAS COUNT counters of the mapped EPS NAS security context respectively. The UE shall set the uplink and downlink NAS COUNT counters to the uplink and downlink NAS COUNT counters of the current 5G NAS security context respectively.

During the handover from E-UTRAN to UTRAN/GERAN the MME signals the current downlink NAS COUNT value in a NAS security transparent container (see clause 9.9.2.6).

During handover to or from E-UTRAN, the MME shall increment downlink NAS COUNT by one after it has created a NAS security transparent container (see clause 9.9.2.6 and 9.9.2.7).

NOTE 2: During the handover from UTRAN/GERAN to E-UTRAN, the NAS security transparent container (see clause 9.9.2.7) is treated as an implicit SECURITY MODE COMMAND message for the UE and the MME, and therefore the MME regards the sending of the NAS security transparent container as the sending of an initial SECURITY MODE COMMAND message in order to derive and take into use a mapped EPS security context for the purpose of the NAS COUNT handling.

In some NAS messages only 5 of the 8 NAS sequence number bits are transmitted. When this is the case, the receiver shall estimate the remaining 3 most significant bits of the sequence number.

4.4.3.2 Replay protection

Replay protection shall be supported for received NAS messages both in the MME and the UE. However, since the realization of replay protection does not affect the interoperability between nodes, no specific mechanism is required for implementation.

Replay protection must assure that one and the same NAS message is not accepted twice by the receiver. Specifically, for a given EPS security context, a given NAS COUNT value shall be accepted at most one time and only if message integrity verifies correctly.

Replay protection is not applicable when EIA0 is used.

4.4.3.3 Integrity protection and verification

The sender shall use its locally stored NAS COUNT as input to the integrity protection algorithm.

The receiver shall use the NAS sequence number included in the received message (or estimated from the 5 bits of the NAS sequence number received in the message) and an estimate for the NAS overflow counter as defined in clause 4.4.3.1 to form the NAS COUNT input to the integrity verification algorithm.

The algorithm to calculate the integrity protection information is specified in 3GPP TS 33.401 [19], and the integrity protection shall include octet 6 to n of the security protected NAS message, i.e. the sequence number IE and the NAS message IE. The integrity protection of the SERVICE REQUEST message is defined in clause 9.9.3.28. In addition to the data that is to be integrity protected, the constant BEARER ID, DIRECTION bit, NAS COUNT and NAS integrity key are input to the integrity protection algorithm. These parameters are described in 3GPP TS 33.401 [19].

After successful integrity protection validation, the receiver shall update its corresponding locally stored NAS COUNT with the value of the estimated NAS COUNT for this NAS message.

Integrity verification is not applicable when EIA0 is used.

4.4.3.4 Ciphering and deciphering

The sender shall use its locally stored NAS COUNT as input to the ciphering algorithm.

The input parameters to the NAS ciphering algorithm are the constant BEARER ID, DIRECTION bit, NAS COUNT, NAS encryption key and the length of the key stream to be generated by the encryption algorithm. When an initial plain NAS message for transport of user data via control plane (i.e. CONTROL PLANE SERVICE REQUEST message) is to be partially ciphered, the length of the key stream is set to the length of the part of the initial plain NAS message (i.e. the value part of the ESM message container IE or the value part of the NAS message container) that is to be ciphered.

4.4.3.5 NAS COUNT wrap around

If, when increasing the NAS COUNT as specified above, the MME detects that either its downlink NAS COUNT or the UE’s uplink NAS COUNT is "close" to wrap around, (close to 2²⁴), the MME shall take the following actions:

– If there is no non-current native EPS security context with sufficiently low NAS COUNT values, the MME shall initiate a new AKA procedure with the UE, leading to a new established EPS security context and the NAS COUNT being reset to 0 in both the UE and the MME when the new EPS security context is activated;

– Otherwise, the MME can activate a non-current native EPS security context with sufficiently low NAS COUNT values or initiate a new AKA procedure as specified above.

If for some reason a new K_ASME has not been established using AKA before the NAS COUNT wraps around, the node (MME or UE) in need of sending a NAS message shall instead release the NAS signalling connection. Prior to sending the next uplink NAS message, the UE shall delete the eKSI indicating the current EPS security context.

When the EIA0 is used as the NAS integrity algorithm, the UE and the MME shall allow NAS COUNT wrap around. If NAS COUNT wrap around occurs, the following requirements apply:

– the UE and the MME shall continue to use the current security context;

– the MME shall not initiate the EPS AKA procedure;

– the MME shall not release the NAS signalling connection; and

– the UE shall not perform a local release of the NAS signalling connection.

4.4.4 Integrity protection of NAS signalling messages

4.4.4.1 General

For the UE, integrity protected signalling is mandatory for the NAS messages once a valid EPS security context exists and has been taken into use. For the network, integrity protected signalling is mandatory for the NAS messages once a secure exchange of NAS messages has been established for the NAS signalling connection. Integrity protection of all NAS signalling messages is the responsibility of the NAS. It is the network which activates integrity protection.

The use of "null integrity protection algorithm" EIA0 (see clause 9.9.3.23) in the current security context is only allowed for an unauthenticated UE for which establishment of emergency bearer services or access to RLOS is allowed. For setting the security header type in outbound NAS messages, the UE and the MME shall apply the same rules irrespective of whether the "null integrity protection algorithm" or any other integrity protection algorithm is indicated in the security context.

If the "null integrity protection algorithm" EIA0 has been selected as an integrity protection algorithm, the receiver shall regard the NAS messages with the security header indicating integrity protection as integrity protected.

Details of the integrity protection and verification of NAS signalling messages are specified in 3GPP TS 33.401 [19].

When a NAS message needs to be sent both ciphered and integrity protected, the NAS message is first ciphered and then the ciphered NAS message and the NAS sequence number are integrity protected by calculating the MAC. The same applies when an initial NAS message needs to be sent partially ciphered and integrity protected.

NOTE: NAS messages that are ciphered or partially ciphered with the "null ciphering algorithm" EEA0 are regarded as ciphered or partially ciphered, respectively (see clause 4.4.5).

When a NAS message needs to be sent only integrity protected and unciphered, the unciphered NAS message and the NAS sequence number are integrity protected by calculating the MAC.

When during the EPS attach procedure or service request procedure an ESM message is piggybacked in an EMM message, there is only one sequence number IE and one message authentication code IE, if any, for the combined NAS message.

4.4.4.2 Integrity checking of NAS signalling messages in the UE

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the UE or forwarded to the ESM entity, unless the network has established secure exchange of NAS messages for the NAS signalling connection:

– EMM messages:

– IDENTITY REQUEST (if requested identification parameter is IMSI);

– AUTHENTICATION REQUEST;

– AUTHENTICATION REJECT;

– ATTACH REJECT (if the EMM cause is not #25);

– DETACH ACCEPT (for non switch off);

– TRACKING AREA UPDATE REJECT (if the EMM cause is not #25);

– SERVICE REJECT (if the EMM cause is not #25).

NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.

All ESM messages are integrity protected.

Once the secure exchange of NAS messages has been established, the receiving EMM or ESM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. The processing of the SECURITY MODE COMMAND message that has not successfully passed the integrity check is specified in clause 5.4.3.5. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.

4.4.4.3 Integrity checking of NAS signalling messages in the MME

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the MME or forwarded to the ESM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:

– EMM messages:

– ATTACH REQUEST;

– IDENTITY RESPONSE (if requested identification parameter is IMSI);

– AUTHENTICATION RESPONSE;

– AUTHENTICATION FAILURE;

– SECURITY MODE REJECT;

– DETACH REQUEST;

– DETACH ACCEPT;

– TRACKING AREA UPDATE REQUEST.

NOTE 1: The TRACKING AREA UPDATE REQUEST message is sent by the UE without integrity protection, if the tracking area updating procedure is initiated due to an inter-system change in idle mode and no current EPS security context is available in the UE. The other messages are accepted by the MME without integrity protection, as in certain situations they are sent by the UE before security can be activated.

NOTE 2: The DETACH REQUEST message can be sent by the UE without integrity protection, e.g. if the UE is attached for emergency bearer services or access to RLOS and there is no shared EPS security context available, or if due to user interaction an attach procedure is cancelled before the secure exchange of NAS messages has been established. For these cases the network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic tracking area updating or still responding to paging) before marking the UE as EMM-DEREGISTERED.

All ESM messages are integrity protected except a PDN CONNECTIVITY REQUEST message if it is sent piggybacked in ATTACH REQUEST message and NAS security is not activated.

Once a current EPS security context exists, until the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving EMM entity in the MME shall process the following NAS signalling messages, even if the MAC included in the message fails the integrity check or cannot be verified, as the EPS security context is not available in the network:

– ATTACH REQUEST;

– IDENTITY RESPONSE (if requested identification parameter is IMSI);

– AUTHENTICATION RESPONSE;

– AUTHENTICATION FAILURE;

– SECURITY MODE REJECT;

– DETACH REQUEST;

– DETACH ACCEPT;

– TRACKING AREA UPDATE REQUEST;

– SERVICE REQUEST;

– EXTENDED SERVICE REQUEST;

– CONTROL PLANE SERVICE REQUEST.

NOTE 3: These messages are processed by the MME even when the MAC that fails the integrity check or cannot be verified, as in certain situations they can be sent by the UE protected with an EPS security context that is no longer available in the network.

If an ATTACH REQUEST message is received without integrity protection or fails the integrity check and it is not an attach request for emergency bearer services and it is not an attach request for access to RLOS, the MME shall authenticate the subscriber before processing the attach request any further. Additionally, if the MME initiates a security mode control procedure, the MME shall include a HASH_MME IE in the SECURITY MODE COMMAND message as specified in clause 5.4.3.2. If authentication procedure is not successful the MME shall maintain, if any, the EMM-context and EPS security context unchanged. For the case when the attach procedure is for emergency bearer services see clause 5.5.1.2.3 and clause 5.4.2.5.

If a DETACH REQUEST message fails the integrity check, the MME shall proceed as follows:

– If it is not a detach request due to switch off, and the MME can initiate an authentication procedure, the MME should authenticate the subscriber before processing the detach request any further.

– If it is a detach request due to switch off, or the MME does not initiate an authentication procedure for any other reason, the MME may ignore the detach request and remain in state EMM-REGISTERED.

NOTE 4: The network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic tracking area updating or still responding to paging) before marking the UE as EMM-DEREGISTERED.

If a TRACKING AREA UPDATE REQUEST message is received without integrity protection or fails the integrity check and the UE provided a nonce_UE, GPRS ciphering key sequence number, P-TMSI and RAI in the TRACKING AREA UPDATE REQUEST message, the MME shall initiate a security mode control procedure to take a new mapped EPS security context into use; otherwise, if the UE has only a PDN connection for non-emergency bearer services established and the PDN connection is not for RLOS, the MME shall initiate an authentication procedure. Additionally, if the MME initiates a security mode control procedure, the MME shall include a HASH_MME IE in the SECURITY MODE COMMAND message as specified in clause 5.4.3.2. If authentication procedure is not successful the MME shall maintain, if any, the EMM-context and EPS security context unchanged. For the case when the UE has a PDN connection for emergency bearer services or for RLOS see clause 5.5.3.2.3 and clause 5.4.2.5.

If a SERVICE REQUEST, EXTENDED SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message fails the integrity check and the UE has only PDN connections for non-emergency bearer services established and the PDN connections are not for RLOS, the MME shall send the SERVICE REJECT message with EMM cause #9 "UE identity cannot be derived by the network" and keep the EMM-context and EPS security context unchanged. For the case when the UE has a PDN connection for emergency bearer services or RLOS and integrity check fails, the MME may 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 clause 5.4.3. After successful completion of the service request procedure, the network shall deactivate all non-emergency EPS bearers locally which are not EPS bearers for RLOS. The emergency EPS bearers shall not be deactivated. The network may deactivate the EPS bearers for RLOS.

Once the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving EMM or ESM entity in the MME shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If any NAS signalling message, having not successfully passed the integrity check, is received, then the NAS in the MME shall discard that message. If any NAS signalling message is received, as not integrity protected even though the secure exchange of NAS messages has been established, then the NAS shall discard this message.

4.4.5 Ciphering of NAS signalling messages

The use of ciphering in a network is an operator option subject to MME configuration. When operation of the network without ciphering is configured, the MME shall indicate the use of "null ciphering algorithm" EEA0 (see clause 9.9.3.23) in the current security context for all UEs. For setting the security header type in outbound NAS messages, the UE and the MME shall apply the same rules irrespective of whether the "null ciphering algorithm" or any other ciphering algorithm is indicated in the security context.

When the UE establishes a new NAS signalling connection, it shall send the initial NAS message

– partially ciphered, if it is a CONTROL PLANE SERVICE REQUEST message including an ESM message container information element or a NAS message container information element; and

– unciphered, if it is any other initial NAS message.

The UE shall partially cipher the CONTROL PLANE SERVICE REQUEST message by ciphering the value part of the ESM message container IE or the value part of the NAS message container, using the ciphering algorithm of the current EPS security context.

The UE shall send the ATTACH REQUEST message always unciphered.

The UE shall send the TRACKING AREA UPDATE REQUEST message always unciphered.

Except for the CONTROL PLANE SERVICE REQUEST message including an ESM message container information element or a NAS message container information element, the UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has been established for a NAS signalling connection. From this time onward, unless explicitly defined, the UE shall send all NAS messages ciphered until the NAS signalling connection is released, or the UE performs intersystem handover to A/Gb mode or Iu mode.

The MME shall start ciphering and deciphering of NAS messages as described in clause 4.4.2.3. From this time onward, except for the SECURITY MODE COMMAND message, the MME shall send all NAS messages ciphered until the NAS signalling connection is released, or the UE performs intersystem handover to A/Gb mode or Iu mode.

Once the encryption of NAS messages has been started between the MME and the UE, the receiver shall discard the unciphered NAS messages which shall have been ciphered according to the rules described in this specification. The MME shall discard any CONTROL PLANE SERVICE REQUEST message including an ESM message container information element or a NAS message container information element which has not been partially ciphered according to the rules described above.

If the "null ciphering algorithm" EEA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered.

Details of ciphering and deciphering of NAS signalling messages are specified in 3GPP TS 33.401 [19].

4.5 Disabling and re-enabling of UE’s E-UTRA capability

The UE shall only disable the E-UTRA capability when in EMM-IDLE mode.

When the UE supports both N1 mode and S1 mode then the UE’s capability to access the 5GCN via E-UTRA shall not be affected, if the UE’s E-UTRA capability is disabled or enabled.

When the UE is disabling the E-UTRA capability not due to redirection to 5GCN required, it should proceed as follows:

a) select another RAT (GERAN, UTRAN, or NG-RAN if the UE has not disabled its N1 mode capability for 3GPP access as specified in 3GPP TS 24.501 [54]) of the registered PLMN or a PLMN from the list of equivalent PLMNs;

b) if another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, or the UE does not have a registered PLMN, then perform PLMN selection as specified in 3GPP TS 23.122 [6]. As an implementation option, instead of performing PLMN selection, the UE may select another RAT of the chosen PLMN. If disabling of E-UTRA capability was not due to UE initiated detach procedure for EPS services only, the UE may re-enable the E-UTRA capability for this PLMN selection; or

c) if no other allowed PLMN and RAT combinations are available, then the UE may re-enable the E-UTRA capability and remain registered for EPS services in E-UTRAN of the registered PLMN. If the UE chooses this option, then it may periodically attempt to select another PLMN and RAT combination that can provide non-EPS services. How this periodic scanning is done, is UE implementation dependent.

When the UE is disabling the E-UTRA capability upon receiving reject cause #31 "Redirection to 5GCN required" as specified in clauses 5.5.1.2.5, 5.5.1.3.5, 5.5.3.2.5, 5.5.3.3.5 and 5.6.1.5, it should proceed as follows:

i) If the UE is in NB-S1 mode:

1) if lower layers do not provide an indication that the current E-UTRA cell is connected to 5GCN or lower layers do not provide an indication that the current E-UTRA cell supports CIoT 5GS optimizations that are supported by the UE, search for a suitable NB-IoT cell connected to 5GCN according to 3GPP TS 36.304 [21];

2) if lower layers provide an indication that the current E-UTRA cell is connected to 5GCN and the current E-UTRA cell supports CIoT 5GS optimizations that are supported by the UE then perform a core network selection to select 5GCN as specified in 3GPP TS 24.501 [54] clause 4.8.4A.1; or

3) if lower layers cannot find a suitable NB-IoT cell connected to 5GCN or there is no suitable NB-IoT cell connected to 5GCN which supports CIoT 5GS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to EPC, may then start an implementation-specific timer and enter the state EMM-REGISTERED.LIMITED-SERVICE the UE may re-enable the E-UTRA capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then, proceed with the appropriate EMM procedure.

ii) If the UE is in WB-S1 mode:

1) if lower layers do not provide an indication that the current E-UTRA cell is connected to 5GCN or lower layers do not provide an indication that the current E-UTRA cell supports CIoT 5GS optimizations that are supported by the UE, search for a suitable E-UTRA cell connected to 5GCN according to 3GPP TS 36.304 [21];

2) if lower layers provide an indication that the current E-UTRA cell is connected to 5GCN and the current E-UTRA cell supports CIoT 5GS optimizations that are supported by the UE, then perform a core network selection to select 5GCN as specified in 3GPP TS 24.501 [54] clause 4.8.4A.1; or

3) if lower layers cannot find a suitable E-UTRA cell connected to 5GCN or there is no suitable E-UTRA cell connected to 5GCN which supports CIoT 5GS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to EPC, may then start an implementation-specific timer and enter the state EMM-REGISTERED.LIMITED-SERVICE the UE may re-enable the E-UTRA capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then, proceed with the appropriate EMM procedure.

The UE shall re-enable the E-UTRA capability when performing a PLMN selection unless:

– the disabling of E-UTRA capability was due to UE initiated detach procedure for EPS services only; or

– the UE has already re-enabled the E-UTRA capability when performing bullets b) or c) above.

If due to handover, the UE moves to a new PLMN in A/Gb, Iu, or N1 mode which is not in the list of equivalent PLMNs and not a PLMN memorized by the UE for which E-UTRA capability was disabled, and the disabling of E-UTRA capability was not due to UE initiated detach procedure for EPS services only, the UE shall re-enable the E-UTRA capability after the RR/RRC connection is released.

If UE that has disabled its E-UTRA capability due to IMS voice not available and CS fallback not available re-enables it when PLMN selection is performed, then it should memorize the identity of the PLMNs where E-UTRA capability was disabled and use that stored information in subsequent PLMN selections as specified in 3GPP TS 23.122 [6].

The UE may support "E-UTRA Disabling for EMM cause #15" and implement the following behaviour:

– if the "E-UTRA Disabling Allowed for EMM cause #15" parameter as specified in 3GPP TS 24.368 [15A] or 3GPP TS 31.102 [17] is present and set to enabled; and

– if the UE receives an ATTACH REJECT or TRACKING AREA UPDATE REJECT message including both EMM cause #15 "no suitable cells in tracking area" and an Extended EMM cause IE with value "E-UTRAN not allowed";

then the UE shall disable the E-UTRA capability, memorize the identity of the PLMN where the E-UTRA capability was disabled and use that stored information in subsequent PLMN selections as specified in 3GPP TS 23.122 [6].

When the UE supporting the A/Gb and/or Iu mode together with the S1 mode needs to stay in A/Gb or Iu mode, in order to prevent unwanted handover or cell reselection from UTRAN/GERAN to E-UTRAN, the UE shall disable the E-UTRA capability and:

– The UE shall not set the E-UTRA support bits of the MS Radio Access capability IE (see 3GPP TS 24.008 [13], clause 10.5.5.12a), the E-UTRA support bits of Mobile Station Classmark 3 IE (see 3GPP TS 24.008 [13], clause 10.5.1.7), the PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability bit and the ISR support bit of the MS network capability IE (see 3GPP TS 24.008 [13], clause 10.5.5.12) in the ATTACH REQUEST message and the ROUTING AREA UPDATE REQUEST message after it selects GERAN or UTRAN;

– the UE shall use the same value of the EPC capability bit of the MS network capability IE (see 3GPP TS 24.008 [13], clause 10.5.5.12) in the ATTACH REQUEST message and the ROUTING AREA UPDATE REQUEST message; and

– the UE NAS layer shall indicate the access stratum layer(s) of disabling of the E-UTRA capability.

When the UE supporting N1 mode together with S1 mode needs to stay in N1 mode, in order to prevent unwanted handover or cell reselection from NG-RAN to E-UTRAN, the UE shall disable the E-UTRA capability and:

– the UE shall set the S1 mode bit to "S1 mode not supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message (see 3GPP TS 24.501 [54]);

– the UE shall not include the S1 UE network capability IE in the REGISTRATION REQUEST message (see 3GPP TS 24.501 [54]); and

– the UE NAS layer shall indicate the access stratum layer(s) of disabling of the E-UTRA capability.

If the UE is disabling its E-UTRA capability before selecting to GERAN, UTRAN or NG-RAN radio access technology, the UE shall not perform the detach procedure of clause 5.5.2.1.

If the UE is required to disable the E-UTRA capability and select GERAN, UTRAN or NG-RAN radio access technology, and the UE is in the EMM-CONNECTED mode:

– if the UE has a persistent EPS bearer context and the ongoing procedure is not a detach procedure, then the UE shall wait until the radio bearer associated with the persistent EPS bearer context has been released;

– otherwise, the UE shall locally release the established NAS signalling connection and enter the EMM-IDLE mode before selecting GERAN, UTRAN or NG-RAN radio access technology.

If the E-UTRA capability was disabled due to the attempt to select GERAN or UTRAN radio access technology progressing the CS emergency call establishment (see clause 4.3.1), the criteria to enable the E-UTRA capability again is UE implementation specific.

If the E-UTRA capability was disabled due to the UE initiated detach procedure for EPS services only (see clause 5.5.2.2.2), upon request of the upper layers to re-attach for EPS services the UE shall enable the E-UTRA capability again. If the E-UTRA capability was disabled due to receipt of EMM cause #14 "EPS services not allowed in this PLMN", then the UE shall enable the E-UTRA capability when the UE powers off and powers on again or the USIM is removed. If E-UTRA capability was disabled for any other reason, the UE shall enable the E-UTRA capability in the following cases:

– the UE mode of operation changes from CS/PS mode 1 of operation to CS/PS mode 2 of operation;

– the UE mode of operation changes from PS mode 1 of operation to PS mode 2 of operation; or

– the UE powers off and powers on again or the USIM is removed;

As an implementation option, the UE may start a timer for enabling E-UTRA when the UE’s attach attempt counter or tracking area updating attempt counter reaches 5 and the UE disables E-UTRA capability for cases described in clauses 5.5.1.2.6, 5.5.1.3.4.3, 5.5.1.3.6, 5.5.3.2.6, 5.5.3.3.4.3 and 5.5.3.3.6. The UE should memorize the identity of the PLMNs where E-UTRA capability were disabled. On expiry of this timer:

– if the UE is in Iu mode or A/Gb mode and is in idle mode as specified in 3GPP TS 24.008 [13] on expiry of the timer, the UE should enable the E-UTRA capability;

– if the UE is in Iu mode or A/Gb mode and an RR connection exists, the UE shall delay enabling E-UTRA capability until the RR connection is released;

– if the UE is in Iu mode and a PS signalling connection exists but no RR connection exists, the UE may abort the PS signalling connection before enabling E-UTRA capability;

– if the UE is in N1 mode and is in 5GMM-IDLE mode as specified in 3GPP TS 24.501 [54], on expiry of the timer, the UE should enable the E-UTRA capability; and

– if the UE is in N1 mode and is in 5GMM-CONNECTED mode as specified in 3GPP TS 24.501 [54], on expiry of the timer, the UE shall delay enabling the E-UTRA capability until the N1 NAS signalling connection is released.

If the UE attempts to establish an emergency bearer service or to access RLOS in a PLMN where the E-UTRA capability was disabled due to the UE’s attach attempt counter or tracking area updating attempt counter have reached 5, the UE may enable the E-UTRA capability for that PLMN memorized by the UE.

The UE may support being configured for No E-UTRA Disabling In 5GS (see 3GPP TS 24.368 [50] or 3GPP TS 31.102 [17]). If the UE supports being configured for No E-UTRA Disabling in 5GS, No E-UTRA Disabling In 5GS is enabled if the corresponding configuration parameter is present and set to enabled. Otherwise, No E-UTRA Disabling In 5GS is disabled. If No E-UTRA Disabling In 5GS is enabled at the UE and the UE selects an NG-RAN cell in a PLMN where the E-UTRA capability was disabled due to the UE’s attach attempt counter or tracking area updating attempt counter having reached 5, the UE shall enable the E-UTRA capability for that PLMN.

For other cases, it is up to the UE implementation when to enable the E-UTRA capability.

NOTE: If the UE is not operating in CS/PS mode 1 operation, the value of the timer for enabling E-UTRA capability is recommended to be not larger than the default value of T3402.

4.6 Applicability of procedures

4.6.1 Relay nodes

A relay node shall support all procedures that are mandatory for a UE supporting S1 mode only.

There is also functionality which is only applicable to a relay node, in which case the specification uses the term "relay node" instead of "UE".

4.7 EPS mobility management and EPS session management in NB-S1 mode

A UE in NB-S1 mode (see 3GPP TS 36.331 [22]) shall calculate the value of the applicable NAS timer:

– indicated in table 10.2.1 plus 240s; and

– indicated in table 10.3.1 plus 180s.

The timer value obtained is used as described in the appropriate procedure clause of this specification. The NAS timer value shall be calculated at start of a NAS procedure and shall not re-calculate the use of the NAS timer value until the NAS procedure is completed, restarted or aborted.

When an MME that supports NB-S1 mode performs NAS signalling with a UE, which is using NB-S1 mode, the MME shall calculate the value of the applicable NAS timer:

– indicated in table 10.2.2 plus 240s; and

– indicated in table 10.3.2 plus 180s.

NOTE 1: If the tracking area updating procedure is initiated in EMM-CONNECTED mode, the MME can stop any running implementation specific supervision timer if it is started when sending an ESM DATA TRANSPORT message to the UE.

NOTE 2: As NB-S1 mode includes the case when satellite access is used in EPS, the values for applicable NAS timers specified in this clause apply also for satellite access.

4.8 EPS mobility management and EPS session management in WB-S1 mode for IoT

4.8.1 UE not using satellite E-UTRAN access

In WB-S1 mode, a UE operating in category CE can operate in either CE mode A or CE mode B (see 3GPP TS 36.306 [44]). If a UE that supports CE mode B and operates in WB-S1 mode not using satellite E-UTRAN access, the UE’s usage setting is not set to "voice centric" (see 3GPP TS 23.401 [10]), and

a) the use of enhanced coverage is not restricted for the UE; or

b) CE mode B is not restricted for the UE (see 3GPP TS 23.401 [10]);

the UE shall apply the value of the applicable NAS timer indicated in tables 10.2.1 and indicated in table 10.3.1 for WB-S1/CE mode.

A UE that supports CE mode B and operates in WB-S1 mode not using satellite E-UTRAN access shall not apply the value of the applicable NAS timer indicated in table 10.2.1 and table 10.3.1 for WB-S1/CE mode before receiving an indication from the network that the use of enhanced coverage is not restricted as described in this clause.

The NAS timer value obtained is used as described in the appropriate procedure clause of this specification. The NAS timer value shall be calculated at start of a NAS procedure, and shall not be re-calculated until the NAS procedure is completed, restarted or aborted.

The support of CE mode B by a UE is indicated to the MME by lower layers and shall be stored by the MME. When an MME that supports WB-S1 mode performs NAS signalling with a UE not using satellite E-UTRAN access, which supports CE mode B and operates in WB-S1 mode and the MME determines that

a) the use of enhanced coverage is not restricted for the UE; or

b) CE mode B is not restricted for the UE (see 3GPP TS 23.401 [10])

the MME shall calculate the value of the applicable NAS timer indicated in tables 10.2.2 and indicated in table 10.3.2 for WB-S1/CE mode.

The NAS timer value obtained is used as described in the appropriate procedure clause of this specification. The NAS timer value shall be calculated at start of a NAS procedure and shall not be re-calculated until the NAS procedure is completed, restarted or aborted.

4.8.2 UE using satellite E-UTRAN access

In WB-S1 mode via satellite E-UTRAN access, the UE shall apply the value of the applicable NAS timer indicated in tables 10.2.1 and indicated in table 10.3.1 for WB-S1/CE mode.

NOTE 1: The applied NAS timer values are based on the current satellite E-UTRAN RAT type determined based on information from lower layers.

When an MME that supports WB-S1 mode performs NAS signalling with a UE via satellite E-UTRAN access, the MME shall calculate the value of the applicable NAS timer indicated in tables 10.2.2 and indicated in table 10.3.2 for WB-S1/CE mode.

NOTE 2: The applied NAS timer values are based on the current satellite E-UTRAN RAT type determined based on information from lower layers.

NOTE 3: When using satellite E-UTRAN access, the restriction on use of enhanced coverage indication from the network is not considered when applicable NAS timers are determined.

4.9 Disabling and re-enabling of UE’s NB-IoT capability

If the UE supports disabling and re-enabling of UE’s NB-IoT capability and the UE in NB-S1 mode is disabling the NB-IoT capability, it should proceed as follows:

a) select E-UTRAN of the registered PLMN or a PLMN from the list of equivalent PLMNs;

b) if E-UTRAN of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, select another RAT (GERAN, UTRAN, or NG-RAN if the UE has not disabled its N1 mode capability for 3GPP access as specified in 3GPP TS 24.501 [54]) of the registered PLMN or a PLMN from the list of equivalent PLMNs;

c) if another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, or the UE does not have a registered PLMN, then perform PLMN selection as specified in 3GPP TS 23.122 [6]. As an implementation option, instead of performing PLMN selection, the UE may select another RAT of the chosen PLMN; or

d) if no other allowed PLMN and RAT combinations are available, then the UE may re-enable the NB-IoT capability and remain registered for EPS services in NB-IoT of the registered PLMN. If the UE chooses this option, then it may periodically attempt to select another PLMN and RAT combination that can provide non-EPS services. How this periodic scanning is done, is UE implementation dependent.

If the NB-IoT capability is disabled, the UE shall re-enable the NB-IoT capability when:

– performing a PLMN selection unless the UE has already re-enabled the NB-IoT capability when performing bullets c) or d) above; or

– the UE powers off and powers on again or the USIM is removed.

If the UE in NB-S1 mode receives an ATTACH REJECT or TRACKING AREA UPDATE REJECT message including both EMM cause #15 "no suitable cells in tracking area" and an Extended EMM cause IE with value "NB-IoT not allowed" after the UE requests access to the NB-IoT, in order to prevent unwanted cell reselection from GERAN, UTRAN, E-UTRAN or NG-RAN to NB-IoT, the UE may:

– disable the NB-IoT capability:

– indicate the access stratum layer(s) of disabling of the NB-IoT capability; and

– memorize the identity of the PLMN where the NB-IoT capability was disabled and use that stored information in subsequent PLMN selections as specified in 3GPP TS 23.122 [6].

NOTE: The UE can only disable the NB-IoT capability when in EMM-IDLE mode.

If the UE in NB-S1 mode is required to disable the NB-IoT capability and select E-UTRAN radio access technology, and the UE is in the EMM-CONNECTED mode, the UE shall locally release the established NAS signalling connection and enter the EMM-IDLE mode before selecting E-UTRAN radio access technology.

As an implementation option, the UE may start a timer for enabling the NB-IoT capability. On expiry of this timer, the UE may enable the NB-IoT capability.

4.10 Support of MUSIM features

A network and a MUSIM UE may support one or more of the MUSIM features (i.e. the NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control).

If MUSIM UE supports one or more MUSIM features, the UE indicates support of one or more MUSIM features during the attach procedure and the normal tracking area updating procedure. If the UE has indicated support of the NAS signalling connection release or the reject paging request or both and the UE supports the paging restriction, the UE indicates support of the paging restriction.

If the UE indicates support of one or more MUSIM features and the network decides to accept one or more MUSIM features, the network indicates the support of one or more MUSIM features during the attach procedure and the normal tracking area updating procedure. The network only indicates the support of the paging restriction together with the support of either NAS signalling connection release or the reject paging request.

The network does not indicate support for any MUSIM feature to the UE during the attach for emergency bearer services.

If a UE stops fulfilling the condition to be considered a MUSIM UE as defined in subclause 3.1, and the UE has negotiated support of one or more MUSIM features, then the UE shall initiate a normal tracking area update procedure to indicate that all the MUSIM features are not supported as specified in clause 5.5.3.2.

A MUSIM UE operating in NB-S1 mode or in WB-S1 mode CE mode B does not indicate the support for paging indication for voice services during the attach procedure or the normal tracking area update procedure towards the network.

4.11 Satellite access for CIoT

4.11.1 General

The UE and the network may support a satellite E-UTRAN access in WB-S1 mode or NB-S1 mode with CIoT EPS optimization. Support for satellite E-UTRAN access is specified in 3GPP TS 36.300 [20].

An MME can determine a UE is accessing the network using a satellite E-UTRAN access and may enforce mobility restriction for the UE as specified in 3GPP TS 23.401 [10].

4.11.2 Handling list of "PLMNs not allowed to operate at the present UE location"

The UE may be rejected with EMM cause #78 in ATTACH REJECT message, TRACKING AREA UPDATE REJECT message or DETACH REQUEST message. The EMM cause #78 is applicable for the UE only when the UE is accessing a PLMN using a satellite E-UTRAN access.

For the satellite E-UTRAN access the UE shall store a list of "PLMN not allowed to operate at the present UE location". Each entry in the list consists of:

a) PLMN identity of the PLMN which sent a message including EMM cause value #78 "PLMN not allowed to operate at the present UE location" via the satellite E-UTRAN access technology;

b) geographical location, if known by the UE, where the EMM cause value #78 was received over the satellite E-UTRAN access technology; and

c) if the geographical location exists, a UE implementation specific distance value.

Before storing a new entry in the list, the UE shall delete any existing entry with the same PLMN identity. Upon storing a new entry, the UE starts a timer instance associated with the entry with an implementation specific value that shall not be set to a value smaller than the timer value indicated by the network in the Lower bound timer value IE, if any. If the Lower bound timer value IE was not provided by the network, the value of the timer shall be set based on the UE implementation. An entry in the list is deleted if the timer associated to the entry expires or the UE successfully registers to the PLMN stored in the entry.

The UE is allowed to attempt to access a PLMN via the satellite E-UTRAN access technology which is part of the list of "PLMNs not allowed to operate at the present UE location" if:

a) the current UE location is known, a geographical location is stored for the entry of this PLMN, and the distance from location where EMM cause value #78 was received to the current UE location is larger than a UE implementation specific value; or

b) the access is for emergency services (see 3GPP TS 23.122 [5] for further details).

NOTE: When the UE is accessing network for emergency services, it is up to operator and regulatory policies whether the network needs to determine if the UE is in a location where network is not allowed to operate.

The list shall accommodate three or more entries. The maximum number of entries is an implementation decision. When the list is full and a new entry has to be inserted, the oldest entry shall be deleted.

Each entry shall be removed if for the entry:

a) the UE successfully registers via the satellite E-UTRAN access technology to the PLMN stored in the entry except when the UE is attached for emergency bearer services; or

b) the timer instance associated with the entry expires.

The UE may remove an entry in the list, if the UE’s current location is known, a geographical is stored for the entry of this PLMN, and the distance from location where EMM cause value #78 was received to the current UE location is larger than the UE implementation specific value.

If the UE is in EMM-DEREGISTERED.LIMITED-SERVICE state and an entry from the list of "PLMNs not allowed to operate at the present UE location" is removed, the UE shall perform PLMN selection according to 3GPP TS 23.122 [6].

When the UE is switched off, the UE shall keep the list of "PLMNs not allowed to operate at the present UE location" in its non-volatile memory together with the SUPI from the USIM. The UE shall delete the list of "PLMNs not allowed to operate at the present UE location" if the USIM is removed.

If the UE is switched off when the timer instance associated with the entry in the list is running, the UE shall behave as follows when the UE is switched on and the USIM in the UE remains the same:

let t1 be the time remaining for timer instance associated with the entry in the list to timeout at switch off and let t be the time elapsed between switch off and switch on. If t1 is greater than t, then the timer shall be restarted with the value t1 – t. If t1 is equal to or less than t, then the timer need not be restarted and considered expired. If the UE is not capable of determining t, then the UE shall restart the timer with the value t1.

4.11.3 Handling multiple tracking area codes from the lower layers

When a UE camps on a satellite E-UTRAN cell, the UE may receive multiple TACs from the lower layers. The UE shall construct TAIs from the multiple TACs (i.e. concatenate the identity of the current PLMN and each of the TACs) and select a TAI as follows:

a) if at least one TAI belongs to the TAI list of the UE, the UE shall select a TAI which belongs to the TAI list. If there are multiple TAIs which belong to the TAI list the UE shall consider each of these TAIs equal and:

– if the UE can determine a TAI which represents the best the tracking area of the UE’s geographical location, the UE shall select a TAI which represents the best the tracking area of the UE’s geographical location; and

– otherwise, the UE shall select a TAI in an implementation-specific way.

b) if no TAI belongs to the TAI list of the UE and:

1) there is a TAI which belongs to neither the list of "forbidden tracking areas for roaming" nor the list of "forbidden tracking areas for regional provision of service", the UE shall select a TAI which belongs to neither the list of "forbidden tracking areas for roaming" nor the list of "forbidden tracking areas for regional provision of service". In this case, if there are multiple TAIs which belong to neither the list of "forbidden tracking areas for roaming" nor the list of "forbidden tracking areas for regional provision of service", then the UE shall consider each of these TAIs equal and:

– otherwise, the UE shall select a TAI in an implementation-specific way.

2) all TAIs belong to the list of "forbidden tracking areas for roaming" or the list of "forbidden tracking areas for regional provision of service", then the UE shall consider each of these TAIs equal and:

– otherwise, the UE shall select a TAI in an implementation-specific way.

The UE shall consider the selected TAI as the current TAI. The UE shall select a TAI as described above when:

a) the UE receives multiple TACs from the lower layers; or

b) the UE has received multiple TACs from the lower layers upon starting to camping on the current cell and the TAI list, the list of "forbidden tracking areas for roaming", or the list of "forbidden tracking areas for regional provision of service" is updated.

Handling of the list of "forbidden tracking areas for roaming" and the list of "forbidden tracking areas for regional provision of service" is specified in clause 5.3.2.