Difference between revisions of "My 3GPP 24.501 notes"

From Got Opinion Wiki
Jump to navigation Jump to search
 
Line 70: Line 70:


=== 4.4.1 General ===
=== 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 <span style="color:blue">security protection of NAS messages between the UE and the AMF</span>, and the procedures used for the <span style="color:blue">protection of NAS IEs between the UE and the UDM</span>. 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).
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 <span style="color:blue">security protection of NAS messages between the UE and the AMF</span>, and the procedures used for the <span style="color:blue">protection of NAS IEs between the UE and the UDM</span>. <span style="color:purple">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)</span>.


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

Latest revision as of 08:24, 16 July 2023

1 Scope

3GPP TS 24.501 document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:

  • mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and
  • session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.

The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.

The 5GS session management (5GSM) protocol defined in the present document provides procedures for the handling of 5GS PDU sessions. Together with the bearer control provided by the access stratum, this protocol is used for the control of user-plane resources.

For both NAS protocols the present document specifies procedures for the support of inter-system mobility between the NG-RAN and the evolved universal terrestrial radio access (E-UTRAN), between the NG-RAN and the non-3GPP access network connected to the EPC, and between the non-3GPP access network connected to the 5G core network (5GCN) and the E-UTRAN.

For both NAS protocols the present document specifies procedures for the support of mobility between the NG-RAN and the non-3GPP access network connected to the 5GCN.

In addition, the present document specifies the procedures in the 5GS for UE policy delivery service between the UE and the policy control function (PCF) for both 3GPP access and non-3GPP access.

The present document is applicable to the UE, the access and mobility management function (AMF), the session management function (SMF), and the PCF in the 5GS.

The clauses and subclauses in the present document are common for both 3GPP access and non-3GPP access unless it is explicitly stated that they apply to 3GPP access only or non-3GPP access only.

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 5G system (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.

During 5GMM procedures, the UE and the AMF shall suspend the transmission of 5GSM messages, except when:

  1. the 5GMM procedure is piggybacking 5GSM messages; or
  2. the UE is in 5GMM-CONNECTED mode and a service request procedure for re-establishing user-plane resources of PDU session(s) is initiated without including PDU session status IE or Allowed PDU session status IE. In this case, the UE and the AMF need not suspend the transmission of 5GSM messages related to other PDU session(s) than the one(s) for which the user- plane resources re-establishment is requested.

If the UE determines to locally release the N1 NAS signalling connection upon receiving an Steering of Roaming (SOR) transparent container during a registration procedure as specified in 3GPP TS 23.122 Annex C.2, the UE shall suspend the transmission of 5GSM messages after sending the REGISTRATION COMPLETE message and until the N1 NAS signalling connection is released to obtain service on a higher priority PLMN, with the exception of the case when the UE has an emergency PDU session.

A 5GMM message piggybacking a 5GSM message for a PDU session shall be delivered via the access associated with the PDU session, if any, with the following exceptions:

  1. the AMF shall send, via 3GPP access, a Downlink (DL) NAS TRANSPORT message piggybacking a downlink 5GSM message of a network-requested 5GSM procedure for a PDU session associated with non-3GPP access if the conditions specified in subclause 5.5.1.3.4 or subclause 5.6.1.4 are met;
  2. the UE shall send an UL NAS TRANSPORT message piggybacking a response message to the 5GSM message described in a) via either:
    1. 3GPP access; or
    2. non-3GPP access if the UE is in 5GMM-CONNECTED mode over non-3GPP access; and
    NOTE: The interaction between the 5GMM sublayer and the 5GSM sublayer to enable the UE to send the UL NAS TRANSPORT message containing the response message via 3GPP access is required. This is achieved via UE implementation.
  3. the UE shall send, via the target access, an Uplink (UL) NAS TRANSPORT message piggybacking a 5GSM message associated with a request type set to "existing PDU session" or "existing emergency PDU session" for handover of an existing PDU session between 3GPP access and non-3GPP access.

A 5GMM message piggybacking a 5GSM message as a response message to a request message associated with an MA PDU session, shall be delivered via the same access that the initial message was received.

UE domain selection

