SEAL is the service enabler architecture layer common to all vertical industry applications. It provides the functions like location management, group management, configuration management, identity management, key management and network resource management. The UAS communications involve interactions between UAV controller and UAV and between UTM and UAS. UAS communications require support for location information to track the UAVs, secure group communications, etc. Hence, it is required to further study the applicability of the usage of SEAL services for UAS services and whether any enhancements are required for SEAL services (e.g. location management service) and whether SEAL satisfies the stage 1 requirements for UAS.

The broadcast communications stage 1 requirements are specified in TS 22.125 which are required to be supported by the 5GS. The broadcast communications are to be supported for both on-network and off-network scenarios. Hence, it is required to study the following:

• How to enable broadcast communications amongst the UAVs in off-network scenario?
• How to enable broadcast communications amongst the UAVs in on-network scenario?
• Whether and how to support the broadcast communications amongst the UAVs in both on-network and off-network scenarios?

The location related stage 1 requirements are specified in TS 22.125 which are required to be supported by the 5GS. The UAV can report to USS/UTM various types of location information including absolute positioning like GPS coordinates and relative positioning like Cell IDs, nearby UAVs at the particular time instance, etc. The location information from the UAV cannot be fully trusted. The 3GPP system can also provide the location of a UE (in this case the UAV). The accurate positioning of UAV is necessary for UAV field operations of the USS/UTM. Hence, it is required to study the following:

• How to verify the UAV reported location information to the USS/UTM with the location information from the 3GPP system?
• How to supplement 3GPP system based location information to the location reporting towards USS/UTM?

Capability exposure requirements are specified in clause 6.2 of TS 22.125 which are requested to be supported by 3GPP system. 3GPP system is required to provide means to allow a 3rd party to request and obtain real-time monitoring the status information (e.g. location of UAV, communication link status) of a UAV. Based on operator's policy, the 3GPP system is required to provide a 3rd party with the information regarding the service status for UAVs in a certain geographical area and/or at a certain time. Hence, it is required to study the following:

• Whether and how additional service APIs are required to be supported at the UAS application enabler layer.
• Whether and how CAPIF can be leveraged for additional service APIs.

Both C2 communication and Data collected by a UAV onboard system such as payload equipment may get transmitted using 3GPP network and certain QoS parameters need be guaranteed as specified in stage 1 TS 22.125. Hence, it is required to study the following:

• Whether and how the application layer QoS requirements are provided to the 3GPP system?
• Whether and how QoS differentiation can be supported for UAV operations (e.g. for C2 communication mode, mission type, C2 communication types)?
• Whether and how UAE/SEAL layer needs to be enhanced to support the QoS monitoring/provisioning?
• Whether and how UAE/SEAL layer needs to be enhanced to support modifying QoS requirements as requested by the UAV-controller or the USS/UTM?

The C2 communication mode specified in TS 22.125 include the Direct C2 communication, Network-Assisted C2 communication and UTM-Navigated C2 communication. For reliability and service availability considerations, the switching of C2 modes may be required to ensure undisrupted C2 operation between a UAV-C and a UAV while a UAV flight is ongoing. In particular, the configuration of the C2 mode may need to be adapted for a UAS while flight is ongoing, due to possible change of radio conditions, traffic situation, unpredictable events etc. The following scenarios need to be investigated further, with respect to the impact on the application layer functional model for UAS:

• Switch between the Network-Assisted C2 communication and Direct C2 communication (e.g. when the direct link becomes feasible/available, or when a UAV is moving towards BLOS or has poor direct link conditions, etc.).
• Switch between the Network-Assisted/Direct C2 communication and UTM-navigated C2 communication (e.g. for air traffic control, the UAV is approaching a No Drone Zone, and detected potential security threats, etc.).

It is for further study whether and how the UAS application layer need to assist the dynamic C2 mode switching based on the above scenarios. The TS 22.125 also addressed it is possible to activate more than one C2 communication with one as a backup link for C2 communication or switch among the applicable links for C2 communication. It is for further study:

• Whether and how the UAS application layer need to assit in selecting the communication mode between: utilizing more than one C2 communication links, or, switch among applicable C2 communication links.
• Whether and how the C2 communication modes may be selected as primary one.

The USS/UTM information is to be configured on the UAV and/or UAV-C so that the UAS can contact its assigned USS/UTM before the flight take-off. Gap:

