Network-assisted KPI-based UAV flight path planning and monitoring

Abstract

A device, method, and system for flight path network data reporting. A request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint is received. In response to the request for the UAV flight path network data report, a request for data analysis information regarding the at least one UAV corresponding to the at least one waypoint is transmitted. In response to the request for data analysis information, data analysis information regarding the at least one UAV corresponding to the at least one waypoint is received. A UAV flight path network data report is transmitted based on the data analysis information. In some implementations, a network device implements a crewless air system network function (UAS-NF). In some implementations, the network device receives a request for a UAV flight path network data report from a UAS service supplier (USS).

Description

[Technical Field]

[0001] This application relates to network-assisted KPI-based UAV flight path planning and monitoring. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 422,188, filed November 3, 2022, the contents of which are incorporated herein by reference.

[0003] Unmanned or crewless aerial vehicles (UAVs) and other types of vehicles operate without an onboard human pilot. Thus, the position and / or heading of a UAV may be obtained in a variety of ways, for example, to facilitate pilotless operation.

[0004] [Summary of the Invention] Some implementations provide a method implemented in a network device. A request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint is received. In response to the request for the UAV flight path network data report, a request for data analysis information regarding the at least one UAV corresponding to the at least one waypoint is transmitted. In response to the request for data analysis information, data analysis information regarding the at least one UAV corresponding to the at least one waypoint is received. The UAV flight path network data report is transmitted based on the data analysis information.

[0005] In some implementations, the network device implements a crewless air system network function (UAS-NF). In some implementations, the network device receives a request for a UAV flight path network data report from a UAS service supplier (USS). In some implementations, the network device sends a request for data analysis information to another network device implementing a network data analysis function (NWDAF), implementing a data collection and coordination function (DCCF), or implementing an analysis and data repository function (ARDF). In some implementations, the data analysis information includes radio access network (RAN) or core network (CN) information. In some implementations, the data analysis information includes network state information, network load information, quality of service (QoS) information, or link quality information. In some implementations, the request for data analysis information includes key performance information (KPI) or UAV information. In some implementations, the network device sends the UAV flight path network data report to the UAS service supplier (USS). In some implementations, the UAV flight path network data report includes UAV position information, key performance information (KPI), or flight path optimization information. In some implementations, the UAV flight path network data report includes information based on statistical information or core network (CN) forecast information.

[0006] Some implementations provide a network device. The network device includes circuitry configured to receive a request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint. The network device also includes circuitry configured to transmit, in response to the request for the UAV flight path network data report, a request for data analysis information regarding at least one UAV corresponding to the at least one waypoint. The network device also includes circuitry configured to receive, in response to the request for data analysis information, data analysis information regarding the at least one UAV corresponding to the at least one waypoint. The network device also includes circuitry configured to transmit a UAV flight path network data report based on the data analysis information.

[0007] In some implementations, the network device comprises circuitry configured to implement a UAS-NF. In some implementations, the network device comprises circuitry configured to receive a request for a UAV flight path network data report from a USS. In some implementations, the network device comprises circuitry configured to send a request for data analysis information to another network device implementing an NWDAF, implementing a DCCF, or implementing an ARDF. In some implementations, the data analysis information includes RAN information or CN information. In some implementations, the data analysis information includes network condition information, network load information, QoS information, or link quality information. In some implementations, the request for data analysis information includes KPI information or UAV information. In some implementations, the network device comprises circuitry configured to send a UAV flight path network data report to a USS. In some implementations, the UAV flight path network data report includes UAV position information, KPI, or flight path optimization information. In some implementations, the UAV flight path network data report includes information based on statistical information or CN prediction information.

[0008] Some implementations provide a method implemented in a network device: a request for a UAV flight path network data report is received; a request for data analysis information is sent in response to the request for the UAV flight path network data report; the data analysis information is received in response to the request for data analysis information; and a UAV flight path network data report is sent based on the data analysis information.

[0009] In some implementations, the network device comprises circuitry configured to implement a UAS-NF. In some implementations, the network device comprises circuitry configured to receive a request for a UAV flight path network data report from a USS. In some implementations, the network device comprises circuitry configured to send a request for data analysis information to another network device implementing an NWDAF, implementing a DCCF, or implementing an ARDF. In some implementations, the data analysis information includes RAN information or CN information. In some implementations, the data analysis information includes network condition information, network load information, QoS information, or link quality information. In some implementations, the request for data analysis information includes KPI information or UAV information. In some implementations, the network device comprises circuitry configured to send a UAV flight path network data report to a USS. In some implementations, the UAV flight path network data report includes UAV position information, KPI, or flight path optimization information. In some implementations, the UAV flight path network data report includes information based on statistical information or CN prediction information.

[0010] Some implementations provide a network device. The network device includes circuitry configured to receive a request for an unmanned aerial vehicle (UAV) flight path network data report. The network device also includes circuitry configured to transmit a request for data analysis information in response to the request for the UAV flight path network data report. The network device also includes circuitry configured to receive data analysis information in response to the request for data analysis information. The network device also includes circuitry configured to transmit a UAV flight path network data report based on the data analysis information.

[0011] In some implementations, the network device comprises circuitry configured to implement a UAS-NF. In some implementations, the network device comprises circuitry configured to receive a request for a UAV flight path network data report from a USS. In some implementations, the network device comprises circuitry configured to send a request for data analysis information to another network device implementing an NWDAF, implementing a DCCF, or implementing an ARDF. In some implementations, the data analysis information includes RAN information or CN information. In some implementations, the data analysis information includes network condition information, network load information, QoS information, or link quality information. In some implementations, the request for data analysis information includes KPI information or UAV information. In some implementations, the network device comprises circuitry configured to send a UAV flight path network data report to a USS. In some implementations, the UAV flight path network data report includes UAV position information, KPI, or flight path optimization information. In some implementations, the UAV flight path network data report includes information based on statistical information or CN prediction information.