See spec

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:

  1. IDENTITY REQUEST (if requested identification parameter is SUCI);
  2. AUTHENTICATION REQUEST;
  3. AUTHENTICATION RESULT;
  4. AUTHENTICATION REJECT;
  5. REGISTRATION REJECT (if the 5GMM cause is not #76 or #78);
  6. DEREGISTRATION ACCEPT (for non switch off); and
  7. SERVICE REJECT (if the 5GMM cause is not #76 or #78).
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:

  1. REGISTRATION REQUEST;
  2. IDENTITY RESPONSE (if requested identification parameter is SUCI);
  3. AUTHENTICATION RESPONSE;
  4. AUTHENTICATION FAILURE;
  5. SECURITY MODE REJECT;
  6. DEREGISTRATION REQUEST; and
  7. DEREGISTRATION ACCEPT;
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:

  1. REGISTRATION REQUEST;
  2. IDENTITY RESPONSE (if requested identification parameter is SUCI);
  3. AUTHENTICATION RESPONSE;
  4. AUTHENTICATION FAILURE;
  5. SECURITY MODE REJECT;
  6. DEREGISTRATION REQUEST;
  7. DEREGISTRATION ACCEPT;
  8. SERVICE REQUEST; and
  9. CONTROL PLANE SERVICE REQUEST;
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. The protection of initial NAS messages applies to the REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST message, and is achieved as follows:

  1. 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:
    1. 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
    2. 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.
  2. If the UE has a valid 5G NAS security context and:
    1. 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;
    2. the UE needs to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message:
      1. 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;
      2. 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;
    3. 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
    4. 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.

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:

  1. has 5G-EA0 as a selected 5G NAS security algorithm; and
  2. selects a PLMN other than Registered PLMN and EPLMN over one access;

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:

  1. has 5G-EA0 as a selected 5G NAS security algorithm; and
  2. 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;

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:

  1. Serving PLMN rate control does not apply for non-3GPP access;
  2. Small data rate control does not apply for non-3GPP access;
  3. 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;
  4. MBS does not apply for non-3GPP access; and
  5. Support of redundant PDU sessions does not apply for non-3GPP access.

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:

  1. no Universal Subscriber Identity Module (USIM) in the Mobile Equipment (ME);
  2. 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");
  3. a "5GS services not allowed" is received when a registration, network-initiated de-registration or service request is performed;
  4. a "PLMN not allowed" is received when registration, network-initiated de-registration or service request is performed;
  5. a "Tracking area not allowed" is received when a registration, network-initiated de-registration or service request is performed;
  6. a "Roaming not allowed in this tracking area" is received when a registration, network-initiated de-registration or service request is performed;
  7. void; or
  8. a "Serving network not authorized" is received when a registration or service request is performed.

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:

  1. NAS signalling over N1 NAS signalling connection with AMF; and
  2. PDU session establishment, modification and release on behalf of the N5CW device, over N2 connection with the AMF.

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:

  1. 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;
  2. when the UE decides to operate in dual-registration mode (see subclause 5.5.1.2.4), NAS informs the lower layers about this;
  3. if a UE is registered in N1 mode only, then for registration in S1 mode the UE shall use:
    1. the same PLMN to which it is registered in N1 mode; or
    2. an equivalent PLMN; and
  4. if a UE is registered in S1 mode only, then for registration in N1 mode the UE shall use:
    1. the same PLMN to which it is registered in S1 mode; or
    2. an equivalent PLMN.
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:

  1. 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
  2. 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:

  1. indication from the lower layers about the CIoT EPS optimizations supported in EPC;
  2. indication from the lower layers about the CIoT 5GS optimizations supported in 5GCN;
  3. the CIoT EPS optimizations supported by the UE;
  4. the CIoT 5GS optimizations supported by the UE;
  5. the UE's preferred CIoT network behaviour for EPC; and
  6. the UE's preferred CIoT network behaviour for 5GCN.

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:

  1. 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;
  2. 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;
  3. 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
  4. 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.

When the UE is disabling the N1 mode capability for 3GPP access for an SNPN, it should proceed as follows:

  1. 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
  2. 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.

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:

  1. If the UE is in NB-N1 mode:
    1. 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;
    2. 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
    3. 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.
  2. If the UE is in WB-N1 mode:
    1. 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;
    2. 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
    3. 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.

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:

  1. 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
  2. the UE NAS layer shall indicate the access stratum layer(s) of disabling of the N1 mode capability for 3GPP access.

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.

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

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

MUSIM UE: A UE with multiple valid Universal Subscriber Identity Modules (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

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.1 Overview

5.1.1 General

The main function of the 5GS mobility management (5GMM) sublayer is to support the identification, security, mobility of a UE as well as generic message transport.

A further function of the 5GMM sublayer is to provide connection management services to the other sublayer(s).

NOTE: In a satellite NG-RAN access, a GNSS fix time in lower layers can delay transmission of an initial UL NAS message by up to 100 seconds (GNSS cold state).

5.1.2 Types of 5GMM procedures

Depending on how they can be initiated, three types of 5GMM procedures can be distinguished:

  • 5GMM common procedures
  • 5GMM specific procedures
  • 5GMM connection management procedures

Three types of 5GMM procedures broken out...

  1. 5GMM common procedures: 5GMM common procedure can always be initiated when the UE is in 5GMM-CONNECTED mode. The procedures belonging to this type are:
    1. Initiated by the network:
      1. network-initiated NAS transport;
      2. primary authentication and key agreement;
      3. security mode control;
      4. generic UE configuration update;
      5. identification; and
      6. network slice-specific authentication and authorization;
    2. Initiated by the UE:
      UE-initiated NAS transport.
    3. Initiated by the UE or the network and used to report certain error conditions detected upon receipt of 5GMM protocol data:
      5GMM status.
  2. 5GMM specific procedures:
    At any time only one UE initiated 5GMM specific procedure can be running for each of the access network(s) that the UE is camping in. The procedures belonging to this type are:
    1. Initiated by the UE and used e.g. to register to the network for 5GS services and establish a 5GMM context, to update the location/parameter(s) of the UE:
      registration.
    2. Initiated by the UE or the network and used to deregister from the network for 5GS services and to release a 5GMM context:
      de-registration.
    3. Initiated by the UE and used to deregister from the network for 5GS services and to release a 5GMM context:
      eCall inactivity procedure.
  3. 5GMM connection management procedures:
    1. Initiated by the UE and used to establish a secure connection to the network or to request the resource reservation for sending data, or both:
      service request.
      The service request procedure can only be initiated if no UE initiated 5GMM specific procedure is ongoing for each of the access network(s) that the UE is camping in.
    2. Initiated by the network and used to request the establishment of an N1 NAS signalling connection or to request re-establishment of user-plane resources for the PDU session(s) associated with 3GPP access or to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access; not applicable for the non-3GPP access network:
      paging.
    3. Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access or to deliver 5GSM downlink signalling messages associated with non-3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over 3GPP access and in 5GMM-IDLE mode over non-3GPP access; or

      Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with 3GPP access over 3GPP access or to deliver downlink signalling associated with 3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over non-3GPP access, and when the UE is in 5GMM-IDLE mode over 3GPP access and not in MICO mode:
      notification.
NOTE 1: In NB-N1 mode, the UE NAS using 5GS services with control plane CIoT 5GS optimization can wait for the lower layers to complete the transmission of the previous UL NAS TRANSPORT messages carrying control plane user data before providing subsequent NAS messages. Other implementations are possible.
NOTE 2: When providing NAS messages to the lower layers for transmission, the UE NAS using 5GS services with control plane CIoT 5GS optimization can prioritize sending NAS signalling messages over the UL NAS TRANSPORT messages carrying control plane user data. How the UE performs this prioritization is implementation specific.

5.1.3 5GMM sublayer states

5.1.3.1 General

In the following subclauses, the 5GS mobility management (5GMM) sublayer of the UE and the network is described by means of different state machines. The 5GMM sublayer states is managed per access type independently, i.e. 3GPP access or non-3GPP access. In subclause 5.1.3.2, the states of the 5GMM sublayer are introduced.

5.1.3.2.1 5GMM sublayer states in the UE

See spec, lots of info...

5.1.3.2.2 5GS update status in the UE

In order to describe the detailed UE behaviour, the 5GS update (5U) status pertaining to a specific subscriber is defined.

If the UE is not operating in SNPN access operation mode (see 3GPP TS 23.501), the 5GS update status is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.

If the UE is operating in SNPN access operation mode, the 5GS update status for each SNPN whose SNPN identity is included in the "list of subscriber data" configured in the ME (see 3GPP TS 23.122) is stored in the non-volatile memory in the ME as described in annex C.

The 5GS update status value is changed only after the execution of a registration, network-initiated de-registration, 5GS based primary authentication and key agreement, service request, paging procedure or due to change in the current TAI which does not belong to the current registration area while T3346 is running.

5U1: UPDATED
The last registration attempt was successful.
5U2: NOT UPDATED
The last registration or service request attempt failed procedurally, e.g. no response or reject message was received from the AMF.
5U3: ROAMING NOT ALLOWED
The last registration, service request, or registration for mobility or periodic registration update attempt was correctly performed, but the answer from the AMF was negative (because of roaming or subscription restrictions).
5.1.3.2.3 5GMM sublayer states in the network side

There are four 5GMM sublayer states in the network side.

5GMM-DEREGISTERED
In the state 5GMM-DEREGISTERED, no 5GMM context has been established or the 5GMM context is marked as deregistered. The UE is deregistered. The network may answer to an initial registration procedure initiated by the UE. The network may also answer to a de-registration procedure initiated by the UE.
5GMM-COMMON-PROCEDURE-INITIATED
The network enters the state 5GMM-COMMON-PROCEDURE-INITIATED, after it has started a common 5GMM procedure and is waiting for a response from the UE.
5GMM-REGISTERED
In the state 5GMM-REGISTERED, a 5GMM context has been established. Additionally, one or more PDU session(s) may be established at the network.
5GMM-DEREGISTERED-INITIATED
The network enters the state 5GMM-DEREGISTERED-INITIATED after it has started a de-registration procedure and is waiting for a response from the UE.

5.1.4 Coordination between 5GMM and EMM

5.1.4.1 General

If both 5GMM and EMM are enabled, a UE, operating in single-registration mode, shall maintain one common registration for 5GMM for 3GPP access and EMM.

Coordination between 5GMM for 3GPP access and EMM for a UE, which is capable of N1 mode and S1 mode and operates in dual-registration mode, is not needed, except as specified in subclause 4.8.3.

The coordination between 5GMM for 3GPP access and EMM in subclauses 5.1.4.2 and 5.1.4.3 only applies to the UEs operating in single-registration mode.

Regarding the coordination of "SIM/USIM considered invalid" and "USIM considered invalid for 5GS services" between the various mobility management entities see subclause 5.1.5.

5.1.4.2 Coordination between 5GMM for 3GPP access and EMM with N26 interface

N26 interface
N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core.

A UE that is not registered shall be in state EMM-DEREGISTERED and state 5GMM-DEREGISTERED for 3GPP access.

In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter (see 3GPP TS 24.301).

At inter-system change from S1 mode to N1 mode, the UE shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP accessand EMM-REGISTERED.NO-CELL-AVAILABLE and initiate a registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).

In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter or tracking area updating attempt counter (see 3GPP TS 24.301).

At inter-system change from N1 mode to S1 mode when there is no active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, and EMM-REGISTERED without PDN connection is not supported by the UE or the MME, the UE shall enter state 5GMM-DEREGISTERED for 3GPP access and state EMM-DEREGISTERED and then initiate the EPS attach procedure. If EMM-REGISTERED without PDN connection is supported by the UE and the MME, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure.

At inter-system change from N1 mode to S1 mode when there is at least one active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure (see 3GPP TS 24.301).

5.1.4.3 Coordination between 5GMM for 3GPP access and EMM without N26 interface

A UE operating in the single-registration mode that is not registered over 3GPP access shall be in state EMM-DEREGISTERED and in state 5GMM-DEREGISTERED for 3GPP access.

In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE.

At inter-system change from N1 mode to S1 mode in 5GMM-IDLE mode, the UE shall behave as specified in subclause 4.8.2.3.

In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE.

At inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, the UE operating in the single-registration mode shall enter substates EMM-REGISTERED.NO-CELL-AVAILABLE and 5GMM- REGISTERED.NORMAL-SERVICE for 3GPP access and then initiate the registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).

5.1.5 Coordination between 5GMM and GMM

Coordination between 5GMM and GMM states is not required.

Regardless whether the UE is operating in single-registration mode or dual-registration mode,

  • if the UE considers the SIM/USIM invalid for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the SIM/USIM invalid for all of them; and
  • if the UE considers the USIM invalid for 5GS services for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the USIM invalid for 5GS services for all of them.

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:

  1. REGISTRATION REQUEST message;
  2. DEREGISTRATION REQUEST message;
  3. SERVICE REQUEST message; and
  4. CONTROL PLANE SERVICE REQUEST.

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, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.

For the routing of the initial NAS message to the appropriate AMF, if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules...see spec

5.2 Behaviour of the UE in state 5GMM-DEREGISTERED and state 5GMM-REGISTERED

5.3 General on elementary 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 NAS message, the UE shall request the lower layer to establish an 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:

  1. REGISTRATION REQUEST message;
  2. DEREGISTRATION REQUEST message;
  3. SERVICE REQUEST message; and
  4. CONTROL PLANE SERVICE REQUEST.

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, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.

For the routing of the initial NAS message to the appropriate AMF, if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules:

  1. if the registration procedure for mobility and periodic update was triggered due to the last CONFIGURATION UPDATE COMMAND message containing the Configuration update indication IE with the Registration bit set to "registration requested" and including:
    1. no other parameters;
    2. one or both of the Allowed NSSAI IE and the Configured NSSAI IE; or
    3. the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed";
    the UE NAS shall not provide the lower layers with the 5G-S-TMSI or the registered GUAMI;
  2. if the service request procedure was initiated over non-3GPP access, the UE NAS shall provide the lower layers with the registered GUAMI, but shall not provide the lower layers with the 5G-S-TMSI;
  3. if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over untrusted non-3GPP access, the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI; if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over trusted non-3GPP access, the UE NAS shall provide the lower layers with the 5G-GUTI, if available, otherwise shall provide the lower layers with the SUCI; if the UE is the 5G-RG and the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over wireline access, the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, if available, otherwise shall not provide the lower layers with any UE identity;
  4. if the UE does not hold a 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration procedure and if:
    1. the UE operating in the single-registration mode performs a registration procedure for mobility and periodic update indicating "mobility registration updating" following an inter-system change from S1 mode to N1 mode; or
    2. the UE which was previously registered in S1 mode before entering state EMM-DEREGISTERED, performs an initial registration procedure, the UE has received the interworking without N26 interface indicator set to "interworking without N26 interface not supported" from the network, and the UE holds a 4G-GUTI;
    then the UE NAS provides the lower layers with a GUAMI part of the 5G-GUTI mapped from 4G-GUTI as specified in 3GPP TS 23.003 with an indication that the GUAMI is mapped from EPS; or
  5. otherwise:
    1. if the tracking area of the current cell is in the registration area, the UE NAS shall provide the lower layers with the 5G-S-TMSI, but shall not provide the registered GUAMI to the lower layers; or
    2. if the tracking area of the current cell is not in the registration area, the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclauses 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI.


For 3GPP access and untrusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, the UE NAS does not provide the lower layers with the 5G-S-TMSI or the registered GUAMI. For trusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, the UE NAS provides the lower layers with the SUCI.

The UE NAS also provides the lower layers with the identity of the selected PLMN (see 3GPP TS 38.331) if the UE is not operating in SNPN access operation mode. If the UE is operating in SNPN access operation mode, the UE NAS provides the lower layers with the SNPN identity of the selected SNPN. In a shared network, the UE shall choose one of the PLMN identity(ies) or SNPN identity(ies) as specified in 3GPP TS 23.122.

The UE NAS layer may provide the lower layers with an NSSAI as specified in subclause 4.6.2.3.

If the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the UE NAS layer shall provide the lower layers with an indication that the connection is for onboarding.

5.3.1.2 Re-establishment of the N1 NAS signalling connection

When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, the UE shall:

  1. enter 5GMM-IDLE mode; and
  2. initiate the registration procedure for mobility and periodic registration update and include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.5.1.3 for further details).

