UAV flight path planning and monitoring based on network-assisted KPI

Abstract

Devices, methods, and systems for flight path network data reporting. A request for an unmanned aerial vehicle (UAV) flight path network data report indicative of at least one waypoint is received. In response to a request for UAV flight path network data reporting, a request for data analysis information regarding at least one UAV corresponding to at least one waypoint is transmitted. In response to a request for data analysis information, data analysis information regarding at least one UAV corresponding to at least one waypoint is received. A UAV flight path network data report is transmitted based on the data analysis information. In some embodiments, a network device implements an unmanned aerial system network function (UAS-NF). In some embodiments, a network device receives a request for a UAV flight path network data report from a UAS Service Supplier (USS).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 422,188, filed on November 3, 2022, the contents of which are incorporated herein by reference. Background Art

[0003] Unmanned or unmanned aerial vehicles (UAVs) and other types of vehicles travel without a human pilot on board. Accordingly, the position and / or heading of the UAV may be obtained in various ways, for example, to facilitate pilotless operation. Summary of the Invention

[0004] Some embodiments provide a method implemented in a network device. A request is received 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, a request is transmitted for data analysis information regarding at least one UAV corresponding to the at least one waypoint. In response to the request for the data analysis information, data analysis information regarding at least one UAV corresponding to the at least one waypoint is received. Based on the data analysis information, the UAV flight path network data report is transmitted.

[0005] In some embodiments, a network device implements an Unmanned Aerial System Network Function (UAS-NF). In some embodiments, the network device receives a request for a UAV flight path network data report from a UAS service provider (USS). In some embodiments, the network device transmits a request for 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). In some embodiments, the data analysis information includes radio access network (RAN) or core network (CN) information. In some embodiments, the data analysis information includes network status information, network load information, quality of service (QoS) information, or link quality information. In some embodiments, the request for data analysis information includes key performance information (KPI) or UAV information. In some embodiments, the network device transmits a UAV flight path network data report to a UAS service provider (USS). In some embodiments, the UAV flight path network data report includes UAV location information, key performance information (KPI), or flight route optimization information. In some embodiments, the UAV flight path network data report includes information based on statistical information or core network (CN) prediction information.

[0006] Some embodiments 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, in response to the request for the UAV flight path network data report, transmit a request for data analytics information regarding at least one UAV corresponding to the at least one waypoint. The network device also includes circuitry configured to, in response to the request for the data analytics information, receive data analytics information regarding at least one UAV corresponding to the at least one waypoint. The network device also includes circuitry configured to transmit the UAV flight path network data report based on the data analytics information.

[0007] In some embodiments, the network device includes circuitry configured to implement UAS-NF. In some embodiments, the network device includes circuitry configured to receive a request for a UAV flight path network data report from a USS. In some embodiments, the network device includes circuitry configured to transmit a request for data analysis information to another network device that implements NWDAF, DCCF, or ARDF. In some embodiments, the data analysis information includes RAN or CN information. In some embodiments, the data analysis information includes network status information, network load information, QoS information, or link quality information. In some embodiments, the request for data analysis information includes KPIs or UAV information. In some embodiments, the network device includes circuitry configured to transmit the UAV flight path network data report to the USS. In some embodiments, the UAV flight path network data report includes UAV location information, KPIs, or flight route optimization information. In some embodiments, the UAV flight path network data report includes information based on statistical information or CN prediction information.

[0008] Some embodiments provide a method implemented in a network device. A request for a UAV flight path network data report is received. In response to the request for the UAV flight path network data report, a request for data analysis information is transmitted. In response to the request for the data analysis information, data analysis information is received. Based on the data analysis information, the UAV flight path network data report is transmitted.

[0009] In some embodiments, the network device includes circuitry configured to implement UAS-NF. In some embodiments, the network device includes circuitry configured to receive a request for a UAV flight path network data report from a USS. In some embodiments, the network device includes circuitry configured to transmit a request for data analysis information to another network device that implements NWDAF, DCCF, or ARDF. In some embodiments, the data analysis information includes RAN or CN information. In some embodiments, the data analysis information includes network status information, network load information, QoS information, or link quality information. In some embodiments, the request for data analysis information includes KPIs or UAV information. In some embodiments, the network device includes circuitry configured to transmit the UAV flight path network data report to the USS. In some embodiments, the UAV flight path network data report includes UAV location information, KPIs, or flight route optimization information. In some embodiments, the UAV flight path network data report includes information based on statistical information or CN prediction information.

