Mobility execution of unmanned aerial vehicles using candidate configuration TA values

Abstract

Systems, methods, and instrumentalities are disclosed for mobility execution of unmanned aerial vehicles (UAVs) using candidate configuration timing advance (TA) values. A wireless transmit receive unit (WTRU) may receive configuration information indicating a candidate target cell from a network node. The WTRU may receive timing advance (TA) information. The TA information may indicate a first TA value associated with the candidate target cell. The TA information may indicate a TA selection condition. The WTRU may receive an indication of using the candidate target cell as a handover target cell. The WTRU may determine whether a TA selection condition associated with a first TA value for handover of the target cell is satisfied. The WTRU may determine whether to use a random access channel-free (RACH) handover to the handover target cell or a RACH handover to the handover target cell. The WTRU may perform a handover to a handover target cell.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 445621, filed February 14, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be called 5G. The previous generation (traditional) mobile communication can be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] A system, method, and means for performing mobility operations of an unmanned aerial vehicle (UAV) using candidate configuration timing advance (TA) values ​​are disclosed. A radio transmit receiver unit (WTRU) can receive configuration information indicating candidate target cells from a network node. The WTRU can receive timing advance (TA) information from the network node. The TA information may indicate a first TA value associated with the candidate target cell. The TA information may indicate TA selection conditions associated with the first TA value. The WTRU can receive an indication from the network node to use the candidate target cell as a handover target cell. The WTRU can determine whether the TA selection conditions associated with the first TA value used for the handover target cell are met. The WTRU can determine whether to use a no-random-access-channel (RACH) handover to the handover target cell or a RACH handover to the handover target cell. The WTRU can perform a handover to the handover target cell based on this determination.

[0004] If the TA selection conditions associated with the first TA value used for handover to the target cell are met, the WTRU can use a RACH-less handover to the target cell. If the TA selection conditions associated with the first TA value used for handover to the target cell are not met, the WTRU can use a RACH handover to the target cell. RACH handover may include the use of a second TA value obtained during RACH handover.

[0005] TA selection criteria can be associated with a distance threshold. This distance threshold can be related to the distance between the WTRU and the waypoint. TA selection criteria are satisfied when the distance between the WTRU and the waypoint is below the threshold. A first TA value can be associated with candidate target cells and waypoints. Candidate target cells can include L1 / L2 triggered mobility (LTM) candidate target cells. Configuration information can be received via Radio Resource Control (RRC) messages. Attached Figure Description

[0006] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0007] Figure 1B The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example wireless transmit / receive unit (WTRU) used within the communication system.

[0008] Figure 1C The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown.

[0009] Figure 1D The illustration based on one embodiment can be seen in Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0010] Figure 2 An example of L1 / L2 triggered mobility (LTM) using carrier aggregation (CA) is shown.

[0011] Figure 3 An example of LTM is shown.

[0012] Figure 4 An example of the signaling flow for flight path reporting of an unmanned aerial vehicle (UAV) is shown.

[0013] Figure 5 An example of an initial flight path report is shown.

[0014] Figure 6 An example of providing a candidate timing advance (TA) value when LTM candidate configuration is shown.

[0015] Figure 7 An example of using conditional LTM triggering to determine whether to perform a RACH switch or not is shown.

[0016] Figure 8 An example of providing candidate TA values ​​during LTM execution is shown.

[0017] Figure 9 An example of early synchronization with one or more candidate or target cells is shown, based on the fulfillment of conditions triggered by an update indication. Detailed Implementation

[0018] Figure 1AThis diagram illustrates an example communication system 100 that may implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables 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 Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0019] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments are contemplated to 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. For example, WTRUs 102a, 102b, 102c, and 102d—any of which can be referred to as a “station” and / or “STA”—can be configured to transmit and / or receive wireless signals and can include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0020] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN106 / 115, Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0021] 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 base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for radio services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0022] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0023] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0025] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0026] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can 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).

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

[0028] Figure 1A Base station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0029] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it will be understood that RAN 104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0032] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example: ...) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 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 peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0033] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors 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, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

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

[0036] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers for example enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0037] The processor 118 of WTRU 102 can be coupled to and receive user input data from: a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from and store data in any suitable type of memory (such as non-removable memory 130 and / or removable memory 132). 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. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, the processor 118 can access information from and store data in memory that is not physically located on WTRU 102 (such as a server or home computer (not shown)).

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

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

[0040] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

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

[0042] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

[0044] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0045] Figure 1C The CN 106 shown 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 CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0046] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and so on. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0047] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

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

[0049] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, 102c and conventional landline communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0051] In a representative embodiment, another network 112 may be a WLAN.

[0052] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfacing with a Distributed System (DS) or carry services within and / or out of the BSS to another type of wired / wireless network. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0053] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can listen on the primary channel. If the primary channel is listened to / detected by a particular STA and / or determined to be busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0054] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0055] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels—this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0056] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to the operating modes used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (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 metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities (e.g., limited capabilities) including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0057] WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs that support the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

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

[0059] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

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

[0061] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0062] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without access to other RANs (e.g., eNode-B160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0063] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0064] Figure 1DThe CN 115 shown 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 foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0065] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU102a, 102b, and 102c based on the service types being used by WTRU102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or the like. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies such as WiFi.

[0066] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure service routes through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0067] UPF 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This N3 interface provides WTRU 102a, 102b, and 102c with access to a packet-switched network (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0068] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and data networks (DNs) 185a and 185b.

[0069] Given Figures 1A-1D and Figures 1A-1D The corresponding descriptions herein regarding one or more of the functions of WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0071] One or more emulation devices may perform one or more functions (including all functions) but are not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0072] Inter-cell L1 / L2 triggered mobility (LTM) can be implemented. Inter-cell beam management can be used to manage beams in carrier aggregation (CA), with or without cell change / addition support. LTM can be used for mobility latency reduction.

[0073] LTM inter-cell beam management can address both intra-DU and intra-frequency scenarios. In some examples, the serving cell can remain unchanged (e.g., there is no possibility of changing the serving cell using L1 / L2-based mobility). In FR2 deployments, CA can be used to utilize available bandwidth, for example, to aggregate multiple CCs in a single frequency band. These CCs can be transmitted using the same analog beam pairs (e.g., gNB beams and WTRU beams). The WTRU can be configured with TCI states (e.g., 64) for receiving the Physical Downlink Control Channel (PDCCH) and Physical Downlink Shared Channel (PDSCH). Each TCI state may include a Reference Signal (RS) or SSB, which the WTRU references to set its beam. The SSB may be associated with a non-serving PCI. Media Access Control (MAC) signaling (e.g., TCI state indication for a WTRU-specific PDCCH MAC CE) can activate the TCI states of the Control Resource Set (CORESET) / PDCCH. A MAC control element (CE) indicating the TCI state associated with a non-serving PCI can support PDCCH reception from a non-serving cell. MAC signaling (e.g., TCI state activation / deactivation for a WTRU-specific PDSCH) can activate (e.g., up to 8) subsets of TCI states for PDSCH reception. A DCI can indicate (e.g., which of the 8 TCI states). A unified TCI state can be supported using (e.g., DCI-based) different update mechanisms, such as without multiple TRPs. A unified TCI state with multiple TRPs can also be supported.