When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has pending uplink user data for PDU session(s) with user-plane resources already established but no pending NAS procedure, the UE shall:

  1. enter 5GMM-IDLE mode; and
  2. initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication (see subclause 5.6.1 for further details).

When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending registration procedure, a service request procedure, or a de-registration procedure, the UE shall:

  1. enter 5GMM-IDLE mode;
  2. proceed with the pending procedure; and
  3. if the pending procedure is a service request or registration procedure and the SERVICE REQUEST message, the CONTROL PLANE SERVICE REQUEST message or the REGISTRATION REQUEST message does not include UE request type IE with Request type value set to "NAS signalling connection release", the UE shall include the Uplink data status IE in the SERVICE REQUEST message, or in the REGISTRATION REQUEST message, indicating the PDU session(s) for which user-plane resources were not active prior to receiving a fallback indication from the lower layers and the UE has pending user data to be sent over 3GPP access, if any, and the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclauses 5.5.1.3 and 5.6.1 for further details).

When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending NAS procedure other than a registration procedure, a service request procedure, or a de-registration procedure, the UE shall:

  1. enter 5GMM-IDLE mode;
  2. initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details); and
  3. upon successful service request procedure completion, proceed with any pending procedure.

When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, and the UE was using network resources for ProSe direct discovery over PC5 or ProSe direct communication over PC5 (see 3GPP TS 23.304), the UE shall:

  1. enter 5GMM-IDLE mode; and
  2. initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details).

The cases above apply when the UE is in an allowed area or when the UE is not in a non-allowed area.

When the UE:

  1. is in a non-allowed area or is not in an allowed area;
  2. is in 5GMM-CONNECTED mode over 3GPP access;
  3. receives a fallback indication from lower layers; and
  4. does not have signalling pending,