[0012] Some implementations provide a system, device, and method implemented in an unmanned aerial system application enabler (UAE) server for flight path quality of experience (QoE) reporting configuration. A flight path QoE reporting configuration request is received from an unmanned aerial system service supplier (USS) server. A flight path QoE reporting configuration response is sent to the USS. The flight path QoE reporting configuration is performed. After successful execution of the flight path QoE reporting configuration, a notification is sent to the USS indicating that the flight path QoE reporting configuration is complete.

[0013] Some implementations provide systems, devices, and methods for flight path Quality of Experience (QoE) reporting. A QoE report is received from an unmanned aerial system application enabler (UAE) client. UAE client current location information is requested from a Service Enabler Architecture Layer (SEAL) location service. The UAE client current location information is received from the SEAL location service. A QoE report including the location information is sent to an unmanned aerial vehicle service supplier (USS). A location report including the QoE information is sent to the USS.

[0014] Some implementations provide systems, devices, and methods implemented in an Uncrewed Air System Network Function (UAS-NF) for KPI-based UAV flight path exposure. A request for a KPI-based UAV flight path report is received by the UAS-NF. One or more requests for data analysis collection are sent by the UAS NF to a Data Collection / Analysis Function (DCCF / NWDAF). Data analysis information is received by the UAS NF from the DCCF / NWDAF. A request is sent by the UAS NF to store the analysis in the ADRF for subsequent USS request. The UAS NF sends the UAV flight path report, including the KPI information, to the USS.

[0015] Some implementations provide systems, devices, and methods implemented in an Unmanned Aerial System Application Enabler (UAE) server for Quality of Experience (QoE) based on UAV flight path monitoring using a UAE layer. An Unmanned Aerial Vehicle (UAV) QoE reporting configuration is received by the UAE server from a UAV Service Supplier (USS) server. The UAV QoE reporting configuration is sent by the UAE server to a UAE client. A QoE report is received by the UAE server from the UAE client. A request for UAE client location information is sent by the UAE server from a Service Enabler Architecture Layer (SEAL) location service. UAE client location information is received by the UAE server from the SEAL location service. A UAV QoE report including the location information is sent to the USS. [Brief explanation of the drawings]

[0016] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which:

[0017] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to an embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Figure 1D] 1B is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to an embodiment. [Figure 2] FIG. 1 is a network diagram illustrating an example architecture for exposing network performance data and / or flight path network KPI data. [Figure 3] 1 is a message sequence chart illustrating an exemplary procedure for flight path network data reporting. [Figure 4] 10 is a message sequence chart illustrating an exemplary flight path QoE reporting configuration procedure. [Figure 5] 1 is a message sequence chart illustrating an exemplary flight path QoE reporting procedure. [Figure 6] 1 is a flowchart illustrating an example process for responding to a request for flight path network data reporting. DETAILED DESCRIPTION OF THE INVENTION

[0018] 1A 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, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as coded multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tailed unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0019] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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 stations (STAs), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronic devices, devices operating in commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as UEs.

[0020] The communications 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106, 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 NodeB, an eNodeB (eNB), a home NodeB, a home eNodeB, a next generation NodeB such as a gNodeB (gNB), a new radio (NR) NodeB, 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 should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0021] The base station 114a may be part of the RAN 104, 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), relay nodes, and the like. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for wireless services for a particular geographic area, which may be relatively fixed or which may change over time. The cell may also be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, 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 transmit and / or receive signals in desired spatial directions.

[0022] 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 communications 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).

[0023] More specifically, as mentioned 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0024] 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 LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

[0025] 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 NR.

[0026] 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 jointly implement LTE and NR radio access, e.g., using a 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 sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0027] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology 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), and the like.

[0028] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology 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 a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet 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 shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0029] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, charging services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it should be understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] The CN 106 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 providing 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 Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include other CNs connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d of the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and with a base station 114b that may employ an IEEE 802.11 wireless technology.

[0032] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, 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 should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, 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. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0035] 1B 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.

[0036] 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 mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11.

[0037] The processor 118 of the WTRU 102 may be coupled to and 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. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), 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, memory that is not physically located on the WTRU 102, such as a server or home computer (not shown).

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

[0039] The processor 118 may also be coupled to a 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 instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0040] The processor 118 may also be coupled to other peripherals 138, which may include one or more software 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 videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth 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, and the like. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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, a humidity sensor, and the like.

[0041] The WTRU 102 may include a full-duplex radio, in which case transmission and reception of some or all of the signals (e.g., associated with a particular subframe on both the UL (e.g., for transmission) and DL (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference by hardware (e.g., a choke) or by signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio, in which case transmission and reception of some or all of the signals (e.g., associated with a particular subframe on the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be parallel and / or simultaneous.

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

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

[0044] Each of the eNode-Bs 160a, 160b, 160c 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 the UL and / or DL, and the like. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0045] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as 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.

[0046] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function 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 initial attach of the WTRUs 102a, 102b, 102c, and the like. 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.

[0047] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode 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.

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

[0049] The CN 106 may facilitate communication 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 communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may also provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0050] Although the WTRU is depicted in Figures 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

[0051] In an exemplary embodiment, the other network 112 may be a WLAN.

[0052] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be sent through the AP; for example, a source STA may send traffic to the AP, which then delivers the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using an IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad hoc" mode of communication.

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

[0054] High-throughput (HT) STAs may use 40 MHz wide channels for communication, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0055] A very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data may be passed through a segment parser that may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing are performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration may be reversed, and the combined data may be sent to the medium access control (MAC).