[0074] LTM can improve handover latency. The WTRU can (e.g., initially) use RRC signaling to send measurement reports in both regular L3 and conditional handover scenarios. For example, in response to the measurement report, the network can provide additional measurement configurations and / or conditional handover configurations. In handover scenarios, for example, after the WTRU reports that the cell meets the configured radio quality criteria using RRC signaling, the network can provide the target cell configuration. In the case of conditional handover, the network can (e.g., in advance) provide the target cell configuration and / or measurement criteria, which can determine when the WTRU should trigger CHO configuration (e.g., to reduce the handover failure rate due to delays in sending measurement reports and then receiving RRC reconfiguration). These L3 methods may suffer from delays, particularly in regular (unconditional) handover scenarios, due to the sending of measurement reports and the receiving of target configurations.

[0075] LTM allows for the rapid application of candidate cell configurations, including dynamic switching between SCells and PCells (e.g., role switching between SCells and PCells), without the need for RRC signaling. Inter-CU scenarios may not involve PDCP anchor relocation. RRC-based approaches can support inter-CU handovers.

[0076] Before the WTRU moves to complete the handover to the target cell in the coverage area of ​​the new site, one or more currently active SCells may be released. After a successful handover, the currently active SCells may be added back, which may result in a decrease in throughput during the handover. L1 / L2 allows CA operation to be enabled immediately when the serving cell changes.

[0077] Figure 2 An example of LTM operation is shown. Candidate cell groups can be configured using information received via RRC messages. Dynamic switching of PCells and / or SCells can be achieved using L1 / L2 signaling. Figure 2 An example of LTM using carrier aggregation (CA) is shown.

[0078] Figure 3 An example of the LTM process is shown. (As illustrated by...) Figure 3 As shown in the example, at point 1, the WTRU can send a measurement report message to the gNB. The gNB may decide to use LTM. The gNB may initiate preparation for an LTM candidate.

[0079] At point 2, the gNB can transmit an RRC reconfiguration message to the WTRU, which may include, for example, the configuration of one or more LTM candidate target cells.

[0080] At point 3, the WTRU can store the configuration of one or more LTM candidate target cells. The WTRU can transmit an RRC reconfiguration complete message to the gNB.

[0081] At point 4, the WTRU may, for example, perform DL synchronization and / or TA acquisition with one or more candidate target cells before receiving an LTM cell switching command. For example, at least based on the SSB (e.g., SSB reception), DL synchronization of one or more candidate cells before the cell switching command may be supported. For example, at least based on PDCCH ordered RACH, TA acquisition of one or more candidate cells before the LTM cell switching command may be supported. The PDCCH order may be (e.g., only) triggered by the source cell.

[0082] At point 5, the WTRU can perform L1 measurements on one or more configured LTM candidate target cells. The WTRU can transmit lower-layer measurement reports to the gNB. Lower-layer measurement reports can be carried on L1 or MAC.

[0083] At point 6, the gNB can decide to perform LTM cell switching on the target cell. The gNB can, for example, transmit a MAC CE that triggers the LTM cell switching via a candidate configuration index including the target cell. The WTRU can switch to the configuration of the LTM candidate target cell.

[0084] At point 7, the WTRU can, for example, perform a random access procedure to the target cell if the TA is unavailable.

[0085] At point 8, the WTRU can indicate (e.g., successful) completion of the LTM cell exchange to the target cell.

[0086] Uplink signals or messages after the WTRU has been switched to the target cell can be used to indicate the successful completion of LTM cell switching.

[0087] Unmanned aerial vehicles (UAVs) can be supported in LTE (e.g., operating at altitudes up to 300m). Use cases may include drone operation, personal entertainment for flight experiences, and cargo delivery. Applications can support capabilities for remote control and data transmission (e.g., including UL and DL interference and mobility).

[0088] Measurement reports can be based on configured altitude thresholds. Airborne WTRUs can support altitude-triggered measurement reports, for example, based on WTRU capabilities. Altitude-based events can be defined. For example, event H1 might occur when the airborne WTRU altitude becomes above an absolute threshold. Event H2 might occur when the airborne WTRU altitude becomes below an absolute threshold.

[0089] The height threshold can be configured in the Measurement Configuration via the Height Threshold Reference. The height threshold can support values ​​ranging from -420m to 8880m (e.g., in 300m increments). The WTRU can be configured with offsets "h1-threshold offset" and "h2-threshold offset" in the Reporting Configuration EUTRA. The WTRU can also be configured with hysteresis parameters "h1-hysteresis" and "h2-hysteresis," which can be applied separately, for example, during event assessment.

[0090] The height, position, and / or velocity of the WTRU can be reported. The WTRU can be configured to include additional information (e.g., the WTRU's height, position, and horizontal / vertical velocity) within the measurement report. Position reporting can be supported via a "Location Information" element (IE), which can be used to convey detailed location information available at the WTRU to correlate measurements and WTRU location information. Available information may include WTRU location information (e.g., via "Location Coordinates") and / or WTRU azimuth and horizontal velocity (e.g., via "Horizontal Velocity").

[0091] LTE UAV features may involve reporting vertical information via “vertical velocity information”. “Vertical velocity information” may include a selection between the parameters “vertical velocity” and “vertical velocity and uncertainty”, where “vertical velocity” may include WTRU orientation, horizontal / vertical velocity, and / or vertical direction, and “vertical velocity and uncertainty” may include information within “vertical velocity” and / or uncertainties in both horizontal and vertical velocity.

[0092] Based on WTRU capabilities, flight path reporting for in-flight WTRUs can be supported (e.g., in LTE). Flight path information can include several waypoints, which can be 3D locations. The WTRU can indicate the availability of flight path information, for example, via "RRC connection reconfiguration complete," "RRC connection rebuild complete," "RRC connection recovery complete," and / or "RRC connection setup complete" messages. Flight path information allows the network to know its availability immediately after connection is established, enabling subsequent flight path reporting configuration and requests.

[0093] The Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN) can be used, for example, to request the WTRU to report flight path information via a "Flight Path Information Request" message within a "WTRU Information Request" message. When requesting the WTRU to report flight path information, the WTRU can include a "Flight Path Information Report" in a "WTRU Information Response Message," which includes (e.g., all) available waypoints up to a configured maximum. Flight path information may be useful to the network, for example, for collision avoidance, resource provisioning, and / or WTRU configuration. A maximum number (e.g., up to 20) of waypoint locations within the flight path report can be configured (e.g., in LTE). RAN2 can confirm that the maximum number (e.g., 20) of waypoint locations (e.g., for NR use cases) is sufficient.

[0094] Figure 4An example of the signaling flow for a UAV's flight path reporting is shown. A WTRU can be configured to include timestamp information associated with (e.g., each) waypoint, for example, via "Include Timestamps" within the "Flight Path Information Reporting Configuration". Timestamps can improve the predictability of the WTRU's location at a given time, which can help plan WTRU configuration and future resource allocation. Timestamp information may not always be known. For example, timestamp information may be included in the flight path report (e.g., only if such information is available at the WTRU).

[0095] Multiple cell triggering criteria can be met simultaneously. The airborne WTRU can be configured with Radio Resource Management (RRM) events (e.g., A3, A4, or A5) that trigger a measurement report of the per-cell Reference Signal Received Power (RSRP) value based on the configured number of cells that meet the configured event. Once the measurement report is sent, the list of triggering cells can be updated, for example, if one or more subsequent cells meet the event. When the list of triggering cells remains larger than the configured number of cells, additional measurement reports may not be sent.

[0096] The number of trigger cells required for measurement reporting can be provided, for example, in the "Report Configuration EUTRA" via "Number of Triggered Cells". The number of trigger cells used for measurement can range from a minimum (e.g., two (2)) to a maximum (e.g., eight (8)). For example, information about the number of trigger cells may be useful for interference detection and / or for reducing signaling overhead, for example, by reducing the number of measurement reports.