the UE shall:

  1. enter 5GMM-IDLE mode; and
  2. initiate the registration procedure for mobility and periodic registration update. The UE shall not include the Uplink data status IE in the REGISTRATION REQUEST message except if the PDU session for which user-plane resources were active is an emergency PDU session, or if the UE is configured for high priority access in the selected PLMN.

In the above cases when the UE receives a fallback indication from lower layers, if the UE is in non-allowed area or not in allowed area, the UE shall behave as specified in subclause 5.3.5.

5.3.1.3 Release of the N1 NAS signalling connection

See spec for details...

5.3.1.4 5GMM-CONNECTED mode with RRC inactive indication

See spec for details...

5.3.1.5 Suspend and resume of the N1 NAS signalling connection

See spec for details...

5.3.2 Permanent identifiers

A globally unique permanent identity, the 5G subscription permanent identifier (SUPI), is allocated to each subscriber for 5GS-based services. The IMSI, the network specific identifier, the GCI and the GLI are valid SUPI types. When the SUPI contains a network specific identifier, a GCI or a GLI, it shall take the form of a network access identifier (NAI). When the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the SUPI contains the onboarding SUPI derived from the default UE credentials for primary authentication. The UE derives the onboarding SUPI before or during the initial registration for onboarding services in SNPN and uses the derived onboarding SUPI in the initial registration for onboarding services in SNPN and while registered for onboarding services in SNPN.

The structure of the SUPI and its derivatives are specified in 3GPP TS 23.003. See My 3GPP TS 23.003 notes

The UE provides the SUPI to the network in concealed form. The SUCI is a privacy preserving identifier containing the concealed SUPI. When the SUPI contains a network specific identifier, a GCI or a GLI, the SUCI shall take the form of a NAI as specified in 3GPP TS 23.003.

A UE supporting N1 mode includes a SUCI:

  1. in the REGISTRATION REQUEST message when the UE is attempting initial registration procedure and a valid 5G-GUTI is not available;
  2. in the IDENTITY RESPONSE message, if the SUCI is requested by the network during the identification procedure; and
  3. in the DEREGISTRATION REQUEST message when the UE initiates a de-registration procedure and a valid 5G-GUTI is not available.

If the UE uses the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI, the SUCI contains the unconcealed SUPI.

When:

  • not operating in SNPN access operation mode; or
  • operating in SNPN access operation mode but not performing initial registration for onboarding services and not registered for onboarding services;

the UE shall use the "null-scheme" if:

  1. the home network has not provisioned the public key needed to generate a SUCI;
  2. the home network has configured "null-scheme" to be used for the UE;
  3. the UE needs to perform a registration procedure for emergency services after the failure of authentication procedure or after reception of a REGISTRATION REJECT message with the 5GMM cause #3 "Illegal UE", or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully, and the UE does not have a valid 5G-GUTI for the selected PLMN; or
  4. the UE receives an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully.

When operating in SNPN access operation mode and:

  • performing initial registration for onboarding services; or
  • registered for onboarding services;

the UE shall use the "null-scheme" if:

  1. the public key needed to generate a SUCI is not configured as part of the default UE credentials for primary authentication; or
  2. "null-scheme" usage is configured as part of the default UE credentials.

If:

  1. the UE uses the "null-scheme" as specified in 3GPP TS 33.501 [24] to generate a SUCI;
  2. the UE operates in SNPN access operation mode and:
    1. an indication to use anonymous SUCI which is associated with the selected entry of the "list of subscriber data", is configured in the ME, if the UE is not registering or registered for onboarding services in SNPN; or
    2. an indication to use anonymous SUCI which is associated with the default UE credentials, is configured in the ME, if the UE is registering or registered for onboarding services in SNPN;
    NOTE 1: The ME can be configured with an indication to use anonymous SUCI associated with an entry of "list of subscriber data" when the EAP method associated with the credentials of the entry supports SUPI privacy at the EAP layer, or can be configured with an indication to use anonymous SUCI associated with the default UE credentials when the EAP method associated with the default UE credentials supports SUPI privacy at the EAP layer, or both.

    Editor's note: (WI eNPN, CR 4139) it is FFS whether another UE-level configuration for usage of anonymous SUCI is needed.
  3. the UE does not need to perform a registration procedure for emergency services, or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully; and
  4. the UE does not receive an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully;

then the UE shall use anonymous SUCI as specified in 3GPP TS 23.003.

A W-AGF acting on behalf of an FN-RG shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.

A W-AGF acting on behalf of an N5GC device shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.

If a UE is a MUSIM UE, the UE shall use a separate permanent equipment identifier (PEI) for each USIM, if any, and each entry of "list of subscriber data", if any, the UE operates for accessing 5GS-based services; otherwise, a UE contains and uses a permanent equipment identifier (PEI) for accessing 5GS-based services. When the UE is registered with a network by using a PEI, the UE shall not use that PEI to register with another network until the UE is de-registered from the network.

In this release of the specification, the IMEI, the IMEISV, the MAC address together with the MAC address usage restriction indication and the EUI-64 are the only PEI formats supported by 5GS. The structure of the PEI and its formats are specified in 3GPP TS 23.003.

Each UE supporting at least one 3GPP access technology (i.e. satellite NG-RAN, NG-RAN, E-UTRAN, UTRAN or GERAN) contains a PEI in the IMEI format and shall be able to provide an IMEI and an IMEISV upon request from the network.

Each UE not supporting any 3GPP access technologies and supporting NAS over untrusted or trusted non-3GPP access shall have a PEI in the form of the Extended Unique Identifier EUI-64 of the access technology the UE uses to connect to the 5GC.

A UE supporting N1 mode includes a PEI:

  1. when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";
  2. when the network requests the PEI by using the identification procedure, in the IDENTITY RESPONSE message; and
  3. when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.

Each 5G-RG supporting only wireline access and each FN-RG shall have a permanent MAC address configured by the manufacturer. For 5G-CRG, the permanent MAC address configured by the manufacturer shall be a cable modem MAC address.

When the 5G-RG contains neither an IMEI nor an IMEISV, the 5G-RG shall use as a PEI the 5G-RG's permanent MAC address configured by the manufacturer and the MAC address usage restriction indication set to "no restrictions".

The Wireless Access Gateway Function (W-AGF) acting on behalf of the Fixed Network Residential Gateway (FN-RG) shall use as a PEI the MAC address provided by the FN-RG and if the MAC address provided by the FN-RG is not unique or does not correspond to the FN-RG's permanent MAC address according to W-AGF's configuration, the MAC address usage restriction indication set to "MAC address is not usable as an equipment identifier" otherwise the MAC address usage restriction indication set to "no restrictions".

The 5G-RG containing neither an IMEI nor an IMEISV shall include the PEI containing the MAC address together with the MAC address usage restriction indication:

  1. when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";
  2. when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and
  3. when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.
NOTE 2: In case c) above, the MAC address is provided even though AMF requests the IMEISV.

The W-AGF acting on behalf of the FN-RG shall include the PEI containing the MAC address together with the MAC address usage restriction indication:

  1. when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and
  2. when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.
NOTE 3: In case b) above, the MAC address is provided even though AMF requests the IMEISV.

The W-AGF acting on behalf of the N5GC device shall use as a PEI the MAC address provided by the N5GC device and the MAC address usage restriction indication set to "no restrictions". Based on operator policy, the W-AGF acting on behalf of the N5GC device may encode the MAC address of the N5GC device using the EUI-64 format as specified in IEEE "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" and use as a PEI the derived EUI-64.

NOTE 4: The MAC address of an N5GC device is universally/globally unique.

The AMF can request the PEI at any time by using the identification procedure.

