Methods, architectures, apparatuses and systems for low layer mobility based on non-radio measurements

Abstract

In an embodiment, a method implemented in a wireless transmit / receive unit includes transmitting a first message containing information about non-radio measurement capability to a network; receiving, from the network, a second message including information on a configuration for determining a partition location of the WTRU; receiving, from the network, a third message including a plurality of mobility configurations and information indicating non-radio measurements; determining one or more changes in the non-radio measurements; determining a WTRU partition location based on non-radio measurements from the non-radio measurements and based on the configuration for determining the partition location; transmitting the determined partition location to a network; receiving, from the network, a command message containing information for performing a cell handover to a target cell associated with one of the plurality of configurations; and performing a cell handover to the target cell based on the command message.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 463,160, filed May 1, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to the fields of communications, software, and coding, including methods, architectures, apparatuses, and systems relating to wireless communication systems, and more specifically, to user equipment mobility within wireless networks. Background Technology

[0003] User equipment mobility leads to cell changes for service continuity. Traditional mobility processes operate primarily at the radio resource control layer, also known as Layer 3 (L3). The network and user equipment exchange messages, measurements, and configurations prior to cell changes.

[0004] For networks employing high carrier frequencies (leading to the need for very dense deployment of narrow beam transmissions), traditional mobility frameworks based on higher-layer measurements, cell measurements, reporting, cell change / update decisions, and execution involve very high overhead and generate delays far beyond the time scale of mobility events.

[0005] There is a need to improve the mobility of user equipment within the wireless network. Summary of the Invention

[0006] In an embodiment, a method implemented in a wireless transmit / receive unit may include the step of sending a first message to a network, the first message containing first information about non-radio measurement capabilities. The method may further include the step of receiving a second message from the network, the second message containing second information indicating a first configuration for determining the partition location of a WTRU based on non-radio measurement capabilities. The method may further include the step of receiving a third message from the network, the third message containing third information indicating multiple mobility configurations and indicating a second configuration based on a reporting trigger event for non-radio measurements. The method may further include the step of determining the WTRU partition location based on the first configuration for determining the partition location. The method may further include the step of sending a fourth message to the network indicating the determined partition location, provided that a reporting trigger event in the configured reporting trigger event is satisfied. The method may further include: in response to sending the fourth message, receiving a command message from the network, the command message containing information for performing a cell handover to a target cell associated with one of the multiple mobility configurations; and the step of performing the cell handover to the target cell based on the command message.

[0007] In another embodiment, a method implemented in a wireless transmit / receive unit may include the step of sending a first message to a network, the first message containing information about non-radio measurement capabilities. The method may further include the step of receiving a second message from the network, the second message containing information about network coverage and deployment topology. The method may further include the step of receiving a third message from the network, the third message containing multiple mobility configurations and information indicating non-radio measurements used for network coverage and deployment topology. The method may further include the step of determining one or more variations among the non-radio measurements. The method may further include the step of determining WTRU partition locations based on non-radio measurement values ​​from the non-radio measurements and based on network coverage and deployment topology. The method may further include the step of sending the determined partition locations to the network. The method may further include the step of receiving a command message from the network, the command message containing information for performing a cell handover to a target cell associated with one of a plurality of configurations; and the step of performing the cell handover to the target cell based on the command message.

[0008] In another embodiment, a method implemented in a wireless transmit / receive unit may include the step of sending a first message to a network, the first message containing information about non-radio measurement capabilities. The method may further include the step of receiving a second message from the network, the second message containing configuration information for determining partition information for a WTRU. The method may further include the step of receiving a third message from the network, the third message containing multiple mobility configurations and multiple non-radio measurement configurations associated with multiple partition information. The method may further include the step of determining the partition information based on the second message. The method may further include: determining one of the multiple non-radio measurements associated with the partition information; and performing the determined non-radio measurement based on the determined partition information. Attached Figure Description

[0009] A more detailed understanding can be obtained from the following detailed description, taken in conjunction with the accompanying drawings. The figures in these drawings are, as in the detailed description, exemplary. Therefore, these figures and the detailed description should not be considered limiting, and other equally valid examples are possible and likely to exist. Furthermore, similar reference numerals in the figures indicate similar elements, wherein: Figure 1A This is a system diagram illustrating an exemplary communication system; Figure 1B It shows that it can be used Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C It shows that it can be used Figure 1AA system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system; Figure 1D It shows that it can be used Figure 1A The system diagram shown illustrates another exemplary RAN and another exemplary CN used within the communication system. Figure 2 This is a sequence diagram illustrating an example of the switching process; Figure 3 This is a sequence diagram illustrating an example of a conditional switching process; Figure 4A This is a system diagram illustrating an example of multi-TRP transmission based on a single downlink control information; Figure 4B This is a system diagram illustrating an example of multi-TRP transmission based on multiple downlink control information; Figure 5 This is a flowchart illustrating an example of updating WTRU coverage information and low-level triggered mobility (LTM) configuration; Figure 6 This is a flowchart illustrating an example of an LTM measurement framework based on the reporting configuration; Figure 7 This is a flowchart illustrating an example of an LTM measurement framework based on measurement identifiers; Figure 8 This is a flowchart illustrating an example of an LTM measurement framework employing a combined reporting and quantity configuration; Figure 9 This is a block diagram illustrating an example of an LTM measurement model employing L1 / L2 filtering; Figure 10 This is a block diagram illustrating an example of an LTM measurement model using events based on L1 and L3; Figure 11 This is a block diagram illustrating an example of an LTM measurement model employing measurement bias; Figure 12 This is a block diagram illustrating an example of a unified measurement model employing separate parameter sets for L3 and LTM measurements; Figure 13 This is a flowchart illustrating an example of a network-controlled LTM process triggered by a non-radio WTRU measurement; Figure 14 This is a flowchart illustrating an example of a method for activating LTM configuration based on partition information reported by WTRU.

[0010] Figure 15 This is a flowchart illustrating an example of a method for performing cell handover based on WTRU partition location, implemented in a radio transmit / receive unit (WTRU) according to an embodiment; Figure 16This is a flowchart illustrating an example of a method for performing cell handover based on WTRU partition location, implemented in a WTRU according to another embodiment; Figure 17 This is a flowchart illustrating an example of a method for performing non-radio measurements based on WTRU partition information, implemented in a WTRU according to an embodiment. Detailed Implementation

[0011] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that these embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples described herein, disclosed, or otherwise expressly, implicitly, and / or inherently provided (collectively, the “Provided”). Although this document describes and / or claims various embodiments in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0012] The methods, apparatus, and systems provided herein are particularly applicable to communications involving wired and wireless networks. Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein multiple elements of a network can utilize, perform, be arranged according to, and / or adapt and / or configure for use with the methods, apparatuses and systems provided herein.

[0013] Figure 1AThis is a system diagram illustrating an exemplary communication system 100 that can be used to implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content (e.g., voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Zero-Tail (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0014] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments consider any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, any one of WTRU 102a, 102b, 102c, and 102d may be referred to as a “station” and / or “STA”, configured to transmit and / or receive wireless signals, and may include (or be) user equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable device, head-mounted display (HMD), vehicle, drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any one of WTRU 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0015] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to connect to the wireless interface of at least one of WTRUs 102a, 102b, 102c, and 102d (e.g., to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or Network 112)). For example, base stations 114a and 114b may be any of a base transceiver station (BTS), Node-B (NB), eNode B (eNB), home Node B (HNB), home eNode B (HeNB), gNode-B (gNB), NR Node-B (NR NB), site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0016] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area, which may be relatively fixed or may vary over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell. For example, beamforming can be used to send and / or receive signals in a desired spatial direction.

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

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

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

[0020] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0021] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can together implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0022] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Interconnection Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), and GSM EDGE (GERAN).

[0023] Figure 1A Base station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In embodiments, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: small cell, pico cell, and femtocell. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may access Internet 110 without needing to go through CN 106 / 115.

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

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

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

[0027] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other elements / peripherals 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0028] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together (e.g., in an electronic package or chip).

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

[0030] Although Figure 1B While the transmitting / receiving element 122 is depicted as a single element, the WTRU 102 may include any number of transmitting / receiving elements 122. For example, the WTRU 102 may employ MIMO technology. Therefore, in an embodiment, the WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0031] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0032] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 may access and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access and store data in memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

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

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

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

[0036] WTRU 102 may include a full-duplex radio unit for which the transmission and reception of some or all signals (e.g., associated with specific subframes of both the uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio unit may include an interference management unit to reduce and / or substantially eliminate self-interference through signal processing via hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio unit for which the transmission and reception of some or all signals (e.g., associated with specific subframes of either the uplink (e.g., for transmission) or downlink (e.g., for reception) are separate.

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

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

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

[0040] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the foregoing elements is depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

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

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

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

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

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

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

[0047] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic from outside the BSS to a STA can reach and be transmitted to the STA via the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for transmission to the corresponding destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can transmit the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) via Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0048] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can listen to the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0050] Very High Throughput (VHT) STAs support wide channels of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels; this is known as an 80+80 configuration. For the 80+80 configuration, channel-coded data is delivered via a segmented parser that splits the data into two streams. Each stream can be individually processed using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the merged data can be sent to the Media Access Control (MAC) layer, entities, etc.

[0051] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

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

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

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

[0056] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using multiple or scalable lengths of subframes or transmission time intervals (TTIs), such as including different numbers of OFDM symbols and / or varying absolute time lengths.

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

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

[0059] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0060] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. The AMF162 provides control plane functionality for switching between 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 Wi-Fi).

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

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

[0063] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0064] Given Figures 1A to 1D And to Figures 1A to 1D As described herein, one or more of the functions described herein, relating to any of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other element / device described herein, may be performed by one or more emulated elements / devices (not shown). Emulation devices may be configured to emulate one or more devices that perform one or more of the functions described herein. For example, emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0066] One or more simulation devices may perform one or more functions when not implemented or deployed as part of a network node (e.g., a wired and / or wireless communication network). For example, simulation devices may be used in test scenarios in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., under test) to perform testing on one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0067] WTRU mobility may trigger cell changes for service continuity. Traditional mobility procedures primarily operate at the Radio Resource Control (RRC) layer, also known as Layer 3 (L3). The network and WTRU exchange messages, measurements, and configurations before a cell change. In the following description, the protocol stack (e.g., Layers 1, 2, and 3) can be defined as follows: Layer 1 is the physical layer. Layer 2 may include the MAC layer, Radio Link Control (RLC) layer, and Packet Data Convergence Protocol (PDCP). Layer 3 is the RRC layer.

[0068] In this embodiment, the L3 mobility process can be a gNB handover process, also known as a traditional handover. If the WTRU is in RRC connectivity mode, cell / gNB-level mobility may require explicit RRC signaling to be triggered. When the quality of a neighboring cell is consistently better by an offset within a preset trigger time (TTT), the WTRU can report cell quality measurements to its serving (source) cell. Different events can be defined to trigger the WTRU measurement reporting, referred to as A1, A2, A3, A4, A5, etc. The TTT and cell-specific offset can be specified during the measurement configuration step. If a handover (HO) decision is made based on the measurement report, the source gNB can issue a handover request to the target gNB. If the target gNB admits the WTRU, the target gNB can send a handover request confirmation to the source gNB, which includes the RRC message to be sent to the WTRU. Next, the source gNB can initiate the handover and can send an RRC reconfiguration message to the WTRU. It may also include a dedicated random access channel (RACH) resource set. Finally, the WTRU can synchronize with the target cell and complete the RRC handover process. The overall HO process in Figure 2 As shown in the image.

[0069] refer to Figure 2 In step 1, the source gNB can configure the WTRU measurement process and WTRU report according to the measurement configuration. In step 2, the source gNB can decide to hand over the WTRU based on the measurement report and radio resource management information. In step 3, the source gNB can send a handover request message to the target gNB, conveying a transparent RRC container containing the information required for handover preparation on the target side. In step 4, admission control can be performed by the target gNB. In step 5, the target gNB can prepare for handover at Layer 1 and / or Layer 2 (L1 / L2) and can send a handover request confirmation to the source gNB, containing a transparent container to be sent as an RRC message to the WTRU to perform the handover. The target gNB can also indicate whether to accept Dual Active Protocol Stack (DAPS) handover. In step 6, the source gNB triggers the handover by sending an RRC reconfiguration message to the WTRU, which contains the information required for access to the target cell.

[0070] In step 7a, for a Data Radio Bearer (DRB) configured with DAPS, the source gNB can send an EARLYSTATUS TRANSFER message.

[0071] In step 7, for a Data Radio Bearer (DRB) without DAPS configured, the source gNB can send an SNSTATUS TRANSFER message to the target gNB to transmit the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the DRB with applicable PDCP status reservation.

[0072] In step 8, the WTRU can synchronize with the target cell and complete the RRC handover process by sending an RRCReconfigurationComplete message to the target gNB. In the case of DAPS handover, the WTRU can remain in the source cell upon receiving the RRCReconfiguration message.

[0073] In steps 8a and 8b, during a DAPS handover, the target gNB can send a HANDOVERSUCCESS message to the source gNB to notify the WTRU that it has successfully accessed the target cell. In response, the source gNB can send a STATUS TRANSFER message to the DRB configured with DAPS.

[0074] In step 9, the target gNB can send a PATH SWITCH REQUEST message to the network (e.g., the core network) to trigger the core network to switch the DL data path to the target gNB and establish an interface instance toward the target gNB. The core network can switch the DL data path to the target gNB. The core network (e.g., the UPF) can send one or more "end marker" packets to the source gNB on the old path per PDU session / tunnel, and then can release any U-plane / TNL resources toward the source gNB. The core network (e.g., the AMF) can acknowledge the PATH SWITCH REQUEST message with a PATH SWITCH REQUEST ACKNOWLEDGE message.

[0075] In step 10, after receiving the PATH SWITCH REQUEST ACKNOWLEDGE message from the core network (e.g., AMF), the target gNB can send WTRU CONTEXT RELEASE to notify the source gNB that the handover was successful.

[0076] The HO (Hosting On) process may fail due to poor channel quality of the target gNB, source gNB, or both. In scenarios with directional links, handover problems can be exacerbated because the link quality of the target and source gNBs can deteriorate rapidly due to moving obstructions or WTRU rotation. Obstruction of the target gNB during the handover process can lead to a handover failure (HOF). A handover failure timer can be started when the WTRU receives an RRC reconfiguration message. If the handover failure timer expires before the handover is completed, an HOF can be declared, and the WTRU can perform connection reconstruction. Following a sudden WTRU rotation or obstruction, the source gNB may not be able to initiate a handover process in a timely manner based on the latest measurement reports. Even measurement reports from the WTRU may be lost due to poor link quality. Therefore, without handover assistance from the source gNB, even with a potential target gNB with good channel quality, the WTRU may need to wait for the source gNB to recover from the outage or declare a radio link failure (RLF).

[0077] As a potential solution to the problem of a target gNB being obstructed, Dual Active Protocol Stack (DAPS) handover is specified in 3GPP Rel. 16. In DAPS handover, the WTRU may not release the source cell connection until random access to the target gNB is complete. If the target gNB link deteriorates before random access is complete, the WTRU can fall back to the source gNB.

[0078] To address the issue of source gNB obstruction, Conditional Handover (CHO) is defined in 3GPP Rel. 16. In a CHO, the WTRU can be configured to perform a handover when one or more handover execution conditions are met. The source gNB can proactively configure the WTRU to meet the CHO execution conditions defined for candidate gNBs. Once the conditions are met, for example, when the target gNB is offset higher than the source gNB, the WTRU can initiate a handover to the target gNB without signaling from the source gNB. Therefore, even if the source gNB is interrupted due to sudden obstruction or rotation, the WTRU can still successfully complete the handover to the target gNB if the CHO execution conditions are met. The overall CHO process is as follows: Figure 3 As shown in the image.

[0079] refer to Figure 3In step 1, the source gNB can configure the WTRU measurement process and WTRU reporting according to the measurement configuration. In step 2, the source gNB can decide to use a CHO (Confirmation of Hazard) request. In step 3, the source gNB can request a CHO for one or more candidate cells (e.g., target gNBs) belonging to one or more candidate / potential target gNBs. A CHO request message can be sent for each candidate cell. In step 4, admission control can be performed by one or more target gNBs. In step 5, the candidate target gNB can send a CHO response (HO REQUEST ACKNOWLEDGE) to the source gNB, including the configuration of the CHO candidate cells. A CHO response message can be sent for each candidate cell. In step 6, the source gNB can send a CHO request message to the WTRU. RRCReconfiguration The message contains the configuration of the CHO candidate target cell (e.g., the target gNB) and the CHO execution conditions. WTRU can send this message to the source gNB. RRCReconfigurationComplete In step 7a, if early data forwarding is applied, the source gNB can send an EARLY STATUS TRANSFER message to the potential target gNB.

[0080] In step 8, after receiving the CHO configuration, the WTRU can maintain its connection with the source gNB and begin evaluating the CHO execution conditions of candidate cells. If at least one CHO candidate cell meets the corresponding CHO execution conditions, the WTRU can disconnect from the source gNB, apply the corresponding configuration stored for the selected candidate cell (e.g., a potential target gNB), synchronize with the candidate cell, and complete the RRC handover process by sending an RRCReconfigurationComplete message to the target gNB. After successfully completing the RRC handover process, the WTRU can release the stored CHO configuration. In steps 8a and 8b, the target gNB can send a HANDOVER SUCCESS message to the source gNB to notify the WTRU that it has successfully accessed the target cell. In response, the source gNB can send an SN STATUS TRANSFER message to the target gNB. In step 8c, the source gNB can send a HANDOVER CANCEL message to other signaling connections or other candidate / potential target gNBs (if any) to cancel the CHO for the WTRU.

[0081] In step 9, the target gNB can send a PATH SWITCH REQUEST message to the network (e.g., the core network) to trigger the core network to switch the DL data path to the target gNB and establish an interface instance toward the target gNB. The core network can switch the DL data path to the target gNB. The core network (e.g., the UPF) can send one or more "end marker" packets to the source gNB on the old path per PDU session / tunnel, and then can release any U-plane / TNL resources toward the source gNB. The core network (e.g., the AMF) can acknowledge the PATH SWITCH REQUEST message with a PATH SWITCH REQUEST ACKNOWLEDGE message.

[0082] In step 10, after receiving the PATH SWITCH REQUEST ACKNOWLEDGE message from the core network (e.g., AMF), the target gNB can send WTRU CONTEXT RELEASE to notify the source gNB that the handover was successful.

[0083] While CHO (Content Handling Requests) offers flexibility in addressing moving obstructions and can significantly reduce the number of RLFs (Redirecting Link Failures) stemming from rapidly deteriorating links, its success may depend on the availability of candidate gNBs before the source link fails, the link quality of the target link, and the condition thresholds for the target gNB. Even with candidate gNBs present, the WTRU (Time-to-Domain) needs to maintain link quality with the selected candidate gNB until handover is complete. Careful configuration of the condition thresholds used for handover execution may also be required. High thresholds may prevent the WTRU from performing the handover to the target gNB in ​​a timely manner, leading to handover failure. On the other hand, low thresholds may result in suboptimal selection of a new serving gNB and potentially useless handovers in certain situations.

[0084] The Transmitter-Receiver Point (TRP) transmission mechanism can be limited to the INTRA-CELL configuration and can be specified to support Noncoherent Joint Transmission (NCJT), which can improve downlink data rate and spectral efficiency, especially for cell-edge users. Considering the various backhaul capabilities in practical deployments (e.g., ideal backhaul, non-ideal backhaul), two different NCJT-based transmission schemes can be supported: one based on a single downlink control information (DCI) and the other based on multiple DCIs, such as... Figure 4A and Figure 4B As shown.

