• Solution should be applicable to EPS and 5GS.
• The 3GPP system shall enable UTM to associate the UAV and UAV controller and identify them for both 3GPP networked UAV controller and non-3GPP networked UAV controller.
• The 3GPP network shall enable the serving PLMN of the UAV(s) and the serving PLMN of the corresponding UAV controller to be different.
• Solutions shall minimize the impact on 5GS and EPS system protocols.

• Each UAS consist of one UAV Controller and one UAV.
• The UTM is a set of functionalities defined outside the 3GPP system and subject to specific regional requirements
• Connectivity for Command and control of a UAV may be between the UAV and, mutually exclusively, an UAV Controller, or a TPAE, or the UTM.
• UAVs not connected through the 3GPP network are out of scope of the 3GPP system.
• Each networked component of a UAS is considered as an individual UE from the perspective of the 3GPP system.
• A UAV can be replaced by another from a UAS.
• An UAV Controller can be removed from a UAS and replaced with another UAV Controller or a TPAE.
• It shall be possible for the 3GPP system to identify if the 3GPP connectivity service (i.e. a PDU Session or a PDN Connection) requested by a UAV or UAVC will be used for a UAV flight operation or not.
• A UAV is assigned, and a networked UAVC may be assigned, a CAA-level UAV Identity by functions in the aviation domain (e.g. USS) or by functions in the USS/UTM. This assigned identity is used for Remote Identification and Tracking.
• A 3GPP UAV ID is used by the 3GPP system to identify the UAV. GPSI is used as the 3GPP UAV ID.
• The 3GPP CN is aware of the CAA-level UAV Identity. A mapping shall be possible in the mobile operator network and in the UAS application layer outside of 3GPP between the 3GPP UAV ID and the CAA-level UAV ID.
• The USS/UTM accesses 3GPP services (e.g. location services) for a UAV corresponding to the CAA-level UAV Identity by using the 3GPP UAV Identity (i.e. the GPSI).
• Consistent identification information for the UAV is used for both Networked Remote ID and Broadcast Remote ID, based on regulatory requirements (e.g. [2]), and the UAV identification information used for Networked Remote ID are assumed to be also applicable for Broadcast Remote ID and to satisfy the regulatory requirements.
• It is assumed that mechanisms are available to ensure privacy and protection (e.g. anti-spoofing) of the CAA-assigned UAV Identity when used for Remote Identification. Security solutions to provide such privacy are outside the scope of SA WG2 (e.g. in SA WG3's scope) and may be outside the scope of 3GPP (e.g. in ASTM's scope).
• Whether security solutions to protect the CAA-Level UAV ID for privacy and against spoofing are necessary is FFS and should be discussed in coordination with SA3.
• For UAV authentication and authorization the following is assumed:
  • The UAV is authenticated at registration with the 3GPP using the existing UE authentication mechanisms based on MNO credentials
  • A UAV USS-registration takes place between the UAV and the USS/UTM. This e.g. involves authorization of the UAV and may involve authentication and is not performed by 3GPP system: it is not the 3GPP system that decides on the authorization. The results of such procedure may be known to the 3GPP system. This may be out of band and performed before accessing the 3GPP system. This is not performed each time the UAV registers with the 3GPP system. This is not performed on a per-flight basis and may have longer lifetime. However, this may be part of or follow-on of the 3GPP registration, authentication/authorization procedures.
  • A UAV authentication/authorization with UTM is triggered by the MNO when the UAV accesses the 3GPP system. This may be required when the UAV registers with the 3GPP system or when the UAV request to establish user plane resources from the 3GPP system for UAV operations. This may be needed to ensure the UAV has successfully registered with USS/UTM and has been authorized for UAV operations by USS/UTM. This involves the USS, and it is not the 3GPP system that decides to authorize the UAV: the 3GPP system receives confirmation of the authorization from the USS.
  • For networked UAV controllers and non-networked UAV controllers, pairing between the UAV and the UAV controller for the use of UAV3 or UAV5 may be at least authorized, or even authenticated. The pairing authorization/authentication, when performed, is authorized by the USS/UTM, not by the 3GPP system. The 3GPP system enables such authorization process. The result of such authorization/authentication are made known to the MNO in order to enable the USS/UTM to enable the connectivity between the UAV and the UAV controller.
  • Further work is needed to clarify if the 3GPP system needs to be aware of of connectivity set-up between UAV and UAV controller.
  • The USS/UTM may indicate to the 3GPP system revocation of UAV3 connectivity between the UAV and UAV Controller.
  • Flight plan authorization is the responsibility of air traffic control and is not performed by the 3GPP system. The 3GPP system may support the authorization of flight plan (i.e. the aviation-level flight plan authorization that UAV needs to receive from USS/UTM) between the UAV and the USS/UTM. Support of authorization of flight plan does not imply that the 3GPP system is involved in authorizing the flight plan (e.g. may provide transport for exchange of information related to flight plan authorization).
• The UAV is authorized for connectivity to USS over UAV9 based on existing MNO policies, and is allowed to establish connectivity with a DNN to exchange traffic with the USS without USS authorization
• One or more USS(s) may be present in a specific region and may manage UAVs over one or more 3GPP networks.
• For this release, it is assumed a UAV is served by the same USS/UTM for the duration of a flight.
• The 3GPP system should provide enablers to support geofencing (for in-flight UAV) and geocaging (for UAV on the ground intending to fly) functionality in USS/UTM.
• Activation of RAN aerial features for UAV accessing via E-UTRA reuses the existing mechanism defined in TS 36.300.
• It is assumed that both the UAV and the networked UAV controller in a UAS are served by the same USS.
• It is assumed that in this release the UAV uses 3GPP access (i.e. LTE & NR) for 3GPP UAV related operations.
• It is assumed that UAV reports the real-time flight information periodically to USS/UTM via 3GPP network, and the report frequency depends on geography and regulations(CAAC UAV cloud system data specification [15]).

The architecture considers a Third Party Authorized Entity (TPAE), which is not part of the UTM functionality. The following reference points are considered:

• UAV1: interfaces the UAV and UAVC with the 3GPP system to support UAV and UAVC authorization, authentication, identification, and tracking.
• UAV2: interfaces a TPAE with the 3GPP system for remote identification and tracking.
• UAV3: 3GPP user plane connectivity for transporting C2. UAV3 can be intra-PLMN or inter-PLMN.
• UAV4: interfaces a TPAE with a UAV over 3GPP network for:
  • Command and control (C2)
  • Remote identification (RID) and tracking of the UAV.
• UAV5: like UAV3 for transporting C2 but interfacing a UAV with a non-networked UAVC via the Internet outside the scope of 3GPP.
• UAV6: interfaces the 3GPP system with external USS/UTM for functionality exposure, support of identification and tracking, and UAV authorization.
• UAV7: for RID information sent in broadcast (BRID), on a transport outside the scope of 3GPP.
• UAV8: UAV8 is used for C2 over a transport outside the scope of 3GPP.
• UAV9: UAV9 supports connectivity between the UAV or a networked UAV Controller and the USS/UTM for UAS management, such as authentication and authorization, transporting C2, networked remote identification (NRID) and tracking of the UAV, etc.
• U2U: supports UAV to UAV communications for broadcast RID.