• How to support provisioning the USS/UTM information via U1 reference point is FFS?

Once a 3GPP network connection has been successfully made, the subsequent communication between the UAS application layer and USS/UTM may solely rely on the ID(s) assigned either by the 3GPP network or a USS/UTM or a combination of both. Based on TR 23.754 architecture's assumption, components of a UAS may be changed/updated. Therefore, a UAV ID may also be updated along the process. The current SA6 UAS architecture enables direct communication between the UAS and USS/UTM using SEAL as specified in TS 23.434. Therefore, SEAL may need to be able to support the UAV ID(s) update to provide a seamless service to the UAS application layer. Hence, it is required to study the following:

• Whether and how SEAL can support dynamic UAV ID(s) update.
• Whether and how SEAL can be enhanced to support communication between UAS and USS/UTM using either ID or a combination of both.

In most of the real-time media communications, the session is initialized with media parameters negotiation. Those parameters include codec types and profiles, maximum bitrate. This media capability negotiation is carried in an application control plane prior to the real media data traffic. In clause 7.1 of TS 22.125, following requirement is stated: SEAL, defined in TS 23.434, already offers session management for all verticals. It is then worth investigating the application enabler aspects allowing the UAS application layer to monitor and manage media sessions, in line with the KPIs listed in Stage 1 requirement in Table 7.1-1 of TS 22.125. The following scenarios have been identified:

• The SEAL may be used to facilitate the application layer for media session control and monitoring.
• The SEAL may be used to provide network resource modification for media sessions used by the application layer.

Hence, it is required to study the following:

• Whether and how existing SEAL mechanisms are sufficient to monitor and manage the media session between UAV and UAV-C and USS/UTM.

Edge deployments are vitally important for applications that require performance levels that cannot be met by existing cloud deployments. Applications executing on a UAV or UAV-C may require performance levels that can only be met when using edge deployed application servers. 3GPP TS 22.125 specifies performance KPIs (e.g. latency) for services provided to the UAV applications and UAV command and control. Some of these performance KPIs can be achieved via edge deployment. It should be studied how application servers deployed in an edge data network can be utilized by the corresponding application clients in the UAV or UAV-C by aligning the UAS Application Enabler layer architecture with the Edge Enabler layer architecture (as specified in 3GPP TS 23.558 [14]).

As per TS 22.125, "The 3GPP system shall provide means to allow a 3rd party to request and obtain real-time monitoring the status information (e.g., location of UAV, communication link status) of a UAV ". Many events related to the UAV may need to be taken into consideration by UTM to detect any problems related to UAV. According to TS 23.288 (network data analytics services) there are abnormal behaviour related network data analytics for UE or groups of UEs, which could be mobility related, communication related or both. Mobility related are unexpected UE location, ping-ponging across neighbouring cells, unexpected wakeup, unexpected radio link failures, etc. Communication related are unexpected long-live/large rate flows, unexpected wakeup, suspicion of DDoS attack, wrong destination address, too frequent service access. The abnormal behaviour analytics are exposed via NEF (as specified in TS 29.522). USS/UTM may be able to fetch multiple events related to the UAV (UE) from the 3GPP core network, using the current services of NEF/SCEF, or provide expected UE behaviour parameters to NWDAF. Taking the above into consideration, this key issue is needed to study:

• Whether the existing abnormal behavior analytics (NWDAF), event monitoring and reporting capabilities from the 3GPP exposure points (e.g. NEF APIs, UAE APIs, SEAL APIs) are sufficient for the UTM.

According to the requirements [R-5.1-012] and [R-5.1-013] of TS 22.125, one of the key functionalities of the UTM is to track the UAV/UAV-C location. Also, for "Automatic flight by UTM" control mode as mentioned in TS 22.125, it is required for UTM to track the UAV's location. In order to achieve this, the USS/UTM needs to obtain UAV's current location information periodically and process it to confirm the UAV's location deviation. Hence, it is required to the study the following:

• Whether the existing location reporting capabilities in the UAE/SEAL are sufficient to enable the USS/UTM to monitor the UAV's location deviation.

[AR-6.1-a] [AR-6.1-b]

In the UAS reference model:

