Condition trigger for flight path update indication

Abstract

Systems, methods, devices, and instrumentalities related to conditional triggering for flight path update indication are described herein. A wireless transmit / receive unit (WTRU) may receive configuration information. The configuration information may indicate a trigger condition (e.g., a threshold) associated with the transmission enabling the flight path update indication. The WTRU may determine that a threshold associated with enabling the transmission of the flight path update indication is satisfied. Based on the threshold fulfillment, a flight path update indication may be sent. The WTRU may receive a request to transmit the updated flight path information, and transmit the updated flight path information.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 445,617, filed February 14, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0003] Mobile communications using wireless communications continue to develop. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (legacy) mobile communications RAT mobile communications RAT may be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0004] Systems, methods, devices, and means related to conditional triggering for flight path update indications are described herein.

[0005] A wireless transmit / receive unit (WTRU) may receive configuration information. The configuration information may indicate a trigger condition (e.g., a threshold) associated with enabling transmission of a flight path update indication. The WTRU may determine that the threshold associated with enabling transmission of a flight path update indication is met.

[0006] In an example, the threshold may be a distance threshold. The distance threshold associated with enabling transmission of a flight path update indication may be satisfied based on a distance between the WTRU's location and a previously provided flight path location exceeding the distance threshold. In an example, the threshold may be a time-based threshold. The time-based threshold associated with enabling transmission of a flight path update may be satisfied based on an arrival time at a waypoint location exceeding a previously reported arrival time by a time-based threshold. In an example, the threshold may be a waypoint threshold. The waypoint threshold associated with enabling transmission of a flight path indication may be satisfied based on a number of invalid waypoint(s) exceeding a waypoint threshold.

[0007] Based on the threshold being met, a flight path update indication may be sent. In an example, the flight path update indication may be sent via a UE assistance information (e.g., WTRU assistance information) message or via radio resource control (RRC) signaling. The WTRU may receive a request to send updated flight path information and send the updated flight path information. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 1B It is shown that according to the embodiment, Figure 1AA system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0010] Figure 1C It is shown that according to the embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system is shown in FIG.

[0011] Figure 1D It is shown that according to the embodiment, Figure 1A A system diagram of another example RAN and another example CN used within the communication system shown in .

[0012] Figure 2 An example signaling flow for flight path reporting is shown.

[0013] Figure 3 An example unmanned aerial vehicle (UAV) process for updating an initial flight path report is shown.

[0014] Figure 4 An example of the initial flight path reporting process is shown.

[0015] Figure 5 An example of a conditional trigger for updating an indication is shown.

[0016] Figure 6 Examples of periodic or network-requested triggering for flight path status indication are shown.

[0017] Figure 7 Examples of partial and / or differential update indications are shown.

[0018] Figure 8 An example of a preconfigured fallback is shown.

[0019] Figure 9 An example request for an alternative flight path is shown. DETAILED DESCRIPTION

[0020] Figure 1Ais 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-tail unique word DFT spread OFDM (ZT UW DTS-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0021] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, 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” and / or “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 devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated process chains), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0022] 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 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode-B, a Home Node B, a Home eNode-B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0023] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), 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 wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A 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 an 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.

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

[0025] 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 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Air Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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) communications.

[0026] 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 use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish the air interface 116.

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

[0028] 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 jointly implement LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface used 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).

[0029] 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 Evolution (GERAN), etc.

[0030] Figure 1A The base station 114b in the embodiment may be, for example, a wireless router, a master Node B, a master 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 another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-a Pro, NR, etc.) to establish a microcell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106 / 115.

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

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

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

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

[0035] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal 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.

[0036] 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 an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF signals and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0038] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and 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 (e.g., such as NR and IEEE 802.11).

[0039] The processor 118 of the WTRU 102 may be coupled to and receive user input data from the speaker / microphone 124, keypad 126, and / or 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, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from and store data in any suitable type of 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).

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

[0041] 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 receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

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

[0043] The WTRU 102 may include a full-duplex radio in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. 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 signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both uplink (UL) (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

[0045] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though 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.

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

[0047] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as 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.

[0048] 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 facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0049] 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.

[0050] 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.

[0051] 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 communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may 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.

[0052] Even though the WTRU Figures 1A to 1D Although depicted 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.

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

[0054] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution 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 and destined for a STA may reach the AP and may be delivered to the STA. Traffic from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between a source STA and a destination STA using a direct link setup (DLS) (e.g., sent directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0055] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit a beacon on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. 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, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary signal is sensed / detected by a specific STA and / or is determined to be busy, the specific STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

[0056] 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.

[0057] 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 consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, data can be passed through a fragment parser after channel coding, which can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream separately. The 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 of the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC) layer, entity, etc.

[0058] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, 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 can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, for example, 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).

[0059] 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 primary channel can have a bandwidth 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 a STA that supports (e.g., only supports) a 1 MHz mode (e.g., an MTC-type device), 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 allocation 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 the 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy even if most of the frequency band remains idle and available.

[0060] In the United States, the available frequency bands for 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 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.

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

[0062] The RAN 113 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 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, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located in the unlicensed spectrum, while the remaining component carriers may be located in the licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0063] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmit 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 a different absolute time).

[0064] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as the eNode Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 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-B 160a, 160b, 160c may serve as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

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

[0066] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly a data network (DN) 185a, 185b. While each of the aforementioned elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

[0070] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 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 local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local data networks (DNs) 185a, 185b.

[0071] Given that Figures 1A to 1D and Figures 1A to 1D

[0015] As described above, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more simulation devices (not shown) . The simulation devices may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0072] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions when being implemented and / or deployed in whole or in part as a part of a wired and / or wireless communication network to test other devices in the communication network. One or more simulation devices can perform one or more or all functions when being temporarily implemented / deployed as a part of a wired and / or wireless communication network. The simulation device can be directly connected to another device for testing purposes and / or can use over-the-air wireless communication to perform testing.

[0073] One or more simulation devices can perform one or more (including all) functions when not being implemented / deployed as a part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to achieve the test of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) to transmit and / or receive data.

[0074] As used herein, a timer may refer to a determination of a time or a time period. Timer expiration as used herein may refer to a determination that a time has occurred or a time period has expired. A timer as used herein may refer to a time, a time period, a tracking time, a tracking time period, and the like.

[0075] Systems, methods, devices, and means related to conditional triggering for flight path update indications are described herein.

