METHOD AND APPARATUS FOR DETECTION AND AVOIDANCE MECHANISM FOR UNMANNED Flight SYSTEMS

Abstract

A method performed by a wireless transmit / receive unit (WTRU) implemented in a first unmanned aerial vehicle (UAV1) includes registering a detection and avoidance (DAA) capability with an unmanned flight system (UAS) service provider (USS) in a registration message transmitted by the first UAV; detecting a flight path conflict with a second UAV (UAV2); selecting a unicast or broadcast communication mode with the UAV2; transmitting the DAA capability of the UAV1 and a conflict resolution message to the UAV2 based on the selected communication mode; and avoiding collisions by performing trajectory correction.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 324,360, filed on March 28, 2022, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to communications for aerial systems, including methods and apparatus for implementing a detect and avoid (DAA) mechanism for an unmanned aerial system (UAS). BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be obtained from the following detailed description, which is given by way of example in conjunction with the accompanying drawings thereof. As with the detailed description, the figures in such drawings are exemplary. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and contemplated. In addition, like reference numerals ("ref.") in the accompanying drawings ("Figures") indicate similar elements, and wherein:

[0005] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0006] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0007] Figure 1C is an example of an embodiment in which Figure 1A a system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0008] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0009] Figure 2 is a block diagram illustrating a reference architecture for supporting unmanned (unmanned) aerial system (UAS) services in 5GC / EPC;

[0010] Figure 3 is a block diagram illustrating a UAS application layer functional model;

[0011] Figure 4 is a signaling diagram illustrating coordinated conflict resolution between unmanned (unmanned) aerial vehicles (UAS) according to an embodiment;

[0012] Figure 5 is a signaling diagram illustrating conflict resolution with assistance of a UAS service provider (USS) according to an embodiment;

[0013] Figure 6 is a block diagram illustrating network-triggered conflict alerting and resolution according to an embodiment;

[0014] Figure 7 is a signaling diagram illustrating collision monitoring for all UAVs in a conflict resolution zone (CRZ) according to an embodiment;

[0015] Figure 8 is a signaling diagram illustrating conflict and collision monitoring of USS requests according to an implementation scheme;

[0016] Fig. 9 is a signaling diagram illustrating a process for UAV Application Enablement (UAE) support for DAA operation according to an embodiment; and

[0017] Fig.10 is a flow chart of a method according to an embodiment. DETAILED DESCRIPTION

[0018] 1 Introduction

[0019] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, processes, components, and circuits are not described in detail to avoid blurring the following description. In addition, embodiments and examples not specifically described herein may be practiced in place of embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein, or practiced in combination with these embodiments and examples.

[0020] 2 Example Communication System

[0021] Figure 1A1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0022] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0023] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0024] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0025] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0026] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0031] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), roads, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0032] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 / 115 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0033] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0035] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0036] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0037] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from the base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0038] Although the transmit / receive element 122 Figure 1B 1 as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0039] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0040] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0041] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0042] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0043] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0044] The WTRU 102 may include a full-duplex radio component for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio component may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio component for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0045] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0046] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0047] Each of the evolved Node Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0048] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0049] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0050] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-evolved Node-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0051] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0052] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0053] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communication interface with a communication network.

[0054] In a representative embodiment, the other network 112 may be a WLAN.

[0055] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0056] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may listen to the primary channel. If the primary channel is listened / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0057] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0058] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0059] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0060] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.

[0061] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0062] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0063] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0064] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0065] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the evolved Node-B 160a, 160b, 160c. For example, the WTRU 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRU 102a, 102b, 102c.

[0066] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink (UL) and / or downlink (DL), support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0067] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. AMFa 82a, 182b may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0069] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0070] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0071] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0072] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0073] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0074] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas) can be used by the simulation device to send and / or receive data.

[0075] The examples provided herein do not limit the applicability of the subject matter to other wireless technologies, eg, using the same or different principles may be applicable.

[0076] As explained herein, a wireless transmit / receive unit (WTRU) may be an example of avionics equipment in a user equipment (UE) or a UAV. Hence, the terms UE and WTRU may be used interchangeably herein.

[0077] Method and apparatus for detection and avoidance (DAA) of unmanned aerial systems (UAS)

[0078] Traditional systems

[0079] 3GPP REL-17 System Architecture for UAS Connectivity, Identification and Tracking

[0080] 3GPP Release 17 supports UAS connectivity, identification and tracking functionality, and has created specifications for Stage 2 and Stage 3. Figure 2 As shown in the reference architecture, there are network functions (UAS Network Function (NF)) to support these functionalities. UAS NF 200 plays a partial role of Network Exposure Function (NEF) for exposing services to external UAS Service Provider (USS) 202. UAS NF also supports some UAS specific processes, such as USS UAV Authorization / Authentication (UUAA) and UAS Tracking. UAS NF 200 also stores some UAS contexts, such as UUAA results.

[0081] Multiple USS (communication issues between UAS and USS)

[0082] In recent years, the number of UAVs has grown rapidly, and the application of UAVs is expanding to various industries. In the UAS traffic management (UTM) configuration, multiple USSs can operate in the same geographic area to perform traffic management and eliminate conflicts with other operations of UAVs; USSs also need to track UAVs via a network application program interface (API). The Federal Aviation Administration / National Aeronautics and Space Administration (FAA / NASA) has identified several use cases and potential requirements to achieve better capability level configuration and UAV flight operation resilience Error! Reference source not found. In one of these use cases, the UAS establishes a connection with the USS, shares its position during flight, and ensures that flight updates are periodically provided to the USS / Universal Transverse Mercator Projection (USS / UTM) network. However, during flight, the UAS may experience a loss of performance capability due to unstable connection and / or lack of availability at the USS level. For example, this loss may occur when the USS reaches its maximum capacity (traffic management) to serve a possible number of UAVs and is no longer able to support any additional new UAVs. In the case of operational cost constraints, there may also be an explicit intent to have multiple USSs, where specific USSs are more equipped / suitable for certain missions / UAV types (e.g., in a specific area).

[0083] UAV Application Enablement (UAE) Framework

[0084] 3GPP SA6 has specified a framework to provide support for UAV applications. Figure 3 A simplified UAS application layer functional model is illustrated in FIG. 30. A UAE client 300 residing in a WTRU 302 provides an API to a UAS client application 304 and interfaces with a UAE server 306, which provides an API to a UAS server application 308 (e.g., USS). The UAE server 306 may also interface directly with the 5GC via a network exposed function (NEF) API or via a service enabler architecture layer (SEAL) service.

[0085] Detection and avoidance

[0086] 3GPP TR 23.700-58 “Study of further architecture enhancements for uncrewed aerial systems and urban air mobility” v0.1.0 focuses on supporting detection and avoidance mechanisms in 3GPP systems based on the DAA requirements defined in 3GPP TS22.125 “Unmanned Aerial System (UAS) support in 3GPP” v17.5.0TS22.125. Such requirements include the ability for UAVs to use direct communications to avoid short-range collisions. Consider aspects such as architectural modifications to current solutions using PC5 (e.g., ProSe, C-V2X) to support direct UAV-to-UAV communications for the purpose of DAA.