[0010] Some embodiments 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 the data analysis information. The network device also includes circuitry configured to transmit the UAV flight path network data report based on the data analysis information.

[0011] In some embodiments, the network device includes circuitry configured to implement UAS-NF. In some embodiments, the network device includes circuitry configured to receive a request for a UAV flight path network data report from a USS. In some embodiments, the network device includes circuitry configured to transmit a request for data analysis information to another network device that implements NWDAF, DCCF, or ARDF. In some embodiments, the data analysis information includes RAN or CN information. In some embodiments, the data analysis information includes network status information, network load information, QoS information, or link quality information. In some embodiments, the request for data analysis information includes KPIs or UAV information. In some embodiments, the network device includes circuitry configured to transmit the UAV flight path network data report to the USS. In some embodiments, the UAV flight path network data report includes UAV location information, KPIs, or flight route optimization information. In some embodiments, the UAV flight path network data report includes information based on statistical information or CN prediction information.

[0012] Some embodiments provide systems, devices, and methods 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 vehicle service provider (USS) server. A flight path QoE reporting configuration response is sent to the USS. The flight path QoE reporting configuration is executed. After the flight path QoE reporting configuration is successfully executed, a notification is sent to the USS indicating that the flight path QoE reporting configuration is complete.

[0013] Some embodiments 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. The UAE client's current location information is requested from a service enabler architecture layer (SEAL) location service. The UAE client's current location information is received from the SEAL location service. The QoE report including the location information is sent to an unmanned aerial vehicle service provider (USS). The location report including the QoE information is sent to the USS.

[0014] Some embodiments provide systems, devices, and methods implemented in an Unmanned Aerial System Network Function (UAS-NF) for KPI-based UAV flight path exposure. The UAS NF receives a request for a KPI-based UAV flight path report. The UAS NF sends one or more requests for data analysis collection to a data collection / analysis function (DCCF / NWDAF). The UAS NF receives data analysis information from the DCCF / NWDAF. The UAS NF sends a request to store the analysis in the ADRF for subsequent USS requests. The UAS NF sends the UAV flight path report with the KPI information to the USS.

[0015] Some embodiments provide systems, devices, and methods implemented in an Unmanned Aerial System Application Enabler (UAE) server for performing quality of experience (QoE)-based UAV flight path monitoring using the UAE layer. The UAE server receives an unmanned aerial vehicle (UAV) QoE reporting configuration from a UAV service provider (USS) server. The UAE server sends the UAV QoE reporting configuration to a UAE client. The UAE server receives a QoE report from the UAE client. The UAE server sends a request for UAE client location information from a Service Enabler Architecture Layer (SEAL) location service. The UAE server receives the UAE client location information from the SEAL location service. The UAE server sends the UAV QoE report with the location information to the USS. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0018] Figure 1B is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system as illustrated in FIG.

[0019] Figure 1C is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used in a communication system illustrated in FIG.

[0020] Figure 1D is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an additional example RAN and an additional example CN used in the communication system illustrated in FIG;

[0021] Figure 2 is a network diagram illustrating an example architecture for presenting network performance data and / or flight path network KPI data;

[0022] Figure 3 is a message sequence chart illustrating an example procedure for flight path network data reporting;

[0023] Figure 4 is a message sequence chart illustrating an example flight path QoE reporting configuration procedure;

[0024] Figure 5 is a message sequence chart illustrating an example flight path QoE reporting procedure; and

[0025] Figure 6 is a flow chart illustrating an example process for servicing a request for a flight path network data report. DETAILED DESCRIPTION

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

[0027] like Figure 1A As shown in FIG, the communication 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. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0028] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, 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 will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0029] 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, etc. 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 cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, 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 a desired spatial direction.

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

[0031] More specifically, as described 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 in the RAN 104 and the WTRUs 102a, 102b, 102c 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).

[0032] In one 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).

[0033] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access and may establish the air interface 116 using NR.

[0034] In one 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 implement both LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. 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 / from multiple types of base stations (e.g., eNBs and gNBs).

[0035] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio 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.