[0056] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communication (MTC), such as MTC devices within macro coverage areas. MTC devices may have specific capabilities, for example, limited capabilities including support (e.g., support only) of specific and / or limited bandwidths. MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0057] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest 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 that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports 1 MHz mode (e.g., only supports 1 MHz), even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (that only supports 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though most of the available frequency bands are idle.

[0058] In the United States, the available frequency bands that may be used with 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah is 6MHz to 26MHz depending on the country code.

[0059] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

[0061] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerical values. For example, the 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., including different numbers of OFDM symbols and / or lasting for varying absolute time lengths).

[0062] 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 without also accessing other RANs (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement a DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0063] 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 during UL and / or DL, support for network slicing, DC, 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, and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0064] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as 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.

[0065] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration realms, terminating non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 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 Massive Mobile Broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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.

[0066] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, and the like. PDU session types may be IP-based, non-IP-based, Ethernet-based, and the like.

[0067] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an 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 UPFs 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 DL packets, providing mobility anchors, and the like.

[0068] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate 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 and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b via the UPFs 184a, 184b via an N3 interface with the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0069] 1A-1D and the corresponding description thereof, one or more, or all, of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0070] The emulation device may be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation device may be directly coupled to another device for testing and / or to perform testing using over-the-air wireless communications.

[0071] The one or more emulation devices may perform one or more functions (including all functions) while not implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in a non-deployed (e.g., test) wired and / or wireless communications network to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0072] The following abbreviations and acronyms are used inter alia herein: AF Application Features ADRF analysis data storage function BVLOS (Beyond the Visual Line of Sight) C2 Command and Control DCCF Data Collection Coordination and Distribution Function KPI Key Performance Indicator LCS Location Services ML Machine Learning NEF Network Exposure Function NF Network Function NWDAF Network Data Analysis Function OAM Operations, Administration and Maintenance RSRP reference signal received power RSRQ Reference Signal Received Quality UAS Unmanned Aerial System UAS NF Unmanned Aerial System Network Function (similar to NEF) UAV unmanned aerial vehicle USS UAV Service Supplier RSSI Received Signal Strength Indicator RTT Round Trip Time CQI Channel Quality Indicator QoE quality of experience

[0073] 3GPP introduced procedures and application programming interfaces (APIs) in Rel-17 that allow a USS to track and monitor the location of UAVs. In some implementations, the USS (e.g., a server that may be part of an Unmanned Aircraft System Traffic Management (UTM) system) may interface directly with the UAS NF and / or use application layer support APIs through the UAS Application Enabler (UAE) layer and / or use Service Enabler Architecture Layer (SEAL) APIs. In some implementations, the UAS NF uses the LCS to obtain location information for a given UAV or group of UAVs.

[0074] 3GPP introduced communication performance requirements for UAV applications in Rel-17. In some implementations, 5G systems (5GS) are required to support various KPIs (e.g., QoS, minimum altitude, maximum ground speed) for various UAV applications and command and control modes. For example, in some implementations, a UAV including a "steering to waypoint" control mode or autonomous flight with UTM capabilities may be classified as requiring, e.g., 1 second of end-to-end latency at speeds up to 300 km / h, whereas in some implementations, a "direct stick steering" mode, with a much lower maximum speed, may require, e.g., only 40 ms of end-to-end latency.

[0075] 3GPP has introduced enhancements to LTE for support of unmanned aerial vehicles (e.g., UAVs) from an interference mitigation and mobility perspective. To address these requirements, support for the "flightPathInfoReport" function has been defined, allowing transmission of height, position, and velocity information from the UAV / UE to the eNB along with signal quality measurements. Similar NR-specific enhancements could be part of Rel-18, for example, based on previous work done in LTE.

[0076] 3GPP added support for network data analytics to 5GS in Rel-16. Functions that could be part of this framework include the Network Data Analytics Function (NWDAF), the Data Collection and Coordination Function (DCCF), and the Analysis and Data Repository Function (ADRF).

[0077] In some implementations, the NWDAF interacts with other NFs / NEFs / OAMs or AFs to provide data analytics services. The NWDAF supports data analytics collection and processing (e.g., statistical or predictive information derivation, ML model training).

[0078] In some implementations, the DCCF provides data collection coordination and distribution to NF data consumers. Such functionality is also supported by the NWDAF. The DCCF provides support for collecting and formatting data from NF data sources (including the ADRF below) to multiple NF consumers.

[0079] In some implementations, the ADRF provides data and analytics storage services. The ADRF stores, retrieves, or deletes data / analytics based on consumer NF requests.

[0080] The Aerial Connectivity Joint Activity (ACJA) initiative has defined a general mechanism called the "Network Coverage Service," which describes high-level principles for Mobile Network Operators (MNOs) to exchange network coverage / connectivity information with the UTM ecosystem.

[0081] In some implementations, it may be desirable to provide network data (e.g., performance / KPIs, status, load, coverage) to the USS for UAV flight path management. In some implementations, it may be desirable to provide UAV enhancements (e.g., as part of 3GPP Rel-19) for one or more of the following purposes: providing additional information to the UAV operator / USS to perform pre-flight preparation and in-flight operations (e.g., flight mission application, flight path recommendation, flight monitoring and control, etc.), and supporting enhanced UAV flight / path management, e.g., based on network capacity and / or QoS information along the planned path.

[0082] Some implementations enable the USS to track the location of a UAV, but lack exposure to network performance and / or network condition (e.g., coverage, QoS, signal levels, etc.) related information, such as information associated with an ongoing or planned UAV flight path and / or area of ​​interest.

[0083] In some implementations, such network metrics may be used by the USS as part of flight path management operations (e.g., optimal flight path selection based on network-provided information), for example, to ensure the availability of reliable and efficient connectivity for the UAV. Reliable connectivity is particularly important to ensure safety and proper operation during BVLOS maneuvers.