[0085] refer to Figure 4ASingle-DCI-based transmission may be more suitable for ideal backhaul between TRPs because a single DCI schedules resources from both TRPs. To receive DL data from different TRPs (TRP1, TRP2), two Transport Configuration Indication (TCI) states can be provided to the WTRU, each TCI state corresponding to one TRP, providing quasi-co-address (QCL) information to the corresponding PDSCH layer. Different TCI code points can be activated by MAC, and the scheduled DCI can indicate one of the activated TCI code points with two TCI states.

[0086] refer to Figure 4B The multi-DCI-based scheme can support scenarios with non-ideal backhaul, where each TRP (TRP1, TRP2) can use its own DCI (DCI1, DCI2) to schedule its resources. In the RRC configuration, the two TRPs (TRP1, TRP2) are implicitly represented by two different control resource sets (CORESET) groups, each identified by the value of the RRC parameter CORESETPoolIndex.

[0087] Multiple TRP operations can be extended to inter-cell scenarios. This can be achieved by allowing the TCI state to be defined from the Synchronization Signal Block (SSB) associated with the Physical Cell Identifier (PCI) of a cell that has established an RRC connection with a cell other than the WTRU. This makes it possible to implement inter-cell multiple TRP operations by properly configuring / activating the TCI state that can be associated with any PCI.

[0088] For networks that employ higher carrier frequencies and thus require very dense deployment of narrow beam transmissions, traditional mobility frameworks based on higher-layer measurements, cell measurements, reporting, cell change / update decisions and execution may involve very high overhead and may produce delays far beyond the timescale of mobility events.

[0089] Layer 1 and / or Layer 2 triggered mobility (LTM) can minimize mobility disruptions. Significant reductions in mobility disruptions can be achieved by triggering mobility events based on non-radio-based measurements. Triggering mobility events based on non-radio measurements combined with network knowledge of cell / beam deployment can lead to more deterministic mobility handling.

[0090] To achieve deterministic L1L2-triggered mobility using non-radio measurements, the following questions need to be addressed: How to enable L1L2 mobility features that focus on non-radio measurements and event sets? And what are the configurations, execution conditions, triggers, and step-by-step procedures for such an L1L2-triggered mobility process? The various embodiments described below illustrate in detail solutions for minimizing mobility disruption based on non-radio measurements.

[0091] The evolution of wireless systems with new applications requiring low latency, high reliability, and high availability has led to a greater focus on and activity regarding service continuity on the move and minimizing service disruptions caused by mobility. To this end, 3GPP has defined and standardized numerous mechanisms that minimize mobility disruptions through faster beam, cell, and network node switching.

[0092] The various embodiments described below enable low-level triggered mobility primarily driven by non-radio measurement data, aiming for near-deterministic mobility. The proposed non-radio measurement-based mobility schemes depend on: (i) the network's knowledge of its node / cell / beam deployments; (ii) the WTRU's ability to perform non-radio measurements in various forms, such as tracking its movement and determining updated geolocation / positioning and orientation in a highly accurate manner; and (iii) the network combining deployment information with the WTRU's non-radio measurement reports to identify (e.g., suitable) target LTM candidates and move the WTRU from its serving cell to such determined LTM targets.

[0093] This strategy is applicable to controlled environments, meaning the network is aware of the surrounding environment of the mobile device / WTRU, and therefore radio conditions are deterministic relative to non-radio measurement reporting related to WTRU location / or orientation. Therefore, the following embodiments are applicable to non-public and / or private networks. The following embodiments are also applicable to industrial / factory scenarios where environmental knowledge is strictly controlled and known to the operator deploying the network, who in many cases is the factory owner or someone working on its behalf. Another scenario for controlled environments can be more forward-looking, where the operator possesses such precise environmental information through other sources (terrain, visual images, real-time cameras, etc.) that even in public network scenarios, network dynamics and environmental changes are known.

[0094] In public cellular networks, operators may be reluctant to fully share deployment configurations with equipment, as this could pose a risk to their facilities. An important aspect relevant to controlled environments and factory scenarios (such as warehouses) is that communication equipment (such as robots, industrial machines, etc.) is also installed and operated by the same owner. This provides confidence that the network topology configuration will not be used for purposes other than those shared with the equipment. To allow for broader use of the various proposed embodiments while maintaining precise information security, deployment topologies are provided in different forms, where partitions are provided with indications of the beams / cells of interest within that partition.

[0095] In different scenarios, LTM strategies can be helpful when the relevant devices have limited measurement capabilities due to any of the following: power limitations, hardware limitations, or antenna / panel implementation limitations. Therefore, network decisions are primarily based on non-radio measurements.

[0096] In the various embodiments described below, the proposed LTM strategy can be broadly divided into two main phases. The first phase can be an LTM preparation phase based on non-radio measurements. The second phase can be an execution phase.

[0097] The ability of a WTRU to quickly and accurately determine its location / orientation and geographic coordinates can be used to select the node / cell / beam to which the WTRU should connect. The network can share a limited portion of its deployment / coverage topology with the WTRU, which uses these portions to report its precise instantaneous coverage coordinates to the network. Details regarding coverage topology content, configuration, maintenance, signaling mechanisms, and WTRU post-processing are provided below.

[0098] In various embodiments, the LTM process can use non-radio measurements. A measurement framework for both radio and non-radio measurements is also provided below. This framework can be used for measurements based on 3GPP radio signals, non-3GPP radio signals, data from local sensors, and other interfaces. To reduce latency and achieve a certain level of stability and accuracy in measurements, different measurement models can select measurements from L1, L3, or a combination of both.

[0099] If the LTM process is run solely based on radio measurements, a ping-pong effect can occur, where the WTRU may switch back and forth between a set of cells due to noise and fading affecting the quality of the radio signal estimation. Using non-radio measurements helps to address this issue.

[0100] In various embodiments, the LTM process can be network-controlled. The network can explicitly issue commands to the WTRU to switch from its serving cell to the target cell. The network decision can be based on measurements taken by the WTRU and reported to the network.

[0101] Low-layer triggered mobility or L1L2 triggered mobility (LTM) is used herein as a term to refer to the process of cell handover triggering, command, and acknowledgment being exchanged primarily at lower layers between the WTRU and the network, as opposed to the traditional mobility process operating at RRC or Layer 3. These lower layers are the PHY layer or the MAC layer, or a combination of both, as detailed in the examples below.

[0102] The preparation phase for an LTM procedure based on non-radio measurements can generally include the configuration of the deployment topology, LTM cell configuration, measurement configuration, and the transfer of capabilities from the WTRU to the network to support the procedure.

[0103] Regarding deployment and coverage zoning, a cellular network can be a planned network in which operators deploy network nodes in (e.g., suitable) locations to provide sufficient coverage to their subscribers. Therefore, network operators can have (e.g., very precise) knowledge of coverage zoning attributes regarding their cells and the deployment of beams within those cells, such as the location of the cell or transport point of reference (TRP) (e.g., a reference location), the potential spatial direction of transmission (e.g., defined by azimuth, elevation, and the location coordinates of the TRP), beamwidth information (such as 3D beamwidth information (e.g., in the horizontal and vertical directions)), transmission range information, and coverage shape information (e.g., including the location coordinates of points that constitute the coverage boundaries of a beam, cell, or TRP).

[0104] The deployment topology can include any information about the TRP's location and beam coverage / orientation. In one embodiment, the TRP's location can be represented using 2D coordinates, examples of which are latitude and longitude coordinates. The location can also be represented using 3D coordinates, which is 2D coordinates with added altitude or elevation. Both 2D and 3D representations can be in a global or local coordinate system.

[0105] A beam from a given TRP can be represented using azimuth and elevation angles. Suitable references, such as a base direction and zenith direction, can be used, or the reference direction can be provided as part of the configuration. For a given beam, these angles can be refined or quantized to meaningfully capture mobility processes and signal strength within or outside the coverage area. In addition to the angles, beamwidths in these directions can also be explicitly provided for the beam. Therefore, with knowledge of the TRP location parameters and beam angles (plus beamwidth), the WTRU can prepare a local topology where the coverage of different beams from different TRPs can be seen. Additional attributes such as range / power can be added to the cell / beam to further refine the deployment topology.

[0106] Coverage topology can provide indications of geographic coverage for different beams from different TRPs. It can represent the coverage boundaries for different TRPs and beams. Coverage topology can incorporate geomorphic properties, topographic aspects, buildings, and other geographic parameters into the deployment topology to prepare partitions and boundaries associated with coverage for different beams from different TRPs.

[0107] Coverage topology can be represented by (e.g., a suitable) geometric shape. Different reference shapes can be defined to indicate the shape defining cell / beam-level coverage. Reference shapes can be (e.g., a suitable) parameterized circular, oval, elliptical, ellipsoidal, etc. Coverage topology can be indicated using these shapes with (e.g., suitable) attributes. These attributes can provide links to cell / beam identifiers associated with a given shape / area.

[0108] The terms "deployment topology" and "coverage topology" are used interchangeably in this document. Where a distinction is required, it will be explicitly stated.

[0109] Coverage topology can be associated with a region, referred to here as a coverage topology region. A coverage topology region can correspond to one or more cells, RAN notification areas (RNA), tracking areas (TA), public land mobile networks (PLMN), etc.

[0110] Coverage topology can be defined at different granularities. The granularity of the coverage topology can be part of the coverage topology configuration. In one embodiment, the coverage topology can be defined at the cell level, and geographical coverage information from different gNB / TRPs can be indicated to the WTRU via (e.g., appropriate) signaling. Cell-level coverage can be useful for different handover and cell change procedures.

[0111] Coverage topology granularity can be reflected in the form of coverage partitions. For cell-level procedures, coverage topology partitions can have cell-level granularity. For beam-level procedures (e.g., WTRUs may need to track, maintain, or switch beams), coverage topology granularity can be defined at the beam level, and partitions in such coverage topologies can belong to different beams.

[0112] Partitions can be assigned to a given beam from a given TRP. Further granularity can be achieved by defining and associating partitions in different directions from each gNB or TRP. Partitions in the coverage topology can indicate geographical areas corresponding to a given set of reference signals. For beam-level partitioning, in one design, each partition can indicate the coverage area for synchronization signals and Physical Broadcast Control Channel Block (SSB) beams. In another beam-level partitioning design, each partition can indicate the coverage area for SSB beams or Channel State Information Reference Signal (CSI-RS) beams, where the SSB / CSI-RS beams are used for coverage of the corresponding SSB / CSI-RS signals. Configurations can specify one-to-one or one-to-many correspondences, where one-to-many correspondences can exist when the reference used for partitioning is not an SSB but other signals or GPS coordinates. One-to-many correspondences can also exist in overlapping networks, where multiple cells / beams can serve overlapping areas.

[0113] Each partition can be identified using an identifier that can be provided as part of the configuration. In another design, each partition identifier can be a decisive combination of its home cell, TRP, and SSB / CSI-RS beam identifiers. The formulas for calculating partition identifiers can be known in advance to the network and devices, and they can use additional modulation parameters, such as length, width, number of SSB beams, etc., which can be part of system information or configuration.

[0114] Different granularities for partitioning can be gNB, TRP, or cell level. For cell-level partitioning, the partition can indicate an area where the cell has sufficient coverage. The reference for sufficient coverage can be specified based on existing cell selection, reselection references, or a new reference associated with (e.g., a suitable) reference signal. Cell-level partitioning can combine all SSB / CSI-RS partitions associated with a given cell, thus representing the area where any SSB / CSI-RS signal for that cell can be received with known / configured quality. In the same way, partitioning representation can be extended to larger granularities for RNA, Tracking Area (TA), or PLMN-based coverage partitioning. Cell-level partition identifiers can be cell identifiers or cell identifiers that are deterministically modified by combining them with some other parameters. The same design can be used to represent partitions for coverage of RNA, TA, PLMN, etc.

[0115] In this embodiment, partitions can be defined for each location using longitude and latitude values. Partition length information can be provided as part of the configuration. The formula for calculating partitions can be predefined or can be signaled as part of a configuration from a predefined set. The partition design can facilitate the calculation of partition identifiers. For the partition design, the longitude and latitude values ​​are the geodetic distances to geographic coordinates (0,0), as used in the NR-side walkway frame. (For example, suitable) parameters can be provided as part of the configuration to determine the partition modularity along the longitude and latitude directions. A single parameter can be used to determine the same modularity along the longitude and latitude directions. This parameter can be a fixed value to simplify configuration. In this design, all devices can calculate their partitions and the partition for any location (based on the longitude and latitude coordinates of that location).

[0116] Examples of deployment topologies can include information about TRP location and beam coverage / orientation. In one example, the TRP location can be represented using 2D coordinates, such as latitude and longitude. Location can also be represented using 3D coordinates, which are 2D coordinates with added altitude or elevation. Both 2D and 3D representations can be in global or local coordinate systems. If the partitioned configuration follows a sidelink design, the TRP location can be provided based on the partition, rather than on latitude and longitude coordinates.

[0117] A beam from a given TRP can be represented using azimuth and elevation angles. Suitable references, such as a base direction and zenith direction, can be used, or reference directions can be provided as part of the configuration. For a given beam, these angles can be refined or quantized to meaningfully capture mobility processes and signal strength within or outside the coverage area. In addition to the angles, beamwidths in these directions can also be explicitly provided for the beam.

[0118] The network can be configured directly in richly shaped forms that capture all specific aspects of the local topography, shadows cast by buildings and other objects. One advantage of this approach is that the network not only has precise knowledge of its cell / TRP and beam deployment, but it can also access terrain data through navigation systems, cameras, and continuous measurements of cells / beams from the devices, giving it a very precise coverage topology. Another advantage is the use of all historical data with network measurements and cell / beam transformation patterns, which can be used to update and refine such detailed coverage topology. This approach can have (e.g., large) signaling overhead. The amount of information that needs to be exchanged can be enormous, as even precise coverage for a single beam may require a set of objects and their attributes to be passed to the WTRU. Large signaling overhead may require multiple message exchanges at the RRC level, also leading to increased configuration latency.

[0119] If the partition configuration follows a sidelink design, the network can provide coverage indications for different cells and beams, which in turn provide the association between these cells and beams and the partition.

[0120] Topology configuration can be a hybrid of two earlier approaches, where some parts can be indicated in the form of a network deployment-based configuration, while other parts can be indicated using a coverage topology-based configuration.

[0121] In this embodiment, the initial configuration for the coverage topology can be communicated to the WTRU in the form of dedicated RRC signaling. WTRUs in a mobile RRC active state can be provided with the initial coverage topology configuration. From the WTRU's perspective, the signaling may be dedicated, but the network may provide the same information to a group of WTRUs. These WTRUs may be adjacent to each other, and therefore the same coverage topology may be associated with them.

[0122] In this embodiment, the network (e.g., a base station) may broadcast coverage topology information. A new Coverage Topology System Information Block (SIB) may be specified. It is understood that, in this case, the coverage topology information broadcast by a cell or TRP can be configured to reflect the local deployment environment of the cell or TRP broadcasting the coverage topology.

[0123] In many relevant scenarios, the initial configuration may provide a coarse coverage topology, which may need to be refined (e.g., appropriately) to a finer granularity and coverage extension to be fully useful. For this purpose, the coverage topology can be appropriately refined via dedicated signaling. Refinement can be initiated when the network is configured with certain applications / flows that have QoS constraints and require active mobility. WTRUs can request refinement of their coverage topology.

[0124] The network deployment topology can be shared with the WTRU according to the configurations described above, either by adding additional attributes to the cell configuration or by introducing a new configuration with these geographic attributes and providing a link between these TRP / beam-level configurations and the traditional cell configuration. For use in mobility events and efficient selection of beams, cells, and TRPs, the WTRU may require a detailed and effective coverage topology, which we can call a field coverage topology. One remaining question is how to make the deployment topology rich enough to capture all terrain and shading aspects. This coverage topology should not only consider TRP locations and beam attributes but also the physical properties of the surrounding environment, including details of the topography and buildings with all possible physical attributes that could obstruct, block, or reflect beams.

[0125] Two implementation examples are presented below, which enable WTRU to acquire / build field coverage topology.

[0126] In the first embodiment, the deployment configuration provided by the network can be very rich and detailed, offered in a variety of shapes that capture all specific aspects of the local topography, shadows from buildings and other objects. Different reference shapes can be defined to indicate the shapes defining cell / beam-level coverage. These reference shapes can be, for example, circles, ovals, ellipses, ellipsoids, etc., parametrically assigned (e.g., suitable) shapes. The network then indicates these shapes with (e.g., suitable) attributes and provides links to them with cell / beam identifiers. One advantage of this approach is that the network can (e.g., accurately / precisely) know its cell / TRP and beam deployment. It can access terrain data using navigation systems, cameras, and continuous measurements of cells / beams from the devices, giving it a very precise knowledge of the coverage topology. Another advantage is the use of all historical data with network measurements and cell / beam transformations, which can be used to update and refine such detailed coverage topologies. This approach can have (e.g., large) signaling overhead. The amount of information that needs to be exchanged can be enormous, as even precise coverage of a single beam may require a set of objects and their attributes to be passed to the WTRU. (For example, large) signaling overhead may require multiple message exchanges at the RRC level, which also leads to increased configuration latency.

[0127] In the second embodiment, the network can provide the WTRU with a snapshot of its node deployment and limited information about the beams it transmits. Therefore, this approach can (e.g., primarily) be used when the network provides its deployment configuration. In the second embodiment, the network can provide information about any of the TRP location, beam angle, and beam-specific parameters without modulating coverage based on the characteristics of the local terrain. Because of the limited information compared to the first embodiment where the network provides detailed coverage topology, this approach may offer significantly better signaling overhead and latency performance.

[0128] In this second embodiment, the device may acquire deployment features / parameters for the TRP / beam and use local knowledge obtained through other technologies (locally stored terrain, positioning systems, cameras) to prepare a refined coverage topology that incorporates terrain aspects into the deployment configuration. After local processing and construction, the WTRU can obtain an effective topology that defines different coverage zones associated with different beams and cells. This refined coverage topology can then be used for beam and cell-level mobility procedures at the WTRU. This local physical coverage topology can be refined using mobility or additional information obtained from other sensors. Since the device can use deployment parameters provided by the network combined with information from local sensors to prepare such an effective topology, this may require support from local sensors, additional storage, and computing power to prepare an effective topology by combining network deployment with information from local sensors.

[0129] Hybrid solutions can be standardized to obtain granular coverage topologies at the device level. If devices lack local sensors or the computing power to process and build their own topologies, the network can send granular topologies to such devices. Conversely, devices with local sensors and computing / storage capabilities can receive only limited deployment characteristics from the network and prepare effective topologies locally. Hybrid solutions can also be used based on WTRU power requirements, battery quality, remaining battery capacity, or based on active applications and their attributes.

[0130] When a change in coverage topology is detected, the WTRU can reacquire the coverage topology for its current location. Reacquisition can take the form of dedicated RRC signaling. In another design, it can be achieved by reacquiring the coverage topology SIB. WTRU detection of a change in coverage topology can include one or more of the following: a change of serving cell or (re)selection to a cell that does not belong to the current coverage topology; (re)selection to an RNA that does not belong to or correspond to the current coverage topology; performing an RNA update procedure or sending an RNA update message to the network (e.g., a base station); (re)selection to a TA that does not belong to or whose topology does not correspond to the current coverage topology; performing a TA update procedure or sending a TA update message to the network (core network); and (re)selection to a PLMN that does not belong to or whose topology does not correspond to the current coverage topology.

[0131] If coverage topology configuration information becomes outdated, the WTRU can discard it. The obsolescence indication can be determined if the WTRU changes its coverage area and cannot obtain an updated coverage topology. In embodiments, the configuration may include (e.g., explicit) timers that, if they expire, cause the WTRU to release the configuration. These timers can be refreshed if the WTRU remains in an area associated with its current coverage topology. The coverage topology area can be defined based on RNA, TA, PLMN, or other (e.g., suitable) benchmarks. The WTRU can receive (e.g., explicit) indications from the network to release its coverage topology configuration. The WTRU can release its coverage topology configuration if it exits RRC activity.