[0036] Figure 1A The base station 114b in 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 to facilitate wireless connectivity in a local 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 one 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-APro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown in FIG, base station 114b may be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106.

[0037] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication). Although in Figure 1ANot shown, but it will be appreciated that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT as the RAN 104. 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.

[0038] 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 that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from 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 networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

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

[0040] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), 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. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0045] 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. Furthermore, 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 on a server or a home computer (not shown).

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

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

[0048] The processor 118 may be further 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, an FM radio unit, a digital music player, a media player, an electronic 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, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biometric sensor, a humidity sensor, and the like.

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

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

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

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

[0053] Figure 1C The CN 106 shown in FIG 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 will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] 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 serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for translating between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0055] 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 downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0057] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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.

[0058] Even though the WTRU Figure 1A-Figure 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

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

[0060] 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 to or be connected to a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS destined for a STA may reach the AP and may be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. For example, traffic between STAs within a BSS may be sent through the AP, where the source STA may send traffic to the AP, and the AP may deliver 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 a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

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

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

[0063] Very High Throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. A 160MHz channel can be formed by combining 8 adjacent 20MHz channels, or by combining two non-adjacent 80MHz channels - this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing separately. These streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0064] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers in 802.11af and 802.11ah are reduced relative to the operating modes 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support metered type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities (e.g., limited capabilities), including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0065] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) 1 MHz mode (e.g., MTC-type devices), the primary channel can be 1 MHz wide, 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 assignment vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy, even if most of the available frequency band remains idle.

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

[0067] Figure 1D 1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described 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 be in communication with the CN 106.

[0068] The RAN 104 may include gNBs 180a, 180b, and 180c, although it will be appreciated 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 gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0069] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing a different number of OFDM symbols and / or lasting for a different length of absolute time).

[0070] 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 another RAN (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles 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 serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for the serving WTRUs 102a, 102b, 102c.

[0071] 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, user scheduling in UL and / or DL, network slicing support, DC, interworking between NR and E-UTRA, routing of user plane data to a user plane function (UPF) 184a, 184b, routing of control plane information to an access and mobility management function (AMF) 182a, 182b, and the like. Figure 1D As shown in , gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

[0072] Figure 1DThe CN 106 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and possibly a data network (DN) 185 a, 185 b. Although the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0073] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service being utilized by the WTRU 102a, 102b, 102c. For example, different network slices can 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 translating 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.

[0074] The SMF 183a, 183b can connect to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b can also connect to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, and the like. The PDU session type can be IP-based, non-IP-based, Ethernet-based, and the like.

[0075] 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 anchoring, and the like.

[0076] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Furthermore, 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 connect to the local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0077] Given that Figure 1A-Figure 1D and Figure 1A-Figure 1D As described herein, one or more or all of the functionality described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) 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 functionality described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functionality.

[0078] Emulation devices can be designed to perform one or more tests on other devices in a lab environment and / or in a carrier network environment. For example, one or more emulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices can be directly coupled to another device for testing purposes and / or perform tests using over-the-air wireless communications.

[0079] One or more emulated devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulated devices can be used in test scenarios in a test lab and / or in a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more emulated devices can be test devices. The emulated devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0080] This document uses, among others, the following abbreviations and acronyms:

[0081] AF application function

[0082] ADRF Analysis Data Repository Function

[0083] BVLOS (Beyond Visual Line of Sight)

[0084] C2 Command and Control

[0085] DCCF Data Collection Coordination and Delivery Function

[0086] KPI Key Performance Indicator

[0087] LCS Location Services

[0088] ML Machine Learning

[0089] NEF Network Display Function

[0090] NF Network Function

[0091] NWDAF network data analysis function

[0092] OAM Operations, Administration and Maintenance

[0093] RSRP Reference Signal Received Power

[0094] RSRQ Reference Signal Received Quality

[0095] UAS Unmanned Aerial System

[0096] UAS NF Unmanned Aerial System Network Function (similar to NEF)

[0097] UAV Unmanned Aerial Vehicle

[0098] USS UAV Service Provider

[0099] RSSI Received Signal Strength Index

[0100] RTT Round Trip Time

[0101] CQI Channel Quality Index

[0102] QoE Quality of Experience

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