[0084] In some implementations, data analytics exposure may support general-purpose WTRUs (e.g., terrestrial WTRUs), for example, by using various data within 5GS, but system requirements for providing detailed network resource information adapted to and relevant for UAV flight path planning or monitoring are not defined.

[0085] In some implementations, the devices, systems, methods, and techniques described herein may advantageously provide for exposing to a USS detailed network performance information (e.g., QoS, signal levels) associated with planned, ongoing, and / or past flight paths or areas of interest, for example, based on predictive, statistical, and / or real-time data.

[0086] Some such devices, systems, methods, and techniques may advantageously facilitate a USS obtaining timely and accurate information (e.g., from an MNO) about network coverage and performance. For example, in some implementations, a USS may collect network data about air operations to infer and recommend optimal flight routes, flight scheduling, and / or flight path adjustments as part of UAV flight control and monitoring.

[0087] In some implementations, the network advantageously enables the storage and sharing of network performance data (e.g., federated network data) among a network of USSs. In other words, the network may maintain aggregated or federated flight path-related network coverage or QoE metric information that the network may expose to one or more USSs. In some such implementations, the network leverages accumulated flight path network data, e.g., associated with several USSs and / or associated with wider coverage than is possible with a single USS, to build a richer data set. This may have the advantage of improving network service value-add. In some implementations, each USS benefits from “economies of scale” using such federated network flight data, which may further improve inferential predictions (e.g., with better ML model fitting).

[0088] 2 is a network diagram illustrating an example architecture 200 for exposing network performance data and / or flight path network KPI data. Example architecture 200 includes a USS 204 and a network 250. The USS is a server in this example, although any suitable network equipment or other device for communication by the USS can be used in other implementations. Network 250 is a 3GPP 5G network or 5G Core (5GC) in this example, although any suitable network can be used in other implementations.

[0089] Network 250 includes, in this example, UAS NF 202, NWDAF / DCCF / ARDF 206, LCS 208, data source NF 210, OAM 212, RAN 214, and UE 216, although in other implementations, network 250 includes a subset of these devices, additional devices, and / or different devices.

[0090] In this example, the UAS NF 202 is a server or other suitable network device implementing a UAS NF.

[0091] The NWDAF / DCCF / ARDF 206 is a server or other suitable network device implementing the NWDAF, DCCF, and / or ARDF. Some implementations include a subset of these functions. In some implementations, these functions (or a subset of these functions) are implemented in the same device, different devices, or any combination among multiple devices. The LCS 208 is a server or other suitable network device implementing LCS functions. For example, in some implementations, the LCS 208 is a device configured to provide information regarding the location of the UE 216 (or in some implementations, any suitable WTRU, e.g., on or part of any suitable vehicle or uncrewed vehicle). Data Source NFs. Some examples of such NFs include: a RAN node, a Data Collection AF (DCAF), an SMF, an AMF, a Management Data Analysis Function (MDAF) (e.g., for collecting data from an OAM). 210 is a server (or a single server) or other suitable network device implementing one or more Data Source NFs. The OAM 212 is a server or other suitable network device that implements one or more operations, administration, and / or maintenance functions (e.g., providing service experience / quality of experience (QoE) analysis, event / incident reporting and response). The RAN 214 is or includes a radio access network or a portion thereof. In this example, the RAN 214 includes a 5G RAN, although other implementations include one or more different RANs or additional RANs. The UE 216 is or includes a UAV (e.g., a WTRU onboard a UAV), although in other implementations the UE 216 is or includes any suitable WTRU, and in some implementations is onboard or part of any suitable vehicle or crewless vehicle.

[0092] In some implementations, the UAS NF 202 provides an API or other interface for the USS 204 (or other device) to obtain network information associated with the UE 216, such as, for example, network KPIs or other network information related to the flight path 292 or the area of ​​interest 290. In some implementations, the API may be an enhanced and / or augmented version of an existing API for UAV tracking and / or monitoring, for example, as described herein with respect to procedures and / or APIs (which in some implementations include new or existing procedures and / or APIs) for enabling the USS to track and monitor the location of the UAV, or use a dedicated API.

[0093] In some implementations, the UAS NF 202 interfaces with one or more data analysis functions (e.g., NWDAF / DCCF / ARDF 206) to collect network KPI data based on a request from the USS 204. In some implementations, the data analysis function (e.g., NWDAF / DCCF / ARDF 206) interacts with the RAN 214 (e.g., via the AMF) to collect information related to the flight path of the UE 216 (e.g., height, position, speed, and signal quality information) and interacts with other NFs (e.g., data source NFs 210, such as SMF, MDAF / OAM, etc.) to obtain QoS and / or QoE information (e.g., for an ongoing flight mission).

[0094] In some implementations, the collected flight path network data is stored and may be later retrieved, e.g., via the NWDAF / DCCF / ARDF 206 and / or other devices or functions. In some implementations, the UAS NF 202 obtains location information about the UE 216, for example, from a location service such as the LCS 208 (e.g., as described herein with respect to UAV tracking and location monitoring).

[0095] In some implementations, the UAS NF 202 prepares and sends network and / or location information to the USS 204 based on the request (e.g., taking into account network data sharing policies). For example, if network data sharing is enabled between multiple USSs (i.e., if the network has service level agreements with several collaborating USSs), the data collected by the UAS NF may result from an aggregation of data analyses compiled based on input from one or more USSs (e.g., using flight paths of UAVs belonging to different USSs). If network data sharing is not enabled, the data collected by the UAS NF may be limited to data analyses compiled based on input from the requesting USS (e.g., using flight path information for UAVs belonging to the requesting USS).

