WO2025021327A1

WO2025021327A1 - No-transmit zones for uncrewed aerial vehicles

Info

Publication number: WO2025021327A1
Application number: PCT/EP2024/055393
Authority: WO
Inventors: Emmanouil Pateromichelakis; Dimitrios Karampatsis
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2024-02-16
Filing date: 2024-03-01
Publication date: 2025-01-30
Anticipated expiration: 2026-08-16

Abstract

Various aspects of the present disclosure relate to a UE for wireless communication, the UE being configured to be associated with an uncrewed aerial vehicle (UAV), comprising at least one memory at least one processor coupled with the at least one memory. The at least one processor is configured to cause the UE to: obtain an indication of at least one expected route for a second UE corresponding to a second UAV; obtain information identifying at least one no-transmit zone corresponding to the expected route; and transmit a n indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

Description

NO-TRANSMIT ZONES FOR UNCREWED AERIAL VEHICLES

TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to wireless communications relating to operation of uncrewed aerial vehicles (UAVs).

BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be constmed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] Some implementations of the method and apparatuses described herein may further include a UE for wireless communication, the UE being configured to be associated with an uncrewed aerial vehicle (UAV), comprising at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: obtain an indication of at least one expected route for a second UE corresponding to a second UAV; obtain information identifying at least one no-transmit zone corresponding to the expected route; and transmit a n indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

[0005] The at least one processor may be further configured to cause the UE to determine the trigger event.

[0006] The indication of the trigger event may comprise an indication of a trigger action.

[0007] The trigger action may comprise at least one of: a selection of an alternative route for the second UE; a modification of a traffic schedule for the second UE; a modification of at least one quality of service requirement for the second UE; a transfer of nominal processing responsibility from an uncrewed aerial system (UAS) associated with the second UE to a UAS associated with the first UE; an intention for the first UE to act as a relay between a network entity and the UAS associated with the second UE; a change of at least one of public land mobile network (PLMN) and radio access technology (RAT) for the second UE; and an intention for the second UE to buffer application messages.

[0008] The trigger action may be to apply while the second UE has a geographic location within the no-transmit zone.

[0009] The indication of the at least one expected route may correspond to a group of UEs including the second UE. [0010] The first UE may be configured to be an aerial UE of the UAV.

[0011] The first UE may be configured to be a UAV controller configured to control operation of one or more UAVs including the UAV.

[0012] The first UE may be configured to be a lead UE of a group of UEs including the first UE.

[0013] The group of UEs may include the second UE.

[0014] The processor may be configured to cause the UE to receive the indication of the at least one expected route from a network entity of the wireless communication network.

[0015] The processor may be configured to cause the UE to receive the indication of the at least one expected route from said network entity comprising at least one or a UAS application enabler (UAE) server and a UAS service supplier (USS)/UAS traffic management (UTM).

[0016] The information identifying the at least one no-transmit zone may comprise one or more of at least one geographical area, at least one topological area, at least one spectrum restriction, and at least one transmission power restriction.

[0017] The at least one indication of the at least one expected route may comprise mobility information associated with the second UAV. The at least one processor may be further configured to cause the UE to determine the at least one expected route for the second UAV based on the mobility information.

[0018] The at least one processor may be configured to cause the UE to monitor a location of the second UE.

[0019] The at least one indication may comprise a planned route of the second UAV. The at least one processor may be further configured to cause the UE to determine the at least one expected route for the second UAV based on the planned route.

[0020] The at least one processor may be configured to cause the UE to broadcast the indication of the trigger event to a plurality of UEs including the second UE. [0021] In some implementations of the method and apparatuses described herein, a processor for wireless communication comprises at least one controller coupled with at least one memory and configured to cause the processor to: obtain an indication of at least one expected route for a second UE corresponding to a second UAV; obtain information identifying at least one no-transmit zone corresponding to the expected route; and transmit an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

[0022] In some implementations of the method and apparatuses described herein, A method performed by a user equipment (UE) comprises: obtaining an indication of at least one expected route for a second UE corresponding to a second UAV; obtaining information identifying at least one no-transmit zone corresponding to the expected route; and transmitting an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

[0023] In some implementations of the method and apparatuses described herein, a wireless communication system comprises a first UE associated with a first UAV, a second UE associated with a second UAV, and at least one network entity, wherein: the at least one network entity is configured to transmit, to the first UAV, an indication of at least one expected route for the second UE; the at least one network entity is configured to transmit, to the first UAV, information identifying at least one no-transmit zone corresponding to the expected route; and the first UE is configured to transmit, to the second UE, an indication of a trigger event associated with the at least one no-transmit zone.