[0087] DAA is considered one of the essential features to achieve safe BVLOS UAV operations. To ensure DAA safety, especially for safety-critical DAA, DAA safety is important. Error! Reference source not found.

[0088] Problems in traditional systems

[0089] When UAVs fly close to each other, they are likely to collide unless their flight paths are actively or passively managed to mitigate potential collisions. UAVs may be able to perform local collision detection and avoidance (DAA) operations (e.g., using application layer level logic, with the help of onboard sensors such as cameras or position sensors). However, such sensors are only capable of detecting collisions when another UAV is in direct line of sight (LOS). It may not work for scenarios outside of visual LOS (BVLOS). Additionally, for those situations where the accuracy of onboard sensors and position sensors is problematic, all UAVs may not meet accuracy and reliability requirements (e.g., due to inaccurate GNSS module measurements); therefore, other UAVs may not rely on reported / broadcasted position estimates. In such scenarios where the position, velocity, etc. reported by the UAV may not be reliable or trustworthy, it may be desirable for the system to have more global / central support for DAA applications to supplement the UAV local DAA support. The solution should be designed to cover scenarios where the UAV is both within and outside the coverage area.

[0090] With respect to DAA security, security-critical DAA data flows in local (e.g., broadcast) or network DAA communications may be authenticated / authorized. Without appropriate security protection mechanisms, an adversary could potentially interfere with UAS operations (e.g., causing the UAS to reroute in an insecure manner), for example, by spoofing or replaying DAA data flows.

[0091] UAV-related standards do not yet support detection and avoidance (DAA) for collision avoidance for UAVs. In order to support DAA for UAVs, the following issues need to be addressed:

[0092] a. How to enable 5G system to support DAA?

[0093] b. How are potential collisions resolved or avoided? For example, whether and how is the flight path adopted and updated to avoid a collision based on an anticipated collision warning?

[0094] c.Does the UAV need to communicate directly through PC5?

[0095] What would trigger such direct communication (broadcast / unicast / multicast) between UAVs?

[0096] d. Whether and how will cyber assistance for DAA be implemented?

[0097] e. For safety-critical DAA operations (for local or network DAA communications), what aspects of DAA security can be implemented?

[0098] Advanced Examples

[0099] UAVs can detect the presence of other UAVs locally with the help of onboard sensors and cameras. If the possibility of a collision is detected, the UAV can change its flight path or make small adjustments to avoid any imminent risk of collision. In the absence of coordination between UAVs, this can be driven locally by the UAV (e.g., based on decisions and actions triggered at the application level).

[0100] In the present disclosure, the proposed support for the DAA process can be achieved by enabling direct communication between UAVs and / or through network-assisted collision detection and conflict resolution. The disclosed systems and methods may or may not involve coordinated operation of UAVs. The following discusses advanced techniques for network-assisted DAA for UAV detection and conflict resolution.

[0101] Collision detection and conflict resolution

[0102] Collision detection operates at three levels, Level 1 Close, Level 2 Short Range, and Level 3 Long Range, as described below.

[0103] Level 1: Approach occurs within a few meters. In Level 1, active UAVs may participate in the following exemplary DAA protocol. In Level 1, the UAV may perform collision detection locally if the UAV has the capability. The UAV may broadcast its identity, its mobility information (e.g., speed, direction, and location), and include its DAA capabilities to nearby UAVs. As part of its DAA capabilities, the UAV may support different modes or levels of collision detection / resolution. The UAV may determine to perform local (using local DAA protocol with other UAVs) and / or central (USS and / or network assisted resolution) collision resolution. This determination may be based on the provided DAA policy, as described in the following reference Figure 6 and Figure 7 Described in more detail.

[0104] In Level 1 collision detection, the UAV may include additional information, such as onboard cameras, radars, and / or other safety features as part of its DAA capability. The UAV may detect collisions at the application layer, may receive DAA capability indications in broadcasts from other UAVs, and may trigger direct communication requests to lower layers (broadcast or unicast) via PC5 if the UAV receives other UAV indications of DAA capability.

[0105] The broadcast may include a DAA capability indication, one or more collision detection alerts, a Civil Aviation Authority (CAA) level UAV ID of a participating UAV (e.g., a UAV sensed nearby), and trajectory correction information (e.g., a new direction and / or speed that the UAV is intended to avoid collision). The broadcast may include a traffic conflict resolution alert and / or CAA level UAV ID of a participating UAV from a receiving UAV. The UAV may use unicast communication with another UAV. A unicast link may be established when a potential collision is detected, and the unicast link may be disconnected when the collision situation is resolved. In order to establish a unicast link, the UAV may transmit a direct connection request (DCR) message with a service information parameter identifying a DAA service (e.g., using a standardized DAA service name). The target user information may be set to the UAV identity of another UAV, as received from a previously received message (as in 1). If multiple other UAVs are involved, the target user information may not be set. When matching services and / or target user information, other UAVs may reply with a direct connection acceptance (DCA). The DCR may include DAA policy information. The DAA policy may be transmitted in an application generic container DAA message. The DAA policy may indicate the preferred / supported mode of DAA (e.g., local DAA: on / off, central DAA: on / off). The DAA policy may be based on a specified policy and collision context. For example, if more than 2 UAVs are involved in a traffic conflict situation, the UAVs may select a central DAA resolution mechanism. If the UAV is within or outside the coverage area, the UAV may select a local conflict resolution mechanism. The message may include the expected trajectory correction information, or the information may be exchanged in subsequent messages after the link is established and based on the agreed DAA policy. Other UAVs may reply with a DCA, confirming the accepted DAA policy (e.g., local and / or central: on / off), acceptance of the new trajectory, and / or conflict resolution.

[0106] The UAV may detect a collision at the application layer and may request accurate location information and trajectory information about the UAV itself from a location service (LCS), and any one or more of the other UAVs may affect the collision detection.

[0107] The UAV may detect a collision at the application layer, notify the USS of the expected collision, including the CAA-level UAV ID of the other UAV, location information (e.g., current location and time, flight path information and / or current speed), its DAA capability status, the USS address to which it is connected, etc. When the UAV requests the lower layer to perform any of the above actions, the UAV layer may perform RAT selection respectively.

[0108] In Level 1 collision detection, a passive UAV can be defined as a traditional UAV that does not support the DAA protocol, as described above. Note: For passive UAVs, as long as the other UAVs belong to the same USS, the USS can detect the collision and resolve the conflict. The following brief process assumes that a potential collision is detected between UAVs belonging to different USSs. (1) The UAV may transmit information about nearby UAVs (as received) to the USS, including the CAA-level UAV ID of the other UAV, location information (current location and time, flight path information and / or current speed), its DAA capability status, USS address, etc. (2) The UAV may receive flight path corrections and / or adjustments from the USS.