• a UAS is composed by one UAV and one UAV controller.
• UAVs are connected over cellular connectivity.
• a UAV can be controlled by a UAV controller connected via the 3GPP mobile network.
• a UAV can be controlled by a UAV controller not connected via the 3GPP mobile network, using a C2 interface not in 3GPP scope.
• a UAV controller connected via the 3GPP mobile network can control one or more UAV(s).
• the UAS exchanges application data traffic with a UAS Service Supplier (USS).

Figure 7.3-1 and Figure 7.3-2 illustrates the simplified architectural models for the UAS application layer.

The UAS UE1 communicates with UAS application server over U1 reference point. The UAS UE1 and UAS UE2 communicate over U2 reference point. The UAS UE1 and the UAS UE2 may be a UAV-Controller or a UAV. The reference point U1 supports the UAS application related interactions between UAS UE and UAS AS. It is expected that this reference point is supported at least for unicast delivery mode, and may support multicast delivery mode. The reference point U2 supports the interactions between the UAS UEs. The UAS AS may be the USS/UTM. The reference point U1 is based on Uu connectivity and is an instance of UAV4 or UAV9 as specified in TR 23.754. The reference point U2 is based on Uu connectivity and is an instance of UAV3 or UAV5 as specified in TR 23.754. Figure 7.3-3 illustrates the detailed UAS application layer functional model. It enhances the simplified architectural model for the UAS application layer by specifying the functional entities at the UAS application layer.

Figure 7.3-4 illustrates the detailed UAS application layer functional model where the UAV-C has a network-assisted connectivity with the UAV.

The UAS application layer functional entities for the UAS UE and the UAS application server are grouped into the UAS application specific layer and the UAE layer. The UAE layer offers the UAE capabilities to the UAS application specific layer. The UAS application layer functional model utilizes the SEAL services as specified in TS 23.434. The UAE server is located in the UAE layer. The SEAL services/UAS application specific layer utilized by UAE layer may include location management, group management, configuration management, identity management, key management and network resource management. The UAS application specific layer consists of the UAS application specific functionalities. The following connectivity for the UAS are supported:

• UAV-C to UAV overU2 (Uu connectivity).

The UAS application server consists of the UAE server, the SEAL servers and the UAS application specific server. The UAE server provides the UAS application layer support functions to the UAS application specific server over Us reference point. The SEAL servers provides the SEAL services to the UAS application specific server/UAE server over SEAL-S reference point. The UAS UEs consist of the UAE client, the SEAL clients and the UAS application specific client. The UAE client provides the UAS application layer support functions to the UAS application specific client over Uc reference point. The SEAL clients provides the SEAL services to the UAS application specific client/UAE client over SEAL-C reference point. The UAS application specific client/UAE client acts as a VAL client for its interaction with the SEAL clients as specified in TS 23.434. The UAS application specific server/UAE server acts as a VAL server for its interaction with the SEAL servers as specified in TS 23.434. In the UAE layer, the UAE client communicates with the UAE server over U1-AE reference point. In the UAS application specific layer, the UAS application specific client communicates with UAS application specific server over U1-APP reference point. In the UAE layer, the UAE client of UAS UE2 communicates with UAE client of UAS UE1 over U2-AE reference point. In the UAS application specific layer, the UAS application specific client of UAS UE2 communicates with UAE client of UAS UE1 over U2-APP reference point. The following SEAL services for UAS applications may include:

• Location management as specified in TS 23.434;
• Group management as specified in TS 23.434;
• Configuration management as specified in TS 23.434;
• Identity management as specified in TS 23.434;
• Key management as specified in TS 23.434; and
• Network resource management as specified in TS 23.434.

The UAS application specific client/UAE client interacts with SEAL clients over the SEAL-C reference point specified for each SEAL service. The UAS application specific server/UAE server interacts with SEAL servers over the SEAL-S reference point specified for each SEAL service. The interaction between the SEAL clients is supported by SEAL-PC5 reference point specified for each SEAL service. The interaction between a SEAL client and the corresponding SEAL server is supported by SEAL-UU reference point specified for each SEAL service. To support distributed UAE server deployments, the UAE server interacts with another UAE server over UAE-E reference point. A U1-AE message can be sent over at least unicast, and may be sent over transparent multicast via xMB or transparent multicast via MB2. The non-transparent multicast via xMB (as specified in TS 26.348) is triggered by a U1-AE message. Multicast distribution can be supported by both transparent and non-transparent multicast modes. The UAE server interacts with the 3GPP network system over U2, MB2, xMB, Rx, T8 and Nnef reference points.