[0096] Some implementations provide KPI-based UAV flight path exposure by the UAS NF. For example, in some implementations, the UAS NF exposes the USS to network metrics and analytics associated with a given flight path and / or area of ​​interest.

[0097] 3 is a message sequence chart illustrating an example procedure 300 for flight path network data reporting (e.g., UAV flight path network data reporting). In this example, procedure 300 is implemented by the example architecture 200 shown and described with respect to FIG. 2; however, it should be noted that procedure 300, or portions thereof, may be implemented by any other suitable hardware and / or architecture. In some implementations, aspects of flight path network data reporting illustrated by example procedure 300 may be implemented by other suitable devices and / or other architectures. In this example, a WTRU 216 (a UE and / or UAV in this example) registers with the RAN 214 at 350 and is authorized by the USS 204 to fly. In some implementations, the WTRU 216 sends flight path information measurements (e.g., NR flight path information measurements) to RAN 214 nodes along its flight path.

[0098] In this example, the UAS NF202 receives a request 302 for flight path network data reporting (e.g., network service experience, such as network QoS, network conditions, and / or WTRU / UAV responsiveness experienced to C2 commands from the UAV controller / pilot).

[0099] The request 302 may include identification information of the UE 216 (e.g., UE ID), UE / UAV class type, QoS / KPI thresholds and / or requirements, flight path network data analysis retention / sharing policy, UAV application ID, flight path information and / or area of ​​interest, reporting periodicity, coverage area (e.g., geographic area, time), and other suitable information. The request may apply to an ongoing flight mission, or to past flight data, or to past / predicted network data not associated with a specific flight (e.g., network coverage, capacity, or load within an area).

[0100] In some implementations, the WTRU / UAV class type and / or application ID may be used to derive reference KPI thresholds (e.g., RSSI, RTT, CQI) or QoS profiles, or to filter out analysis results (e.g., UAV only) as part of data analysis generation.

[0101] In example procedure 300, the UAS NF 202 verifies whether the USS 204 is authorized to obtain the requested network data (e.g., network data associated with an ongoing or past flight mission). In some implementations, the UAS NF 202 verifies whether the USS is authorized to obtain the requested network data in verification 304. In some implementations, the USS 204 may be authorized based on a network data sharing policy (e.g., network data shared among several USSs) and / or based on a local configuration (e.g., based on local privacy regulatory requirements). In some implementations, the UAS NF 202 may use the services of a PCF to determine network data storage and / or sharing policies. In some implementations, the UAS NF 202 verifies whether the USS 204 is authorized to obtain the requested network data in response to request 302. In some implementations, the UAS NF 202 verifies whether the USS 204 is authorized to obtain the requested network data in response to something else (e.g., in response to another request or other message or configuration) without receiving a request such as, for example, request 302. In some implementations, the UAS NF 202 does not perform verification 304 or verifies in other ways whether the USS 204 is authorized to obtain the requested network data.

[0102] In some implementations, the UAS NF 202 sends a request 306 (or multiple requests) for data analysis information to the NWDAF / DCCF / ARDF 206. In some implementations, the requested data analysis information includes one or more of an identification of the WTRU 216 (e.g., a WTRU ID), a WTRU class type (e.g., a UAV class type) of the WTRU 216, QoS and / or KPI requirements (e.g., what the network needs to provide along a given flight path) and / or thresholds (e.g., for the network to trigger the generation of a report), one or more areas of interest, a WTRU (e.g., UAV) application ID of an application running on the WTRU 216, an identifier of the requested analysis information (analysis ID; e.g., “service experience,” “flight path information”), and / or any other suitable information. In some implementations, the request 306 specifies the particular data analysis information requested by the UAS NF 202 (e.g., from the information above). In some implementations, the request 306 does not specify the particular data analysis information.

[0103] In some implementations, the request 306 (or another appropriate indication from the USS NF 202) indicates or includes an indication from the NWDAF / DCCF / ARDF 206 to store network data, for example, based on a data storage / sharing policy (e.g., received in the request 302 or separately). In some implementations, the request 306 includes network data collection reference information. In some implementations, such data collection reference information includes information identifying the USS 204, storage rules and / or sharing rules, or any other suitable information. The network data collection reference information (e.g., a reference identifier or number) may be provided by the UAS NF 202 to the USS in a response to the request 306. The network data collection reference information may be used by the UAS NF 202 to locate network data previously collected for the USS 204.

[0104] In some implementations, the UAS NF 202 may send a request to a unified data management service (UDM) that performs the expected behavior based on the received WTRU / UAV class type, UAV application ID, and target waypoint / trajectory. The UAS NF 202 may translate some parameters in the request 306 into parameters provided to the UDM. The UDM stores that information for use by the data source NF 210 (e.g., AMF, SMF). In some implementations, the request 306 (or another appropriate indication from the USA NF 202) may also or may not be sent to an entity other than the NWDAF / DCCF / ARDF 206.

[0105] In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or initiate collection (and receive) network data for, from, and / or from the RAN 214 collected about the WTRU 216 (e.g., via AMF), e.g., when collecting measurements received from the WTRU 216. In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or initiate collection (and receive) network data via messaging 308 to or with the RAN 214.

[0106] In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or begin collecting (and receive) network data in response to the request 306. In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or begin collecting (and receive) network data, for example, without receiving a request such as the request 306, but in response to something other than the request 306 (e.g., in response to another request or other message or configuration). In some implementations, the NWDAF / DCCF / ARDF 206 does not collect and / or begin collecting network data. For example, the UAS_NF 202 may retrieve available past collected data from the NWDAF / DCCF / ARDF 206. In another example, data collection of network data may be performed by the NWDAF / DCCF / ARDF 206 to retrieve near real-time information about an ongoing flight or to add more recent measurements to maintain up-to-date collected data.