[0024] The at least one network entity may at least one of a UAE server and a USS/UTM.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0026] Figures 2 and 3 illustrate architectures for communication according to examples. [0027] Figure 4 illustrates a method according to an example.

[0028] Figures 5 and 6 illustrate communication flows according to examples.

[0029] Figure 7 illustrates an example of a user equipment (UE) 700 in accordance with aspects of the present disclosure.

[0030] Figure 8 illustrates an example of a processor 800 in accordance with aspects of the present disclosure.

[0031] Figure 9 illustrates a flowchart of method performed by a UE in accordance with aspects of the present disclosure.

[0032] Figure 10 illustrates a system according to an example.

DETAILED DESCRIPTION

[0033] Some wireless communication systems may support operation of unmanned aerial systems that include an unmanned/uncrewed aerial vehicle (UAV) controller and a UAV, which may perform UAV operations, such as command and control (C2) operations. However, these wireless communication systems may be unable to comply with notransmit zones (NTZs), which may be enforced by a third-party entity. For example, notransmit zones may be geographical areas in which a UAV is permitted to operate, but in which transmissions (e.g., on one or more frequency bands) are prohibited, for example, to mitigate or reduce interference with other receivers and transmitters such as radars.

[0034] In some cases, these wireless communication systems may incur performance degradations in flight as a consequence of complying with NTZs, for example for data services such as video feeds transmitted from a UAV, e.g. for surveillance.

[0035] Various aspects of the present disclosure relate to enabling a UE, such as a UAV, to operate appropriately in one or more NTZs. Particularly, aspects of the present disclosure relate to identifying NTZs along a route of a UAV, and configuring UAV operation to comply with such NTZs while reducing or avoiding disruptions and improving compliance with performance metrics such as key performance indicators (KPIs). Such aspects may relate to mechanisms at an application enablement layer (e.g. a UAS enabler), which can provision NTZ information to UAVs of interest from application layer, track the UAV status, and provide notifications of expected entries and leavings of a UAV from a NTZ in a predicted manner.

[0036] For example, particular aspects of the present disclosure relate to dynamically notifying one or more UAVs of the existence of one or more NTZs along their planned route or routes, even if the planned route is at least partly in locations which are off- network, out of Uu coverage, or have poor connectivity (for example rural or remote areas). This provides for such UAVs to adapt their behavior to ensure they meet performance metrics or to improve compliance with such metrics.

[0037] Aspects of the present disclosure are described in the context of a wireless communications system.

[0038] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LIE- A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0039] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0040] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0041] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of- Things (loT) device, an Intemet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0042] A UE 104 may be able to support wireless communication directly with other

UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0043] An NE 102 may support communications with the CN 106, or with another NE

102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0044] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0045] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0046] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0047] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., /r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., /r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., /r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., /r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., /r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., /r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0048] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0049] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., /r=0, jU=l , /r=2, jU=3, /r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., /r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0050] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0051] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., /r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., /r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., /r=3), which includes 120 kHz subcarrier spacing.

[0052] In the wireless communication system 100, a UE 104 may be, for example, a UAV configured to manage operation (e.g., refrain from performing transmission(s)) when the UE 104 is within at least one NTZ associated with at least one geographical area of the wireless communication system 100. The UE 104 may be configured with (e.g., indicated) the at least one NTZ associated with at least one geographical area of the wireless communication system 100 as described herein with reference to the following figures.

[0053] In such systems providing cellular-enabled UAS, the NTZs may together form “lakes” of restricted connectivity within overall coverage of a public land mobile network (PLMN) e.g. across a wider region such as nationally. This may strongly affect the performance of UAVs having on-going sessions when traveling in routes including these NTZ areas. This will be even more complex in multi-operator services (roaming) and multi-USS deployments.

[0054] In example wireless communication systems there may be provided an enabler for UAS communications, for example in conformance with 3 GPP TS 23.255. Such an enabler may provide support for the connectivity of UAS and quality of service (QoS) optimizations in an application layer, as well as middleware support for command & control (C2) and detect & avoid (DAA). A UAS enabler, which may for example be a UAE server or client, may be conceptually positioned between a Core Network and a UAS service supplier/UAS traffic management (USS/UTM), and may allow interaction among multiple mobile network operators (MNOs).

[0055] Figure 2 depicts an example of a UAS application enabler (UAE) architecture in accordance with aspects of the present disclosure. A UAS may be a system comprising a UAS application server and one or more UAS application clients, each of which resides at a UAV or a UAV controller (UAV-C). Such UAS application clients may for example be UAS application enablement clients and/or application specific clients. A corresponding UAV UE / UAV-C UE in such a system may comprise one or more UAS Application Clients, UAS Application Enablement Clients, and one or more UE modems (in examples which support dual radio/multi-RAT, multiple radio protocols may exist).