[0076] A wireless transmit / receive unit (WTRU) may receive configuration information. The configuration information may indicate a trigger condition (e.g., a threshold) associated with enabling transmission of a flight path update indication. The WTRU may determine that the threshold associated with enabling transmission of a flight path update indication is met.

[0077] In an example, the threshold may be a distance threshold. The distance threshold associated with enabling transmission of a flight path update indication may be satisfied based on a distance between the WTRU's location and a previously provided flight path location exceeding the distance threshold. In an example, the threshold may be a time-based threshold. The time-based threshold associated with enabling transmission of a flight path update may be satisfied based on an arrival time at a waypoint location exceeding a previously reported arrival time by a time-based threshold. In an example, the threshold may be a waypoint threshold. The waypoint threshold associated with enabling transmission of a flight path indication may be satisfied based on a number of invalid waypoint(s) exceeding a waypoint threshold.

[0078] Based on the threshold being met, a flight path update indication may be sent. In an example, the flight path update indication may be sent via a UE assistance information (e.g., WTRU assistance information) message or via radio resource control (RRC) signaling. The WTRU may receive a request to send updated flight path information and send the updated flight path information.

[0079] Examples of configurations for flight path update indication and reporting are provided herein. A WTRU may receive a UE information request message (e.g., a WTRU information request message) including a flight path reporting configuration requesting flight path information. The flight path reporting configuration (e.g., configuration information) may include at least one of: the number of waypoints; whether timestamp information is included; conditions and associated thresholds for triggering updated flight path indication; a configuration for periodic reporting of flight path information updates; or, in the event a deviation is required, fallback candidate flight paths and / or waypoint(s) (e.g., additional fallback candidate flight paths and / or waypoint(s)).

[0080] The configuration for the periodicity (e.g., configuration information for the periodicity) may include one or more of the following: the periodicity; the window and / or resources for reporting the updated flight path; or changing the scaling / offset of the periodicity based on the speed and / or position of the WTRU. The conditions for triggering the updated flight path indication may include one or more of the following: the distance and / or delay from the original reported value exceeds a threshold; the number of invalid waypoint(s) and / or timestamp(s) exceeds a threshold; the number of waypoint(s) and / or timestamp(s) exceeds a threshold (e.g., the number of available new waypoint(s) and / or timestamp(s) exceeds a threshold); or a message initiating collision avoidance is received (e.g., from a CN).

[0081] Examples of trigger conditions for flight path update indications are provided herein. If one or more of the trigger conditions are met, the WTRU may send an indication that an updated flight is available. At a configured periodicity, the WTRU may evaluate whether the flight path information has changed since a previous flight path report was sent (e.g., an initial flight path report was sent). If the previous flight path has changed (e.g., the previous flight path information is invalid or waypoints (e.g., new waypoints) are available), the WTRU may send an indication that updated flight path information is available (e.g., via UE assistance information (e.g., WTRU assistance information) for example). The WTRU may receive a request to send updated flight path information. The WTRU may send the updated flight path information. If the previous flight path has not been changed, the WTRU may send a confirmation that no changes have occurred since the previous flight path report. If the configured periodicity is a skip opportunity, the WTRU may retroactively indicate that an indication was skipped in the past (e.g., the past X indications were skipped).

[0082] Examples of partial and / or delta flight data reporting are provided herein. A WTRU may send updated partial and / or delta flight path information that includes one or more of: reporting signaling (e.g., reporting waypoints and delta information from an initial flight path report); reporting that waypoint and / or timestamp information is available (e.g., reporting that new waypoint and / or timestamp information is available); reporting waypoint(s) and / or timestamp(s); reporting that information has become invalid; or reporting that information has become invalid based on a threshold.

[0083] An example of fallback flight path application is provided herein. The WTRU may evaluate (one or more) candidate fallback waypoints and / or flight paths to determine whether one or more candidate fallback waypoints and / or flight paths are suitable alternative routes. If a suitable candidate is found, the WTRU may apply the fallback waypoints and / or flight paths and may notify the network that the (e.g., pre-configured) fallback waypoints and / or flight paths have been applied. In an example, the WTRU may indicate which waypoints and / or flight paths have been updated (e.g., by transmission of an index). The WTRU may detect that the initial flight path is invalid and may notify the network. The WTRU may monitor the network for indications of updated fallback waypoints and / or flight paths to apply. If the WTRU receives one or more fallback waypoints and / or flight paths, the WTRU may update the currently maintained flight path (e.g., the initial flight path) and may send an acknowledgment (ACK) to the network that the updated flight path has been applied.

[0084] Examples of flight path reporting for unmanned aerial vehicles (UAVs) traveling at altitudes up to 300 meters have been provided. These examples may target use cases including drone operations, personal entertainment for flight experience, and / or cargo delivery. Examples of remote control and data transmission capabilities associated with flight path reporting may also be provided.

[0085] An example of flight path reporting based on WTRU capabilities is provided. The flight path information may include waypoint(s), which may be 3D locations. The WTRU may indicate whether flight path information is available via an RRCConnectionReconfigurationComplete message, an RRCConnectionReestablishmentComplete message, an RRCConnectionResumeComplete message, or an RRCConnectionSetupComplete message. This may allow the network to know (e.g., immediately thereafter) whether a connection is established, resumed, and / or modified, whether flight path information is available, which may enable subsequent flight path reporting configuration and requests.

[0086] Figure 2 An example signaling flow for flight path reporting is shown. The E-UTRAN may request the WTRU to report flight path information via a FlightPathInfoReq in a UEInformationRequest message. If reporting of WTRU flight path information is requested, the WTRU may include a FlightPathInfoReport in a UEInformationResponseMessage that includes available waypoints (e.g., all available waypoints up to a configured maximum). Such information may be useful to the network (e.g., for collision avoidance, resource provisioning, and WTRU configuration). Support (e.g., currently supported) configuration of up to 20 waypoint locations within the flight path report may be provided. RAN2 may confirm that a maximum of 20 waypoint locations may be sufficient for NR use cases.

[0087] The WTRU may (e.g., may additionally) be configured to include timestamp information associated with a waypoint (e.g., each waypoint) via includeTimeStamp within the FlightPathInforReportCon configuration. The timestamp may improve the predictability of the WTRU's position at a given time, further aiding in the planning of WTRU configuration and future resource allocation. However, the timestamp information may not always be known, and the timestamp information may (e.g., may only) be included in the flight path report if such information is available at the WTRU.

[0088] An example of a flight path report including a flight path availability indication via a radio resource control (RRC) complete message may be provided. Flight path request and reporting via a UE information request and / or response (e.g., a WTRU information request and / or response) procedure, and similar flight path reporting content may be provided.