[0132] The following three embodiments relate to deployment topologies that can be provided to WTRUs, and to cell / beam configurations and mobility configurations with deployment configurations.

[0133] In the first embodiment, the deployment topology can be part of a cell / beam configuration. This cell / beam configuration can be part of a conditional (re)configuration associated with a PsCell or SCell, and thus can be part of a conditional handover or conditional PSCell change / addition process. The deployment topology can be associated with any serving cell configuration and can be used in any beam management process, i.e., beam handover, beam failure recovery, etc. New attributes can be added to the cell configuration, which can define the TRPs that perform transmissions in that cell, the locations of these TRPs in the global or local coordinate system, and the beam coverage attributes for the beams used for transmissions through these TRPs. The configuration can provide information about SSB beams or CSI-RS beams. Attributes for the beam can be a shape with azimuth and elevation angles having (e.g., a suitable) reference direction. The reference direction can be obtained from a basic direction or can be indicated as part of the configuration itself. The range for the beam can be indicated per beam attribute or as a single value that indicates unobstructed range taking into account transmit power. Beam attributes can define the beam width in the horizontal and vertical directions. (For example, a simpler deployment could specify a single beamwidth attribute for the horizontal direction and a single beamwidth attribute for the vertical direction, assuming these are the same for all configured beams.) For deployments with different beamwidth sizes, the network could provide a value for the TRP and then provide a delta value for each beam. Alternatively, the beamwidth could be provided as part of the beam configuration without any TRP or cell-level indication. In another alternative, the coverage for each beam could be specified as an ellipsoid using (for example, a suitable) parameterized parameter.

[0134] In the second embodiment, the topology indication can be a separate, dedicated configuration. More specifically, in the second embodiment, the topology can be provided to the WTRU as a separate configuration. The coverage topology configuration may not be part of the cell configuration or conditional (re)configuration. The coverage topology may depend on geographic deployment and coverage, but its configuration and signaling can be provided by the network independently of cell configuration or other conditional (re)configuration.

[0135] Coverage topology configuration can be a form of network node deployment and beam attributes, or it can be a form of detailed on-site coverage that incorporates specific terrain and topographic features. Coverage / deployment topology configuration can provide links between the indicated TRP locations and beam attributes and cell identifiers and cell configurations.

[0136] In the third embodiment, the deployment / coverage topology indication can be sent by the network in the form of broadcast signaling. This indication can be broadcast by the network, and relevant devices can be informed in advance or have prior knowledge of how to acquire and decode the indication. In one strategy, control information for locating topology-related broadcast information can be broadcast (e.g., via special paging or special downlink control information) to notify all devices about broadcast-based topology information.

[0137] Topology indications can be considered part of system information. New System Information Blocks (SIBs) can be designed to carry and communicate deployment / overlay topology indications. The network can use periodic transmissions of topology SIBs to keep WTRUs aware of the topology information. WTRUs that are initiating relevant services that require minimal disruption can send (e.g., explicitly) request messages to the network to request the transmission of the topology SIB.

[0138] The network can provide multiple deployment / coverage topology snapshots via RRC signaling (whether broadcast-based or WTRU-specific). In these cases, the network can send a MAC control element (MAC-CE) that indicates one of the deployment / coverage topology snapshots, which can be considered the active topology and used in the LTM process. A custom MAC-CE can be designed for this purpose, where the topology identifier provides a pointer to one of the topologies configured via RRC signaling.

[0139] For more reactive scenarios, physical (PHY) based signaling, such as DCI, can be used to activate one of the configured topologies.

[0140] D Low-level triggered mobility aims to change cells, whether it is the primary cell of a primary cell group, the primary cell of a secondary cell group, or any serving cell in either a primary or secondary cell group. The target LTM configuration can be (e.g., essentially) a cell configuration. In one embodiment, the LTM configuration can be provided as part of the cell group configuration via the "CellGroupConfig" information element. In another embodiment, the LTM configuration can be provided via "SpCellConfig" or "SCellConfig," although this imposes some limitations on the range of LTM mobility.

[0141] An important point involves WTRU monitoring and evaluating (e.g., certain) LTM measurements, and events can be triggered when (e.g., certain) conditions are met. Details regarding LTM measurements and example events are provided below. These events can be associated with certain LTM configurations, and triggering such events subsequently leads to the WTRU applying the linked LTM candidate configurations to achieve mobility with zero or minimal disruption and heavy switching with the network. These processes are explained below.

[0142] One of the initial goals of LTM might be to leverage the knowledge and overlap of configurations used for cells deployed through the same Distributed Unit (DU) or through different DUs. With dense networks using access points serving smaller areas via narrow beams and the rollout of LTM features, the WTRU may potentially have multiple LTM configurations configured in addition to the already supported higher-level configurations. The advantage of supporting many LTM configurations is that the WTRU can perform LTM handovers to LTM candidates for one of these configurations more quickly. The disadvantage is that the network needs to provide all these configurations to the WTRU, which can consume transmission resources. Furthermore, the WTRU may need to keep all these configurations available locally for application during LTM handover and needs to measure the configuration candidates and report them to the network.

[0143] The following are several embodiments that can be used to configure how to provide services from the network to WTRUs and how they are maintained at the WTRUs.

[0144] In the first embodiment, the network can provide a separate configuration for each LTM candidate at the cell and beam granularity. This incurs (e.g., significant) overhead in terms of transmission resources and the maintenance of separate configurations by the WTRU.

[0145] In the second embodiment, the network can provide a separate configuration for each LTM candidate cell. This configuration can be linked to different beams of the candidate cell. These beams can be identified by an SSB index, a CSI-RS index, or a TCI state representing the QCL relationship with the reference signal.

[0146] In the third embodiment, the cell configuration for each LTM candidate cell is provided as a differential configuration relative to (e.g., a suitable) reference configuration. This cell configuration can then be applied to the configured beam / TCI state of the candidate cell.

[0147] (For example, a suitable) reference configuration (for which differential configurations are provided) could be the primary serving cell. In the case of dual connectivity, the reference configuration could be the primary serving cell of the corresponding cell group.

[0148] In different embodiments, a reference configuration can be explicitly provided to the WTRU. The network can consider the serving DU or neighboring DUs to determine the configuration that best minimizes the size of the differential configuration and the overhead.

[0149] In another embodiment, to minimize signaling overhead, the network may indicate (e.g., appropriately) a reference configuration as part of the LTM differential candidate configuration. As an example, the network may provide an LTM configuration for cell C1 as the differential configuration. In the differential configuration for C1, a pointer may indicate a reference configuration to be used as the reference configuration for candidate C1. The network may appropriately select this reference configuration, for example, by providing a reference to one of the cell configurations already provided to the WTRU, which may be a cell configuration on the same DU. If the WTRU does not receive any cell configuration on the same DU as candidate C1, the network may provide a pointer to a cell configuration on a different DU.

[0150] In an embodiment, the network may provide reference DU configurations associated with DUs, for which it intends to provide LTM handover candidates. Identifiers for these DUs may be provided as part of these reference configurations in (e.g., a suitable) format. Differential configurations may be provided as differential configurations on top of the reference DU configurations. This can be achieved by indicating the reference DU configuration identifier and each candidate differential configuration.

[0151] For embodiments with reference and differential configurations, whenever the WTRU performs an LTM switch, it applies the complete configuration jointly determined from the reference configuration and the differential configuration used for LTM candidates. In the event of a conflict / overlap, the WTRU may prioritize the configuration values / parameters provided as part of the differential configuration.

[0152] The following describes an example of LTM configuration activation for LTM based on non-radio measurements.

[0153] A WTRU can receive multiple LTM configurations from the network. Depending on application requirements, WTRU mobility level, WTRU's ability to support simultaneous LTM configurations, WTRU subscription level, and other network-level considerations, the network may activate (e.g., only) a subset of the configured LTM configurations. In these cases, the network can send a MAC-CE that can activate (e.g., the appropriate) LTM configuration. Two different MAC-CEs can be designed to accommodate different numbers of LTM configurations that may need to be activated for the final LTM process. A custom MAC-CE can be designed for this purpose, where the identifier of the LTM configuration provides a pointer to the LTM configuration configured via RRC signaling.

[0154] For more reactive scenarios, one of the configured LTM configurations can be activated using PHY-based signaling (such as DCI).

[0155] One aspect of LTM based on non-radio measurements is that the WTRU may perform very few radio measurements on the active LTM configuration, and in some cases, the network can be configured with non-radio measurements such that, from the WTRU's perspective, the measurement overhead is zero regardless of whether one or more LTM configurations are in an ACTIVATED state. For a non-radio measurement-based LTM procedure, all configured LTM configurations can be considered as the active LTM configuration for the final handover when an LTM handover command is received from the network.

[0156] Figure 5 A flowchart illustrating an example of updating WTRU coverage information and LTM configuration is provided.

[0157] More specifically, according to step 510, the network can provide the initial configuration of LTM candidate cells / beams to the WTRU in the RRC_Connected state.

[0158] However, prior to receiving the initial configuration, in step 515, the WTRU may send initial mobility assistance information to the network. This initial mobility assistance information may include radio and non-radio measurements. In step 520, the network may provide the WTRU with initial coverage information, which may be appropriate for the WTRU's geographic location and network deployment. In step 525, the network may also provide an initial mobility configuration, more specifically relating to L1L2 triggered mobility (LTM). The initial LTM configuration may consist of (e.g., suitable) LTM configurations that can be triggered at L1L2. The selection of LTM configuration candidates may depend on the WTRU's LTM mobility capabilities indicated to the network, the WTRU's mobility requirements (QoS / QoE) for active services / applications, WTRU non-radio measurements (such as geographic coordinates and orientation), and network dynamics (e.g., cell load, active traffic with different QoS levels, subscription levels, differentiated services, etc.). The network may provide an initial configuration of LTM candidates to a given WTRU based on the previously mentioned aspects.

[0159] However, if the WTRU moves from its previously reported location to a new location that may have a different set of LTM candidate configurations, the initial configuration associated with coverage information and LTM candidates may no longer be appropriate.

[0160] Therefore, referring to step 530, the WTRU can, for example, monitor the configured non-radio measurements, and referring to step 535, the WTRU can decide to report its measurement results, for example, by considering whether the value of the non-radio measurement has changed over time. If it decides to report the measurement results, referring to step 540, the WTRU can report the measurement results corresponding to the configured non-radio measurements to the network.

[0161] Therefore, referring to step 545, if the reported measurements (for both radio and non-radio measurements) from the WTRU change, rendering the previously configured LTM candidate unsuitable, the network can update the configuration. The update process may include steps 550 (corresponding to updating network coverage information) and 555 (corresponding to updating the LTM candidate configuration). The update may be a differential addition / removal of the previously provided configuration. In some cases, the network may decide to provide a new configuration.

[0162] Although not in Figure 5 As shown, the network can decide to update its configuration without explicit reporting from the WTRU. One scenario is that the network can estimate changes in the WTRU's location / positioning through uplink signals. These uplink signals can be WTRU uplink transmissions (such as PUSCH, Physical Uplink Control Channel (PUCCH)) or some reference signals (such as probe reference signals).

[0163] In another supplementary embodiment, the network can decide to update the LTM configuration independently of WTRU reports. This update can be performed without any reports from WTRUs, or if there are WTRU reports indicating no change in WTRU location / positioning, etc. Network updates can be triggered if network dynamics change in terms of active services and active devices. This may result in some previously configured LTM candidates lacking resources to support incoming WTRUs through the LTM process; therefore, the network can remove some previously configured LTM candidates and provide additional LTM candidate configurations to the WTRUs.

[0164] A key component of the various embodiments presented herein is radio measurements, non-radio measurements, and combinations thereof, which can be used for low-level mobility procedures. The mobility procedures of interest are those for L1L2 triggered mobility (LTM). The measurement framework, configuration, quantities, and reporting mechanisms presented herein can be used to provide measurement reports to the network, which can then potentially combine these with other network / device information for network-controlled and network-triggered mobility procedures. In these procedures, the network can send commands to the target WTRU to perform an LTM handover to a given target cell / beam, where the target cell / beam can be broadcast by the network (compared to the current serving cell / beam) from the same DU (intra-DU scenario) or different DUs (inter-DU scenario). In addition to the network-commanded LTM cell / beam handover, the LTM measurement framework can also enable the configuration of LTM measurements, triggers, and execution conditions, which can be used to trigger WTRU-managed LTM mobility to the target cell / beam. These cells / beams can be pre-configured by the network along with execution conditions (as presented in this framework) for (e.g., appropriate) measurement quantities.

[0165] One aspect of LTM-related measurements is that these are primarily low-layer measurements, where processing, necessary filtering (if configured), and reporting occur at the lower layers. These lower layers include Layer 1 and Layer 2. The primary role of Layer 3 (the RRC layer of the radio protocol stack) may be to provide configuration for the lower layers (e.g., the PHY and MAC layers), which can then perform measurements and processing based on the configuration received via RRC. Some processes may involve some involvement from Layer 3 (the RRC layer of the protocol stack), but this will be explicitly mentioned whenever this is the case.

[0166] The equipment may be equipped with interfaces from non-3GPP RATs, local sensors, or may acquire environmental information and quantities from certain aggregation points. The use of these quantities and their integration with measurements on 3GPP standardized RATs may require a unified framework, where the WTRU can use data from non-3GPP RATs, either alone or in conjunction with 3GPP RAT data / measurements. The following sections aim to provide a framework through which measurements or data quantities from non-3GPP RATs / sensors can be used in beamforming and cell remapping processes.

[0167] While the measurement framework for 3GPP radio signals, non-3GPP radio signals, and local sensors is primarily discussed within the context of low-layer mobility, it is applicable to a variety of processes / scenarios. Measurements and events can be used to adjust certain aspects of low-layer processes, such as channel state information feedback. Measurements can be used to initiate monitoring of specific frequencies, cells, TRPs, or beams when certain events are triggered. Applicability can also be directly applied to higher-layer processes such as classic handover, conditional handover, conditional PSCell changes / additions, etc.

[0168] The WTRU can provide indications of its ability to perform PHY layer measurements, which are performed on both radio and non-radio signals / sources. This capability can be initiated by the WTRU itself when it attaches to a network or enters RRC state, etc. The network can also (e.g., explicitly) request the WTRU's ability to perform PHY layer LTM measurements, and the WTRU can respond with its capability indications.

[0169] Some relevant PHY layer measurements used in the LTM process can be quantities calculated on the reference signal. The most important are the (auxiliary) synchronization sequence (SS), channel state information reference signal (CSI-RS), positioning reference signal (PRS), and sounding reference signal (SRS). Definitions for resource and reference antenna connectors can be similar to those defined in 3GPP 38.215 for calculating reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-noise plus interference ratio (SINR), and received signal strength indicator (RSSI).

[0170] Regarding 3GPP radio quantity measurements: The following are quantities that the WTRU can measure at the PHY layer and can indicate its capabilities in these quantities, the number of measurements at the same and different frequencies, the number of frequencies / bands it can support for simultaneous measurements, etc. These quantities can be estimated (e.g., primarily) on SSB, CSI-RS, PRS, and SRS. These quantities can be any of the following: SS reference signal received power (SS-RSRP), CSI reference signal received power (CSI-RSRP), SS reference signal received quality (SS-RSRQ), CSI reference signal received quality (CSI-RSRQ), SS signal-to-noise plus-interference ratio (SS-SINR), CSI signal-to-noise plus-interference ratio (CSI-SINR), SRS reference signal received power (SRS-RSRP), Received Signal Strength Indicator (RSSI), DL PRS reference signal received power (DL PRS-RSRP), DL reference signal time difference (DL RSTD), WTRU Rx-Tx time difference, and SS reference signal antenna relative phase (SS-RSARP).

[0171] Regarding measurements on non-3GPP radio signals: The WTRU can provide indications of its ability to measure and report certain non-3GPP signal quantities via other receivers available on the device. This may include, for example, GNSS, WLAN, and Bluetooth-related measurements. More specifically, this may include any of the following: GNSS code measurements: GNSS code phase (integer and fractional parts) of the spreading code of a GNSS satellite signal, provided by configuration or with reference power; GNSS carrier phase measurements: number of carrier phase cycles (integer and fractional parts) of a GNSS satellite signal, provided by configuration or with reference power; WLAN RSSI: IEEE 802.11 WLAN RSSI; Bluetooth signal power and source ID measurements; RF pattern recognition and matching based measurements; terrestrial beacon systems.

[0172] Regarding non-radio measurements available from local sensors: In addition to the measurements described above, the WTRU may have local sensors that can provide additional measurements. Some examples are motion sensors (e.g., accelerometers, gyroscopes), environmental sensors (e.g., barometers), position sensors (e.g., magnetometers, orientation sensors), and velocity measurement sensors. These sensors can provide any of the following measurements: linear acceleration or its variation, velocity or its variation, direction or its variation, angular velocity or its variation, atmospheric pressure or its variation, and magnetic field or its variation.

[0173] Some of these quantities can also be obtained through non-3GPP interfaces. WTRU capability indicators can provide information about the sensors, the measurements available through those sensors, and the potential accuracy of those measurements.

[0174] Regarding the combination of radio and non-radio measurements: Another class of measurements can be defined, which can be obtained by combining radio and non-radio measurements. An example might be the orientation of the WTRU relative to a reference TRP. The WTRU's own orientation can be defined in a suitable manner (e.g., the principal angle of its main antenna (or antenna array)) and can be obtained from local sensors. This can be known at the network or can be conveyed as part of capability exchange information. The WTRU's orientation relative to the reference TRP can be defined as the angle between the WTRU's own orientation and the line connecting the WTRU to the reference TRP. This determination can use various sources and methods. In one approach, the WTRU can use GPS signals processed by its local sensors (hardware / firmware / software), combined with the TRP's location provided over 3GPP radio signals via the network. In another approach, the WTRU can process the 3GPP radio signals transmitted by the TRP and determine the angle between the reference TRP and its antenna array's principal orientation angle or positive lateral angle by local estimation of these signals (such as angle of arrival). This determination can also utilize local sensors (such as magnetometers and other orientation sensors) in addition to the processing performed on the 3GPP radio signals. This information can be used at the WTRU along with its own orientation information to estimate the WTRU's orientation relative to the reference TRP. Such measurements can be retained as a subgroup of non-radio measurements.

[0175] For multi-panel WTRUs, a reference panel concept can be introduced on the WTRU side. This reference panel can be a panel with more antenna elements or better sensitivity, or a main antenna panel, or a panel with better connectivity to the WTRU Tx / Rx chain. For such WTRUs, this information can be shared with the network when the WTRU provides information about its antenna panel implementation.

[0176] For multi-TRP transmission scenarios, the concept of a reference TRP can be introduced to determine the purpose. The reference TRP can be the TRP of the DCI used for multi-TRP transmission based on a single DCI. For multi-TRP transmission based on multiple DCIs, the reference TRP can be the TRP identified by a smaller CORESETPoolIndex. In another design, the network can explicitly indicate the reference TRP. For WTRU-based selection, the WTRU can determine the TRP it receives through its reference antenna panel (in the case of multi-panel WTRUs). In yet another design, the reference TRP selection can be left to the WTRU, and the WTRU can provide an indication of the reference TRP to the network via (e.g., appropriate) signaling. For measurement configurations as part of 3GPP positioning and location services, the RRC can request the Location Management Function (LMF) to obtain positioning services for the target WTRU. The WTRU can be configured with reference signals and methods for positioning purposes, the results of which can be used for LTM-based procedures. In another compatible design, the RRC layer can be allowed to request the target WTRU to initiate location services to the LMF, and the LMF can then provide the RRC with information related to the positioning signals and procedures.