[0056] The architecture includes a UAS application server 205 in communication with a UAS application client 210a of a first UAV UE (UE1), which may for example be a UAV-C or UAV. This communication is performed via a 3GPP network system 215. The architecture further includes a UAS application client 210b of a second UAV UE (UE2), which may also be a UAV-C or UAV. The second UAS application client 210b is in communication with the first UAS application client 210a. The second UAS application client 210b may not have a direct connection with the network in general, or more specifically may not have a connection to the UAS application server 205. As explained in more detail below, the first UAS application client 210a may act as a relay between the second UAS application client 210b and the network.

[0057] The architecture includes three layers, which may for example form part of a layered communication architecture such as an open systems interconnect (OSI) model. These comprise a UAS application specific layer 220a, a UAE layer 220b, and a service enabler architecture layer (SEAL) 220c

[0058] Each UAS application client 210a, 210b (sometimes referred to below as a “UAV” or a “UAS UE”, referring in general to the connectivity functionality associated with a UAV) comprises a respective UAS application specific client 225a, 225b, in the UAS application specific layer 220a, a respective UAE client 230a, 230b, in the UAE layer 220b, and respective SEAL clients 235a, 235b in the SEAL 220c. Each UAS application specific client 225a, 225b may for example be configured to act in accordance with clause 5.3.2 of 3GPP TS 23.255.

[0059] The UAS application server 205 comprises a UAS application specific server 240 in the UAS application specific layer 220a, a UAE server 245 in the UAE layer 220b, and SEAL layers 250 in the SEAL 220c.

[0060] Figure 2 additionally depicts API/application layer interfaces specified in SA6, and comprise among others: a. Ul-AE: The interactions related to UAS application layer 220a support functions between a UAE client 210 and UAE server 205 are supported by Ul-AE reference point. b. U2-AE: The interactions related to UAS application layer 220a support functions between the UAE clients 210a, 210b are supported by U2-AE reference point. c. UAE-E: The interactions related to UAS application support functions between UAE servers 245 in a distributed deployment are supported by UAE-E reference point. d. SEAL-UU, SEAL-PC5 may for example be as defined in 3GPP TS 23.434 and are used for SEAL 220c services which are utilized by the UAE layer 220b for offering services. For example, group management and location management services may be consumed to offer some services for UAS.

[0061] In the present example the total service area (defined based on USS or UTM, or based on UAE layer coverage area) includes NTZs. The present example can thus include one or more of the following considerations: a. A UAV UE 210 plans to travel in an area (based on the allowed list of areas) which includes one or more NTZs. The sessions apart from C2, can be also for data services. For example, a UAV 210 may intend to send video feeds to the UASS 240 or to the UAV controller. In this scenario, a KPI for the data service may be defined between the UAV and the UASS or the UAV and the UAV-C. b. One or both of the UAVs 210a, 210b may have been made aware of the NTZs during a pre-configuration process (for example at a corresponding UAV application, or by the UTM or UAV-C), and/or one or both of the UAVs 210a, 210b may be unaware of the NTZs c. One or more of the following sessions may be applicable to this scenario and may be affected by the existence of NTZs: i. One or more network sessions (PDU session) between a UAV UE 210 and the NW (one or more networks) 215 ii. An off-network session (PC5) between a UAV UE and a UAV-C UE iii. An application session (Ul-APP, U2-APP) between a UAV application client 225 and the UASS 240 iv. An application session (Ul-AE, U2-AE) between a UAE client 230 and the UAE server 245. v. An application session between UAE clients of UAV and UAV-C.

[0062] In examples, a UAV 210 may have dual connectivity via more than one PLMN.

[0063] A NTZ may be translated to a topological area. For example, such a topological area may have coverage which is equal to equal to one or more cells, or an area smaller than a cell area.

[0064] A UAV UE 210 may be provisioned by one or more USSs which cover orthogonal or overlapping service areas. A USS is an entity that assists UAS Operators with meeting UTM operational requirements that enable safe and efficient use of airspace. A USS acts as a communications bridge between federated UTM actors to support operators’ abilities to meet the regulatory and operational requirements for UAS operations. A USS may provide the operator with information about planned operations in and around a volume of airspace so that operators can ascertain the ability for the UAV 210 to conduct its mission safely and efficiently.

[0065] In multi -USS scenarios, each USS may be physically located in different clouds, and it is also possible that a USS is deployed at the edge. In such multi-USS scenarios, the interaction with the communication network for supporting a UAS session which requires the interaction to more than one USS e.g. due to UAV mobility to different geographical area covered by different edge cloud, may be required in case of NTZ areas.