[0104] 3GPP introduced communication performance requirements for UAV applications in Rel-17. In some embodiments, the 5G system (5GS) is required to support various KPIs (e.g., QoS, minimum altitude, maximum ground speed) for a variety of UAV applications and command and control modes. For example, in some embodiments, a UAV with a "turn-waypoint" control mode or autonomous flight capability on a UTM may be classified as requiring, for example, an end-to-end latency of 1 second and a speed of up to 300 km / h, while in some embodiments, a "direct stick steering" mode may require, for example, an end-to-end latency of as little as 40 ms and a much lower maximum speed.

[0105] 3GPP has introduced enhancements to LTE to support unmanned aerial vehicles (e.g., UAVs) in terms of interference mitigation and mobility. To address those requirements, support for the "Flight Path Information Reporting" feature has been defined, enabling the transmission of altitude, position, and velocity information, as well as signal quality measurements, from the UAV / UE to the eNB. Similar NR-specific enhancements may become part of Rel-18, for example, based on previous work completed in LTE.

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

[0107] In some embodiments, the NWDAF provides data analysis services that interact with other NF / NEF / OAM or AF. The NWDAF provides support for data analysis collection and processing (e.g., statistical or predictive information derivation, ML model training).

[0108] In some embodiments, DCCF provides data collection coordination and delivery to NF data consumers. NWDAF also supports this functionality. DCCF provides support for collecting and formatting data from NF data sources (including ADRF below) to multiple NF consumers.

[0109] In some embodiments, ADRF provides data and analytics storage services. ADRF stores, retrieves, or deletes data / analytics based on consumer NF requests.

[0110] The Aviation Connectivity Joint Activity (ACJA) initiative has defined a common mechanism called “Network Coverage Service” that describes the high-level principles for mobile network operators (MNOs) to exchange network coverage / connectivity information with the UTM ecosystem.

[0111] In some embodiments, 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 embodiments, it may be desirable to provide enhancements for UAVs (e.g., as part of 3GPP Rel-19) that address one or more of the following goals: provide additional information to the UAV operator / USS to perform pre-flight preparation and in-flight operations (e.g., flight mission applications, flight path recommendations, flight monitoring and control, etc.), and support enhanced UAV flight / route management, e.g., based on network capacity and / or QoS information along a planned route.

[0112] Some embodiments enable the USS to track the location of the UAV, but lack the presentation of information related to network performance and / or network status (e.g., coverage, QoS, signal level, etc.), for example, information associated with ongoing or planned UAV flight paths and / or areas of interest.

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

[0114] In some embodiments, data analytics presentation may provide support for general purpose WTRUs (e.g., terrestrial WTRUs), for example, by utilizing various data within the 5GS, however, system requirements for providing detailed network resource information suitable for and associated with UAV flight path planning or monitoring are not yet defined.

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

[0116] Some such devices, systems, methods, and techniques may advantageously facilitate USSs (e.g., from MNOs) in obtaining timely and accurate information about network coverage and performance. For example, in some embodiments, as part of UAV flight control and monitoring, USSs may collect network data for aviation operations to infer and recommend optimal flight routes, flight scheduling, and / or adjust flight paths.

[0117] In some embodiments, the network advantageously enables storage and sharing of network performance data (e.g., federated network data) across a network of USSs. In other words, the network can maintain aggregated or federated flight path-related network coverage or QoE metric information that the network can expose to one or more USSs. In some such embodiments, the network utilizes, for example, accumulated flight path network data associated with several USSs to construct a richer dataset and / or have a wider coverage than a single USS could achieve. This can have the advantage of improving the added value of network services. In some embodiments, each USS benefits from the "economy of scale" of using such federated network flight data, which can further improve inference predictions (e.g., with better ML model fit).

[0118] Figure 2FIG2 is a network diagram illustrating an example architecture 200 for displaying network performance data and / or flight path network KPI data. Example architecture 200 includes a USS 204 and a network 250. In this example, the USS is a server, however, any suitable network device or other device for communicating via the USS may be used in other embodiments. In this example, network 250 is a 3GPP 5G network or 5G Core (5GC), however, any suitable network may be used in other embodiments.

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

[0120] In this example, UAS NF 202 is a server or one or more other suitable network devices that implements a UAS NF.