[0177] LTM measurements can be defined for each cell group. Therefore, in the case of dual connectivity, there can be one configuration for the primary cell group (MCG) and another for the secondary cell group (SCG).

[0178] LTM measurement configuration can be provided as part of the cell group configuration. This can be achieved by defining a new structure "LTM_meas_config" within "CellGroupConfig". Providing LTM measurement configuration within the cell group (CG) configuration has the advantage that the configuration does not need to be provided with each cell change.

[0179] LTM measurement configurations can be provided via RRC_Reconfiguration signaling. This allows one configuration to be associated with an MCG and another with an SCG. An added benefit is that the configurations can be maintained even if the cell group configuration is updated.

[0180] LTM measurement configuration can be embedded within the serving cell configuration (e.g., a portion thereof). The serving cell configuration provides the configuration for LTM measurements. This can be achieved by defining a new structure "LTM_meas_config" within "ServingCellConfig". The advantage of this is that each cell can be configured with associated LTM measurements. The disadvantage is that the serving cell configuration becomes larger, and updates to the serving cell configuration may result in higher overhead.

[0181] LTM measurement configuration can include the configuration of LTM measurement resources and LTM reporting configuration. Additionally, the configuration can include quantity configuration. Quantity configuration can provide low-level filtering, processing, or other measurement benchmarks applied to LTM measurements prior to reporting according to the reporting configuration.

[0182] LTM measurement configurations can provide a variety of LTM measurement resources and LTM measurement reporting configurations. This appears to pose (e.g., very high) overhead for the WTRU in terms of performing measurements, processing, and reporting to the network. In an embodiment, the WTRU may (e.g., only) perform measurements for activated LTM candidates. Activation can be achieved through explicit network configuration, conditional on radio or non-radio conditions, or through the expiration of certain timers.

[0183] Measurement resource sets can be associated with radio measurement resources that can be transmitted from 3GPP RATs (e.g., NG-RAN, EUTRAN, UTRAN, GPRS, GSM, etc.). These sources can be configured (e.g., appropriately) parameterized. These sources can be one or more SSBs, CSI-RS, PRS, SRS, or other reference signals designed for measurement purposes. In addition to resource identifiers, time-frequency resource mappings, subcarrier spacing (SCS), power control-related parameters, periods for periodic resources, cell identifiers associated with the measurement resources, and QCL information for the measurement resources can also be provided.

[0184] In addition to the parameters mentioned above, certain new parameters can be added to the measurement resource, which may be helpful to the LTM process. These may include DU identifiers or DU identifiers, CU identifiers or CU identifiers, TRP identifiers or identifiers, etc. These may be meaningful in certain situations where some aspects of the LTM process require the WTRU to know such information, and the WTRU is expected to take certain actions based on this information.

[0185] The reporting configuration can provide reporting attributes regarding the periodicity, semi-persistence, and aperiodicity of the configured measurement reporting.

[0186] Reporting configurations can provide resources for providing reports to the network. LTM reporting resources include PUCCH resources, PUSCH resources, or SRs sent to the network when reporting or triggering conditions are met. This can reduce latency because reporting can be configured to occur at the PHY layer or MAC layer as part of a MAC CE, which can be custom-designed to convey the reported configuration.

[0187] For certain scenarios and processes where delays may not be an issue or where the report size may be large, reporting can be based on RRC.

[0188] The reporting configuration can provide LTM triggers and execution conditions for measurements associated with a given reporting configuration.

[0189] The reporting configuration can provide a sub-selection of measurement resources based on (e.g., a suitable) benchmark. In a non-limiting example, the reporting configuration can instruct the reporting of the N strongest / largest quantities measured within the configured measurement period. In another compatible design, the reporting configuration can provide to report N maximum quantities if they exceed a configured threshold. The value of N can be configurable. In some cases, N can take values ​​of 1, 2, 3, or more. When N is configured to 1, only the strongest measurement among those performed on the configured resource is reported.

[0190] The LTM measurement framework can provide measurements for reporting purposes. The configuration of these measurements can provide additional processing and filtering that needs to be applied to the raw measurements before reporting. Processing can include thresholding, format-specific quantization, mapping to certain formats and bit ranges, etc. Filtering coefficients can be specified to achieve a certain level of noise or channel variation filtering. A non-limiting example of LTM aims to achieve seamless mobility over short time intervals, thus enabling or disabling filtering options through configuration. In another implementation, the filtering coefficients can have values ​​that allow them to be reported as raw measurements.

[0191] The configuration can provide 3GPP-based radio measurements, including SSB index-RSRP, SSB index-RSRQ, SSB index-SINR, CRI-RSRP, CRI-RSRQ, CRI-CQI, CRI-SINR, and PRS / SRS related quantities, as previously described.

[0192] In addition to 3GPP-based radio quantities, the configuration can also provide quantities for reporting and related post-processing / filtering of non-3GPP-based radio signals, as well as quantities that become available from local sensors and potentially other interfaces.