[0097] Airborne WTRUs (UAVs) can be supported in LTE and NR, enabling simultaneous fulfillment of altitude-based measurement reports, flight path reports, and / or triggering criteria for multiple cells using similar mechanisms. Support can be provided for altitude-dependent parameter scaling, user consent for location reports, flight path updates after initial reporting, and beamforming and reporting regarding departure conditions in the "Number of Triggering Cells".

[0098] In LTM, candidate cells can be pre-configured via RRC. For example, cell switching can be performed via L1 signaling and / or based on L1 measurements. Flight path reports from one or more UAVs can inform the network (NW) where the WTRU is located at a given time, which can enable the provision of additional information during candidate configuration (e.g., timing advance (TA)), providing information on when / where the WTRU should perform and report L1 / L2 measurements, and / or help determine which type of RACH procedure to perform. Flight path information can also be used, for example, to improve the early synchronization and execution of L1 / L2 triggered mobility (LTM).

[0099] While the examples pertain to UAV flight path reporting, they can be applied to other devices or situations where trajectory or path information is interchangeable. For example, the examples described herein can be applied to autonomous vehicles, mobile relays / base stations attached to vehicles, and so on. In these and other situations, "flight path" can be used interchangeably with equivalent interpretations (e.g., trajectory, route, etc.).

[0100] The WTRU and network can accurately determine the current UAV flight path (e.g., the current UAV flight path). For example, the WTRU can adhere to the initial flight path report. If changes have occurred in the initial or previously reported flight path, the WTRU can provide an updated flight path.

[0101] The examples described herein can enable networks and WTRUs to utilize (e.g., via flight path reports) additional information about the location of WTRUs, for example, to facilitate advance timing (TA) acquisition, RACH, and LTM execution.

[0102] Figure 5 An example of an initial flight path report is shown. A UAV's flight path report can be generated, for example, via... Figure 5 To summarize. For example, by Figure 5 As shown in the example, at point 1, the WTRU can indicate whether flight path information is available via an RRC message. For example, the RRC message could be "RRC connection reconfiguration complete", "RRC connection reconstruction complete", "RRC connection recovery complete", and / or "RRC connection setup complete" messages.

[0103] At point 2, the E-UTRAN can, for example, request the WTRU to report flight path information by including a "Flight Path Information Request" (IE) information element in the "UE Information Request" message. The network can indicate the number of waypoints to be reported by the WTRU (e.g., in the IE) (e.g., up to a maximum of 20). The network can also request timestamp information.

[0104] At point 3, the WTRU may respond to a UE information request, for example, by including a Flight Path Information Report (IE) in the UE information response message (which includes, for example, all, available waypoints (e.g., up to the configured maximum) and / or timestamp information (e.g., if requested by the network and available at the WTRU)). The UE information request / response message in this document may be a WTRU information request / response message.

[0105] UAVs can have similar flight path reporting content (e.g., waypoints and optional timestamps) and initial reporting procedures. UAVs can update previously reported flight paths, for example, via instructions in UE auxiliary information messages. The network can retrieve the updated flight path using a UE information request / response procedure (e.g., or another procedure described herein). The UE auxiliary information message in this document can be a WTRU auxiliary information message. The UE information request / response procedure in this document can be a WTRU information request / response message.

[0106] The WTRU may transmit flight path update indications (e.g., indications that the current flight path has changed from the most recent flight path report) and / or updated flight path reports (e.g., full flight path reports or incremental / partial flight path reports including waypoints and / or timestamps) via one or more of the following (e.g., signaling examples): UE auxiliary information; UE information response messages; RRC signaling; MAC CE; RACH messages (e.g., MSG3, MSG5, MSGA); configured authorization (CG) timing; L1 reports; and / or scheduling requests (SRs). The UE information response message in this document may be a WTRU information response message.

[0107] Triggering conditions (e.g., UAV-specific triggering conditions) may include one or more of the following: a threshold, a specific value, and / or a value range. A triggering condition may include a threshold. For example, a triggering condition may be satisfied if the measured value is higher than, lower than, or equal to a threshold. A triggering condition may include a specific value. For example, a condition may be satisfied if the measured value equals one or more indicated values. A triggering condition may include a value range. For example, a condition may be satisfied if the measured value falls within a range. For example, a condition may be satisfied (e.g., alternatively) if the measured value falls outside an indicated range.

[0108] WTRUs can be configured with altitude-based conditions, which can be used to determine parameters, behaviors, etc. Altitude-based conditions can be configured by the network (e.g., in RRC) or can be predefined. Altitude-based conditions can be configured by the network. They can then be enabled / disabled via NW signaling (e.g., MAC CE, DCI, System Information Block (SIB), RRC, etc.). Altitude-based conditions can be enabled / disabled by another condition (e.g., speed-based conditions, waypoint-based conditions, etc.).

[0109] (For example, a height-based condition associated with a threshold) could be in the form that the WTRU reaches at least or at most a certain height. For example, a height-based condition could indicate one or more of the following: the WTRU's height may be higher than a configured threshold; the WTRU's height may be lower than a configured threshold; and / or the WTRU's height may be between (for example, two configured) thresholds.

[0110] Height-based conditions can take the form of changes in WTRU height. For example, height-based conditions can indicate one or more of the following: the height of the WTRU (e.g., within a configured time period / duration) has changed by an amount greater than a threshold; the height of the WTRU (e.g., within a configured time period / duration) has increased by an amount greater than a threshold; the height of the WTRU (e.g., within a configured time period / duration) has decreased by an amount greater than a threshold; a change in the WTRU height has (e.g., within a configured time period / duration) increased by an amount greater than a threshold; and / or a change in the WTRU height has (e.g., within a configured time period / duration) decreased by an amount greater than a threshold.

[0111] Height-based conditions can take the form of time spent by a WTRU at a certain height. For example, height-based conditions can indicate one or more of the following: the height of the WTRU remains the same value at least during the configured time period; the height of the WTRU remains within the configured range at least during the configured time period; the height change of the WTRU is less than the configured amount during the configured time period; and / or the WTRU has spent the maximum amount of time at a certain height (e.g., within the configured time period).

[0112] The WTRU can be configured with waypoint-based conditions (e.g., associated with thresholds), which can be used to determine parameters, behaviors, etc. Waypoint-based conditions can be configured by the network (e.g., in RRC) or can be predefined. Waypoint-based conditions can be configured by the network. Waypoint-based conditions can be enabled / disabled, for example, via NW signaling (e.g., MAC CE, Downlink Control Information (DCI), System Information Broadcast (SIB), Radio Resource Control (RRC) signaling, etc.). Waypoint-based conditions can be enabled / disabled by another condition (e.g., speed-based conditions, altitude-based conditions, etc.).

[0113] Waypoint-based conditions can take the form of the WTRU arriving at a waypoint (e.g., given coordinates) and / or approaching a waypoint previously reported in the WTRU's flight path. This condition can be configured for one or more specific waypoints, or it can be a general condition for several waypoints. For example, a waypoint-based condition can indicate one or more of the following: the WTRU is located at a specific waypoint; and / or the WTRU is within a specific configured distance from the waypoint.

[0114] (For example, a waypoint-based condition associated with a threshold can be in the form of time to reach a waypoint or time spent at a waypoint.) For example, a waypoint-based condition can indicate one or more of the following: the WTRU can be within a configured distance to a waypoint for less than a configured threshold time; the WTRU can spend at least a configured time period within a configured distance to a particular waypoint; the WTRU can be outside the configured distance to a waypoint for more than a configured threshold time; and / or the WTRU can spend less than a configured time period within a configured distance to a particular waypoint.