5.3.3 Temporary identities

A temporary user identity for 5GS-based services, the 5G globally unique temporary identity (5G-GUTI), is used for identification within the signalling procedures. In case of PLMN the 5G-GUTI is globally unique and in case of Standalone Non-Public Network (SNPN) the 5G-GUTI is unique within an SNPN. When the UE is registered to the same PLMN or SNPN over 3GPP and non-3GPP access, the UE and the AMF maintain one 5G-GUTI that is common to both 3GPP and non-3GPP access. When the UE is required to delete the 5G-GUTI according to a NAS procedure, the UE shall delete the 5G-GUTI only if it is not registered to the same PLMN or SNPN through other access. When the UE is registered to different PLMNs or SNPNs over 3GPP access and non-3GPP access, the UE maintains two 5G-GUTIs, a 5G-GUTI for the registration with a PLMN or SNPN over the 3GPP access and another 5G-GUTI for the registration with another PLMN or SNPN over the non-3GPP access. In the paging and service request procedures, a shortened form of the 5G-GUTI, the 5G S-temporary mobile subscriber identity (5G-S-TMSI), is used to enable more efficient radio signalling. The purpose of the 5G-GUTI and 5G-S-TMSI is to provide identity confidentiality, i.e., to protect a user from being identified and located by an intruder. The structure of the 5G-GUTI and its derivatives are specified in 3GPP TS 23.003. The 5G-GUTI has two main components (see 3GPP TS 23.501):

  1. the GUAMI; and
  2. the 5G-TMSI that provides an unambiguous identity of the UE within the AMF(s) identified by the GUAMI.
NOTE: The UE registered with an SNPN over non-3GPP access refers to the UE accessing SNPN services via a PLMN.

The 5G-S-TMSI has three main components:

  1. the AMF set ID that uniquely identifies the AMF set within the AMF region;
  2. the AMF pointer that identifies one or more AMFs within the AMF set; and
  3. the 5G-TMSI.

A UE supporting N1 mode includes a valid 5G-GUTI, if any is available, in the REGISTRATION REQUEST and DEREGISTRATION REQUEST messages. In the SERVICE REQUEST message, the UE includes a valid 5G-S-TMSI as user identity. The AMF shall assign a new 5G-GUTI for a particular UE:

  1. during a successful initial registration procedure;
  2. during a successful registration procedure for mobility registration update;
  3. after a successful service request procedure invoked as a response to a paging request from the network and before the:
    1. release of the N1 NAS signalling connection; or
    2. suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;
    as specified in subclause 5.4.4.1; and
  4. after the AMF receives an indication from the lower layers that it has received the NGAP UE context resume request message as specified in 3GPP TS 38.413 for a UE in 5GMM-IDLE mode with suspend indication and this resumption is a response to a paging request from the network, and before the:
    1. release of the N1 NAS signalling connection; or
    2. suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;
    as specified in subclause 5.4.4.1.

The AMF should assign a new 5G-GUTI for a particular UE during a successful registration procedure for periodic registration update. The AMF may assign a new 5G-GUTI at any time for a particular UE by performing the generic UE configuration update procedure.

If a new 5G-GUTI is assigned by the AMF, the UE and the AMF handle the 5G-GUTI as follows:

  1. Upon receipt of a 5GMM message containing a new 5G-GUTI, the UE considers the new 5G-GUTI as valid and the old 5G-GUTI as invalid, stops timer T3519 if running, and deletes any stored SUCI. The new 5G-GUTI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.
  2. The AMF considers the old 5G-GUTI as invalid as soon as an acknowledgement for a registration or generic UE configuration update procedure is received.

5.3.4 Registration areas

Within the 5GS, the registration area is managed independently per access type, i.e., 3GPP access or non-3GPP access. The AMF assigns a registration area to the UE during the registration procedure. A registration area is defined as a set of tracking areas and each of these tracking areas consists of one or more cells that cover a geographical area. Within the 5GS, the concept of "registration to multiple tracking areas" applies:

  1. A tracking area is identified by a TAI which is broadcast in the cells of the tracking area. The TAI is constructed from a TAC and a PLMN identity. In case of a shared network:
    1. one or more TACs; and
    2. any of the following:
      1. multiple PLMN identities;
      2. multiple SNPN identities; or
      3. one or more PLMN identities and one or more SNPN identities; are broadcast.
  2. In order to reduce the tracking area update signalling within the 5GS, the AMF can assign several tracking areas to the UE. These tracking areas construct a list of tracking areas which is identified by a TAI list. When generating the TAI list, the AMF shall include only TAIs that are applicable on the access where the TAI list is sent. The AMF shall be able to allocate a TAI list over different NG-RAN access technologies. The AMF shall not allocate a TAI list containing both tracking areas in NB-N1 mode and tracking areas not in NB-N1 mode.
  3. The UE considers itself registered to a list of tracking areas and does not need to trigger the registration procedure for mobility and periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) as long as the UE stays in one of the tracking areas of the list of tracking areas received from the AMF.
  4. The UE will consider the TAI list as valid, until it receives a new TAI list in the next registration procedure for mobility and periodic registration update or generic UE configuration update procedure, or the UE is commanded by the network to delete the TAI list by a reject message or it is deregistered from the 5GS. If the registration request is accepted or the TAI list is reallocated by the AMF, the AMF shall provide at least one entry in the TAI list. If the new and the old TAI list are identical, the AMF does not need to provide the new TAI list to the UE during mobility registration update or periodic registration update.
  5. The TAI list can be reallocated by the AMF.
  6. When the UE is deregistered from the 5GS, the TAI list in the UE is invalid.
  7. The UE includes the last visited registered TAI, if available, to the AMF. The last visited registered TAI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.

5.3.5 Service area restrictions

5.3.5.1 General

Service area restrictions are applicable only to 3GPP access and to wireline access.

Subclause 5.3.5.2 applies when the UE accesses 5GCN over 3GPP access.

Subclause 5.3.5.3 applies when the 5G-RG or the W-AGF acting on behalf of an FN-CRG (or on behalf of the N5GC device) access 5GCN over wireline access.

NOTE: Service area restrictions are not applicable for the W-AGF acting on behalf of the FN-BRG.

5.3.5.2 3GPP access service area restrictions

The service area restrictions consist of tracking areas forming either an allowed area, or a non-allowed area. The tracking areas belong to either the registered PLMN or its equivalent PLMNs in the registration area. The allowed area can contain up to 16 tracking areas or include all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area. The non-allowed area can contain up to 16 tracking areas. The network conveys the service area restrictions to the UE by including either an allowed area, or a non-allowed area, but not both, in the Service area list IE of a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message.

If the network does not convey the service area restrictions to the UE in the Service area list IE of a REGISTRATION ACCEPT message, the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".

When the UE receives a Service area list IE with an allowed area indication during a registration procedure or a generic UE configuration update procedure:

  1. if the "Type of list" included in the Service area list IE does not indicate "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall delete the old list of "allowed tracking areas" and store the tracking areas in the allowed area as the list of "allowed tracking areas". If the UE has a stored list of "non-allowed tracking areas", the UE shall delete that list; or
  2. if the "Type of list" included in the Service area list IE indicates "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".

When the UE receives a Service area list IE with a non-allowed area indication during a registration procedure or a generic UE configuration update procedure, the UE shall delete the old list of "non-allowed tracking areas" and store the tracking areas in the non-allowed area as the list of "non-allowed tracking areas". If the UE has a stored list of "allowed tracking areas", the UE shall delete that list.

