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

24.5013GPPNon-Access-Stratum (NAS) protocol for 5G System (5GS)Release 17Stage 3TS

In WB-N1 mode, a UE operating in category CE can operate in either CE mode A or CE mode B (see 3GPP TS 36.306 [25D]). If a UE that supports CE mode B and operates in WB-N1 mode and the UE’s usage setting is not set to "voice centric" (see 3GPP TS 23.501 [8]), and:

a) the use of enhanced coverage is not restricted by the network; or

b) CE mode B is not restricted by the network (see 3GPP TS 23.501 [8]);

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

A UE that supports CE mode B and operates in WB-N1 mode shall not apply the value of the applicable NAS timer indicated in table 10.3.1 for WB-N1/CE mode before receiving an indication from the network that the use of enhanced coverage is not restricted, or CE mode B is not restricted, as described in this subclause.

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

If the use of extended NAS timer is indicated by the AMF (see 3GPP TS 23.501 [8] and 3GPP TS 23.502 [9]), the SMF shall calculate the value of the applicable NAS timer indicated in table 10.3.2 for WB-N1/CE mode.

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

4.21 Authentication and Key Management for Applications (AKMA)

The UE may support AKMA.

The purpose of AKMA is to provide authentication and key management to applications based on 3GPP credentials used for 5GS access as specified in 3GPP TS 33.535 [24A], which allows the UE to securely exchange data with an AKMA application function.

Upon receiving a request from the upper layers to obtain AKMA Anchor Key (KAKMA) and AKMA Key Identifier (A-KID), the UE supporting AKMA shall derive the KAKMA and the AKMA Temporary Identifier (A-TID) from the valid KAUSF if available as specified in 3GPP TS 33.535 [24A], shall further derive the A-KID from the A-TID as specified in 3GPP TS 33.535 [24A] and shall provide KAKMA and A-KID to the upper layers.

The UE supporting AKMA shall notify the upper layers whenever there is a change of the KAUSF upon reception of an EAP-success message in subclauses 5.4.1.2.2.8, 5.4.1.2.3.1 and 5.4.1.2.3A.1 or upon reception of SECURITY MODE COMMAND message in subclauses 5.4.2.3.

During an ongoing primary authentication and key agreement procedure (see subclause 5.4.1), if the UE receives a request from upper layers to obtain KAKMA and A-KID, the UE shall derive the KAKMA and A-TID after the completion of the ongoing primary authentication and key agreement procedure, shall further derive the A-KID from the A-TID as specified in 3GPP TS 33.535 [24A] and shall provide KAKMA and A-KID to the upper layers.

NOTE 1: The upper layers derive the AKMA Application Key (KAF) from KAKMA as specified in 3GPP TS 33.535 [24A].

NOTE 2: The knowledge of whether a certain application needs to use AKMA or not is application specific and is out of the scope of 3GPP.

NOTE 3: The exact method of securing the data exchange at the upper layers using KAF is application specific and is out of the scope of 3GPP.

NOTE 4: The upper layers request the UE NAS layer to provide KAKMA and A-KID before the upper layers initiate communication with an AKMA application function.

NOTE 5: Upon receiving a request from the upper layers to obtain KAKMA and A-KID, if there is no KAUSF available, the UE NAS layer cannot derive the KAKMA and A-KID and provides an indication to the upper layers that KAKMA and A-KID cannot be generated.

4.22 Uncrewed aerial vehicle identification, authentication, and authorization

4.22.1 General

A 5GS can support UAV identification, authentication, and authorization (see 3GPP TS 23.256 [6AB]). This subclause describes NAS-specific aspects of the 5GS features to support UAV identification, authentication, and authorization.

Before accessing 5GS for UAS services, the UE supporting UAS services must have an assigned CAA-level UAV ID. The UE can be registered to 5GS for UAS services if there is a valid aerial subscription in the UE’s subscription.

4.22.2 Authentication and authorization of UAV