[0066] Figure 3 schematically depicts an architecture for UAS communication according to an example. In this example, UAS UE to UAS UE communications can be performed over a side-link. Aspects of the communication may for example be performed in accordance with 3GPP TS 25.256 and TS 23.255.

[0067] The top row of Figure 3 depicts communication between a UAS application server 205 and two UAS UEs 210a, 210b as described above. The UAS UE1 210a communicates with the UAS application server 205 over a U1 reference point. The UAS UE1 210a and UAS UE2210b communicate with each other over a U2 reference point. Either or both of the UAS UE1 210a and the UAS UE2210b may be implemented as part of a UAV Controller (UAV-C) and/or a UAV.

[0068] In the example in which one of the UAS UEs is a UAV-C, such a UAV-C may for example connect to a respective UAV via a communication protocol outside the scope of 3 GPP.

[0069] The bottom row of Figure 3 depicts communication between the UAS UE1 210a and the UAS UE2210b over the U2 reference point, without the involvement of the UAS application server 215. Such a communication mode may for example be used in situations in which the UAS UEs 210a, 210b cannot communicate with the UAS application server (for example because of poor connectivity, e.g. rural or remote areas), and thus cannot access the network. The present disclosure thus provides for NTZs to be handled even in situations in which the network is not accessible to one or more UEs.

[0070] The reference point U1 supports UAS application related interactions between the UAS UEs 21a, 210b and the UAS application server 205. In embodiments, this reference point may for example be supported at least for a unicast delivery mode, and may additionally be supported for a multicast delivery mode. The reference point U2 supports the interactions between the UAS UEs 210a, 210b. The UAS application server 205 may for example be a USS/UTM. The reference point U2 may for example be based on Uu connectivity for example in accordance with 3 GPP TS 23.256.

[0071] Furthermore, in SA6 the application layer functional model includes also the UAV-to-UAV-C interfaces (aka off-network functional model). Figure 2 illustrates the detailed UAS application layer functional model in which the UAV-C (e.g. 210a) has a network assisted connectivity with the UAV 210b. The UAS application layer functional entities for the UAS UE 210a, 210b and the UAS application server 205 are grouped into the UAS application specific layer 220a and the UAE layer 220b. The UAE layer 220b offers the UAE capabilities to the UAS application specific layer 220a.

[0072] In the UAE layer 220b, the UAE client 230b of UAS UE2210b communicates with UAE client 230a of UAS UE1 210a over U2-AE reference point. In the UAS application specific layer 220a, the UAS application specific client 225b of UAS UE2210b communicates with the UAS application specific client 225a of UAS UE1 210a over U2- APP reference point.

[0073] As stated above and explained in more detail below, aspects of the present disclosure thus operate within this architecture to dynamically notify one or more UAS UEs 210a, 210b of the existence of one or more NTZs along their planned route or routes, even if the planned route is at least partly in locations in which the network (e.g. the UAS application server 205) cannot be accessed (for example because they are off-network, out of Uu coverage, or otherwise have poor connectivity). This provides for such UAVs to adapt their behavior to ensure they meet performance metrics or to improve compliance with such metrics.

[0074] Figure 4 depicts a method, implemented at the device side (e.g. a UAV UE or UAV-C UE) for providing undisrupted UAS application sessions in scenarios in which NTZs exist along the route of a UAV. This mechanism includes the notification of the NTZ and the generation of a trigger action to prevent service disruption and loss of data due to the UAV transmission restrictions. The method may for example be performed within the architecture of Figure 2 and/or Figure 3. Figure 4 depicts a UAE Server 245(which may be a UASSS) operating in the UAE enabler layer 220b in communication with a UAV client 405 with associated UAS Enabler Client 230a and UAV-C 210a (which may alternatively or additionally be a host, or lead, UAV of a group of UAVs 210a, 210b). Figure 4 further depicts UAVs 210b, 210c with associated UAS Enabler clients 230b, 230c and a UAV client 420 associated with the UAV 210b. The UAVs 210b, 210c are in communication with each other, but not with the UAS Enabler Layer 220b (i.e. the communication mode shown in the bottom row of Figure 3). The first UAV 210a is in communication with the UAV-C 415. [0075] Steps depicted in Figure 4 will now be described. Operations between the above-referenced entities may be performed in a different order than the example shown, or at different times. Some operations may be omitted from the process flow, and some may be added.

[0076] At 1 , the UAE server 245 (or UASSS via UAE server) sends the host/lead UAV or UAV-C (denoted as UAS UE 1) 210a the expected or predicted route for the UAV(s) of interest (e.g. UAVs 210a, 210b and 210c, which may be termed UAS UE1, UAS UE2 and UAS UE3), as well as information on one or more NTZs for the given service area of interest.