[0107] In some implementations, data collected from the RAN 214 (e.g., from or via a gNB of the RAN 214) is based on WTRU 216 aeronautical measurements (e.g., flightPathInfoReport measurements, uplink / downlink measurements, etc.). In some implementations, the NWDAF / DCCF / ARDF 206 generates and / or formats signal quality metrics (e.g., simplified signal level values ​​0-5) based on data received from the RAN 214 (e.g., in messaging 308). In some implementations, the signal quality metrics are generated and / or formatted such that the signal quality metrics are interpretable by the USS 204 (e.g., when received in flight path network data report 320 from the UAS NF 202).

[0108] In some implementations, when collecting data or generating data analytics, the NWDAF / DCCF / ARDF 206 may take into account data that applies specifically to UAVs. For example, some experienced signal strength metrics (e.g., RSRQ / RSRP) may be significantly different when compared to “ground” WTRUs and may negatively skew the accuracy of data analytics / predictions for UAVs, for example, because a UAV / WTRU may be within range of and / or receive signals from a larger number of cells (e.g., more main lobes of transmitted signals) while flying at a particular altitude. In some implementations, the WTRU / UAV class type and application ID may also, or alternatively, be used to derive reference KPI thresholds (e.g., RSSI, RTT, CQI) or QoS profiles used during data analytics generation and processing.

[0109] In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or initiate collection (and receive) network data from one or more other data sources. For example, in some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or initiate collection (and receive) network data from data sources NF 210 and / or OAM 212 (e.g., when the WTRU 216 is in active flight). In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or initiate collection (and receive) network data to or with the NF 210 and / or OAM 212 via messaging 310. In some implementations, the network data includes QoS data from the SMF and / or OAM 212.

[0110] In some implementations, the NWDAF / DCCF / ARDF 206 collects and / or begins collecting (and may receive) network data in response to the request 306. In some implementations, the NWDAF / DCCF / ARDF 206 may collect and / or begin collecting (and receive) network data without receiving a request such as the request 306, for example, but in response to something other than the request 306 (e.g., in response to another request or other message or configuration). In some implementations, the NWDAF / DCCF / ARDF 206 does not collect and / or begin collecting network data.

[0111] In some implementations, the NWDAF / DCCF / ARDF 206 stores 312 the collected data (e.g., received via messaging 310) and / or data generated by the NWDAF based on the collected data, e.g., based on storage and / or sharing indications and / or policies (e.g., received in request 306 or separately).

[0112] In some implementations, the NWDAF / DCCF / ARDF 206 retrieves network data, if available, from the ARDF without collecting, initiating collection, or receiving network data from the RAN 214, data source NF 210, and / or OAM 212 based on the sharing policy (e.g., messaging 308 and / or messaging 310 can be skipped if the network data request is for historical data and / or is not directed to real-time information for a particular UAV). For example, if the request 306 is for historically collected data and / or is not for real-time information for an ongoing flight, it can be retrieved directly from the ARDF, if available.

[0113] In some implementations, the UAS NF 202 receives the data analysis information from the NWDAF / DCCF / ARDF 206 in a response 314 or in other ways. In some implementations, the UAS NF 202 receives the data analysis information from another source. In some implementations, the received data analysis information includes location information (e.g., corresponding to a particular waypoint of the UAV from a past or ongoing flight path). In some implementations, the location information is time-stamped in real time by the RAN 214 and / or core 250 and may include historical or predicted metrics (e.g., historical or predicted network conditions, load, indication of QoS, and / or link quality, etc.). In some implementations, the network data analysis may include indications of alternative flight paths / routes (e.g., alternative waypoints / locations or flight mission times that provide better or optimal network performance).

[0114] In some implementations, the UAS NF 202 may request and / or receive information from the LCS 208 regarding and / or indicative of the location of the WTRU 216, for example, in messaging 316 (e.g., to supplement and / or correlate the location information received in response 314).

[0115] In some implementations, the UAS NF 202 generates 318 a response 320 to the request 302. In some implementations, the response 320 includes a flight path network data report. In some implementations, the response 320 and / or the flight path network data report includes data analysis, such as KPIs, associated location information, and possible alternative locations / KPIs received above. In some implementations, the UAS NF 202 sends the flight path network data report to the USS 204 in the response 320.

[0116] In some implementations, the flight path network data request 302 may be received by the UAS NF 202 using a WTRU (UAV in this example) position tracking API (e.g., as part of an enhanced tracking and position monitoring procedure). In some implementations, the USS 204 may request network data information for a list of WTRUs (UAVs in this example) in a given region of interest, such as region of interest 290 (e.g., without specifying a particular WTRU). In some implementations, the UAS NF 202 may perform some or all of the procedure 300 for a group of WTRUs (UAVs in this example) currently present in the region of interest (e.g., the group may be filtered based on UAV class type and / or whether the WTRUs are owned, managed, or otherwise associated, for example, with the USS 204), or based on historical data of the WTRUs (UAVs in this example) in the region. In some implementations, the USS 204 may request network data information based on whether a UAV is present in the given region of interest (e.g., by monitoring for the presence of a UAV). In some such cases, the UAS NF 202 may initiate the above-described network data collection for the WTRU (in this example, a UAV) in response to being notified by the LCS that the WTRU is in its area.

[0117] Some implementations provide application layer support for QoE-based UAV flight path monitoring. For example, some implementations include UAV flight path QoE reporting by the UAE layer. In some implementations, the UAE server reports location-based QoE metrics from the UAE client (e.g., UAV) to the USS based on a USS-provided flight path QoE reporting configuration. In some implementations, the UAE client reports the QoS experienced by the UAV application layer to the USS via the UAE server in response to a USS-configured threshold in the UAV flight path QoE report received from the USS via the UAE server (e.g., that the UAE client experienced a packet delay greater than a delay threshold (e.g., configured by the USS)).