[0109] In Level 1 collision detection, a USS may request location information about UAVs connected to the USS. A USS may request location information about UAVs connected to other USSs. A USS may notify other USSs of its own UAV in an area where a potential collision with one of the UAVs belonging to other USSs is detected.

[0110] In Level 2 collision detection, short range may be defined as within a few hundred meters between UAVs.

[0111] In level 3 collision detection, long distance can be defined along the entire flight path, where collision detection can be coordinated by the USS. This collision detection can be based on route planning and expected trajectory. Figures 5 to 9 Describe Level 2 and Level 3 in more detail.

[0112] Coordinated conflict resolution between UAVs

[0113] In one embodiment, two UAVs may be active and may be able to locally decide to avoid collisions without involving the USS. Such UAVs may be able to coordinate communications over a PC5 (unicast or broadcast) link and may be referred to as DAA-capable UAVs, which include DAA capabilities in broadcast messages. Figure 4 The steps of the relevant process are depicted as follows.

[0114] exist Figure 4At 401, when performing initial registration or authorization with a USS, UAV1 410 and UAV2 420 may communicate their DAA capabilities to the respective USSs. For example, UAV1 410 may communicate its DAA capabilities to USS1 450, and UAV2 420 may communicate its DAA capabilities to USS2 460. The UAVs may include additional information, such as identifiers (e.g., CAA-level UAVID), onboard cameras, and / or other safety features as part of the DAA capabilities. At 402, at the application layer, UAV1 may receive a broadcast message from another UAV (e.g., UAV2), which may include, for example, a CAA-level UAV ID, a USS address of UAV2, speed, heading direction, and / or position. If an application in UAV1 detects a potential collision, it may use collaborative communication between UAVs to trigger collision avoidance / conflict resolution.

[0115] At 403, the application client of UAV1 in UAV1 (if DAA capable) may sense a trajectory path conflict based on the broadcast messages received from other UAVs (e.g., UAV2) and compare the trajectory path conflict with UAV1's own trajectory and position. Optionally, at 404, UAV1 may request accurate location information of UAV2 and any other UAVs (including its own ID and the ID of the peer WTRU) from the location service (LCS) via the USS. UAV1 may request this information directly if UAV1 has obtained pre-authorization for such operation and the USS has notified the LCS of such authorization, including the user ID of UAV1, such as GPSI, SUPI, GUTI, or CAA level UAV ID. At this step, UAV1 may notify USS1 of the detected potential collision with UAV 2 and include information such as UAV2. Alternatively, if LCS 430 is not available, the UAV may also be able to operate without LCS / USS connection to support scenarios where the UAV is out of coverage. In this case, the UAV may rely solely on position estimates from onboard sensors.

[0116] At 405, UAV1 may trigger a direct communication request to the lower layer via PC5 (broadcast or unicast). The intermediate UAV layer may perform communication mode selection based on input received from the application layer, i.e., PC5 broadcast or PC5 unicast for direct communication (see respectively). Figure 4 406 or 407) or for Uu via USS.

[0117] If broadcast is selected for direct communication, at 406 (a), UAV1 may broadcast a message; for example, a safety message or a conflict resolution message, which may be an application layer message. The broadcast conflict resolution message may include DAA capabilities, collision detection alerts, CAA-level UAV IDs of itself and other UAVs, and / or trajectory correction information for collision avoidance. The broadcast conflict resolution message may also include the frequency of subsequent messages exchanged between UAVs for traffic conflict resolution and / or position / trajectory monitoring. At 406 (b), UAV2 may also broadcast a message and may include DAA capabilities, conflict resolution confirmation (when applicable), and / or CAA-level UAV IDs of participating UAVs from the receiving UAV. At 406 (a) and 406 (b), UAV1 and UAV2 may periodically send one or more broadcast messages, including updated real-time position / trajectory information from the detection of traffic conflict (a) and the issuance of a signal until it is finally resolved.

[0118] If unicast is selected for direct communication, then at 407(a), without 5G PC5 ProSe discovery, UAV1 may initiate a PC5 link establishment request and may include DAA capabilities, DAA resolution strategy (e.g., local and / or central), collision detection alert, and / or WTRU IDs for UAV1 and UAV2. At 407(b), UAV2 may receive and respond to the request from UAV1 as a PC5 link establishment response and may include DAA capabilities, agreed-upon DAA resolution strategy, confirmed collision detection alert, and / or WTRU IDs for UAV1 and UAV2. At 407(c), a unicast link may be established and a path may be negotiated between the UAVs (e.g., UAV1 and UAV2) to resolve the conflict. At 407(d), the UAVs may exchange PC5-s messages based on the agreed-upon DAA strategy, for example, UAV1 may transmit a keep-alive message to UAV2 that carries an expected or new trajectory, real-time position / velocity, and / or a collision end indication. If a central resolution is performed, the UAV may receive new trajectory information from the USS and notify other UAVs of the central resolution status. At 407(e), once the conflict is resolved, a unicast link disconnect request may be initiated, which may be initiated by either UAV1 or UAV2, i.e., UAV2 may initiate a unicast link disconnect request at 407(e). Figure 4 407(e) is shown as the initiator. Step 408: UAV1 transmits a conflict resolution indication to USS1. Figure 4 , UAS-NF 440 is shown for reference because the UAS-NF may provide UAS-specific processes such as US UAV authorization / authentication (UUAA) and UAS tracking.

[0119] Optionally, UAV1 may notify USS1 of the conflict resolution with UAV2, wherein USS1 may coordinate with USS2 for long-term conflict resolution. For example, the long-term conflict resolution may include an indication of the flight path conflict resolution (including a new trajectory to UAV1) for long-term flight path correction by considering other UAVs along the flight path of at least UAV1 and / or UAV2. Figures 6 to 9 Long term flight path conflict resolution is described in more detail further on.

[0120] USS-assisted conflict resolution

[0121] In another embodiment, one or more UAVs may be inactive (passive) and may not be able to detect and avoid collisions locally. For such UAVs, the USS may perform DAA based on the tracking trajectories of the UAVs and may compare them with information received from other UAVs directly or via their USSs. Such UAVs may be referred to as non-DAA capable UAVs and may not broadcast DAA capabilities in their broadcast messages.

[0122] refer to Figure 5 The steps of the conflict resolution process assisted by USS are described below. Figure 5 At 501 of the communication, when performing initial registration or authorization with a USS, UAV1 510 and UAV2 520 may communicate their DAA capabilities (if DAA capable) to the respective USS. For example, UAV1 510 may communicate DAA capabilities to USS1 550, and UAV2 520 may communicate its DAA capabilities to USS2 560, but only if UAV2 has DAA capabilities. At 501, UAV2 520 may or may not notify USS2 560 of its lack of DAA capabilities. When providing DAA capabilities, the UAVs may include additional information (such as an identifier (e.g., CAA level UAVID), an onboard camera, or other safety features) as part of the DAA capabilities. In this example, at least one UAV may not have DAA capabilities.