[0193] refer to Figure 6 This illustrates an example of an LTM measurement framework based on the reporting configuration. (Reference) Figure 6 In this embodiment, LTM measurements can use the identifier configured in the LTM reporting configuration. Figure 6 The LTM Meas Reporting ConfigurationIdentity (LTM measurement reporting configuration identifier) ​​= 'x' is used as the LTM measurement identifier. Then, the reporting configuration provides a pointer to the LTM measurement resource configuration ( Figure 6 In the LTM Meas Resource Configuration Identity (LTM Measurement Resource Configuration Identity = 'a') and LTM Quantity Configuration ( Figure 6The pointer to the LTM Meas Quantity Configuration Identity (LTM Measuring Quantity Configuration Identity) is 'b'. In this design, the LTM reporting configuration identity can be used to enable, disable, activate, deactivate, or trigger LTM measurements via DCI.

[0194] refer to Figure 7 This illustrates an example of an LTM measurement framework based on measurement identifiers. (Reference) Figure 7 In another embodiment, LTM measurement resources and LTM reporting can be configured separately. There is a separate LTM measurement identifier ( Figure 7 The LTM Measurement Identity (LTM Measurement Identifier) ​​'x' can provide two pointers. One pointer points to a set of LTM measurement resource identifiers ( Figure 7 In the LTM Meas Resource Configuration Identity = 'a', another pointer points to the LTM reporting configuration ( Figure 7 In this design, the reporting configuration identity (object) does not need to be unique, because the LTM measurement identity can link a given reporting configuration to different sets of measurement resources to generate multiple LTM measurements. The LTM measurement reporting configuration can provide another pointer (e.g., a suitable LTM measurement configuration) to... Figure 7 The pointer to `LTM Meas Quantity Config Identity` (LTM measurement configuration identifier = 'b') is used. In a minor variant, the parameters of the quantity configuration can be specified (e.g., directly) within the reporting configuration.

[0195] refer to Figure 8 This illustrates an example of an LTM measurement framework with combined reporting and quantity configurations. (Reference) Figure 8 In this embodiment, the LTM measurement can use the identifier configured in the LTM reporting as the LTM measurement identifier. Figure 8 The LTM MeasurementIdentity is set to 'x'. The reporting configuration can provide information related to reports and quantity configurations, and also provides an identifier pointing to the LTM measurement resource configuration. Figure 8 A list or set of pointers to LTM Meas Resource Configuration Identity (='a').

[0196] LMT measurements associated with LTM candidate configurations can be correlated with non-radio signals and events.

[0197] In an embodiment, the LTM measurement configuration can provide activation conditions for (e.g., suitable) non-radio signals. These non-radio signals can be specified as conditional events, with suitable definitions of thresholds and offsets required to determine these conditions. In an embodiment, activation of the LTM measurement configuration can be conditional on the event of a WTRU entering a specific partition.

[0198] In one embodiment, LTM measurement configuration activation can be conditional upon an event in which a WTRU device approaches a transmission point in the network deployment and its orientation aligns with that point. This activation condition can be achieved by evaluating the event.

[0199] In an embodiment, the deactivation condition may be specified as part of the LTM measurement configuration (e.g., explicitly). In an embodiment, the WTRU may deactivate the corresponding measurement configuration when the activation condition is not met. As a non-limiting example, if the activation condition is conditional on the WTRU entering a specific partition, if the WTRU exits the active partition, the WTRU may be configured to treat this as a deactivation condition and stop performing measurements for this configuration.

[0200] Activation and / or deactivation conditions for LTM measurement configuration can be specified as part of the reporting configuration.

[0201] In an embodiment, the activation condition may be specified as part of the measurement identifier.

[0202] In this embodiment, the activation condition may be specified as part of the resource identifier.

[0203] The LTM measurement framework can enhance measurements reported above on non-3GPP radio signals and non-radio quantities. Non-radio quantities can be measurements available through local sensors and other interfaces.

[0204] Non-3GPP-based radio measurements can have measurement resources defined for positioning and non-terrestrial network (NTN) ephemeris data. These can include measurements of signals originating from other radio technologies, such as GNSS, WLAN, Bluetooth, or WTRU, that may be able to measure and report.

[0205] The LTM measurement framework can be enhanced to allow reporting identifiers to provide reporting configurations for non-radio measurements. Reporting configurations can provide a combination of radio measurement resources (indicating their identifiers) and non-radio measurement quantities through parameterization (e.g., appropriately). Configurations can include only non-radio quantities, in which case the LTM report will only contain non-radio measurements. For non-radio measurements, the reporting configuration can provide information about the quantities that have events requiring evaluation, reporting, and use for decision-making to perform LTM switching or widespread use. These measurements can also indicate the type of filtering to be applied to these non-radio measurements through parameters configured (e.g., appropriately) by the quantities. Filtering operations can be specified using existing filtering mechanisms / coefficients for radio measurements, or new filtering procedures / coefficients can be provided for non-radio measurements.

[0206] Regarding measurements available from local sensors: In addition to the measurements mentioned above, the WTRU may have local sensors that can provide additional measurements. Some examples are gyroscopes, accelerometers, barometers, and velocity sensors, which can provide measurements such as velocity, acceleration, direction, atmospheric pressure, etc., which can be further processed to calculate more complex quantities. Some of these quantities can also be obtained through non-3GPP interfaces.

[0207] refer to Figure 9 For LTM measurements, a non-limiting example of a model for measurement, processing, and filtering is shown. L1 filtering can exist for WTRU implementation, specifying performance requirements. Beamcombining to the cell and filtering procedures can be specified by the RRC layer. L1 / L2 filter values ​​can be used to evaluate triggering conditions for LTM procedures or for reporting purposes.

[0208] refer to Figure 9 Point 'A' corresponds to a measurement (beam-specific sample) within the physical layer. The 'Layer 1 Filter' block in the WTRU implementation corresponds to the internal Layer 1 filtering of the input measured at point 'A'. The exact filtering is implementation-dependent. How the implementation actually performs the measurement (input A and Layer 1 filtering) within the physical layer is not subject to standard constraints.

[0209] Point 'A1' corresponds to a measurement (e.g., beam-specific measurement) reported by Layer 1 to Layer 3 after Layer 1 filtering. The beam combining / selection block corresponds to beam-specific measurement combining used to determine cell quality. The behavior of beam combining / selection is standardized, and the configuration of this module is provided by RRC signaling. The reporting cycle at point 'B' is equal to one measurement cycle at point 'A1'. Point 'B' corresponds to a measurement (e.g., cell quality) determined from the beam-specific measurements reported to Layer 3 after beam combining / selection.

[0210] The L1 / L2 filter block for cell quality corresponds to the filtering performed on the measurement provided at point 'B'. The behavior of the L1 / L2 filter can be configured by the network. The filtering reporting period at point 'C' is equal to one measurement period at point 'B'. Point 'C' corresponds to the measurement after processing by the L1 / L2 filter. The reporting rate is the same as the reporting rate at point 'B'. This measurement is used as input for evaluation of one or more reporting benchmarks.

[0211] The reporting benchmark evaluation block checks whether a measurement report is actually needed at point 'D'. The evaluation can be based on more than one measurement stream at reference point 'C', for example, comparing different measurements. This is described by input points 'C' and 'C1'. The WTRU can evaluate the reporting benchmark at least each time a new measurement result is reported at points 'C' and 'C1'. The reporting benchmark is standardized, and its configuration can be provided by RRC signaling (WTRU measurement). Point 'D' corresponds to the measurement report information (message) sent on the radio interface. For non-radio measurements, the network configuration can specify that they be filtered as additional inputs at point 'A' or point 'B'. In compatible designs, the network configuration can specify that non-radio measurements are included as additional inputs at 'C1', which effectively bypasses filtering.

[0212] The L1 / L2 beam filter block corresponds to the filtering performed on the measurement provided at point 'A1' (i.e., the beam-specific measurement). The behavior of the L1 / L2 beam filter can be part of the configuration. The filtering reporting period at point 'E' is equal to one measurement period at point 'A1'. Point 'E' corresponds to the measurement after processing by the beam filter (e.g., the beam-specific measurement). The reporting rate is the same as the reporting rate at point 'A1'. This measurement is used as input for selecting X measurements to be reported.

[0213] The beam selection block used for beam reporting selects X measurements from the measurements provided at point 'E'. The beam selection behavior is standardized, and the configuration of this module can be provided by RRC signaling. Point 'F' corresponds to the beam measurement information included in the measurement report (transmitted) on the radio interface.

[0214] LTM measurement configuration provides a framework through which the network can configure LTM measurements, including both radio and non-radio measurements. The configured measurements can be candidates for periodic, semi-persistent, aperiodic, or event-triggered reporting, as indicated in the "LTM Measurement Reporting Configuration." Once an event is triggered, it can in turn trigger reporting that meets the event criteria and perform the associated LTM handover to the target candidate cell / beam. These conditions, events, and thresholds can be part of the "LTM Measurement Reporting Configuration."

[0215] Although low-level configuration is primarily managed through the RRC layer, configured measurements (whether radio or non-radio based) can be conditionally configured to trigger certain LTM-related events at the PHY layer. In PHY-based evaluations, the PHY layer itself can perform configured post-processing and filtering after measurements are taken or acquired from other interfaces and local sensors.

[0216] A compatible design can perform condition evaluation to generate events and trigger certain processes at the MAC layer. In this design, the PHY layer can remain simple, and measurements can be passed to the MAC layer at configured intervals. Post-processing and filtering can be configured to be performed at the PHY or MAC layer, or partially at both. The MAC layer can evaluate conditions on the processed quantities and generate events. An additional advantage of this approach is that by disabling MAC processing / filtering, latency can be similar to PHY latency.

[0217] In a simpler approach, the configuration can specify only the filtering and post-processing to be performed periodically as specified / indicated. This filtering and post-processing can then be implemented in any of its layers by the WTRU implementation. In this case, the processing and timing availability of the final quantities used to evaluate the LTM triggers may become independent of which layer / block they are implemented in.

[0218] refer to Figure 10 In an embodiment, the LTM measurement framework can combine L1 and L3 filtered measurements, and LTM events can be configured to be evaluated on these L1 or L3 measurements or a combination of these measurements. This combination can be specified by the network and configured by the RRC layer. The LTM measurement model under the L1 / L3 measurement framework is... Figure 10 As shown in the image. Figure 10 The diagram illustrates the input from the L1 beamcombining measurement block to the LTM process / reporting evaluation block (thick black solid line), which also receives L3 filtering quantities from the Layer 3 filtering block used for cell quality. For this measurement model, event triggers and execution conditions may need to specify whether the quantity to be evaluated is L1 or L3.

[0219] refer to Figure 11 In this embodiment, L1 and L3 measurements can be combined prior to event evaluation. This is done in a bias block. The bias block can be configured with appropriate configuration parameters by which lower-layer measurements are biased with L3 filtered quantities. The bias block can be configured to apply bias to lower-layer measurements based on L3 filtered measurements according to the configuration parameters. The bias block can be modeled as a weighted combination of L1 and L3 measurements, where the weights can be provided as part of the configuration. In another example, the bias block can be viewed as a combination and filtering of input L1 and L3 quantities. In this way, the network can control the stable operating point for the biased measurements, which will then be used to evaluate execution conditions before triggering reporting and / or LTM cell handover procedures.

[0220] refer to Figure 12 In this embodiment, a unified model can be used for both L3 and LTM measurements. Two sets of configuration parameters can be provided for each block (e.g., beam combining / selection, L3 filtering for cell / beam quality, event assessment parameters (offset, hysteresis, etc.)). One set is used for L3 conventional measurements, and the second set is used for LTM-related measurement processing and event assessment / monitoring. It should be noted that, although not shown in the figure, candidate quantities include all radio and non-radio measurements as described above.

[0221] For all embodiments related to measurement processing, the network configuration can specify filtering for non-radio measurements. This can be achieved by adding non-radio measurements as additional inputs at point 'A' or point 'B'. In compatible designs, the network configuration can specify including non-radio measurements as additional 'C1' inputs, which effectively bypasses the filtering of these non-radio measurements.

[0222] For the various embodiments described herein, one (e.g., fundamental) theme may be network sharing of a portion of deployment / coverage information and WTRU configured with (e.g., appropriate) LTM measurements, including radio and non-radio quantities for a target cell / beam. The WTRU will monitor and evaluate the configured quantities and, upon triggering certain events, perform an LTM handover to a target candidate cell / beam where the configured conditions are met.

[0223] The reporting configuration can be extended to include new non-radio measurement-based events, where the WTRU will use data from local sensors. These events can utilize serving cells and serving beams (from the primary or secondary cell group), neighboring cells / beams, and deployment attributes of candidate cells / beams in the LTM configuration, as provided by the network configuration. This allows events to be created based on non-data measurements. These events can be combined with radio measurement-based events to verify the suitability of cells / beams for specific signal strengths, etc.

[0224] In embodiments, composite events can be designed where conditions are specified for both non-radio measurements (such as location / positioning, orientation, etc.) and radio measurements (such as RSRP / RSRQ / SINR associated with SSB or CSI-RS or some other reference signal), and these composite events are triggered when conditions from both radio and non-radio measurement groups are met. The triggering of these composite events can be used as triggers for performing certain WTRU procedures and actions. One objective of the various embodiments described herein is to primarily use events from LTM measurements (based on both radio and non-radio) to trigger LTM handover to a target cell / beam.

[0225] For certain LTM measurements, the configuration can provide the selection of parameters related to additional post-processing or filtering coefficients that can be applied to the original measurement. This post-processing or filtering can be configured for all LTM measurements, and therefore (e.g., fully) applicable to both radio and non-radio measurements. One goal of such filtering or post-processing might be to perform additional processing to make these measurements suitable for LTM procedures that may result in intra-DU cell / beam handovers, inter-DU cell / beam handovers, and inter-CU cell / beam handovers. The proposed measurement framework can be used for other cell / beam-level procedures.

[0226] In addition to post-processing or filtering, the LTM measurement framework can specify cell-level quantities derived from beam-level measurements. Parameters and thresholds used to determine cell-level quantities for reporting or event assessment purposes (when configured) from beam-level measurements can be specified as part of the "LTM Measurement Quantity configuration." (For example, a suitable "LTM Measurement Quantity configuration" can be indicated by its identifier from the "LTM Measurement Reporting Configuration." In embodiments, such mapping rules and associated parameters can be provided directly as part of the "LTM Measurement Reporting Configuration."

[0227] A WTRU configured with LTM measurements can monitor and evaluate events configured on (e.g., appropriate) non-radio measurements. Measurements with these event conditions set can follow the measurement model explained above. The above section provides a reference measurement model where event conditions can be set for: L1 measurements only; L3 measurements only; joint events on L1 and L3 measurements; and L1 measurements biased with L3 measurements.

[0228] For non-radio measurements, filtering can be specified individually, or these measurements can be configured to undergo one of the models described above. These processed / filtered non-radio measurements can then be fed into the event evaluation block.

[0229] The details of how these events are used in a particular process are explained in the various embodiments described herein. The following subsections describe some exemplary events relating to radio and non-radio measurements. The triggering conditions for the example events may use certain offset and hysteresis values, which may not always be desirable for LTM measurements, as a key aspect of the framework is its ability to react quickly to changes in channel conditions. In this regard, either such additional adjustment parameters, offsets, and hysteresis can be completely removed from the condition definition, or they can be assigned zero or some other value to achieve the desired delay advantage.

[0230] The following embodiments describe some example LTM events that use information from local sensors and / or non-3GPP interfaces. It should be noted that in some of these events, 3GPP radio signals can be used to improve the quality of the measurement. A prime example of such events would be those using location measurements, where the network can assist in improving estimation accuracy.

[0231] The embodiments presented below attempt to minimize mobility disruptions through low-level cell handover, where additional benefits and deterministic mobility aspects are gained by utilizing information data from non-3GPP radio signals. This category can combine non-3GPP radio signals with information data from local sensors, other interfaces, etc. Therefore, the defined events may become an important point in the proposed LTM process.

[0232] For LTM non-radio events LTM-V1 where the WTRU speed becomes greater than a predetermined threshold, the WTRU can: (1) It is assumed that the entry condition for this event is satisfied when condition V1-1 is satisfied, where condition V1-1 is: (Entry condition 1) (2) It is assumed that the exit condition for this event is satisfied when condition V1-2 is satisfied, where condition V1-2 is: (Leave Condition 1) The variables in the formula are defined as follows: It is the WTRU speed estimated by its local sensors, without taking any offset into account. It can be expressed in kilometers per hour. This is the hysteresis parameter used for this event (i.e., the hysteresis parameter used for this event). configuration Defined within (configuration) hysteresis (Lag) With The same units are used. This is the threshold used for this event, which is used in the event... configuration The internal velocity is defined as a reference velocity and used as the velocity threshold for entering this event. This is the threshold used for this event, which is used in the event... configuration The internal speed is defined as a reference speed and used as the speed threshold for exiting this event. and With The same units are used.

[0233] For LTM non-radio events LTM-R1 where the WTRU rotation amount exceeds a predetermined threshold, the WTRU can: (1) It is assumed that the entry condition for this event is satisfied when condition R1-1 is satisfied, where condition R1-1 is: (Entry condition 1) (2) It is assumed that the exit condition for this event is satisfied when condition R1-2 is satisfied; where condition R1-2 is: (Leave Condition 1) The variables in the formula are defined as follows: It is the rotation estimated by the WTRU through its local sensors, without considering any offset, and the rotation estimation is performed within a duration not exceeding the duration Td configured as part of the configuration. It can be expressed in degrees. In compatible design, It can be expressed in radians. In flexible solutions, The unit can be configured as part of the configuration.

[0234] This is the hysteresis parameter used for this event (i.e., the hysteresis parameter used for this event). configuration Internally defined hysteresis ). With The same units are used. This is the threshold used for this event, which is used in the event... configuration The inner value is defined as the reference rotation amount and is used as the rotation threshold for entering this event. This is the threshold used for this event, which is used in the event... configuration The inner value is defined as the reference rotation amount and is used as the rotation threshold to exit this event. and With The same units are used.

[0235] For an LTM non-radio event LTM-O1 in which the WTRU's orientation changes from the current direction greater than a predetermined threshold, the WTRU can: (1) It is assumed that the entry condition for this event is satisfied when condition O1-1 is satisfied, where condition O1-1 is: (Entry condition 1) (2) It is assumed that the exit condition for this event is satisfied when condition O1-2 is satisfied, where condition O1-2 is: (Leave Condition 1) The variables in the formula are defined as follows: It is the WTRU orientation change estimated by its local sensors, where no offset is taken into account, and the orientation estimation can be made within a duration not exceeding the duration Td configured as part of the configuration. It can be expressed in degrees. In compatible design, It can be expressed in radians. In flexible solutions, The unit can be configured as part of the configuration. This is the hysteresis parameter used for this event (e.g., in the hysteresis parameter used for this event). configuration Internally defined hysteresis ). With The same units are used. This is the threshold used for this event, which is used in the event... configuration The inner value is defined as the amount of change in the reference orientation and is used as the threshold for entering this event. Is with The same threshold is used as the rotation threshold to exit this event. and With The same units are used.

[0236] For LTM-OT1 non-radio events where the WTRU orientation matches the orientation of a given TRP / cell within a predetermined threshold, the conditions for this event can be used to evaluate whether the WTRU orientation is aligned with the given TRP within the configured threshold. The WTRU's own orientation can be defined in a suitable manner (e.g., the principal angle of its main antenna (or antenna array)) and can be obtained from local sensors. The WTRU's orientation relative to a reference TRP can be defined as the angle between its own orientation at the WTRU and the line connecting the WTRU to the reference TRP. This determination can use various sources and methods. In one approach, the WTRU can use GPS signals processed by its local sensors (hardware / firmware / software) in conjunction with the TRP location provided by the network. In another approach, the WTRU can process 3GPP radio signals transmitted by the TRP and determine the angle between the reference TRP and the principal orientation angle or positive lateral angle of its antenna array by local estimation of these signals (such as angle of arrival). This information can be used at the WTRU along with its own orientation information to estimate the WTRU's orientation relative to the reference TRP.

[0237] In this embodiment, the current event LTM-OT1 can be configured so that the network provides a reference location for evaluating the alignment of the WTRU orientation relative to that reference orientation. In this case, the network can ensure that the WTRU orientation is aligned relative to any reference orientation / direction, which can be independent of any deployment topology. The WTRU can: (1) It is assumed that the entry condition for this event is satisfied when condition OT1-1 is satisfied, where condition OT1-1 is: (Entry conditions), where the WTRU has the absolute orientation of the matched cell beam. (2) It is assumed that the exit condition for this event is satisfied when condition OT1-2 is satisfied, where condition OT1-2 is: (Leaving conditions) The variables in the formula are defined as follows: This is the WTRU orientation estimated by the WTRU using its local sensors, without considering any offset. The orientation estimation reference used for this event can be the TRP location or the RS (e.g., beam) of the target cell / TRP. Using the TRP location or a signal from the TRP as a reference aligns the orientation estimate to the given TRP. The reference TRP indication, location, and signal from the given TRP used as a reference are also provided as part of the network configuration. It can be expressed in degrees relative to the configured measurement reference. In compatible designs, It can be expressed in radians. In flexible solutions, The unit can be configured as part of the configuration. This is the hysteresis parameter used for the orientation condition of this event. With The same units are used. This is the threshold used for this event, which is used in the event... configuration The inner vector is defined as the reference vector and is used as the rotation threshold for entering this event. With The same units are used.

[0238] For LTM non-radio events LTM-OD1 where the WTRU orientation and distance match the location of a given TRP / cell coverage within a predetermined threshold, the WTRU can: (1) It is assumed that the entry condition for this event is satisfied when both condition OD1-1 and condition OD1-2 are satisfied, where condition OD1-1 is... (Entry condition 1), where the WTRU has the absolute orientation of the target cell beam; and where condition OD1-2 is (Entry condition 2), where the WTRU and the target TRP are within a suitable distance.

[0239] (2) It is assumed that the exit condition for this event is satisfied when either condition OD1-3 or condition OD1-4 is satisfied, where condition OD1-3 is... (Leaving condition 1); and among them, conditions OD1-4 are (Leave condition 2).

[0240] The variables in the formula are defined as follows: It is the WTRU location, represented by the distance between the WTRU and the reference location parameter used for this event (e.g., the reference location of the candidate TRP for this event), where no offset is considered. It can be expressed in meters. This is the WTRU orientation estimated by the WTRU using its local sensors, without considering any offset. The orientation estimation reference used for this event can be the RS (e.g., beam) of the target TRP. It can be expressed in degrees relative to the configured measurement reference. In compatible designs, It can be expressed in radians. In flexible solutions, The unit can be configured as part of the configuration. This is the hysteresis parameter used for the orientation condition of this event. With The same units are used. This is the hysteresis parameter used for the location conditions of this event. With The same units are used. This is the threshold used for this event, which is used in the event... configuration The inner vector is defined as the reference vector and is used as the rotation threshold for entering this event. With The same units are used. This is the threshold used for this event, which is in this event. configuration The inner distance is defined as the distance from the reference position. With The same units are used.

[0241] For LTM non-radio events LTM-OD2 where the WTRU orientation and distance better match the location covered by a given TRP / cell compared to the location of the serving TRP / cell according to configured thresholds, the WTRU can: (1) It is assumed that the entry condition for this event is satisfied when both condition OD2-1 and condition OD2-2 are satisfied, where condition OD2-1 is... (Entry condition 1), where the absolute orientation of the WTRU is more aligned with the target cell TRP than the serving cell TRP; and where condition OD2-2 is... (Entry condition 2), where the WTRU and the target TRP are within a suitable distance.

[0242] (2) It is assumed that the exit condition for this event is satisfied when either condition OD2-3 or condition OD2-4 is satisfied, where condition OD2-3 is... (Leaving condition 1); and where condition OD2-4 is (Leave condition 2).

[0243] The variables in the formula are defined as follows: It is the WTRU reference orientation estimated by the WTRU through its local sensors, expressed in absolute units, without taking any offset into account. It can be expressed in degrees relative to the configured measurement reference. In compatible designs, It can be expressed in radians. In flexible solutions, The unit can be configured as part of the configuration. It is the orientation of the service TRP relative to the WTRU, which is estimated by the WTRU using the service TRP location received in the configuration, and is expressed in absolute units. It is the orientation of the neighbor TRP relative to the WTRU, which is estimated by the WTRU using the neighbor TRP locations received in the configuration, and is expressed in absolute units. This is the hysteresis parameter used for the orientation condition of this event. , and With The same units are used. It is the distance between the WTRU location and the neighboring TRP location, where the neighboring TRP location is part of the configuration. It can be expressed in meters. It is the distance between the WTRU location and the service TRP location, where the service TRP location is part of the configuration. With The same units are used. This is the hysteresis parameter used for the distance condition in this event. With The same units are used.

[0244] For an LTM non-radio event LTM-CM1 where the WTRU is crossing the boundary of a specific partition in the coverage topology, the WTRU can: (1) It is assumed that the entry condition for this event is satisfied when condition CM1-1 is satisfied, where condition CM1-1 is: (Entry condition), where WTRU crosses the boundary in the coverage topology.

[0245] (2) It is assumed that the exit condition for this event is satisfied when condition CM1-2 is satisfied, where condition CM1-2 is: (Leave conditions).

[0246] The variables in the formula are defined as follows: It is the WTRU position, represented by the distance between the WTRU and the reference position parameter used for this event, without considering any offset. It can be expressed in meters. This is the hysteresis parameter used for this event (e.g., in the hysteresis parameter used for this event). reportConfigNR Internally defined hysteresis ). With The same units are used. This is the threshold used for this event, defined as the distance from the reference location (e.g., the serving TRP) to the coverage topology boundary. WTRU can determine this from the coverage topology based on its current location, the serving TRP location, and boundary definition information, according to its configuration. Boundary definitions can correspond to coverage of RNA, TA, PLMN, or even TRP coverage. Configuration can provide information about... It is the line-of-sight (LOS) distance (in this case, Is it the distance of the coverage boundary on the line connecting the service TRP and WTRU, or is it using information calculated differently? With The same units are used.

[0247] For LTM-CM2 non-radio events indicating that a WTRU is entering a specific zone, this event can be used to assess whether the WTRU has entered that zone. Zone identification can be provided to the WTRU through configuration. In an embodiment, the network can provide coordinates for the zone center, its shape, and the length defining the zone. The zone can be hexagonal, square, or rectangular. The network can provide center coordinates, one length parameter for a square zone, two length parameters for a rectangular zone, or more parameters for refining the shape of the zone. In an embodiment, the zone can represent a sidelink-style zone, which can be obtained through configuration processing of GPS coordinates. The network can provide the WTRU with the configuration for calculating the zone. The WTRU can acquire its position / location estimate through local sensors. WTRU position information can be assisted by radio or non-radio signals. The calculated position allows the WTRU to calculate its distance from the zone center and know the zone boundaries. The WTRU can then determine whether it has entered a particular zone.

[0248] In this embodiment, a partition may be associated with a network deployment or coverage. In this embodiment, the network may designate a deployed TRP as the partition center. Partition boundaries can be provided by selecting parameters that define a square, rectangular, or hexagonal shape by specifying relevant parameters.

[0249] In this embodiment, the network can associate the configured partition with effective coverage information such as its cells and TRPs, which can be obtained through past measurement reports from WTRUs, drive tests, etc.

[0250] WTRU can: (1) It is assumed that the entry condition for this event is satisfied when condition CM2-1 is satisfied, where condition CM2-1 is: (Entry conditions), where WTRU enters a specific partition in the coverage topology.

[0251] (2) It is assumed that the exit condition for this event is satisfied when condition CM2-2 is satisfied, where condition CM2-2 is: (Leave conditions).

[0252] The variables in the formula are defined as follows: This is the WTRU location, represented by the distance between the WTRU and the reference location parameter used for this event, without considering any offset. The reference location belongs to the specific partition associated with this event. It can be expressed in meters. This is the hysteresis parameter used for this event (e.g., in the hysteresis parameter used for this event). reportConfigNR Internally defined hysteresis ). With The same units are used. This is the threshold used for this event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference partition) to the coverage topology boundary. The WTRU can determine this from the coverage topology based on its current location, the reference gNB / TRP location, and boundary definition information, depending on its configuration. Boundary definitions can correspond to RNA, TA, PLMN coverage, or even gNB / TRP coverage. Configuration can provide information about... It is the LOS distance (in this case, Is it the distance of the coverage boundary on the line connecting the reference TRP and WTRU, or is it information calculated differently? The network can provide information that matches the partition configuration. Value. If the partition configuration is sufficient, the network can expect WTRU to determine the value of this threshold. With The same units are used.

[0253] For an LTM non-radio event LTM-CM2V1 (LTM-CM2&<M-V1) where a WTRU is entering a specific partition in the coverage topology and its velocity becomes greater than a predetermined threshold, LTM-CM2V1 can be used to conditionally trigger WTRU reporting for LTM handover based on non-radio measurements, in the form of location coordinates and velocity estimates. It can also be used to increase the periodicity of measurement and reporting for certain target neighbor candidates. This joint event can be set on both location estimates (obtainable through non-radio measurements) and velocity estimates (primarily non-radio measurements). In one configuration, this event can be specified only on non-radio measurements. Other configurations are possible where location estimates are obtained solely through radio measurements or through measurements of 3GPP radio signals, or through any or more combinations of the foregoing.

[0254] WTRU can: (1) It is assumed that the entry condition for this event is satisfied when both condition CM2V1-1 and condition CM2V1-2 are satisfied, where condition CM2V1-1 is... (Entry condition 1), where WTRU enters a specific partition in the coverage topology; and where condition CM2V1-2 is... (Entry condition 2) (2) It is assumed that the exit condition for this event is satisfied when either condition CM2V1-3 or CM2V1-4 is satisfied, where condition CM2V1-3 is... (Leave condition); and condition CM2V1-4 is (Leaving conditions) The variables in the formula are defined as follows: This is the WTRU location, represented by the distance between the WTRU and the reference location parameter used for this event, without considering any offset. The reference location may belong to a specific partition associated with this event. It can be expressed in meters. This is the hysteresis parameter used for this event (e.g., in the hysteresis parameter used for this event). reportConfigNR Internally defined hysteresis ), which is used for positional conditions. With The same units are used. This is the threshold used for this event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference partition) to the coverage topology boundary. The WTRU can determine this from the coverage topology based on its current location, the reference gNB / TRP location, and boundary definition information, depending on its configuration. Boundary definitions can correspond to coverage of RNA, TA, PLMN, or even gNB / TRP coverage. Configuration provides information about... It is the LOS distance (in this case, (Is it the distance of the coverage boundary on the line connecting the reference TRP and WTRU) or using information calculated differently. With The same units are used. It is the speed estimated by the WTRU using its local sensors, without taking any offset into account. It can be expressed in kilometers per hour. This is the hysteresis parameter used for this event (e.g., in the hysteresis parameter used for this event). configuration Internally defined hysteresis ), which is used for velocity condition evaluation. With The same units are used. This is the threshold used for this event, which is used in the event... configuration The internal speed is defined as a reference speed and used as the speed threshold for entering / exiting this event. In another design, two separate thresholds can be configured for the entry and exit conditions. With The same units are used.

[0255] For an LTM non-radio event LTM-CM2O1 (LTM-CM2&<M-OT1) where a WTRU is entering a specific partition in the coverage topology and its orientation matches the configured orientation within a predetermined threshold, LTM-CM2O1 can be used to trigger a WTRU report based on non-radio measurements, in the form of location coordinates providing partition entry information and orientation to a given TRP used for candidate configuration. It can also be used to increase the periodicity of measurements and reporting for certain target neighbor candidates.

[0256] This joint event can be set on both location estimation (obtainable via non-radio measurements) and orientation estimation (primarily non-radio measurements). Therefore, in one configuration, this event can be specified based solely on non-radio measurements. However, other configurations are possible where location estimation is obtained solely through radio measurements or through measurements of 3GPP radio signals, or through a combination of any or more of the aforementioned sets.

[0257] WTRU can: (1) It is assumed that the entry condition for this event is satisfied when both condition CM2O1-1 and condition CM2O1-2 are satisfied, where condition CM2O1-1 is... (Entry condition 1), where WTRU enters a specific partition in the coverage topology; and where condition CM2O1-2 is... (Entry condition 2) (2) It is assumed that the exit condition for this event is satisfied when either condition CM2O1-3 or CM2O1-4 is satisfied, where condition CM2O1-3 is... (Leaving condition), and among which condition CM2O1-4 is (Leave conditions).

[0258] The variables in the formula are defined as follows: This is the WTRU location, represented by the distance between the WTRU and the reference location parameter used for this event, without considering any offset. The reference location may belong to a specific partition associated with this event. It can be expressed in meters. This is the hysteresis parameter used for this event (e.g., in the hysteresis parameter used for this event). reportConfigNR Internally defined hysteresis ), which is used for positional conditions. With The same units are used. This is the threshold used for this event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference partition) to the coverage topology boundary. The WTRU can determine this from the coverage topology based on its current location, the reference gNB / TRP location, and boundary definition information, depending on its configuration. Boundary definitions can correspond to RNA, TA, PLMN coverage, or even gNB / TRP coverage. Configuration can provide information about... It is the LOS distance (in this case, (Is it the distance of the coverage boundary on the line connecting the reference TRP and WTRU) or using information calculated differently. With The same units are used. This is the WTRU orientation estimated by the WTRU using its local sensors, without considering any offset, where the orientation estimation is performed for a duration not exceeding the duration Td configured as part of the configuration. The orientation estimation reference used for this event can be one of the basic directions, the location (e.g., GPS coordinates) from the WTRU antenna (e.g., TRP location), or the RS (e.g., beam) of the target TRP. Therefore, the orientation estimation can provide a measure of how well the WTRU is aligned with a reference WTRU antenna (or antenna panel) relative to the reference location / orientation. Both the reference location / orientation used for orientation estimation and the reference WTRU antenna are part of the configuration. It can be expressed in degrees. In compatible design, It can be expressed in radians. In flexible solutions, The unit can be configured as part of the configuration. This is the hysteresis parameter used for this event (i.e., the hysteresis parameter used for this event). configuration Internally defined hysteresis ). With The same units are used. This is the threshold used for this event, which is used in the event... configuration The inner value is defined as the amount of change in the reference orientation and is used as the threshold for entering this event. With The same units are used.