[0121] NWDAF / DCCF / ARDF 206 is a server or one or more other suitable network devices that implements NWDAF, DCCF, and / or ARDF. Some embodiments include subsets of these functions. In some embodiments, these functions (or subsets of these functions) are implemented in the same device, in different devices, or across any combination of multiple devices. LCS 208 is a server or one or more other suitable network devices that implements LCS functions. For example, in some embodiments, LCS 208 is a device configured to provide information about the location of UE 216 (or, in some embodiments, any suitable WTRU onboard or part of any suitable vehicle or unmanned vehicle). Data Source NF. Some examples of such NFs include: RAN node, Data Collection AF (DCAF), SMF, AMF, Management Data Analysis Function (MDAF) (e.g., collecting data from OAM). 210 is a server (or a single server) or one or more other suitable network devices that implement one or more Data Source NFs. The OAM 212 is a server or one or more other suitable network devices 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, however other embodiments include one or more different RANs or additional RANs. The UE 216 is or includes a UAV or a portion thereof (e.g., a WTRU onboard a UAV), although in other embodiments, the UE 216 is or includes any suitable WTRU, and in some embodiments, the UE 216 is or includes any suitable WTRU onboard any suitable vehicle or unmanned vehicle or a portion thereof.

[0122] In some embodiments, 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 network KPIs or other network information, e.g., regarding the flight path 292 or the area of interest 290. In some embodiments, the API can be an enhanced and / or augmented version of an existing API for UAV tracking and / or monitoring, e.g., as described herein with respect to procedures and / or APIs for enabling a USS to track and monitor the location of a UAV (including, in some embodiments, new or existing procedures and / or APIs) or using a dedicated API.

[0123] In some embodiments, 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 requests from the USS 204. In some embodiments, 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., altitude, position, speed, and signal quality information), and interacts with other NFs (e.g., data source NF 210, such as SMF, MDAF / OAM) to obtain QoS and / or QoE information (e.g., for an ongoing flight mission).

[0124] In some embodiments, the collected flight path network data can be stored and can be retrieved later, for example, via the NWDAF / DCCF / ARDF 206 and / or other devices or functions. In some embodiments, 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).