[0118] 4 is a message sequence chart illustrating an exemplary flight path QoE reporting configuration procedure 400. In this example, a UAE server 402 receives a request 404 to configure flight path QoE reporting from a UAS application dedicated server 406 (e.g., a USS). In some implementations, the UAE server 402 is a middleware server residing between the UAS application dedicated server 406 and the 5G core. In some implementations, the UAE server 402 may receive the flight path QoE reporting configuration request 404 from the USS server, which may indicate and / or include QoE-related trigger event information (e.g., QoE thresholds, periodicity of information collection, such as QoE information), validity scope of where or time the reporting applies (e.g., flight path waypoints and / or geographic region, time), or any other suitable information.

[0119] In some implementations, the UAE server 402 may send a response 408 to the UAS application dedicated server 406, which may indicate and / or include the requested flight path QoE reporting configuration, as well as a positive or negative acknowledgement of the request. In some implementations, the response 408 and / or its indication or content may be based on whether the UAE server 402 is able to undertake this task.

[0120] In some implementations, the UAE server may configure the UAE client with the flight path QoE reporting configuration 410 for the UAE client, for example, by sending a configuration request to the UAE client. In some implementations, the UAE client comprises middleware running on a WTRU (e.g., a UAV). In some implementations, this configuration request sent to the UAE client includes a WTRU (UAV in this example) identifier. In some implementations, this configuration request sent to the UAE client includes some or all of the QoE-related configuration information received in the request 404. In some implementations, the UAE client may store the received QoE-related configuration parameters or other information and may send a QoE reporting configuration response to the UAE server 402.

[0121] After successful completion of the flight path QoE reporting configuration 410, the UAE server 402 may notify the UAS application dedicated server 406, for example, with a flight path QoE reporting configuration complete message 412.

[0122] FIG. 5 is a message sequence chart illustrating an exemplary flight path QoE reporting procedure 500 in which the UAE server 402 processes QoE event reports from the UAE client 502 and sends associated WTRU (UAV in this example) location information to the UAS application dedicated server 406, e.g., in an integrated flight path QoE report.

[0123] In this example, the UAE client 502 may detect the QoE event 504 (e.g., based on a metric exceeding a threshold, such as packet delay). In some implementations, the UAE client 502 detects the QoE event based on the application layer experienced QoS (e.g., packet delay and / or packet loss) and / or a QoE threshold from a previously stored QoE reporting configuration (e.g., the flight path QoE reporting configuration 410 shown in FIG. 4).

[0124] In some implementations, the UAE server 402 may receive a QoE-related event report 506 from a UAE client. In some implementations, the report 506 includes or indicates information about the QoE information (e.g., indicates a low or high QoE). In some implementations, the UAE server 402 records the event with a current timestamp.

[0125] In some implementations, the UAE server 402 may request and receive 508 UAE client location information for the UAE client 502 from the SEAL location services server 510. In some implementations, the UAE server 402 records the received location information with a current timestamp.

[0126] In some implementations, the UAE server 402 may send a QoE report 512 to the UAS application dedicated server 406, which may include or indicate QoE information and / or location information. In some implementations, for example, based on a QoE reporting configuration, the UAE server 402 may send the QoE report 512 to the UAS application dedicated server 406 in response to receiving the QoE information and / or location information, may send the QoE report 512 to the UAS application dedicated server 406 periodically, and / or may send the QoE report 512 to the UAS application dedicated server 406 in response to a session termination between the UAE server 406 and the UAE client 502 (e.g., when a flight mission is completed). In some implementations, the UAS application dedicated server 406 sends an acknowledgment 514 to the UAE server 402 in response to the QoE report 512.

[0127] Some implementations provide KPI-based UAV flight path exposure by the UAS NF, and / or KPI-based UAV flight path monitoring and planning. In the following example methods, certain referenced details may be implemented, for example, with respect to network-assisted KPI-based UAV flight path monitoring and planning, e.g., as discussed herein.

[0128] In this exemplary method, a UAS NF receives a request for KPI-based UAV flight path reporting (e.g., to report network QoS status and / or service experience associated with the flight path). In some implementations, the request includes UAV identification information and / or WTRU / UAV class type, QoS / KPI thresholds and / or requirements, flight path network data analysis retention / sharing policy, UAV application ID, flight path information and / or area of ​​interest, reporting periodicity, coverage (e.g., geographic area, time), and / or any other suitable information. The UAS NF sends one or more requests for data analysis collection to a Data Collection / Analysis Function (DCCF / NWDAF), which results in the WTRU ID, WTRU / UAV class type, QoS / KPI thresholds, area of ​​interest, UAV application ID, analysis ID (e.g., “Service Experience,” “RAN Flight Path Information”), and / or any other suitable information. The UAS NF receives the data analysis information from the DCCF / NWDAF. In some implementations, the data analysis information includes time-stamped location information along with RAN and / or core metrics (e.g., network conditions, load, QoS indications, link quality). The UAS NF requests that the analysis be stored at the ADRF for subsequent USS request, for example, based on flight path network data retention / sharing policies and / or based on local configuration. The UAS NF generates and sends a UAV flight path report to the USS. In some implementations, the UAV flight path report includes UAV location information with associated KPI information and / or an indication of flight path optimization based on collected statistical data or predictions obtained from the NWDAF / DCCF / ADRF, and / or any other suitable information.

[0129] Some implementations perform QoE-based UAV flight path monitoring using the UAE layer. In the following example methods, certain referenced details may be implemented, for example, with respect to application layer support-based UAV flight path monitoring for QoE, e.g., as discussed herein.