[0259] The paragraphs above provide some example events based on non-radio measurements, which can be used to update LTM-related configurations, trigger reporting, and trigger network-controlled LTM handover decisions. These examples can be used to create additional events based on non-radio measurements that can very accurately identify target scenarios and select the most suitable candidates in intra-DU, inter-DU, and / or inter-CU scenarios.

[0260] In this embodiment, new events can be defined on a set of non-radio measurements. This can be advantageous when the environment is controlled or the network has comprehensive knowledge of the wireless environment in terms of terrain, buildings, and other objects.

[0261] For devices with heavy rotational mobility, event LTM-R1 or event LTM-O1 can be combined with other non-radio measurements to generate new events.

[0262] The examples provided above do not cover events that can be created based on signals, measurements, and identifiers related to WLAN, Bluetooth, other RATs, or certain RF measurements. These can be defined where network operators may have public deployments of such access points for other RATs or knowledge of certain reference locations for beacon transmissions or RF points. These measurements can then be combined with other non-radio signals to determine further refined events.

[0263] LTM mobility configuration and subsequent monitoring may require the WTRU to perform additional tracking of cells / beams that could be potential targets for LTM mobility—whether they are active or deactivated. LTM mobility characteristics may require the WTRU to have new capabilities in receiving and maintaining LTM configurations, handling LTM handover candidates within and between DUs, and, perhaps most importantly, monitoring and reporting LTM measurements related to non-radio measurements.

[0264] The WTRU capabilities associated with non-3GPP radio signals, local sensors, and other interfaces can be used in LTM procedures based on non-radio measurements. The WTRU can provide this capability to the network, and based on this knowledge, the network can identify a set of (e.g., suitable) non-radio measurements as part of LTM measurement and configuration. Some of these non-radio measurements can be used to trigger events that will cause reporting and subsequent cell handover. Other non-radio quantities can be part of the measurement report. The WTRU can provide the source of these non-3GPP RATs or local sensors or other interfaces, along with other relevant parameters such as availability and accuracy levels, to help the network determine the set of quantities (e.g., suitable) to use in the non-radio measurement-based LTM procedure.

[0265] The execution phase of an LTM procedure based on non-radio measurements may (e.g., essentially) include the WTRU monitoring and reporting based on non-radio measurements, the network deciding on a cell handover and issuing a cell handover command, and the WTRU performing the cell handover action.

[0266] Once configured, the WTRU can begin monitoring the configured measurements. In some cases, there may be an activation phase via a timer or explicit command. The LTM reporting configuration provides the parameters necessary for reporting LTM measurements to the network. Measurement reports of interest in this disclosure may include non-radio measurements configured by the network as part of the configuration. Events that form the basis of LTM cell handover procedures can be set / triggered based on non-radio measurements. However, when a reporting event is triggered, the network can be configured to provide measurement reports that include both radio and non-radio measurements.

[0267] LTM reporting configurations can be set up so that LTM measurements can be reported as part of uplink control information (UCI). In this design, LTM measurements are reported via PUCCH or PUSCH as specified in the LTM reporting configuration, which has (e.g., appropriate) parameters and periodicity.

[0268] LTM reporting configuration allows for the configuration of certain quantities, enabling LTM measurements to be reported as RRC messages. This design may be more suitable when latency is not an issue.

[0269] LTM reporting configuration can be provided as a hybrid reporting configuration. In a hybrid design, LTM measurement reporting can be partially configured to be sent via UCI (or used to trigger lower-layer events) through PUCCH / PUSCH and partially reported via RRC messages. In an embodiment, LTM reporting can be configured to be reported via RRC when certain conditions are met. If these conditions are not met, the WTRU can begin reporting LTM measurements as part of the UCI (PUCCH / PUSCH). The RRC configuration and UCI (PUCCH / PUSCH) configuration for reporting LTM measurements can be part of the LTM reporting configuration. The LTM reporting configuration also provides conditions that the WTRU can use to select a specific reporting type and switch to other reporting types. These conditions can be specified based on whether the WTRU enjoys good channel conditions with its serving cell / beam. When the serving cell / beam quality is better than a configured threshold, the WTRU can be configured to report LTM measurements via RRC. The associated delay may not be a problem because the WTRU is under good channel conditions. When channel conditions deteriorate, the WTRU can switch to more flexible lower-layer reporting based on conditions and thresholds provided as part of its configuration. In lower-layer reporting, the periodicity may be shorter and the resource overhead may be greater, but this is likely justified because the WTRU may face the risk of link degradation, and these measurements may enable rapid LTM handover to neighboring cells and beams.

[0270] For network-controlled LTM procedures, the network can determine when to switch a given WTRU from a serving cell (whether it is a serving cell in any of its cell groups or the primary cell) to one of the LTM target cells. The network can configure measurements to aid its decision-making. In addition to WTRU measurements and feedback, the network can also use other benchmarks and system-level aspects to make mobility decisions.

[0271] Once the network decides to move the WTRU from the serving cell to the target LTM cell, the network can provide the WTRU with a cell handover indication or command. The cell handover command can be provided to the WTRU along with necessary information to enable it to hand over to the target cell. The cell handover command includes the LTM target configuration and beam indication. The beam indication can be provided as an SSB index, CSI-RS index, or QCL identifier, where the QCL has been configured by the network at the WTRU to provide the reference signal to which this QCL is set. The beam indication can be explicit or implicit. The cell handover command can also provide indications about how to handle the WTRU's data and control plane during the cell handover. This indication can be provided as explicit, such as whether MAC / RLC entities need to be reset and whether PDCP needs to be restored. In another compatible design, the network can only indicate whether the cell handover is intra-DU or inter-DU, and the WTRU can be pre-programmed to perform MAC / RLC / PDCP processing based on the inter-DU / intra-DU indication. In one example, whenever the network sends an inter-DU indication, the MAC and RLC entities can be reset, and PDCP can perform data restoration. In the case of a DU, a reset or data recovery may not be initiated. The cell handover command can also indicate the type of signaling the WTRU should use on the target cell when performing a cell handover. For example, the cell handover command may provide whether the WTRU should transmit RACH, or certain specific PUCCHs, or certain other signals on the target cell. In embodiments, this information may be implicit based on other LTM target cell configuration parameters. These may include, for example, whether the target cell is already a serving cell or an active cell. The cell handover command can also provide timing advance in an explicit or implicit manner. For example, if the deployment is for a very small cell, the WTRU may not need to apply timing advance. This can be known from the configuration or explicitly indicated. In another example without timing advance, the target cell may have the same timing as the current serving cell, possibly within the tolerance of the cyclic prefix. In other cases, the network may (e.g., explicitly) indicate the timing advance value that the WTRU should apply when transmitting to the target cell in the uplink direction.

[0272] The network can transmit cell handover commands via MAC-CE. MAC-CE-based instructions have the advantage of providing other relevant information required for the cell handover command to the WTRU.

[0273] In this embodiment, cell handover commands can be provided via PHY signaling. This can be achieved by designing a downlink control indication (DCI) with (e.g., special) fields that can carry LTM cell handover command parameters as described above. PHY signaling can have lower latency and can further reduce mobility disruptions.

[0274] In embodiments (e.g., a hybrid design), the network can maintain a MAC and PHY-based design. Therefore, the WTRU is configured to receive LTM cell handover commands via MAC and PHY signaling. Depending on WTRU application requirements, WTRU non-radio measurement reports, and the availability of transmission opportunities, the network can determine whether to provide the LTM cell handover command to the WTRU in a timely manner using MAC or PHY signaling.

[0275] When the WTRU performs an LTM handover to an LTM target candidate, it applies the LTM target candidate's configuration. The two main use cases for LTM handover are when the handover occurs when a target cell / beam candidate is served by the same DU or by different DUs. Depending on whether the LTM handover is intra-DU or inter-DU, the WTRU may need to handle internal data plane entities, such as MAC entities, RLC entities, and PDCP, in different ways.

[0276] For LTM handover within a DU, WTRU can keep the MAC, RLC, and PDCP entities unchanged.

[0277] For LTM handover between DUs, the WTRU can reset its MAC and RLC entities and create new MAC and RLC entities based on the configuration of the target LTM candidate. For PDCP, if the RLC is reset, it may need to be re-established.

[0278] The behavior applied to MAC, RLC, and PDCP layer resets can be left to the WTRU to determine whether it is an intra-DU or inter-DU LTM handover. The WTRU can determine whether the LTM handover is intra-DU or inter-DU based on the configuration of the serving cell and its applied candidate LTM configuration.

[0279] In an embodiment, each LTM configuration can provide indications regarding whether a MAC and / or RLC entity needs to be reset and whether a PDCP recovery is required.

[0280] For LTM handover in network control, the LTM handover command can indicate to the WTRU whether the MAC and RLC entities need to be reset and whether PDCP recovery is required.

[0281] When the WTRU performs an LTM handover to an LTM target candidate, it may need to send an indication to the LTM target candidate so that both the WTRU and the LTM target candidate have knowledge of the cell / beam in which the WTRU is performing the LTM handover. The selection of the UL indication can be part of the LTM configuration.

[0282] For network-controlled LTM handover, the LTM handover command can instruct the WTRU which type of UL indication to transmit during an LTM handover event.

[0283] The following describes the design details regarding the uplink indication sent from the WTRU to the network during LTM handover.

[0284] In the indication embodiment based on Physical Random Access Channel (PRACH) transmission, the WTRU can perform the PRACH procedure to the LTM candidate cell / beam. A contention-free random access channel (RACH) configuration can be provided for the LTM candidate to accelerate the RACH procedure.

[0285] In a RACH preamble-based indication implementation, the WTRU may only perform the transmission of the RACH preamble. The preamble identifier and resources can be allocated to LTM candidate cells / beams. If the network already provides the necessary cell configuration, the entire RACH process may not be required. In this case, sending the RACH preamble only to the LTM target candidate can save transmission resources and accelerate attachment to the target candidate. This latency saving is significant because one objective of LTM may be to improve latency when cell / beam handover is required during mobility operations.

[0286] In a reference signal-based indication embodiment, the WTRU can be configured to transmit reference signals to the LTM target candidate cell / beam. These reference signals can be sounding reference signals (SRS). Configuration parameters for SRS transmission, including sequence, power, and time-frequency resources, can be provided to the WTRU as part of the LTM configuration. The source cell may have already communicated and coordinated the likelihood of such SRS transmissions and related parameters to the LTM target candidate, which may be an intra-DU or inter-DU handover. The LTM target candidate can identify such SRS transmissions from the WTRU and can locally record that the WTRU has performed an LTM handover.

[0287] In a PUCCH-based indication embodiment, the WTRU can be configured to send a PUCCH transmission to the target LTM candidate after an LTM handover. The configuration of the PUCCH transmission, including PUCCH format allocation, sequence allocation, and PUCCH time-frequency resources, is specific to the target LTM candidate. The configured PUCCH transmission can indicate to the LTM target that the WTRU has performed an LTM handover.

[0288] In an embodiment, the WTRU can be configured to send a scheduling request (SR) to an LTM target candidate on the configured PUCCH resource. By limiting it to short PUCCHs (e.g., sequence-based PUCCH format 0 transmissions), the design can remain simple.

[0289] In an embodiment of the LTM process based on non-radio measurements, this embodiment may use any of the following actions: (1) WTRU capability transfer for lower-layer mobility / LTM processing and related ancillary information, this step may be accompanied by the reporting of a set of non-radio measurements, which may be further enhanced by some radio measurements; (2) WTRU receiving LTM configuration and (e.g., suitable) LTM non-radio measurements and (e.g., suitable) a set of events set on such non-radio measurements for reporting purposes; (3) WTRU performing the configured non-radio measurements; (4) WTRU detecting changes in non-radio and radio measurements; (5) WTRU determining its partitions using non-radio measurements; (6) evaluating the configured events using conditions set on the non-radio measurements; (7) WTRU reporting its configured non-radio measurements (e.g., partitions, location / orientation, and orientation) on an event-triggered basis. The network may be configured for WTRU to report radio measurements as part of a triggered measurement report. (8) The WTRU receives a network command for performing LTM mobility handover, wherein the network may use WTRU measurement reports and other system-level aspects to determine the target cell / beam configuration of the WTRU; (9) The WTRU performs LTM mobility handover according to the network command; (10) The WTRU performs protocol stack processing and transmits UL instructions according to the network configuration / instructions.

[0290] An example of a detailed network control mobility procedure triggered by WTRU non-radio measurements and subsequently reported by the WTRU is as follows: Figure 13 As shown.

[0291] refer to Figure 13 The process can begin at step 1310, where the WTRU is in the RRC_CONNECTED state. At step 1320, the WTRU can provide the network with its capabilities for handling different aspects of low-level mobility processes. These capabilities can be grouped into different formats covering aspects such as handling intra-DU, inter-DU configurations and mobility processing, and the maximum number of configurations the WTRU can configure. Of particular interest are the WTRU capabilities related to non-radio measurements (position, location, orientation, panel), relevant details, and the accuracy of such measurements, which may help the network determine the LTM configuration. Along with LTM-related capabilities in an appropriate format, the WTRU can also provide mobility assistance information to the network (e.g., gNB). This information may include the ability to measure and perform various non-radio measurements. The set of measurement results sent to the network for the network to use in preparing mobility configurations can be low-level measurements, traditional L3 measurements, or a combination of both.

[0292] Upon receiving capability and mobility assistance information, in step 1330, the WTRU can receive coverage information from the network. This coverage information may be a snapshot of the network deployment near the WTRU's location. The coverage information may be provided to the WTRU by the network at (e.g., appropriate) granularity based on the assistance information and the QoS / QoE requirements of the services the WTRU is using or intends to use. In an embodiment, the WTRU may (e.g., only) receive partition determination information from the network that does not reveal any deployment information.

[0293] In addition to the coverage configuration, in step 1340, the WTRU can receive (e.g., suitable) low-layer mobility configurations from the network. The low-layer mobility configuration, or LTM configuration, may include several candidate configurations. These configurations may be provided as serving cell configurations, cell group configurations, or larger RRC reconfiguration messages. Furthermore, these candidate configurations may be provided as individual configurations or as differential configurations against (e.g., suitable) reference configurations. The reference configuration may be configured as a serving cell configuration or provided as an independent configuration. A subset of the LTM candidate configurations may be marked as ACTIVATED or ENABLE by the network, while other configurations may be considered DE-ACTIVATED. The WTRU will monitor ACTIVATED candidates for potential LTM handover.

[0294] An important point is that the network configures non-radio measurements for the WTRU as part of the LTM configuration. Conditions set on these non-radio measurements can trigger measurement reports sent by the WTRU to the network, which become the basis for the network's LTM cell handover decisions. Upon receiving the LTM configuration, the WTRU can monitor the configured non-radio measurements periodically, semi-persistently, aperiodically, or event-triggered, depending on the received configuration.

[0295] If the WTRU estimates degradation in the current serving link (where link / beam quality degradation is part of the configuration itself), in step 1350, the WTRU can estimate its current location, orientation, and orientation. Additional non-radio measurements may be configured via the WTRU's local sensors or information received through different interfaces. Link quality degradation detection can be configured on beam-based or cell-based signals. The thresholds used to determine the configuration for degradation can differ from traditional beam failure detection or radio link failure detection, as the goal here is to run the process before beam or link failure occurs. As an alternative embodiment, the WTRU may receive configuration information from the network instructing it to monitor non-radio measurements periodically or whenever a change (exceeding a certain threshold) is detected in these quantities.

[0296] After obtaining an updated estimate of its non-radio measurements (in terms of location / positioning and orientation), in step 1360, the WTRU can determine its current partition based on coverage information provided by the network. The parameters and constants used to determine partition information based on one or more non-radio measurements of location, positioning, and orientation can be part of the coverage configuration.

[0297] After measuring the configured non-radio measurements, in step 1370, the WTRU can evaluate the conditions set as a measurement reporting trigger. If the conditions are met, the WTRU can proceed to the next step 1380 to report the configured measurements.

[0298] In step 1380, the WTRU can transmit the configured non-radio measurement report for LTM measurements where the event conditions are met. If the reporting conditions for event-based reporting are not met, the WTRU may not send the corresponding event-based report and continue according to the configured periodic monitoring quantities. LTM measurement reporting can be periodic. In this case, the WTRU can send the measurement report based on the periodicity or the expiration of a timer for when the measurement report should be transmitted. In compatible designs not shown in this flowchart, reporting can be non-periodic and can be triggered by mechanisms such as RRC commands or PDCCH commands sent by the network to the WTRU for DCI.

[0299] Once the WTRU determines that reporting is required, in step 1380, the WTRU can send its determined non-radio measurements, such as partition, location, orientation, etc., to the network according to the configured reporting settings. The network can configure the WTRU to include some radio measurements in measurement reports triggered by non-radio events.

[0300] WTRU reporting of non-radio measurements allows the network to select an LTM candidate from a pre-configured pool of LTM candidates in either the ACTIVATED or ENABLE state. Although not shown in this flowchart, the network can update its LTM configuration using updated measurement reports received from the WTRU. The network can also decide not to perform an LTM handover.

[0301] If the network is handing over a cell to the WTRU via the LTM procedure, in step 1390, the WTRU may receive a network command to perform the LTM handover. The LTM handover command may include an indication of a target LTM candidate configuration. In addition to the target LTM candidate configuration, the network command for LTM handover may also indicate WTRU actions for MAC / RLC reset and the type of UL indication that the WTRU can send after the LTM handover event.

[0302] Upon receiving an LTM candidate configuration for handover, in step 1395, the WTRU may perform an LTM handover to the target candidate. The handover may include local processing of the MAC and RLC entities at the WTRU. In an embodiment, an instruction to perform a MAC / RLC entity reset may (e.g., explicitly) be provided to the WTRU as part of the LTM configuration candidate, and the WTRU may perform MAC and / or RLC entity resets based on the configuration of the selected LTM candidate. In an embodiment, the WTRU may determine this information based on whether the LTM target candidate involves intra-DU or inter-DU handover, by performing a pre-configured MAC / RLC reset operation for each intra-DU or inter-DU handover scenario. In an embodiment, the MAC / RLC reset processing may be indicated as part of an LTM handover command.

[0303] Another aspect of LTM handover may relate to providing the network with an instruction for the WTRU to perform an LTM handover. The WTRU and the network can reach a consensus to communicate with each other without any interruption after the LTM handover. The WTRU may send a UL indication on an LTM target candidate provided by the network. This UL indication, the selection of the associated sequence, and the selection of the transmission resources for sending the indication can be part of the LTM configuration itself. In an embodiment, the WTRU may select a UL LTM handover indication received in a network command to perform the LTM handover.

[0304] It is important to emphasize that traditional radio measurements can require significant time for estimation, filtering, and reporting, which may be completely unacceptable for achieving mobile service continuity in densely deployed narrow-beam systems. Therefore, various embodiments that make low-level mobility decisions based on non-radio measurements can offer greater latency advantages that are entirely impossible due to the instability and latency issues of radio measurements. Other benefits include mobile service continuity and shorter downtime compared to traditional methods.

[0305] In one embodiment, the LTM process can be based on events in terms of location and orientation, without requiring network deployment information.

[0306] In this embodiment, the WTRU can provide a partition-specific configuration but not network deployment information. The WTRU can use its location and orientation information to trigger lower-layer reporting to the network as part of a lower-layer mobility triggering process. WTRU reporting can be performed through network configuration on location and orientation measurements, triggers, and thresholds. This reporting informs the network of the cells and beams used for the WTRU, allowing the network to issue cell handover commands to the WTRU accordingly.

