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"
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).
||WI rapporteur name/company
|840083||5G Enhancement for Uncrewed Aerial Vehicle (UAVs)||EAV||SP-190308||Qun Wei, China Unicom|
|810019||Study on EAV||FS_EAV||S1||SP-180909||Qun Wei, China Unicom|
|840039||Stage 1 of EAV||EAV||S1||SP-190308||Qun Wei, China Unicom|
|880007||Study on security aspects of Uncrewed Aerial Systems (UAS)||FS_UAS_SEC||S3||SP-200352||Adrian Escott, Qualcomm|
|820011||Study on supporting Uncrewed Aerial Systems Connectivity, Identification, and Tracking||FS_ID_UAS_SA2||S2||SP-200097||Qualcomm, Stefano Faccin|
Summary based on the input provided by China Unicom in SP-220664.
This work item expands the scope of 3GPP system to support various enhanced UAV scenarios, especially for a wide range of applications and scenarios by using low altitude UAVs in various commercial and government sectors.
New service level requirements and KPIs for supporting various UAV applications by the 3GPP system have been identified and specified. Some new requirements are closely related to relevant work item 810049 in stage 1, such as C2 communication and related KPIs.
The main work of EAV item is based on the outcome of the study items resulting in TR 22.829
. The General requirements needed for the 5G system to support UAV aspects are introduced in chapter 6.32 in TS 22.261
, which points to the main normative work of TS 22.125
, where the following service requirements and KPIs are addressed:
Requirements for UAV usages: Network exposure for UAV services; Service restriction for UEs onboard of UAV; Requirements for UxNB; C2 communication
Performance requirements: KPIs for services provided to the UAV applications; KPIs for UAV command and control; Positioning performance requirements; Other requirements
Stage-2/3 works related to this WI were progressed by the work item "Application layer support for UAS"
described in the next clause.
||WI rapporteur name/company
|820026||Study on application layer support for Uncrewed Aerial System (UAS)||FS_UASAPP||S6||SP-200111||Niranth Amogh, Huawei|
|920045||Application layer support for Uncrewed Aerial System (UAS)||UASAPP||SP-200988||Niranth Amogh, Huawei Telecommunications India|
|900025||Stage 2 of Application layer support for Uncrewed Aerial System (UAS)||UASAPP||S6||SP-200988||Niranth Amogh, Huawei Telecommunications India|
|920004||CT1 Aspects of Application Layer Support for Uncrewed Aerial Systems (UAS)||UASAPP||C1||CP-211111||Lin Shu, Huawei|
|920046||CT3 Aspects of Application Layer Support for Uncrewed Aerial Systems (UAS)||UASAPP||C3||CP-211111||Lin Shu, Huawei|
Summary based on the input provided by Huawei in SP-220651.
This Feature specifies enabler services related to application layer support for Uncrewed Aerial System (UAS). This feature enables efficient use and deployment of UAS on 3GPP networks. The architecture and protocols for UAS application layer consisting of UAS application enabler are specified considering stage 1 and stage 2 work within 3GPP related to UAS in TS 22.125
and TS 23.256
The UAS application layer utilizes Service Enabler Architecture Layer (SEAL) functionalities. The enhancements to SEAL were specified using the eSEAL WI (see corresponding section).
An architecture for UAS application layer over 3GPP system is introduced as shown in Figure 18.104.22.168.2-1
A UAS UE can be a UAV controller (UAV-C) or a UAV. In the UAS application specific layer, a UAS application server can be a USS/UTM server or any Application server interacting with UAS application clients. The UAS specific applications include C2 communications, multimedia applications, etc. and hence the details of the UAS application specific layer is out of scope of 3GPP. To support the UAS application specific layer, a UAS application support layer is specified which includes the UAS application enabler (UAE) layer and the Service Enabler Architecture Layer (SEAL). The architecture only supports Uu connectivity in this release. The UAE server exposes service APIs which can be consumed by UAS application servers and conforms to the CAPIF framework.
The functional model for UAS application layer over 3GPP system including the UAS application enabler layer functionalities are specified in TS 23.255
. The UAE layer includes UE side function called UAE client and network side function called UAE server and provides the following services to support the UAS application specific layer:
Registration enables authentication and authorization of UAS UEs at UAE layer.
Communications between UAVs within a geographical area where a UAV can send UAV application messages to other UAVs in an application defined proximity range from the UAV (sender).
Group based pairing of UAV-C and UAV enables pairing management (e.g pair creation, pair modification) using SEAL group management service.
C2 QoS provisioning for UAS utilizes SEAL network resource management service to enable QoS based C2 communications.
C2 communication mode selection and switching to enable switching between different C2 modes like Network-Assisted C2 communication, Direct C2 communication and UTM navigated C2 communications.
Real-time UAV connection status monitoring and location reporting enables UAS application servers like USS/UTM to monitor the real-time situation of the UAV.
HTTP protocol is used to enable the above functionalities and the related protocol aspects are specified in TS 24.257
The openAPI specifications for the UAE server services (northbound APIs) exposed to UAS application specific servers over Us reference point are specified in TS 29.257
The feasibility study for UAS application support aspects are specified in TR 23.755
: "Unmanned Aerial System (UAS) support in 3GPP; Stage 1"
: "Support of Uncrewed Aerial Systems (UAS) connectivity, identification, and tracking; Stage 2"
: "Application layer support for Uncrewed Aerial System (UAS); Functional architecture and information flows"
: "Uncrewed Aerial System (UAS); Application Enabler (UAE) layer; Protocol aspects; Stage 3"
: "Application layer support for Uncrewed Aerial System (UAS); UAS Application Enabler (UAE) Server Services; Stage 3"
: "Study on application layer support for Unmanned Aerial Systems (UAS)"
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 .
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 ( - ):
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.