[0125] In some embodiments, the UAS NF 202 prepares and sends network information 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., the network has a service level agreement with some joint USSs), the data collected by the UAS NF may be generated from the aggregation of data analysis compiled based on input from one or more USSs (e.g., using the 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 analysis compiled based on input from the requesting USS (e.g., using the flight path information of the UAV belonging to the requesting USS).

[0126] Some embodiments provide a KPI-based UAV flight path display by the UAS NF. For example, in some embodiments, the UAS NF provides a display of network metrics and analytics associated with a given flight path and / or area of interest to the USS.

[0127] Figure 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, the procedure 300 consists of Figure 2The example architecture 200 shown and described is implemented, however, it is noted that the procedure 300 or portions thereof may be implemented by any other suitable hardware and / or architecture. In some embodiments, the aspects of flight path network data reporting illustrated by the example procedure 300 may be implemented by other suitable devices and / or other architectures. In this example, the WTRU 216 (in this example, a UE and / or UAV) registers with the RAN 214 in 350 and is authorized to fly by the USS 204. In some embodiments, the WTRU 216 sends flight path information measurements (e.g., NR flight path information measurements) along its flight path to the RAN 214 node.

[0128] In this example, the UAS NF 202 receives a request 302 for a flight path network data report (eg, network QoS, network status, and / or network service experience, such as experienced WTRU / UAV responses to C2 commands from a UAV controller / pilot).

[0129] The request 302 may include an identification of the UE 216 (e.g., UE ID), UE / UAV category 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 period, validity range (e.g., geographic area, time), and / or other suitable information. The request may apply to an ongoing flight mission or historical flight data or historical / predicted network data not associated with a specific flight (e.g., network coverage, capacity or load in an area).

[0130] In some embodiments, the WTRU / UAV category 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 (e.g., UAVs only) analysis results as part of data analysis generation.

[0131] In example procedure 300, UAS NF 202 verifies that USS 204 is authorized to obtain the requested network data (e.g., network data associated with an ongoing or past flight mission). In some embodiments, during verification 304, UAS NF 202 verifies that USS 204 is authorized to obtain the requested network data. In some embodiments, USS 204 may be authorized based on a network data sharing policy (e.g., network data shared between multiple USSs) and / or based on a local configuration (e.g., based on local privacy regulations). In some embodiments, UAS NF 202 may utilize services of the PCF to determine network data storage and / or sharing policies. In some embodiments, in response to request 302, UAS NF 202 verifies that USS 204 is authorized to obtain the requested network data. In some embodiments, in response to other circumstances (e.g., in response to a different request or other message or configuration), for example, without receiving a request such as request 302, UAS NF 202 verifies that USS 204 is authorized to obtain the requested network data. In some implementations, the UAS NF 202 does not perform authentication 304 or otherwise verify that the USS 204 is authorized to obtain the requested network data.

[0132] In some embodiments, the UAS NF 202 sends a request 306 (or multiple requests) for data analytics information to the NWDAF / DCCF / ARDF 206. In some embodiments, the requested data analytics information includes one or more of the following: an identification of the WTRU 216 (e.g., a WTRU ID), a WTRU category type of the WTRU 216 (e.g., a UAV category type), QoS and / or KPI requirements (e.g., that the network needs to provide along a given flight path) and / or thresholds (e.g., for network-triggered report generation), one or more regions of interest, a WTRU (e.g., UAV) application ID of an application running on the WTRU 216, an identifier for the requested analytics information (e.g., "Service Experience," "Flight Path Information"), and / or any other suitable information. In some embodiments, the request 306 specifies specific data analytics information requested by the UAS NF 202 (e.g., from the information listed above). In some embodiments, the request 306 does not specify specific data analytics information.

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

[0134] In some embodiments, the UAS NF 202 may send a request to the Unified Data Management (UDM), which provides the expected behavior based on the received WTRU / UAV category type, UAV application ID, and target waypoint / trajectory. The UAS NF 202 may translate some of the parameters in the request 306 into parameters provided to the UDM. The UDM stores this information for use by the data source NF 210 (e.g., the AMF of the SMF). In some embodiments, the request 306 (or another suitable indication from the USA NF 202) may also or alternatively be sent to an entity other than the NWDAF / DCCF / ARDF 206.

[0135] In some embodiments, for example, when collecting measurements received from the WTRU 216 in active flight, the NWDAF / DCCF / ARDF 206 collects and / or initiates the collection of (and may receive) network data collected for, from, and / or about the WTRU 216 from the RAN 214 (e.g., via the AMF). In some embodiments, the NWDAF / DCCF / ARDF 206 collects and / or initiates the collection of (and may receive) network data via messaging 308 to or with the RAN 214.

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

[0137] In some embodiments, data collected from the RAN 214 (e.g., from or via a gNB of the RAN 214) is based on aeronautical measurements (e.g., flight path information report measurements, uplink / downlink measurements, etc.) of the WTRU 216. In some embodiments, the NWDAF / DCCF / ARDF 206 generates and / or formats a signal quality metric (e.g., a simplified signal level value 0-5) based on data received from the RAN 214 (e.g., in messaging 308). In some embodiments, the signal quality metric is generated and / or formatted such that it can be interpreted by the USS 204 (e.g., when received in the flight path network data report 320 from the UAS NF 202).

[0138] In some embodiments, when collecting data or generating data analytics, the NWDAF / DCCF / ARDF 206 may consider data specifically applicable to UAVs. For example, some experienced signal strength metrics (e.g., RSRQ / RSRP) may differ significantly when compared to "terrestrial" WTRUs and may negatively distort 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 greater number of cells (e.g., more main lobes of a transmitted signal) when flying at certain altitudes. In some embodiments, the WTRU / UAV category type and application ID may also or instead be used to derive reference KPI thresholds (e.g., RSSI, RTT, CQI) or QoS profiles used during data analytics generation and processing.

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

[0140] In some embodiments, the NWDAF / DCCF / ARDF 206 collects and / or initiates the collection of (and may receive) network data in response to the request 306. In some embodiments, the NWDAF / DCCF / ARDF 206 collects and / or initiates the collection of (and may receive) network data in response to something other than the request 306 (e.g., in response to a different request or other message or configuration), e.g., without receiving a request such as the request 306. In some embodiments, the NWDAF / DCCF / ARDF 206 does not collect and / or initiate the collection of network data.

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

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

[0143] In some embodiments, the UAS NF 202 receives data analytics information from the NWDAF / DCCF / ARDF 206 in response 314 or otherwise. In some embodiments, the UAS NF 202 receives data analytics information from another source. In some embodiments, the received data analytics information includes location information (e.g., corresponding to a particular waypoint of the UAV from a historical or ongoing flight path). In some embodiments, 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 status, load, QoS indications, and / or link quality, etc.). In some embodiments, the network data analytics may include indications of alternative flight paths / routes (e.g., alternative waypoints / locations or flight mission times that provide better or optimal network performance).

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

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

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

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