If the UE is successfully registered to a PLMN and has a stored list of "allowed tracking areas":

See spec for details...

5.3.6 Mobile initiated connection only (MICO) mode

5.3.7 Handling of the periodic registration update timer and mobile reachable timer

The periodic registration update procedure is used over 3GPP access to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic registration update timer, T3512.

If the UE is registered over the 3GPP access, the AMF maintains an implicit de-registration timer to control when the UE is considered implicitly de-registered over the 3GPP access. If the UE is registered over the non-3GPP access, the AMF also maintains a non-3GPP implicit de-registration timer to control when the UE is considered implicitly de-registered over the non-3GPP access. The UE registered over the non-3GPP access maintains a non-3GPP de-registration timer to control when the UE is considered implicitly de-registered for the non-3GPP access.

The AMF shall start a non-3GPP implicit de-registration timer for the UE registered over non-3GPP access when the N1 NAS signalling connection over non-3GPP access is released.

The UE registered over non-3GPP access shall reset and start a non-3GPP de-registration timer when the N1 NAS signalling connection over non-3GPP access is released. The non-3GPP de-registration timer is stopped when the UE enters 5GMM-CONNECTED mode over non-3GPP access or the 5GMM-DEREGISTERED state over non-3GPP access.

The non-3GPP implicit de-registration timer shall be longer than the non-3GPP de-registration timer.

The value of timer T3512 is sent by the network to the UE in the REGISTRATION ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE until a new value is received. The periodic registration update timer only applies to the UE registered to the 5GS services over 3GPP access.

If timer T3512 received by the UE in a REGISTRATION ACCEPT message contains an indication that the timer is deactivated or the timer value is zero, then timer T3512 is deactivated and the UE shall not perform the periodic registration update procedure.

NOTE 1: The UE does not perform the periodic registration update procedure for non-3GPP access.

If during the registration procedure, the AMF does not indicate "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is reset and started with its initial value, when the UE changes from 5GMM-CONNECTED over 3GPP access to 5GMM-IDLE mode over 3GPP access. Timer T3512 is stopped when the UE enters 5GMM-CONNECTED mode over 3GPP access or the 5GMM-DEREGISTERED state over 3GPP access.

If during the registration procedure, the AMF indicates "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is started with its initial value after the completion of the registration procedure. The UE shall neither stop nor reset the timer T3512 when the UE enters 5GMM-CONNECTED or when changing from 5GMM-CONNECTED mode to 5GMM-IDLE mode. If the timer T3512 expires,

  1. the UE in 5GMM-CONNECTED mode over 3GPP access shall reset and start the timer T3512 with its initial value; or
  2. the UE in 5GMM-IDLE mode over 3GPP access shall perform the periodic registration procedure.

If the UE is registered for emergency services, and timer T3512 expires, the UE shall not initiate a periodic registration update procedure, but shall locally de-register from the network. When the UE is camping on a suitable cell, it may re-register to regain normal service.

When a UE is not registered for emergency services, and timer T3512 expires when the UE is in 5GMM-IDLE mode, the periodic registration update procedure shall be started.

If the UE is not registered for emergency services, and is in a state other than 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access when timer T3512 expires, the periodic registration update procedure is delayed until the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access.

NOTE 2: When the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE and it needs to initiate other 5GMM procedure than the periodic registration update procedure then, based on UE implementation, the 5GMM procedure can take precedence.

The network supervises the periodic registration update procedure of the UE by means of the mobile reachable timer.

If the UE is not registered for emergency services, the mobile reachable timer shall be longer than the value of timer T3512. In this case, by default, the mobile reachable timer is 4 minutes greater than the value of timer T3512.

The network behaviour upon expiry of the mobile reachable timer is network dependent, but typically the network stops sending paging messages to the UE on the first expiry, and may take other appropriate actions.

If the UE is registered for emergency services, the AMF shall set the mobile reachable timer with a value equal to timer T3512. When the mobile reachable timer expires, the AMF shall locally de-register the UE.

The mobile reachable timer shall be reset and started with the value as indicated above, when the AMF releases the NAS signalling connection for the UE. The mobile reachable timer shall be stopped when a NAS signalling connection is established for the UE.

Upon expiry of the mobile reachable timer the network shall start the implicit de-registration timer over 3GPP access. The value of the implicit de-registration timer over 3GPP access is network dependent. If MICO mode is activated, the network shall start the implicit de-registration timer over 3GPP access when the UE enters 5GMM-IDLE mode at the AMF over 3GPP access. The default value of the implicit de-registration timer over 3GPP access is 4 minutes greater than the value of timer T3512.

If the implicit de-registration timer expires before the UE contacts the network, the network shall implicitly de-register the UE. The implicit de-registration timer shall be stopped when a NAS signalling connection is established for the UE.

If the non-3GPP implicit de-registration timer expires before the UE contacts the network over the non-3GPP access, the network shall implicitly de-register the UE and enter the state 5GMM-DEREGISTERED over non-3GPP access for the UE. The non-3GPP implicit de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.

If the non-3GPP de-registration timer expires before the UE contacts the network over the non-3GPP access, the UE shall enter the state 5GMM-DEREGISTERED over non-3GPP access. The non-3GPP de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.

If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "Non-3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of timer T3512, the AMF sets the mobile reachable timer and the implicit de-registration timer such that the sum of the timer values is greater than the value of timer T3346.

If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the AMF sets the non-3GPP implicit de-registration timer value to be 8 minutes greater than the value of timer T3346.

If the UE receives T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the UE sets the non-3GPP de-registration timer value to be 4 minutes greater than the value of timer T3346.

5.3.9 Handling of NAS level mobility management congestion control

5.4 5GMM common procedures

5.4.2 Security mode control (SMC) procedure

5.4.2.1 General

The purpose of the NAS security mode control procedure is to take a 5G NAS security context into use, and initialise and start NAS signalling security between the UE and the AMF with the corresponding 5G NAS keys and 5G NAS security algorithms.

See spec for details...

5.4.3 Identification procedure

5.4.3.1 General

The purpose of this procedure is to request a particular UE to provide specific identification parameters, e.g. the SUCI, the IMEI, the IMEISV, the EUI-64 or the MAC address. The SUCI is a privacy preserving identifier containing the concealed SUPI and the IMEI, the IMEISV, the EUI-64 and the MAC address are formats of PEI.

See spec for details...

5.5 5GMM specific procedures

5.5.1 Registration procedure

5.5.1.1 General

The registration procedure is always initiated by the UE and used for initial registration as specified in subclause 5.5.1.2.2 or mobility and periodic registration update as specified in subclause 5.5.1.3.2.

When the UE needs to initiate registration over both 3GPP access and non-3GPP access in the same PLMN (e.g. the 3GPP access and the selected N3IWF are located in the same PLMN), the UE:

  1. in 5GMM-REGISTERED-INITIATED over 3GPP access shall not initiate registration over non-3GPP access; or
  2. in 5GMM-REGISTERED-INITIATED over non-3GPP access shall not initiate registration over 3GPP access.
  3. NOTE 1: To which access (i.e. 3GPP access or non-3GPP access) the UE initiates registration first is up to UE implementation.

When the UE is registered with a PLMN over a non-3GPP access, the AMF and the UE maintain:

  1. registration state and state machine over non-3GPP access;
  2. 5G NAS security context;
  3. 5G-GUTI;
  4. registration area for non-3GPP access, which is associated with a single TAI; and
  5. non-3GPP de-registration timer in the UE and non-3GPP implicit de-registration timer in the AMF.