[0130] In this exemplary method, the UAE server receives a UAV QoE reporting configuration from the USS server, including QoE-related trigger events (e.g., QoE thresholds, time / period for collecting QoE information), and validity ranges (e.g., geographical area, time). The UAE server sends the UAV QoE reporting configuration to the UAE client. The UAE server receives a QoE report from the UAE client. In some implementations, the QoE report includes QoE information (e.g., low / high QoE) and a timestamp. The UAE server requests / receives UAE client location information from the SEAL location service. The UAE server generates and sends a UAV QoE report including the location information to the USS. In some implementations, the location information includes network-based location information and / or associated UAV QoE information.

[0131] 6 is a flowchart illustrating an example process 600 for responding to a request for a flight path network data report. In some implementations, process 600 is implemented in a network device. In some implementations, the network device implements a UAS-NF (or other network device), and process 600 is implemented by or using this functionality.

[0132] At 602, a report request is received. In some implementations, the report request is, includes, indicates, or is based on a request for a UAV flight path network data report. In some implementations, the report is, includes, indicates, or is based on a request for a UAV flight path network data report indicating at least one waypoint. In some implementations, the report request is received from a requesting device. In some implementations, the requesting device is or includes a USS.

[0133] At 604, a request for information is transmitted. In some implementations, the request for information is, includes, indicates, or is based on a request for data analysis information. In some implementations, the request for information is, includes, indicates, or is based on a request for data analysis information regarding at least one UAV corresponding to at least one waypoint. In some implementations, the request for information is transmitted to one or more network devices implementing the NWDAF, DCCF, and / or ARDF.

[0134] At 606, data analytics information is received. In some implementations, the data analytics information is received in response to a request for data analytics information. In some implementations, the data analytics information is received from one or more network devices implementing the NWDAF, DCCF, and / or ARDF. In some implementations, the data analytics information is, includes, indicates, or is based on RAN or CN information. In some implementations, the data analytics information is, includes, indicates, or is based on KPI and / or UAV information. In some implementations, the data analytics information is, includes, indicates, or is based on data analytics information regarding at least one UAV corresponding to at least one waypoint in response to a request for data analytics information.

[0135] At 608, a flight path network data report is transmitted. In some implementations, the flight path network data report is transmitted to the USS. In some implementations, the flight path network data report is, includes, indicates, or is based on UAV position information, KPI information and / or flight path optimization information, or information based on the UAV position information. In some implementations, the flight path network data report is, includes, indicates, or is based on statistical information or CN forecast information, or information based on statistical information or CN forecast information. In some implementations, the flight path network data report is, includes, indicates, or is based on data analysis information.

[0136] While features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) 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 internal hard disks and removable disks, and optical media such as magneto-optical media, CD-ROM disks, and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method implemented in a network device, comprising: receiving a request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint; In response to the request for the UAV flight path network data report, transmitting a request for data analysis information regarding at least one UAV corresponding to the at least one waypoint; receiving data analysis information regarding at least one UAV corresponding to the at least one waypoint in response to the request for data analysis information; Transmitting a UAV flight path network data report based on the data analysis information; and A method comprising:

2. The method of claim 1 , wherein the network device implements a crewless air system network function (UAS-NF).

3. The method of claim 1 , wherein the network device receives a request for the UAV flight path network data report from a UAS service supplier (USS).

4. 10. The method of claim 1, wherein the network device sends the request for the data analysis information to another network device that implements a Network Data Analysis Function (NWDAF), a Data Collection Coordination Function (DCCF), or an Analysis Data Repository Function (ARDF).

5. The method of claim 1 , wherein the data analysis information includes radio access network (RAN) or core network (CN) information.

6. The method of claim 1 , wherein the data analysis information includes network condition information, network load information, quality of service (QoS) information, or link quality information.

7. The method of claim 1 , wherein the request for data analysis information includes key performance information (KPIs) for a UAV.

8. The method of claim 1 , wherein the network device transmits the UAV flight path network data report to a UAS service supplier (USS).

9. The method of claim 1 , wherein the UAV flight path network data report includes UAV position information, key performance information (KPI), or flight path optimization information.

10. The method of claim 1 , wherein the UAV flight path network data report includes information based on statistical information or core network (CN) forecast information.

11. 1. A network device, comprising: a circuit configured to receive a request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint; a circuit configured to transmit a request for data analysis information regarding at least one UAV corresponding to the at least one waypoint in response to the request for the UAV flight path network data report; a circuit configured to receive data analysis information regarding at least one UAV corresponding to the at least one waypoint in response to the request for data analysis information; a circuit configured to transmit a UAV flight path network data report based on the data analysis information; A network device comprising:

12. The network device of claim 11 , wherein the network device comprises circuitry configured to implement a crewless air system network function (UAS-NF).

13. The network device of claim 11 , wherein the network device comprises circuitry configured to receive a request for the UAV flight path network data report from a UAS service supplier (USS).

14. 12. The network device of claim 11, wherein the network device comprises circuitry configured to transmit the request for data analysis information to be transmitted to another network device that implements a Network Data Analysis Function (NWDAF), implements a Data Collection Coordination Function (DCCF), or implements an Analysis Data Repository Function (ARDF).

15. The network device of claim 11 , wherein the data analysis information includes radio access network (RAN) or core network (CN) information.

16. The network device of claim 11 , wherein the data analysis information includes network condition information, network load information, quality of service (QoS) information, or link quality information.

17. The network device of claim 11 , wherein the request for data analysis information includes key performance information (KPIs) of a UAV.

18. The network device of claim 11 , wherein the network device comprises circuitry configured to transmit the UAV flight path network data report to a UAS service supplier (USS).

19. The network device of claim 11 , wherein the UAV flight path network data report includes UAV position information, key performance information (KPI), or flight path optimization information.

20. The network device of claim 11 , wherein the UAV flight path network data report includes information based on statistical information or core network (CN) forecast information.

Images