Editing My 3GPP 24.501 notes

== 4.1 Overview ==
The non-access stratum (NAS) described in 24.501 forms the highest stratum of the control plane between UE and AMF (reference point "N1" see 3GPP TS 23.501) for both 3GPP and non-3GPP access.

Main functions of the protocols that are part of the NAS are:
* support of mobility of the user equipment (UE) including also common procedures such as authentication, identification, generic UE configuration update and security mode control procedures;
* support of session management procedures to establish and maintain data connectivity between the UE and the data network; and
* NAS transport procedure to provide a transport of SMS, LPP, LCS, UE policy container, SOR transparent container and UE parameters update information payload.

Principles for the handing of 5GS security contexts and for the activation of ciphering and integrity protection, when a NAS signalling connection is established, are provided in subclause 4.4.

For the support of the above functions, the following procedures are supplied within this specification:
* elementary procedures for 5GS mobility management in clause 5; and
* elementary procedures for 5GS session management in clause 6.

Signalling procedures for the control of NAS security are described as part of the 5GMM common procedures in subclause 5.4.

Complete NAS transactions consist of specific sequences of elementary procedures. Examples of such specific sequences can be found in 3GPP TS 23.502.

The NAS for 5GS follows the protocol architecture model for layer 3 as described in 3GPP TS 24.007.

== 4.2 Coordination between the protocols for 5GS mobility management and 5GS session management ==
A 5GS session management (5GSM) message is piggybacked in specific 5GS mobility management (5GMM) transport messages. To this purpose, the 5GSM messages can be transmitted in an information element in the 5GMM transport messages. In this case, the UE, the AMF and the SMF execute the 5GMM procedure and the 5GSM procedure in parallel. The success of the 5GMM procedure is not dependent on the success of the piggybacked 5GSM procedure.

The UE can only initiate the 5GSM procedure when there is a 5GMM context established at the UE.

See spec for full details...

== 4.4 NAS security ==

=== 4.4.1 General ===
This clause describes the principles for the handling of 5G NAS security contexts in the UE and in the AMF, the procedures used for the security protection of NAS messages between the UE and the AMF, and the procedures used for the protection of NAS IEs between the UE and the UDM. Security protection involves integrity protection and ciphering of the 5GMM messages. 5GSM messages are security protected indirectly by being piggybacked by the security protected 5GMM messages (i.e. UL NAS TRANSPORT message and the DL NAS TRANSPORT message).

The signalling procedures for the control of NAS security are part of the 5GMM protocol and are described in detail in clause 5.
:NOTE:	''The use of ciphering in a network is an operator option.'' In this subclause, 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 AMF so that it always selects the "null ciphering algorithm", 5G-EA0.

=== 4.4.2 Handling of 5G NAS security contexts ===