A registration attempt counter is used to limit the number of subsequently rejected registration attempts. The registration attempt counter shall be incremented as specified in subclause 5.5.1.2.7 or subclause 5.5.1.3.7. Depending on the value of the registration attempt counter, specific actions shall be performed. The registration attempt counter shall be reset when:

  • the UE is powered on;
  • a USIM is inserted;
  • a registration procedure is successfully completed;
  • an EPS attach or combined EPS attach procedure is successfully completed in S1 mode and the UE is operating in single-registration mode. In this case, the UE shall reset the registration attempt counter for 3GPP access;
NOTE 2: The registration attempt counter for non-3GPP access is not impacted by the EPS attach and the combined EPS attach procedure.
  • a registration procedure is rejected with cause #11, #12, #13, #15, #27, #31, #62, #72, #73, #74, #75, #76, #77 or #78;
  • a registration procedure is rejected with cause #3, #6 or #7, the REGISTRATION REJECT message is received without integrity protection and the counter for "SIM/USIM considered invalid for GPRS services" events has a value less than a UE implementation-specific maximum value.
  • a network initiated deregistration procedure is completed with cause #11, #12, #13, #15, #27; #62, #72, #74, #75, #76, #77 or #78; or
  • a new PLMN or SNPN is selected.

Additionally, the registration attempt counter shall be reset when the UE is in substate 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION or 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE, and:

  • the current TAI is changed;
  • timer T3502 expires; or
  • timer T3346 is started.

When the registration attempt counter is reset, the UE shall stop timer T3519 if running, and delete any stored SUCI.

The lower layers indicate to NAS whether the network supports emergency services for the UE in limited service state (see 3GPP TS 38.331). This information is taken into account when deciding whether to initiate an initial registration for emergency services.

5.5.1.2 Registration procedure for initial registration

5.5.1.2.1 General

This procedure can be used by a UE for initial registration for 5GS services.

When the UE initiates the registration procedure for initial registration, the UE shall indicate "initial registration" in the 5GS registration type IE. When the UE initiates the registration procedure for emergency services, the UE shall indicate "emergency registration" in the 5GS registration type IE. When the UE initiates the initial registration for onboarding services in SNPN, the UE shall indicate "SNPN onboarding registration" in the 5GS registration type IE. When the UE initiates the initial registration procedure for disaster roaming services, the UE shall indicate "disaster roaming initial registration" in the 5GS registration type IE.

If the MUSIM UE initiates the registration procedure for initial registration and indicates "emergency registration" in the 5GS registration type IE in the REGISTRATION REQUEST message, the network shall not indicate the support of:

  • the N1 NAS signalling connection release;
  • the paging indication for voice services;
  • the reject paging request; or
  • the paging restriction;

in the REGISTRATION ACCEPT message.

5.5.1.2.2 Initial registration initiation

The UE in state 5GMM-DEREGISTERED shall initiate the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF,

  1. when the UE performs initial registration for 5GS services;
  2. when the UE performs initial registration for emergency services;
  3. when the UE performs initial registration for SMS over NAS;
  4. when the UE moves from GERAN to NG-RAN coverage or the UE moves from a UTRAN to NG-RAN coverage and the following applies:
    1. the UE initiated a GPRS attach or routing area updating procedure while in A/Gb mode or Iu mode; or
    2. the UE has performed 5G-SRVCC from NG-RAN to UTRAN as specified in 3GPP TS 23.216,
    and since then the UE did not perform a successful EPS attach or tracking area updating procedure in S1 mode or registration procedure in N1 mode;
  5. when the UE performs initial registration for onboarding services in SNPN; and
  6. when the UE performs initial registration for disaster roaming services;

with the following clarifications to initial registration for emergency services:

  1. the UE shall not initiate an initial registration for emergency services over the current access, if the UE is already registered for emergency services over the non-current access, unless the initial registration has to be initiated to perform handover of an existing emergency PDU session from the non-current access to the current access; and
  2. NOTE 1: Transfer of an existing emergency PDU session between 3GPP access and non-3GPP access is needed e.g. if the UE determines that the current access is no longer available.
  3. the UE can only initiate an initial registration for emergency services over non-3GPP access if it cannot register for emergency services over 3GPP access.

The UE initiates the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF, starting timer T3510. If timer T3502 is currently running, the UE shall stop timer T3502. If timer T3511 is currently running, the UE shall stop timer T3511.

During initial registration the UE handles the 5GS mobile identity IE in the following order:

  1. if:
    1. the UE:
      1. was previously registered in S1 mode before entering state EMM-DEREGISTERED; and
      2. has received an "interworking without N26 interface not supported" indication from the network; and
    2. EPS security context and a valid native 4G-GUTI are available;

    then the UE shall create a 5G-GUTI mapped from the valid native 4G-GUTI as specified in 3GPP TS 23.003 and indicate the mapped 5G-GUTI in the 5GS mobile identity IE. The UE shall include the UE status IE with the EMM registration status set to "UE is not in EMM-REGISTERED state" and shall include an ATTACH REQUEST message as specified in 3GPP TS 24.301 in the EPS NAS message container IE.

    Additionally, if the UE holds a valid 5G GUTI, the UE shall include the 5G-GUTI in the Additional GUTI IE in the REGISTRATION REQUEST message in the following order:

    1. a valid 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration, if available;
    2. a valid 5G-GUTI that was previously assigned by an equivalent PLMN, if available; and
    3. a valid 5G-GUTI that was previously assigned by any other PLMN, if available;
  2. if:
    1. the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same PLMN with which the UE is performing the registration, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or
    2. the UE is registering with a SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same SNPN with which the UE is performing the registration, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;
  3. if the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by an equivalent PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;
  4. if:
    1. the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or
    2. the UE is registering with an SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other SNPN, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE and shall additionally include the NID of the other SNPN in the NID IE;
  5. if a SUCI other than an onboarding SUCI is available, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall include the SUCI other than an onboarding SUCI in the 5GS mobile identity IE;
  6. if the UE does not hold a valid 5G-GUTI or SUCI other than an onboarding SUCI, and is initiating the initial registration for emergency services, the PEI shall be included in the 5GS mobile identity IE; and
  7. if the UE is initiating the initial registration for onboarding services in SNPN, an onboarding SUCI shall be included in the 5GS mobile identity IE.
NOTE 2: The AMF in ON-SNPN uses the onboarding SUCI as specified in 3GPP TS 23.501.

If the SUCI is included in the 5GS mobile identity IE and the timer T3519 is not running, the UE shall start timer T3519 and store the value of the SUCI sent in the REGISTRATION REQUEST message. The UE shall include the stored SUCI in the REGISTRATION REQUEST message while timer T3519 is running.

If the UE is operating in the dual-registration mode and it is in EMM state EMM-REGISTERED, the UE shall include the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state".

NOTE 3: Inclusion of the UE status IE with this setting corresponds to the indication that the UE is "moving from EPC" as specified in 3GPP TS 23.502.
NOTE 4: The value of the 5GMM registration status included by the UE in the UE status IE is not used by the AMF.

If the last visited registered TAI is available, the UE shall include the last visited registered TAI in the REGISTRATION REQUEST message.

If the UE requests the use of SMS over NAS, the UE shall include the 5GS update type IE in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS supported". When the 5GS update type IE is included in the REGISTRATION REQUEST for reasons other than requesting the use of SMS over NAS, and the UE does not need to register for SMS over NAS, the UE shall set the SMS requested bit of the 5GS update type IE to "SMS over NAS not supported" in the REGISTRATION REQUEST message.