[0077] At 2, UAS UE1 210a starts monitoring location of a target UAV, corresponding to UAS UE2 210b via local a monitoring (using SEAL LM off-network services as specified in TS 23.434, or via consuming network LCS (from RAN or Core via AF). This may include monitoring the elevation and/or height of the target UAV. The height may for example be determined from the application layer.

[0078] At 3, UAS UE1 210a detects that UAS UE2210b is expected or predicted to pass from a NTZ. This may for example be determined using the location real-time monitoring, or via checking the planned route, or via predicting its location using network or application layer analytics. In response to this detection, UAS UE1 210a generates a trigger event, which may for example include a notification to be sent to UAS UE2 210b. Alternatively or additionally, this may include determining a recommended action to be performed by UAS UE2 210b, conditional on the reported location and/or status. The recommended trigger action which is mapped to the trigger event can be one or more of the following: a. A change of route for the UAS UE2210b to avoid NTZs, and/or a selection of an alternative route for example a route, from a list of allowable routes, having a minimum number of NTZs and/or a minimum expected performance degradation. In examples, the UAE server 245 may select the alternative route. Alternatively, the UAE server 245 may notify the UASS to select a new route for the UAV 210a. In this example, the USS may determine a new route if the network indicates that the network has no alternative carrier frequencies for the UAS UE2210b to operate in the NTZ area. b. An adaptation of traffic schedule and/or QoS requirements, for example per waypoint, to take into account the NTZ. For example, an encoding rate for video traffic may be altered e.g. reduced in the NTZ. c. Some processing may be moved from UAS UE2210b to UAS UE1 210a, to account for a potential increase in latency when the UAV 210a is within the NTZ. For example, UAS UE1 210a may act as a relay from UAS UE2 210b to the network. d. A change of PLMN, dual connectivity, and or RAT. e. Implementation of buffering of application messages by UAS UE2 210b for the period that it is in the NTZ. For example, the UAS UE2210b may buffer transmissions while within the NTZ, and then transmit them following leaving the NTZ.

[0079] UAS UE1 210a may then also inform the UAE Server 245 (or UASSS) for the generated trigger event/action if this involves the network.

[0080] At 4, UAS UE1 210a transmits the notification and/or recommended action to UAS UE2210b via U2/U2-AE indicating an expected or predicted entering or leaving a NTZ or a sequence of NTZ in given time periods along the route. This may for example be a unicast transmission from UAS UE1 210a to UAS UE2 210b, or a broadcast in the given area to multiple UAS UEs in the group or vicinity including UAS UE2210b).

[0081] UAS UE2210b (and/or other target UEs) may then send a response (for example an ACK) to UAS UE1 in response to the notification message. However, this may not be performed for example if the UAS UE2 210b is already within the NTZ and is thus not permitted to transmit.

[0082] At 5, communication as described above between UAS UE1 210a and UAS UE2210b may be repeated between UAS UE2 210b (taking the role of UAS UE1 210a as described above) and UAS UE3 210c (taking the role of UAS UE2210b as described above). Multiple UAS UEs can thus be connected to the network via a chain of relays, even when they are not individually in communication with the network. [0083] The above-described method may include the adaptation of behaviour of multiple UAS UEs. This may involve further negotiations or triggers to further UEs, as well as the notification of the UAE server 245 (or UASSS).

[0084] Figure 5 depicts an example communication flow between the UAVs 210a, 210b described above (the host UAV 210a comprising a UAE client 230a and a UAS client 225a), an analytics function 505 of the network (which may for example be a NWDAF, AD AES, and/or ADAEC), and a UAE server 245. Operations between the abovereferenced entities may be performed in a different order than the example shown, or at different times. Some operations may be emitted from the process flow, and some may be added.

[0085] The example of Figure 5 provides client-enabled local NTZ identification. In this example, the UAV1 210a can locally configure the other UAVs in its vicinity (including UAV2210b), and can notify the network of expected or predicted mobility to NTZ.

[0086] At 1 , the UAE server 245 transmits a request to the UAE client 230a of the host UAV1 210a to notify and provide information on expected NTZ along the path of one or more UAVs (which may including UAV1 210a and/or UAV2 210b) in a given area for one or more PLMNs

[0087] At 2, the UAE client 230a fetches the planned route of UAV1 210a and/or UAV2 210b from the UAE server 245. Alternatively, this may be fetched from the UAV client 230a itself. The UAE client 230a may additionally request and receive analytics of mobility (for example one or more of predicted location, speed and elevation) from either ADAE layer or from NWDAF via NEF.