[0089] Figure 3 An example process for updating an initial flight path report is shown. Examples of triggers for updating a UAV's flight path report are provided herein. During flight path reporting, if the flight path is not effectively updated after the initial flight path report, this may cause problems, for example, if the WTRU deviates from the planned flight path due to collision avoidance (e.g., one or more reported waypoints or timestamps may be invalidated).

[0090] To maximize the reuse of existing reporting procedures, most of the signaling may be reused for update reporting, except for indicating flight path availability, which may be indicated in a UEAssistanceInformation message. The network may (e.g., then may) use a UE Information Request and / or Response (e.g., a WTRU Information Request and / or Response) procedure to obtain the updated flight path. Excessive and unrestricted flight path updates may result in additional interference, signaling overhead, and may impact WTRU battery power consumption. Examples are provided herein for maintaining flight path information at a desired level of accuracy for the current needs of the WTRU / network while minimizing signaling overhead and interference.

[0091] An exemplary flight path update scenario may include a WTRU that may perform an autonomous flight path update and may notify the network if a previously reported flight path is invalid or out of date. Examples may include the triggering and content of a flight path update indication and / or the transmission and content of an updated flight path report.

[0092]

[0014] An exemplary flight path update scenario may include a WTRU that may be limited to a set of candidate waypoint(s) and / or route(s). If the flight path is invalid, the WTRU may apply a fallback flight path. Examples may include pre-configuration of fallback candidates and autonomous application of flight path updates by the WTRU with subsequent notification. If the WTRU indicates that a route is no longer valid, the network may provide the fallback route(s).

[0093] Examples herein may relate to flight path reporting for UAVs, however, the examples described may (e.g., also) be applicable to other devices or environments where trajectory or path information is exchanged, such as for autonomous vehicles, mobile relays / base stations attached to vehicles, etc. In such cases, flight paths may be exchanged for equivalent interpretations (e.g., trajectories, routes, etc.).

[0094] Examples herein may consider at least one of the following: the WTRU may (e.g., may only) trigger a flight path update if the flight path change meaningfully affects accuracy (e.g., there may be some error tolerance built into the triggering condition); the WTRU may (e.g., may only) update flight path information that has changed to minimize additional signaling overhead (e.g., information that has not changed will not need to be retransmitted); the WTRU may know more about the conditions of the flight path than the network (e.g., so there may be cases where the WTRU will ignore an update request if the information has not changed); or different conditions may apply if the WTRU provides additional waypoints instead of reporting errors in a previous flight path report.

[0095] Examples described herein may enable accurate flight paths (eg, to ensure proper collision avoidance and resource allocation planning) to be maintained while minimizing additional signaling overhead and interference.

[0096] Figure 4An example of an initial flight path reporting procedure is shown. The WTRU may indicate whether flight path information is available via an RRCConnectionReconfigurationComplete message, an RRCConnectionReestablishmentComplete message, an RRCConnectionResumeComplete message, or an RRCConnectionSetupComplete message. The E-UTRAN may request the WTRU to report flight path information by including a FlightPathInfoReq information element (IE) in a UEInformationRequest message. In this IE, the network may include the number of waypoints to be reported by the WTRU (e.g., not exceeding a maximum of 20) and may (e.g., also) request timestamp information. The WTRU may respond to a UE Information Request by including a Flight Path Info Report IE in a UE Information Response Message which may include waypoints (e.g., all available waypoint(s)) up to a configured maximum and timestamp information if requested by the network and available at the WTRU.

[0097] The example UAV may employ similar flight path reporting content (e.g., (one or more) waypoints and (one or more) optional timestamps) and initial reporting procedures. The example UAV may (e.g., may additionally) update a previously reported flight path via an indication in a UE assistance information message (e.g., a WTRU assistance information message). The network may use a legacy UE information request and / or response (e.g., a legacy WTRU information request and / or response) procedure (e.g., if indicated) to obtain the updated flight path (e.g., or in other examples herein may use a legacy UE information request and / or response (e.g., a legacy WTRU information request and / or response) procedure). The UE assistance information message may be referred to herein as a WTRU assistance information message. The UE information request may be referred to herein as a WTRU information request. The UE information response may be referred to herein as a WTRU information response.

[0098] The WTRU may receive a value for at least one parameter of a configuration (e.g., configuration information) for triggering a flight path update (e.g., an indication and / or reporting) from RRC, MAC, or downlink control information (DCI) signaling (e.g., a trigger condition associated with enabling transmission of a flight path update indication). In an example, the WTRU may receive the configuration information within an initial flight path reporting configuration (e.g., within a UE Information Request message (e.g., a WTRU Information Request message)) or within a HO command (e.g., within an RRC reconfiguration with synchronization message).

[0099] The WTRU may receive multiple configurations for triggering a flight path update. A configuration (e.g., each configuration) may be identified by an index, and an indication of the applicable configuration may be received from signaling. The configuration may be specific to one or more of: a cell (e.g., a serving cell) or a cell group; a TRP or a TRP group; or a location (e.g., a waypoint) or a range of locations.

[0100] The WTRU may determine at least one value from one or more of: system information; a dedicated RRC message (e.g., RRC reconfiguration, RRC connection release); a field of a random access response (RAR) message; or an attribute of a RAR grant. In an example, the WTRU may determine the value of the configuration index based on a number of most or least significant bits of a modulation and coding scheme (MCS) field or based on a time domain resource allocation (TDRA) field. The mapping between these bits and corresponding values ​​may be predefined or may be signaled by RRC.

[0101] At least one parameter or configuration index may be determined from a combination of the above examples. The configuration and / or indication of the network may be received in a first message and may be (e.g., then) enabled / disabled by network signaling (e.g., MAC CE, DCI, SIB, RRC, random access channel (RACH) message, etc.) in a second message.

[0102] The WTRU may send a flight path update indication (e.g., an indication that the current flight path has changed from the most recent flight path report) and / or an updated flight path report (e.g., a complete flight path report or a delta / partial flight path report including waypoints and timestamps) via one or more of the following: UE assistance information (e.g., WTRU assistance information); UE information response message (e.g., WTRU information response message); RRC signaling; MAC CE; RACH MSG (e.g., MSG3, MSG5, MSGA); configured authorization timing; L1 report or scheduling request.

