My 3GPP 24.501 notes

From Got Opinion Wiki
Jump to navigation Jump to search

4.1 Overview

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

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

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

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

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

  • elementary procedures for 5GS mobility management in clause 5; and
  • elementary procedures for 5GS session management in clause 6.

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

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

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

4.2 Coordination between the protocols for 5GS mobility management and 5GS session management

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

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

See spec for full details...

4.4 NAS security

4.4.1 General

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

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

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

4.4.2 Handling of 5G NAS security contexts

4.4.2.5 Establishment of secure exchange of NAS messages

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

4.4.4.2 Integrity checking of NAS signalling messages in the UE

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

  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 [24]. The protection of initial NAS messages applies to the REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST message, and is achieved as follows:

  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.


To Telecommunications info
Retrieved from "https://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_24.501_notes&oldid=2721"