[0088] At 3, the UAE client 230b requests, from the UAS client 225a (or UAV modem) the NTZ information. This may for example include one or more of a geographical area, a list of restricted frequency bands, a maximum power to transmit, and one or more impacted interfaces (for example Uu/PC5)) for each of the one or more NTZs along the route.

[0089] At 4, the UAE client 230a translates the NTZ area info into topological area. For example the NTZ may be expressed in terms of edge service areas and/or cells. The UAE client 230a identifies whether and when the UAV1 210a and/or UAV2210b will reach these areas. The UAE client 230a may also identify, based on the analytics, how long the UAVs 210a, 210b are expected to spend in these areas.

[0090] At 5, the UAE client 230a notifies the UAE server 245 as well as the other UAE clients 210b in the vicinity of the expected NTZ. This notification may be a one-time notification, a periodical notification, or a notification that is triggered upon the UAV2 210b reaching an area in or close to the NTZ. The notification of the NTZ can be for the UAV1 210a itself or for further UAVs in the area such as UAV2210b. The notification may be for a further UAV3 210c such as that shown in Figure 4, with the intention for this to be relayed to that UAV. As an example, the UAV1 210a may detect another UAV nearby close to the NTZ and inform the UAE server 245 to notify USS/UTM. In examples, the notification may be an early notification (for example predictive based on the predicted time in NTZ for UAV1 210a or UAV2 210b).

[0091] The UAE server 245 may further interact with USS/UTM to forward the notification/trigger action, so as to allow for instance the USS to determine a new route if the network indicates that the network has no alternative carrier frequencies for the UAV to operate in the NTZ area (as described in more detail above).

[0092] The present method thus allows for a UAV (i.e. UAV1 210a) to configure both itself and other UAVs based on the presence of one or more NTZs.

[0093] Figure 6 depicts an example communication flow between the UAS UEs 210a, 210b described above (the UAS UE1 210a comprising a UAS client 225a and being associated with a UAV-C or lead UAV, also numbered 210a), an analytics function 505 of the network (which may for example be a NWDAF, AD AES, and/or ADAEC), and a UAS network function (NF) and/or application function (AF) 605. The UAS NF 605 may for example implement a UAE server 245. Operations between the above-referenced entities may be performed in a different order than the example shown, or at different times. Some operations may be emitted from the process flow, and some may be added.

[0094] The example of Figure 6 provides UAV-enabled local NTZ identification. In this example, a UAV 210a can locally configure the other UAVs in its vicinity (for example UAS UE 210b) and notify the network of expected or predicted mobility to NTZ using network signaling.

[0095] At 1 , the UAS NF 605 (for example a UASNF as specified in 3GPP TS 23.256) discovers, based on a UAS ID of the UAS UE1 210a (as controller or lead UAV in a group) if the UAS UE 2 210b is not reachable. If so, the UAS NF 605 sends a request to UAS UE1 210a to notify and provide information on one or more expected NTZs along the path of one or more UAVs (including the UAS UE2210b) in a given area for a target PLMN.

[0096] At 2, The UAS UE1 210a fetches the UAV planned route from either the UAV client of the UAS UE 2210b or from UAS UE1 210a. This can be fetched by way of analytics of mobility of each UAV (for example one or more of predicted location, speed, and elevation), from the analytics function 505 (for example from the ADAE layer or from the NWDAF via NEF/AF).

[0097] At 3, the UAS UE1 210a requests from the UAS client 225a (or UAS modem) the NTZ information, which may for example include one or more of a geographical area, a list of restricted frequency bands, a maximum power to transmit, and impacted interfaces (for example Uu/PC5)) for each of the one or more NTZs along the route. Alternatively, this information may be pre-configured or fetched at or prior to the beginning of the method.

[0098] At 4, the UAS UE1 210a translates the NTZ area info into topological area (for example one or more edge service areas and/or cells), and identifies whether and when the UAS UE2210b will reach these areas. The UAS UE1 210a may additionally determine, based at least partially on the analytics, how long the UAS UE2 210b is expected to be in these areas.

[0099] At 5, the UAS UE1 210a notifies the UAS NF 605 (which may for example be a UAE server 245) as well as the UAS UE2210b of the expected NTZ. This notification may be a one-time notification, a periodical notification, or a notification that is triggered upon the UAV2 210b reaching an area in or close to the NTZ. The notification of the NTZ may be for the UAV 210b itself or for further UAVs in the area. For example, a UAV 210a, 210b may detect another UAV nearby, for example close to a NTZ, and informs the UAS NF 605 (e.g. UAE server 245) to notify the USS/UTM. In examples, the notification may be an early notification (for example predictive based on the predicted time in NTZ for UAV1 210a or UAV210b).