[0103] Examples of content for a flight path update indication are provided herein. The flight path update indication may include a flag that the current flight path information has changed from a previously reported flight path. In an example, the WTRU may send additional and / or more detailed information about the current flight path status. The WTRU may send one or more pieces of information in the flight path update indication: invalid time information; invalid waypoint information; invalid number of timestamp(s) and / or waypoint(s); the extent of the change (e.g., small change, large change, percentage change, value of change), where the WTRU may determine the extent of the change based on network configuration; the number of timestamp(s) and / or waypoint(s) available (e.g., new timestamp(s) and / or waypoint(s) available); the number of waypoint(s) to be added (e.g., new waypoint(s) to be added); or a number of waypoints to be removed.

[0104] Examples are provided herein for detecting that a previously reported flight path is no longer valid (e.g., and enabling transmission of a flight path update indication). In an example, the WTRU may autonomously (e.g., based on WTRU implementation) determine whether flight path information is considered changed and / or invalid (e.g., enabling transmission of a flight path update indication) if at least one of the following conditions or a combination thereof occurs: the deviation of the WTRU's actual position from the planned position at a given time (e.g., a previously provided flight path position) exceeds a threshold (e.g., a first distance threshold); the deviation of the WTRU's actual position from the closest position of the flight path exceeds a threshold (e.g., a second distance threshold); the distance between the WTRU's actual position and the closest position of the (valid) fallback flight path is less than the distance between the WTRU's actual position and the closest position of the current flight path minus a threshold (e.g., a third threshold); the WTRU receives an indication from the network (e.g., via RRC) that the current flight path is to be considered invalid; the WTRU receives an indication from the UAV control entity or from another UAV that the current flight path is to be considered invalid; if the expected / estimated time of arrival of a waypoint or set of waypoints (e.g., a previously reported time of arrival) is greater than the expected / estimated time of arrival of the waypoint or set of waypoints. the time of arrival) differs from the current flight path information (e.g., the time to arrive at the current waypoint location) by a certain duration (e.g., a time-based threshold); if the expected / projected waypoint at a certain time differs by a certain distance from the waypoint indicated in the current flight path information; if the WTRU is not expected to be within a certain configured radius / distance from the waypoint; if the WTRU is not expected to arrive at the waypoint within a certain configured time from the time of expected arrival; the number or percentage of waypoints that the WTRU is not expected to traverse (e.g., invalid waypoints) (e.g., in the current flight path information available to the network) is above / below a threshold (e.g., a waypoint threshold); if the WTRU has not yet arrived at the waypoint that it was expected to arrive at when the periodic report was triggered; if the WTRU has not traversed a certain number or percentage of the waypoints that it was expected to traverse when the periodic report was triggered; or if the mobility state of the WTRU has changed by a certain amount (e.g., the WTRU speed has changed by a certain amount, percentage, etc.) from the previous period when the periodic report was triggered and / or sent. The WTRU may receive the first distance threshold, the second distance threshold, and the third distance threshold via signaling (such as an RRC message).

[0105] Examples of conditional triggering for flight path updates are provided herein. In an example, a WTRU may be configured to send an indication to the network that its flight path information has been updated based on one or more conditions (e.g., based on satisfaction of one or more triggering conditions and / or thresholds). If (e.g., subsequently) requested by the network, the WTRU may send the updated flight path. In an example, the WTRU may perform one or more of the following.

[0106] The WTRU may send a first message (e.g., an RRC Connection Complete message) indicating that flight path information is available. The WTRU may receive a second message (e.g., a UE Information Request message (e.g., a WTRU Information Request message)) including a flight path reporting configuration requesting flight path information. The flight path reporting configuration (e.g., configuration information) may include at least one of: the number of waypoint(s); whether timestamp information is included; or a condition (e.g., and an associated threshold) for triggering an updated flight path indication (e.g., a triggering condition for indicating that an updated flight path indication is available).

[0107] The WTRU may monitor conditions (e.g., and associated thresholds) for triggering an updated flight path indication (e.g., triggering conditions and thresholds for indicating that an updated flight path indication is available). The conditions for triggering an updated flight path indication may include one or more of the following: a distance and / or delay from an originally reported value exceeding a threshold (e.g., a distance threshold); a number of invalid waypoint(s) and / or timestamp(s) exceeding a threshold (e.g., a waypoint threshold); a number of available waypoint(s) and / or timestamp(s) exceeding a threshold (e.g., a number of available new waypoint(s) and / or timestamp(s) exceeding a threshold); or receipt of a message initiating collision avoidance (e.g., from a CN).

[0108] If one or more trigger conditions associated with enabling transmission of a flight path update indication are met, the WTRU may send an indication that an updated flight path is available. The WTRU may receive a request to send updated flight path information. The WTRU may send the updated flight path information.

[0109] Figure 5 Examples of conditional triggering for update indications are shown. The trigger condition(s) associated with enabling transmission of a flight path update may include one or more of the following: a threshold associated with enabling transmission of a flight path update indication; a specific value associated with enabling transmission of a flight path update indication; or a range of values ​​associated with enabling transmission of a flight path update indication. For a threshold, the condition may be satisfied if the measured value is above, below, or equal to the threshold. For a specific value, the condition may be satisfied if the measured value is equal to one or more indicated values. For a range of values, the condition may be satisfied if the measured value falls within the range (e.g., in other examples, the condition may be satisfied if the measured value falls outside of an indicated range).

[0110] In an example, according to any of the examples herein, a condition for triggering a flight path update report or indication may include a (e.g., additional) time to trigger (TTT) configuration, where the condition for the TTT may be met before the WTRU considers the condition met and an update report or indication is triggered. In an example, after the WTRU triggers the report or update indication based on the configuration, the conditional flight path update report or change indication configuration may be released and / or deleted. In an example, the WTRU may use the conditional flight path update report or change indication (e.g., until the network has instructed the WTRU to release it). In an example, by sending the report via SRB2, the flight path update report may be sent with a lower priority than other RRC messages (e.g., measurement reports).

[0111] Examples of triggering conditions for an updated conditional flight path or report are provided herein. The conditions for triggering a flight path update indication or report may be time-related. For example, the WTRU may be configured to trigger a flight path update indication or report if the expected / expected time for a waypoint or set of waypoints (e.g., a previously reported arrival time) differs from the current flight path information (e.g., the arrival time at the waypoint location) by a duration (e.g., a time-based threshold). This may be: a delay duration (e.g., the WTRU expects to arrive at a waypoint later than the reported time in the flight path it previously reported to the network); a pre-arrival duration (e.g., the WTRU expects to arrive at a waypoint earlier than the reported time in the flight path it previously reported to the network); or an uncertainty window (e.g., the WTRU expects to arrive at a waypoint earlier or later than the reported time in the flight path it previously reported to the network).