[0123] At 502, at the application layer, UAV1 may detect a collision with the aid of onboard sensors. If an application in UAV1 detects a collision, it may trigger a collision avoidance / conflict resolution. Alternatively, at 502a, at the application layer, the application client of UAV1 may sense a collision based on broadcast messages received from other UAVs (e.g., UAV2) and compare it with its own trajectory and position.

[0124] exist Figure 5At communication 503, if the application in the UAV detects a collision, it can trigger network-assisted avoidance / collision resolution. If the UAV is active (DAA-capable), the UAV can notify the USS of the expected collision, including the CAA-level UAV ID of the other UAV, location information (current location and time, flight path information and / or current speed), the DAA capability status of the other UAV, and / or the USS address. Alternatively, if the UAV is passive (not DAA-capable), the UAV can pass the received information to the USS, including the CAA-level UAV ID of the other UAV, location information (current location and time, flight path information and / or current speed), the DAA capability status of the other UAV, and / or the USS address.

[0125] At 504, the UAVs may have reported their positions to the LCS 530, which improves the position estimate and keeps track of the trajectory, and / or the LCS itself may be tracking their positions and trajectories. If the UAV is active (DAA-capable), the UAV may query the LCS (including its own ID and / or the ID of the peer WTRU) to request accurate position and trajectory estimates from the LCS when a potential collision is detected, and the LCS may transmit this information to the relevant USS. Alternatively, if the UAV is passive (e.g., not DAA-capable), the USS may query the LCS to request accurate position and trajectory estimates of other UAVs from the LCS directly and / or via the UAV's USS.

[0126] At 505 , USS1 may interact with USS2 and negotiate a short-term or long-term flight plan for the conflicting UAVs, depending on whether the destination is known, to avoid future collisions between the particular two UAVs.

[0127] At 506, an application message may be transmitted from the USS to the UAV and suggest a correction to the flight path to avoid a collision. Figure 5 , UAS-NF 540 is shown for reference because the UAS-NF may provide UAS-specific processes such as USS UAV Authorization / Authentication (UUAA) and UAS tracking.

[0128] Network-triggered conflict alerts and resolution

[0129] One or more UAV conflict and collision analysis functions (UCCAFs) may be supported in 5GC. UCCAF may provide DAA as a service to its users (e.g., USS networks, UAV operators, CAA, etc.). The main roles of UCCAF include one or more of the following.

[0130] In the first major role, the UCCAF can track all UAVs in one or more geographic conflict resolution zones (CRZs) and monitor the mobility information (position, altitude, speed, direction, etc.) of the UAVs in the zone. These zones can be planned according to the density of UAV flights. For example, dense flight areas (e.g., above metropolitan areas) may have smaller zones, while non-dense flight areas may have larger zones. The UCCAF can utilize the existing UAV tracking procedures (5.3 in 3GPP TS23.256, "Support of Uncrewed Aerial Systems (UAS) connectivity, identification and tracking", v17.0.0) for the list of UAVs within the zone for which it is responsible.

[0131] In the second main role, the UCCAF may retrieve real-time mobility information from the LCS or USS and analyze the possibility of any potential conflicts or collisions in the area for which it is responsible. The UCCAF may act as an LCS client and retrieve mobility information from the LCS using existing procedures (e.g., MT-LR procedures in TS23.273), or the UCCAF may be part of the GMLC function, where mobility information of the WTRU / UAV is readily available. The UCCAF may interact with multiple USSs for feeding real-time mobility information of the UAVs via a web interface or via the UAS NF in the 5GC. The UCCAF may also be part of the UAS NF. The UCCAF may also be configured with information (e.g., location, altitude, etc.) of high-rise objects (buildings, towers, mountains, etc.) in the area. The UCCAF may be an AF (e.g., part of or external to a USS network) that may interact with one or more networks (e.g., via a UAS NF) on behalf of one or more USSs.

[0132] In the third major role, when the UCCAF determines that one or more UAVs are at risk of potential conflict or collision, it can trigger the network to transmit an alarm / warning message to the UAVs, their controllers and / or USSs. If the UCCAF is authorized to do so, the UCCAF can also provide flight path adjustments or maneuvering recommendations directly to the WTRU via the network.

[0133] Multiple UCCAFs within a PLMN may interact and exchange information with each other when necessary. In an area that may be covered by multiple PLMNs, the UCCAF in one PLMN may interact with the UCCAFs in other PLMNs to determine and resolve conflict risks.

[0134] refer to Figure 6, UCCAF 600 may provide conflict monitoring and resolution services to all UAVs in the area it is responsible for by default. Alternatively, UCCAF may provide such services to one or more UAVs upon request of USS or UAS NF. In the former case, UCCAF may periodically receive presence information of UAVs in its CRZ 602 and monitor the mobility / tracking information of these UAVs. In the latter case, UCCAF may determine the CRZ where the target UAV is located (which may change along the flight path of the UAV) and monitor the mobility / tracking information of all UAVs in that particular CRZ.

[0135] Figure 7 Depicted are steps of a process in which a UCCAF 720 monitors all UAVs 710 in its CRZ for collision risk. Figure 7 At message 701 of 3GPP TS 23.256, UCCAF may obtain a list of UAVs in its CRZ by using a similar process described in Section 5.3.4 of 3GPP TS 23.256. UCCAF may initiate a UAV list request on behalf of USS 750 and may provide the geographic information of its CRZ to UAS NF 730. If the CAA-level UAV ID is not received in the list, UCCAF may further query the UAS NF for the corresponding CAA-level UAV ID.

[0136] exist Figure 7 At message 702a of , after obtaining the list of UAVs in the CRZ, the UCCAF (acting as an LCS client) may receive periodic location information of the UAV using the periodic MT-LR location reporting procedure defined in Section 6.3.1 or TS23.273. Alternatively, at 702b, the UCCAF may retrieve real-time tracking information directly from the USS responsible for the UAV, for example via a web interface.

[0137] Based on the received position / tracking information, the UCCAF may perform real-time intelligent analysis of potential conflicts and collision risks for all UAVs in the CRZ at 703. The UCCAF may be configured with a "minimum clearance" parameter to determine the risk.

[0138] At 704a, if the UCCAF determines that one or more groups of WTRUs may be involved in a potential conflict or collision, the UCCAF may transmit a conflict warning message to the responsible USS responsible for those UAVs at risk, for example, via a web interface. The UCCAF may indicate the identifier of the UAV at risk and / or the estimated time and location of the potential conflict or collision. The UCCAF may also recommend flight path adjustments or UAV maneuvers that are less likely to result in another conflict / collision. Based on the received warnings and / or recommendations, the USS may notify the UAVs and / or their UAV-Cs of the warnings and recommended flight path updates and maneuvers.

[0139] Alternatively, at 704b, the UCCAF may transmit a warning event to the USSAF via the UAS NF using a network event exposure mechanism. At 704c, a conflict warning event notification may be transmitted from the UAS NF to the USS.