[0307] This embodiment can use any of the following actions: WTRU capability delivery for low-level mobility processing and related ancillary information to support LTM processes based on non-radio measurements. The WTRU receives configuration for determining partition information, as well as orientation-specific parameters and references. The WTRU receives LTM configuration and (e.g., suitable) LTM non-radio measurements and (e.g., suitable) events for reporting purposes, which are set on the combination of non-radio measurements. In this embodiment, the network can configure the WTRU for events regarding partition entry (LTM-CM2) and possibly combine them with velocity or orientation aligned with a specific location (LTM-OT1). The network can optionally configure to capture a joint event of both aspects via a single event (e.g., LTM-CM2O1). The WTRU performs configured non-radio measurements on its position and orientation periodically according to the configuration. The WTRU detects changes in non-radio or radio measurements. The WTRU determines its partition based on the non-radio measurements and partition configuration. The WTRU evaluates the configured events, where conditions are set on position and orientation. In the event-triggered scenario where a WTRU enters a specific partition according to its configuration and heads towards a matching given reference location, the WTRU reports its partition, location / positioning, and possible radio measurements on an event-based basis according to its configuration. The WTRU receives network commands for performing LTM mobility handover, where the network can use WTRU reports and other system-level aspects to determine the target cell / beam configuration for the WTRU. The WTRU performs LTM mobility handover according to the network commands. The WTRU performs protocol stack processing according to network instructions. The WTRU transmits UL indications according to network configuration / instructions, where the network can indicate the transmission of a reference signal (RS) or an indication based on the Physical Uplink Control Channel (PUCCH) via an LTM handover command or by prior configuration.

[0308] In an embodiment, the LTM process may be based on network topology information and events on non-radio measurements.

[0309] This embodiment can use any of the following actions: WTRU capability delivery for low-layer mobility / LTM processing and related ancillary information to support LTM processes based on non-radio measurements. The WTRU receives coverage and deployment topology and related configuration. The WTRU receives LTM configuration and (e.g., suitable) LTM non-radio measurements and (e.g., suitable) events for reporting purposes, set on the combination of non-radio measurements, utilizing deployment / coverage information provided by the network.

[0310] In this embodiment, the network can indicate any proposed non-radio event as part of the configuration: non-radio events LTM-OD1 and LTM-OD2 can be configured in scenarios with rotational and translational mobility relative to certain specific TRP (e.g., distributed unit) locations. Non-radio events LTM-CM1, LTM-CM2, and LTM-CM2V1 can be used for potential handover assessment when a WTRU may enter a given partition. Non-radio event LTM-CM2V1 can be used for potential handover assessment when a WTRU may enter a given partition at high speed.

[0311] This embodiment can also utilize any of the following actions: The WTRU performs configured non-radio measurements. The WTRU detects changes in non-radio or radio measurements. The WTRU determines its zone based on non-radio measurements. The WTRU evaluates configured events, where conditions are set on non-radio measurements. The WTRU reports its zone, location / positioning, and radio measurements based on the configuration, upon event triggering. The WTRU receives network commands for performing LTM mobility handover, where the network can use WTRU reports and other system-level aspects to determine the target cell / beam configuration for the WTRU. The WTRU performs LTM mobility handover according to the network commands. The WTRU performs protocol stack processing according to the network instruction embodiment. The WTRU transmits UL instructions according to the network configuration / instruction, where the network can instruct the transmission of RS or PUCCH-based instructions via LTM handover commands or through prior configuration.

[0312] In an embodiment, the LTM process can be activated / deactivated based on LTM measurements associated with the partition.

[0313] In this embodiment, the WTRU can be provided with a partition-determined configuration. The WTRU can use its location information to determine its partition based on the network configuration. As part of the LTM process, the network can configure LTM candidates for the WTRU. To reduce measurement and tracking overhead, LTM measurements can be mapped to relevant partitions. Therefore, these measurements may only be activated, deactivated, executed, and reported when the WTRU determines which partitions it is in. This provides the WTRU with a streamlined mechanism to trigger measurements only in appropriate partitions and then report to the network based on the reporting and triggering of these measurements. The network can then use the relevant measurement reports to trigger (e.g., appropriate) mobility procedures to target LTM candidates.

[0314] This embodiment can utilize any of the following actions: WTRU capability delivery for low-layer mobility / LTM processing and related ancillary information to support LTM procedures based on non-radio measurements. The WTRU receives configurations and parameters for determining partition information. The WTRU receives LTM configurations for candidate cells. The WTRU receives LTM-related measurement configurations (associated with LTM candidates), where the measurement configurations provide associations with certain partitions. Measurements can be part of the measConfig in RRC reconfiguration, CSI configuration, or through new information elements specifically designed for the LTM procedure. The association of measurement configurations with partitions can be achieved by explicitly providing a set of partition identifiers where the measurement configuration is activated, or this information can be provided in different information elements. The WTRU periodically performs non-radio measurements for its location configuration based on the configuration. The WTRU determines its location / partition through non-radio measurements. The WTRU evaluates the conditions / events for the LTM measurements used for the configuration. The WTRU monitors active measurement configurations and provides reports to the network based on the configurations therein. When a WTRU partition changes, the WTRU can activate measurement configurations configured as active in the new partition. When a WTRU partition changes, WTRU deactivates measurement configurations that are not configured as active in the new partition.

[0315] An exemplary embodiment for L1L2-triggered mobility procedures can be based on Figure 13The process can begin when the WTRU is in an RRC connected state. The WTRU can provide its capability information and additional ancillary information related to low-layer mobility / LTM processing. This step can be accompanied by the reporting of non-radio measurement sets. The transmission of capability and ancillary information can be triggered by the WTRU itself, for example, if its measurements indicate some coverage degradation, or if the WTRU is running or starting to run an application that requires low-mobility disruption. In another embodiment, the WTRU can be triggered by the network to send capability and ancillary information by sending a (e.g., explicit) request to the WTRU. As an example, the network request can be sent as an RRC message. After receiving the WTRU capability and ancillary information, the network can provide the WTRU with coverage and deployment topology (e.g., in a suitable format). This information can be provided as WTRU-specific signaling or system information broadcast signaling. In another design, basic coverage information can be transmitted as system information broadcast and then refined in WTRU-specific signaling according to the WTRU's application requirements and capabilities. The WTRU can receive LTM configuration, along with (e.g., appropriate) non-radio measurements and (e.g., appropriate) events for reporting purposes, from the network. Coverage information and LTM configuration can be transmitted by the network simultaneously or in any order. Once the network has completed configuration, the WTRU can begin measuring and monitoring the configured non-radio measurements. In some cases, there may be additional activation steps for measuring the configuration, upon which the WTRU begins measuring and monitoring the configured quantities. The WTRU can be configured by the network to perform periodic measurements of non-radio quantities, or the WTRU can be configured to detect changes in its radio or non-radio measurements. In this case, the WTRU can proceed to the next step, perform novel measurements, and evaluate reporting conditions. The WTRU can estimate its non-radio measurements, which allow it to determine its partitions from the coverage topology configuration provided by the network. For event-based LTM measurement configurations, the WTRU can calculate measurements based on the configured or standardized measurement model, where measurements can be L1, L3, combined quantities, or bias quantities. After estimating the configured non-radio measurements, the WTRU can evaluate the conditions set as event triggering conditions for measurement reporting. If the conditions are met to trigger the event in question, the WTRU can send a measurement report to the network. The WTRU can report configured non-radio measurements to the network, which are configured as part of the measurement configuration. The reports received from the WTRU provide information to the network, enabling the network to determine (e.g., appropriately) the next steps. The network can switch the WTRU from its current serving cell to one of the configured and active LTM cell configurations because it gains visibility from the WTRU measurement reports. This decision can be a calculation combining the measurement results reported by the WTRU with network-level optimization considerations (e.g., load balancing).If the network decides to change the WTRU serving cell to one of the LTM candidate cells, it can send an LTM cell handover command to the WTRU. Once the WTRU receives the network command to perform an LTM mobility handover, the WTRU can perform a mobility handover to the target cell configured in the network command.

[0316] The network commands for LTM handover can include an indication of the target LTM candidate configuration. In addition to the target LTM candidate configuration, the network commands for LTM handover can also indicate WTRU behavior for MAC / RLC reset. The type of UL indication that the WTRU can send after the LTM handover event is specified.

[0317] Upon receiving an LTM candidate configuration for performing an LTM handover, the WTRU will perform an LTM handover to the target candidate. The LTM handover may include local processing of MAC and RLC entities at the WTRU. In one embodiment, an instruction to perform a MAC / RLC entity reset may be provided to the WTRU (e.g., explicitly) as part of the LTM configuration candidate. The WTRU can perform MAC and / or RLC entity resets based on the configuration of the selected LTM candidate. In another embodiment, the WTRU may determine this information based on whether the LTM target candidate involves an intra-DU or inter-DU handover, by performing a pre-configured MAC / RLC reset operation for each intra-DU or inter-DU handover scenario. In yet another embodiment, the MAC / RLC reset processing may be indicated as part of an LTM handover command.

[0318] Other aspects of LTM handover may relate to providing the network with an instruction for the WTRU to perform an LTM handover. This is necessary so that the WTRU and the network have consensus to communicate with each other without any interruption after the LTM handover. The WTRU may send a UL indication on an LTM target candidate provided by the network. This UL indication, the selection of the associated sequence, and the selection of the transmission resources for sending the indication may be part of the LTM configuration itself. In an embodiment, the WTRU may select a ULLTM handover indication received in a network command to perform an LTM handover.

[0319] For LTM procedural implementations based on location and orientation events without relying on network deployment information, the WTRU is provided with a partition-determined configuration but not network deployment information. The WTRU can use its location and orientation information to trigger lower-layer reporting to the network, which is configured as part of the lower-layer mobility triggering process. WTRU reporting can be performed by configuring the network on location and orientation measurements, triggers, and thresholds. The network can use this reporting to determine the WTRU's cell and beam, and accordingly issue a cell handover command to the WTRU. This embodiment may include any of the following actions: WTRU capability delivery for low-level mobility processing and related ancillary information to support LTM processes based on non-radio measurements; WTRU receiving configuration for determining partition information and orientation-specific parameters and references (e.g., reference TRP selection); WTRU receiving LTM configuration and (e.g., suitable) LTM non-radio measurements and (e.g., suitable) events for reporting purposes, which are set on the combination of non-radio measurements; WTRU performing non-radio measurements of its position and orientation according to the periodicity of the configuration; WTRU detecting changes in non-radio or radio measurements; WTRU determining its partitions based on non-radio measurements and partition configuration; WTRU evaluating the events of the configuration, where conditions are set on the position and orientation. Orientation; In the event triggered when the WTRU enters a specific partition according to its configuration and its orientation matches a given reference location, the WTRU reports its partition, location / positioning, and possible radio measurements on an event-based basis according to its configuration; The WTRU receives network commands for performing LTM mobility handover, where the network can use WTRU reports and other system-level aspects to determine the WTRU's target cell / beam configuration; The WTRU performs LTM mobility handover according to the network commands; The WTRU performs protocol stack processing according to network indications in dynamic signaling or as part of the LTM configuration; and The WTRU transmits UL indications according to network configuration / indications, where the network can indicate the transmission of RS or PUCCH-based indications via LTM handover commands or via prior configuration.

[0320] For the WTRU to receive LTM configuration and (e.g., appropriate) LTM non-radio measurements, the network can configure the WTRU to receive events related to partition entry (LTM-CM2) and possibly combined with velocity or orientation aligned with a location (LTM-OT1). Furthermore, the network can optionally configure to capture a combined event of both aspects via a single event (e.g., LTM-CM2O1).

[0321] For an LTM process implementation using network topology information and based on events on non-radio measurements, this implementation may use any of the following actions: WTRU capability delivery for lower-layer mobility / LTM processing and related ancillary information to support the non-radio measurement-based LTM process; WTRU receiving coverage and deployment topology and related configuration; WTRU receiving LTM configuration and (e.g., suitable) LTM non-radio measurements and (e.g., suitable) events based on non-radio measurement combinations for reporting purposes, which utilize deployment / coverage information provided by the network; WTRU performing configured non-radio measurements; WTRU detecting changes in non-radio or radio measurements; WTRU transmitting non-radio measurements... The WTRU determines its partition; the WTRU evaluates the configured events and conditions set on non-radio quantity measurements; the WTRU reports its partition, location / positioning, and radio measurements on an event-triggered basis according to the configuration; the WTRU receives network commands for performing LTM mobility handover, where the network can use WTRU reports and other system-level aspects to determine the WTRU's target cell / beam configuration; the WTRU performs LTM mobility handover according to the network commands; the WTRU performs protocol stack processing according to network instructions; and the WTRU transmits UL instructions according to network configuration / instructions, where the network can instruct the transmission of RS or PUCCH-based instructions via LTM handover commands or by pre-configuration.

[0322] For a WTRU receiving LTM configuration and (e.g., appropriate) LTM non-radio measurements and (e.g., appropriate) event actions for reporting purposes, the network may instruct any of the following non-radio events as part of the configuration: non-radio events LTM-OD1 and LTM-OD2 may be configured in scenarios with rotational and translational mobility relative to certain specific TRP (DU) locations; non-radio events LTM-CM1, LTM-CM2, and LTM-CM2V1 may be used for potential handover assessment when the WTRU may enter a given partition; and non-radio event LTM-CM2V1 may be used for potential handover assessment when the WTRU enters a given partition at high speed.

[0323] For embodiments where LTM measurement activation / deactivation is associated with partitions, a partition determination configuration is provided to the WTRU. The WTRU can use its location information to determine its partitions based on the network configuration. As part of the LTM process, the WTRU can be configured with LTM candidates by the network. To reduce measurement and tracking overhead, LTM measurements can be mapped to (e.g., relevant partitions). Therefore, these measurements may only be activated, deactivated, performed, and reported when the WTRU determines which partitions it is in. This provides the WTRU with a streamlined mechanism to trigger measurements (only) in (e.g., suitable) partitions, and then report to the network based on the reporting and triggering of these measurements. The network can use the associated measurement reports to trigger a mobility process toward a target LTM candidate. This embodiment can use any of the following actions: WTRU capability delivery for low-layer mobility / LTM processing and related ancillary information to support LTM processes based on non-radio measurements; WTRU receiving configurations and (e.g., appropriate) parameters for determining partition information; WTRU receiving LTM configurations for candidate cells; WTRU receiving LTM-related measurement configurations (associated with LTM candidates), where the measurement configurations provide associations with certain partitions; WTRU performing configured non-radio measurements on its location according to the configured periodicity; WTRU determining its location / partition through non-radio measurements; WTRU evaluating the conditions / events for the configured LTM measurements; when WTRU partitions change, WTRU can activate measurement configurations configured as active in the new partition, and WTRU can deactivate measurement configurations not configured as active in the new partition; and WTRU monitoring active measurement configurations and providing reports to the network based on the configurations therein.

[0324] For an action where the WTRU is receiving LTM-related measurement configurations (where the measurement configurations provide associations with certain partitions), the measurement can be part of the measConfig in RRCreconfiguration, CSIconfiguration, or through a new information element specifically designed for the LTM process. The association between the measurement configuration and the partition can be achieved by (e.g., explicitly) providing the set of partition identifiers that this measurement configuration is active, or this information can be provided in a different information element.

[0325] For an LTM process implementation based on periodic reporting of non-radio measurements, this implementation may include any of the following key actions: WTRU capability delivery for lower-layer mobility / LTM processing and related ancillary information to support the non-radio measurement-based LTM process; receiving coverage and deployment topology and related configurations; the WTRU receiving the LTM configuration and (e.g., appropriate) LTM non-radio measurements and periodic reporting configuration; the WTRU performing the configured non-radio measurements; the WTRU determining its partition through the non-radio measurements; upon timer expiration, the WTRU reporting the configured non-radio measurements, such as its partition, location / positioning, and radio measurements, according to the configuration; and the network being able to perform the measurements after receiving the WTRU measurement report. The measurements are compared with thresholds and previous measurements; the network can determine an active LTM configuration based on WTRU reports and other system-level considerations; the WTRU receives network commands for performing LTM mobility handover, where the network can use non-radio measurements reported by the WTRU and other system-level aspects to determine the WTRU's target cell / beam configuration; the WTRU performs LTM mobility handover according to the network commands; the WTRU performs protocol stack processing according to network instructions; and the WTRU transmits UL instructions according to network configuration / instructions, where the network can instruct the transmission of RS or PUCCH-based instructions via LTM handover commands or by pre-configuration.

[0326] For embodiments that activate LTM candidate configurations based on partition information reported by the WTRU, the network can control (e.g., appropriately) the activation and deactivation of the LTM candidate configurations. As part of the configuration, the network can provide parameters related to determining the WTRU partition information. The network can also provide necessary measurement information enabling the WTRU to determine its partition information. Partition information can be determined from location information obtainable by the WTRU through local GNSS measurements. This can be done via a local GNSS receiver. Location information can be determined through other non-radio measurements. The WTRU may have already (e.g., prior) informed the network of its ability to perform non-3GPP radio and non-radio measurements.

[0327] The WTRU can receive LTM candidate configurations from the network. These candidate configurations may include cell configurations, as well as events and conditions on non-radio measurements that can trigger the WTRU to report.

[0328] The WTRU can be configured by the network to periodically estimate its location through configured measurements. Based on these periodic estimates, the WTRU can determine its partition information according to the coverage topology configuration. The WTRU can be configured to report the partition information to the network. The reporting can be periodic, configurable according to WTRU mobility and QoS requirements. To reduce reporting overhead, WTRU reporting can be event-based and (e.g., only) reported when the partition estimated by the WTRU differs from a previous partition. The WTRU partition information can be transmitted to the network as part of the UCI. A new MAC-CE can be designed to provide the partition information. Upon receiving updated partition information, the network can update the active LTM configuration. The network can send an "LTM Configuration Activate" MAC-CE, which can activate the LTM configuration. Two different MAC-CEs can be designed to accommodate different numbers of LTM configurations that may need to be activated for the final LTM process. A custom MAC-CE can be designed for this purpose, where the identifier of the LTM configuration can provide a pointer to the LTM configuration configured via RRC signaling. One design for activating the MAC-CE can be bitmap-based, where the network can indicate the activation status of the LTM configuration for each configuration. For more reactive scenarios, PHY-based signaling (such as DCI) can be used to activate a configured LTM configuration.

[0329] Therefore, this embodiment offers significant advantages in terms of resource overhead and latency reduction. The WTRU can (e.g., closely) monitor only configuration measurements of the network-activated LTM configuration corresponding to its location. This saves the WTRU from making unnecessary measurements based on candidate configurations that are unnecessary for its update location.

[0330] This embodiment is achieved through Figure 14 The flowchart is used for illustration.

[0331] refer to Figure 14The process can begin at step 1405, where the WTRU is in the RRC_CONNECTED state. At step 1410, the WTRU can send low-layer mobility / LTM processing and related ancillary information to the gNB / cell / base station to support LTM processes based on non-radio measurements. At step 1415, the WTRU can receive coverage and deployment topology and related configurations for determining partition information. At step 1420, the WTRU can receive LTM configurations and (e.g., appropriate) LTM non-radio measurements and (e.g., appropriate) non-radio events for reporting purposes. A subset of the LTM configurations can be indicated as active by the network as part of configuration / initialization. At step 1425, the WTRU can be configured to periodically determine / estimate its partition information based on non-radio measurements to assist in configuration activation / deactivation. At step 1430, in order to determine its partitions via non-radio measurements, the WTRU can perform configuration measurements associated with the active LTM configuration and can perform configured non-radio measurements for activation / deactivation purposes, these measurements being configured to determine its partition information.

[0332] In step 1435, the WTRU can determine whether the newly determined partition is different from the previous partition. If so, the WTRU can perform the following four steps.

[0333] In step 1440, the WTRU can send a report to the network via the UL, indicating its newly determined partition information.

[0334] In step 1445, the WTRU can receive updated coverage information (e.g., an update to the coverage topology) from the network.

[0335] In step 1450, the WTRU can receive an updated list of activated and deactivated LTM configurations from the network. The network can add or remove candidates from the configured LTM candidate list.