[0115] Waypoint-based conditions can take the form of reported waypoint changes. For example, waypoint-based conditions can indicate one or more of the following: the waypoint has changed at least the configured distance; the timestamp associated with the waypoint has changed at least the configured time; and / or the WTRU skips a waypoint (e.g., arriving at a second waypoint expected to be reached after the first waypoint before arriving at the first waypoint, etc.).

[0116] WTRUs can be configured with speed-based conditions, which can be used to determine parameters, behaviors, etc. Speed-based conditions can be configured by the network (e.g., in RRC) or can be predefined. Speed-based conditions can be configured by the network. Speed-based conditions can be enabled / disabled via NW signaling (e.g., MAC CE, DCI, SIB, RRC signaling, etc.). Speed-based conditions can be enabled / disabled by another condition (e.g., altitude-based conditions, waypoint-based conditions, etc.).

[0117] Speed-based conditions can be in the form of the WTRU reaching at least or at most a certain speed. For example, speed-based conditions can indicate one or more of the following: the WTRU's speed is higher than a configured threshold; the WTRU's speed is lower than a configured threshold; and / or the WTRU's speed is between two configured thresholds.

[0118] Speed-based conditions can take the form of changes in the speed of the WTRU (e.g., acceleration / deceleration). For example, speed-based conditions can indicate one or more of the following: the speed of the WTRU (e.g., over a period of time) changes by an amount greater than a threshold; the speed of the WTRU (e.g., over a period of time) increases by an amount greater than a threshold; and / or the speed of the WTRU (e.g., over a period of time) decreases by an amount greater than a threshold.

[0119] Speed-based conditions can take the form of time spent by the WTRU at a certain speed. For example, speed-based conditions can indicate one or more of the following: the WTRU's speed remains the same value at least during the configured time period; the WTRU's speed remains within the configured range at least during the configured time period; and / or the WTRU's speed variation is greater than / less than the configured amount during the configured time period.

[0120] A list of candidate TAs can be provided during candidate configuration. One or more candidate TA values ​​can be provided to the WTRU, associated with, for example, different points along the UAV flight path. The WTRU can determine, for example, based on one or more conditions, whether one or more of the pre-configured candidate TA values ​​are suitable for use during LTM execution. The WTRU can use this determination for subsequent RACH procedures on the target cell. In one example, the WTRU can execute... Figure 6 One or more of the steps shown in the example.

[0121] Figure 6 An example of providing candidate TA values ​​is shown. TA values ​​can be provided during LTM candidate configuration. For example... Figure 6 As shown, a device (e.g., a WTRU) may (e.g., be configured to) perform one or more of the following actions. For example, the WTRU may send an "RRC Complete" message, which may include, for example, an indication that flight path information is available. The gNB (e.g., a network node) may transmit (e.g., and the WTRU may receive) a UE information request, which may include, for example, a configuration of flight path reporting and / or a flight path information request. The WTRU may transmit a UE information response message, for example, including initial flight path information, which may include waypoints and / or timestamp information (e.g., if configured and available at the WTRU).

[0122] The WTRU can send measurement report messages to the gNB. The gNB may decide to use LTM. The gNB may initiate LTM candidate preparation. The gNB can transmit (e.g., and the WTRU can receive) configuration information. Configuration information can be received via radio resource control messages (e.g., “RRC reconfiguration” messages), which may include, for example, the configuration of candidate target cells (e.g., one or more (e.g., many) LTM candidate target cells). The gNB can provide (e.g., and the WTRU can receive) a list of possible timing advance (TA) values ​​(e.g., a list of possible TA values, which may include, for example, a first TA value, may be included in the TA information). The first TA value may be associated with a candidate target cell and a waypoint. TA information may be associated with one or more future waypoints. TA information may include (e.g., TA information may indicate) the conditions used (e.g., one or more TA selection conditions) (e.g., a distance threshold from a waypoint). The WTRU can store the configuration and timing advance values ​​of one or more LTM candidate target cells. The WTRU can transmit an “RRC reconfiguration complete” message to the gNB. For example, before receiving an LTM cell switching command, the WTRU can perform downlink (DL) synchronization with one or more candidate target cells. The WTRU can perform L1 measurements on the configured one or more LTM candidate target cells.

[0123] The WTRU can transmit lower-layer measurement reports to the gNB. The gNB can decide to perform LTM cell switching to the target cell. For example, by including a candidate configuration index of the target cell, the gNB can transmit (e.g., and the WTRU can receive) an indication (e.g., a Media Access Control (MAC) element (CE)) to trigger LTM cell switching (e.g., the indication could be to use the candidate target cell as the handover target cell). The WTRU can switch to the LTM candidate target cell configuration. The WTRU can evaluate its current location. The WTRU can select the nearest waypoint. The WTRU can determine whether a candidate TA (e.g., a first TA) is applicable (e.g., if the current location is within X meters (m) of the waypoint, for example, if the TA selection criteria associated with the first TA value for handover target cell are met based on the distance between the WTRU and the waypoint being less than a threshold).

[0124] The WTRU can determine whether it can perform a RACH handover (e.g., 4-step RACH, 2-step RACH) or no-RACH synchronization to the target cell based on whether TA selection conditions associated with a first TA value used for handover to the target cell are met, such as whether a candidate TA is applicable. The WTRU can indicate the (e.g., successful) completion of LTM cell switching to the target cell (e.g., the WTRU can perform the handover to the target cell based on a determination of whether a no-RACH handover or a RACH handover to the target cell is used).

[0125] Figure 7 An example is shown that uses conditional LTM triggering to determine whether to perform a RACH switch or not. For example... Figure 7 As shown, at point 1, the WTRU can receive an LTM candidate configuration, which may include a pre-configured RRC cell configuration. The RRC cell configuration can be applied upon receiving an L1 / L2 indication that triggers a handover (e.g., LTM trigger).

[0126] At point 2, the WTRU may receive a list of TA values, an indication that associates one or more TA values ​​with one or more LTM candidate configurations, and / or TA selection conditions. The configuration at point 2 may be received together with the LTM candidate configuration at point 1, or in a separate message (e.g., in an RRC message or in a MAC CE).

[0127] At point 3, the WTRU can receive an indication that one or more of the LTM candidate configurations are identified as (e.g., in MAC CE) the target cell for handover.

[0128] At point 4, the WTRU can evaluate one or more TA value selection criteria for the indicated cell.

[0129] At point 5, for example, if the selection criteria are met (e.g., if the selection criteria associated with the first TA value used for handover to the target cell are met), the WTRU can perform (e.g., use) a RACH-free handover (e.g., to the target cell) using the selected TA value.

[0130] At point 6, for example, if it is determined that no TA value satisfies the selection criteria (e.g., if the selection criteria associated with the first TA value used for handover to the target cell are not met), the WTRU may perform (e.g., using) a RACH procedure (e.g., RACH handover) to the indicated target cell (e.g., the handover target cell) (e.g., to obtain a TA value from that cell). RACH handover may include using a second TA value obtained during RACH handover.

[0131] Content and signaling can be provided for the candidate TA value list. WTRU can receive the candidate TA value list in the RRC configuration (e.g., as shown in the image). Figure 7 (As shown at point 1). Candidate TA values ​​can be received as part of one or more LTM candidate configurations (e.g., candidate cells). (e.g., each) LTM candidate can be associated with one or more potential TA values ​​(e.g., as shown in point 1). Figure 7 (As shown in point 2).

