WTRU LTM CANDIDATE SET UPDATE BASED UNCREWED AERIAL VEHICLE CONDITION
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63/445,430, filed February 14, 2023, the contents of which are hereby incorporated by reference herein.
BACKGROUND
[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).
SUMMARY
[0003] A layer one/two (L1/2) triggered mobility (LTM) candidate set may be selected for use in an LTM procedure based on uncrewed aerial vehicle (UAV) factors such as height, speed, or waypoint condition, for example.
[0004] For example, a device (e.g., a wireless transmit/receive unit (WTRU), for example, a UAV) may include a processor that is configured to receive configuration information that indicates a first LTM procedure, a first geographic dependent condition associated with the first LTM procedure, a second LTM procedure, and a second geographic dependent condition associated with the second LTM procedure, wherein the first LTM procedure is associated with a first cell and the second LTM procedure is associated with a second cell. The device may determine that the first geographic dependent condition is satisfied. Based on the first geographic dependent condition being satisfied, the device may perform the first LTM procedure. Performing the first LTM procedure may include using or measuring the first cell. The device may determine that the second geographic dependent condition is satisfied. Based on the second geographic dependent condition being satisfied, the device may perform the second LTM procedure. Performing the second LTM procedure may include using or measuring the second cell.
[0005] The first geographic dependent condition may be a first height condition associated with an altitude at which the WTRU is located, a first speed condition associated with a speed at which the WTRU is moving, or a first waypoint condition associated with a first waypoint in a flight path location of the WTRU. The second geographic dependent condition may be a second height condition associated with an the altitude at which the WTRU is located, a second speed condition associated with the speed at which the WTRU is moving, or a second waypoint condition associated with a second waypoint in the flight path location of the WTRU.
[0006] Determining that the first geographic dependent condition is satisfied may include determining that an altitude of the WTRU is below an altitude threshold. Determining that the second geographic dependent condition is satisfied may include determining that the altitude of the WTRU is above the altitude threshold.
[0007] Determining that the first geographic dependent condition is satisfied may involve determining that a speed of the WTRU is below a speed threshold. Determining that the second geographic dependent condition is satisfied may include determining that the speed of the WTRU is above the speed threshold.
[0008] Determining that the first geographic dependent condition is satisfied may include determining that the WTRU has reached a first waypoint. Determining that the second geographic dependent condition is satisfied may include determining that the WTRU has reached a second waypoint.
[0009] The configuration information may indicate a first set of candidate cells and a second set of candidate cells. The device may select the first cell from the first set of candidate cells. The device may select the second cell from the second set of candidate cells.
[0010] Performing the second LTM procedure may involve ceasing performing the first LTM procedure; and sending, to a network entity, an indication that the second cell is in use.
[0011] Performing the first LTM procedure may include sending, to a network entity, a first indication that information associated with the first cell (e.g., indicates that the first cell is in use). Performing the second LTM procedure may include sending, to the network entity, a second indication that indicates information associated with the second cell (e.g., that indicates) the second cell is in use). At least one of the first indication or the second indication may be sent via a medium access control (MAC) control element (MAC CE), a radio resource control (RRC) message, uplink control information (UCI), or a channel state information (CSI) report.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;
[0013] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment; [0014] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment;
[0015] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;
[0016] FIG. 2 illustrates an example of a measurement model.
[0017] FIG. 3 illustrates an example of LTM.
[0018] FIG. 4 illustrates an example of an LTM procedure.
[0019] FIG. 5 illustrates an example of signaling flow for a flight path report in LTE UAV.
[0020] FIG. 6 illustrates an example of an initial flight path reporting procedure.
[0021] FIG. 7 illustrates an example use-case utilizing known waypoints associated with sets of LTM candidate configurations (e.g., or cells).
[0022] FIG. 8 illustrates an example procedure utilizing waypoints or height or speed thresholds associated with different sets of LTM candidate configurations (e.g., or cells).
[0023] FIG. 9 illustrates an example use-case utilizing waypoints, height, and/or speed thresholds associated with different types of mobility.
[0024] FIG. 10 illustrates an example procedure utilizing waypoints, height, and/or speed thresholds associated with different types of mobility.
[0025] FIG. 11 illustrates an example procedure utilizing network (NW) controlled fast candidate set update.
[0026] FIG. 12 illustrates an example of signaling to perform the procedure utilizing NW controlled fast candidate set update.
DETAILED DESCRIPTION
[0027] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
[0028] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a ON 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “ST A”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.
[0029] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
[0030] The base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.
[0031] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
[0032] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).
[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).
[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).
[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).
[0036] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0037] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106/115.
[0038] The RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
[0039] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.
[0040] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0041] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
[0042] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0043] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [0044] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
[0045] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.
[0046] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0047] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0048] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment. [0049] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
[0050] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the 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 either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
[0051] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.
[0052] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
[0053] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface. [0054] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
[0055] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.
[0056] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
[0057] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0058] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
[0059] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
[0060] In representative embodiments, the other network 112 may be a WLAN.
[0061] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (I BSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.
[0062] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.
[0063] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
[0064] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC). [0065] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and
802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
[0066] WLAN systems, which may support multiple channels, and channel bandwidths, such as
802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.
[0067] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for
802.11 ah is 6 MHz to 26 MHz depending on the country code.
[0068] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.
[0069] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).
[0070] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).
[0071] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.
[0072] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.
[0073] The CN 115 shown in FIG. 1 D 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 are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
[0074] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
[0075] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.
[0076] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like. [0077] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
[0078] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
[0079] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.
[0080] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.
[0081] In a connected state (e.g., RRC_CONNECTED), a WTRU may measure one or more beams (e.g., multiple beams) of a cell. The measurement results (e.g., power values) may be averaged to derive the cell quality. The WTRU may (e.g., be configured to) consider a subset of the detected beams. Filtering may take place at multiple (e.g., two) different levels (e.g., at the physical layer to derive beam quality and at RRC level to derive cell quality from multiple beams). Cell quality from beam measurements may be derived (e.g., in the same way) for the serving cell(s) and for the non-serving cell(s). Measurement reports may include the measurement results of the X best beams (e.g., if the WTRU is configured to do so by the gNB).
[0082] FIG. 2 illustrates an example measurement model. Inter-cell L1/L2 triggered mobility (LTM) may be implemented. Inter-cell beam management may be used to manage the beams (e.g., to manage beams in carrier aggregation (CA)). Cell change/add may or may not be supported. L1/L2 based inter-cell mobility may be implemented to reduce mobility latency. Configuration and maintenance may be provided for multiple candidate cells to allow fast application of configurations for candidate cells (e.g., in RAN2, RAN3). Dynamic switching among candidate serving cells (e.g., including SpCell and SCell) may be provided for applicable scenarios based on L1/L2 signaling (e.g., in RAN2, RAN1). L1 enhancements may be provided for inter-cell beam management (e.g., including L1 measurement and reporting), and beam indication (e.g., in RAN1, RAN2). Timing advance management may be provided (e.g., in RAN1 , RAN2). Centralized unit- distributed unit (CU-DU) interface signaling may be provided to support L1/L2 mobility (e.g., in RAN3). L1/L2 based inter-cell mobility may be applicable to one or more of the following scenarios: standalone (e.g., CA and NR-DC case with serving cell change within one cell group (CG)); intra-DU case and intra-CU inter-DU case (e.g., applicable for standalone and CA); intra-frequency and inter-frequency scenarios; frequency range (FR) (e.g., FR1 and FR2); source and target cells (e.g., synchronized or nonsynchronized); and/or inter-CU case.
[0083] L1/L2 based mobility and inter-cell beam management may address intra-DU and intra-frequency scenarios. A serving cell may remain unchanged (e.g., if there is no possibility to change the serving cell using L1/L2 based mobility). In FR2 deployments, CA may be used to exploit the available bandwidth (e.g., to aggregate multiple control channels (CCs) in a (on)e band). The CCs may be transmitted with the same analog beam pair (e.g., gNB beam and WTRU beam). The WTRU may be configured with transmission configuration index (TCI) states (e.g., 64 TCI states) for reception of physical downlink control channel (PDCCH) and physical downlink shared channel (PDSCH). A (e.g., each) TCI state may include a reference signal (RS) or synchronization signal block (SSB) that the WTRU refers to for setting its beam. An SSB may be associated with a non-serving physical cell identity (PCI). Medium access control (MAC) signaling (e.g., a “TCI state indication for WTRU-specific PDCCH MAC CE”) may activate the TCI state for a control resource set (CORESET) and/or PDCCH. Reception of PDCCH from a non-serving cell may be supported by a MAC CE indicating a TCI state associated with a non-serving PCI. MAC signaling (e.g., “TCI States Activation/Deactivation for WTRU-specific PDSCH”) may activate a subset of (e.g., up to 8) TCI states for PDSCH reception. Downlink control information (DCI) may indicate which of the (e.g., 8) TCI states. A “unified TCI state” may be supported with a different updating mechanism (e.g., DCI-based), for example, without multiple transmission/reception points (multi-TRP). Unified TCI states with multi-TRP may be supported.
[0084] LTM may improve handover latency. A WTRU may (e.g., first) send a measurement report using RRC signaling for an (e.g., a conventional or conditional) L3 handover. The network may provide a further measurement configuration and/or a conditional handover configuration. The network may (e.g., for conventional handover) provide a configuration for a target cell after the WTRU reports using RRC signaling that the cell meets a configured radio quality criteria. The network may (e.g., for a conditional handover (CHO)) provide (e.g., in advance) a target cell configuration and/or a measurement criteria that determines if the WTRU should trigger the CHO configuration, for example, to reduce the handover failure rate due to the delay in sending a measurement report before receiving an RRC reconfiguration. These conventional and conditional L3 handovers may suffer from a delay due to the sending of measurement reports and receiving of target configurations (e.g., especially in case of the conventional (non-conditional) handover).
[0085] LTM may allow a fast application of configurations for candidate cells (e.g., including dynamically switching between SCells and switching of the PCell, for example, switch the roles between SCell and PCell) without performing RRC signaling. The inter-CU case may involve relocation of the packet data convergence protocol (PDCP) anchor. An RRC based approach may support inter-CU handover.
[0086] Active (e.g., currently active) SCell(s) may be released before the WTRU moves to complete the handover to a target cell in the coverage area of a new site. Active (e.g., currently active) SCell(s) may be added back after successful handover, which may lead to throughput degradation during handover. L1/L2 may enable CA operation to be enabled instantaneously upon serving cell change.
[0087] FIG. 3 shows an example of LTM operation. The candidate cell group may be configured by RRC. A dynamic switch of PCell and SCell may be achieved using L1/2 signaling.
[0088] FIG. 4 illustrates an example of LTM. As shown in FIG. 4, at 1, a WTRU may send a MeasurementReport message to the gNB. The gNB may (e.g., decide to) use LTM and initiate LTM candidate preparation.
[0089] At 2, the gNB may transmit an RRCReconfiguration message to the WTRU. The RRCReconfiguration message may include the configuration of one or multiple LTM candidate target cells. [0090] At 3, the WTRU may store the configuration of LTM candidate target cell(s). The WTRU may transmit an RRCReconfigurationComplete message to the gNB. [0091] At 4, the WTRU may perform DL synchronization and TA acquisition with candidate target cell(s) (e.g., before receiving the LTM cell switch command). DL synchronization for candidate cell(s) before cell switch command may be supported (e.g., at least based on SSB). TA acquisition of candidate cell(s) before LTM cell switch command may be supported (e.g., at least based on PDCCH ordered RACH). The PDCCH order may be triggered by a source cell.
[0092] At 5, the WTRU may perform L1 measurements on the configured LTM candidate target cell(s). The WTRU may transmit lower-layer measurement reports to the gNB. The lower-layer measurement reports may be carried on L1 or MAC.
[0093] At 6, the gNB may decide to execute an LTM cell switch to a target cell. The gNB may transmit a MAC CE triggering LTM cell switch, for example, by including the candidate configuration index of the target cell. The WTRU may switch to the configuration of the LTM candidate target cell.
[0094] At 7, the WTRU may perform a random access procedure towards the target cell (e.g., if TA is not available).
[0095] At 8, the WTRU may indicate successful completion of the LTM cell switch towards the target cell. An uplink signal or message after the WTRU has switched to the target cell may be used to indicate successful completion of the LTM cell switch.
[0096] Uncrewed aerial vehicles (UAV) (e.g., travelling at a height of up to 300m) may be supported (e.g., in LTE). Use cases may include drone operation, personal entertainment for flight experience, and cargo delivery. Applications may support capabilities for remote control and data transmissions (e.g., including UL and DL interference and mobility).
[0097] A measurement report may be based on a configured height threshold. In LTE, aerial WTRUs may support height-triggered measurement reporting based on WTRU-capability. For example, two heightbased events may be defined: Event H1 , an event in which an aerial WTRU height becomes higher than an absolute threshold; and Event H2, an event in which an aerial WTRU height becomes lower than an absolute threshold.
[0098] Height thresholds may be configured in MeasConfig via heig htThresh Ref. Height thresholds may support values ranging from -420m to 8880m (e.g., in increments of 300m). A WTRU may be configured in ReportConfigEUTRA with offsets, such as hi -Thresholdoffset and h2-ThresholdOffset, and/or hysteresis parameters, such as h1-Hysteresis and h2-Hysteresis, which may be applied during event evaluation.
[0099] WTRU height, location, and/or speed may be reported. A WTRU may be configured to include additional information (e.g., the WTRU height, location, and/or horizontal/vertical velocity) within a measurement report. Location reporting in LTE may be supported via the Locationinfo information element (IE), which may be used to transfer location information (e.g., detailed location information) available at the WTRU to correlate measurements and WTRU position information. Available information may include WTRU location information (e.g., via locationCoordinates) and/or WTRU bearing and horizontal speed (e.g., via horizontalVelocity).
[0100] An LTE UAV feature may involve reporting vertical information (e.g., via verticalVelocitylnfo). Vertical Velocityinfo may include the choice between parameters verticalvelocity, which may include WTRU bearing, horizontal/vertical speed, and/or vertical direction, and verticalVelocityAndUncertainty, which may include information within verticalvelocity and/or uncertainty of horizontal and vertical speed.
[0101] Feature(s) associated with flight path reporting are provided herein. Flight path reporting may be supported in LTE for aerial WTRUs based on WTRU capability. Flight path information may include a number of waypoints, which may be 3D locations. A WTRU may indicate if flight path information is available, for example, via RRCConnectionReconfigurationComplete, RRCConnectionReestablishmentComplete, RRCConnectionResumeComplete, and/or RRCConnectionSetupComplete messages. Flight path information may allow the network to know (e.g., immediately after connection) whether flight path information is available, enabling subsequent flight path report configuration and request.
[0102] E-UTRAN may be used to request that a WTRU report flight path information (e.g., via flightPathl nfoReq in the UElnformationRequest message). Upon request to report WTRU flight path information, the WTRU may include flightPathl nfoReport in the UElnformationResponseMessage, for example, including available waypoints (e.g., up to the configured maximum). Flight path information may be useful to the network, for example, for collision avoidance, resource provisioning, and/or WTRU configuration. LTE may support configuration of up to 20 waypoint locations within a flight path report. RAN2 may confirm that a maximum of 20 waypoint locations are sufficient for an NR use case.
[0103] FIG. 5 illustrates an example of signaling flow for a flight path report in LTE UAV.
[0104] A WTRU may be configured to include time stamp information associated with a (e.g., each) waypoint, for example, via includeTimeStamp within FlightPathl nforReportConfig. Time stamps may improve predictability of the WTRU location at a given time, which may aid planning of WTRU configuration and future resource allocation. Time stamp information may not always be known. Timestamp information may be included in a flight path report if such information is available at the WTRU.
[0105] One or more trigger criteria may be fulfilled (e.g., simultaneously) for multiple cells. An aerial WTRU may be configured with a radio resource management (RRM) event (e.g., A3, A4, or A5), which may trigger measurement reporting if per-cell reference signal received power (RSRP) values for a configured number of cells fulfill the configured event. A measurement report may be sent. The list of triggered cells may be updated if/when subsequent cell(s) fulfill the event. Additional measurement reports may not be sent while the list of triggered cells remains larger than the configured number of cells.
[0106] The number of triggered cells for measurement reporting may be provided in ReportConfigEUTRA via numberOfTriggeringCells. The number of triggered cells may range from two (2) up to a maximum of eight (8). The number of triggered cells may be useful, for example, for interference detection and/or to reduce signaling overhead (e.g., by reducing the number of measurement reports).
[0107] NR UAV may support aerial WTRUs (e.g., which may be UAVs). LTE and NR support may be harmonized. NR and LTE may support height-based measurement reporting, flight path reporting, and simultaneous fulfillment of trigger criteria for multiple cells. Location and speed reporting may be supported in NR and LTE UAV.
[0108] NR UAV may support height dependent parameter scaling, user consent for location reporting, flight path update after initial report, and/or consideration of beams and report on leave condition (e.g., in numberoftriggeringcells). Flight path reporting may include location coordinates, timestamp, and/or flight path information. Mobility control may include height based parameter scaling, height based events based on WTRU location information (e.g., H1 (above threshold), H2 (below threshold)). Interference control may include the number of triggered cells (e.g., A3, A4, A5), triggered cells list in MR, new events B1/B2 (e.g., inter-RAT), and/or beam impacts.
[0109] RRC may be enhanced for L1/L2 triggered mobility (LTM) to support a UAV use case. An LTM procedure may support UAV in a similar way as other mobility procedures. LTM procedures may take into account flight path reporting, height, and interference control due to the presence of a higher number of cells and beams when the WTRU is at a higher altitude than other WTRUs on the ground. RRC management of LTM candidate cells and measurement configurations may take into account the aspects that are specific to a UAV.
[0110] Waypoints in the context of UAV may be sets of 3-dimensional coordinates that identify a point in physical space. A waypoint may (e.g., alternatively) be a set of 2-dimensional coordinates that identify a point on the ground, which may be used in conjunction with a height value to determine a 3-dimentional point in physical space. A waypoint may be associated with a timestamp to identify the time at which a WTRU is expected to be at the indicated location.
[0111] A flight path may include one or more waypoints (e.g., and a timestamp), indicating the position (e.g., and the time) at which the WTRU expects to be at a position. A (e.g., each) waypoint may be numbered or indexed, such that each waypoint may be uniquely identified.
[0112] “Perform LTM” may refer to performing any/all of the steps described in FIG. 4, such as early synchronization in DL and/or UL to one or more of the candidate cells, performing L1 measurements and reporting on one or more of the candidate cells, switching (e.g., performing handover) between candidate cells. For example, “perform LTM” may mean that the WTRU moves/switches between multiple candidate cells during the procedure.
[0113] Candidate cell sets may be groups of more than one RRC configuration corresponding to a handover configuration for one or more candidate SpCells (e.g., and SCells). Candidate cell sets may be modelled or received as one or more complete RRC reconfiguration messages, one or more cell group configurations, or one or more cell configurations. A (e.g., each) candidate cell configuration may include a candidate configuration identifier. A (e.g., each) candidate cell group may include a candidate cell group identifier. Switching between different sets of candidate cells may include updating the serving cell indexes or candidate configuration indexes that are used in L1 and MAC signalling to refer to specific indexes, for example, if the grouping is performed at RRC. For example, a MAC CE triggering a reconfiguration may include a candidate configuration index informing the WTRU a cell to which to perform the reconfiguration. [0114] The one or more candidate cell groups may be configured as a single list or group of candidate cell configurations at RRC. The grouping may occur at the early sync or LTM execution phase, for example, rather than the configuration phase. The candidate cell set may be considered as a (e.g., single) group in terms of an RRC configuration list or group. The cells selected for performing early sync, L1 measurements, and/or LTM execution may depend on a further grouping into multiple subsets of the overall candidate cell list. The grouping itself may not be modelled at RRC using candidate configuration identifiers. The grouping may be executed as part of the early sync or the LTM execution procedure.
[0115] An LTM candidate configuration may apply to any type of preconfigured cell information. For example, a WTRU may be configured with one or more conditional reconfigurations, such as CHO, conditional PSCell addition (CPA), or conditional PSCell change (CPC), which may be valid before and/or after a cell change or may be valid in certain cells.
[0116] Examples indicate that UAV support to improve the performance of L3 mobility and measurements may be applied in a similar way to LTM. LTM procedures may be adapted to UAV devices. The use of height, speed, and location information may enhance mobility procedures. A device at a high altitude may experience different challenges than a device at a lower/ground level altitude, such as detecting a higher number of beams or cells and causing a higher interference in the uplink due to the DL measurement values. For example, a cell in relatively close proximity with beams directed towards ground level may be measured at a relatively low quality. A WTRU may transmit with a higher power in the UL, e.g., based on a determination that the perceived low quality is due to a high path loss. The precise location may be predictable for at least some devices (e.g., if the WTRU reports flight path information, then the location at a particular time may be known with high confidence). [0117] An L1 measurement may include a measurement of RSRP, reference signal strength indicator (RSSI), etc., performed by a WTRU of a cell, beam, set of cells, or set of beams. An L1 measurement may be similar to L3 measurements reported in RRM (e.g., with differences in the filtering, reference signals measured, reporting mechanisms, etc.).
[0118] One or more events may trigger reporting or define WTRU behavior, for example, based on a specific waypoint (e.g., coordinates in the path of a UAV). The term waypoint may be used interchangeably with location. Examples may use any mechanism to define the geographical location of a WTRU in a space.
[0119] Measurements may refer to L1 measurements for LTM. In some examples, measurements may (e.g., also) refer to RRM/L3 measurements and/or other measurements (e.g., measurements of speed, location, height, traffic, etc.).
[0120] LTM candidate cell management for UAV may provide benefits. LTM may reduce handover latency and radio link failure rates. The performance of LTM (e.g., when used by a UAV device) may be improved (e.g., under certain conditions). Use of fast mobility, with new conditions such as height, speed, and/or predictable location, may improve the efficiency of signaling (e.g., by reducing the overall amount of information to be configured or reconfigured by RRC). Unnecessary L1 measurement reporting may be reduced, handover failure rates may be improved, and data interruption may be reduced, for example, by adapting LTM procedures to take into account UAV specific information.
[0121] FIG. 6 illustrates an example of an initial flight path reporting procedure. A WTRU may indicate if flight path information is available, for example, via one or more messages, such as RRCConnectionReconfigurationComplete, RRCConnectionReestablishmentComplete, RRCConnectionResumeComplete, and/or RRCConnectionSetupComplete messages.
[0122] E-UTRAN may request a WTRU to report flight path information via flightPathl nfoReq in the UElnformationRequest message. Timestamp information may be requested (e.g., and included) via includeTimeStamp. LTE may support configuration of up to 20 waypoint locations within a flight path report. A WTRU may include flightPathl nfoReport in the UElnformationResponseMessage, for example, including (e.g., all) available waypoints (e.g., up to the configured maximum) and timestamp information (e.g., if configured and available at WTRU).
[0123] A UAV may provide flight path reporting content (e.g., waypoints and optional timestamps) and/or an initial reporting procedure. A UAV may update a previously reported flight path, for example, via an indication in the UEassistanceinformation message. Upon indication, a network (NW) may use a WTRU (e.g., UE) information request/response procedure to retrieve an updated flight path. [0124] Feature(s) associated with flight path reporting are provided herein. Flight path reporting may be associated with an LTM configuration. In some examples, a WTRU may report flight path information to the gNB. The gNB may configure the WTRU with parameters or conditions associated with one or more of the waypoints. A WTRU may report flight path information to the gNB (e.g., GPS co-ordinates and time of future one or more waypoints). A gNB may configure an LTM candidate or parameter sets corresponding to one or more of the waypoints.
[0125] A WTRU may receive one or more of the following types of configurations, which may be associated with one or more of the waypoints (e.g., by associating the configuration with a waypoint index): one or more candidate cell configurations, mobility related parameters, and/or synchronization types.
[0126] A candidate cell configuration or a set of candidate cell configurations may be referred to by an index (e.g., candidate configuration index).
[0127] Mobility related parameters may include, for example, one or more of the following: a radio quality threshold; a time to trigger; a measurement identity (e.g., to identify a measurement event type and/or a set of measurement parameters); a CSI-RS reporting configuration; a CSI-RS resource configuration; one or more TCI states; measurement filter parameters; measurement evaluation type (e.g., L3 or L1 measurement); and/or a reporting type (e.g., RRC, MAC CE, or CSI-RS).
[0128] A synchronization type may include, for example, one or more of the following: whether to perform early synchronization (e.g., before handover trigger) in the DL or UL; what type of random access procedure to perform (e.g., RACH-less, 2-step RA, 4-step RA); and/or a timing advance (TA) value.
[0129] In some examples (e.g., if/when the WTRU reaches a certain waypoint), the parameters or configurations that have been previously configured and associated with the waypoint may be applied, and the parameters or configurations currently in use that are not associated with the new waypoint may be deactivated or released.
[0130] A height based condition may be implemented. A (e.g., each) height threshold may be associated with configurations or parameters in a similar way as described for waypoints (e.g., the configurations and parameters described herein for potential association with waypoints may additionally or alternatively be associated with height thresholds).
[0131] In some examples (e.g., if/when the WTRU goes above or below a certain height threshold), the parameters or configurations that have been previously configured and associated with the threshold may be applied, and the parameters or configurations currently in use that are not associated with the threshold may be deactivated or released. In some examples, one or more (e.g., certain) parameters and/or configurations may apply if/when above the threshold, and other parameters and/or configurations may apply if/when below the threshold. Multiple thresholds may be configured and associated with different parameters and thresholds.
[0132] A WTRU may be configured with a height-based condition used to determine a parameter, behavior, etc. A height-based condition may be configured by the network (e.g., in RRC), or may be predefined. A height-based condition may be configured by the network. A height-based condition may be enabled/disabled, for example, by NW signaling (e.g., MAC CE, DCI, system information block (SIB), RRC, etc.). A height-based condition may be enabled/disabled by another condition (e.g., speed-based condition, waypoint-based condition, etc.).
[0133] A height-based condition may be in the form of the WTRU reaching at least or at most a certain height. For example, a height-based condition may indicate one or more of the following: a WTRU’s height is above a configured threshold; a WTRU’s height is below a configured threshold; and/or a WTRU’s height is between (e.g., two configured) thresholds.
[0134] A height-based condition may be in the form of a change in the WTRU’s height. For example, a height-based condition may indicate one or more of the following: a WTRU’s height changes by an amount greater than a threshold (e.g., within a configured time period/duration); a WTRU’s height increased by an amount greater than a threshold (e.g., within a configured time period/duration); a WTRU’s height decreases by an amount greater than a threshold (e.g., within a configured time period/duration); a change of the WTRU’s height has increased by an amount greater than a threshold (e.g., within a configured time period/duration); and/or a change of the WTRU’s height has decreased by an amount greater than a threshold (e.g., within a configured time period/duration).
[0135] A height-based condition may be in the form of a time the WTRU spends at a certain height. For example, a height-based condition may indicate one or more of the following: a WTRU’s height stays at the same value for at least a configured period of time; a WTRU’s height stays within a configured range at least for a configured period of time; a WTRU’s height changes by less than a configured amount over a configured period of time; and/or a WTRU has spent the most amount of time, within a configured period of time, at a certain height.
[0136] A location-based condition may be implemented. A WTRU may be configured with a waypointbased condition used to determine a parameter, behavior, etc. A waypoint-based condition may be configured by the network (e.g., in RRC), or may be predefined. A waypoint-based condition may be configured by the network. A waypoint-based condition may then be enabled/disabled, for example, by NW signaling (e.g., MAC CE, DCI, SIB, RRC, etc.). A waypoint-based condition may be enabled/disabled by another condition (e.g., speed-based condition, height-based condition, etc.). [0137] A waypoint-based condition may be in the form of a WTRU reaching a waypoint (e.g., a given coordinate) and/or being in proximity of a waypoint that was earlier reported in the WTRU’s flight path. A waypoint-based condition may be configured for one or more (e.g., specific or selected) waypoints or may be generic for any number of waypoints. For example, a waypoint-based condition may indicate one or more of the following: a WTRU is located at a certain waypoint; and/or a WTRU is within a (e.g., certain) configured distance from a waypoint.
[0138] A waypoint-based condition may be in the form of a time to reach a waypoint or time spent at a waypoint. For example, a waypoint-based condition may indicate one or more of the following: a WTRU will be within a configured distance from a waypoint in less than a configured threshold time; a WTRU spends at least a configured period of time within a configured distance from a certain waypoint; a WTRU will not be within a configured distance from a waypoint for more than a configured threshold time; and/or a WTRU spends less than a configured period of time within a configured distance from a certain waypoint.
[0139] A waypoint-based condition may be in the form of a change in a reported waypoint. For example, a waypoint-based condition may indicate one or more of the following: a waypoint changes by at least a configured distance; a timestamp associated with a waypoint changes by at least a configured time; and/or a WTRU skips a waypoint (e.g., arrives at a second waypoint that it was expected to arrive at after a first waypoint, before arriving at the first waypoint, etc.).
[0140] A speed-based condition may be implemented. A WTRU may be configured with a speed-based condition used to determine a parameter, behavior, etc. A speed-based condition may be configured by the network (e.g., in RRC) or may be predefined. A speed based condition may be configured by the network. A speed-based condition may be enabled/disabled by NW signaling (e.g., MAC CE, DCI, SIB, RRC, etc.).
A speed-based condition may be enabled/disabled by another condition (e.g., height-based condition, waypoint-based condition, etc.).
[0141] A speed-based condition may be in the form of the WTRU reaching at least or at most a certain speed. For example, a speed-based condition may indicate one or more of the following: a WTRU’s speed is above a configured threshold; a WTRU’s speed is below a configured threshold; and/or a WTRU’s speed is between two configured thresholds.
[0142] A speed-based condition may be in the form of a change in the WTRU’s speed (e.g., acceleration/deceleration). For example, a speed-based condition may indicate one or more of the following: a WTRU’s speed changes by an amount greater than a threshold (e.g., within a time period); a WTRU’s speed increased by an amount greater than a threshold (e.g., within a time period); a WTRU’s speed decreases by an amount greater than a threshold (e.g., within a time period). [0143] A speed-based condition may be in the form of a time the WTRU spends at a certain speed. For example, a speed-based condition may indicate one or more of the following: a WTRU’s speed stays at the same value for at least a configured period of time; a WTRU’s speed stays within a configured range at least for a configured period of time; and/or a WTRU’s speed changes by more/less than a configured amount over a configured period of time.
[0144] A WTRU LTM candidate set update may be based on height, speed, and/or waypoint conditions. For example, a device may include a processor that is configured to receive first configuration information. The first configuration information may indicate a first candidate cell and a second candidate cell. For example, the first candidate cell may be an LTM candidate cell. The second candidate cell may be an LTM candidate cell. The first candidate cell may be part of a first set of LTM candidate cells. The second candidate cell may be part of a second set of LTM candidate cells. The first configuration information may be indicative of the first set of LTM candidate cells and the second set of LTM candidate cells. The WTRU may select the first cell from the first set of candidate cells and select the second cell from the second set of candidate cells.
[0145] The processor may be configured to receive second configuration information. The second configuration information may be indicative of a first geographic dependent condition and a second geographic dependent condition (e.g., potential UAV condition). For example, the geographic dependent conditions may include metrics related to aspects such as UAV height, UAV speed, waypoints, and the like, as described herein. For example, the geographic dependent condition may represent a condition that is potentially satisfiable during UAV operation. For example, the geographic dependent condition may include any UAV parameter reportable to the E-UTRAN. For example, the geographic dependent condition may represent a threshold metric associated with UAV operation.
[0146] The processor may receive information indicative of an apparent UAV condition. For example, the processor may receive information related to UAV operating aspects such as present and/or recently present UAV height, UAV speed, waypoints, and the like. The apparent UAV condition may be determined by the UAV. For example, the apparent UAV condition may be determined by a status determination and/or measurement of the UAV operation.
[0147] The configuration information may indicate a first layer one/two triggered mobility (LTM) procedure and a second LTM procedure. The processor may be configured to determine which one of the first candidate cell and the second candidate cell to perform an LTM procedure based on a comparison of an apparent UAV condition and the potential UAV condition. For example, the LTM procedure may be performed with the first candidate cell based on the apparent UAV condition not satisfying the potential UAV condition. For example, the LTM procedure may be performed with the second candidate cell based on the apparent UAV condition satisfying the potential UAV condition.
[0148] In an example, a WTRU may receive a configuration of a first and a second set of LTM candidate cells (e.g., or CHO/CPAC configurations). A WTRU may receive a configuration associating a (e.g., each) set with one or more geographic dependent conditions (e.g., height, speed, and/or waypoint conditions). For example, the geographic dependent condition may be a height condition associated with an altitude at which the WTRU is located, a speed condition associated with a speed at which the WTRU is moving, or a waypoint condition associated with a waypoint in a flight path location of the WTRU. The first geographic dependent condition may be associated with the first LTM procedure, and the second geographic dependent condition may be associated with the second LTM procedure.
[0149] The WTRU may perform LTM procedures using a first set of candidate cells (e.g., measurements, reporting, early sync, MAC CE contents refer to the cells in a first set). For example, the WTRU may perform the first LTM procedure by using or measuring a first cell (e.g., in the first set).
[0150] The WTRU may determine that the first geographic dependent condition (e.g., one or more height, speed, and/or waypoint conditions) is met (e.g., that height is above a threshold or that a waypoint is reached). The WTRU may (e.g., based on the one or more geographic dependent conditions being satisfied) transmit an indication. The WTRU may perform LTM procedures using the second set of candidate cells. For example, the WTRU may perform the first LTM procedure by using or measuring a first cell (e.g., in the first set).
[0151] FIG. 7 illustrates an example use-case utilizing known waypoints associated with sets of LTM candidate configurations (e.g., or cells). The WTRU may determine that the first geographic dependent condition is satisfied if the WTRU determines that the WTRU has reached a first waypoint. The WTRU may determine that the second geographic dependent condition is satisfied if the WTRU determines that the WTRU has reached a second waypoint. As shown in FIG. 7, sets of candidate LTM configurations or cells may be associated with previously reported waypoints. Waypoint 1 may be associated with candidate set 1. Waypoint 2 may be associated with candidate set 2. FIG. 7 may be a simplified example. As described herein, a location/waypoint-based condition may be a range of locations (e.g., within a certain radius of a location, between two location co-ordinates, etc.), for example, rather than one exact location.
[0152] A location/waypoint-based condition specified as a range of locations may be appropriate, for example, if the WTRU moves from one geographical area to another, the WTRU may monitor for a different group of cells after a certain time. The WTRU may move from the location indicated by waypoint 1 to the location indicated by waypoint 2. The WTRU may perform the second LTM procedure (e.g., associated with waypoint 2). For example, the WTRU may cease performing the first LTM procedure (e.g., stop monitoring the cells associated with waypoint 1) and monitor the cells associated with waypoint 2. The WTRU may send an indication (e.g., to the network) that the second cell (e.g., cell associated with waypoint 2) is in use. [0153] In some examples (e.g., use-case(s)), each of the known waypoints may be at different heights. For example, the WTRU at a waypoint closer to the ground may be configured to monitor for cells in close proximity to each other, or monitor for cells with a smaller coverage, while a WTRU with a waypoint higher in the air may be configured to monitor for cells that are geographically further apart or with a wider coverage. A WTRU with a waypoint at a higher altitude (e.g., an absolute altitude or a height relative to the ground level) may (e.g., alternatively) be configured to measure a larger or a smaller set of cells compared to a WTRU with a waypoint closer to the ground. For example, the WTRU may be able to detect and use a higher number of different cells at a high altitude. The best cell (e.g., at any point of time) may be one of a larger set than if the WTRU was closer to the ground. In another example, the number of monitored cells may be smaller at a higher altitude waypoint, for example, if each of the cells have a larger coverage than each of the larger set of cells monitored while the WTRU is at a waypoint closer to the ground. For example, the cells with a larger coverage may use a carrier or band in FR1 while the cells with a smaller coverage may use a carrier or band in FR2. Similarly, the sets of candidate cells may alternatively or additionally be associated with one or more height thresholds. As described herein in the context of using waypoints at different heights, a WTRU may monitor a different set of cells when above the height threshold compared to when below a threshold. A WTRU may monitor a first set of cells if the WTRU is above a speed-based threshold and a second set of cells if the WTRU is below the threshold.
[0154] FIG. 8 illustrates an example procedure utilizing waypoints or height or speed thresholds associated with different sets of LTM candidate configurations (e.g., or cells). As shown in FIG. 8, at 1 , the WTRU may receive a configuration of a first and a second set of LTM candidate cells. A (e.g., each) set of cells may be associated or linked to (e.g., certain) conditions based on waypoint, height, and/or speed conditions. The configuration may be received using RRC signalling.
[0155] At 2, the WTRU may perform LTM procedures (e.g., early sync, L1 measurements, LTM execution) using a first set of LTM candidate cells.
[0156] At 3, the WTRU may evaluate the configured height, speed, and/or waypoint based condition(s) while performing LTM execution on the first set of candidate cells. The WTRU may determine that the first geographic dependent condition is satisfied if an altitude of the WTRU is below an altitude threshold. The WTRU may determine that the first geographic dependent condition is satisfied if the speed of the WTRU is below a speed threshold. The WTRU may perform LTM procedures using the first set of candidate cells, for example, as long as the second geographic dependent condition is not met. For example, the WTRU may use the first set of candidate cells if the WTRU has not reached a second waypoint, or as long as the height or speed is below a configured threshold.
[0157] At 4, the second geographic dependent condition may be met. For example, the WTRU may determine that the second geographic dependent condition is satisfied if the altitude of the WTRU is above the altitude threshold. The WTRU may determine that the second geographic dependent condition is satisfied if the speed of the WTRU is above the speed threshold. The WTRU may reach waypoint 2, or the height or speed of the WTRU may go above a configured threshold. The WTRU may start using the second set of LTM candidate cells for performing LTM execution.
[0158] In some examples, a WTRU may (e.g., based on/upon selecting the second set of LTM candidate cells) send an indication to the network indicating (e.g., using an identity) that the second set of LTM candidate cells is in use. The indication may be sent in a MAC CE, in an RRC message, or in an L1 UCI (e.g., a scheduling request resource configured for this purpose). In some examples, the indication may be delayed (e.g., not sent immediately). The indication may be included in another uplink message (e.g., a MAC CE or CSI report, for example, including L1 measurement results of the candidate cells). The indication may be implicit. For example, a measurement for a cell that is in the candidate set 1 may be included, which may imply candidate set 1 is in use.
[0159] L3 and LTM mobility switching may be based on height, speed, and/or waypoint conditions. For example, a WTRU may receive a configuration of a first mobility evaluation associated with a first measurement type (e.g., a first type of mobility evaluation LTM using L1 measurements) and a second mobility evaluation associated with a second measurement type (e.g., a second type of mobility evaluation L3 handover using RRC measurements). A (e.g., each) type of mobility evaluation may be associated with one or more height, speed, and/or waypoint conditions.
[0160] The WTRU may perform a mobility evaluation (e.g., the first mobility evaluation) based on (e.g., using) the first measurement type/type of mobility evaluation (e.g., L1 measurements, reporting using MAC CE). The WTRU may send (e.g., to the network) a result of the first mobility evaluation (e.g., send L1 measurements using a MAC CE).
[0161] The WTRU may determine that a geographic dependent condition is satisfied. For example, the WTRU may determine (e.g., based on the mobility evaluation) that a height condition (e.g., associated with an altitude at which the WTRU is located), a speed condition (e.g., associated with the speed at which the WTRU is moving), and/or waypoint condition (e.g., associated with a waypoint in a flight path location of the WTRU) is met (e.g., the height or speed may be above a threshold or a waypoint may be reached). The WTRU may (e.g., based on the geographic dependent condition(s) being satisfied) transmit an indication and/or perform mobility evaluation (e.g., the second mobility evaluation) based on (e.g., using) the second measurement type/type of mobility evaluation (e.g., L3 filtering, reporting using RRC measurement report). The WTRU may send (e.g., to the network) a result of the second mobility evaluation (e.g., send L3 measurements in RRC signaling).
[0162] FIG. 9 illustrates an example use case utilizing waypoints, height, and/or speed thresholds associated with different types of mobility. As shown by example in FIG. 9, a WTRU may be configured with different types/methods of mobility depending on the current height. A heig ht/altitude threshold may be configured. The WTRU may perform LTM if the WTRU is below the height/altitude threshold. The WTRU may determine that the geographic dependent condition is satisfied (e.g., and therefore use L3 mobility) if the WTRU is above the height/altitude threshold.
[0163] Using different types/methods of mobility may be appropriate, for example, for controlling whether the WTRU performs the enhanced (e.g., lower latency) LTM procedure when performing mobility between cells belonging to the same CU (e.g., both intra-DU and inter-DU may be supported for LTM) and performing mobility between cells belonging to different CUs (e.g., inter-CU mobility may not be supported for LTM). Groups of cells within close proximity to one another may (e.g., likely) belong to the same CU. A WTRU close to the ground may measure and perform handover between cells of the same CU. A WTRU at a higher altitude may be able to measure cells from multiple different CUs. A (e.g., each) CU may provide cells with different coverage (e.g., using different frequency layers or bands). For example, a single CU may provide one or more wider coverage cells (e.g., in FR1) and multiple narrower coverage cells (e.g., in FR2). A WTRU at a high altitude may be configured to perform L3 mobility using the one or more wider coverage cells covering a larger geographical area while the WTRU at a lower altitude may be configured to perform LTM using sets of narrower coverage cells covering a smaller geographical area (e.g., but which may be capable of providing higher throughput and lower latency).
[0164] In some examples, a WTRU may be at a higher altitude, where more beams and cells may be “visible” (e.g., detectable). A WTRU may be configured to use L3 measurements and L3 mobility at a higher altitude, for example, to take advantage of the longer evaluation times and lowered ping-pong rates (e.g., compared to LTM) to ensure a more stable transition between different cells and reduce the number of handovers that may take place. A WTRU may (e.g., alternatively) be configured to take advantage of the higher number of detected beams. The WTRU may enable LTM at higher altitude, giving the network more scheduling flexibility, for example, if/when more potential cells and beams are available. The WTRU may (e.g., be configured to) use L3 mobility, for example, if/when the WTRU is closer to the ground. The multiple configurations based on altitude or height above ground may be an advantage, for example, if the WTRU moves at a relatively high speed when close to the ground, such that the WTRU is moving between different CDs (e.g., relatively regularly) and using L3 mobility (e.g., frequently), while at higher altitude the WTRU may detect more of the beams and cells in a single CU for a longer period of time.
[0165] In some examples, each of the multiple known waypoints may be at different heights. For example, the WTRU at a waypoint closer to the ground may be configured to use LTM procedures to monitor for cells in close proximity to each other (e.g., or monitor for cells with a smaller coverage) while a WTRU with a waypoint higher in the air may be configured to use L3 measurements to monitor for cells that are geographically further apart or with a wider coverage.
[0166] In some examples, the number of monitored cells may be smaller at a higher altitude waypoint, for example, if each of the cells have a larger coverage than each of the larger set of cells monitored while the WTRU is at a waypoint closer to the ground. For example, the cells with a larger coverage may use a carrier or band in FR1 while the cells with a smaller coverage may use a carrier or band in FR2. Similarly, the sets of candidate cells may alternatively or additionally be associated with one or more height thresholds. As described herein (e.g., in the context of using waypoints at different heights), the WTRU may monitor a different set of cells when above a height threshold compared to when below the threshold. The WTRU may monitor a different set of cells when above a speed based threshold compared to a set of cells monitored when below the threshold.
[0167] FIG. 10 illustrates an example procedure utilizing waypoints, height, and/or speed thresholds associated with different types of mobility. For example, a device may include a processor configured to receive first configuration information and second configuration information. The first configuration information may be indicative of a first mobility method (e.g., an L1 -based mobility method) and a second mobility method (e.g., an L3-based mobility method). The second configuration information may be indicative of a potential UAV condition (such as a potential UAV condition disclosed herein). The processor may be configured to determine which one of the first mobility method and the second mobility method to perform based on a comparison of an apparent UAV condition and the potential UAV condition.
[0168] For example, as shown in FIG. 10, at 1 , a WTRU may receive a configuration of a first type of mobility and a second type of mobility. The WTRU may receive a configuration associating each type of mobility with one or more waypoint, height, and/or speed conditions. The configuration may be received using RRC signalling. The first type of mobility may be, for example, LTM. The first type of mobility (e.g., LTM) may use L1 measurements and reporting and a MAC CE cell change trigger. The second type of mobility may be L3 mobility. The second type of mobility (e.g., L3) may use L3 measurements, an RRC measurement report, and RRC reconfiguration.
[0169] At 2, the WTRU may perform mobility using the first mobility method. [0170] At 3, the WTRU may evaluate the configured height, speed, and/or waypoint-based condition while performing the first type of mobility. The WTRU may perform mobility using the first type of mobility, for example, as long as the geographic dependent condition is not met. For example, the WTRU may use LTM if the WTRU has not reached a second waypoint, or as long as the height or speed is below a configured threshold.
[0171] At 4, the WTRU may start using the second type of mobility (e.g., L3 mobility), for example, if/when the geographic dependent condition is met (e.g., the WTRU reaches waypoint 2, or the WTRU’s height or speed is/goes above a configured heigh or speed threshold).
[0172] In some examples, the WTRU may (e.g., upon selecting the second mobility method) send an indication to the network indicating (e.g., using an identity) that the second mobility method is in use or that the condition is met. The indication may be sent, for example, in a MAC CE, an RRC message or in L1 UCI. In some examples, the indication may be delayed (e.g., not sent immediately). The indication may be included in another uplink message (e.g., a MAC CE or CSI report including L1 measurement results of the candidate cells). The indication may be implicit. For example, the WTRU may send an RRC measurement report including L3 measurements, which may (e.g., impliedly/implicitly) indicate that an L3 based mobility procedure has been selected. The WTRU may send an L1 measurement report (e.g., CSI report or MAC CE), which may (e.g., impliedly/implicitly) indicate that an L1/2 based mobility procedure has been selected.
[0173] In some examples, multiple (e.g., both) types of mobility may be configured, and may run in parallel. Each type of mobility may be associated with a condition (e.g., the same condition or independent conditions) that enables or disables the type of mobility. In some examples, conditional reconfigurations (e.g., CHO evaluation and trigger) may be enabled/disabled based on the condition.
[0174] Updates may be NW-controlled fast candidate set updates.
[0175] For example, a WTRU may receive configuration information that indicates a first LTM procedure associated with a first cell (e.g., of first set of LTM candidate cells) and a second LTM procedure associated with a second cell (e.g., of a second set of LTM candidate cells). The WTRU may select the first cell from the first set of candidate cells and the second cell from the second set of candidate cells The WTRU may receive (e.g., in the configuration information) a geographic dependent condition (e.g., measurement event condition) related to height and/or speed thresholds and/or waypoint arrival.
[0176] The WTRU may perform the first LTM procedure based on (e.g., using or measuring) the first cell (e.g., of the first set of candidate cells). The WTRU may determine that a measurement event condition has been met. The WTRU may transmit an L1/2 indication of the event (e.g., via/in a MAC CE). The WTRU may receive an L1/2 indication of an index (e.g., in a MAC CE) to a second set of cells. The WTRU may (e.g., additionally) receive an indication of new SpCell/SCell(s) (e.g., to trigger LTM execution). The WTRU may update the candidate cell set and/or execute LTM (e.g., if indicated). The WTRU may perform LTM using the second set of candidate cells.
[0177] A WTRU may autonomously update, for example, based on certain criteria, such as if the LTM set is in use. In some examples, a WTRU may report that a condition has been met, and (e.g., in response) the network may control the change of LTM set.
[0178] FIG. 11 illustrates an example procedure utilizing NW controlled fast candidate set update. At 1, the WTRU may receive a configuration of a first LTM procedure associated with a first cell (e.g., of first set of LTM candidate cells) and a second LTM procedure associated with a second cell (e.g., of a second set of LTM candidate cells). A (e.g., each) set of cells may be a grouping of individual candidate cell configurations. Some candidate cell configurations may be part of more than one set. A (e.g., each) set of cells may be provided with an index or identifier. A (e.g., each) set of cells may be provided with a different index or identifier. The configuration may be received using RRC signaling.
[0179] At 2, the WTRU may receive a measurement reporting event configuration. The WTRU may receive a geographic dependent condition (e.g., a configuration to trigger a measurement event), for example, if it is determined that the height or speed goes above or below a threshold. The WTRU may receive a geographic dependent condition (e.g., a configuration to trigger a measurement event), for example, if/when it is determined that a waypoint has been reached, or the WTRU is within a threshold distance or time from a waypoint.
[0180] At 3, the WTRU may perform LTM procedures (e.g., early sync, L1 measurements, LTM execution) using a first set of LTM candidate cells.
[0181] At 4, the WTRU may determine whether the geographic dependent condition has been met. For example, the geographic dependent condition may be a height condition associated with an altitude at which the WTRU is located, a speed condition associated with a speed at which the WTRU is moving, or a waypoint condition associated with a waypoint in a flight path location of the WTRU. The WTRU may evaluate the configured height, speed, and/or waypoint based condition while performing LTM execution on the first set of candidate cells. The WTRU may perform LTM procedures using the first set of candidate cells, for example, as long as the geographic dependent condition is not met. The WTRU may use the first set of candidate cells, for example, if the WTRU has not reached a second waypoint, or as long as the height or speed is below a configured threshold.
[0182] At 5, the WTRU may determine that the geographic dependent condition has been satisfied/met (e.g., if/when the WTRU reaches waypoint 2, or the height/altitude or speed goes above a configured height/altitude or speed threshold). The WTRU may (e.g., in response to the determination that the geographic dependent condition was satisfied) send an indication (e.g., to the network) that the geographic dependent condition (e.g., measurement event) was met. The indication may be sent using a MAC CE or an RRC measurement report. The indication may include an index or identifier to the criteria configuration (e.g., event ID). The indication may include measurement information, such as an indication of the radio quality (e.g., RSRP, RSRQ) of one or more beams or cells.
[0183] At 6, the WTRU may receive (e.g., from the network) an indication associated with the second LTM procedure (e.g., a MAC CE, which may include an index or identifier for a second set of cells). The MAC CE may indicate indexes or identifiers for new SpCell/SCell(s) to trigger LTM execution and/or SCell activation/deactivation.
[0184] At 7, in response to receiving the indication associated with the second LTM procedure, the WTRU may perform the second LTM procedure (e.g., by using or measuring the second cell). For example, the WTRU may update the candidate cells considered for LTE to the second set of candidate cells. The update may involve updating individual candidate cell indexes. The WTRU may execute LTM (e.g., if indicated) to perform an RRC reconfiguration to a new SpCell. The WTRU may activate or deactivate one or more SCells (e.g., if indicated). The indication to execute LTM may be received in the same message (e.g., MAC CE) as the indication to update the set of cells in use. In some examples, the WTRU may execute a cell change and update the group of candidate cells simultaneously.
[0185] At 8, the WTRU may start using the second set of LTM candidate cells for performing LTM execution. The WTRU may determine that a second geographic dependent condition has been satisfied (e.g., the WTRU has reached a third waypoint, or the height/altitude or speed is below the height/altitude or speed threshold). The WTRU may send (e.g., to the network entity) an indication that the second geographic dependent condition has been satisfied. The WTRU may receive (e.g., from the network entity) an indication associated with the first LTM procedure. In response to receiving the indication associated with the first LTM procedure, the WTRU may use or measure a third cell based on the first LTM procedure. [0186] FIG. 12 illustrates an example of signaling to perform the procedure utilizing NW controlled fast candidate set update. At 1 , an RRC reconfiguration message may be received. The reconfiguration message may be provided in any type of downlink signalling from the gNB to the WTRU. The measurement condition may be provided in an RRC measurement control message, or may be provided together with the configuration at 1 (e.g., in an RRC reconfiguration), or may be provided in any other downlink signalling message from the gNB to the WTRU. The event at 5 may be reported using a MAC CE in the uplink. The uplink indication may include measurement results for cells or beams measured as part of performing LTM. The indication at 6 may be provided in a MAC CE. The indication at 6 may include an indication to execute LTM to a new SpCell and/or to activate or deactivate one or more SCells. [0187] The event at 5 may (e.g., alternatively) be reported by transmission on a PUCCH resource, such as a scheduling request resource configured for this purpose, e.g., as part of the second LTM configuration. For example, the WTRU may initiate a procedure (e.g., a CSI prompting procedure), which may be the same as a scheduling request procedure but the condition for cancelling the scheduling request may be the reception of signaling that performs at least one of the following: activates or triggers L1 (e.g., CSI) reporting for a report configuration or a trigger state associated with a second LTM configuration or for a second set of candidate cells, SSB indices or CSI-RS resources; and/or activates resources for channel and/or interference measurements associated with a second LTM configuration for at least one report configuration or trigger state.
[0188] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.
[0189] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.
[0190] The processes described above may be implemented in a computer program, software, and/or firmware 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 over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as compact disc (CD)-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.