[0100] Figure 7 illustrates an example of a UE 700 in accordance with aspects of the present disclosure. The UE 700 may include a processor 702, a memory 704, a controller 706, and a transceiver 708. The processor 702, the memory 704, the controller 706, or the transceiver 708, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0101] The processor 702, the memory 704, the controller 706, or the transceiver 708, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0102] The processor 702 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 702 may be configured to operate the memory 704. In some other implementations, the memory 704 may be integrated into the processor 702.

The processor 702 may be configured to execute computer-readable instructions stored in the memory 704 to cause the UE 700 to perform various functions of the present disclosure.

[0103] The memory 704 may include volatile or non-volatile memory. The memory 704 may store computer-readable, computer-executable code including instructions when executed by the processor 702 cause the UE 700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 704 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0104] In some implementations, the processor 702 and the memory 704 coupled with the processor 702 may be configured to cause the UE 700 to perform one or more of the functions described herein (e.g., executing, by the processor 702, instructions stored in the memory 704). For example, the processor 702 may support wireless communication at the UE 700 in accordance with examples as disclosed herein. The UE 700 may be associated with a UAV and configured to support a means for obtaining an indication of at least one expected route for a second UE corresponding to a second UAV; obtaining information identifying at least one no-transmit zone corresponding to the expected route; and transmitting an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

[0105] The controller 706 may manage input and output signals for the UE 700. The controller 706 may also manage peripherals not integrated into the UE 700. In some implementations, the controller 706 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 706 may be implemented as part of the processor 702.

[0106] In some implementations, the UE 700 may include at least one transceiver 708. In some other implementations, the UE 700 may have more than one transceiver 708. The transceiver 708 may represent a wireless transceiver. The transceiver 708 may include one or more receiver chains 710, one or more transmitter chains 712, or a combination thereof.

[0107] A receiver chain 710 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 710 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 710 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 710 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 710 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data. [0108] A transmitter chain 712 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 712 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 712 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 712 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0109] Figure 8 illustrates an example of a processor 800 in accordance with aspects of the present disclosure. The processor 800 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 800 may include a controller 802 configured to perform various operations in accordance with examples as described herein. The processor 800 may optionally include at least one memory 804, which may be, for example, an L1/L2/L3 cache. Additionally, or alternatively, the processor 800 may optionally include one or more arithmetic-logic units (ALUs) 806. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0110] The processor 800 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 800) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others). [0111] The controller 802 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 800 to cause the processor 800 to support various operations in accordance with examples as described herein. For example, the controller 802 may operate as a control unit of the processor 800, generating control signals that manage the operation of various components of the processor 800. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0112] The controller 802 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 804 and determine subsequent instruction(s) to be executed to cause the processor 800 to support various operations in accordance with examples as described herein. The controller 802 may be configured to track memory address of instructions associated with the memory 804. The controller 802 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 802 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 800 to cause the processor 800 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 802 may be configured to manage flow of data within the processor 800. The controller 802 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 800.

[0113] The memory 804 may include one or more caches (e.g., memory local to or included in the processor 800 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 804 may reside within or on a processor chipset (e.g., local to the processor 800). In some other implementations, the memory 804 may reside external to the processor chipset (e.g., remote to the processor 800).

[0114] The memory 804 may store computer-readable, computer-executable code including instructions that, when executed by the processor 800, cause the processor 800 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 802 and/or the processor 800 may be configured to execute computer-readable instructions stored in the memory 804 to cause the processor 800 to perform various functions. For example, the processor 800 and/or the controller 802 may be coupled with or to the memory 804, the processor 800, the controller 802, and the memory 804 may be configured to perform various functions described herein. In some examples, the processor 800 may include multiple processors and the memory 804 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0115] The one or more ALUs 806 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 806 may reside within or on a processor chipset (e.g., the processor 800). In some other implementations, the one or more ALUs 806 may reside external to the processor chipset (e.g., the processor 800). One or more ALUs 806 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 806 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 806 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 806 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 806 to handle conditional operations, comparisons, and bitwise operations.

[0116] The processor 800 may support wireless communication in accordance with examples as disclosed herein. The processor 800 may be configured to or operable to support a means for obtaining an indication of at least one expected route for a second UE corresponding to a second UAV; obtaining information identifying at least one no-transmit zone corresponding to the expected route; and transmitting an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE. [0117] Figure 9 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions.

[0118] At 902, the method comprises obtaining an indication of at least one expected route for a second UE corresponding to a second UAV.

[0119] At 904, the method comprises obtaining information identifying at least one notransmit zone corresponding to the expected route.

[0120] At 905, the method comprises transmitting an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