[0140] At 705, if the UCCAF and / or UAS NF is configured or authorized to directly warn the UAV, the UAS NF may transmit a NAS conflict warning message to the UAV via the AMF or SMF. The NAS message may also contain flight path adjustments and / or maneuvering recommendations. If the UAV is configured to directly follow the recommendations from the UCCAF / UAS NF, it may take action accordingly; otherwise, the UAV may report the warning and recommendations back to the USS or its UAV-C and wait for further instructions.

[0141] Figure 8 The steps of a process applicable in the case where the UCCAF 820 monitors one or more UAVs 810 for collision risk at the request of the USS-1 850 are depicted as follows. Figure 8 At message 801 of , USS-1 850 may transmit a conflict monitoring request to UCCAF 820 via UAS NF 830. USS-1 may provide the target UAV identifier (e.g., GPSI and / or CAA level ID) and its current tracking information. USS-1 may also provide the UCCAF with a geographic area to monitor all of its UAVs in that area, and USS-1 may provide some requirements, such as a "minimum clearance" for conflict / collision monitoring. USS-1 may also indicate whether a flight path adjustment recommendation is needed in the event of a conflict.

[0142] exist Figure 8 At message 802 of the UCCAF, the UCCAF may periodically obtain the location information of the target UAV from the LCS. At 803, the UCCAF may determine which CRZ the WTRU is currently in. The UCCAF may do this periodically as the UAV changes position along the flight path. If the geographic area to be monitored is provided by the USS, the UCCAF may map the geographic area to the CRZ for which it is responsible.

[0143] At 804, the UCCAF may obtain a list of all UAVs within the same CRZ. At 805, the remaining process is similar to that described above. Figure 7 Messages 802 to 805.

[0144] DAA support using enhanced UAE

[0145] UAE client registration with UAE server

[0146] Using enhanced UAE, in a method for DAA support capability registration between a UAE client and a UAE server, the UAE client may transmit a registration request including DAA capabilities to the UAE server. The UAE client may indicate the UAE client DAA capabilities and UAE client context information (e.g., the frequency of broadcasting UAV mobility information (location, direction and / or speed)). The UAE server may also indicate the UAE server DAA capabilities and possible UAE server context information to the serving USS (e.g., the network area that the UAE server can use for DAA purposes based on network coverage information). The UAE server may perform one or more authentication and authorization checks, and may interact with the USS in the process to indicate the DAA capabilities and identification information of the UAA client / server. If the UAE server supports such capabilities, the UAE client may receive a registration response including a success indication from the UAE server.

[0147] DAA Management / DAA Configuration

[0148] Using enhanced UAE, in a method for enabling DAA support in a UAE client upon request from a USS, a UAE server may receive a DAA management request for managing DAA from a serving USS. The request may include UAV (UAE client) identification information and / or DAA configuration parameters / DAA policies. The UAE server may transmit a response confirming support based on the UAE client and server's support for such capabilities. The UAE client may receive a DAA configuration request including DAA configuration parameters / DAA policies from the UAE server. The policy may include parameters / rules regarding whether and how the UAE client takes action regarding detection and / or avoidance. For example, the policy may include rules for UAV communication with USS and / or other UAVs (i.e., for central and / or local flight path conflict resolution) to indicate possible interfering objects based on the policy and / or perform changes in the expected forward path or altitude due to interfering objects. For example, DAA policy rules may be applied considering whether the UAV is within or outside the network coverage. The UAE client may store DAA configuration parameters and transmit a DAA support configuration response to the server. The UAE server may transmit to the USS an acknowledgement that the DAA information was provided to the UAE client. The UAE client / server may use the provided DAA policy to prevent collisions in flight.

[0149] UAE layer assisted DAA

[0150] Using enhanced UAE, in a method for dynamically changing the current path upon request from a USS and / or based on a UAE client / server configuration due to DAA, the USS, UAE server, and / or UAE client may notice that the expected flight path needs to be changed due to an identified object that may interfere with the UAV and potentially cause a dangerous situation. The UAE server may receive a DAA request from the USS. The request may include UAV (UAE client) identification information and / or actions taken to avoid collisions. The UAE server may verify that the request is authorized. The UAE client may receive a DAA request from the UAE server and actions to be taken to avoid collisions. The UAE client may act accordingly. Alternatively, for example, when a UAA policy from the application layer or a UAV internal function identifies an anomaly, the UAE client may initiate a change in the flight path based on a previously received DAA policy without any external indication (i.e., without an explicit request from the UAE server). The UAE client may transmit a DAA response to notify the UAE server. The UAE server may update the USS accordingly.

[0151] Alternatively, the UAE server may initiate a flight path change (on behalf of the USS) based on the DAA capabilities and policies provided by the USS. For example, if the UAE server is allowed to initiate a flight path change due to the DAA policy (e.g., after the UAE server determines that a flight path change is required).

[0152] Support for DAA at the UAE layer - Call flow

[0153] Using Enhanced UAE, Fig. 9 The following illustrates the process of UAE support for DAA operation as described above. Fig. 9 , the steps of the process for UAE layer support of multi-USS operation are described as follows. At 901, a UAE client (UAV) 920 may transmit a registration request to a UAE server 930, including an indication of DAA capabilities. At 902, the UAE server may perform authentication and authorization checks, and may interact with the USS 940 in the process and indicate the DAA capabilities and identification information of the UAE client. At 903, the UAE client may receive a registration response from the UAE server with an indication of authorization for DAA support.

[0154] At 904, the UAE server may receive a DAA management request from the serving USS for managing support for DAA. The request may include UAV (UAE client) identification information and DAA configuration parameters. If the request is to add a configuration, the UAE server may store the configuration parameters associated with the DAA in the UAE client context. If the request is to remove a configuration, the UAE server may check that the configuration is associated with the requesting USS before deleting the configuration from the UAE client context and transmitting the request to the UAE client.

[0155] At 905, the UAE client may receive a DAA configuration request from the UAE server. The request may be to add or delete a DAA configuration. At 906, if the request is to add (or respectively delete) a configuration, the UAE client may store (or respectively delete) the DAA configuration associated with the USS. At 907, the UAE client may transmit a DAA support configuration response to the server to confirm the addition / removal of the configuration. At 908, the UAE server may transmit a response to the USS indicating the enabling or disabling of the DAA capability.

[0156] In one situation, a UAE client (UAV) may initiate a DAA alert. Fig. 9 , depicted at 909a, 909b, 910a, and 910b in FIG. 1 . At 909a, the UAE client may transmit a DAA alert to the UAE server indicating a detected or resolved flight path conflict with one or more nearby UAVs. The message may include an updated trajectory and a reason for the DAA alert. In response, at 909b, the UAE server may transmit the DAA alert to the USS. At 910a, the USS may confirm the alert to the UAE server. At 910b, the UAE server may transmit a DAA alert confirmation to the UAE client (UAV).

[0157] In another case, the USS may initiate a DAA alert. Fig. 9 1 and 12. The USS may transmit a DAA alert to the UAE server at step 911a, 911b, 912a, and 912b. At step 911a, the USS may transmit a DAA alert to the UAE server indicating a detected or resolved flight path conflict with one or more nearby UAVs. The DAA alert message may include an updated trajectory and a reason for the DAA alert. The UAE server may verify whether the received DAA alert is authorized.