==== 4.4.2.5	Establishment of secure exchange of NAS messages ====
Secure exchange of NAS messages via a NAS signalling connection is usually established by the AMF during the registration 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 AMF are sent integrity protected using the current 5G security algorithms, and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered using the current 5G security algorithms.'''''

==== 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 5GMM entity in the UE or forwarded to the 5GSM entity, unless the network has established secure exchange of 5GS NAS messages for the NAS signalling connection:
<ol type="a">
<li>IDENTITY REQUEST (if requested identification parameter is SUCI);</li>
<li>AUTHENTICATION REQUEST;</li>
<li>AUTHENTICATION RESULT;</li>
<li>AUTHENTICATION REJECT;</li>
<li>REGISTRATION REJECT (if the 5GMM cause is not #76 or #78);</li>
<li>DEREGISTRATION ACCEPT (for non switch off); and</li>
<li>SERVICE REJECT (if the 5GMM cause is not #76 or #78).</li>
</ol>
: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.
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.

Once the secure exchange of NAS messages has been established, the receiving 5GMM 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 subclause 5.4.2.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 AMF ====
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the AMF or forwarded to the 5GSM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:

<ol type="a">
<li>REGISTRATION REQUEST;</li>
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li>
<li>AUTHENTICATION RESPONSE;</li>
<li>AUTHENTICATION FAILURE;</li>
<li>SECURITY MODE REJECT;</li>
<li>DEREGISTRATION REQUEST; and</li>
<li>DEREGISTRATION ACCEPT;</li>
</ol>

:NOTE 1:	The REGISTRATION REQUEST message is sent by the UE without integrity protection, if the registration procedure is initiated due to an inter-system change in 5GMM-IDLE mode and no current 5G NAS security context is available in the UE. The other messages are accepted by the AMF without integrity protection, as in certain situations they are sent by the UE before security can be activated.

:NOTE 2:	The DEREGISTRATION REQUEST message can be sent by the UE without integrity protection, e.g. if the UE is registered for emergency services and there is no valid 5G NAS security context available, or if due to user interaction a registration 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 registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.

Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.

Once a current 5G NAS security context exists, until the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF 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 5G NAS security context is not available in the network:

<ol type="a">
<li>REGISTRATION REQUEST;</li>
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li>
<li>AUTHENTICATION RESPONSE;</li>
<li>AUTHENTICATION FAILURE;</li>
<li>SECURITY MODE REJECT;</li>
<li>DEREGISTRATION REQUEST;</li>
<li>DEREGISTRATION ACCEPT;</li>
<li>SERVICE REQUEST; and</li>
<li>CONTROL PLANE SERVICE REQUEST;</li>
</ol>

:NOTE 3:	These messages are processed by the AMF 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 a 5G NAS security context that is no longer available in the network.

If a REGISTRATION REQUEST message for initial registration fails the integrity check and it is not a registration request for emergency services, the AMF shall authenticate the subscriber before processing the registration request any further. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the registration procedure is for emergency services see subclause 5.5.1.2.3 and subclause 5.4.1.3.5.

If a REGISTRATION REQUEST message for mobility and periodic registration update fails the integrity check and the UE provided EPS NAS message container IE which was successfully verified by the source MME, the AMF may create a mapped 5G NAS security context and initiate a security mode control procedure to take the new mapped 5G NAS security context into use; otherwise if the UE has only a non-emergency PDU session established, the AMF shall initiate a primary authentication and key agreement procedure to create a new native 5G NAS security context. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the UE has an emergency PDU session see subclause 5.5.1.3.3 and subclause 5.4.1.3.5.

If a DEREGISTRATION REQUEST message fails the integrity check, the AMF shall proceed as follows:
:- If it is not a deregistration request due to switch off, and the AMF can initiate an authentication procedure, the AMF should authenticate the subscriber before processing the deregistration request any further.
:- If it is a deregistration request due to switch off, or the AMF does not initiate an authentication procedure for any other reason, the AMF may ignore the deregistration request and remain in state 5GMM-REGISTERED.
:NOTE 4:	The network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.

If a SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message fails the integrity check and the UE has only non-emergency PDU sessions established, the AMF shall send the SERVICE REJECT message with 5GMM cause #9 "UE identity cannot be derived by the network" and keep the 5GMM-context and 5G NAS security context unchanged. For the case when the UE has an emergency PDU session and integrity check fails, the AMF may skip the authentication procedure even if no 5G NAS security context is available and proceed directly to the execution of the security mode control procedure as specified in subclause 5.4.2. Additionally, the AMF shall include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. After successful completion of the service request procedure, the network shall perform a local release of all non-emergency PDU sessions. The emergency PDU sessions shall not be released.

Once the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF 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 AMF 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 AMF configuration. When operation of the network without ciphering is configured, the AMF shall indicate the use of "null ciphering algorithm" 5G-EA0 (see subclause 9.11.3.34) in the current 5G NAS security context for all UEs. For setting the security header type in outbound NAS messages, the UE and the AMF shall apply the same rules irrespective of whether the "null ciphering algorithm" or any other ciphering algorithm is indicated in the 5G NAS security context.

When the UE establishes a new N1 NAS signalling connection, it shall apply security protection to the initial NAS message as described in subclause 4.4.6.

The UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has been established for an N1 NAS signalling connection. From this time onward, unless explicitly defined, the UE shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.

The AMF shall start ciphering and deciphering of NAS messages as described in subclause 4.4.2.5. From this time onward, except for the SECURITY MODE COMMAND message, the AMF shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.

Ciphering is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.

Once the encryption of NAS messages has been started between the AMF and the UE, the receiver shall discard the unciphered NAS messages which shall have been ciphered according to the rules described in this specification.
If the "null ciphering algorithm" 5G-EA0 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.501.

=== 4.4.6 Protection of initial NAS signalling messages ===
The 5GS supports protection of initial NAS messages as specified in 3GPP TS 33.501 [24]. The protection of initial NAS messages applies to the REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST message, and is achieved as follows:
<ol type="a"><li>If the UE does not have a valid 5G NAS security context, the UE sends a REGISTRATION REQUEST message including cleartext IEs only. After activating a 5G NAS security context resulting from a security mode control procedure:
<ol>
<li>if the UE needs to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message; or</li>
<li>if the UE does not need to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs only) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message.</li></ol></li>
<li>If the UE has a valid 5G NAS security context and:
<ol>
<li>the UE needs to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE includes the entire REGISTRATION REQUEST or SERVICE REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a REGISTRATION REQUEST or SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li>
<li>the UE needs to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message:</li>
<ol type="i">
:<li>if CIoT small data container IE is the only non-cleartext IE to be sent, the UE shall cipher the value part of the CIoT small data container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the CIoT small data container IE;</li>
:<li>otherwise, the UE includes non-cleartext IEs in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li></ol>
<li>the UE does not need to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE sends the REGISTRATION REQUEST or SERVICE REQUEST message without including the NAS message container IE; or</li>
<li>the UE does not need to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message, the UE sends the CONTROL PLANE SERVICE REQUEST message without including the NAS message container IE and the CIoT small data container IE.</li>
</ol>
</ol>
When the initial NAS message is a REGISTRATION REQUEST message, the cleartext IEs are:
* Extended protocol discriminator;
* Security header type;
* Spare half octet;
* Registration request message identity;
* 5GS registration type;
* ngKSI;
* 5GS mobile identity;
* UE security capability;
* Additional GUTI;
* UE status;
* EPS NAS message container;
* NID; and
* PLMN with disaster condition.

When the initial NAS message is a SERVICE REQUEST message, the cleartext IEs are:
* Extended protocol discriminator;
* Security header type;
* Spare half octet;
* ngKSI;
* Service request message identity;
* Service type; and
* 5G-S-TMSI.

When the initial NAS message is a CONTROL PLANE SERVICE REQUEST message, the cleartext IEs are:
* Extended protocol discriminator;
* Security header type;
* Spare half octet;
* ngKSI;
* Control plane service request message identity; and
* Control plane service type.

When the UE sends a REGISTRATION REQUEST or SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message that includes a NAS message container IE, the UE shall set the security header type of the initial NAS message to "integrity protected".

When the AMF receives an integrity protected initial NAS message which includes a NAS message container IE, the AMF shall decipher the value part of the NAS message container IE. If the received initial NAS message is a REGISTRATION REQUEST message or a SERVICE REQUEST message, the AMF shall consider the NAS message that is obtained from the NAS message container IE as the initial NAS message that triggered the procedure.

When the AMF receives a CONTROL PLANE SERVICE REQUEST message which includes a CIoT small data container IE, the AMF shall decipher the value part of the CIoT small data container IE and handle the message as specified in subclause 5.6.1.4.2.

When the initial NAS message is a DEREGISTRATION REQUEST message, the UE always sends the NAS message unciphered.

If the UE:
<ol type="a">
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li>
<li>selects a PLMN other than Registered PLMN and EPLMN over one access;</li>
</ol>
the UE shall send an initial NAS message including cleartext IEs only via the access type associated with the newly selected PLMN as described in this subclause for the case when the UE does not have a valid 5G NAS security context.

If the UE:
<ol type="a">
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li>
<li>selects a PLMN other than Registered PLMN and EPLMN over one access, and the Registered PLMN or EPLMN is not registering or registered over other access;</li>
</ol>
the UE shall delete the 5G NAS security context.

:NOTE:	UE deletes the 5G NAS security context only if the UE is not in the connected mode.

=== 4.4.7 Protection of NAS IEs ===
The network can provide the Steering of Roaming (SOR) transparent container Information Element (IE) during the registration procedure to the User Equipment (UE) in the REGISTRATION ACCEPT message. The SOR transparent container IE is integrity protected by the Home Public Land Mobile Network (HPLMN) or subscribed Standalone Non-Public Network (SNPN) as specified in 3GPP TS 33.501.

The UE can provide the SOR transparent container IE during the registration procedure to the network in the REGISTRATION COMPLETE message. The SoR-MAC-IUE in the SOR transparent container IE is generated by the UE as specified in 3GPP TS 33.501.

The network can provide the Payload container IE during the Network-initiated NAS transport procedure to the UE in DL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the Payload container IE is integrity protected by the HPLMN or subscribed SNPN as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the payload container entry contents field of the payload container entry is integrity protected correspondingly.

The UE can provide the Payload container IE during the UE-initiated NAS transport procedure to the network in UL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the Payload container IE is generated by the UE as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the payload container entry contents field of the payload container entry is generated by the UE correspondingly.

== 4.7 NAS over non-3GPP access ==

See spec for details

=== 4.7.1 General ===
From the UE's NAS perspective, in general the procedures and messages defined for 5GMM and 5GSM are used over non-3GPP access as over 3GPP access. However, a number of aspects are different as described in the following subclauses.

=== 4.7.2 5GS mobility management (5GMM) aspects ===

==== 4.7.2.1 General ====
The mobility management procedures defined over 3GPP access are re-used over non-3GPP access with certain exceptions. The list goes from a) to s), see spec for details.

==== 4.7.2.2 Establishment cause for non-3GPP access ====
When establishment of an N1 NAS signalling connection over non-3GPP access is initiated, the UE shall do certain things. See spec for details.


=== 4.7.3 5GS session management (5GSM) aspects ===
The session management procedures defined over 3GPP access are re-used over non-3GPP access with the following exceptions:
<ol type="a">
<li>Serving PLMN rate control does not apply for non-3GPP access;</li>
<li>Small data rate control does not apply for non-3GPP access;</li>
<li>Handling of 5GSM cause value #82 "maximum data rate per UE for user-plane integrity protection is too low" does not apply for non-3GPP access;</li>
<li>MBS does not apply for non-3GPP access; and</li>
<li>Support of redundant PDU sessions does not apply for non-3GPP access.</li>
</ol>

=== 4.7.4 Limited service state over non-3GPP access ===

There are a number of situations in which the UE is unable to obtain normal service from a PLMN over non-3GPP access and the UE enters the limited service state over non-3GPP access. These include:
<ol type="a">
<li>no Universal Subscriber Identity Module (USIM) in the Mobile Equipment (ME);</li>
<li>an "illegal UE" or "illegal ME" is received when registration, network-initiated de-registration or service request is performed (any USIM in the ME is then considered "invalid");</li>
<li>a "5GS services not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li>
<li>a "PLMN not allowed" is received when registration, network-initiated de-registration or service request is performed;</li>
<li>a "Tracking area not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li>
<li>a "Roaming not allowed in this tracking area" is received when a registration, network-initiated de-registration or service request is performed;</li>
<li>void; or</li>
<li>a "Serving network not authorized" is received when a registration or service request is performed.</li>
</ol>
In limited service state with a valid USIM in the UE, the network selection is performed as defined in 3GPP TS 24.502.

With the exception of performing initial registration for emergency services, no registration requests are made until a valid USIM is present. For registration for emergency services, the PLMN of the current N3IWF or TNGF is considered as the selected PLMN for the duration the UE is registered for emergency services.

=== 4.7.5 NAS signalling using trusted WLAN access network ===

A trusted WLAN interworking function (TWIF) provides functionalities for a non-5G capable over WLAN (N5CW) device to access 5GCN, including:
<ol type="a">
<li>NAS signalling over N1 NAS signalling connection with AMF; and</li>
<li>PDU session establishment, modification and release on behalf of the N5CW device, over N2 connection with the AMF.</li>
</ol>
The TWIF registers on behalf of the N5CW device to an AMF according to subclause 5.5.1.3 by populating the parameters for the registration by using implementation specific default values which are the same for N5CW devices.

The TWIF may request to establish a PDU session as specified in subclause 6.4.1.2 on behalf of the N5CW device upon receipt of an IP configuration request from the N5CW device by populating either all the required parameters or part of the required parameters for the PDU session establishment by using implementation specific default values from the TWIF's configuration. Only one PDU session is supported when N5CW device accessing 5GC via the TWIF.

:NOTE 1: If part of the required parameters for the PDU session establishment is provided by the TWIF, the remaining of the required parameters are determined by the AMF or the SMF based on the N5CW device's subscription information.
Upon loss of the IP address of the N5CW device, the TWIF acting on behalf of the N5CW device shall initiate the UE-requested PDU session release procedure as defined in subclause 6.4.3.

:NOTE 2: The established PDU session on behalf of the N5CW device can be modified by the TWIF or the network.

== 4.8 Interworking with E-UTRAN connected to EPC ==

=== 4.8.1 General ===
In order to interwork with E-UTRAN connected to EPC, the UE supporting both S1 mode and N1 mode can operate in single-registration mode or dual-registration mode (see 3GPP TS 23.501). Support of single-registration mode is mandatory for UEs supporting both S1 mode and N1 mode.

During the EPS attach procedure (see 3GPP TS 24.301) or initial registration procedure (see subclause 5.5.1.2), the mode for interworking is selected if the UE supports both S1 mode and N1 mode, and the network supports interworking. The mode for interworking may also be selected during the EPS tracking area updating procedure (see 3GPP TS 24.301) or registration procedure for mobility and periodic registration update (see subclause 5.5.1.3).

For interworking between E-UTRAN connected to EPC and TNGF or N3IWF connected to 5GCN, the UE shall operate as specified in either subclause 4.8.2.3 or subclause 4.8.3. Which subclause the UE follows is chosen by the UE irrespective of the interworking without N26 interface indicator.

=== 4.8.2 Single-registration mode ===
See spec for details...

=== 4.8.3 Dual-registration mode ===

If both 5G Mobility Management (5GMM) and EPS Mobility Management (EMM) are enabled, a UE, operating in the dual-registration mode shall maintain independent contexts for 5GMM and EMM and this includes independent lists of equivalent PLMNs. Coordination between 5GMM and EMM is not needed, except as specified in the present subclause, subclause 5.1.5 and 5.3.13A.

For dual-registration mode the following applies:
<ol type="a">
<li>a UE operating in the dual-registration mode may register to N1 mode only, S1 mode only, or to both N1 mode and S1 mode;</li>
<li>when the UE decides to operate in dual-registration mode (see subclause 5.5.1.2.4), NAS informs the lower layers about this;</li>
<li>if a UE is registered in N1 mode only, then for registration in S1 mode the UE shall use:</li>
# the same PLMN to which it is registered in N1 mode; or
# an equivalent PLMN; and
<li>if a UE is registered in S1 mode only, then for registration in N1 mode the UE shall use:</li>
# the same PLMN to which it is registered in S1 mode; or
# an equivalent PLMN.
</ol>
:NOTE 1: It is up to UE implementation how to handle the case when the UE is registered in both N1 mode and S1 mode and the PLMNs to which the UE is registered, are not equivalent, e.g. search for a PLMN which is the same or equivalent to any of the registered ones.

When no PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure with PDN connection establishment if EMM-REGISTERED without PDN connection is not supported by the MME. If EMM-REGISTERED without PDN connection is supported by the MME, the UE may initiate either the EPS attach procedure without PDN connection establishment or the attach procedure with PDN connection establishment.

When at least one PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure. If necessary, the UE may transfer an active PDU session from N1 mode to S1 mode by initiating the EPS attach procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message. After successfully attached in S1 mode, if necessary, the UE may transfer other active PDU sessions from N1 mode to S1 mode by initiating the PDN connectivity procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message.

:NOTE 2: It is up to UE implementation to determine which active PDU session is transferred from N1 mode to S1 mode.

When the UE has not registered to N1 mode, the UE may initiate the initial registration procedure. After successfully registered in N1 mode, if necessary, the UE may transfer one or more active PDN connections from S1 mode to N1 mode by initiating the PDU session establishment procedure with request type set to "existing PDU session".

:NOTE 3: It is up to UE implementation to determine which active PDN connection is transferred from S1 mode to N1 mode.

If the MME supports EMM-REGISTERED without PDN connection, the UE that transferred all PDN connections to the 5GS, may stay in state EMM-REGISTERED. Otherwise, the UE shall enter state EMM-DEREGISTERED upon transferring all PDN connection to the 5GS.

:NOTE 4: When the UE has registered in both N1 mode and S1 mode, it is up to UE implementation to maintain the registration update to date in both N1 mode and S1 mode.

See subclause 6.1.4 for coordination between 5GSM and ESM.

See subclause 4.8.2.3.2 for interworking between TNGF or N3IWF connected to 5GCN and E-UTRAN.

=== 4.8.4 Core Network selection for UEs not using Cellular Internet of Things (CIoT) 5GS optimizations ===
If the UE is capable of both N1 mode and S1 mode, when the UE needs to use one or more functionalities not supported in 5GS but supported in EPS and the UE is in 5GMM-IDLE mode, the UE may disable the N1 mode capability for 3GPP access (see subclause 4.9.2).

If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN without also providing an indication that a target core network type was received from the NG-RAN, the UE shall select a core network type (EPC or 5GCN) based on the PLMN selection procedures as specified in 3GPP TS 23.122 and provide the selected core network type information to the lower layer during the initial registration procedure.

If the UE is capable of both N1 mode and S1 mode and the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN and an indication of whether the network supports IMS emergency services via either EPC or 5GCN or both (see 3GPP TS 36.331 [25A]), the UE selects a core network type (EPC or 5GCN) as specified in 3GPP TS 23.167 [6] annex H.2 for initiating emergency calls when in the state 5GMM-DEREGISTERED.LIMITED-SERVICE or EMM-DEREGISTERED.LIMITED-SERVICE.
:NOTE 1: If the PLMN selection information provisioned in the USIM does not contain any prioritization between E-UTRAN and NG-RAN for a PLMN, which core network type to select for that PLMN is up to UE implementation.

If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN with:
# an indication that target core network type EPC was received from the NG-RAN, the UE shall select the EPC and proceed with the appropriate EMM procedure as specified in 3GPP TS 24.301; or
# an indication that target core network type 5GCN was received from the NG-RAN, the UE shall select the 5GCN and proceed with the appropriate 5GMM procedure.
:NOTE 2: The NG-RAN can provide a target core network type to the UE during RRC connection release with redirection (see 3GPP TS 36.331 and 3GPP TS 38.331).

=== 4.8.4A Core Network selection and redirection for UEs using CIoT optimizations ===

==== 4.8.4A.1 Core network selection ====
A UE that supports CIoT optimizations performs core network selection (i.e. it selects EPC or 5GCN) if the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN as specified in 3GPP TS 23.501.

When selecting a PLMN as described in 3GPP TS 23.122, the UE shall select a core network type (EPC or 5GCN) based on:
<ol type="a">
<li>indication from the lower layers about the CIoT EPS optimizations supported in EPC;</li>
<li>indication from the lower layers about the CIoT 5GS optimizations supported in 5GCN;</li>
<li>the CIoT EPS optimizations supported by the UE;</li>
<li>the CIoT 5GS optimizations supported by the UE;</li>
<li>the UE's preferred CIoT network behaviour for EPC; and</li>
<li>the UE's preferred CIoT network behaviour for 5GCN.</li>
</ol>

The UE shall provide the selected core network type information to the lower layer during the initial registration procedure.

==== 4.8.4A.2 Redirection of the UE by the core network ====
The network that supports CIoT optimizations can redirect a UE between EPC and 5GCN as specified in subclause 5.31.3 of 3GPP TS 23.501. The network can take into account the UE's N1 mode capability or S1 mode capability, the CIoT network behaviour supported and preferred by the UE or the CIoT network behaviour supported by the network to determine the redirection.

:NOTE:	It is assumed that the network would avoid redirecting the UE back and forth between EPC and 5GCN.

The network redirects the UE to EPC by rejecting the registration request or service request with the 5GMM cause #31 "Redirection to EPC required" as specified in subclause 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5. Upon receipt of reject message, the UE disables the N1 mode capability for 3GPP access as specified in subclause 4.9.2 and enables the E-UTRA capability if it was disabled in order to move to EPC.

When there is no ongoing registration procedure or service request procedure for a UE in 5GMM-CONNECTED mode, if the AMF determines to redirect the UE to EPC, the AMF shall initiate the generic UE configuration update procedure to indicate registration requested and release of the N1 NAS signalling connection not requested as described in subclause 5.4.4. The network then redirects the UE to EPC by rejecting the registration request as specified in subclause 5.5.1.3.5.

The network that supports CIoT optimizations can also redirect a UE from EPC to 5GCN as specified in subclause 5.3.19.2 of 3GPP TS 24.301.

== 4.9 Disabling and re-enabling of UE's N1 mode capability ==

=== 4.9.1 General ===

The UE shall re-enable the N1 mode capability when the UE powers off and powers on again, the USIM is removed or an entry of the "list of subscriber data" with the SNPN identity of the SNPN is updated.

=== 4.9.2 Disabling and re-enabling of UE's N1 mode capability for 3GPP access ===

The UE shall only disable the N1 mode capability for 3GPP access when in 5GMM-IDLE mode.

When the UE is disabling the N1 mode capability for 3GPP access for a PLMN not due to redirection to EPC, it should proceed as follows:
<ol type="a">
<li>select an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs, if the UE supports S1 mode and the UE has not disabled its E-UTRA capability as specified in 3GPP TS 24.301;</li>
<li>if an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, the UE does not support S1 mode or the UE has disabled its E-UTRA capability as specified in 3GPP TS 24.301, the UE may select another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs that the UE supports;</li>
<li>if another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, then enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH, or the UE does not have a registered PLMN, then enter the state 5GMM-DEREGISTERED.PLMN-SEARCH and perform PLMN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this PLMN selection. As an implementation option, if the UE does not have a registered PLMN, instead of performing PLMN selection, the UE may select another RAT of the selected PLMN if the UE has chosen a PLMN and the RAT is supported by the UE; or</li>
<li>if no other allowed PLMN and RAT combinations are available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered PLMN, and may periodically scan for another PLMN and RAT combination which can provide EPS services or non-EPS services (if the UE supports EPS services or non-EPS services). How this periodic scanning is done, is UE implementation dependent.</li>
</ol>
When the UE is disabling the N1 mode capability for 3GPP access for an SNPN, it should proceed as follows:
<ol type="a">
<li>enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH and perform SNPN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this SNPN selection; or</li>
<li>if no other SNPN is available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered SNPN.</li>
</ol>

When the UE is disabling the N1 mode capability upon receiving cause value #31 "Redirection to EPC required" as specified in subclauses 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5, it should proceed as follows:
<ol type="a">
<li>If the UE is in NB-N1 mode:</li>
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable NB-IoT cell connected to EPC according to 3GPP TS 36.304;
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or
# if lower layers cannot find a suitable NB-IoT cell connected to EPC or there is no suitable NB-IoT cell connected to EPC which supports CIoT EPS 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 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.
<li>If the UE is in WB-N1 mode:</li>
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable E-UTRA cell connected to EPC according to 3GPP TS 36.304;
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, then perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or
# if lower layers cannot find a suitable E-UTRA cell connected to EPC or there is no suitable E-UTRA cell connected to EPC which supports CIoT EPS 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 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.
</ol>

When the UE supporting both N1 mode and S1 mode needs to stay in E-UTRA connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional handover or cell reselection from E-UTRA connected to EPC to NG-RAN connected to 5GCN, the UE operating in single-registration mode shall disable the N1 mode capability for 3GPP access and:
<ol type="a">
<li>shall set the N1mode bit to "N1 mode for 3GPP access not supported" in the UE network capability IE (see 3GPP TS 24.301) of the ATTACH REQUEST message and the TRACKING AREA UPDATE REQUEST message in EPC; and</li>
<li>the UE NAS layer shall indicate the access stratum layer(s) of disabling of the N1 mode capability for 3GPP access.</li>
</ol>

If the UE is required to disable the N1 mode capability for 3GPP access and select E-UTRA or another RAT, and the UE is in the 5GMM-CONNECTED mode,
* if the UE has a persistent PDU session, then the UE waits until the radio bearer associated with the persistent PDU session has been released;
* otherwise the UE shall locally release the established NAS signalling connection;

and enter the 5GMM-IDLE mode before selecting E-UTRA or another RAT.

If the UE is disabling its N1 mode capability for 3GPP access before selecting E-UTRA or another RAT, the UE shall not perform the UE-initiated de-registration procedure of subclause 5.5.2.2.

The UE shall re-enable the N1 mode capability for 3GPP access when the UE performs PLMN or SNPN selection over 3GPP access, unless
* disabling of the N1 mode capability for 3GPP access was due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off; or
* the UE has already re-enabled the N1 mode capability for 3GPP access when performing items c) or d) above.

If the disabling of N1 mode capability for 3GPP access was due to IMS voice is not available over 3GPP access and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for 3GPP access when the UE's usage setting is changed from "voice centric" to "data centric", as specified in subclauses 4.3.3.

The UE should memorize the identity of the PLMN or SNPN where N1 mode capability for 3GPP access was disabled and should use that stored information in subsequent PLMN or SNPN selections as specified in 3GPP TS 23.122.

If the disabling of N1 mode capability for 3GPP access was due to successful completion of an emergency services fallback, the criteria to enable the N1 mode capability again are UE implementation specific.

The UE shall disable the N1 mode capability for 3GPP access if requested by the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229). If the UE disabled the N1 mode capability for 3GPP access based on the request from the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229), the criteria to re-enable the N1 mode capability for 3GPP access after the completion of an emergency service are UE implementation specific.

If the N1 mode capability for 3GPP access was disabled due to the UE initiated de-registration procedure for 3GPP access or for 3GPP access and non-3GPP access and the UE is operating in single-registration mode (see subclause 5.5.2.2.3), upon request of the upper layers to re-register for 5GS services over 3GPP access the UE shall enable the N1 mode capability for 3GPP access again.

As an implementation option, the UE may start a timer for enabling the N1 mode capability for 3GPP access when the UE's registration attempt counter reaches 5 and the UE disables the N1 mode capability for 3GPP access for cases described in subclauses 5.5.1.2.7 and 5.5.1.3.7. The UE should memorize the identity of the PLMNs where N1 mode capability for 3GPP access was 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 on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access;
* 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 the N1 mode capability for 3GPP access; and
* if the UE is in S1 mode and is in EMM-IDLE mode as specified in 3GPP TS 24.301, on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access.

If the UE is in Iu mode or A/Gb mode and an Radio Resource (RR) connection exists, the UE should delay enabling the N1 mode capability for 3GPP access until the RR connection is released. If the UE is in S1 mode and is in EMM-CONNECTED mode as specified in 3GPP TS 24.301, the UE should delay enabling the N1 mode capability for 3GPP access until the NAS signalling connection in S1 mode is released.

<pre>A	Interface between a BSS and a 2G MSC
Gb	Interface between a BSS and a 2G SGSN
Iu-cs	Interface between a BSS and a 3G MSC
Iu-ps	Interface between a BSS and a 3G SGSN
Iur-g	Interface between two BSSs
Um	Interface between MS and BSS

Source: 3GPP TS 43.501</pre>

The UE may disable the N1 mode capability for currently camped PLMN or SNPN over 3GPP access (see 3GPP TS 23.122) if no network slice is available for the camped PLMN or SNPN.

If the UE attempts to establish an emergency PDU session in a PLMN where N1 mode capability was disabled due to the UE's registration attempt counter have reached 5, the UE may enable N1 mode capability for that PLMN memorized by the UE.

:NOTE: If N1 mode capability is disabled due to the UE's registration attempt counter reaches 5, the value of the timer for re-enabling N1 mode capability is recommended to be the same as the value of T3502 which follows the handling specified in subclause 5.3.8.

=== 4.9.3 Disabling and re-enabling of UE's N1 mode capability for non-3GPP access ===

When the UE disables the N1 mode capability for non-3GPP access, the UE NAS layer shall not initiate any 5GS NAS procedures towards the network over non-3GPP access.

When the UE supporting both N1 mode and S1 mode needs to stay in non-3GPP access connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional selection of a non-3GPP access network connected to 5GCN, the UE operating in single-registration mode shall not transfer any PDN connection to a non-3GPP access network connected to the 5GCN.

If the disabling of N1 mode capability for non-3GPP access was due to IMS voice is not available over non-3GPP access in 5GS and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for non-3GPP access when the UE's usage setting is changed from "voice centric" to "data centric" as specified in subclauses 4.3.3.

The UE shall re-enable the N1 mode capability for non-3GPP access when a new PLMN or SNPN is selected over non-3GPP access.

:NOTE: In SNPN, the term "UE's N1 mode capability for non-3GPP access" in this subclause refers to the UE's N1 mode capability to access SNPN services via a PLMN.

The UE may disable the N1 mode capability for the currently camped PLMN or SNPN over non-3GPP access if no network slice is available for the camped PLMN or SNPN.

As an implementation option, the UE may start a timer for re-enabling the N1 mode capability for non-3GPP access, after the N1 mode capability for non-3GPP access was disabled. On the expiry of this timer, the UE should re-enable the N1 mode capability for non-3GPP access.

== 4.11 UE configuration parameter updates ==

The 5GS in a PLMN supports updating UE parameters via NAS signalling. The feature enables the HPLMN to securely and dynamically re-configure the UE configuration parameters stored on the USIM and the ME.

See spec for details...

== 4.13 Support of NAS signalling using wireline access network ==
A 5G-RG, a W-AGF acting on behalf of an FN-RG or a W-AGF acting on behalf of an N5GC device can use wireline access network to access the 5GCN by using NAS signalling procedures as described in 3GPP TS 23.501, 3GPP TS 23.502 and 3GPP TS 23.316.

Wireline access is a type of non-3GPP access.

A 5G-RG simultaneously connected to the same 5GCN of a PLMN over a 3GPP access and a wireline access is connected to a single AMF.

5G-RG maintains the N1 NAS signalling connection with the AMF over the wireline access network after all the PDU sessions for the 5G-RG over that access have been released or handed over to 3GPP access.

See spec for details...

== 4.14 Non-public network (NPN) ==
=== 4.14.1 General ===
Two types of NPN can be deployed using 5GS: SNPN (see subclause 4.14.2) and PNI-NPN (see subclause 4.14.3).

==== 4.14.2 Stand-alone non-public network ====
If the UE is not SNPN enabled, the UE is always considered to be not operating in SNPN access operation mode. If the UE is SNPN enabled, the UE can operate in SNPN access operation mode. Details of activation and deactivation of SNPN access operation mode at the SNPN enabled UE are up to UE implementation.

The functions and procedures of NAS described in the present document are applicable to an SNPN and an SNPN enabled UE unless indicated otherwise.

See spec for details...

=== 4.14.3 Public network integrated non-public network (PNI-NPN) ===

A PNI-NPN is made available by means of e.g. dedicated DNNs or by one or more S-NSSAIs allocated for it. A CAG can be optionally used in order to prevent UEs not allowed to access a PNI-NPN from accessing the PNI-NPN.

See spec for details...

== 4.16 UE radio capability signalling optimization ==

See spec for details...

== 4.17 5GS mobility management in NB-N1 mode ==

See spec for details...

== 4.19 5GS mobility management in WB-N1 mode for IoT ==

See spec for details...

== 4.20 5GS session management in WB-N1 mode for IoT ==

See spec for details...

== 4.23 NAS over Non-Terrestrial Network ==

See spec for details...

== 4.24 Minimization of service interruption (MINT) ==

The UE and the network may support Minimization of service interruption (MINT). MINT aims to enable a UE to obtain service from a PLMN offering disaster roaming service when a disaster condition applies to the UE's determined PLMN with disaster condition.

If the UE supports MINT, the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "list of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range provisioned by the network, if available, are stored in the non-volatile memory in the ME as specified in annex C and are kept when the UE enters 5GMM-DEREGISTERED state. Annex C specifies condition under which the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "lists of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range stored in the ME are deleted.

See spec for details...

== 4.25	Support of MUSIM features ==
<pre>MUSIM UE: A UE with multiple valid USIMs, capable of initiating and maintaining simultaneous separate registration states over 3GPP access with PLMN(s) using identities and credentials associated with those USIMs and supporting one or more of the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control (see 3GPP TS 23.501).

Source: 3GPP TS 24.501</pre>

A network and a MUSIM UE may support one or more of the MUSIM features (i.e. the N1 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 (except for the paging timing collision control) during the registration procedure. If the UE has indicated support of the N1 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 registration procedure. The network only indicates the support of the paging restriction together with the support of either N1 NAS signalling connection release or the reject paging request.

The network does not indicate support for any MUSIM feature to the UE during the registration for emergency 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 registration procedure for mobility and periodic registration update to indicate that all the MUSIM features are not supported (except for the paging timing collision control) as specified in subclause 5.5.1.3.

A MUSIM UE operating in NB-N1 mode or in WB-N1 mode CE mode B does not indicate the support for paging indication for voice services during the registration procedure towards the network.

== 5.3 General on elementary 5G Mobility Management (5GMM) procedures ==

=== 5.3.1 5GMM modes and N1 NAS signalling connection ===

==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====
When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial Non-Access Stratum (NAS) message, the User Equipment (UE) shall request the lower layer to establish an Radio Resource Controller (RRC) connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access.

When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access.

Initial NAS messages are:
<ol type="a">
<li>REGISTRATION REQUEST message;</li>
<li>DEREGISTRATION REQUEST message;</li>
<li>SERVICE REQUEST message; and</li>
<li>CONTROL PLANE SERVICE REQUEST.</li>
</ol>


<center>[[Telecommunications info|To Telecommunications info]]</center>