[0121] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0122] Figure 10 illustrates a wireless communication system according to an example. The system comprises a network equipment 1005, which may for example implement a UAS NF/AF and/or UAE server as described above. The system further comprises a first UE 1010a and a second UE 1010b, which may for example be first and second UAS UEs as described above. The network entity 1005 is configured to transmit, to the first UAV 1010a, an indication of at least one expected route for the second UE 1010b. The network entity 1005 is configured to transmit, to the first UAV 1010a, information identifying at least one no-transmit zone corresponding to the expected route. The first UE 1010a is configured to transmit, to the second UE 1010b, an indication of a trigger event associated with the at least one no-transmit zone

[0123] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

CLAIMS What is claimed is:

1. A UE for wireless communication, the UE being configured to be associated with an uncrewed aerial vehicle (UAV), comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: obtain an indication of at least one expected route for a second UE corresponding to a second UAV; obtain information identifying at least one no-transmit zone corresponding to the expected route; and transmit an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

2. The UE of claim 1, wherein the at least one processor is configured to cause the UE to determine the trigger event.

3. The UE of claim 1 or claim 2, wherein the indication of the trigger event comprises an indication of a trigger action.

4. The UE of claim 3, wherein the trigger action comprises at least one of: a selection of an alternative route for the second UE; a modification of a traffic schedule for the second UE; a modification of at least one quality of service requirement for the second UE; a transfer of nominal processing responsibility from an uncrewed aerial system (UAS) associated with the second UE to a UAS associated with the first UE; an intention for the first UE to act as a relay between a network entity and the UAS associated with the second UE; a change of at least one of public land mobile network (PLMN) and radio access technology (RAT) for the second UE; and an intention for the second UE to buffer application messages.

5. The UE of claim 4, wherein the trigger action is to apply while the second UE has a geographic location within the no-transmit zone.

6. The UE of any preceding claim, wherein the indication of the at least one expected route corresponds to a group of UEs including the second UE.

7. The UE of any preceding claim, wherein the first UE is configured to be at least one of: an aerial UE of the UAV, and a UAV controller configured to control operation of one or more UAVs including the UAV.

8. The UE of any preceding claim, wherein the first UE is configured to be a lead UE of a group of UEs including the first UE.

9. The UE of claim 8, wherein the group of UEs includes the second UE.

10. The UE of any preceding claim, wherein the processor is configured to cause the UE to receive the indication of the at least one expected route from a network entity of the wireless communication network.

11. The UE of claim 10, wherein the processor is configured to cause the UE to receive the indication of the at least one expected route from said network entity comprising at least one or a UAS application enabler (UAE) server and a UAS service supplier (USS)/UAS traffic management (UTM).

12. The UE of any preceding claim, wherein the information identifying the at least one no-transmit zone comprises one or more of at least one geographical area, at least one topological area, at least one spectrum restriction, and at least one transmission power restriction.

13. The UE of any preceding claim, wherein: the at least one indication of the at least one expected route comprises mobility information associated with the second UAV; and the at least one processor is further configured to cause the UE to determine the at least one expected route for the second UAV based on the mobility information.

14. The UE of claim 13, wherein the at least one processor is configured to cause the UE to monitor a location of the second UE.

15. The UE of any preceding claim, wherein: the at least one indication comprises a planned route of the second UAV; and the at least one processor is further configured to cause the UE to determine the at least one expected route for the second UAV based on the planned route.

16. The UE of any preceding claim, wherein the at least one processor is configured to cause the UE to broadcast the indication of the trigger event to a plurality of UEs including the second UE.

17. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: obtain an indication of at least one expected route for a second UE corresponding to a second UAV; obtain information identifying at least one no-transmit zone corresponding to the expected route; and transmit an indication of a trigger event, associated with the at least one no-transmit zone, to the second UE.

18. A method performed by a user equipment (UE), the method comprising: obtaining an indication of at least one expected route for a second UE corresponding to a second UAV; obtaining information identifying at least one no-transmit zone corresponding to the expected route; and transmitting an indication of a trigger event, associated with the at least one notransmit zone, to the second UE.

19. A wireless communication system comprising a first UE associated with a first UAV, a second UE associated with a second UAV, and at least one network entity, wherein: the at least one network entity is configured to transmit, to the first UAV, an indication of at least one expected route for the second UE; the at least one network entity is configured to transmit, to the first UAV, information identifying at least one no-transmit zone corresponding to the expected route; and the first UE is configured to transmit, to the second UE, an indication of a trigger event associated with the at least one no-transmit zone.

20. The wireless communication system of claim 19, wherein the at least one network entity comprises at least one of a UAE server and a USS/UTM.