[0158] At 911b, the UAE server may transmit a request to change the flight path to the UAE client. At 912a, the UAE client (UAV) may confirm the alert to the UAE server. At 912b, the UAE server may transmit a DAA alert confirmation to the USS.

[0159] At 913, the UAE server may receive a DAA flight path update request from the UAE server. At 914, the UAE client (UAV) may receive a flight path update request from the UAE server.

[0160] At 915, the UAE client may perform a change in the flight path according to the DAA based on the request and / or the DAA configuration. The UAE layer may notify the application in the client. At 916, the UAE client may transmit a DAA flight path update response to the UAE server to indicate the change in the flight path of the client UAV. The UAE client may include relevant additional information about the reason for changing the flight path and the actual new flight path in the message. At 917, the UAE server may transmit a DAA flight path response to the USS to indicate the change in the flight path. The UAE server may include relevant additional information about the reason for changing the flight path and the actual new flight path in the message.

[0161] Fig.10 A method 1000 performed by a wireless transmit / receive unit (WTRU) implemented in a first unmanned aerial vehicle (UAV1) is illustrated. At 1005, the WTRU registers the WTRU's detect and avoid capabilities with an unmanned aerial system (UAS) service provider (USS) in a sent registration message. Registering the DAA capabilities of UAV1 with the USS may include sending one or more of an identifier of UAV1 and a hardware capability profile to the USS.

[0162] At 1010, the WTRU in UAV1 detects a flight path conflict with a second UAV (UAV2). The detection of the flight path conflict may include receiving a broadcast message from UAV2 and determining whether UAV1 and UAV2 have a flight path conflict based on the broadcast message. The determination may be made at an application layer of UAV1. The broadcast message from UAV2 may include one or more of a UAV2 identifier, a UAV2 speed, a UAV2 heading direction, and a UAV2 position. Detecting the flight path conflict with UAV2 may include obtaining location information of UAV2 using a network location service (LCS) and determining that a flight path conflict exists between UAV1 and UAV2.

[0163] At 1015, the WTRU selects a communication mode with UAV2. The communication mode is one of a broadcast mode or a unicast mode. The selected mode may be a direct communication request over a PC5 link.

[0164] If the unicast mode of the communication mode is selected at 1015 , UAV1 initiates a PC5 link establishment request.

[0165] If the broadcast communication mode is selected at 1015 , UAV1 broadcasts UAV1 and UAV2 identifiers, UAV1 DAA capabilities, and trajectory correction information for avoiding a collision between the two UAVs.

[0166] At 1020, the DAA capabilities and conflict resolution message of UAV1 are sent to UAV2 based on the selected mode (unicast or broadcast).

[0167] If the unicast mode of the communication mode is selected at 1015, the transmission at 1020 includes UAV1 initiating a PC5 link establishment request. The establishment request may include UAV1 and UAV2 identifiers, UAV1 DAA capabilities, DAA resolution strategies, a conflict resolution message that may include DAA capabilities, a collision detection alert, CAA-level UAV IDs of UAV1 and UAV2, and trajectory correction information for avoiding collisions of two or more UAVs. The conflict resolution message may be similar to or equivalent to Fig. 9 Track correction information may be transmitted via unicast keep-alive messages.

[0168] If the broadcast communication mode is selected at 1015, the transmission at 1020 includes UAV1 broadcasting a conflict resolution message, which may include UAV1 and UAV2 identifiers, UAV1 DAA capabilities, and trajectory correction information for avoiding a collision between the two UAVs.

[0169] At 1025, a trajectory correction is performed by one of the UAVs to avoid a collision between the UAVs. Optionally, at 1030, at least one of the UAVs may also send an indication of the flight path conflict resolution to the USS.

[0170] In an example embodiment, a method performed by a WTRU implemented in a first UAV (UAV1) includes registering DAA capabilities of UAV1 with a USS in a registration message sent by UAV1. UAV1 detects a flight path conflict with a second UAV (UAV2). UAV1 selects a communication mode with UAV2, wherein the communication mode is one of a broadcast communication mode or a unicast communication mode. UAV1 sends the DAA capabilities of UAV1 to UAV2 in a conflict resolution message based on the selected communication mode, and thereafter avoids the collision by performing a trajectory correction.

[0171] In an example embodiment, registering DAA capabilities with the USS includes sending one or more of an identifier of UAV1 and a hardware capability profile of UAV1 to the USS. UAV1 detects a flight path conflict by receiving a broadcast message from UAV2 and determining whether UAV1 and UAV2 have a flight path conflict based on the broadcast message. The broadcast message from UAV2 may include one or more of a UAV2 identifier, a UAV2 speed, a UAV2 heading direction, and a UAV2 position. Detecting a flight path conflict with UAV2 may also include or optionally include obtaining location information of one or more of UAV1 and UAV2 using a network location service and determining that a flight path conflict exists between UAV1 and UAV2.

[0172] When a direct communication request through the PC5 link is selected, UAV1 can select a communication mode with UAV2, where the selection of the communication mode is performed at the UAV application layer.

[0173] UAV1 may signal the DAA capability of UAV1 to UAV2 in a conflict resolution message by sending a conflict resolution message including one or more of the DAA capability, a collision detection alert, a UAV identifier, and trajectory correction information.

[0174] In an example embodiment, UAV1 may send UAV1's DAA capabilities and conflict resolution messages to UAV2 based on the selected communication mode by selecting a unicast communication mode, wherein UAV1 initiates a PC5 link establishment request. The request includes UAV1 and UAV2 identifiers, UAV1 DAA capabilities, DAA resolution strategies, collision detection alerts, and trajectory correction information for collision avoidance. The trajectory correction information may be sent using a unicast keep-alive message.

[0175] In an alternative or additional method of sending UAV1's DAA capabilities and conflict resolution messages to UAV2 based on the selected communication mode, UAV1 may select a broadcast communication mode in which UAV1 broadcasts UAV1 and UAV2 identifiers, UAV1 DAA capabilities, and trajectory correction information for collision avoidance.

[0176] UAV1 may also receive an indication of one or more of DAA capability, collision resolution confirmation, and a new trajectory from UAV2. UAV1 may also send an indication of flight path conflict resolution to the USS. The indication of flight path conflict resolution may include a new trajectory to UAV1 for long-term flight path correction by taking into account other UAVs along the flight path of at least one of UAV1 and UAV2.

[0177] In an example embodiment, the WTRU may include circuitry including a transmitter, a receiver, a processor, and a memory implemented in a first UAV (UAV1). The WTRU in UAV1 may be configured such that the WTRU is configured to register the DAA capability with the USS in a registration message sent by the WTRU. The WTRU may detect a flight path conflict with a second UAV (UAV2) and select a communication mode with UAV2. The communication mode may be one of a broadcast communication mode or a unicast communication mode. The WTRU of UAV1 may send the DAA capability of UAV1 to UAV2 in a conflict resolution message based on the selected communication mode and avoid collision by performing trajectory correction.