[0112] The conditions for triggering a flight path update indication or report may be distance-related. For example, the WTRU may be configured to trigger a flight path update indication or report if the expected / expected waypoint at a certain time is a certain distance away from the waypoint indicated in the current flight path information (e.g., the distance between the WTRU's location and the previously provided flight path location exceeds a distance threshold). This may be: a delay (e.g., the WTRU may expect to be a certain distance behind a waypoint when it was indicated to be at that waypoint in the flight path information that the WTRU had previously reported to the network); a pre-arrival (e.g., the WTRU may expect to be a certain distance ahead of a waypoint when it was indicated to be at that waypoint in the flight path information that the WTRU had previously reported to the network); or an uncertainty window (e.g., the WTRU may expect to be a certain distance before or after a waypoint when it was indicated to be at that waypoint in the flight path information that the WTRU had previously reported to the network).

[0113] The delay / pre-arrival / uncertainty window time or distance duration / value may refer to all waypoints, a subset of waypoints, or only one specific waypoint.

[0114] A trigger condition for a flight path update indication or report may be when the number or percentage of waypoints that the WTRU is not expected to traverse (e.g., invalid waypoints) (e.g., in the current flight path information available in the network) exceeds a threshold (e.g., a waypoint threshold). A distance threshold may be configured to determine whether the WTRU may consider a waypoint invalid (e.g., if the WTRU is not expected to be within a certain configured radius / distance from the waypoint, the waypoint may be configured as invalid). A time threshold may be configured to determine whether the WTRU may consider a waypoint invalid (e.g., if the WTRU is not expected to arrive at the waypoint within a certain configured time from the time it was expected to arrive at the location, according to (e.g., in) the current flight path information available in the network).

[0115] In an example, the WTRU may be configured to send a flight path update indication or report if it reaches or is near a certain waypoint (e.g., within a certain configured radius from a certain waypoint). In an example, the WTRU may be configured to send a flight path update indication or report if it has passed a certain number or a certain percentage of waypoints previously indicated in the flight path information. For example, the WTRU may be configured to update the flight path if it has traversed half of its previously indicated flight path. In an example, the WTRU may be configured to send a flight path update indication or report if it detects that its mobility has changed by a certain threshold. For example, the WTRU may trigger a report or update indication if the WTRU's speed / acceleration has changed by more than a certain percentage or absolute value compared to the time when the previous flight path information was sent to the network. In an example, an update or update indication may be triggered if the WTRU has changed its mobility state from low mobility to high mobility, where the low and high mobility states may be based on a network-configured range of speed values. The speed / acceleration / mobility change may be axis-dependent (e.g., a speed change on the X, Y, or Z axis). In an example, a WTRU may be configured to send a flight path update indication or report if the WTRU detects that its altitude has changed by a certain threshold since the last time flight path information was sent to the network.

[0116] The RAN may obtain information about the WTRU's flight path from another entity other than the WTRU (e.g., a CN, an application server, etc.). The network may send flight path information to the WTRU, which may inform the WTRU to send a flight path update indication or report (e.g., if the WTRU deviates from the current flight path information according to any example herein). Some waypoints in the flight path information may have higher importance than other waypoints. The WTRU may be configured to consider (e.g., only) those waypoints, or to prioritize conditions related to those waypoints when checking for a trigger for a flight path update indication.

[0117] An example of sending an updated flight path report instead of an update indication is provided herein. In the example, a WTRU (eg, instead of sending an indication to the network that its flight path information is updated) may send an updated flight path (hereinafter also referred to as a flight path report).

[0118] A WTRU may be configured with at least one set of conditions associated with sending an indication to a network that its flight path has changed and at least another set of conditions to directly send a (e.g., updated) flight path report (e.g., without sending an indication to the network and waiting for a network request). Different configurations of triggering conditions for a flight path update indication or report may be uniquely identified (e.g., by an integer value), and the WTRU may include an identification of the configuration and / or conditions that triggered the flight path indication or report in the update indication or report that the WTRU sends to the network. The WTRU may be configured to send the report if the WTRU has an available uplink (UL) grant sufficient for sending the updated flight path report. The WTRU may (e.g., otherwise) send (e.g., only) an indication that a flight path update is available.

[0119] Examples of explicit requests for flight path status are provided herein. In an example, the WTRU may periodically report flight path status (e.g., based on configuration and / or in response to an explicit request from the network). The WTRU may send updated flight path reports (e.g., if subsequently requested by the network). In an example, the WTRU may perform one or more of the following.

[0120] The WTRU may send a first message (e.g., an RRC Connection Complete message) indicating that flight path information is available. The WTRU may receive a second message (e.g., a UE Information Request message (e.g., a WTRU Information Request message)) that includes a flight path reporting configuration requesting flight path information. The flight path reporting configuration (e.g., configuration information) may include at least one of: the number of waypoints; whether to include timestamp information; or a configuration for periodic reporting of flight path information updates. The configuration for periodicity may include one or more of: the periodicity; a window and / or resources for reporting the updated flight path; or a scaling / bias to change the periodicity based on the WTRU's speed / position. The WTRU may send an initial flight path report (e.g., in a third message or a UE Information Response message (e.g., a WTRU Information Response message)).

[0121] At a configured periodicity, the WTRU may evaluate whether the flight path information has changed since a previous flight path report (e.g., an initial flight path report). If the flight path information has changed (e.g., the previous flight path information is invalid or a waypoint (e.g., a new waypoint) is available), the WTRU may send an indication that updated flight path information is available (e.g., via UE assistance information (e.g., WTRU assistance information) example). The WTRU may receive a request to send updated flight path information. The WTRU may send the updated flight path information. If the flight path information has not changed, the WTRU may send an ACK that there has been no change since the previous flight path report. If the configured periodicity is a skip opportunity, the WTRU may retroactively indicate that an indication was skipped in the past (e.g., the past X indications were skipped). In an example, if the network autonomously requests a flight path information update (e.g., without a previous transmission of a WTRU update indication), the WTRU may apply the above behavior.

[0122] Figure 6An example of a periodic or network requested trigger for a flight path status indication is shown. A WTRU may be configured to periodically report the status of a flight path. At the configured periodicity, the WTRU may compare the current flight path with a previously reported flight path. The configuration for the periodicity may include one or more of the following: the periodicity; the window and / or resources for reporting the updated flight path, or a scaling / bias to change the periodicity based on the speed and / or location of the WTRU. The WTRU may be configured with a configured authorization (e.g., such that its periodicity matches the periodicity of flight path related reports) for the window and / or resources to report the updated flight path. The WTRU may use resources to send flight path update reports or indications. For scaling / bias to change the periodicity based on the speed and / or location of the WTRU, the WTRU may scale the periodicity of the reporting if the WTRU is considered to be in a high mobility state or a high speed state.

[0123] In an example, the WTRU may receive a request from the network to report the status of the flight path information, for example, via RRC signaling (e.g., such as a UE Information Request message (e.g., a WTRU Information Request message). The network may indicate one or more of the following (e.g., in addition to the request): resources to respond to the network request (e.g., UL grant); whether to send an ACK / NACK or skip the response entirely if there is no change; or a condition to reply that the flight path has changed (e.g., if the flight path has changed by X% compared to the previously reported flight path, the WTRU may report that the flight path has changed).

[0124] If a periodic trigger is reached (e.g., or if a network request is received), the WTRU may compare the current status of the flight path with the last reported flight path. In an example, if the flight path information has not changed, the WTRU may not send the flight path status. In an example, the flight path status may be a simple indication (e.g., yes or no, ACK or NACK) that may indicate whether the flight path information has changed. In an example, if the flight path has not changed, the WTRU may send an indication. In an example, if the flight path has changed, the WTRU may send an updated flight path. If the WTRU is configured with a configured grant opportunity for reporting status updates, the WTRU may determine whether to send a status indication or a full report based on the size of the configured grant available at that time.

[0125] If the WTRU has deprioritized the transmission of a flight path status or flight path update report (e.g., due to other high priority data or the current flight path has not changed), the WTRU may send a flight path status or flight path update report when UL resources become available later, or the WTRU may skip it entirely until the next reporting period. If the WTRU has skipped an occasion, the WTRU may retroactively indicate that one or more indications have been skipped at the next opportunity that the WTRU sends an ACK / update indication.

[0126] The WTRU may be configured to deprioritize the transmission of flight path status or flight path reports (e.g., even if a configured grant is available) if there is high priority data to be transmitted (e.g., via measurement reports). This may be achieved, for example, by associating flight path reports with SRB2.

[0127] Examples of partial and / or differential updated flight path reporting are provided herein. A WTRU may report partial and / or differential information to convey an updated flight path report (e.g., if requested by the network). The WTRU may perform one or more of the following.

[0128] The WTRU may send a first message (e.g., an RRC Connection Complete message) indicating that flight path information is available. The WTRU may receive a second message (e.g., a UE Information Request message (e.g., a WTRU Information Request message)) including a flight path reporting configuration requesting flight path information. The WTRU may send an initial flight path report in a third message (e.g., a UE Information Response message (e.g., a WTRU Information Response message)). The WTRU may detect that a previously reported flight path (e.g., an initial flight path) needs to be updated (e.g., based on information associated with a change from a previous flight path to an updated flight path).

[0129] The WTRU may send an indication that an updated flight path is available. The indication may include information about the differences associated with the change from the previous flight path report to the updated flight path report (e.g., additional detailed information). The information may include a flag indicating that an updated flight is available; a flag indicating that time information is invalid; a flag indicating that waypoint information is invalid; an invalid time and / or number of waypoints; or an available timestamp and / or number of waypoints (e.g., a new timestamp and / or number of waypoints).

[0130] The WTRU may receive a request for partial and / or differential flight path information. The WTRU may send updated partial and / or flight path information. The updated partial and / or flight path information may include one or more of: reporting incremental signaling (e.g., reporting waypoints and delta information from an initial flight path report); reporting available waypoint / timestamp information (e.g., new waypoint / timestamp information is available); reporting waypoint(s) or timestamp(s); reporting information that has become invalid; or reporting information that has become invalid based on a threshold. The WTRU may receive an ACK indicating receipt of the partial and / or differential flight path information.

[0131] Figure 7 Examples of partial and / or differential update indications are shown. If the WTRU detects that the flight path is invalid (e.g., based on satisfying one or more conditions listed in the examples herein), the WTRU may send an indication that the flight path information is changed. The network may request the WTRU to send complete path information or differential information including changes (e.g., only changes). The network may request differential path information for one or more waypoints. For example, the network may include in the request: one or more waypoint indexes (e.g., a list of indices, a range of indices, etc.); one or more timestamps or timestamp ranges (e.g., which may be interpreted by the WTRU to mean that the network requests an update of waypoints that were previously indicated as being reached within the indicated timestamp range or that the WTRU currently expects to reach within the indicated timestamp range); waypoints that are expected to change in distance by a certain distance from the waypoints indicated in the current path information; waypoints that are expected to arrive at a time that differs by more than a certain threshold from the timestamp indicated by the current flight information; or waypoints that are considered invalid (e.g., waypoints that the WTRU may no longer be expected to traverse).

[0132] If the flight path information is determined to have changed, the WTRU may send delta information directly to the network (e.g., rather than sending an indication and then waiting for the network to request delta information). The WTRU's flight path report / information may include the index / identification of the waypoint, along with the corresponding waypoint coordinates and optional timestamp information (e.g., when the WTRU is expected to be at the waypoint). The WTRU may send an indication to the network that includes (e.g., only includes) the index / identification of the waypoint, the updated waypoint coordinates, and / or the updated timestamp. An example is shown in Table 1 below:

[0133]

[0134]

[0135] Table 1: Initial flight path information transmission network

[0136] If the WTRU determines that information about a waypoint has changed, the WTRU may send delta information (e.g., in a structure similar to the AddMod list used by RRC messages). For example, the following structure in Table 2 may be used to indicate to the network a change in the coordinates of waypoint 2, a change in the timestamp of waypoint 3, and a change in the coordinates and timestamp of waypoint n:

[0137] index Updated waypoints Update timestamp 1 - - 2 W2_new - 3 - T3_new … … … n Wn_new Tn_new

[0138] Table 2: Example of a waypoint add modification list (WaypointAddModList)

[0139] In an example, the waypoint coordinates or timestamp values ​​indicated in the delta flight path update may be absolute values. In an example, the waypoint coordinates or timestamp values ​​indicated in the delta flight path update may be relative to a previous value of the indicated waypoint (e.g., the network may add / subtract the indicated value from the previous value of the associated waypoint to obtain the waypoint coordinates or timestamp).

[0140] The delta information sent for a given waypoint may apply to the waypoint (e.g., all subsequent waypoints thereafter), and the WTRU may include such an indication in the waypoint indication. For example, the WTRU may explicitly indicate that the delta information is propagated (e.g., as shown in Table 3 below).

[0141]

[0142] Table 3: Example of a waypoint addition modification list with propagation conditions (assuming absolute values ​​are indicated)

[0143] If a delta update is received, the network may consider updating the coordinates of waypoints with indices greater than or equal to 10 (e.g., all waypoints) by (W2_new - W2_old) and updating the timestamps of waypoints with indices greater than or equal to 13 (e.g., all waypoints) by (T3_new - t3_old). The propagation indication may be at the message level (e.g., as shown in the example here) or it may be at the waypoint level. An example at the waypoint level is shown in Table 4 below:

[0144] spread? index Updated waypoints Update timestamp yes 10 W2_new - no 13 - T3_new

[0145] Table 4: Example of a waypoint addition modification list with propagation conditions (assuming absolute values ​​are indicated)

[0146] In an example, the absence of a propagate indication may be interpreted as a NO indication (e.g., delta updates may apply only to the waypoint in question). In an example, the absence of a propagate indication may be interpreted as a YES indication (e.g., delta updates may apply to all subsequent waypoints).

[0147] The delta update may include information about the waypoint(s) to be removed from the flight path. For example, WayPointToReleaseList = Index: 10, 13, 15, which may indicate to the network that waypoints 10, 13, and 15 are not valid (e.g., no longer valid) and may be removed.

[0148] The release of a waypoint may be propagated or non-propagated (e.g., similar to a modification of a waypoint). For example, the removal of waypoint 13 may be interpreted by the network as indicating that waypoints with indices 13 or above (e.g., all waypoints) are to be removed from the flight path information. In an example, if a waypoint is removed, the indices of other waypoints may not be affected. In an example, if a waypoint is removed, the indices of waypoints indexed above the waypoint may be decremented by 1 to accommodate the change. For example, if a WTRU has 3 waypoints in a flight path and the WTRU has sent an indication to release waypoint #2, then the old waypoint #3 may adopt an index value of 2.

[0149] To prevent cascading errors (e.g., additive errors) (e.g., due to erroneously received delta signaling) and to ensure proper alignment between the WTRU and the network on the current state of the flight path, the WTRU may receive an ACK from the network that the partial and / or delta flight path information has been successfully received. If the WTRU does not receive such an ACK (e.g., within a period of time after the delta flight path report), the WTRU may send (e.g., another) flight path report including the full value.

[0150] Examples of preconfigured fallback waypoint(s) and / or flight path(s) are provided herein. The WTRU may fall back to an alternative preconfigured flight path and / or waypoint. The WTRU may perform one or more of the following.

[0151] The WTRU may send a first message (e.g., an RRC Connection Complete message) indicating that flight path information is available. The WTRU may receive a second message (e.g., a UE Information Request message (e.g., a WTRU Information Request message)) including a request for flight path information and a flight path reporting configuration for candidate fallback waypoints or an updated flight path (e.g., additional candidate fallback waypoints or an updated flight path). The WTRU may send an initial flight path report in a third message. The WTRU may detect whether a previously reported flight path (e.g., an initial flight path) is invalid.

[0152] The WTRU may evaluate candidate fallback waypoint(s) and / or updated flight path(s) to determine if one or more are suitable alternative routes. In an example, if suitable candidates are found, the WTRU may apply one or more fallback waypoints and / or updated flight paths. The WTRU may notify the network that (e.g., pre-configured) fallback waypoints and / or updated flight paths have been applied.

[0153] In an example, the WTRU may indicate which waypoint(s) and / or which updated flight path(s) have been updated (e.g., by transmission of an index). In an example, if a suitable candidate is found, the WTRU may send a request to confirm whether the WTRU may apply the (e.g., preconfigured) fallback waypoint(s) and / or updated flight path(s). The WTRU may receive a response approving the candidate fallback waypoint(s) or updated flight path(s). If the candidate is approved, the WTRU may confirm the approval and apply one or more of the fallback waypoint(s) or updated flight path(s). If the candidate is rejected, the WTRU may perform an autonomous update procedure. If no suitable candidate is found, the WTRU may perform an autonomous flight path update and notify the network.

[0154] Figure 8 An example of a preconfigured fallback is shown. A WTRU / UAV may be configured with at least one candidate flight path or waypoint. Without loss of generality, one of the at least one candidate flight paths may be the flight path currently being followed by the WTRU / UAV. This flight path may be referred to as the current or initial flight path. The remaining flight path(s) in the at least one candidate flight path may be referred to as the fallback flight path(s).

[0155] The WTRU may send the initial flight path and at least one fallback flight path in at least one of the following: in an RRC Connection Complete message; or in a UE Information Response message (e.g., a WTRU Information Response message) (e.g., as part of a UE Information Request (e.g., a WTRU Information Request) procedure). The flight paths (e.g., each flight path) may be identified by a flight path identifier. The WTRU may determine a priority level for the flight paths (e.g., each flight path) based on at least one of: a flight path for which the distance between the WTRU's actual location and the nearest point on the flight path is minimized; a flight path that minimizes travel time or distance to the destination; or an explicit priority indication from the network.

[0156] In an example, the WTRU may receive an explicit priority indication of a flight path (e.g., each flight path) from the network (e.g., after transmitting the initial flight path and the fallback flight path). In an example, the WTRU may receive the explicit priority indication in response to a request to modify the current flight path to the fallback flight path.

[0157] The WTRU may notify the network that the current flight path is being changed to a fallback flight path. The WTRU may evaluate the validity of the fallback flight paths (e.g., based on the conditions described in the examples herein). If at least one fallback flight path is valid, the WTRU may select one of the fallback flight paths and update the current flight path to that fallback flight path. If no fallback flight path is valid, the WTRU may autonomously determine an alternative (e.g., not previously indicated) or default flight path.

[0158] The WTRU may send an indication to the network (e.g., using a flight path identifier) ​​that the flight path has changed to one of the fallback flight path or the default flight path, or may provide a previous flight path that was not indicated (e.g., if no fallback flight path is valid). Such an indication may be included in an RRC message (e.g., a measurement report or a message type dedicated to this purpose (e.g., a new message type). The WTRU may (e.g., may) apply the change in flight path.

[0159] The WTRU may send a request to the network to change the flight path to one of the fallback flight paths. The WTRU may include an identification of the proposed fallback flight path in the request. The WTRU may (e.g., may subsequently) receive a response from the network. If the response indicates confirmation of the fallback flight path, the WTRU may change the current flight path to the fallback flight path. If the response indicates a rejection of the proposed fallback flight path, the WTRU may apply a default flight path or an alternative (e.g., one that was not previously signaled) flight path. The response may (e.g., may also) indicate a set of possible fallback flight paths using a priority indication. The WTRU (e.g., in this case) may select one of the valid fallback flight paths (e.g., the highest priority) and may change the current flight path to the fallback flight path. The WTRU may (e.g., may subsequently) send a notification to the network including the selected fallback flight path.

[0160]

[00145] This document provides examples of network-indicated fallback waypoints and / or flight paths. The WTRU may request an updated flight path, waypoints, and / or waypoint set from the network. The WTRU may perform one or more of the following.

[0161] The WTRU may send a first message (e.g., an RRC Connection Complete message) indicating that flight path information is available. The WTRU may receive a second message (e.g., a UE Information Request message (e.g., a WTRU Information Request message)) including a flight path reporting configuration requesting flight path information. The WTRU may send an initial flight path report (e.g., within a third message). The WTRU may detect that the initial flight path is invalid and notify the network. The WTRU may indicate a set of waypoints that are no longer valid and may (e.g., be needed) as an alternative. The WTRU may monitor the network for updated fallback waypoints and / or flight paths to apply. In an example, the WTRU may monitor the network for a fixed duration.

[0162] If the WTRU receives the fallback waypoints and / or flight path, the WTRU may update the currently maintained flight path (e.g., the initial flight path). The WTRU may send an ACK to the network that the updated flight path has been applied. If the WTRU does not receive the fallback waypoints or flight path (e.g., in time), the WTRU may perform autonomous flight path corrections and may send a flight path update indication to the network.

[0163] Figure 9An example request for an alternative flight path is shown. The WTRU may let the network decide on a fallback route or waypoint location. This may be useful, for example, to allow the network to steer the WTRU to an area that is less congested by other WTRUs, or to help with load balancing on the network side (e.g., by physically steering the WTRU to a different location).

[0164] If the WTRU detects that the current flight path is no longer valid (e.g., based on satisfying one or more of the conditions listed in the examples herein), the WTRU may notify the network. The notification may include (e.g., in addition to) a request for updated waypoint and / or flight path information from the network. The WTRU may remain stationary in the air (e.g., while waiting for a response from the network).

[0165] The WTRU may monitor the network response for a given time period (e.g., the monitoring may be initiated if an indication / request is received). If the WTRU receives an indication including alternative fallback flight path information and / or waypoints within the time period, the WTRU may adjust the WTRU's flight path accordingly. If a flight path adjustment is performed, the WTRU may send an ACK to the network to notify that the flight path has been successfully updated. If a flight path update is performed, the WTRU may send an updated flight path report. The WTRU may receive the updated flight path and / or waypoints via one or more of: RRC signaling, MAC CE, or DCI.

[0166] If the WTRU does not receive the alternative flight path and / or waypoints, receives a negative acknowledgement (NACK) or a rejection of the request, or if the WTRU does not receive the alternative flight path and / or waypoints within the indicated time period, the WTRU may perform autonomous flight path corrections. If (e.g., when) autonomous flight path corrections have been applied, the WTRU may notify the network (e.g., via a flight path update notification) or may directly send an updated flight path report.

[0167] Examples of inhibit conditions for triggering flight path indications are provided herein. An inhibit timer may be configured to control the WTRU from sending two consecutive flight path update reports or indications within a given time (e.g., the WTRU may refrain from sending a second flight path update report or indication after sending a first flight path update report or indication for the configured inhibit timer duration). The timer may be started when a flight path report is sent and / or a flight path update is indicated. The inhibit timer may be overridden, for example, based on a network request or subject to certain conditions (e.g., more than X waypoints have become invalid).

[0168] Although the above features and elements are described in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements.

[0169] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the embodiments described herein are not limited to such scenarios and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and may be applicable to other wireless systems.

[0170] The above process may be implemented in a computer program, software, and / or firmware that is incorporated into a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disc (CD)-ROMs and / or digital versatile discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor configured to: receiving configuration information via a radio resource control (RRC) reconfiguration message, wherein the configuration information indicates a threshold associated with enabling transmission of a flight path update indication; determining that the threshold associated with enabling transmission of the flight path update indication is satisfied; and Based on the threshold being met, the flight path update indication is sent via a user equipment (UE) assistance information message or RRC signaling.

2. The WTRU of claim 1 , wherein: The threshold is a distance threshold, and wherein the distance threshold associated with enabling transmission of the flight path update indication is met based on a distance between the WTRU's location and a previously provided flight path location exceeding the distance threshold.

3. The WTRU of claim 1 , wherein: The threshold is a time-based threshold, and wherein the time-based threshold associated with enabling transmission of the flight path update indication is satisfied based on an arrival time at a waypoint location exceeding a previously reported arrival time by the time-based threshold.

4. The WTRU of claim 1 , wherein: The threshold is a waypoint threshold, and wherein the waypoint threshold associated with enabling transmission of the flight path update indication is met based on a number of invalid waypoints exceeding the waypoint threshold.

5. The WTRU of claim 1 , wherein: The processor is further configured to: receiving a request to send updated flight path information; and The updated flight path information is sent.

6. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information via a radio resource control (RRC) reconfiguration message, wherein the configuration information indicates a threshold associated with enabling transmission of a flight path update indication; determining that the threshold associated with enabling transmission of the flight path update indication is satisfied; and Based on the threshold being met, the flight path update indication is sent via a user equipment (UE) assistance information message or RRC signaling.

7. The method according to claim 6, wherein: The threshold is a distance threshold, and wherein the distance threshold associated with enabling transmission of the flight path update indication is met based on a distance between the WTRU's location and a previously provided flight path location exceeding the distance threshold.

8. The method according to claim 6, wherein: The threshold is a time-based threshold, and wherein the time-based threshold associated with enabling transmission of the flight path update indication is satisfied based on an arrival time at a waypoint location exceeding a previously reported arrival time by the time-based threshold.

9. The method according to claim 6, wherein: The threshold is a waypoint threshold, and wherein the waypoint threshold associated with enabling transmission of the flight path update indication is met based on a number of invalid waypoints exceeding the waypoint threshold.

10. The method according to claim 6, further comprising: receiving a request to send updated flight path information; as well as The updated flight path information is sent.

Images