[0148] Figure 44 is a message sequence chart illustrating an example flight path QoE report configuration procedure 400. In this example, a UAE server 402 receives a request 404 from a UAS-specific application server 406 (e.g., a USS) to configure a flight path QoE report. In some embodiments, the UAE server 402 is a middleware server residing between the UAS-specific application server 406 and the 5G core. In some embodiments, the UAE server 402 may receive the flight path QoE report configuration request 404 from the USS server, which may indicate and / or include QoE-related trigger event information (e.g., QoE thresholds, periodicity for collecting information such as QoE information), a validity range for which reports apply (e.g., flight path waypoints and / or geographic areas, time), or any other suitable information.

[0149] In some embodiments, the UAE server 402 may send a response 408 to the UAS-specific application server 406, which may indicate and / or include the requested flight path QoE reporting configuration and may indicate and / or include a positive or negative acknowledgment of the request. In some embodiments, the response 408 and / or its indication or content may be based on whether the UAE server 402 is able to undertake the task.

[0150] In some embodiments, the UAE server may configure the UAE client with a flight path QoE reporting configuration 410 for the UAE client, for example, by sending a configuration request to the UAE client. In some embodiments, the UAE client includes middleware running on a WTRU (e.g., a UAV). In some embodiments, the configuration request sent to the UAE client includes a WTRU (in this example, a UAV) identifier. In some embodiments, the configuration request sent to the UAE client includes some or all of the QoE-related configuration information received in the request 404. In some embodiments, 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.

[0151] Upon successful completion of flight path QoE reporting configuration 410 , UAE server 402 may notify UAS-specific application server 406 , for example, with a flight path QoE reporting configuration complete message 412 .

[0152] Figure 5is a message sequence chart illustrating an example 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-specific application server 406, for example, in a consolidated flight path QoE report.