[0178] The WTRU registers the DAA capability with the USS by sending one or more of an identifier of UAV1 and a hardware capability profile of UAV1 to the USS. The WTRU detects a flight path conflict by receiving a broadcast message from UAV2 and may determine whether UAV1 and UAV2 have a flight path conflict based on the broadcast message. The broadcast message from UAV2 may include one or more of a UAV2 identifier, a UAV2 speed, a UAV2 heading direction, and a UAV2 position.

[0179] In addition, the WTRU may detect a flight path conflict with UAV2 by obtaining location information of one or more of UAV1 and UAV2 using a location service of the USS and determining that a flight path conflict exists between UAV1 and UAV2.

[0180] The WTRU may send a direct communication request over a PC5 link to communicate with UAV2. The WTRU may send the DAA capabilities of UAV1 to UAV2 in a conflict resolution message based on selecting a unicast communication mode, wherein UAV1 initiated the PC5 link establishment request. The request may include UAV1 and UAV2 identifiers, UAV1 DAA capabilities, DAA resolution strategy, collision detection alert, and trajectory correction information for collision avoidance, wherein the trajectory correction information may be a unicast keep alive message. The conflict resolution message may include one or more of the DAA capabilities, collision detection alert, UAV identifier, and trajectory correction information.

[0181] The WTRU may send UAV1's DAA capability and collision resolution message to UAV2 based on selecting a broadcast communication mode, wherein UAV1 broadcasts UAV1 and UAV2 identifiers, UAV1 DAA capability, and trajectory correction information for collision avoidance. The WTRU may also receive an indication of one or more of the DAA capability, collision resolution confirmation, and new trajectory from UAV2.

[0182] The WTRU may also send an indication of a flight path conflict resolution to the USS. The indication of a flight path conflict resolution may include a new trajectory for UAV1 for long-term flight path correction by considering other UAVs along the flight path of at least one of UAV1 and UAV2.

[0183] in conclusion

[0184] Although features and elements are provided above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended to be illustrative of various aspects. Many modifications and variations can be made without departing from the essence and scope of the present invention, as they will be apparent to those skilled in the art. Unless explicitly provided as such, any element, action or description used in the present application specification should not be understood as being essential or necessary to the present invention. According to the foregoing description, in addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only to the terms of the appended claims and the full range of equivalent forms of such entitled claims. It should be understood that the present disclosure is not limited to a specific method or system.

[0185] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of infrared capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but may be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0186] It should also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed on a time basis. For example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a plurality of embodiments of the WTRU; (iii) a wireless and / or wired (e.g., tetherable) device configured with (in particular) some or all of the structure and functionality of the WTRU; (iii) a wireless and / or wired device configured with less than all of the structure and functionality of the WTRU; or (iv), etc. This document is relative to Figures 1A to 1DDetails of an example WTRU are provided that may represent any WTRU described herein. As another example, various disclosed embodiments herein above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0187] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired connection or a wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0188] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments that can be applied, it should be understood that the embodiments shown are merely examples and should not be considered as limiting the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0189] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to the symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being "executed", "computer executed" or "CPU executed".

[0190] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation of electrical signals or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and performing other processing of signals. The memory location that holds the data bits is a physical location that has specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0191] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage system readable by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside solely on the processing system or distributed across multiple interconnected processing systems that may be local or remote relative to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may also support the provided methods.

[0192] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0193] There is little difference between hardware implementation and software implementation of various aspects of the system. The use of hardware or software is usually (but not always, because in some contexts, the choice between hardware and software may become important) a design choice that represents a trade-off between cost and efficiency. There may be various media (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary with the context of the deployment process and / or system and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a specific implementation that is primarily software. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0194] The above detailed description has listed various embodiments of the device and / or process by using block diagrams, flow charts and / or examples. In the case where such block diagrams, flow charts and / or examples include one or more functions and / or operations, it should be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or almost any combination thereof. In one embodiment, several parts of the subject matter described herein can be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in integrated circuits as a whole or in part as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware or almost any combination thereof, and according to the present disclosure, designing circuits and / or writing software and / or firmware codes will be completely within the technical scope of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0195] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally may include one or more of the following: a system unit housing; a video display device; a memory, such as a volatile memory and a non-volatile memory; a processor, such as a microprocessor and a digital signal processor; a computing entity, such as an operating system, a driver, a graphical user interface, and an application; one or more interactive devices, such as a touch pad or a screen; and / or a control system, including a feedback loop and a control motor (e.g., a feedback for sensing position and / or velocity, a control motor for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0196] The subject matter described herein sometimes illustrates different components included in or connected to different other components.It should be understood that such depicted architectures are merely examples, and in fact many other architectures that achieve the same function can be realized.In a conceptual sense, any arrangement of components that achieve the same function is effectively "associated" so that the desired function can be achieved.Therefore, any two components that are combined to achieve a specific functionality herein can be considered to be "associated" with each other so that the desired functionality can be achieved, regardless of the architecture or intermediate components.Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired function, and any two components that can be so associated can also be considered to be "operably coupleable" to each other to achieve the desired function.Specific examples of operable coupling include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or wirelessly interact and / or components that can logically interact and / or components that can logically interact.

[0197] With respect to substantially any plural and / or singular terms used herein, those skilled in the art may translate from the plural to the singular and / or from the singular to the plural as appropriate, as appropriate to the context and / or application. For clarity, various singular / plural arrangements may be explicitly listed herein.

[0198] It will be understood by those skilled in the art that, in general, the terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", etc.). It will also be understood by those skilled in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly stated in the claim, and in the absence of such a recitation, there is no such intent. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as implying that any particular claim including such introduced claim recitations is limited to an embodiment including only one such recitation by the indefinite article "a" or "an" to introduce the claim recitation. This is true even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "a kind" (e.g., "a" and / or "a kind" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the stated number (e.g., a bare recitation of "two recitations" without other modifiers means at least two recitations or two or more recitations). In addition, in those instances where a convention similar to "at least one of A, B, and C, etc." is used, generally speaking, the meaning of such construction is that one skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, a system having A alone, B alone, C alone, A and B simultaneously, A and C simultaneously, B and C simultaneously, and / or A, B, and C simultaneously, etc.). In those instances where a convention similar to "at least one of A, B, or C, etc." is used, generally speaking, the meaning of such construction is that one skilled in the art will understand the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). One skilled in the art will also understand that, in fact, any discrete words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, any of the terms, or both of the terms.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" followed by a listing of multiple items and / or multiple categories of items is intended to include "any of," "any combination," "any multiples," and / or "any combination of multiples" of the items and / or categories of items, either alone or in combination with other items and / or other categories of items. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "quantity" is intended to include any quantity, including zero. And, as used herein, the term "plurality" is intended to be synonymous with "multiple."