[0132] A MAC CE (e.g., a MAC CE that triggers LTM early synchronization, triggers CSI-RS measurements, and / or triggers LTM execution) can be used to provide multiple potential TA values. For example, a MAC CE that triggers early synchronization for one or more cells can provide multiple TA values ​​for those cells, or a MAC CE that triggers LTM execution can provide multiple TA values ​​for the indicated target LTM configuration. A MAC CE can provide an index or identifier corresponding to the TA values ​​provided in the RRC configuration. A MAC CE can include the TA values ​​to be used (e.g., explicit).

[0133] One or more candidate TA values ​​for a given LTM candidate cell (e.g., any) can be associated with one or more conditions. For example, a TA value can be associated with one or more of the following: waypoint or location, altitude, and / or one or more cells.

[0134] TA values ​​can be associated with waypoints or locations. A WTRU can apply one of several indicated TA values ​​based on which waypoint or location is closest, or which location or waypoint is the next to be visited. A WTRU may not necessarily need to report its location or waypoint, but can select a TA value, for example, based on its current location (e.g., automatically). For example, the current location can be determined using GPS positioning and / or based on elapsed time compared to a predefined flight path.

[0135] TA values ​​can be associated with height. Multiple TA values ​​can correspond to height thresholds. For example, if the WTRU determines that a first TA value is below a height threshold, the first TA value can be selected, and if the WTRU determines that it is above a height threshold, a second TA value can be selected. For example, multiple height thresholds can be provided and associated with multiple TA values, such that if the height is above an associated threshold, a specific TA value can be selected.

[0136] A TA value can be associated with one or more cells. One or more TA values ​​can correspond to a specific cell. For example, a MAC CE instructing the performance of LTM on a specific cell can be received. The WTRU can (e.g., in response to this instruction) select a TA value corresponding to a specific cell. One or more other conditions may apply, such as altitude, location / waypoint, etc.

[0137] The WTRU can be configured to associate one or more TA values ​​with one or more of the following example conditions (e.g., any one of them): validity period; geographic area; last waypoint reached by the WTRU; time interval; interval of travel distance from the reference point; altitude threshold; speed threshold; and / or measurement threshold.

[0138] WTRU can be configured to associate one or more TA values ​​with conditions including an expiration date. For example, early synchronization with the cell can be performed again after the expiration date has passed.

[0139] A WTRU can be configured to associate one or more TA values ​​with conditions that include a geographic region. For example, (only) if the WTRU is within that geographic region, early synchronization with the cell can be performed.

[0140] A WTRU can be configured to associate one or more TA values ​​with conditions including the last waypoint reached by the WTRU. For example, early synchronization with the cell can be performed (only if) the last waypoint of the flight path is a specific waypoint.

[0141] A WTRU can be configured to associate one or more TA values ​​with a condition including a time interval, which can be defined by a start time and an end time. For example, early synchronization with the cell can be performed (e.g., only if the current time is within that time interval).

[0142] The WTRU can be configured to associate one or more TA values ​​with an interval that includes the distance traveled from a reference point (e.g., a waypoint). For example, early synchronization with the cell can be performed (e.g., only if the distance traveled from the reference point is within that interval).

[0143] The WTRU can be configured to associate one or more TA values ​​with conditions including a height threshold. For example, early synchronization with the cell can be performed (only if the WTRU height is above or below the height threshold).

[0144] WTRU can be configured to associate one or more TA values ​​with conditions including a speed threshold. For example, early synchronization with the cell can be performed (only if the WTRU speed is below a threshold).

[0145] WTRU can be configured to associate one or more TA values ​​with conditions including measurement thresholds (e.g., RSRP, RSRQ, etc.). For example, early synchronization with the cell can be performed (e.g., only if the WTRU measurement is above the threshold).

[0146] Candidate TA values ​​can be evaluated to determine their suitability for RACH. For example, during LTM execution (e.g., upon receiving a cell switching command), upon triggering LTM early synchronization (e.g., upon receiving an early synchronization command), and / or upon triggering L1 reporting (e.g., upon receiving a command to begin execution and reporting CSI-RS measurements), the WTRU can evaluate a list of candidate TA values ​​to determine if a candidate TA value is suitable for a given cell. For example, if the conditions for using any of the provided TA values ​​are not met, the WTRU can determine that there is no valid TA for that cell at the current time.

[0147] WTRU can use one or more of the following criteria to determine whether a TA value is appropriate (e.g., TA selection criteria): when the altitude condition is met; when the distance condition is met; when the speed condition is met; when the measurement condition is met; and / or when a combination of events is met.

[0148] (For example,) the WTRU may determine to use the TA value only if the altitude condition is met. In some examples, the WTRU may determine whether the TA value is appropriate if the altitude is below or above a configured threshold. For example, if the WTRU determines that the TA value is appropriate for use, the WTRU may use the TA value to access the indicated cell.