The 5GS supports the USS UAV Authorization and Authentication (UUAA) procedure for a UE supporting UAS services. Depending on operator policy or regulatory requirements, the UUAA-MM procedure can be performed by the UE and the AMF at a registration procedure as specified in subclause 5.5.1 or the UUAA-SM procedure can be performed by the UE and the SMF at a PDU session establishment procedure as specified in subclause 6.4.1. The UE shall support UUAA-MM and UUAA-SM, and the network shall support UUAA-SM and may optionally support UUAA-MM. The UUAA procedure needs to be performed by 5GS with USS successfully before the connectivity for UAS services is established.

During a registration procedure, the UE supporting UAS services provides CAA-level UAV ID to the AMF (see subclause 5.5.1.2), and the AMF may trigger the UUAA-MM procedure. If the UE supporting UAS services does not provide CAA-level UAV ID to the AMF and the network is configured to perform UUAA at registration, the AMF may accept the registration and shall reject PDU session establishment requests for UAS services. If the UE wants to use the UAS services by providing the CAA Level UAV ID later on, then the UE shall first perform UE-initiated de-registration procedure followed by an initial registration to the 5GS including the CAA Level UAV ID in the registration request.

When a UE supporting UAS services requests to establish a PDU session for USS communication, the UAV provides CAA-level UAV ID to the network (see subclause 6.4.1.2), and the SMF may trigger the UUAA-SM procedure. If the UE does not provide CAA-Level UAV ID and the SM subscription for the UE requires the UUAA-SM, the network rejects the UE-requested PDU session establishment procedure for UAS services.

The UE supporting UAS services shall not provide CAA-level UAV ID to the network over non-3gpp access, and the network shall not perform UUAA procedure for non-3gpp access and shall ensure that the UE is not allowed to access any aerial services in non-3GPP access.

A UE supporting UAS services may provide to the network the USS address or USS FQDN during the registration procedure or PDU session establishment procedure so that the network may use the information to discover the USS.

After successful UUAA procedure, either the AMF or the SMF may initiate re-authentication of the UAV when required by the USS. If UUAA-MM fails during a re-authentication and there are PDU sessions established using UAS services, AMF shall release these PDU sessions and may trigger a network-initiated de-registration procedure based on network policy. If UUAA-SM fails during a re-authentication, the SMF shall release the PDU session related to re-authentication.

If the UUAA is revoked, the PDU session related to UAS services shall be released by the SMF. Based on operator policy, the AMF may decide to keep the UE registered or trigger a de-registration procedure.

4.22.3 Authorization of C2 communication

The 5GS supports USS authorization of C2 communication for pairing of UAV and UAV-C. The pairing of UAV and UAV-C needs to be authorized by USS successfully before the user plane connectivity for C2 communication is enabled. The UE supporting UAS services may provide the SMF with an identification information of UAV-C to pair with, if available.

If a UE supporting UAS services uses a common PDU session for both USS communication and C2 communication with a UAV-C, the C2 comunication with the UAV-C can be authorized using UUAA-SM procedure during the PDU session establishment procedure or during the PDU session modification procedure. If the pairing of UAV and UAV-C is revoked, the network shall disable C2 communication for the PDU session.

Editor’s note [ID_UAS, CR3135]: It is FFS whether disabling C2 communication leads other actions than releasing of the PDU session.

If a UE supporting UAS services uses separate PDU sessions for, respectively, USS communication and C2 communication with a UAV-C, the C2 communication with the UAV-C is authorized using UUAA-SM during the PDU session establishment procedure. If the pairing of UAV and UAV-C is revoked, the PDU session for C2 communication shall be released by the SMF.

Editor’s note [ID_UAS, CR3135]: Details of the authorization of C2 communication procedure will be specified once stage-2 normative text is available.

Editor’s note [ID_UAS, CR3135]: Details of UAV-C pairing change will be specified according to stage-2 normative text

4.22.4 Authorization of UAV flight

The 5GS supports USS authorization of UAV flight. The authorization of UAV flight for the UE supporting UAS services can be performed using UUAA-SM procedure during the PDU session establishment procedure or during PDU session modification procedure. The UE may provide flight authorization information to the SMF if the authorization information is already available in the UAV.

Editor’s note [ID_UAS, CR3135]: Details of the UAV flight authorization procedure will be specified once stage-2 normative text is available.