[0199] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also described in terms of any individual member or subgroup of members of the Markush group.

[0200] As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of their sub-ranges. Any listed range can be easily identified as fully describing and enabling the same range to be divided into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily divided into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "up to", "at least", "greater than", "less than", etc. include the cited numbers and refer to the ranges that can be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the range includes each individual number. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2 or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4 or 5 units, etc.

[0201] Furthermore, the claims should not be read as limited to the order or elements presented unless otherwise stated. Furthermore, the use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, 6 or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

[0202] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or state machine.

[0203] The WTRU may be used in conjunction with a module, which may be implemented in hardware and / or software including: software defined radio (SDR) and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0204] Although various embodiments have been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0205] Furthermore, while the invention has been shown and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU) implemented in a first unmanned aerial vehicle (UAV1), the method comprising: registering the detect and avoid (DAA) capability of the UAV1 with an unmanned aerial system service provider (USS) in a registration message sent by the UAV1; detecting a flight path conflict with a second UAV (UAV2); selecting a communication mode with the UAV2, wherein the communication mode is one of a broadcast communication mode or a unicast communication mode; Based on the selected communication mode, sending the DAA capabilities of the UAV1 to the UAV2 in a conflict resolution message; as well as Avoid collisions by performing trajectory corrections. 2 . The method of claim 1 , wherein registering the DAA capability with the USS comprises sending one or more of an identifier of the UAV1 and a hardware capability profile of the UAV1 to the USS.

3. The method according to any one of claims 1 to 2, wherein detecting a flight path conflict comprises receiving a broadcast message from the UAV2 and determining whether the UAV1 and the UAV2 have the flight path conflict based on the broadcast message.

4. The method of claim 3, wherein the broadcast message from UAV2 includes one or more of the UAV2 identifier, UAV2 speed, UAV2 heading direction, and UAV2 position.

5. The method according to any one of claims 1 to 4, wherein detecting a flight path conflict with UAV2 comprises obtaining location information of one or more of UAV1 and UAV2 using a network location service and determining that a flight path conflict exists between UAV1 and UAV2.

6. The method of any one of claims 1 to 5, wherein selecting a communication mode with UAV2 comprises selecting a direct communication request over a PC5 link, wherein selecting the communication mode is performed at the UAV application layer.

7. The method according to any one of claims 1 to 6, wherein sending the DAA capability of the UAV1 to the UAV2 in a conflict elimination message includes sending a conflict elimination message, the conflict elimination message including one or more of the DAA capability, a collision detection alert, a UAV identifier, and trajectory correction information.

8. The method according to any one of claims 1 to 7, wherein sending the DAA capability of the UAV1 and the conflict elimination message to the UAV2 based on the selected communication mode includes selecting a unicast communication mode, wherein UAV1 initiates a PC5 link establishment request, the request including UAV1 and UAV2 identifiers, the UAV1 DAA capability, a DAA resolution strategy, a collision detection alert, and trajectory correction information for avoiding collision.

9. The method of claim 8, wherein the trajectory correction information is sent using a unicast keep-alive message.

10. The method according to any one of claims 1 to 9, wherein sending the DAA capability and conflict elimination message of the UAV1 to the UAV2 based on the selected communication mode includes selecting a broadcast communication mode, wherein UAV1 broadcasts the UAV1 and UAV2 identifiers, the UAV1 DAA capability and trajectory correction information for avoiding collision.

11. The method according to any one of claims 1 to 10, further comprising: An indication of one or more of DAA capability, collision resolution confirmation, and a new trajectory is received from the UAV2.

12. The method according to any one of claims 1 to 11, further comprising: An indication of a flight path conflict resolution is sent to the USS.

13. The method of claim 12, wherein the indication of a flight path conflict resolution comprises a new trajectory to the UAV1 for long-term flight path correction by taking into account other UAVs along a flight path of at least one of the UAV1 and the UAV2.

14. A wireless transmit / receive unit (WTRU) implemented in a first unmanned aerial vehicle (UAV1), the WTRU comprising circuitry, the circuitry comprising a transmitter, a receiver, a processor, and a memory, the WTRU being configured to: registering a detect and avoid (DAA) capability with an unmanned air system service provider (USS) in a registration message sent by the WTRU; detecting a flight path conflict with a second unmanned UAV (UAV2); selecting a communication mode with the UAV2, wherein the communication mode is one of a broadcast communication mode or a unicast communication mode; Based on the selected communication mode, sending the DAA capabilities of the UAV1 to the UAV2 in a conflict resolution message; Avoid collisions by performing trajectory corrections.

15. The WTRU of claim 14, wherein the WTRU registers the DAA capability with the USS by sending one or more of an identifier of the UAV1 and a hardware capability profile of the UAV1 to the USS.

16. The WTRU according to any one of claims 14 to 15, wherein the WTRU detects a flight path conflict by receiving a broadcast message from the UAV2, and determines whether the UAV1 and the UAV2 have the flight path conflict based on the broadcast message.

17. The WTRU of claim 16, wherein the broadcast message from the UAV2 includes one or more of the UAV2 identifier, UAV2 speed, UAV2 heading direction, and UAV2 position.

18. The WTRU according to any one of claims 14 to 17, wherein the WTRU detects a flight path conflict with UAV2 by obtaining location information of one or more of UAV1 and UAV2 using a location service of the USS and determining that a flight path conflict exists between UAV1 and UAV2.

19. The WTRU of any one of claims 14 to 18, wherein the WTRU sends a direct communication request over a PC5 link to communicate with the UAV2.

20. A WTRU according to any one of claims 14 to 19, wherein the WTRU sends the DAA capability of the UAV1 to the UAV2 in a conflict elimination message based on selecting a unicast communication mode, wherein the UAV1 initiates a PC5 link establishment request, the request including UAV1 and UAV2 identifiers, the UAV1 DAA capability, a DAA resolution strategy, a collision detection alert, and trajectory correction information for avoiding collisions, wherein the trajectory correction information includes a unicast keep-alive message.

21. The WTRU of claim 20, wherein the conflict resolution message includes one or more of a DAA capability, a collision detection alert, a UAV identifier, and trajectory correction information.

22. A WTRU according to any one of claims 14 to 21, wherein the WTRU sends the DAA capability and conflict elimination message of the UAV1 to the UAV2 based on selecting a broadcast communication mode, wherein the UAV1 broadcasts the UAV1 and UAV2 identifiers, the UAV1 DAA capability and trajectory correction information for avoiding collision.

23. The WTRU of any one of claims 14 to 22, further wherein the WTRU receives an indication of one or more of a DAA capability, a collision resolution confirmation, and a new trajectory from the UAV2.

24. The WTRU of any one of claims 14 to 23, wherein the WTRU further sends an indication of flight path conflict resolution to the USS.

25. The WTRU of claim 24, wherein the indication of flight path conflict resolution comprises a new trajectory to the UAV1 for long-term flight path correction by taking into account other UAVs along a flight path of at least one of the UAV1 and the UAV2.

26. A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 13.

Images