[0149] (For example,) the WTRU may determine to use a TA value only if a distance condition is met. In some examples, the WTRU may compare its current location (e.g., the WTRU's position) with a waypoint. For example, one or more TA values ​​may be associated with a waypoint. (For example,) the WTRU may use a TA value only if its current position is within the configured distance to the waypoint. If the current WTRU position is not within the configured distance to the waypoint (e.g., the TA value is determined to be invalid), the WTRU may not use a TA value.

[0150] (For example, only if) a speed condition is met, the WTRU may determine whether to use a TA value. The WTRU may (for example, alternatively or additionally) consider its current speed (e.g., the WTRU's current speed) or mobility status to determine whether a TA value is valid. For example, (for example, only if) some or all of the pre-configured TA values ​​may be valid based on the WTRU being above or below a certain speed threshold.

[0151] (For example, only if) the measurement conditions are met, the WTRU may determine to use the TA value. When determining whether the TA value is valid, the WTRU may (for example, additionally or alternatively) consider the current measurement conditions. For example, (for example, only if) the measured cell quality value (e.g., RSRP, RSRQ) is higher than a configured threshold, the TA value may be considered valid.

[0152] (For example,) the WTRU may determine to use a TA value only if a combination of events is met. The WTRU can be configured to determine the validity of a TA value based on a combination of events (e.g., any combination of events described herein). For example, the WTRU may determine to use a (pre-)configured TA value based on assessments determining whether the WTRU is above a configured altitude threshold, within a configured distance to a waypoint, below a certain speed, and whether the measured cell quality is above a configured value. Multiple TA values ​​can be provided to correspond to different combinations of conditions. The WTRU may select (e.g., one) TA value based on (e.g., all) the configured conditions.

[0153] The RACH type can be determined based on the evaluation of candidate TA values. WTRU can determine whether a candidate TA value can be used to perform RACH via one or more alternative methods based on the evaluation. WTRU can choose from one or more of the following RACH types based on the evaluation: 4-step RACH; 2-step RACH; and / or no RACH.

[0154] WTRU can use one or more of the following methods to determine which RACH type to use. For example, WTRU can have multiple evaluation criteria configured for each type of RACH (e.g., no RACH with strict timing requirements, 2-step RACH with less stringent requirements, and / or 4-step RACH if no suitable candidate is found). For example, WTRU can meet multiple requirements (e.g., distance and measurement) before triggering no RACH.

[0155] In some examples, if the WTRU determines that none of the pre-configured TA values ​​are suitable, the WTRU may trigger a random access procedure. In some examples, if the WTRU determines that one of the pre-configured TA values ​​is suitable, the WTRU may perform a RACH-free handover. Determination and / or execution can occur during the early synchronization phase of the LTM procedure. For example, the WTRU may determine whether to perform RACH or use the pre-configured TA values ​​based on the triggered early synchronization. For example, based on the target candidate LTM cell indicated in the cell switching command, the WTRU may (e.g., alternatively or additionally) perform this during the execution phase. The WTRU may (e.g., at this time) determine whether the pre-configured TA values ​​are suitable, for example, to determine whether to perform RACH, and (e.g., if so, which type of RACH to perform).

[0156] TA can be provided during LTM execution. The WTRU can be configured to report location information, for example, using L1 measurement reports. This information can be used to determine the timing advance value applied by the WTRU during target cell synchronization. In one example, the WTRU can execute... Figure 8 One or more of the following are shown.

[0157] Figure 8 An example of providing candidate TA values ​​during LTM execution is shown.

[0158] like Figure 8 As shown, a device (e.g., a Wireless Transmit / Receive Unit (WTRU)) may (e.g., be configured to) perform one or more of the following actions. For example, the WTRU may send an RRC completion message, which may include, for example, an indication that flight path information is available. The gNB (e.g., a network node) may transmit (e.g., and the WTRU may receive) a UE information request, which may include, for example, a configuration for flight path reporting and / or a flight path information request (e.g., the configuration information may indicate a configuration associated with the reported location information or flight path information associated with the WTRU). The WTRU may transmit a UE information response message, which may include, for example, initial flight path information. The flight path information may include waypoints and / or timestamp information associated with waypoints (e.g., if configured and available at the WTRU).

[0159] The WTRU can send measurement report messages to the gNB. The gNB may decide to use LTM. The gNB may initiate LTM candidate preparation. The gNB can transmit (e.g., and the WTRU can receive) configuration information, such as an "RRC reconfiguration" message, which may include, for example, the configuration of one or more candidate target cells (e.g., LTM candidate target cells). The WTRU can store the configuration of one or more LTM candidate target cells. The WTRU can transmit an "RRC reconfiguration complete" message to the gNB. For example, before receiving an LTM cell switching command, the WTRU can perform downlink (DL) synchronization and / or TA acquisition with one or more candidate target cells. The WTRU can perform L1 measurements on the configured one or more LTM candidate target cells. The WTRU can transmit lower-layer measurement reports to the gNB. The WTRU can transmit location or flight path information to the gNB. Measurement reports (e.g., including L1 measurements) may be associated with one or more of the location or flight path information. Location or flight path information may include, for example, the complete WTRU location, incremental coordinates from waypoints, and / or waypoint indices / values, or an indication of whether earlier transmitted flight path information is still valid. Location or flight path information may be associated with a Media Access Control (MAC) element (CE). For Channel State Information (CSI), one or more additional factors may be considered. The gNB may decide to perform LTM cell switching to the target cell.

[0160] For example, by including a candidate configuration index for the target cell and / or by including a timing advance value applied to (e.g., associated with) the candidate target cell, the gNB can transmit (e.g., and the WTRU can receive) a message including an indication to trigger LTM cell switching (e.g., MAC CE) (e.g., an indication that the candidate target cell will be used as the handover target cell). The WTRU can switch to the LTM candidate target cell configuration. For example, based on a TA value (e.g., the TA may have already been provided), the WTRU can perform a handover to the candidate target cell (e.g., a handover without a random access channel (RACH) (HO)). The WTRU can indicate the (e.g., successful) completion of the LTM cell switching (e.g., handover) to the target cell.

[0161] WTRU flight path and / or information location reporting can be triggered. For example, if an L1 measurement report is triggered, the WTRU can be configured to send information related to the flight path / location. This configuration could be one or more of the following: flight path update information that replaces (e.g., complete) previous flight path information sent by the WTRU; incremental flight path update information that can partially update / replace previous flight path information sent by the WTRU (e.g., adding entries, replacing entries, deleting entries, etc.); an indication that previous flight path information is still valid; and / or an indication of the current WTRU location (e.g., an index of a location entry in the previous flight path, an index of a location entry in the previous flight path information, and incremental location information indicating the difference between the current location of the WTRU and the location associated with the index in the previous flight path, etc.).

[0162] In some examples, flight path / location information can be sent separately from L1 measurements (e.g., in a separate MAC CE, or in an RRC message).

[0163] In some examples, such as if the flight path has changed (e.g., by a certain margin of error compared to previous flight path information sent to the network, where the margin of error can be determined by time difference and / or position difference), the WTRU can use an RRC message to send the flight path / position information. Alternatively, if the flight path information has not changed or if the change is minor, the WTRU can use a MAC CE, whereby the change can be encoded / included within the MAC CE without exposing the WTRU's flight path in a plain MAC CE without security protection.

[0164] In some examples, flight path / location information can be included in the L1 measurement report (e.g., in the MAC CE that includes the L1 measurement report, such as in an optional field).

[0165] In some examples, flight path / location information can be sent based on a triggered L1 measurement report.

[0166] In some examples, the WTRU can be configured to send flight path / location information based on one or more triggered measurement events, and / or not send flight path information based on other triggered measurement events (e.g., information included in the measurement event configuration that indicates to the WTRU whether to trigger flight path information at the same time as the measurement report).

[0167] In some examples, the WTRU can be configured to send flight path / location information based on measurement reports triggered by measurements of the candidate target LTM set.

[0168] In some examples, the WTRU can be configured to send flight path / location information (e.g., only) if there is an error magnitude exceeding (e.g., a specific or threshold) in the WTRU's current location or new path (e.g., compared to a previous flight path sent to the network).

[0169] In some examples, the WTRU can be configured to send flight path / location information based on L1 measurement reports that are triggered depending on the current WTRU location (e.g., whether the location is within a specific coordinate system), altitude (e.g., whether the altitude is above a specific range), and / or current time (e.g., the WTRU sends flight path information for a specific duration).

[0170] In some examples, the WTRU can be configured to trigger L1 measurement reports (e.g., reporting the best n cells among LTM candidate cells) based on flight path information reports triggered by another means (e.g., due to configurations related to flight path updates).

[0171] WTRU information location can be signaled. For example, the WTRU can transmit information when triggering WTRU location and / or flight path reporting, when transmitting L1 measurement reports, and / or during the early synchronization phase. For example, the WTRU can transmit one or more of the following: flight path reports (e.g., including one or more waypoints and optional timestamps); waypoints or subsets of waypoints (e.g., the WTRU can send coordinates or indexes to reference previously reported flight path reports); offsets from waypoints (e.g., the WTRU can transmit distance-based offsets from one or more coordinates within a previously reported flight path, which may be reported along with the indexes or coordinates of one or more specific waypoints); GPS coordinates; and / or positioning reference signals.

[0172] In some examples, the information that the WTRU is to report can be pre-configured by the network. For example, the WTRU can receive a set of information (e.g., location and / or flight path) to report when transmitting L1 measurement reports (e.g., via RRC signaling, MAC CE, or within an LTM configuration).

[0173] In some examples, the WTRU can select the signaling method (e.g., the type of signaling) based on what kind of information is to be reported. For example, information affected by security considerations (e.g., location coordinates, GPS, etc.) can be (e.g., only) sent via RRC signaling. Information or some information (e.g., offset from a waypoint or waypoint index) can be (e.g., alternatively) sent via unprotected signaling (such as MAC CE).

[0174] The WTRU can receive TA commands and / or synchronization with the target cell. The WTRU can receive cell switching commands (e.g., in response to one or more of the following: previous transmissions of L1 measurement reports; early synchronization; and / or location / flight path reports), which may include a TA to be applied to an LTM candidate. The cell switching command may (e.g., also) include an indication of whether the WTRU should use a specific RACH procedure (e.g., no RACH, 2-step RACH, or 4-step RACH). For example, based on synchronization with the LTM candidate cell, the WTRU may apply the indicated TA command and RACH type.

[0175] Early synchronization can be triggered, for example, by altitude and / or waypoint. The WTRU can be configured to initiate early synchronization with one or more candidate or target cells based on the fulfillment of conditions. The early synchronization process with a candidate or target cell may include one or more of the following: detecting at least one synchronization signal block (SSB) from a cell (e.g., a candidate target cell), determining (e.g., associated with the candidate target cell) receive timing, and / or determining (e.g., associated with the candidate target cell) transmit timing. For example, the WTRU may perform a first early synchronization for the cell at a first time and a second early synchronization for the cell at a second (e.g., later) time to update receive and / or transmit timing information. In one example, the WTRU may perform... Figure 9 One or more of the following are shown.

[0176] Figure 9 An example of early synchronization with one or more candidate or target cells is shown, based on the fulfillment of conditions triggered by an update indication.

[0177] A device (e.g., a Radio Transmit / Receive Unit (WTRU)) may (e.g., be configured to) perform one or more of the following actions. For example, the WTRU may send an RRC completion message, which may include, for example, an indication that flight path information is available. The gNB may transmit (e.g., and the WTRU may receive) a UE information request, which may include, for example, a configuration of flight path reporting and / or a flight path information request. The WTRU may transmit a UE information response message, which may include, for example, initial flight path information, which may include waypoints and / or timestamp information (e.g., if configured and available at the WTRU).

[0178] The WTRU can send measurement report messages to the gNB. The gNB may decide to use LTM. The gNB may initiate LTM candidate preparation. The gNB can transmit (e.g., and the WTRU can receive) RRC reconfiguration messages, which may include, for example, the configuration of one or more LTM candidate target cells. Configuration information can be provided to the WTRU (e.g., and the WTRU can receive). The configuration information may include conditions / events (e.g., one or more triggering conditions) to trigger early synchronization with candidate target cells, for example, based on waypoint arrival or altitude. The WTRU can store the configuration of one or more LTM candidate target cells. The WTRU can transmit an RRC reconfiguration complete message to the gNB.

[0179] The WTRU can determine that a condition / event (e.g., a triggering condition) is met / triggered (e.g., during altitude increase or decrease, upon arrival at a waypoint). For example, before receiving an LTM cell switching command, the WTRU can (e.g., based on the met / triggered condition / event) perform downlink (DL) synchronization (e.g., early synchronization) and / or timing advance (TA) acquisition with one or more candidate target cells. The WTRU can perform L1 measurements on one or more configured LTM candidate target cells. The WTRU can perform a first early synchronization with the candidate target cells at a first time and a second early synchronization with the candidate target cells at a second time. The WTRU can transmit lower-layer measurement reports to the gNB. The gNB can decide to perform an LTM cell switching to the target cell.

[0180] For example, by including a candidate configuration index for the target cell, the gNB can transmit (and the WTRU can receive) a Media Access Control (MAC) element (CE) that triggers LTM cell switching. The WTRU can switch the configuration to the LTM candidate target cell. The WTRU can transmit synchronization reports. For example, if the TA is unavailable, the WTRU can perform a random access procedure for the target cell. The WTRU can indicate (e.g., successful) completion of the LTM cell switching to the target cell.

[0181] Configuration and signaling can be provided for early synchronization. The WTRU can determine a set of conditions for performing early synchronization with candidate cells. This set of conditions can include one or more of the following, which can be applied to at least one candidate cell: validity period (e.g., early synchronization with the cell can be performed again after the validity period has expired); geographic region (e.g., early synchronization with the cell can be performed if (or only if) the WTRU is in the geographic region); the last waypoint reached by the WTRU (e.g., early synchronization with the cell can be performed if (or only if) the last waypoint of the flight path is a specific waypoint); a time interval, which can be defined by a start time and an end time (e.g., early synchronization can be performed if (or only if) the current time is within the time interval). Early synchronization with the cell; intervals of travel distance from a reference point, such as waypoints (e.g., early synchronization with the cell can be performed if (or only if) the travel distance from the reference point is within this interval); altitude thresholds (e.g., early synchronization with the cell can be performed if (or only if) the WTRU altitude is above or below an altitude threshold); speed thresholds (e.g., early synchronization with the cell can be performed if (or only if) the WTRU speed is below a threshold); and / or measurement thresholds, such as RSRP or RSRQ (e.g., early synchronization with the cell can be performed if (or only if) the WTRU measurement is above a threshold).

[0182] One or more conditions and associated thresholds (e.g., as described herein) may depend on another condition. For example, the effective time may be a function of the WTRU's speed and / or height. The effective time may be a configured or (pre)defined constant divided by the WTRU's speed. In some examples, the effective time may be a first value if the WTRU's height is below a threshold, and a second value if the WTRU's height is above a threshold.

[0183] In some examples, the measurement threshold can be a function of height. For instance, if the height is above a height threshold, WTRU can use a first RSRP threshold, and if the height is below a height threshold, a second RSRP threshold can be used.

[0184] In some examples, (e.g., only) when the WTRU height is above a threshold, time intervals, geographic regions, travel distance intervals, and / or the last waypoint may be applied.

[0185] In some examples, the cell set and applicable conditions may depend on the last waypoint reached by the WTRU (e.g., or may be updated at the last waypoint reached by the WTRU).

[0186] The WTRU can receive one or more conditions (e.g., and associated parameters) for one or more candidate cells via signaling (such as RRC or MAC CE). For example, the configuration can be included within an RRC reconfiguration message or a flight path configuration. The signaling can include, for example, at least one set of cells, along with associated conditions (e.g., trigger conditions) and thresholds. Conditions (e.g., and associated cell sets) can be identified by condition identifiers. Indications for the parameter set can be associated with trigger conditions.

[0187] The WTRU can transmit signaling for reporting based on one or more conditions that occur. For example, the WTRU can transmit a MAC CE upon arrival at a waypoint. The WTRU can (e.g., subsequently) receive RRC or MACCE signaling to update the configuration for early synchronization.

[0188] Triggering can occur within early synchronization. For example, the WTRU may perform early synchronization (and perform one or more subsequent actions) on a cell if at least one of the following conditions (e.g., or a combination thereof) occurs: the WTRU had not previously detected the cell; the difference between the current time and the last time the WTRU performed early synchronization on the cell becomes greater than the applicable validity period of the cell; the cell is included in a set of cells configured for early synchronization; the WTRU is located and / or at an altitude in the geographic area where the WTRU intends to perform early synchronization on the cell; and / or the WTRU receives (e.g., explicitly) signaling requesting early synchronization on the indicated cell.

[0189] The WTRU may (e.g., subsequently) transmit a synchronization report. For example, after early synchronization has been performed, the WTRU may transmit signaling (e.g., MAC CE). The signaling may include at least one of the following: the cell identifier; at least one detected SSB index, such as N strongest detected SSB indices and / or a measurement result with a threshold; at least one measurement result applicable to the SSB index and the cell; the frequency of cell detection (e.g., or the identity of the corresponding measurement object); the time of early synchronization (e.g., this time may be represented as the elapsed time during the initial transmission of the PUSCH including MAC CE); and / or an indication of the conditions that trigger early synchronization to the cell (e.g., this condition may be identified by a condition identifier).

[0190] The WTRU can transmit information about at least one cell for which early synchronization has been performed. For at least one cell, the WTRU can (e.g., also) indicate the identifier of a cell whose synchronization was unsuccessful, not performed, or performed before the current time minus the effective time. The at least one cell may include cells that meet one or more conditions for early synchronization (e.g., as described herein).

[0191] For example, the WTRU may transmit information based on at least one of the following: the WTRU successfully completes early synchronization of a cell; the WTRU (e.g., from the DCI or MAC CE) receives signaling requesting early synchronization of at least one cell; the WTRU (e.g., from the DCI or MAC CE) receives signaling requesting early synchronization status of at least one cell; and / or at least one condition is met (e.g., as described herein).

[0192] The WTRU may not have a line-of-sight (LOS) with gNB or TRP. This could occur, for example, in a dense urban environment or in an area surrounded by other large obstacles such as mountains. The timing advance values ​​provided by the WTRU (e.g., based on the WTRU-reported location or pre-supplied based on the WTRU flight path) may be inaccurate. For example, the optimal beam may be a reflection and not calculated based on the LOS.

[0193] The WTRU and / or network can (e.g., be able to / be configured to) detect whether, for example, a TRP or gNB has a line of sight with the WTRU. Detection can be based on one or more of the following: timing advance with a previous TRP; location / connectivity information with other WTRUs located near the WTRU; positioning information, such as reference signals; measurement reports; and / or statistical data collected by the network.

[0194] In some examples, the probability of LOS can be significantly reduced based on altitude. For instance, a WTRU flying high above the Earth can maintain LOS, for example, in a dense urban scene. The WTRU can be configured with an altitude threshold X. For example, if the WTRU's current altitude is above the threshold, the WTRU can assume that it is in a position where line of sight with a candidate is likely.

[0195] In some examples, a WTRU can infer whether it has a line of sight based on the number of TRP / GNBs visible at a given time. For example, a WTRU that detects more than X TRP / GNBs can determine or assume that it is located in a candidate line of sight. In some examples, for instance, if a WTRU is able to observe many (e.g., two or more) TRP / GNBs with similar RSRPs, the WTRU can conclude that it is located in a candidate line of sight.

[0196] For example, a network can determine, based on flight paths, that portions of a flight path (e.g., certain parts) may be outside the line of sight. For example, a network can determine non-LOS (e.g., a WTRU may fly through an area that may suffer from multipath / non-LOS) based on network coverage statistics. The network can indicate to the WTRU one or more (e.g., specific) portions of a flight path in a non-LOS area where the WTRU may be able to operate.

[0197] For example, if the WTRU detects that it (e.g., the WTRU) is no longer in the line of sight of an LTM candidate, the WTRU may (e.g., based on the satisfaction of one or more conditions (e.g., as described herein)) send an indication to the network. The WTRU may disable the ability to use one or more candidate TA values ​​for LTM execution (e.g., as described herein), and / or may trust the TA values ​​provided by the network during LTM execution (e.g., as described herein). For example, if connected to an LTM candidate cell, the WTRU may disable the ability to perform no-RACH or 2-step RACH on the candidate cell (e.g., and may instead revert to 4-step RACH). For example, the WTRU may perform one or more actions (e.g., as described herein) based on an indication from the network that the WTRU is no longer in the LOS, or when in an area where the network indicates it is no longer in the LOS.

[0198] A confirmation can indicate that timing advance is not required. For more than one LTM candidate cell, the timing advance applied by the WTRU can be the same (e.g., in the case of TRP co-location). The network can (e.g., within the candidate TA list, as described herein) indicate that the same TA can be applied to many (e.g., two or more) LTM candidates. In some examples (e.g., when WTRU location is transmitted during LTM execution, as described herein), the network can indicate that the current timing advance is valid for the candidate. The WTRU can (e.g., based on this indication) perform cell synchronization / RACH on the LTM candidate using the same timing advance as the currently serving cell.

[0199] Although the above features and elements are described in specific 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 other features and elements.

[0200] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and can be applied to other wireless systems. For example, although the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems.

[0201] The above processes can be implemented in computer programs, software, and / or firmware, which are incorporated in 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 CD-ROMs and / or DVDs. The processor associated with the software can be used to implement a radio frequency transceiver for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information indicating candidate target cells from network nodes; Receive timing advance (TA) information from a network node, wherein the TA information indicates a first TA value associated with a candidate target cell, and wherein the TA information indicates TA selection conditions associated with the first TA value; Receive instructions from network nodes to use candidate target cells as handover target cells; Determine whether the TA selection criteria associated with the first TA value used for handover to the target cell are met; Based on whether the TA selection condition associated with the first TA value used for handover to the target cell is met, it is determined whether to use the random access channel (RACH) without handover to the target cell or the RACH handover to the target cell. and Based on the determination of whether to use a RACH-free handover to the target cell or a RACH handover to the target cell, a handover to the target cell is performed.

2. The WTRU of claim 1, wherein the processor is configured to use RACH-free handover to the target cell if a TA selection condition associated with a first TA value for handover of the target cell is satisfied.

3. The WTRU of claim 1, wherein the processor is configured to use RACH handover to the target cell if a TA selection condition associated with a first TA value for handover of the target cell is not satisfied, and wherein the RACH handover includes using a second TA value obtained during the RACH handover.

4. The WTRU of claim 1, wherein the TA selection condition is associated with a distance threshold, and wherein the distance threshold is associated with the distance between the WTRU and the waypoint, and wherein the TA selection condition is satisfied based on the distance between the WTRU and the waypoint being less than the threshold.

5. The WTRU of claim 1, wherein the first TA value is associated with the candidate target cell and waypoint.

6. The WTRU of claim 1, wherein the candidate target cell includes L1 / L2 triggered mobility (LTM) candidate target cells.

7. The WTRU of claim 1, wherein the configuration information is received via Radio Resource Control (RRC) messages.

8. A method for a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information indicating candidate target cells from network nodes; Receive timing advance (TA) information from the network node, wherein the TA information indicates a first TA value associated with the candidate target cell, and wherein the TA information indicates TA selection conditions; Receive instructions from network nodes to use candidate target cells as handover target cells; Determine whether the TA selection criteria associated with the first TA value used for handover to the target cell are met; Based on whether the TA selection condition associated with the first TA value used for handover to the target cell is met, it is determined whether to use the random access channel (RACH) without handover to the target cell or the RACH handover to the target cell. and Based on the determination of whether to use a RACH-free handover to the target cell or a RACH handover to the target cell, a handover to the target cell is performed.

9. The method of claim 8, wherein the method comprises: If the TA selection conditions associated with the first TA value used for handover to the target cell are met, then RACH-free handover to the target cell is used.

10. The method of claim 8, wherein the method comprises: If the TA selection criteria associated with the first TA value used for handover to the target cell are not met, then RACH handover to the target cell is used, wherein the RACH handover includes the use of a second TA value obtained during the RACH handover.

11. The method of claim 8, wherein the TA selection condition is associated with a distance threshold, wherein the distance threshold is associated with the distance between the WTRU and the waypoint, and wherein the TA selection condition is satisfied based on the distance between the WTRU and the waypoint being less than the threshold.

12. The method of claim 8, wherein the first TA value is associated with the candidate target cell and waypoint.

13. The method of claim 8, wherein the candidate target cell includes L1 / L2 triggered mobility (LTM) candidate target cells.

14. The method of claim 8, wherein the configuration information is received via a Radio Resource Control (RRC) message.

Images