See spec for more info...

...

If the UE does not have a valid 5G NAS security context, the UE shall send the REGISTRATION REQUEST message without including the NAS message container IE. The UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs and non-cleartext IEs, if any) in the NAS message container IE that is sent as part of the SECURITY MODE COMPLETE message as described in subclauses 4.4.6 and 5.4.2.3.

If the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6. If the UE does not need to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message without including the NAS message container IE.


...

8.2 5GS mobility management messages

8.2.6 Registration Request

8.2.6.1 Message definition

The REGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.6.1.1.

Message type
REGISTRATION REQUEST
Significance
dual
Direction
UE to network
Table 8.2.6.1.1: REGISTRATION REQUEST message content
IEI Information Element Type/Reference Presence Format Length
Extended protocol discriminator Extended Protocol discriminator 9.2 M V 1
Security header type Security header type 9.3 M V 1/2
Spare half octet Spare half octet 9.5 M V 1/2
Registration request message identity Message type 9.7 M V 1
5GS registration type 5GS registration type 9.11.3.7 M V 1/2
ngKSI NAS key set identifier 9.11.3.32 M V 1/2
5GS mobile identity 5GS mobile identity 9.11.3.4 M LV-E 6-n
C- Non-current native NAS key set identifier NAS key set identifier 9.11.3.32 O TV 1
10 5GMM capability 5GMM capability 9.11.3.1 O TLV 3-15
2E UE security capability UE security capability 9.11.3.54 O TLV 4-10
2F Requested NSSAI NSSAI 9.11.3.37 O TLV 4-74
52 Last visited registered TAI 5GS tracking area identity 9.11.3.8 O TV 7
17 S1 UE network capability S1 UE network capability 9.11.3.48 O TLV 4-15
40 Uplink data status Uplink data status 9.11.3.57 O TLV 4-34
50 PDU session status PDU session status 9.11.3.44 O TLV 4-34
B- MICO indication MICO indication 9.11.3.31 O TV 1
2B UE status UE status 9.11.3.56 O TLV 3
77 Additional GUTI 5GS mobile identity 9.11.3.4 O TLV-E 14
25 Allowed PDU session status Allowed PDU session status 9.11.3.13 O TLV 4-34
18 UE's usage setting UE's usage setting 9.11.3.55 O TLV 3
51 Requested DRX parameters 5GS DRX parameters 9.11.3.2A O TLV 3
70 EPS NAS message container EPS NAS message container 9.11.3.24 O TLV-E 4-n
74 LADN indication LADN indication 9.11.3.29 O TLV-E 3-811
8- Payload container type Payload container type 9.11.3.40 O TV 1
7B Payload container Payload container 9.11.3.39 O TLV-E 4-65538
9- Network slicing indication Network slicing indication 9.11.3.36 O TV 1
53 5GS update type 5GS update type 9.11.3.9A O TLV 3
41 Mobile station classmark 2 Mobile station class mark 2 9.11.3.31C O TLV 5
42 Supported codecs Supported codec list 9.11.3.51A O TLV 5-n
71 NAS message container NAS message container 9.11.3.33 O TLV-E 4-n
60 EPS bearer context status EPS bearer context status 9.11.3.23A O TLV 4
6E Requested extended DRX parameters Extended DRX parameters 9.11.3.26A O TLV 3
6A T3324 value GPRS timer 3 9.11.2.5 O TLV 3
67 UE radio capability ID UE radio capability ID 9.11.3.68 O TLV 3-n
35 Requested mapped NSSAI Mapped NSSAI 9.11.3.31B O TLV 3-42
48 Additional information requested Additional information requested 9.11.3.12A O TLV 3
1A Requested WUS assistance information WUS assistance information 9.11.3.71 O TLV 3-n
A- N5GC indication N5GC indication 9.11.3.72 O TV 1
30 Requested NB-N1 mode DRX parameters NB-N1 mode DRX parameters 9.11.3.73 O TLV 3
29 UE request type UE request type 9.11.3.76 O TLV 3
28 Paging restriction Paging restriction 9.11.3.77 O TLV 3-35
72 Service-level-AA container Service-level-AA container 9.11.2.10 O TLV-E 6-n
32 NID NID 9.11.3.79 O TLV 8
16 MS determined PLMN with disaster condition PLMN identity 9.11.3.85 O TLV 5
2A Requested PEIPS assistance information PEIPS assistance information 9.11.3.80 O TLV 3-n

See spec for details of each message.

8.2.6.21 NAS message container

This IE shall be included if the UE is sending a REGISTRATION REQUEST message as an initial NAS message, the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs.

8.2.12 De-registration request (UE originating de-registration)

8.2.12.1 Message definition

The DEREGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.12.1.1.

Message type
DEREGISTRATION REQUEST
Significance
dual
Direction
UE to network

See spec for details...

8.2.16 Service request

8.2.16.1 Message definition

The SERVICE REQUEST message is sent by the UE to the AMF in order to request the establishment of an N1 NAS signalling connection and/or to request the establishment of user-plane resources for PDU sessions which are established without user-plane resources. See table 8.2.16.1.1.

Message type
SERVICE REQUEST
Significance
dual
Direction
UE to network

See spec for details...

8.2.30 Control Plane Service request

8.2.30.1 Message definition

The CONTROL PLANE SERVICE REQUEST message is sent by the UE to the AMF when the UE is using 5GS services with control plane CIoT 5GS optimization. See table 8.2.30.1.1.

Message type
CONTROL PLANE SERVICE REQUEST
Significance
dual
Direction
UE to network

See spec for details...

9.1 General message format and information elements coding Overview

See spec for details of section 9.

9.1.1 NAS message format

Within the protocols defined in the present document, every 5GS NAS message is a standard L3 message as defined in 3GPP TS 24.007.

9.11 Other information elements

9.11.1 General

The different formats (V, LV, T, TV, TLV, LV-E, TLV-E) and the five categories of information elements (type 1, 2, 3, 4 and 6) are defined in 3GPP TS 24.007.

The first octet of an information element in the non-imperative part contains the IEI of the information element. If this octet does not correspond to an IEI known in the message, the receiver shall determine whether this IE is of type 1 or 2 (i.e., it is an information element of one octet length) or an IE of type 4 (i.e., that the next octet is the length indicator indicating the length of the remaining of the information element) (see 3GPP TS 24.007).

This allows the receiver to jump over unknown information elements and to analyze any following information elements of a particular message.

The definitions of information elements which are:

  1. common for the 5GMM and 5GSM protocols;
  2. used by access stratum protocols; or
  3. sent to upper layers

are described in subclause 9.11.2.

The information elements of the 5GMM or 5GSM protocols can be defined by reference to an appropriate specification which provides the definition of the information element, e.g., "see subclause 10.5.6.3A in 3GPP TS 24.008".

See spec for details...

9.11.3 5GS mobility management (5GMM) information elements

See spec for details...

9.11.3.4 5GS mobile identity

The purpose of the 5GS mobile identity information element is to provide either the SUCI, the 5G-GUTI, the IMEI, the IMEISV, the 5G-S-TMSI, the MAC address or the EUI-64.

The 5GS mobile identity information element is coded as shown in figures 9.11.3.4.1, 9.11.3.4.2, 9.11.3.4.3, 9.11.3.4.4, 9.11.3.4.5, 9.11.3.4.6, 9.11.3.4.8 and 9.11.3.4.7, and table 9.11.3.4.1.

The 5GS mobile identity is a type 6 information element with a minimum length of 4.

See spec for figures and details...


To Telecommunications info