[0153] In this example, the UAE client 502 can detect a QoE event 504 (e.g., based on a metric exceeding a threshold, such as packet delay). In some embodiments, the UAE client 502 generates a response based on the QoS experienced by the application layer (e.g., packet delay and / or packet loss) and / or from a previously stored QoE reporting configuration (e.g., Figure 4 The QoE events are detected by using the QoE thresholds of the flight path QoE reporting configuration 410 shown in FIG.

[0154] In some embodiments, the UAE server 402 can receive a QoE-related event report 506 from the UAE client. In some embodiments, the report 506 includes or indicates information about QoE information (e.g., indicating low or high QoE). In some embodiments, the UAE server 402 records the event using a current timestamp.

[0155] In some embodiments, at 508, the UAE server 402 may request and receive UAE client location information about the UAE client 502 from the SEAL location service server 510. In some embodiments, the UAE server 402 records the received location information with a current timestamp.

[0156] In some embodiments, the UAE server 402 may send a QoE report 512 to the UAS-specific application server 406, the report including or indicating the QoE information and / or the location information. In some embodiments, for example, based on a QoE reporting configuration, the UAE server 402 may send the QoE report 512 to the UAS-specific application server 406 in response to receiving the QoE information and / or the location information, may periodically send the QoE report 512 to the UAS-specific application server 406, and / or may send the QoE report 512 to the UAS-specific application server 406 in response to the end of the session between the UAE server 406 and the UAE client 502 (e.g., when the flight mission is completed). In some embodiments, in response to the QoE report 512, the UAS-specific application server 406 sends an acknowledgment 514 to the UAE server 402.

[0157] Some embodiments provide KPI-based UAV flight path presentation via a UAS NF and / or KPI-based UAV flight path monitoring and planning. In the following example methods, specific references to details may be implemented, for example, as discussed herein, for example, with respect to network-assisted KPI-based UAV flight path monitoring and planning.

[0158] In this example method, a UAS NF receives a request for a KPI-based UAV flight path report (e.g., reporting network QoS status and / or service experience associated with the flight path). In some embodiments, the request includes a UAV identity and / or WTRU / UAV category 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 period, validity range (e.g., geographic area, time), and / or any other suitable information. The UAS NF sends one or more requests for data analytics collection to a data collection / analysis function (DCCF / NWDAF), the one or more requests providing the WTRU ID, WTRU / UAV category type, QoS / KPI thresholds, area of interest(s), 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 analytics information from the DCCF / NWDAF. In some embodiments, the data analysis information includes time-stamped location information with RAN and / or core metrics (e.g., network status, load, QoS indications, link quality). For example, based on flight path network data retention / sharing policies and / or based on local configuration, the UAS NF requests that the analysis be stored in the ADRF for subsequent USS requests. The UAS NF generates and sends a UAV flight path report to the USS. In some embodiments, the UAV flight path report includes UAV location information with associated KPI information and / or an indication of flight path optimization based on collected statistics or predicted data obtained from the NWDAF / DCCF / ADRF, and / or any other suitable information.

[0159] Some embodiments provide QoE-based UAV flight path monitoring using a UAE layer. In the following example methods, specific references to details may be implemented, for example, as discussed herein, for example, with respect to application layer support for QoE-based UAV flight path monitoring.

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

[0161] Figure 6 6 is a flow chart illustrating an example process 600 for servicing a request for a flight path network data report. In some embodiments, process 600 is implemented in a network device. In some embodiments, the network device implements a UAS-NF (or other network device), and process 600 is implemented by or using that functionality.

[0162] At 602, a report request is received. In some embodiments, the report request is, includes, indicates, or is based on a request for a UAV flight path network data report. In some embodiments, 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 embodiments, the report request is received from a requestor device. In some embodiments, the requestor device is or includes a USS.

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

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

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

[0166] Although the features and elements are described above in specific combinations, it will be appreciated by those skilled in the art 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 can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memories (ROMs), random access memories (RAMs), registers, cache memories, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented in a network device, the method comprising: receiving a request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint; transmitting, 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; receiving, in response to the request for data analytics information, data analytics information regarding at least one UAV corresponding to the at least one waypoint; as well as Transmitting a UAV flight path network data report based on the data analysis information.

2. The method according to claim 1, wherein The network device implements an unmanned aerial system network function (UAS-NF).

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

4. The method according to claim 1, wherein The network device transmits the request for data analysis information, the request being transmitted to another network device implementing a network data analysis function (NWDAF), implementing a data collection coordination function (DCCF), or implementing an analysis data repository function (ARDF).

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

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

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

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

9. The method according to claim 1, wherein The UAV flight path network data report includes UAV location information, key performance information (KPI) or flight route optimization information.

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

11. A network device comprising: circuitry configured to receive a request for an unmanned aerial vehicle (UAV) flight path network data report indicating at least one waypoint; 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; circuitry configured to receive, in response to the request for data analytics information, data analytics information regarding at least one UAV corresponding to the at least one waypoint; as well as Circuitry is configured to transmit a UAV flight path network data report based on the data analysis information.

12. The network device according to claim 11, wherein: The network device includes circuitry configured to implement an Unmanned Aerial System Network Function (UAS-NF).

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

14. The network device according to claim 11, wherein: The network device includes circuitry configured to transmit the request for data analysis information to another network device implementing a network data analysis function (NWDAF), implementing a data collection coordination function (DCCF), or implementing an analysis data repository function (ARDF).

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

16. The network device according to claim 11, wherein: The data analysis information includes network status information, network load information, quality of service (QoS) information or link quality information.

17. The network device according to claim 11, wherein: The request for data analytics information includes key performance information (KPIs) of the UAV.

18. The network device according to claim 11, wherein: The network device includes circuitry configured to transmit the UAV flight path network data report to a UAS service provider (USS).

19. The network device according to claim 11, wherein: The UAV flight path network data report includes UAV location information, key performance information (KPI) or flight route optimization information.

20. The network device according to claim 11, wherein: The UAV flight path network data report includes information based on statistical information or core network (CN) prediction information.

Images