Content for  TR 21.917  Word version:  17.0.1

For several reasons, drone-related aspects have been using different names: during the course of Rel-17, "unmanned" was changed to "uncrewed". Also, some groups have been using "Vehicle" "UAV") while other have been using "Systems" ("UAS"). This section refers to drone being supported as a vertical by the 5GS. It does not cover the case of drones being used within the system, e.g. to provide extended coverage (this is not covered in the Release).

Summary based on the input provided by Qualcomm in SP-220619. The work on Remote Identification of Uncrewed Aerial Systems (UAS) includes a set of 5GS enhancements aiming at supporting aviation industry needs for remote identification, tracking and authorization of Uncrewed Aerial Vehicles (UAVs) operating via the 3GPP system. Besides stage-1/2 requirements and principles, main stage-3 enhancements relate to Core Network and NAS. High-level service requirements for remote UAS identification are described in [1]. Key functions of the 3GPP architecture for UAS are depicted in the following Figure (where the UE is assumed to be part, or on board, of a UAV):

The main architectural and protocol functionalities, added to the stage-2&3 specifications, include the following ([2] - [10]): UAV remote identification: The CAA (Civil Aviation Administration)-Level UAV ID is introduced in the 3GPP system, which allows any entity receiving the identity (e.g. with means outside the scope of 3GPP) to address the correct USS for retrieval of UAV information. It can be assigned by the USS with assistance from 3GPP system, e.g., whereby the USS delegates the role of "resolver" of the CAA-Level UAV ID to the UAS NF (Network Function withing the 3GPP CN). It is assumed that, during initial UAV's owner registration of the UAV with the USS (out of 3GPP scope), the CAA-level UAV ID is provided to the UAV and the aviation-level information (e.g. UAV serial number, pilot information, UAS operator, etc.) is provided to the USS. UAV USS authentication and authorization (UUAA): After a successful 3GPP authentication of the UE (using existing procedures for 3GPP primary authentication, e.g., with MNO credentials stored in the USIM), a specific/new UUAA procedure is defined, to enable the 3GPP Core Network to verify that the UAV has successfully registered with the USS. The procedure pivots on the CAA-Level UAV ID that is used by the UAV to identify itself with the USS and be authenticated by the USS. In 5GS, this procedure can take place during the 3GPP registration, or during the establishment of a PDU session for UAS services; In EPS, the UUAA procedure takes place during PDN connection establishment. As part of UUAA, a generic container (Service-level-AA container) and a generic SM procedure for authentication/authorization purpose (Service-level-AA procedure) are defined, to exchange the UUAA authentication information between the UE and the USS; in addition, an API based authentication/authorization procedure is also specified. The details of the security material used for the UUAA are outside the scope of 3GPP and considered application layer. C2 (Command and Control) communication authorization: For C2 communication over cellular connectivity, consisting of a UAV user plane connection with the UAVC, authorization by the USS is required to enable such traffic, including authorization for pairing of the UAV with a UAVC, as well as optional flight authorization for the UAV (performed by the USS). To support this, NAS PDU session establishment and modification procedures have been extended, to enable inclusion of the CAA-level UAV ID and other application layer authorization information in the Service-level-AA container. UAV location reporting and tracking UAV location reporting and tracking is specified by mostly re-using the existing location procedures. Different UAV tracking modes have been defined, e.g. where the USS can be notified of the location of a UAV, a UAV moving in/out of a given geographic area, or a list of UAVs in given geographic area.