[0336] In step 1455, WTRU can update the activation status of the configured LTM candidate list, wherein the status is updated according to network instructions.

[0337] refer to Figure 15This document illustrates a method 1500 implemented in a Radio Transmit / Receive Unit (WTRU) according to an embodiment for performing cell handover based on WTRU partition location. Method 1500 may include a step whereby the WTRU may send a first message 1510 to the network, the first message containing first information regarding non-radio measurement capabilities. Method 1500 may include a step whereby the WTRU may receive a second message 1520 from the network, the second message containing second information indicating a first configuration for determining at least one partition location of the WTRU based on non-radio measurement capabilities. Method 1500 may include a step whereby the WTRU may receive a third message 1530 from the network, the third message containing third information indicating multiple mobility configurations and indicating a second configuration for reporting trigger events based on non-radio measurement quantities. The multiple mobility configurations may be multiple Low Layer Triggered Mobility (LTM) configurations. Method 1500 may include a step whereby the WTRU may determine 1540 the WTRU partition location based on the first configuration for determining the partition location. Method 1500 may include a step in which, upon satisfaction of a configured reporting trigger event, the WTRU may send a fourth message 1550 to the network, indicating the determined partition location. In method 1500, in response to sending the fourth message, the WTRU may receive a command message 1560 from the network, the command message containing information for performing a cell handover to a target cell associated with one of a plurality of mobility configurations. This cell handover may be an LTM mobility cell handover. Method 1500 may include a step in which the WTRU may perform a cell handover 1570 to the target cell based on the command message.

[0338] Non-radio measurements may include at least one measurement based on data from a local sensor. The local sensor may be any of a motion sensor, an environmental sensor, a position sensor, and a speed measurement sensor.

[0339] The multiple mobility configurations may each contain information indicating the partition location used to activate or deactivate the mobility configuration. The fourth message may also indicate the activated mobility configuration among the multiple mobility configurations based on the determined partition location.

[0340] Method 1500 may include a step in which the WTRU can perform non-radio measurements based on non-radio measurement capabilities; and whereby the WTRU can determine a non-radio measurement quantity based on the performed non-radio measurements. The performance of non-radio measurements on the WTRU location may be performed periodically as configured. The configured reporting trigger event may include a change in the determined WTRU partition location relative to a previously determined WTRU partition location.

[0341] Method 1500 may include a step in which the WTRU performs protocol stack processing based on a mobility configuration associated with the target cell. Alternatively, method 1500 may include a step in which the WTRU performs protocol stack processing based on network indications over dynamic signaling.

[0342] Method 1500 may include a step in which the WTRU may send an uplink (UL) message to the network containing an instruction to perform a cell handover.

[0343] Method 1500 may include a step in which the second information further indicates a third configuration for determining the WTRU orientation based on non-radio measurement capabilities, and wherein the WTRU can determine its orientation based on the third configuration, and wherein a fourth message further indicates the determined WTRU orientation. Reporting triggering conditions may include any one of the following: (i) a change in the determined WTRU partition location relative to a previously determined WTRU partition location; and (ii) a WTRU orientation change exceeding a configured threshold.

[0344] refer to Figure 16 This illustrates a method 1600 for performing cell handover based on WTRU partition location, implemented in a wireless transmit / receive unit (WTRU) according to another embodiment.

[0345] Method 1600 may include a step in which the WTRU can send a first message 1610 to the network, the first message containing information about non-radio measurement capabilities. Method 1600 may include a step in which the WTRU can receive a second message 1620 from the network, the second message containing information about network coverage and deployment topology. Method 1600 may include a step in which the WTRU can receive a third message 1630 from the network, the third message containing multiple mobility configurations and information indicating non-radio measurements (e.g., LTM) for network coverage and deployment topology. The multiple mobility configurations may be multiple Low Layer Triggered Mobility (LTM) configurations. Method 1600 may include a step in which the WTRU can determine one or more variations among the (e.g., LTM) non-radio measurements 1640. Method 1600 may include a step in which the WTRU can determine a WTRU partition location 1650 based on non-radio measurement values ​​from the non-radio measurements and based on network coverage and deployment topology. Method 1600 may include a step in which the WTRU can send the determined partition location 1660 to the network. Method 1600 may include a step in which the WTRU receives a command message 1670 from the network, the command message containing information for performing a cell handover to a target cell associated with one of a plurality of configurations. This cell handover may be an LTM mobility cell handover. Method 1600 may include a step in which the WTRU performs a cell handover 1680 to the target cell based on the command message.

[0346] refer to Figure 17 This illustrates a method 1700 implemented in a WTRU according to an embodiment for performing non-radio measurements based on WTRU partition information.

[0347] Method 1700 may include a step in which the WTRU may send a first message 1710 to the network, the first message containing information about non-radio measurement capabilities. Method 1700 may include a step in which the WTRU may receive a second message 1720 from the network, the second message containing configuration information for determining WTRU partition information. Method 1700 may include a step in which the WTRU may receive a third message 1730 from the network, the third message containing multiple mobility configurations and multiple (e.g., LTM) non-radio measurement configurations associated with multiple partition information. The multiple mobility configurations may be multiple Low Layer Triggered Mobility (LTM) configurations. Method 1700 may include a step in which the WTRU may determine the partition information 1740 based on the second message. Method 1700 may include a step in which the WTRU may determine one of multiple non-radio measurements associated with the partition information 1750. Method 1700 may include a step in which the WTRU may perform the determined (e.g., LTM) non-radio measurement 1760 based on the determined partition information. Each of the multiple partition information may contain a partition identifier, and each partition identifier may be associated with information indicating the activation (e.g., LTM) or deactivation (e.g., LTM) of a non-radio measurement.

[0348] While features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. This disclosure should not be limited to the specific embodiments described herein, which are intended as illustrative of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Unless expressly provided so, no element, action, or instruction used in the description of this application should be construed as critical or necessary to the invention. Within the scope of this disclosure, functionally equivalent methods and apparatuses, in addition to those listed herein, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terminology of the appended claims and the scope of their complete equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0349] For simplicity, the foregoing embodiments have discussed the terminology and structure of infrared functional devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (e.g., sound waves).

[0350] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may refer to any one of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" or its abbreviation "HMD" may refer to or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of the many embodiments of a WTRU; (iii) a device with wireless and / or wired capabilities (e.g., wired connectivity) configured with some or all of the structure and functionality of a WTRU, among other things; (iv) a device with wireless and / or wired capabilities configured with less than all the structure and functionality of a WTRU; or (iv) a similar device. Details of exemplary WTRUs (which may represent any WTRU mentioned herein) are provided in Figures 1A to 1D Provided herein. As another example, the various disclosed embodiments described above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and that some or all of the disclosure and various disclosed embodiments can be modified accordingly without much experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive reality experience.

[0351] Furthermore, the methods provided herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to: read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical discs (e.g., CD-ROMs and Digital Universal Optical Discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0352] Modifications can be made to the methods, apparatus, and systems described above without departing from the scope of the invention. Given the wide variety of applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (e.g., a battery) to provide any suitable voltage.

[0353] Furthermore, in the above embodiments, a processing platform, computing system, controller, and other devices, including a processor, are mentioned. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0354] Those skilled in the art will understand that these actions and symbolic representations of operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits that can lead to the eventual conversion or reduction of electrical signals and maintain the data bits in memory locations within the memory system, thereby reconfiguring or otherwise altering the CPU's operation and other processing of signals. The memory location maintaining the data bits is a physical location with specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

[0355] Data bits can also be maintained on computer-readable media, including disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by the CPU. Computer-readable media may include cooperative or interconnected computer-readable media, which may be dedicated to a processing system or distributed among multiple interconnected processing systems, which may be located locally or remotely to the processing system. It should be understood that the embodiments are not limited to the above-described memories, and other platforms and memories may support the provided methods.

[0356] In illustrative embodiments, any operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0357] There is virtually no difference between the hardware and software implementations of various aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software can become important in some cases) a design choice representing a trade-off between cost and efficiency. Multiple vehicles may exist to implement the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary depending on the environment in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are critical, the implementer may choose a primary hardware and / or firmware vehicle. If flexibility is critical, the implementer may choose a primary software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0358] The foregoing detailed description illustrates embodiments of various devices and / or processes using block diagrams, flowcharts, and / or examples. As long as such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by various hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented using application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein, whether in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing circuits and / or writing software and / or firmware code in accordance with this disclosure will be within the capabilities of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as a program product in various forms, and that the illustrative embodiments of the subject matter described herein are applicable to specific types of signal-bearing media in which the distribution is actually performed. Examples of signal-bearing media include, but are not limited to: recordable media, such as floppy disks, hard disks, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmission media, such as digital and / or analog communication media (e.g., optical fibers, waveguides, wired communication links, wireless communication links, etc.).

[0359] Those skilled in the art will recognize that it is common practice to describe devices and / or processes in the manner set forth herein, and then integrate such devices and / or processes into data processing systems using engineering practice. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, memory (e.g., volatile and non-volatile memory), a processor (e.g., a microprocessor and a digital signal processor), computing entities (e.g., an operating system, drivers, a graphical user interface, and applications), one or more interactive devices (e.g., a touchpad or screen), and / or a control system (including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or numbers)). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0360] The topics described herein sometimes illustrate different components contained in or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” to achieve the desired function. Therefore, any two components combined in this document to achieve a particular function can be considered “associated” with each other to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two components so associating can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be so associating can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of being operablely coupled include, but are not limited to: physically matchable and / or physically interactable components, and / or wirelessly interactable and / or logically interactable components.

[0361] Regarding any plural and / or singular forms used herein, those skilled in the art can translate them from plural to singular and / or from singular to plural forms as needed by the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0362] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “comprising” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if there is an intent to introduce a specific number of claims, such intent will be explicitly stated in the claims, and without such a statement, such intent does not exist. For example, the term “single” or similar terminology may be used if the intent is to refer to only one item. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claims. However, the use of such phrases should not be construed as implying that introducing a claim statement with the indefinite article "a" or "an" limits any particular claim to an embodiment containing only one such statement, even if the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to cases where a definite article is used to introduce a claim statement. Furthermore, even if a specific number of introduced claim statements is explicitly stated, those skilled in the art will recognize that such statements should be interpreted as meaning at least the stated number (e.g., simply stating "two statements" without other modifiers implies at least two statements, or two or more statements). Furthermore, when using conventions such as "at least one of A, B, and C," this structure is generally intended to be understood in accordance with the conventions as understood by those skilled in the art (e.g., "a system having at least one of A, B, and C" will include, but is not limited to: a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.). When using conventions such as "at least one of A, B, or C," this structure is generally intended to be understood in accordance with the conventions as understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" will include, but is not limited to: a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.). Those skilled in the art will further understand that any extractive terms and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, any, or both terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B”.Furthermore, the term "any" as used herein, followed by a list of multiple items and / or multiple item categories, is intended to include "any single," "any combination," "any multiple," and / or "any multiple combinations" of items and / or item categories, whether alone or in combination with other items and / or other item categories. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any digit, including zero. And the term "multiple," as used herein, is intended to be synonymous with "plural."

[0363] Furthermore, when features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is therefore also described in accordance with any single member or subgroup of the Markush Group.

[0364] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any scope listed can be readily identified as sufficiently descriptive and such that the same scope can be decomposed into at least two equal halves, three equal parts, four equal parts, five equal parts, ten equal parts, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be decomposed into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1-3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1-5 units refers to a group having 1, 2, 3, 4, or 5 units, and so on.

[0365] Furthermore, unless otherwise specified, the claims should not be read in the order in which the elements are presented. Additionally, the use of the term "means for..." in any claim is intended to invoke 35 U.S.SC §112, ¶6 or the means plus function claim format, while any claim that does not use the term "means for..." is not so intended.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Send a first message to the network, the first message containing first information about non-radio measurement capabilities; Receive a second message from the network, the second message containing second information indicating a first configuration for determining at least one partition location of the WTRU based on the non-radio measurement capability; A third message is received from the network, the third message containing third information indicating multiple mobility configurations and indicating a second configuration based on one or more reporting trigger events based on non-radio measurements; The partition location of the WTRU is determined based on the first configuration; If one or more of the reporting trigger events is satisfied, a fourth message is sent to the network, the fourth message indicating the determined partition location; In response to sending the fourth message, a command message is received from the network, the command message containing information for performing a cell handover to a target cell associated with one of the plurality of mobility configurations; as well as The cell handover to the target cell is performed based on the command message.

2. The method of claim 1, wherein the plurality of mobility configurations are a plurality of low-layer triggered mobility (LTM) configurations, and wherein the cell handover is an LTM mobility cell handover.

3. The method of any one of claims 1 and 2, comprising: The non-radio measurement is performed based on the non-radio measurement capability; as well as The non-radio measurement quantity is determined based on the non-radio measurement performed.

4. The method of claim 3, further comprising performing the non-radio measurement of the WTRU location according to a configured periodicity.

5. The method of any one of claims 1 to 4, wherein the configured reporting trigger event includes a change in the determined WTRU partition location relative to a previously determined WTRU partition location.

6. The method of any one of claims 1 to 5, comprising performing protocol stack processing based on the mobility configuration associated with the target cell.

7. The method of claim 1, further comprising performing protocol stack processing based on network indications on dynamic signaling.

8. The method of any one of claims 1 to 7, comprising sending an uplink (UL) message to the network containing an instruction to perform the cell handover.

9. The method of any one of claims 1 to 8, wherein the non-radio measurement includes at least one measurement based on data from a local sensor.

10. The method of claim 9, wherein the local sensor is any one of a motion sensor, an environmental sensor, a position sensor, and a speed measurement sensor.

11. The method of any one of claims 1 to 10, wherein the second information further indicates a third configuration for determining the WTRU orientation based on non-radio measurement capabilities, the method further comprising: The WTRU orientation is determined based on the third configuration. as well as The fourth message also indicates the determined WTRU orientation.

12. The method of claim 11, wherein the reporting trigger condition includes any one of the following: (i) a change in the determined WTRU partition location relative to a previously determined WTRU partition location; and (ii) a change in the orientation of the WTRU exceeding a configured threshold.

13. The method of any of the preceding claims, wherein the plurality of mobility configurations each includes information indicating the partition location for activating or deactivating the mobility configuration.

14. The method of claim 13, wherein the fourth message further indicates the activated mobility configuration among the plurality of mobility configurations based on the determined partition location.

15. A wireless transmit / receive unit (WTRU) including a memory and a processor, the WTRU being configured to: Send a first message to the network, the first message containing first information about non-radio measurement capabilities; Receive a second message from the network, the second message containing second information indicating a first configuration for determining at least one partition location of the WTRU based on the non-radio measurement capability; A third message is received from the network, the third message containing third information indicating multiple mobility configurations and indicating a second configuration based on one or more reporting trigger events based on non-radio measurements; The partition location of the WTRU is determined based on the first configuration; If one or more of the reporting trigger events is satisfied, a fourth message is sent to the network, the fourth message indicating the determined partition location; In response to sending the fourth message, a command message is received from the network, the command message containing information for performing a cell handover to a target cell associated with one of the plurality of mobility configurations; as well as The cell handover to the target cell is performed based on the command message.

16. The WTRU of claim 15, wherein the plurality of mobility configurations are a plurality of low-layer triggered mobility (LTM) configurations, and wherein the cell handover is an LTM mobility cell handover.

17. The WTRU as claimed in any one of claims 15 and 16, configured to: The non-radio measurement is performed based on the aforementioned non-radio measurement capability; and The non-radio measurement quantity is determined based on the non-radio measurement performed.

18. The WTRU of claim 17, configured to perform the non-radio measurement of the WTRU location according to a configured periodicity.

19. The WTRU of any one of claims 15 to 18, wherein the configured reporting trigger event includes a change in the determined WTRU partition location relative to a previously determined WTRU partition location.

20. The WTRU of any one of claims 15 to 19, configured to perform protocol stack processing based on the mobility configuration associated with the target cell.

21. The WTRU of claim 15, comprising performing protocol stack processing based on network indications on dynamic signaling.

22. The WTRU of any one of claims 15 to 21, configured to send an uplink (UL) message to the network containing an indication to perform the cell handover.

23. The WTRU of any one of claims 15 to 22, wherein the non-radio measurement includes at least one measurement based on data from local sensors.

24. The WTRU of claim 23, wherein the local sensor is any one of a motion sensor, an environmental sensor, a position sensor, and a speed measurement sensor.

25. The WTRU of any one of claims 15 to 24, wherein the second information further indicates a third configuration for determining the WTRU orientation based on non-radio measurement capabilities, the WTRU being configured to: The WTRU orientation is determined based on the third configuration; and The fourth message also indicates the determined WTRU orientation.

26. The WTRU of claim 25, wherein the reporting trigger condition includes any one of the following: (i) a change in the determined WTRU partition location relative to a previously determined WTRU partition location; and (ii) a change in the orientation of the WTRU exceeding a configured threshold.

27. The WTRU of any one of claims 15 to 26, wherein each of the plurality of mobility configurations includes information indicating the partition location for activating or deactivating the mobility configuration.

28. The WTRU of claim 27, wherein the fourth message further indicates the activated mobility configuration among the plurality of mobility configurations based on the determined partition location.

29. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Send a first message to the network, the first message containing information about non-radio measurement capabilities; Receive a second message from the network, the second message containing information about network coverage and deployment topology; A third message is received from the network, the third message containing multiple mobility configurations and information indicating non-radio measurements for network coverage and deployment topology; To determine one or more changes in non-radio measurements; The WTRU partition location is determined based on non-radio measurements from non-radio measurements and based on network coverage and deployment topology. Send the determined partition location to the network; Receive a command message from the network, the command message containing information for performing a cell handover to a target cell associated with one of the plurality of mobility configurations; as well as The cell handover to the target cell is performed based on the command message.

30. A wireless transmit / receive unit (WTRU) including a memory and a processor, the WTRU being configured to: Send a first message to the network, the first message containing information about non-radio measurement capabilities; Receive a second message from the network, the second message containing information about network coverage and deployment topology; A third message is received from the network, the third message containing multiple mobility configurations and information indicating non-radio measurements for network coverage and deployment topology; To determine one or more changes in non-radio measurements; The WTRU partition location is determined based on non-radio measurements from non-radio measurements and based on network coverage and deployment topology. Send the determined partition location to the network; Receive a command message from the network, the command message containing information for performing a cell handover to a target cell associated with one of the plurality of configurations; as well as The cell handover to the target cell is performed based on the command message.

31. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Send a first message to the network, the first message containing information about non-radio measurement capabilities; Receive a second message from the network, the second message containing information about the configuration for determining the partition information of the WTRU; A third message is received from the network, the third message containing multiple mobility configurations and multiple non-radio measurement configurations associated with multiple partition information; The partition information is determined based on the second message; Determine one of the plurality of non-radio measurements that is associated with the partition information; as well as The determined non-radio measurements are performed based on the determined partition information.

32. The method of claim 31, wherein each of the plurality of partition information comprises a partition identifier, and wherein each partition identifier is associated with information indicating the activation or deactivation of non-radio measurements.

33. A wireless transmit / receive unit (WTRU) including a memory and a processor, the WTRU being configured to: Send a first message to the network, the first message containing information about non-radio measurement capabilities; Receive a second message from the network, the second message containing information about the configuration for determining the partition information of the WTRU; A third message is received from the network, the third message containing multiple mobility configurations and multiple non-radio measurement configurations associated with multiple partition information; The partition information is determined based on the second message; Determine one of the plurality of non-radio measurements that is associated with the partition information; as well as The determined non-radio measurements are performed based on the determined partition information.

34. The WTRU of claim 33, wherein each of the plurality of partition information includes a partition identifier, and wherein each partition identifier is associated with information indicating the activation or deactivation of non-radio measurements.

Images