Methods, architectures, apparatus and systems for non-wireless measurement-based lower-layer mobility
Non-radio measurement-based methods in wireless transceiver units address high overhead and latency in legacy mobility procedures, improving user equipment mobility in wireless networks with high carrier frequencies.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- INTERDIGITAL PATENT HOLDINGS INC
- Filing Date
- 2024-04-30
- Publication Date
- 2026-06-02
AI Technical Summary
Legacy mobility procedures in wireless networks with high carrier frequencies and narrow-beam transmissions result in high overhead and latency, exceeding the time scale of mobility events, necessitating improved user equipment mobility management.
Implementing methods in wireless transceiver units to utilize non-radio measurement capabilities for determining zone location and mobility configurations, enabling efficient cell switching based on network feedback and non-wireless measurements.
Reduces mobility latency and overhead by leveraging non-radio measurements for zone location and mobility management, enhancing user equipment mobility within wireless networks.
Smart Images

Figure 2026517828000001_ABST
Abstract
Description
Technical Field
[0001] The present disclosure generally relates to the fields of communication, software, and encoding, which include, for example, wireless communication systems, and more particularly, methods, architectures, devices, and systems for user equipment mobility within a wireless network.
Background Art
[0002] Cross - reference to Related Applications This application claims the benefit of U.S. Patent Provisional Application No. 63 / 463,160, filed on May 1, 2023, which is incorporated herein by reference.
[0003] User equipment mobility results in cell changes for service continuity. Legacy mobility procedures mainly operate in the radio resource control layer, also known as layer 3 (L3). The network and the user equipment will exchange messages, measurements, and configurations prior to a cell change.
[0004] In the case of a network that employs a high carrier frequency, which results in narrow - beam transmissions that require a very high - density deployment, the conventional mobility framework based on upper - layer measurements, cell measurements, reporting, cell change / update determination, and execution involves a very large overhead and introduces latency far exceeding the time scale of mobility events.
[0005] There is a need to improve the mobility of user equipment within a wireless network.
Summary of the Invention
Means for Solving the Problems
[0006] In one embodiment, a method implemented in a wireless transceiver unit may include the step of transmitting a first message to a network containing first information relating to non-radio measurement capability. The method may further include the step of receiving a second message from the network containing second information indicating a first configuration for determining the zone location of a WTRU based on non-radio measurement capability. The method may further include the step of receiving a third message from the network containing third information indicating a plurality of mobility configurations and a second configuration of reporting trigger events based on non-radio measurement. The method may further include the step of determining the WTRU zone location based on the first configuration for determining the zone location. If a reporting trigger event among the configured reporting trigger events is met, the method may further include the step of transmitting a fourth message to the network indicating the determined zone location. Depending on the step of sending a fourth message, the method may further include receiving a command message from the network containing information for performing a cell switch to a target cell associated with one of several mobility configurations, and performing a cell switch to the target cell based on the command message.
[0007] In another embodiment, a method implemented in a wireless transceiver unit may include the step of transmitting a first message to the network containing information about non-wireless measurement capabilities. The method may further include the step of receiving a second message from the network containing information about network coverage and deployment topology. The method may further include the step of receiving a third message from the network containing a plurality of mobility configurations and information indicating non-wireless measurements for network coverage and deployment topology. The method may further include the step of determining one or more changes in non-wireless measurements. The method may further include the step of determining a WTRU zone location based on non-wireless measurements from non-wireless measurements, and based on network coverage and deployment topology. The method may further include the step of transmitting the determined zone location to the network. The method may further include the step of receiving a command message from the network containing information for performing a cell switch to a target cell associated with one of the plurality of configurations, and the step of performing a cell switch to the target cell based on the command message.
[0008] In another embodiment, a method implemented in a wireless transceiver unit may include the step of transmitting a first message to a network containing information about non-wireless measurement capabilities. The method may further include the step of receiving a second message from the network containing information about a configuration for determining zone information of a WTRU. The method may further include the step of receiving a third message from the network containing a plurality of mobility configurations and a plurality of non-wireless measurement configurations associated with a plurality of zone information. The method may further include the step of determining zone information based on the second message. The method may further include the step of determining one non-wireless measurement from a plurality of non-wireless measurements associated with the zone information, and the step of performing the determined non-wireless measurement based on the determined zone information. [Brief explanation of the drawing]
[0009] A more detailed understanding can be obtained from the following detailed description, which is given as an example along with the drawings attached to this specification. The figures in such drawings, as well as the detailed description, are examples. Therefore, the figures and detailed description should not be considered limiting, and other equally valid examples may be possible. Furthermore, similar reference numbers in the figures indicate similar elements.
[0010] [Figure 1A] This is a system diagram illustrating an exemplary communication system. [Figure 1B] Figure 1A is a system diagram showing an exemplary wireless transceiver unit (WTRU) used in the communication system. [Figure 1C] Figure 1A is a system diagram showing exemplary radio access networks (RAN) and core networks (CN) used within the communication system shown. [Figure 1D] Figure 1A is a system diagram showing further exemplary RAN and CN used within the communication system. [Figure 2]This is a sequence diagram showing an example of a handover procedure. [Figure 3] This is a sequence diagram showing an example of a conditional handover procedure. [Figure 4A] This is a system diagram showing an example of a single downlink control information-based multi-TRP transmission. [Figure 4B] This is a system diagram showing an example of multi-downlink control information-based multi-TRP transmission. [Figure 5] This flowchart shows an example of updating WTRU coverage information and lower layer triggered mobility (LTM) configuration. [Figure 6] This flowchart shows an example of an LTM measurement framework based on reporting structure. [Figure 7] This flowchart shows an example of an LTM measurement framework based on measurement identifiers. [Figure 8] This flowchart shows an example of an LTM measurement framework that combines reporting and quantitative components. [Figure 9] This block diagram shows an example of an LTM measurement model using L1 / L2 filtering. [Figure 10] This block diagram shows an example of an LTM measurement model using L1- and L3-based events. [Figure 11] This block diagram shows an example of an LTM measurement model using measurement bias. [Figure 12] This block diagram shows an example of an integrated measurement model using separate parameter sets for L3 and LTM measurements. [Figure 13] This flowchart shows an example of a network-controlled LTM procedure triggered by non-wireless WTRU measurement. [Figure 14] This flowchart shows an example of how to activate the LTM configuration based on WTRU-reported zone information. [Figure 15]A flowchart illustrating an example of a method implemented in a wireless transmit / receive unit (WTRU) that performs cell switching based on WTRU zone location, according to one embodiment. [Figure 16] A flowchart illustrating an example of a method implemented in a WTRU for performing cell switching based on WTRU zone location, according to another embodiment. [Figure 17] A flowchart illustrating an example of a method implemented in a WTRU for performing non-radio measurements based on WTRU zone information, according to one embodiment. **DETAILED DESCRIPTION OF THE INVENTION**
[0011] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively "provided") herein. It is to be understood that various embodiments described and / or claimed herein of apparatuses, systems, devices, etc., and / or any elements thereof, performing operations, processes, algorithms, functions, etc., and / or any portions thereof, assume that any apparatus, system, device, etc., and / or any elements thereof, are configured to perform any operations, processes, algorithms, functions, etc., and / or any portions thereof.
[0012] The methods, apparatus, and systems provided herein are suitable for communications involving both wired and wireless networks. Outlines of various types of wireless devices and infrastructure are provided with respect to Figures 1A to 1D, where various elements of the network may utilize, implement, and be arranged in accordance with the methods, apparatus, and systems provided herein, as well as adapt and / or be configured for them.
[0013] Figure 1A is a system diagram showing an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple radio users. The communication system 100 can enable multiple radio users to access such content through the sharing of system resources, including radio bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).
[0014] As shown in FIG. 1A, communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access network (RAN) 104 / 113, core network (CN) 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, but it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may each be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals, and may include (or be) a 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, wristwatch or other wearable, head-mounted display (HMD), vehicle, drone, medical device and application (e.g., remote surgery), industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), home electronic device, device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may also be referred to interchangeably as a UE.
[0015] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or network 112. As an example, base stations 114a and 114b may be any of the following: base station transceiver station (BTS), node B (NB), e-node B (eNB), home node B (HNB), home e-node B (HeNB), g-node B (gNB), NR node B (NR NB), site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will 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 a base station controller (BSC), a radio network controller (RNC), and relay nodes. 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 called cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide coverage for radio services to a particular geographic area that may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, which may utilize multiple transceivers for each sector of the cell or any sector. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.
[0017] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 may be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
[0018] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRU 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).
[0019] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as Advanced UMTS Terrestrial Radio Access (E-UTRA), which can establish an air interface 116 using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).
[0020] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).
[0021] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base stations 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, and 102c may be characterized by multiple types of radio access technologies and / or transmissions from / to multiple types of base stations (e.g., eNBs and gNBs).
[0022] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Advanced Data Rate (EDGE), and GSM EDGE (GERAN).
[0023] In Figure 1A, base station 114b may be, for example, a wireless router, home node B, home enode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, premises, industrial facilities, aerial corridors (for use by drones, for example), and roads. In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRU 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any small cell, picocell, or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.
[0024] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing one of the following technologies: GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.
[0025] CN106 / 115 can also act as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (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 employ the same RAT as RAN104 / 114 or a different RAT.
[0026] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 can include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which can employ cellular-based radio technology and may be configured to communicate with base station 114b which can employ IEEE 802 radio technology.
[0027] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the above elements while remaining consistent with one embodiment.
[0028] The processor 118 may be a general-purpose processor, a dedicated 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. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transceiver element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together, for example, in an electronic package or chip.
[0029] The transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmitting / receiving element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In one embodiment, the transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of radio signals.
[0030] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 can include any number of transmit / receive elements 122. For example, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.
[0031] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal to be received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.
[0032] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 can access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data therein.
[0033] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to 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.), a solar cell, a fuel cell, 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) regarding 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 the air interface 116 and / or determine its location based on the timing of when signals are received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information via any preferred location determination method while remaining consistent with one embodiment.
[0035] The processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency-modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The element / peripheral device 138 may include one or more sensors, the sensors being one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.
[0036] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of a signal may be parallel and / or simultaneous, associated with a specific subframe for both an uplink (for transmission, for example) and a downlink (for reception, for example). The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing either through hardware (e.g., chokes) or through a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU102 may include a half-duplex radio, which is for the transmission and reception of some or all of a signal (e.g., associated with a specific subframe for either an uplink (for transmission, for example) or a downlink (for reception, for example).
[0037] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.
[0038] RAN104 may include enodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of enodes B while remaining consistent with one embodiment. Each of enodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, enodes B160a, 160b, and 160c can implement MIMO technology. Thus, enode B160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a.
[0039] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.
[0040] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the above elements is shown as part of CN106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the CN operator.
[0041] The MME162 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.
[0042] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.
[0043] SGW164 may be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.
[0044] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and legacy landline communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 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] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).
[0046] In a typical embodiment, the other network 112 may be a WLAN.
[0047] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with distributed systems (DSs) or other types of wired / wireless networks that carry traffic during and / or from the BSS. Traffic originating outside the BSS to the STAs may arrive through the APs and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the APs to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent through the APs; for example, a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS is considered and / or sometimes referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In some typical embodiments, the DLS may be an 802.11e DLS or an 802.11z tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (for example, all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the “ad-hoc” communication mode in this specification.
[0048] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS, which can be used by STAs to establish a connection with the AP. In some typical embodiments, Carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. In CSMA / CA, an STA, including the AP (e.g., any STA), can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA can backoff. One STA (e.g., only one station) can transmit at any given time within a given BSS.
[0049] A high-throughput (HT) STA can use a 40MHz wide channel for communication, for example, via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.
[0050] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, data can be passed through a segment parser that, after channel encoding, can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC) layer, entities, etc.
[0051] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for some and / or limited bandwidths (e.g., support only for that). MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).
[0052] A WLAN system that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode from among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and could be available.
[0053] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.
[0054] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.
[0055] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while remaining consistent with one embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, the gNB180a, 180b, and 180c can implement MIMO technology. For example, the gNB180a and 180b can utilize beamforming to transmit signals to and / or receive signals from the WTRU102a, 102b, and 102c. Thus, the gNB180a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from the WTRU102a. In one embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c can implement coordinated multi-point (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).
[0056] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may differ for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (including, for example, a varying number of OFDM symbols and / or a varying length of absolute time that persists).
[0057] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (such as e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.
[0058] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, routing of control plane information to access and mobility management functions (AMF) 182a and 182b, etc. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.
[0059] The CN115 shown in Figure 1D 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 above elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0060] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, mobility management, etc. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service being utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b can provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.
[0061] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a 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] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN113, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184a and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.
[0063] CN115 can facilitate communication with other networks. For example, CN115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 can provide WTRU102a,102b,102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a,102b,102c may be connected to DN185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b, and an N6 interface between UPF184a,184b and local data networks (DN) 185a,185b.
[0064] In view of Figures 1A to 1D and their corresponding descriptions, one or more, or all, of the functions described herein with respect to any of the WTRU 102a to d, base stations 114a to b, e-nodes B160a to c, MME 162, SGW 164, PGW 166, gNB 180a to c, AMF 182a to b, UPF 184a to b, SMF 183a to b, DN 185a to b, and / or any other (one or more) elements / devices described herein may be implemented by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.
[0065] Emulation devices may be designed to implement one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more, or all, of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in a communication network. One or more emulation devices may perform one or more, or all, of the functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for testing purposes and / or tests may be performed using over-the-air wireless communication.
[0066] One or more emulation devices can perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory and / or in a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., including one or more antennas) may be used by an emulation device to transmit and / or receive data.
[0067] WTRU mobility can lead to cell changes for service continuity. Legacy mobility procedures primarily operate at the Radio Resource Control (RRC) layer, also known as Layer 3 (L3). The network and WTRUs will exchange messages, measurements, and configurations before a cell change occurs. In the following description, the protocol stack as Layer 1, Layer 2, and Layer 3 can be defined as follows: Layer 1 is the physical layer. Layer 2 can include the MAC layer, the Radio Link Control (RLC) layer, and the Packet Data Convergence Protocol (PDCP). Layer 3 is the RRC layer.
[0068] In one embodiment, the L3 mobility procedure may be a gNB handover procedure, also known as a legacy handover. When the WTRU is in RRC connection mode, cell / gNB level mobility may require explicit RRC signaling to be triggered. The WTRU may report a cell quality measurement to its serving (source) cell when the neighboring cell quality is offset more favorably for a predetermined duration of the trigger time (TTT). Different events, such as A1, A2, A3, A4, A5, etc., may be defined for WTRU measurement report triggering. The TTT and cell-specific offset may be specified during the measurement configuration step. If a handover (HO) determination is made based on the measurement report, the source gNB may issue a handover request to the target gNB. If the WTRU is approved by the target gNB, the target gNB may send a handover request acknowledgment to the source gNB, which contains the RRC message to be sent to the WTRU. Next, the source gNB can initiate the handover and send an RRC reconfiguration message to the WTRU. It can also include a set of dedicated Random Access Channel (RACH) resources. Finally, the WTRU can synchronize with the target cell and complete the RRC handover procedure. The overall HO procedure is shown in Figure 2.
[0069] Referring to Figure 2, in step 1, the source gNB can configure the WTRU measurement procedure 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 issue a handover request message to the target gNB, passing a transparent RRC container with the necessary information to prepare the handover on the target side. In step 4, acknowledgment control can be performed by the target gNB. In step 5, the target gNB can prepare a handover by Layer 1 and / or Layer 2 (L1 / L2) and send a handover request acknowledgment to the source gNB, which may include a transparent container to be sent to the WTRU as an RRC message to perform the handover. The target gNB may also indicate whether a Dual Active Protocol Stack (DAPS) handover is acceptable. In step 6, the source gNB triggers the handover by sending an RRC reconfiguration message to the WTRU containing the necessary information to access the target cell.
[0070] In step 7a, if the data radio bearer (DRB) is configured with DAPS, the source gNB can send an EARLY STATUS TRANSFER message.
[0071] In step 7, for data radio bearers (DRBs) not configured with DAPS, the source gNB can send an SN STATUS TRANSFER message to the target gNB to communicate the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the DRB to which PDCP status saving applies.
[0072] In step 8, the WTRU can synchronize with the target cell and complete the RRC handover procedure by sending the RRCReconfigurationComplete message to the target gNB. In the case of a DAPS handover, the WTRU may not detach from the source cell upon receiving the RRCReconfiguration message.
[0073] In steps 8a and 8b, in the case of a DAPS handover, the target gNB may send a HANDOVER SUCCESS message to the source gNB to indicate that the WTRU has successfully accessed the target cell. In response, the source gNB may send a STATUS TRANSFER message for the DRB configured by 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 toward the target gNB and establish an interface instance toward the target gNB. The core network can switch the DL data path toward the target gNB. The core network (e.g., UPF) can send one or more "end marker" packets on the old path toward the source gNB for each PDU session / tunnel, and then release any U-plane / TNL resources toward the source gNB. The core network (e.g., AMF) can acknowledge the PATH SWITCH REQUEST message with a PATH SWITCH REQUEST ACKNOWLEDGE message.
[0075] In step 10, upon receiving a PATH SWITCH REQUEST ACKNOWLEDGE message from the core network (e.g., AMF), the target gNB can send a WTRU CONTEXT RELEASE to inform the source gNB of the successful handover.
[0076] The HO process may fail due to insufficient channel quality in the target gNB, source gNB, or both. In scenarios with directional links, mobile blockers or WTRU rotation can rapidly degrade the link quality of the target and source gNBs, exacerbating handover problems. Interference with the target gNB during the handover procedure can result in a handover failure (HOF). The handover failure timer can be started when the WTRU receives an RRC reconfiguration message. If the handover failure timer expires before the handover is complete, an HOF can be declared, and the WTRU can perform connection re-establishment. After a sudden WTRU rotation or interference, the source gNB may not be able to start the handover procedure in time based on the most recent measurement report. Even measurement reports from the WTRU can be lost due to insufficient link quality. Therefore, without handover assistance from the source gNB, even when there is a potential target gNB with good channel quality, the WTRU may need to either wait for the source gNB to recover from the outage or declare a radio link failure (RLF).
[0077] As a potential solution to the failure of the target gNB, Dual Active Protocol Stack (DAPS) handover was specified in 3GPP Rel.16. In a 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 degrades before random access is complete, the WTRU can fall back to the source gNB.
[0078] To address interference with the source gNB, a Conditional Handover (CHO) was specified in 3GPP Rel. 16. In a CHO, a 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 evaluate the CHO execution conditions defined for the candidate gNB. When the conditions are met, for example, when the target gNB has a better offset than the source gNB, the WTRU can initiate a handover to the target gNB without signaling from the source gNB. Therefore, even when the source gNB is stopped due to sudden interference or rotation, the WTRU can still successfully complete a handover with the target gNB if the CHO execution conditions are met. The overall CHO procedure is shown in Figure 3.
[0079] Referring to Figure 3, in step 1, the source gNB can configure the WTRU measurement procedure and WTRU report according to the measurement configuration. In step 2, the source gNB can decide to use CHO. In step 3, the source gNB can request 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, approval 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 cell. A CHO response message can be sent for each candidate cell. In step 6, the source gNB can send an RRCReconfiguration message to the WTRU, including the configuration of the CHO candidate target cell (e.g., target gNB) and the CHO execution conditions. The WTRU can send an RRCReconfigurationComplete message to the source gNB. 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 for the candidate cell. If at least one CHO candidate cell satisfies the corresponding CHO execution conditions, the WTRU can detach from the source gNB, apply the stored corresponding configuration for its selected candidate cell (e.g., a potential target gNB), synchronize with that candidate cell, and complete the RRC handover procedure by sending an RRCReconfigurationComplete message to the target gNB. After the successful completion of the RRC handover procedure, 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 indicate that the WTRU 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 may cancel the CHO for the WTRU by sending a HANDOVER CANCEL message to any other signaling connections or other candidate / potential target gNBs.
[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 toward the target gNB and establish an interface instance toward the target gNB. The core network can switch the DL data path toward the target gNB. The core network (e.g., UPF) can send one or more "end marker" packets on the old path toward the source gNB for each PDU session / tunnel, and then release any U-plane / TNL resources toward the source gNB. The core network (e.g., AMF) can acknowledge the PATH SWITCH REQUEST message with a PATH SWITCH REQUEST ACKNOWLEDGE message.
[0082] In step 10, upon receiving a PATH SWITCH REQUEST ACKNOWLEDGE message from the core network (e.g., AMF), the target gNB can send a WTRU CONTEXT RELEASE to inform the source gNB of the successful handover.
[0083] While CHOs are resilient to mobile blockers and can significantly reduce the number of RLFs resulting from links that degrade quickly, their success may depend on the availability of candidate gNBs prior to source link failure, the link quality of the target link, and conditional thresholds for the target gNB. Even when candidate gNBs are available, the WTRU may need to maintain link quality with the selected candidate gNB until the handover is complete. Careful configuration of conditional thresholds for handover execution may also be required. Higher thresholds may lead to the WTRU failing to perform a timely handover to the target gNB, resulting in a failed handover. On the other hand, lower thresholds may lead to a suboptimal selection of a new serving gNB, potentially resulting in a potentially unnecessary handover.
[0084] The multi-transmit-receive-point (TRP) transmission mechanism may be limited to INTRA-CELL and may be specified to support non-coherent 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: a single downlink control information (DCI)-based one and a multi-DCI-based one, as shown in Figures 4a and 4B.
[0085] Referring to Figure 4A, since a single DCI schedules resources from two TRPs, single DCI-based transmission can be more suitable for ideal backhaul between TRPs. To receive DL data from different TRPs (TRP1, TRP2), the WTRU can have two Transmit Configuration Indication (TCI) states, each TCI state can correspond to one TRP and provide quasi-co-location (QCL) information for the corresponding PDSCH layer. Different TCI code points can be activated by MAC, and the scheduling DCI can indicate one of the activated TCI code points having two TCI states.
[0086] Referring to Figure 4B, the multi-DCI-based scheme can support scenarios with non-ideal backhauls, 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 set (CORESET) groups, each identified by the value of the RRC parameter CORESETPoolIndex.
[0087] Multi-TRP operation can be extended to inter-cell cases. This can be achieved by allowing the TCI state to be defined from a Synchronization Signal Block (SSB) where the WTRU is associated with a different Physical Cell Identification Information (PCI) than the RRC-connected cell, and this enables inter-cell multi-TRP operation by proper configuration / activation of the TCI state which can be associated with any of the PCIs.
[0088] For networks employing higher carrier frequencies, which result in narrow beam transmissions requiring extremely high-density deployments, legacy mobility frameworks based on upper-layer measurements, cell measurements, reporting, cell change / update determination, and execution can incur very high overhead and lead to latencies far exceeding the timescale of mobility events.
[0089] Layer 1 and / or Layer 2 triggered mobility (LTM) can minimize mobility interruptions. Significant reductions in mobility interruptions 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 deployments, can lead to a more deterministic approach to mobility handling.
[0090] The following issues need to be resolved in order to achieve deterministic L1L2 triggered mobility using non-wireless measurements: How should L1L2 mobility features focused on measurements and events set for non-wireless measurements be enabled? Also, what are the configurations, execution conditions, triggers, and step-by-step actions for such an L1L2 triggered mobility procedure?
[0091] In the various embodiments described below, non-wireless measurement-based solutions for minimizing mobility interruptions are detailed.
[0092] The evolution of wireless systems, with new applications requiring low latency, high reliability, and high availability, has brought greater attention and activity to service continuity during mobility and minimizing service interruptions caused by mobility. To this end, 3GPP has defined and standardized several mechanisms to minimize mobility interruptions through faster switching of beams, cells, and network nodes.
[0093] The various embodiments described below can achieve lower-layer triggered mobility, primarily triggered by measurements against non-radiometric quantities, in order to achieve nearly deterministic mobility. The proposed methods for non-radiometric-based mobility rely on (i) knowledge of its node / cell / beam network deployment, as well as (ii) the WTRU's ability to perform non-radiometric measurements in different forms, such as tracking the WTRU's movement and determining its updated geographical location / position and orientation in a highly accurate manner, and (iii) a network that combines deployment information with WTRU reports of non-radiometric measurements to determine (e.g., preferred) target LTM candidates and move the WTRU from its serving cell to such determined LTM targets.
[0094] This approach can be applicable when the environment is controlled, the network knows what is around the moving device / WTRU, and therefore implies that the radio conditions are deterministic with respect to reporting of non-radio measurements relating to the WTRU location / position and orientation. For this purpose, the various embodiments below can be applicable to non-public and / or private networks. The various embodiments below can also be applicable in industrial / factory settings where knowledge of the environment is tightly controlled and known to the operator deploying the network, the operator is often the industrial owner or someone working for them. Another scenario for controlled environments can be a bit more futuristic, where the operator has such precise information about the environment through other sources (topography, visual images, live cameras, etc.) and even in a public network setting, the network dynamics and environmental changes are known.
[0095] In public cellular networks, operators may hesitate to fully share deployment configurations with devices because it can introduce a certain level of risk to their installation. One important aspect of controlled environments and factory settings, such as warehouses, is the fact that communication devices (such as robots and industrial machinery) are also installed and operated by the same owner. This provides assurance that the network topology configuration will not be used for any purpose other than that for which it is shared with the devices. To make the various proposed embodiments more widely available while securely preserving sensitive information, deployment topologies are provided in different forms, with zones featuring indications of cells / beams of interest within that zone.
[0096] In different settings, the LTM strategy can be useful when the relevant devices have limited measurement capabilities due to power constraints, hardware limitations, or antenna / panel implementation limitations, and therefore, network determination is primarily based on non-wireless measurements.
[0097] In the various embodiments described below, the proposed LTM strategy can be broadly divided into two main stages. The first stage may be a non-wireless measurement-based LTM preparation stage. The second stage may be an implementation stage.
[0098] The WTRU's ability to rapidly detect its location / orientation and geographic coordinates in a highly accurate manner can be used to select the nodes / cells / beams to which the WTRU should connect. The network can share a finite portion of its deployment / coverage topology with the WTRU, which the WTRU uses to report its precise instantaneous coverage coordinates to the network. Details regarding the content, configuration, maintenance, signaling mechanisms, and WTRU post-processing of the coverage topology are provided below.
[0099] In various embodiments, the LTM procedure can utilize non-wireless measurements. Measurement frameworks for both wireless and non-wireless measurements are also provided below. This framework can be used for measurements on 3GPP wireless signals, non-3GPP wireless signals, local sensors, and data from other interfaces. To reduce latency and achieve a certain level of stability and accuracy in the measurements, different measurement models can select the measurement quantity from either L1, L3, or a combination of the former.
[0100] If the LTM procedure operates solely on wireless measurements, a ping-pong effect may occur, where the WTRU may switch back and forth within a group of cells due to noise and fading that affect the quality of wireless signal estimation. Using non-wireless measurements helps eliminate this problem.
[0101] In various embodiments, the LTM procedure can be network-controlled. The network can explicitly issue commands for the WTRU to switch from its serving cell to a target cell. Network determination can be the result of the WTRU performing measurements and reporting them to the network.
[0102] Lower-layer triggered mobility or L1L2 triggered mobility (LTM) is used herein as a term to refer to procedures in which cell switching triggers, commands, and confirmations are exchanged primarily over the lower layers of the WTRU and network, in contrast to legacy mobility procedures that operate via RRC or Layer 3. These lower layers are the PHY layer, the MAC layer, or a combination of both, as detailed in the following embodiments.
[0103] The preparatory steps for non-wireless measurement-based LTM procedures can essentially include configuring the deployment topology, configuring the LTM cells, configuring the measurements, and transferring WTRU capabilities to the network to support the procedure.
[0104] With respect to deployment and coverage zones, a cellular network can be a planned network with operators deploying network nodes in (e.g., suitable) locations to provide sufficient coverage to its subscribers. Thus, a network operator can have (e.g., very precise) knowledge of the deployment of cells and the beams within those cells with respect to coverage zone attributes, such as the location of cells or transmit points (TRPs) (e.g., reference location), beamwidth information such as three-dimensional (3D) beamwidth information, including the potential spatial directions of transmission, e.g., horizontal and vertical, defined by the azimuth, elevation, and location coordinates of the TRP, and coverage shape information, including beam, cell, or TRP coverage boundary location coordinates.
[0105] The deployment topology may include information regarding the location of the TRP and the beam coverage / orientation. In one embodiment, the TRP location can be represented in 2D coordinates, an example of which are latitude and longitude coordinates. This location can also be represented in 3D coordinates, which are the 2D coordinates plus altitude or height. Both the 2D and 3D representations can be in a global or local coordinate system.
[0106] A beam from a given TRP can be represented using azimuth and elevation angles. Preferred references such as cardinal direction and zenith can be used, or the reference direction can be provided as part of the configuration. These angles can be refined or quantized to meaningfully capture in-coverage or out-of-coverage mobility procedures and signal strength for a given beam. In addition to angles, beam widths in these directions can be explicitly provided for the beam. Thus, with knowledge of TRP location parameters and beam angles (plus width), a WTRU can prepare a local topology that allows it to view the coverage of different beams from different TRPs. Additional attributes such as range / power can be added to cells / beams to further refine the deployment topology.
[0107] A coverage topology can provide indications of geographical coverage from different TRPs for different beams. Through representation, it can provide coverage boundaries for different TRPs and different beams. A coverage topology can incorporate terrain properties, geomorphological features, buildings, and other geographic parameters into the unfolded topology to prepare zones and boundaries associated with the coverage of different beams from different TRPs.
[0108] The representation of coverage topology can be in the form of (for example, preferred) geometric shapes. Different reference shapes can be defined to indicate the shapes that define cell / beam level coverage. The reference shapes can be in the form of circles, ovals, ellipsoids, or ellipsoids with (for example, preferred) parameterization. Coverage topology can be represented using these shapes with (for example, preferred) attributes. These attributes can provide a link to cell / beam identification information to which a given shape / area is associated.
[0109] The terms “deployment topology” and “coverage topology” are interchangeable herein. Where a distinction is necessary, it will be explicitly mentioned.
[0110] A coverage topology can be associated with an area referred to here as a coverage topology area. A coverage topology area can correspond to one or more cells, a RAN notification area (RNA), a tracking area (TA), a public land mobile network (PLMN), and so on.
[0111] Coverage topology can be defined at different levels of granularity. The granularity of coverage topology can be part of the coverage topology configuration. In one embodiment, coverage topology can be defined at the cell level, and geographical coverage information from different gNBs / TRPs can be indicated to the WTRU by (for example, preferred) signaling. Cell-level coverage can be useful for different handover and cell change procedures.
[0112] The coverage topology granularity can be reflected in the form of coverage zones. In the case of cell-level procedures, the coverage topology zones may have cell-level granularity. For example, in the case of beam-level procedures, where a WTRU may need to track, maintain, or switch beams, the coverage topology granularity can be defined at the beam level, and zones in such a coverage topology may belong to different beams.
[0113] A zone can be assigned to a given beam from a given TRP. Further refined granularity can be achieved by defining and associating zones in different directions from each gNB or TRP. Zones in a coverage topology can represent geographical areas corresponding to a given set of reference signals. In the case of beam-level zones, in one design, each zone may represent a coverage area for synchronization signal and physical broadcast control channel block (SSB) beams. In another beam-level zone design, each zone may represent a coverage area for an SSB beam or a channel state information reference signal (CSI-RS) beam, where SSB / CSI-RS beam is the coverage for the corresponding SSB / CSI-RS signal. The configuration can specify one-to-one or one-to-many correspondences, where one-to-many correspondences can exist when the criterion for zone delimitation is some other signal or GPS coordinates instead of SSB. A one-to-many correspondence can also exist in overlaid networks, where multiple cells / beams can serve overlapping areas.
[0114] Each zone can be identified by identification information, which may be provided as part of the configuration. In an alternative design, each zone identification information may be a deterministic combination of the identification information of the cell, TRP, and SSB / CSI-RS beam to which it belongs. The formula for calculating the zone identification information may be known a priori to the network and devices, and may use additional modulation parameters such as the length, width, and number of SSB beams, which may be part of the system information or configuration.
[0115] Different granularities for zones can be gNB, TRP, or cell level. In the case of cell-level zones, a zone can indicate an area where this cell has sufficient coverage. Criteria for sufficient coverage can be specified in relation to existing cell selection, re-selection criteria, or new criteria associated with (e.g., a preferred) reference signal. A cell-level zone can group all SSB / CSI-RS zones associated with a given cell, and therefore it represents an area where any SSB / CSI-RS signal for this cell can be received at a known / configured quality. Similarly, zone representations can be extended to larger granularities for RNA, tracking area (TA), or PLMN-based coverage zones. Cell-level zone identification information can be cell identification information, or a deterministic modification of cell identification information by combining it with some other parameters. The same design can be used for zones to represent coverage for RNA, TA, PLMN, etc.
[0116] In one embodiment, a zone can be defined for each location using its longitude and latitude values. Zone length information can be provided as part of the configuration. Formulas for calculating zones can be predefined or signaled as part of the configuration from a predefined set. Zone design can facilitate the calculation of zone identification information. In the above zone design, the longitude and latitude values are geodetic distances from geographic coordinates (0,0), as used in the NR sidelink framework. (For example, preferred) parameters can be provided as part of the configuration for determining zone modularity along the longitude and latitude directions. The same modularity along the longitude and latitude directions can be determined using only a single parameter. This parameter can be a fixed value to simplify configuration. In this design, all devices can calculate their zones and zones for any location relative to the longitude and latitude coordinates of that location.
[0117]
[0118] An example of a deployment topology may include information about the location of the TRP and beam coverage / orientation. In one example, the TRP location can be represented in 2D coordinates, an example of which are latitude and longitude coordinates. This location can also be represented in 3D coordinates, which are the 2D coordinates plus altitude or height. Both 2D and 3D representations can be in a global or local coordinate system. If the zone configuration follows a side-link design, the TRP location can be provided for the zone instead of longitude and latitude coordinates.
[0119] A beam from a given TRP can be represented using azimuth and elevation angles. Preferred references such as the cardinal direction and zenith can be used, or the reference direction can be provided as part of the configuration. These angles can be refined or quantized to meaningfully capture in-coverage or out-of-coverage mobility procedures and signal intensity for a given beam. In addition to angles, beam widths in these directions can be explicitly provided for the beam.
[0120] The network can directly provide configuration in rich geomorphic form, capturing all detailed aspects of the local terrain, shadowed by buildings and other objects. One advantage of this approach is that the network not only knows its cell / TRP and beam deployments precisely, but it can also have access to geomorphic data using ongoing measurements of cells / beams from navigation systems, cameras, and devices that inform it of a very precise coverage topology. One other advantage is the use of all historical data in the form of network measurements and cell / beam transitions, which can be used to update and improve such a 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 communicated to the WTRU. The (e.g., large) signaling overhead may also lead to increased configuration latency, as it requires several message exchanges at the RRC level.
[0121] If the zone configuration follows a side-link design, the network can provide different cell and beam coverage indications that provide the association of these cells and beams to the zone.
[0122] The topology configuration can be a hybrid of the two previous methods, with some parts represented in the form of a network deployment-based configuration and others represented using a coverage topology-based configuration.
[0123] In one embodiment, the initial configuration for the coverage topology can be communicated to the WTRU in the form of dedicated RRC signaling. The WTRU, in an RRC active state with mobility, can be provided with the initial coverage topology configuration. From the WTRU's perspective, the signaling can be dedicated, but the network can provide the same information to a set of WTRUs. These WTRUs can be in close proximity to each other, and therefore the same coverage topology can be associated with them.
[0124] In one embodiment, a network (e.g., a base station) can broadcast coverage topology information. A new coverage topology system information block (SIB) can be specified. In this case, it is understood that 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.
[0125] In many relevant cases, the initial configuration may provide a coarse coverage topology that may need to be improved to (e.g., suitable) granularity and coverage expansion for sufficient usefulness. To this end, the coverage topology can be suitably improved through dedicated signaling. Improvements can be initiated by the network when it constitutes certain applications / flows with QoS constraints requiring proactive mobility. WTRUs can request improvements to their coverage topology.
[0126] The network deployment topology can be shared with WTRUs following the configuration proposed above, either by adding additional attributes to the cell configuration or by introducing new configurations with these geographical attributes and providing links to these TRP / beam-level configurations in the legacy cell configuration. For use in mobility events and in the effective selection of beams, cells, and TRPs, WTRUs may need to have a detailed and effective coverage topology, which may be called an on-the-ground coverage topology. Questions still remain about how to make the deployment topology rich enough so that it captures all geographical and shadowing aspects. This coverage topology should not only take into account TRP locations and beam attributes, but it should also incorporate the physical properties of the surrounding environment, including topographic details and buildings with all their physical attributes that may shadow, block, or reflect beams.
[0127] Below, two embodiments are proposed that enable the WTRU to capture / create a ground coverage topology.
[0128] In the first embodiment, the deployment configuration provided by the network can be made very rich and refined, and provided in the form of rich shapes that capture all detailed aspects of the local terrain, shadowing from buildings and other objects. Different reference shapes can be defined to indicate shapes that define cell / beam level coverage. The reference shapes can be in the form of circles, ovals, ellipsoids, or ellipsoids with (preferred) parameterization. The network will then indicate these shapes with (preferred) attributes and provide links to their cell / beam identification information. One advantage of this scheme can be that the network can know (preferably / accurately) its cell / TRP and beam deployments. It can have access to geomorphological data using ongoing measurements of cells / beams from navigation systems, cameras, and devices that inform it of a very precise coverage topology. One other advantage can be the use of all historical data of network measurements, cell / beam transitions, which can be used to update and refine such detailed coverage topology. This approach can have (for example, large) signaling overhead. Even precise coverage for a single beam may require a set of objects and their attributes to be communicated to the WTRU, so the amount of information that needs to be exchanged can be enormous. The (for example, large) signaling overhead requires several message exchanges at the RRC level and can also lead to increased configuration latency.
[0129] In a 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 technique can be used when the network (primarily, for example) provides its deployment configuration. In this second embodiment, the network can provide information about TRP locations, beam angles, and beam-specific parameters without modulating coverage with local terrain features. Because the information is less extensive compared to the first embodiment where the network provides a detailed coverage topology, the signaling overhead and latency performance of this technique can be significantly better than the former.
[0130] In this second embodiment, the device may be assumed to obtain TRP / beam deployment features / parameters and use local knowledge through other techniques (locally stored topography, positioning systems, cameras) to prepare an improved coverage topology that adds geomorphological features to the deployment configuration. After local processing and fabrication, the WTRU can obtain a valid topology that can define different coverage zones associated with different beams and cells. This improved coverage topology can then be used in beam and cell-level mobility procedures in this WTRU. This local physical coverage topology can be improved with mobility or additional information obtained from other sensors. The device can prepare this valid topology using deployment parameters provided by the network combined with information from local sensors, so this can be supported by local sensors, additional storage capacity, and computing power to prepare the valid topology by combining network deployment with information from local sensors.
[0131] Hybrid solutions can be standardized in devices to obtain improved coverage topologies. If there are devices without local sensors, or if they lack the computing power to process and fabricate topologies themselves, the network can send the improved topology to such devices. Conversely, devices with local sensors and computing / storage capabilities can receive only limited deployment features from the network and prepare a valid topology locally. Hybrid solutions can also be used depending on WTRU power consumption requirements, battery quality, remaining battery, or active applications and their attributes.
[0132] Upon detection of a change in coverage topology area, the WTRU can recapture the coverage topology for its current location. Recapture can take the form of dedicated RRC signaling. In an alternative design, it can be through recapture of the coverage topology SIB. WTRU detection of a change in coverage topology area can consist of one or more of the following: (re)selection of a serving cell or a cell not belonging to the current coverage topology area; (re)selection of RNA not belonging to or corresponding to the current coverage topology area; execution of an RNA update procedure or transmission of an RNA update message to a network (e.g., a base station); (re)selection of a TA not belonging to or corresponding to the current coverage topology area; execution of a TA update procedure or transmission of a TA update message to a network (core network); and (re)selection of a PLMN not belonging to or corresponding to the current coverage topology area.
[0133] A WTRU may discard coverage topology configuration information when it becomes outdated. An outdated indication may be determined when a WTRU changes its coverage area and is unable to capture the updated coverage topology. In one embodiment, the configuration may include (e.g., explicit) timers that, upon expiration, cause the WTRU to release the configuration. These timers may be refreshed if the WTRU remains in the area associated with its current coverage topology. Coverage topology areas may be defined with respect to RNA, TA, PLMN, or another (e.g., preferred) criterion. A WTRU may receive (e.g., explicit) indications from the network to release its coverage topology configuration. A WTRU may release its coverage topology configuration when it exits the RRC active state.
[0134] The following three embodiments relate to deployment topologies that can be provided to a WTRU, relating to cell / beam configurations and mobility configurations with deployment configurations.
[0135] In the first embodiment, the deployment topology may be part of a cell / beam configuration. This cell / beam configuration may be part of a conditional (re)configuration associated with a PsCell or SCell, and therefore may be part of a conditional handover or conditional PsCell modification / addition procedure. The deployment topology may be associated with any serving cell configuration and may be used for beam management procedures, i.e., beam switching, beam failure recovery, etc. New attributes may be added to the cell configuration that can define the TRPs from which this cell is transmitting, the locations of these TRPs in a global or local coordinate system, and beam coverage attributes for the beams being transmitted through these TRPs. The configuration may provide information about an SSB beam or a CSI-RS beam. Attributes for a beam may be in the form of azimuth and elevation angles with (for example, preferred) reference directions. The reference direction may be taken from the cardinal direction or may be indicated as part of the configuration itself. Ranges for beams may be indicated for each beam attribute, or as a single value that can indicate an unobstructed range in light of the transmitted power. Beam attributes can define horizontal and vertical beam widths. A (simpler) deployment, for example, can specify a single beam width attribute for the horizontal and one for the vertical, which are assumed to be the same for all configured beams. For deployments with varying beam width sizes, the network can provide a single value for the TRP, and then a difference value for each beam. Alternatively, beam width can be provided as part of the beam configuration without TRP or cell-level indication. Another alternative is that coverage for each beam can be specified as an ellipsoid with (preferred) parameterization.
[0136] In a second embodiment, topology indication may be a separate, dedicated configuration. More specifically, in a second embodiment, topology may be provided as a separate configuration to WTRU. Coverage topology configuration may not be part of cell configuration or conditional (re)configuration. Coverage topology may depend on geographical deployment and coverage, but its configuration and signaling may be provided by the network independently of cell configuration or other conditional (re)configuration.
[0137] A coverage topology configuration can take the form of network node deployment and beam attributes, or it can take the form of detailed ground coverage incorporating geomorphological and terrain-specific features. The coverage / deployment topology configuration can provide linkage of indicated TRP locations and beam attributes to cell identification information and cell configuration.
[0138] In a third embodiment, deployment / coverage topology indications can be transmitted by the network in the form of broadcast signaling. These indications can be broadcast by the network, and the relevant devices can be informed in advance or have prior knowledge of how to obtain and decode these indications. In one approach, control information for identifying topology-related broadcast information can be broadcast, for example, through special paging or special downlink control information that informs all devices about broadcast-based topology information.
[0139] Topology indications can be treated as part of system information. New System Information Blocks (SIBs) can be designed to carry and transmit deployment / coverage topology indications. The network can keep WTRUs aware of topology information by using periodic transmissions of topology SIBs. WTRUs that may be starting related services that require minimal downtime can send a request message (e.g., an explicit one) to the network requesting the transmission of topology SIBs.
[0140] The network can provide several snapshots of its deployment / coverage topology through RRC signaling, whether broadcast-based or WTRU-specific signaling. In these cases, the network can send a MAC control element (MAC-CE) that can indicate one of the deployment / coverage topology snapshots, which can be considered the activated topology and used in the LTM procedure. A customized MAC-CE can be designed for this purpose, and the topology identification information provides a pointer to one of the topologies configured through RRC signaling.
[0141] In more reactive situations, physical (PHY)-based signaling, such as DCI, can be used to activate one of the configured topologies.
[0142] D
[0143] Mobility triggered by lower layers can be intended to change a cell, whether it be the primary cell in a master cell group, the primary cell in a secondary cell group, or any serving cell in a master / secondary cell group. The target LTM configuration can be (for example, essentially) a cell configuration. In one embodiment, the LTM configuration can be provided as part of the cell group configuration through the "CellGroupConfig" information element. In another embodiment, the LTM configuration can be provided through "SpCellConfig" or "SCellConfig," but this imposes some limitations with respect to the LTM mobility range.
[0144] One important point is that the WTRU is involved in monitoring and evaluating (e.g., several) LTM metrics, and when (e.g., several) conditions are met, events can be triggered. Details regarding LTM metrics and exemplary events are provided below. These events can be linked to several LTM configurations, and the triggering of such events then results in the WTRU applying the linked LTM candidate configurations to achieve mobility with zero or minimal disruption and burdensome network exchanges. These procedures are described below.
[0145] One of the initial goals of LTM can be to leverage the knowledge and overlap of configurations for cells deployed through the same Distributed Unit (DU) or through different DUs. Similar to high-density networks using access points to serve smaller areas through narrower beams, and the rollout of LTM features, a WTRU may potentially be configured with several LTM configurations in addition to the already supported upper-layer configurations. Supporting many LTM configurations has the advantage that a WTRU may be able to perform faster LTM switching to one of the configured LTM candidates. On the downside, 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 locally available for application in case of LTM switching, and may need to perform measurements across the configured candidates and provide reports to the network.
[0146] The following are various embodiments that can be used to describe how configurations can be provided from the network to the WTRU and how they can be maintained within the WTRU.
[0147] In the first embodiment, the network can provide individual configurations for each LTM candidate at the cell and beam granularity. This involves (e.g., very large) overhead in terms of transmission resources and WTRUs maintaining individual configurations.
[0148] In a second embodiment, the network can provide individual configurations to each LTM candidate cell. These configurations can be linked to different beams of the candidate cell. These beams can be identified through the SSB index, the CSI-RS index, or the TCI state, which represents the QCL relationship to a reference signal.
[0149] In the third embodiment, the cell configuration for each LTM candidate cell is provided as a differential configuration to a (preferred) reference configuration. This cell configuration can then be applied to the configured beam / TCI state of the candidate cell.
[0150] The (preferred) reference configuration for which the differential configuration is provided can be the primary serving cell. In the case of dual connectivity, the reference configuration can be the primary serving cell of the corresponding cell group.
[0151] In various embodiments, a reference configuration may be explicitly provided to the WTRU. The network can determine a configuration that best minimizes differential configuration size and overhead, taking into account the serving DU or neighboring DU.
[0152] In another embodiment, to minimize signaling overhead, the network may indicate a (for example, preferred) reference configuration as part of the LTM differential candidate configuration. As an example, the network may provide an LTM configuration for cell C1 as a differential configuration. Within the differential configuration for C1, a pointer may indicate a reference configuration that will be used as a reference configuration for candidate C1. The network may preferentially select this reference configuration by providing a reference to one of the cell configurations that the WTRU has and which may be cell configurations for the same DU. If the WTRU has not received any cell configurations on the same DU as candidate C1, the network may provide a pointer to a cell configuration on a different DU.
[0153] In one embodiment, the network may provide reference DU configurations associated with DUs, which are intended to provide candidates for LTM switching. DU identification information may be provided as part of these reference configurations in a preferred 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 identification information along with each candidate differential configuration.
[0154] In embodiments with reference and differential configurations, whenever the WTRU performs an LTM switchover, it will apply the complete configuration determined together from the reference and differential configurations for the LTM candidate. In case of conflicts / duplication, the WTRU can prioritize configuration values / parameters provided as part of the differential configuration.
[0155] An example of activating an LTM configuration for non-wireless measurement-based LTM is described below.
[0156] A WTRU can receive several LTM configurations from the network. Depending on application requirements, WTRU mobility levels, WTRU capability to support simultaneous LTM configurations, WTRU subscription levels, and other network-level considerations, the network may activate only a subset (e.g., only) of the configured LTM configurations. In these cases, the network may send a MAC-CE that can activate (e.g., a preferred) 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 procedure. Customized MAC-CEs can be designed for this purpose, and the LTM configuration identification information provides a pointer to the configured LTM configuration through RRC signaling.
[0157] In more reactive situations, PHY-based signaling such as DCI can be used to activate one of the configured LTM configurations.
[0158] One aspect of non-wireless measurement-based LTM is that the WTRU may perform only minimal wireless measurements on the activated LTM configuration, and in some cases, the network may configure non-wireless measurements so that the measurement overhead from the WTRU's perspective is zero, regardless of whether there are one or more LTM configurations in the ACTIVATED state. In the case of non-wireless measurement-based LTM procedures, all configured LTM configurations can be considered activated LTM configurations for final switching once they receive an LTM switching command from the network.
[0159] Figure 5 is a flowchart showing an example of updating WTRU coverage information and LTM configuration.
[0160] More specifically, according to step 510, the network can provide the initial configuration of the LTM candidate cell / beam to the WTRU in the RRC_Connected state.
[0161] However, prior to receiving the initial configuration, in step 515, the WTRU may transmit initial mobility assistance information to the network. Such 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 preferred according to the WTRU's geographical location and network deployment. In step 525, the network may also provide initial mobility configurations relating more specifically to L1L2 triggered mobility (LTM). The initial LTM configurations may consist of (e.g., preferred) LTM configurations that can be triggered at L1L2. The selection of LTM configuration candidates may depend on the WTRU's capabilities for LTM mobility shown to the network, WTRU mobility requirements (QoS / QoE) for active services / applications, WTRU non-radio measurements such as geographical coordinates and orientation, network dynamics, such as cell load, volume of active traffic with different QoS levels, subscriber levels, differentiated services, etc. Depending on the embodiments described above, the network may provide initial configurations of LTM candidates to a given WTRU.
[0162] Nevertheless, the initial configuration related to coverage information and LTM candidates may no longer be suitable if the WTRU moves to a new location that may have a different set of LTM candidate configurations, away from its previously reported location.
[0163] Therefore, referring to step 530, the WTRU may, for example, monitor configured non-wireless measurements, and referring to step 535, the WTRU may decide to report its measurements, for example, considering whether the values of those non-wireless measurements may change over time. If it decides to report its measurements, referring to step 540, the WTRU may report its measurements to the network corresponding to the non-wireless configured measurements.
[0164] Therefore, referring to step 545, if the measurements reported from the WTRU for radio and non-radio measurements change to the point where the previously configured LTM candidate is no longer suitable, the network may update its configuration. The update process may include step 550, which corresponds to updating network coverage information, and step 555, which corresponds to updating the LTM candidate configuration. The update may be a incremental addition / deletion of previously provided configurations. In some cases, the network may decide to provide a new configuration.
[0165] Although not shown in Figure 5, the network may decide to update its configuration without explicit reporting from the WTRU. One scenario may be that the network can infer changes in WTRU location / position through uplink signals. These uplink signals may be WTRU uplink transmits such as PUSCH, physical uplink control channels (PUCCH), or some reference signal, such as a sounding reference signal.
[0166] In another complementary embodiment, the network may decide to update the LTM configuration independently of WTRU reports. This update may occur without a report from the WTRU, or if there is a WTRU report indicating no changes, such as WTRU location / position. Network updates may be triggered when there are changes in network dynamics with respect to active traffic and active devices. This may lead to a situation where some previously configured LTM candidates do not have the resources to support incoming WTRUs throughout the LTM procedure, and therefore the network can remove some of the previously configured LTM candidates and provide the WTRU with configurations for additional LTM candidates.
[0167] The main components of the various embodiments presented herein are radio measurements, non-radio measurements, and combinations thereof, which can be used in lower-layer mobility procedures. These mobility procedures are used for L1L2 triggered mobility (LTM). The measurement framework, configurations, quantities, and reporting mechanisms proposed herein can be used to provide measurement reports to a network, which can then use these, potentially combined with other network / device information, to advance network-controlled and network-triggered mobility procedures. In these procedures, the network can send commands to a target WTRU to perform an LTM switch to a given target cell / beam, which may be broadcast by the network from the same DU (in-DU scenario) or from a different DU (inter-DU scenario) compared to the current serving cell / beam. Beyond the network-commanded cell / beam LTM switch, the LTM measurement framework can enable the configuration of LTM measurements, triggers, and execution conditions, which can work to trigger WTRU-controlled LTM mobility to the target cell / beam. These cells / beams can be pre-configured by a network, along with (for example, preferred) operating conditions for the quantifier, as proposed in this framework.
[0168] One aspect of LTM-related measurements can be that they are lower-layer measurements, where processing, necessary filtering (if configured), and reporting primarily occur at lower layers. Here, lower layers include Layer 1 and Layer 2. The main role of Layer 3 (the RRC layer of the radio protocol stack) is to provide configuration for lower layers, such as the PHY layer and MAC layer, which can then perform and process measurements according to the configuration received through the RRC. Some procedures may involve some involvement from Layer 3 (the RRC layer of the protocol stack), but whenever this occurs, it will be explicitly mentioned.
[0169] The device may be equipped with interfaces from non-3GPP RATs, local sensors, or obtain environmental information and quantities from several storage points. The use of these quantities and their integration with measurements via 3GPP standardized RATs may require a harmonized framework that allows WTRUs to use data from non-3GPP RATs alone or in combination with data / measurements via 3GPP RATs. The following subsections aim to provide a framework that allows measurements or data quantities from non-3GPP RATs / sensors to be used in beam change and cell change procedures.
[0170] The measurement framework via 3GPP radio signals, non-3GPP radio signals, and local sensors is primarily described in the context of lower-layer mobility, but it can be applied to a wide variety of procedures / scenarios. Measurements and events can be used to adapt several aspects of lower-layer procedures, such as channel state information feedback. Measurements can be employed to initiate monitoring of certain frequencies, cells, TRPs, or beams at some triggers among these events. This applicability can also be easily applied to higher-layer procedures such as classic handovers, conditional handovers, and conditional PSCell changes / additions.
[0171] A WTRU can provide an indication of its ability to perform PHY layer measurements on radio and non-radio signals / sources. This ability can be initiated by the WTRU itself, for example, while attached to a network or while in an RRC state. A network can also (e.g., explicitly) request a WTRU's ability to perform PHY layer LTM measurements, and the WTRU can respond with an indication of its ability.
[0172] Several relevant PHY layer measurements for the LTM procedure can be quantities calculated across the reference signal. The most important are the (secondary) synchronous sequence (SS), channel status information reference signal (CSI-RS), positioning reference signal (PRS), and sounding reference signal (SRS). The definitions of resources and reference antenna connectors can be similar to those defined in 3GPP38.215 for the calculation of reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-noise interference ratio (SINR), and received signal strength indicator (RSSI).
[0173] Regarding 3GPP radio quantity measurements: The following are quantities that a WTRU can measure on the PHY layer and that can demonstrate its capability regarding these quantities, such as the number of measurements within and between frequencies, and the number of frequencies / bands it can support for simultaneous measurement. These quantities can be estimated (for example, primarily) across 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 interference ratio (SS-SINR), CSI signal-to-noise 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).
[0174] Regarding measurements of non-3GPP radio frequencies: WTRU can provide indication of its ability to measure and report several non-3GPP signal frequencies through other available receivers on the device. This could include, for example, GNSS, WLAN, and Bluetooth-related measurements. More specifically, this could include any of the following: GNSS code measurement: GNSS code phase (integer and fractional parts) of the spreading code of a GNSS satellite signal provided by the configuration or with reference power; GNSS carrier phase measurement: number of carrier phase cycles (integer and fractional parts) of a GNSS satellite signal provided by the configuration or with reference power; WLAN RSSI: IEEE 802.11 WLAN RSSI; Bluetooth signal power and source ID measurement; RF pattern identification and matching-based measurements; Terrestrial Beacon Systems.
[0175] Regarding non-wireless 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 include motion sensors (e.g., accelerometers, gyroscopes), environmental sensors (e.g., barometers), position sensors (e.g., magnetometers, orientation sensors), and velocity sensors. These sensors may provide any of the following measurements: linear acceleration or change in linear acceleration, velocity or change in velocity, orientation or change in orientation, angular velocity or change in angular velocity, atmospheric pressure or change in atmospheric pressure, and magnetic field or change in magnetic field.
[0176] Some of these quantities can also be obtained through several non-3GPP interfaces. WTRU capability indication can provide indications of the sensors, the measurements available through those sensors, and potentially the accuracy of those measurements.
[0177] Regarding the combination of wireless and non-wireless measurements: Another class of measurements can be defined that can be obtained by combining wireless and non-wireless measurements. One example is the WTRU orientation relative to a reference TRP. The WTRU self-orientation can be defined in a preferred manner, for example, by the principal angle of its primary antenna (or antenna array), and can be obtained from a local sensor. This can be known in the network or transmitted as part of capability exchange information. The WTRU orientation relative to a reference TRP can be defined as the angle between the WTRU's self-orientation and the line connecting the WTRU to the reference TRP. This determination can be made using various sources and methods. In one method, the WTRU can use GPS signals processed in the WTRU local sensor (hardware / firmware / software) combined with TRP locations provided by the network via 3GPP wireless signals. Alternatively, the WTRU can process 3GPP radio signals transmitted by the TRP and determine the angle of the reference TRP from its antenna array's principal or broadside angle through local estimations made on these signals (such as the angle of arrival). This determination can utilize local sensors, such as a magnetometer and other orientation sensors, in addition to the processing performed via the 3GPP radio signals. This information can be used in the WTRU, along with its self-orientation information, to estimate the WTRU's orientation relative to the reference TRP. This class of measurements can be retained as a subgroup of non-radio measurements.
[0178] In the case of a multi-panel WTRU, the concept of a reference panel can be introduced on the WTRU side. This reference panel may be a panel with more antenna elements, better sensitivity, or a primary antenna panel, due to its implementation or better connectivity in the WTRU Tx / Rx chain. In such a WTRU, this information can be shared with the network when the WTRU provides information about the implementation of those antenna panels.
[0179] In multi-TRP transmission scenarios, the concept of a reference TRP can be introduced for orientation determination purposes. The reference TRP can be a TRP that transmits DCIs for single-DCI-based multi-TRP transmissions. For multi-DCI-based multi-TRPs, the reference TRP can be a TRP identified through a lower CORESETPoolIndex. In another design, the network may explicitly indicate the reference TRP. In WTRU-based selection, the WTRU can determine which TRP it receives through its reference antenna panel in the case of a multi-panel WTRU. In yet another design, reference TRP selection can be left to the WTRU, which can provide indication of the reference TRP to the network through (e.g., preferred) signaling. In measurement configurations that are part of 3GPP positioning and location services, the RRC can request the Location Management Function (LMF) to obtain positioning services for a target WTRU. The WTRU can consist of reference signals and methods for positioning purposes, the results of which can be used in LTM-based procedures. In an alternative compatible design, the RRC layer may be permitted to request the target WTRU to launch location services with the LMF, which can then provide the RRC with positioning signals and information related to the procedure.
[0180] LTM measurements can be defined for each cell group. Therefore, in the case of dual connectivity, there can be one configuration for the master cell group (MCG) and another configuration for the secondary cell group (SCG).
[0181] The LTM measurement configuration can be provided as part of the cell group configuration. This can be achieved by defining a new structure called "LTM_meas_config" within "CellGroupConfig". Providing the LTM measurement configuration within the cell group (CG) configuration has the advantage that the configuration does not need to have changes for each cell.
[0182] LTM measurement configurations can be provided through RRC_Reconfiguration signaling. This allows one configuration to be associated with an MCG and another with an SCG. However, a further benefit may be that the configurations can be maintained even if the cell group configuration is updated.
[0183] The LTM measurement configuration can be embedded within (for example, as part of) the serving cell configuration. The serving cell configuration can provide the configuration for the LTM measurement. This can be achieved by defining a new structure, "LTM_meas_config," within "ServingCellConfig." This has the advantage that each cell can be configured with its associated LTM measurement. The disadvantage is that the serving cell configuration may become larger, and serving cell updates requiring configuration updates may incur higher overhead.
[0184] An LTM measurement configuration may include configurations for LTM measurement resources and LTM reporting configurations. Furthermore, the configuration may include a quantitative configuration. The quantitative configuration may provide lower-layer filtering, processing, or other metrics applied to the LTM measurement before reporting according to the reporting configuration.
[0185] An LTM measurement configuration can provide various LTM measurement resources and LTM measurement reporting configurations. This may appear to have (e.g., very high) overhead for the WTRU in terms of performing, processing, and reporting measurements to the network. In one embodiment, the WTRU can perform measurements on (e.g., only on) an ACTIVATED LTM candidate. Activation can be through an explicit network configuration, conditional on wireless or non-wireless conditions, or through the expiration of some timer.
[0186] The set of measurement resources may relate to radio measurement resources that can be transmitted from 3GPP RATs, such as NG-RAN, EUTRAN, UTRAN, GPRS, GSM, etc. These sources may be configured by (for example, preferred) parameterization. These sources may be one or more of SSB, CSI-RS, PRS, SRS, or other reference signals that can be designed for measurement purposes. In addition to resource identification, resource mapping with respect to time and frequency, subcarrier spacing (SCS), power control-related parameters, periodicity for periodic resources, cell identification information associated with the measurement resource, and QCL information for the measurement resource may be provided.
[0187] In addition to the parameters mentioned above, several new parameters can be added to the measurement resources, which can assist the LTM procedure. These may include DU identification information or DU identifiers, CU identification information or CU identifiers, TRP identification information or TRP identifiers, etc. These may be important in some cases where certain aspects of the LTM procedure require such information to be known in the WTRU, based on which WTRUs are expected to take certain actions.
[0188] The reporting configuration can provide reporting attributes relating to the periodic, semi-permanent, and aperiodic nature of the configured measurement reports.
[0189] A reporting configuration can provide resources for delivering reports to the network. LTM reporting resources include PUCCH resources, PUSCH resources, or SRs that are sent to the network when reporting conditions or trigger conditions are met. This can reduce latency because reporting can be configured to occur via the PHY or MAC layer in the form of MAC CEs, which can be custom designed to deliver a configured amount of reports.
[0190] In some scenarios and procedures where latency may not be an issue, or where the report size may be large, reporting can be RRC-based.
[0191] A reporting configuration can provide LTM triggers and execution conditions for the quantifier associated with a given reporting configuration.
[0192] The reporting configuration can provide a sub-selection of measurement resources according to (for example, preferred) criteria. In a non-limiting example, the reporting configuration may show the reporting of the N quantities that were most strongly / largest measured during the configured measurement period. In another compatible design, the reporting configuration may provide the reporting of the N largest quantities if they are greater than 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 as 1, only the strongest measurements among those taken on the configured resources are reported.
[0193] The LTM measurement framework can provide a measurement for reporting purposes. Configurations for the measurement can provide additional processing and filtering that needs to be applied to the raw measurement before reporting. Processing can include thresholding, quantization in a specific format, and mapping to several formats and bit ranges. Filtering coefficients can be specified to achieve the removal of a certain level of noise or channel variation by the filter. One non-limiting exemplary goal of LTM is to enable seamless mobility within shorter time intervals, and therefore filtering options can be enabled or disabled by configuration. In another implementation, filtering coefficients may have values such that they allow for raw measurement reporting.
[0194] The configuration can provide 3GPP-based radio metric quantities, including the previously described SSB-index-RSRP, SSB-index-RSRQ, SSB-index-SINR, CRI-RSRP, CRI-RSRQ, CRI-CQI, CRI-SINR, and PRS / SRS-related quantities.
[0195] In addition to 3GPP-based radio frequencies, the configuration can provide frequencies for reporting and related post-processing / filtering of non-3GPP-based radio signals, as well as frequencies available from local sensors and potentially other interfaces.
[0196] Referring to Figure 6, an example of an LTM measurement framework based on a reporting configuration is shown. Referring to Figure 6, in one embodiment, an LTM measurement can use the identifier of an LTM reporting configuration (LTM measurement reporting configuration identifier = "x" in Figure 6) as the LTM measurement identifier. The reporting configuration then provides a pointer to an LTM measurement resource configuration (LTM measurement resource configuration identifier = "a" in Figure 6) and a pointer to an LTM quantity configuration (LTM measurement quantity configuration identifier = "b" in Figure 6). In this design, the LTM measurement can be enabled, disabled, activated, deactivated, or triggered through the DCI using the identifier of the LTM reporting configuration.
[0197] Referring to Figure 7, an example of an LTM measurement framework based on measurement identifiers is shown. Referring to Figure 7, in another embodiment, there may be separate configurations for LTM measurement resources and LTM reporting. There is a separate LTM measurement identifier (LTM measurement identifier "x" in Figure 7) which can provide two pointers. One pointer may be to a set of LTM measurement resource identifiers (LTM measurement resource configuration identifier = "a" in Figure 7), and the other pointer may be to an LTM reporting configuration (LTM measurement reporting configuration identifier = "y" in Figure 7). In this design, the reporting configuration identifiers (objects) may not be unique, as the LTM measurement identifiers may generate multiple LTM measurements by linking a given reporting configuration to different sets of measurement resources. The LTM measurement reporting configuration may provide another pointer (LTM measurement quality configuration identifier = "b" in Figure 7) to a (preferred) LTM measurement quantity configuration. In a minor variation, the parameters of the quantity configuration may be specified (for example, directly) within the reporting configuration.
[0198] Referring to Figure 8, an example of an LTM measurement framework in which reporting configuration and quantity configuration are combined is shown. Referring to Figure 8, in one embodiment, the LTM measurement can use the identification information of the LTM reporting configuration (LTM measurement identification information = "x" in Figure 8) as the LTM measurement identification information. The reporting configuration can provide all the necessary parameters related to providing reporting, quantity configuration, and a list or set of pointers to LTM measurement resource configuration identification information (LTM measurement resource configuration identification information = "a" in Figure 8).
[0199] LMT measurements associated with LTM candidate configurations can be linked to non-radio-volume and events.
[0200] In one embodiment, the LTM measurement configuration can provide activation conditions for (for example, preferred) non-radio quantities. These non-radio quantities can be specified as conditional events with preferred definitions of thresholds and offsets required to determine these conditions. In one embodiment, activation of the LTM measurement configuration can be conditional on an event occurring when the WTRU enters a particular zone.
[0201] In one embodiment, activation of the LTM measurement configuration may be conditional on an event occurring when a WTRU device reaches the vicinity of a network-deployed transmission point and its orientation is aligned to that point. Such activation conditions can be achieved by evaluating the event.
[0202] In one embodiment, the deactivation condition may be specified (for example, explicitly) as part of the LTM measurement configuration. In one embodiment, when the activation condition is not met, the WTRU may deactivate the corresponding measurement configuration. As a non-limiting example, if the activation condition is that the WTRU enters a particular zone, the WTRU may be configured to treat the departure of the activation zone as a deactivation condition and cease performing measurements for that configuration.
[0203] Activation and / or deactivation conditions for the LTM measurement configuration can be specified as part of the reporting configuration.
[0204] In one embodiment, the activation conditions can be specified as part of the measurement identification information.
[0205] In one embodiment, the activation conditions can be specified as part of the resource identification information.
[0206] The LTM measurement framework can be enhanced to report measurements made on non-3GPP radio signals and non-radio quantities. Non-radio quantities can be measurements available through local sensors and other interfaces.
[0207] Non-3GPP-based radio measurements may have defined measurement resources for positioning and non-terrestrial network (NTN) ephemeris data. These may include measurements from GNSS, WLAN, Bluetooth, or signals from other radio technologies that WTRUs can measure and report.
[0208] The LTM measurement framework can be enhanced so that reporting identification information can provide reporting configurations for non-radio measurements. Reporting configurations can provide combinations of radio measurement resources and non-radio measurements (by indicating their identification information) through (e.g., preferred) parameterization. Configurations may include only non-radio quantities, in which case the LTM report will include only non-radio measurements. For non-radio measurements, reporting configurations can provide information about quantities with events that need to be evaluated, reported, and used, or widely used, for decision-making to implement LTM switching. These measurements can also indicate the type of filtering to be applied to these non-radio measurements through (e.g., preferred) parameters of the quantity configuration. Filtering behavior can be specified using existing filtering mechanisms / coefficients for radio measurements, or new filtering procedures / coefficients can be provided for non-radio measurements.
[0209] 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 include gyroscopes, accelerometers, barometers, and velocity sensors, which can provide measurements such as velocity, acceleration, orientation, and atmospheric pressure, and these can be further processed to calculate more complex quantities. Some of these quantities can also be obtained through several non-3GPP interfaces.
[0210] Referring to Figure 9, a non-limiting example of a model for measurement, processing, and filtering is shown for LTM measurements. There may be L1 filtering left to the WTRU implementation with specified performance requirements. Beam integration into the cell and filtering procedures can be specified by the RRC layer. L1 / L2 filtered values can be used to evaluate trigger conditions for the LTM procedure or for reporting purposes.
[0211] Referring to Figure 9, point "A" corresponds to the measurement inside the physical layer (beam-specific sample). The "Layer 1 filtering" block in the WTRU implementation-specific part corresponds to the internal Layer 1 filtering of the input measured at point "A". Strict filtering is implementation-dependent. How the measurement is actually performed in the physical layer by the implementation (input A and Layer 1 filtering) is not constrained by the standard.
[0212] Point "A1" corresponds to measurements (e.g., beam-specific measurements) reported to Layer 3 by Layer 1 after Layer 1 filtering. The beam integration / selection block corresponds to the integration of beam-specific measurements to determine cell quality. The behavior of beam integration / 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 measurements (e.g., cell quality) determined from beam-specific measurements reported to Layer 3 after beam integration / selection.
[0213] The L1 / L2 filtering block for cell quality corresponds to the filtering performed on the measurement provided at point "B". The behavior of the L1 / L2 filtering can be configured by the network. The filtering reporting cycle at point "C" is equal to one measurement cycle at point "B". Point "C" corresponds to the measurement after processing in the L1 / L2 filter. The reporting rate is equivalent to the reporting rate at point B. This measurement is used as input for one or more evaluations of reporting criteria.
[0214] The reporting criteria evaluation block checks whether an actual measurement report is required at point "D". The evaluation can be based on two or more flows of measurements at reference point "C" to compare different measurements, for example. This is indicated by input points "C" and "C1". The WTRU can evaluate the reporting criteria at least each time a new measurement result is reported at points "C" and "C1". The reporting criteria can be standardized, and the configuration can be provided by RRC signaling (WTRU measurement). Point "D" corresponds to measurement report information (messages) sent over the wireless interface. For non-wireless measurements, the network configuration can specify that they be filtered as an additional input at either point "A" or point "B". In a compatible design, the network configuration can specify that non-wireless measurements be included as an additional "C1" input, which effectively bypasses the filtering.
[0215] The L1 / L2 beam filtering block corresponds to the filtering performed on the measurement provided at point "A1" (i.e., beam-specific measurement). The behavior of the L1 / L2 beam filter can be part of the configuration. The filtering reporting cycle at point "E" is equal to one measurement cycle at point "A1". Point "E" corresponds to the measurement after processing in the beam filter (e.g., beam-specific measurement). The reporting rate is equivalent to the reporting rate at point "A1". This measurement is used as input for selecting X measurements to be reported.
[0216] The beam selection block 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 beam measurement information included in the measurement report on (and transmitted over) the wireless interface.
[0217] The LTM measurement configuration can provide a framework that allows a network to configure LTM measurements consisting of wireless and non-wireless measurements. The configured measurements can be candidates for periodic, semi-persistent, aperiodic, or event-triggered reporting, as shown in the "LTM Measurement Reporting Configuration". Once triggered, an event can then trigger reporting of event execution and the execution of associated LTM switching to target candidate cells / beams. These conditions, events, and thresholds can be part of the "LTM Measurement Reporting Configuration".
[0218] Configuration of lower layers can be managed primarily through the RRC layer, but configured measurements, both wireless and non-wireless, can be configured by conditions used to trigger specific LTM-related events on the PHY layer. In PHY-based evaluation, the PHY layer itself can perform configured post-processing and filtering after performing measurements or obtaining measurements from other interfaces and local sensors.
[0219] A compatible design allows for the generation of events in the MAC layer and the implementation of conditional evaluations to trigger several steps. In this design, the PHY layer can simply be retained, and measurements can be passed to the MAC layer at intervals according to the configuration. Post-processing and filtering can be configured to be performed in the PHY or MAC layer, or partially in both layers. The MAC layer can evaluate conditions regarding the processed quantity and generate events. A further advantage of this approach is that by disabling MAC processing / filtering, the latency can be similar to that of the PHY.
[0220] In a simpler approach, the configuration may simply specify filtering and post-processing to be performed at a given / indicated periodicity. In this case, the implementation of this filtering and post-processing in one of its layers can be a WTRU implementation. In this case, the processing and time availability for the final quantity used to evaluate the LTM trigger can be independent of the layer / block in which they are implemented.
[0221]
[0222] Referring to Figure 10, in one embodiment, the LTM measurement framework can combine L1-filtered and L3-filtered measurements, and LTM events can be configured to evaluate against these L1 or L3 measurements or a combination thereof. This combination can be specified by a network and configured by an RRC layer. An LTM measurement model under the L1 / L3 measurement framework is shown in Figure 10. Figure 10 shows the input (thick black solid line) from the L1 beam integrated measurement block to the evaluation block for the LTM procedure / report, which also receives L3-filtered quantities from the Layer 3 filtering block for cell quality. In this measurement model, the event trigger and execution conditions may need to specify whether the quantity to be evaluated is L1 or L3.
[0223] Referring to Figure 11, in one embodiment, the L1 and L3 measurements can be combined before the evaluation of the event. This is done in a bias block. The bias block can be composed of appropriate configuration parameters that allow lower-layer measurements to be biased with the L3 filtered quantity. The bias block can be configured to apply a bias to lower-layer measurements based on the L3 filtered measurement, according to the configuration parameters. The bias block can be modeled as a weighted combination of L1 and L3 measurements, where weights can be provided as part of the configuration. In another example, the bias block can be considered as a combination and filtering of input L1 and input L3 quantities. In this way, the network can control a stable operating point for the biased measurement, which will then be used to evaluate the execution conditions before triggering the reporting and / or LTM cell switching procedure.
[0224] Referring to Figure 12, in one embodiment, there can be an integrated model for L3 and LTM measurements. Each block, for example, beam integration / selection, L3 filtering for cell / beam quality, and event evaluation parameters (offset, hysteresis, etc.), may comprise two sets of configuration parameters. One set is used for L3 legacy measurements, and the second set is used for LTM-related measurement processing and event evaluation / monitoring. Note that, although not shown in this figure, candidate quantities include all radio and non-radio measurements described previously.
[0225] For all embodiments related to the measurement process, the network configuration can be specified to filter out non-wireless measurements. This can be achieved by adding non-wireless measurements as an additional input at either point "A" or point "B". In compatible designs, the network configuration can be specified to include non-wireless measurements as an additional "C1" input, which effectively bypasses the filtering for these non-wireless measurements.
[0226]
[0227] For the various embodiments described herein, one of the themes (for example, basic) could be a WTRU consisting of a network sharing a single deployment / coverage information, as well as (for example, preferred) LTM measurements including radio and non-radio quantities to a target cell / beam. The WTRU would monitor and evaluate the configured quantities and, upon triggering certain events, perform an LTM switch to a target candidate cell / beam where the configured conditions are met.
[0228] The reporting configuration can be expanded to include new non-radio measurement-based events in which the WTRU will use data from local sensors. These events can utilize deployment attributes of both cells and beams, i.e., serving cells / beams (from primary or secondary cell groups), neighboring cells / beams, and LTM-configured candidate cells / beams, provided by the network configuration. In this way, events can be generated based on non-data measurements. These events can be combined with radio measurement-based events to verify cell / beam suitability for specific signal strengths, etc.
[0229] In one embodiment, a composite event can be designed in which conditions are specified for both non-radio metric quantities (such as location / position, orientation, etc.) and radio metric quantities (such as RSRP / RSRQ / SINR related to SSB or CSI-RS, or some other reference signals), and these composite events are triggered when conditions from both the radio measurement group and the non-radio measurement group are met. Triggering these composite events can be used as triggers to perform several WTRU procedures and actions. One aim of the various embodiments described herein can be primarily to use events from LTM measurements (radio and non-radio based) to trigger LTM switching to a target cell / beam.
[0230] For some LTM measurements, the configuration can provide a selection of parameters relating to additional post-processing or filtering coefficients that can be applied to the raw measurements. The 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 of the goals of this filtering or post-processing may be to perform additional processing to make these measurements suitable for use in LTM procedures that may lead to intra-DU cell / beam switching, inter-DU cell / beam switching, or inter-CU cell / beam switching. The proposed measurement framework can be used in other cell / beam level procedures.
[0231] In addition to post-processing or filtering, the LTM measurement framework may specify the derivation of cell-level quantities from beam-level measurements. Parameters and thresholds for determining cell-level quantities from beam-level measurements for reporting or event evaluation purposes (when configured) may be specified as part of the "LTM Measurement Configuration." A (preferred) "LTM Measurement Configuration" may be identified by its identifier from the "LTM Measurement Report Configuration." In one embodiment, such mapping rules and associated parameters may be provided directly as part of the "LTM Measurement Report Configuration."
[0232] A WTRU configured by LTM measurements can monitor and evaluate events configured via (for example, preferred) non-radio measurements. The measurements on which these event conditions are set can follow the measurement model described above. A reference measurement model is provided in the section above, and the event conditions can be set for L1 measurements only, L3 measurements only, joint events relating to L1 and L3 measurements, or L1 measurements biased by L3 measurements.
[0233] For non-radio measurements, filtering can be specified separately, or these quantities can be configured to undergo one of the models described above. These processed / filtered non-radio measurements can then be fed to the event evaluation block.
[0234] Details on how these events can be used in specific procedures are described in the various embodiments described herein. Some exemplary events relating to wireless and non-wireless measurements are described in the following subsections. One point of this framework is that it can respond quickly to changing channel conditions, so the trigger conditions for exemplary events can use some offset and hysteresis values that may not always be desirable for LTM measurements. For that embodiment, such additional tuning parameters, offsets, and hysteresis can either be completely removed from the condition definition, or they can be assigned zero or a value to achieve the desired latency advantage.
[0235] In the following embodiments, some defined exemplary LTM events that utilize information from local sensors and / or non-3GPP interfaces are described. It would be important to note that in some of these events, 3GPP radio signals can be used to improve the quality of the measurement. A prime example of such an event is one that utilizes location measurements, where the network can help improve the estimated accuracy.
[0236] The embodiments proposed below aim to minimize mobility interruptions due to lower-layer cell switching, and further benefits and deterministic mobility modes can be obtained by utilizing information from non-3GPP radio signals. This category can combine non-3GPP radio signals with information data from local sensors, other interfaces, etc. Events defined in this way can become a key point in the proposed LTM procedure.
[0237] In the case of an LTM non-wireless event LTM-V1 where the WTRU speed is greater than a predetermined threshold, the WTRU is:
[0238] (1) When condition V1-1 is satisfied, it can be regarded that the entering condition for this event is met, where condition V1-1 is Mv - Hys > Thresh1 (entering condition 1), and
[0239] (2) When condition V1-2 is satisfied, it can be regarded that the leaving condition for this event is met, where condition V1-2 is Mv + Hys < Thresh2 (leaving condition 1).
[0240] The variables in the formula are defined as follows. Mv is the WTRU speed estimated by the WTRU through its local sensor without considering any offset. Mv can be expressed in km / h. Hys is the hysteresis parameter for this event (i.e., the hysteresis defined within the configuration for this event). Hys is expressed in the same unit as Mv. Thresh1 is the threshold for this event defined as the reference speed within the configuration for this event and is used as the speed threshold for entering this event. Thresh2 is the threshold for this event defined as the reference speed within the configuration for this event and is used as the speed threshold for exiting this event. Thresh1 and Thresh2 are expressed in the same unit as Mv.
[0241] In the case of the LTM non-radio event LTM-R1 where WTRU rotation occurs for an amount greater than a predetermined threshold, the WTRU
[0242] (1) When condition R1-1 is satisfied, it can be regarded that the entering condition for this event is met, where condition R1-1 is Mr - Hys > Thresh1 (entering condition 1), and
[0243] (2) When condition R1-2 is fulfilled, the leaving condition for this event can be considered to be satisfied, where condition R1-2 is Mr+Hys>Thresh2 (leaving condition 1).
[0244] The variables in the formula are defined as follows: Mr is the WTRU rotation estimated by the WTRU through its local sensor without considering any offsets, and the rotation estimate is over a duration not exceeding the duration Td configured as part of the configuration. Mr can be expressed in degrees. In compatible designs, Mr can be expressed in radians. In flexible methods, the units for Mr can be configured as part of the configuration.
[0245] Hys is the hysteresis parameter for this event (i.e., the hysteresis defined within the configuration for this event). Hys is expressed in the same units as Mr. Thresh1 is the threshold for this event, defined as the amount of reference rotation within the configuration for this event, and is used as the rotation threshold for entering this event. Thresh2 is the threshold for this event, defined as the amount of reference rotation within the configuration for this event, and is used as the rotation threshold for exiting this event. Thresh1 and Thresh2 are expressed in the same units as Mr.
[0246] In the case of an LTM non-radio event LTM-O1 where the WTRU orientation changes from the current orientation by a certain threshold, the WTRU is:
[0247] (1) When condition O1-1 is fulfilled, the entering condition for this event can be considered to be satisfied, where condition O1-1 is Mo-Hys > Thresh1 (entering condition 1),
[0248] (2) When condition O1-2 is satisfied, it can be considered that the leaving condition for this event is satisfied, where condition O1-2 is Mo + Hys < Thresh2 (leaving condition 1).
[0249] The variables in the formula are defined as follows. Mo is the change in WTRU orientation estimated by the WTRU through its local sensor without considering any offset, and the orientation estimation can be over a duration that does not exceed the duration Td configured as part of the configuration. Mo can be expressed in degrees. In a compatible design, Mo can be expressed in radians. In a flexible approach, the unit for Mo can be configured as part of the configuration. Hys is the hysteresis parameter for this event (e.g., hysteresis defined within the configuration for this event). Hys is expressed in the same unit as Mo. Thresh1 is the threshold for this event defined as the amount of reference orientation change within the configuration for this event and is used as the threshold for entering this event. Thresh2 is the same threshold as Thresh1 and is used as the rotation threshold for exiting this event. Thresh1 and Thresh2 are expressed in the same unit as Mo.
[0250] In the case of the LTM non - radio event LTM - OT1 where the WTRU orientation matches the direction of a given TRP / cell within a predetermined threshold, the condition for this event can evaluate whether the WTRU orientation is aligned towards a given TRP within the configured threshold. The WTRU self - orientation can be defined in a suitable manner, for example, by the principal angle of its primary antenna (or antenna array), and can be obtained from local sensors. The WTRU orientation with respect to a reference TRP can be defined as the angle between its self - orientation in the WTRU and the line connecting the WTRU to the reference TRP. This determination can use various sources and methods. In one method, the WTRU can use GPS signals processed in a WTRU local sensor (hardware / firmware / software) combined 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 of the reference TRP from the principal angle or broadside angle of its antenna array based on local estimations made on these signals (such as the angle of arrival). This information can be used in the WTRU together with its self - orientation information to estimate the WTRU orientation with respect to the reference TRP.
[0251] In one embodiment, the current event LTM - OT1 can be configured such that the network provides a reference location for evaluating the WTRU orientation alignment with respect to a reference orientation. In this case, the network can guarantee the WTRU orientation alignment for any reference orientation / direction that may not have a link to any of its deployment topologies. The WTRU
[0252] (1) When condition OT1 - 1 is met, the entry condition for this event can be considered satisfied, where condition OT1 - 1 is abs(Ou - Thresh1)<Hys1 (entry condition), and the WTRU has an absolute orientation that matches the cell beam,
[0253] (2) When condition OT1-2 is fulfilled, the leaving condition for this event can be considered to have been met, where condition OT1-2 is abs(Ou-Thresh1)>Hys1(leaving condition).
[0254] The variables in the formula are defined as follows: Ou is the WTRU orientation estimated by the WTRU through its local sensor without taking any offset into account. The reference for orientation estimation for this event can be the TRP location or RS (e.g., beam) of the target cell / TRP. Alignment of this orientation estimation with respect to a given TRP is performed by using the TRP location or signal from the TRP as a reference. A reference TRP indication, location, or signal to be used as a reference from a given TRP is also provided as part of the network configuration. Ou can be expressed in degrees relative to the configured measurement reference. In compatible designs, Ou can be expressed in radians. In flexible methods, the units for Ou can be configured as part of the configuration. Hys1 is a hysteresis parameter for the orientation condition used for this event. Hys1 is expressed in the same units as Ou. Thresh1 is a threshold for this event, defined as the amount of reference orientation in the configuration for this event, and is used as the rotation threshold for entering this event. Thresh1 is expressed in the same units as Ou.
[0255] For an LTM non-radio event LTM-OD1, where the WTRU orientation and distance match the location of a given TRP / cell coverage within a predetermined threshold, the WTRU is:
[0256] (1) When both condition OD1-1 and condition OD1-2 are satisfied, it can be considered that the entry condition for this event is met, where condition OD1-1 is abs(Ou-Thresh1)<Hys1 (entry condition 1), the WTRU has an absolute orientation that matches the target cell beam, condition OD1-2 is Ml+Hys2<Thresh2 (entry condition 2), and the WTRU is within a suitable distance from the target TRP.
[0257] (2) When condition OD1-3 or condition OD1-4 is satisfied, it can be considered that the leaving condition for this event is met, where condition OD1-3 is abs(Ou-Thresh1)>Hys1 (leaving condition 1), and condition OD1-4 is Ml-Hys2>Thresh2 (leaving condition 2).
[0258] The variables in the formula are defined as follows: Ml is the WTRU location, expressed as the distance between the WTRU and the reference location parameter for this event (e.g., the reference location of the candidate TRP for this event), without considering any offsets. Ml can be expressed in meters. Ou is the WTRU orientation, estimated by the WTRU through its local sensor, without considering any offsets. The reference for orientation estimation for this event can be the RS of the target TRP (e.g., beam). Ou can be expressed in degrees relative to the configured measurement reference. In compatible designs, Ou can be expressed in radians. In flexible methods, the units for Ou can be configured as part of the configuration. Hys1 is the hysteresis parameter for the orientation condition used for this event. Hys1 is expressed in the same units as Ou. Hys2 is the hysteresis parameter for the location condition used for this event. Hys2 is expressed in the same units as Ml. Thresh1 is the threshold for this event, defined as the amount of reference orientation in the configuration for this event, and is used as the rotation threshold for entering this event. Thresh1 is expressed in the same units as Ou. Thresh2 is the threshold for this event, defined as the distance from the reference location configured in the configuration for this event. Thresh2 is expressed in the same units as Ml.
[0259] For LTM non-wireless events LTM-OD2, where the WTRU orientation and distance better match the location of a given TRP / cell coverage than the serving TRP / cell due to the configured threshold, the WTRU is:
[0260] (1) When both condition OD2-1 and condition OD2-2 are satisfied, it can be considered that the entry condition for this event is met, where condition OD2-1 is abs(Ou-On)-Hys1 < abs(Ou-Op) (entry condition 1), the WTRU has an absolute orientation that aligns the target cell TRP better than the serving cell orientation, and condition OD2-2 is Dn-Hys2 < Dp (entry condition 2), and the WTRU is within a suitable distance from the target TRP.
[0261] (2) When condition OD2-3 or condition OD2-4 is satisfied, it can be considered that the leaving condition for this event is met, where condition OD2-3 is abs(Ou-On)+Hys1 > abs(Ou-Op) (leaving condition 1), and condition OD2-4 is Dn+Hys2 > Dp (leaving condition 2).
[0262] The variables in the formula are defined as follows: Ou is the WTRU reference orientation in absolute units, estimated by the WTRU through its local sensor without considering any offsets. Ou can be expressed in degrees relative to the configured measurement reference. In compatible designs, Ou can be expressed in radians. In flexible methods, the units for Ou can be configured as part of the configuration. Op is the orientation of the serving TRP from the WTRU in absolute units, estimated by the WTRU using the location of the serving TRP received in the configuration. On is the orientation of the neighbor TRP from the WTRU in absolute units, estimated by the WTRU using the location of the neighbor TRP received in the configuration. Hys1 is the hysteresis parameter for the orientation condition used for this event. Op, On, and Hys1 are expressed in the same units as Ou. Dn is the distance between the WTRU location and the neighbor TRP location, where the neighbor TRP location is part of the configuration. Dn can be expressed in meters. Dp is the distance between the WTRU location and the Serving TRP location, where the Serving TRP location is part of the configuration. Dp is expressed in the same units as Dn. Hys2 is the hysteresis parameter for the distance condition used for this event. Hys2 is expressed in the same units as Dn.
[0263] In the case of an LTM non-radio event LTM-CM1, where the WTRU crosses the boundary of a specific zone in the coverage topology, the WTRU is:
[0264] (1) When condition CM1-1 is fulfilled, the entering condition for this event can be considered to be met, where condition CM1-1 is Ml1-Hys>Thresh1 (entering condition) and WTRU crosses a boundary in the coverage topology.
[0265] (2) When condition CM1-2 is satisfied, it can be considered that the leaving condition for this event is met, where condition CM1-2 is Ml1 + Hys < Thresh1 (leaving condition).
[0266] The variables in the formula are defined as follows. Ml1 is the WTRU location represented by the distance between the WTRU and the reference location parameter for this event without considering any offset. Ml1 can be expressed in meters. Hys is the hysteresis parameter for this event (e.g., hysteresis defined within reportConfigNR for this event). Hys is expressed in the same unit as Ml1. Thresh1 is the threshold for this event defined as the distance from the reference location (e.g., serving TRP) to the boundary of the coverage topology. The WTRU can determine Thresh1 from the coverage topology according to the configuration using its current location, serving TRP location, and boundary definition information. The boundary definition can correspond to the coverage of RNA, TA, PLMN, and further the TRP coverage. The configuration can provide information on whether Thresh1 is a line-of-sight (LOS) distance (in which case Thresh1 is the distance of the coverage boundary on the line connecting the serving TRP and the WTRU), or whether different calculations should be used. Thresh1 is expressed in the same unit as Ml1.
[0267] In the case of an LTM non-radio event LTM-CM2 where the WTRU is in a specific zone, the event can evaluate whether the WTRU is in a specific zone. Zone identification can be provided to the WTRU through configuration. In one embodiment, the network can provide coordinates for the zone center, its shape, and the length defining the zone. The zone can be in the form of a hexagon, square, or rectangle. The network can provide the center coordinates, one length parameter for a square zone, two length parameters for a rectangular zone, or more parameters for zones of improved shapes. In one embodiment, the zone can represent a sidelink-style zone, which can be obtained through a configured processing of GPS coordinates. The network can provide the WTRU with configuration for calculating the zone. The WTRU can obtain its location / position estimate through local sensors. WTRU location information can be assisted by radio or non-radio signals. The calculated location allows the WTRU to calculate its distance from the center of the zone and know the zone boundaries. The WTRU can calculate whether it is in a zone or not.
[0268] In one embodiment, a zone can be associated with a network deployment or coverage. In one embodiment, a network can designate a zone center as its deployed TRP. Zone boundaries can be defined as square, rectangular, or hexagonal shapes by specifying associated parameters, and this can be provided by parameter selection.
[0269] In one embodiment, the network can associate the configured zones with valid coverage information such as its cells and TRPs, which may be captured through historical measurement reports from WTRUs, drive tests, etc.
[0270] WTRU is
[0271] When condition CM2-1 is satisfied, it can be considered that the entry condition for this event is met, where condition CM2-1 is Ml1-Hys < Thresh1 (entry condition), and the WTRU crosses into a specific zone in the coverage topology.
[0272] When condition CM2-2 is satisfied, it can be considered that the leaving condition for this event is met, where condition CM2-2 is Ml1+Hys > Thresh1 (leaving condition).
[0273] The variables in the formula are defined as follows: Ml1 is the WTRU location, expressed as the distance between the WTRU and the reference location parameter for this event, without considering any offsets. The reference location belongs to a specific zone to which this event is associated. Ml1 can be expressed in meters. Hys is the hysteresis parameter for this event (e.g., hysteresis as defined in reportConfigNR for this event). Hys is expressed in the same units as Ml1. Thresh1 is the threshold for this event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference zone) to the boundary of the coverage topology. Depending on the configuration, Thresh1 can be determined from the coverage topology using information about its current location, reference gNB / TRP location, and boundary definition. The boundary definition can correspond to RNA, TA, PLMN coverage, and even gNB / TRP coverage. The configuration can provide information on whether Thresh1 is a LOS distance (in which case Thresh1 is the distance of the coverage boundary on the line connecting the reference TRP and WTRU) or whether a different calculation should be used. The network can provide a value for Thresh1 that matches the zone configuration. If the zone configuration is sufficient, the network can expect the WTRU to determine the value for this threshold. Thresh1 is expressed in the same units as Ml1.
[0274] In the case of the LTM non-radio event LTM-CM2V1 (LTM-CM2 && LTM-V1), where the WTRU is in a specific zone in the coverage topology and the speed is greater than a predetermined threshold, LTM-CM2V1 can be used to conditionally trigger a WTRU report for LTM switching based on non-radio measurements in the form of location coordinates and speed estimates. It can also be used to increase the measurement and reporting periodicity for some target neighbor candidates. This joint event can be set with respect to location estimation (which can be obtained through non-radio measurements) and speed estimation (mainly non-radio measurements). In one configuration, this event can simply be specified for non-radio measurement quantities. There can be other configurations where the location estimation can be obtained through either wireless measurements, or measurements on 3GPP wireless signals, or any one or a combination of the former sets.
[0275] The WTRU is
[0276] (1) When conditions CM2V1-1 and CM2V1-2 are met, the entry condition for this event can be considered satisfied, where condition CM2V1-1 is Ml-Hys1 < Thresh1 (entry condition 1) and the WTRU crosses into a specific zone in the coverage topology, and condition CM2V1-2 is Mv-Hys2 > Thresh2 (entry condition 2).
[0277] (2) When condition CM2V1-3 or CM2V1-4 is met, the leaving condition for this event can be considered satisfied, where condition CM2V1-3 is Ml + Hys1 > Thresh1 (leaving condition) and condition CM2V1-4 is Mv + Hys2 < Thresh2 (leaving condition).
[0278] The variables in the formula are defined as follows: Ml is the WTRU location, expressed as the distance between the WTRU and the reference location parameter for this event, without considering any offsets. The reference location can be attributed to a specific zone to which this event is associated. Ml can be expressed in meters. Hys1 is the hysteresis parameter for this event (e.g., hysteresis defined in reportConfigNR for this event) to be used in the location conditions. Hys1 is expressed in the same units as Ml1. Thresh1 is the threshold for this event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference zone) to the boundary of the coverage topology. Depending on the configuration, Thresh1 can be determined from the coverage topology using information about its current location, reference gNB / TRP location, and boundary definition. The boundary definition can correspond to RNA, TA, PLMN coverage, and even gNB / TRP coverage. The configuration provides information on whether Thresh1 is the LOS distance (in which case Thresh1 is the distance of the coverage boundary on the line connecting the reference TRP and the WTRU) or whether a different calculation should be used. Thresh1 is expressed in the same units as Ml1. Mv is the WTRU velocity estimated by the WTRU through its local sensor without taking any offset into account. Mv can be expressed in km / h. Hys2 is the hysteresis parameter for this event (e.g., hysteresis defined within the configuration for this event) which should be used for velocity condition evaluation. Hys2 is expressed in the same units as Mv. Thresh2 is the threshold for this event, defined as the reference velocity within the configuration for this event, and is used as the velocity threshold for entering / exiting this event. In an alternative design, two separate thresholds may be configured for entry and exit conditions.Thresh2 is expressed in the same unit as Mv.
[0279] In the case of the LTM non - radio event LTM - CM2O1 (LTM - CM2 && LTM - OT1), where the WTRU is within a specific zone in the coverage topology and the orientation matches a configured orientation within a given threshold, LTM - CM2O1 can be used to trigger a WTRU report based on non - radio measurements in the form of location coordinates that provide zone entry information and orientation for a given TRP for candidate configurations. It can also be used to increase the measurement and reporting periodicity for some target neighbor candidates.
[0280] This joint event can be configured with respect to location estimation (which can be obtained through non - radio measurements) and orientation estimation (mainly non - radio measurements). Thus, in one configuration, this event can simply be specified for non - radio measurement quantities. Nevertheless, there can be other configurations where the location estimation is obtained solely through radio measurements, or measurements on 3GPP radio signals, or any one or a combination of the former sets.
[0281] The WTRU
[0282] (1) When conditions CM2O1 - 1 and CM2O1 - 2 are fulfilled, it can be considered that the entry condition for this event is met, where condition CM2O1 - 1 is Ml - Hys1 < Thresh1 (entry condition 1) and the WTRU crosses into a specific zone in the coverage topology, and condition CM2O1 - 2 is abs(Mo - Hys2) < Thresh2 (entry condition 2).
[0283] (2) When condition CM2O1-3 or CM2O1-4 is fulfilled, the leaving condition for this event can be considered to be met, where condition CM2O1-3 is Mil + Hys1 > Thresh1 (leaving condition) and condition CM2O1-4 is abs(Mo + Hys2) > Thresh2 (leaving condition).
[0284] The variables in the formula are defined as follows: Ml is the WTRU location, expressed as the distance between the WTRU and the reference location parameter for this event, without considering any offsets. The reference location can belong to a specific zone to which this event is associated. Ml can be expressed in meters. Hys1 is the hysteresis parameter for this event (e.g., hysteresis defined in reportConfigNR for this event) to be used in the location conditions. Hys1 is expressed in the same units as Ml. Thresh1 is the threshold for this event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference zone) to the boundary of the coverage topology. Depending on the configuration, Thresh1 can be determined from the coverage topology using information about its current location, reference gNB / TRP location, and boundary definition. The boundary definition can correspond to RNA, TA, PLMN coverage, and even gNB / TRP coverage. The configuration can provide information on whether Thresh1 is the LOS distance (in which case Thresh1 is the distance of the coverage boundary on the line connecting the reference TRP and the WTRU) or whether a different calculation should be used. Thresh1 is expressed in the same units as Ml. Mo is the WTRU orientation estimated by the WTRU through its local sensor without taking any offset into account, and the orientation estimate is over a duration not exceeding the duration Td configured as part of the configuration. The reference for the orientation estimate for this event can be one of the following: cardinal direction, location from the WTRU antenna (e.g., TRP location) (e.g., GPS coordinates), or RS of the target TRP (e.g., beam). Thus, the orientation estimate can provide a measure of how closely the WTRU is aligned to the reference location / direction relative to the reference WTRU antenna (or antenna panel). The reference location / direction and reference WTRU antenna for the orientation estimate are all part of the configuration. Mo can be expressed in degrees.In an interchangeable design, Mo can be expressed in radians. In a flexible approach, the unit for Mo can be configured as part of the configuration. Hys2 is the hysteresis parameter for this event (i.e., the hysteresis defined within the configuration for this event). Hys2 is expressed in the same unit as Mo. Thresh2 is the threshold for this event, defined as the amount of reference orientation change within the configuration for this event and used as the threshold to enter this event. Thresh2 is expressed in the same unit as Mo.
[0285] The above paragraph provides some exemplary events for non-radio measurements that can be used to update LTM-related configurations, trigger reports, and trigger LTM switching decisions controlled by the network. These examples can be used to create additional events for non-radio measurements that can identify target scenarios in a very precise manner and select the most suitable candidates in intra-DU, inter-DU, and / or inter-CU scenarios.
[0286] In one embodiment, new events can be defined for a set of non-radio measurements. This can be beneficial when the environment is controlled or when the network may have complete knowledge of the radio environment with respect to terrain, buildings, and other objects.
[0287] For devices with highly rotational mobility, new events can be generated by combining event LTM-R1 or event LTM-O1 with other non-radio measurements.
[0288] The examples provided above do not cover events that can be created via signals, measurements, and identification information related to WLAN, Bluetooth, other RATs, or certain RF measurements. These can be defined when a network operator has knowledge of the public deployment of several reference locations with such access points or beacon transmissions or RF points for other RATs. These measurements can then be combined with other non-radio quantities to determine more refined events.
[0289] LTM mobility configurations and subsequent monitoring may require additional tracking in the WTRU for cells / beams that could be potential targets for LTM mobility, whether activated or deactivated. LTM mobility features may require new WTRU capabilities with respect to receiving and maintaining LTM configurations, handling LTM switching to intra-DU and inter-DU candidates, and perhaps most importantly, monitoring and reporting LTM measurements related to non-radiometric measurements.
[0290] WTRU capabilities relating to non-3GPP radio signals, local sensors, and other interfaces can be used for non-radio measurement-based LTM procedures. A WTRU can provide such capabilities to a network, and based on this knowledge, the network can determine (e.g., preferred) sets of non-radio measurements as part of LTM measurements and configuration. Some of these non-radio measurements can be used to trigger events that will lead to reporting and subsequent cell switching. Other non-radio measurements can be part of the measurement report. A WTRU can help the network determine (e.g., preferred) sets of quantities to be used in non-radio measurement-based LTM procedures by providing the source of these non-3GPP RATs, or local sensors or other interfaces, and other relevant parameters such as availability and accuracy levels.
[0291] The execution phase for a non-wireless measurement-based LTM procedure may (basically) include WTRU monitoring and reporting based on non-wireless measurements, network determination for switching cells and issuing cell switching commands, and WTRU actions for performing cell switching.
[0292] Once configured, the WTRU can begin monitoring the configured measurements. In some cases, there may be an activation phase, either via a timer or an explicit command. The LTM reporting configuration provides the parameters necessary to report LTM measurements to the network. Measurement reports covered by this disclosure may include non-radio measurements configured by the network as part of the configuration. The events underlying the LTM cell switching procedure may be set / triggered for non-radio measurements. Nevertheless, if a reporting event is triggered, the network may be configured to provide a measurement report including both radio and non-radio measurements.
[0293] The LTM reporting configuration can be configured so that LTM measurements can be reported as part of the uplink control information (UCI). In this design, LTM measurements are reported via PUCCH or PUSCH as specified in the LTM reporting configuration, which has (for example, preferred) parameters and periodicity.
[0294] The LTM reporting configuration can be configured for several quantities so that LTM measurements can be reported as RRC messages. This design may be preferable when latency is not a concern.
[0295] The LTM reporting configuration can be provided as a hybrid reporting configuration. In a hybrid design, the LTM measurement report can be partially configured as a UCI transmitted via PUCCH / PUSCH (or used to trigger lower-layer events) and partially reported via an RRC message. In one embodiment, the LTM report can be configured to be reported via RRC when certain conditions are met. If these conditions are not met, the WTRU can initiate reporting of the LTM measurement as part of a UCI (PUCCH / PUSCH). The RRC configuration and UCI (PUCCH / PUSCH) configuration for reporting the LTM measurement can be part of the LTM reporting configuration. The LTM reporting configuration also provides conditions that the WTRU can use to select one particular reporting type and conditions for switching to other reporting types. These conditions can be specified in relation to when the WTRU is enjoying better channel conditions than its serving cell / beam. When the serving cell / beam quality is better than a configured threshold, the WTRU can be configured to report the LTM measurement via RRC. Since the WTRU is under good channel conditions, the associated latency may not be a problem. When channel conditions degrade, the WTRU can switch to more agile lower-layer reporting, according to the conditions and thresholds provided as part of the configuration. Lower-layer reporting may have shorter periodicities and greater resource overhead, but this can be justified as the WTRU may be at risk of link degradation, and these measurements can enable faster LTM switching to neighboring cells and beams.
[0296] In a network-controlled LTM procedure, the network can determine when a given WTRU will switch from a serving cell to one of the LTM target cells in its cell group, whether that cell is the serving cell or the primary cell. The network can configure measurements to assist in this determination. In addition to WTRU measurements and feedback, the network can perform mobility decisions using other criteria and system-level aspects.
[0297] When the network decides to move a WTRU from a serving cell to a target LTM cell, the network may provide the WTRU with a cell switching indication or command. A cell switching command may be provided to the WTRU along with the necessary information to enable it to switch to the target cell. The cell switching command may include the LTM target configuration and beam indications. The beam indication may be provided as an SSB index, CSI-RS index, or QCL identification information, which is already configured by the network in the WTRU that provides the reference signal to which this QCL is set. The beam indication may be explicit or implicit. The cell switching command may also provide indications regarding how the data and control planes should be handled in the WTRU when the cell switching is performed. This indication may be provided as an explicit indication, such as that MAC / RLC entities require a reset and PDCPs require recovery. In an alternative compatible design, the network may only indicate whether the cell switchover is intra-DU or inter-DU, and the WTRU may be programmed a priori to perform MAC / RLC / PDCP handling according to the inter-DU / intra-DU indication. For example, whenever an inter-DU indication is transmitted by the network, MAC and RLC entities may be reset and PDCP may perform data recovery. In the case of an intra-DU, reset or data recovery may not be initiated. The cell switchover command may also indicate the type of signaling the WTRU should use on the target cell while the cell switchover is being performed. For example, the cell switchover command may provide whether the WTRU should transmit RACH, or some specific PUCCH, or some other signal on the target cell. In one embodiment, this information may be implicit depending on other parameters of the LTM target cell configuration.These may include, for example, cases where the target cell is already a serving cell or an activated cell. Cell switching commands can also provide timing advances in an explicit or implicit manner. For example, if the deployment is for a very small cell, the WTRU may not need to apply a timing advance. This may be known from the configuration or explicitly indicated. In another example where there is no timing advance, the target cell may have the same timing as the current serving cell, potentially within the margin of the cyclic prefix. In other cases, the network may (e.g., explicitly) indicate the timing advance value that the WTRU should apply while transmitting in the uplink direction to the target cell.
[0298] The network can send cell switching commands via MAC-CE. MAC-CE-based indication has the advantage of being able to provide the WTRU with other relevant information required by the cell switching command.
[0299] In one embodiment, cell switching commands can be provided via PHY signaling. This can be achieved by designing a downlink control indication (DCI) having (e.g., special) fields capable of carrying LTM cell switching command parameters, as previously described. PHY signaling can have lower latency and further reduce mobility interruptions.
[0300] In one embodiment (for example, a hybrid design), the network can maintain both MAC-based and PHY-based designs. Thus, the WTRU is configured to receive LTM cell switching commands via MAC and PHY signaling. Depending on the circumstances, given WTRU application requirements, WTRU reporting of non-radio measurements, and the availability of transmission occasions, the network can determine whether to use MAC or PHY signaling to provide LTM cell switching commands to the WTRU in a timely manner.
[0301] When a WTRU performs an LTM switchover to an LTM target candidate, it applies the configuration of the LTM target candidate. Two primary use cases for LTM switchover are when it occurs for a target cell / beam candidate that is serviced by the same DU or by different DUs. Depending on the intra-DU or inter-DU LTM switchover, the WTRU may need to handle internal data plane entities such as MAC entities, RLC entities, and PDCPs in different ways.
[0302] In the case of an LTM switchover within a DU, the WTRU can retain its MAC, RLC, and PDCP entities.
[0303] In the case of an inter-DU LTM switchover, the WTRU can reset its MAC and RLC entities and create new MAC and RLC entities according to the configuration of the target LTM candidate. In the case of a PDCP, it may need to re-establish the RLC if it has been reset.
[0304] The determination of the behavior to be applied for MAC, RLC, and PDCP layer resets can be left to the WTRU to determine whether it is an intra-DU LTM switch or an inter-DU LTM switch. The WTRU can determine the information that the LTM switch is intra-DU or inter-DU through the serving cell configuration and the candidate LTM configurations to which it applies.
[0305] In one embodiment, each LTM configuration can provide an indication of whether the MAC and / or RLC entity needs to be reset and whether PDCP recovery is required.
[0306] In the case of network-controlled LTM switching, the LTM switching command can indicate to the WTRU whether the MAC and RLC entities need to be reset and whether PDCP recovery is required.
[0307] When the WTRU performs an LTM switch 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 the same knowledge regarding which cell / beam the WTRU is performing the LTM switch to. The selection of the UL indication can be part of the LTM configuration.
[0308] In the case of network-controlled LTM switching, the LTM switching command can indicate to the WTRU which type of UL indication should be sent in the LTM switching event.
[0309] Design details for the uplink indication transmitted from the WTRU to the network during LTM switching are described below.
[0310] In a Physical Random Access Channel (PRACH) transmit-based indication embodiment, the WTRU can perform the PRACH procedure to the LTM candidate cell / beam. A contention-free Random Access Channel (RACH) configuration can be provided to accelerate the RACH procedure for the LTM candidate.
[0311] In RACH preamble-based indication embodiments, the WTRU can perform only the transmission of the RACH preamble. Preamble identification information and resources can be allocated for LTM candidate cells / beams. If the network already provides the necessary cell configuration, the entire RACH procedure may not be required. In this case, transmitting only the RACH preamble to the LTM target candidate can save transmission resources and speed up attachment to the target candidate. This latency saving is very important because one goal of LTM can be to improve latency when cells / beams need to be switched in mobility procedures.
[0312] In a reference signal-based indication embodiment, the WTRU may be configured to transmit several reference signals to an LTM target candidate cell / beam. These reference signals may be sounding reference signals (SRS). Configuration parameters for SRS transmission, including sequence, power, and time-frequency resources, may be provided to the WTRU as part of the LTM configuration. The source cell may have already communicated and coordinated such SRS transmit capability and associated parameters with an LTM target candidate, which may be an intra-DU or inter-DU switch. The LTM target candidate may recognize the transmission of such SRS from the WTRU and register that the WTRU has locally performed an LTM switch.
[0313] In a PUCCH-based indication embodiment, the WTRU can be configured to perform a PUCCH transmission to a candidate LTM target when switching to a candidate LTM target. The configuration of the PUCCH transmission, including PUCCH format assignment, sequence assignment, and PUCCH time-frequency resources, is specific to the candidate LTM target. The configured PUCCH transmission can indicate to the LTM target that the WTRU has performed an LTM switch.
[0314] In one embodiment, the WTRU can be configured to send scheduling requests (SRs) to LTM target candidates via a configured PUCCH resource. The design can be simply maintained by limiting it to short PUCCHs, for example, sequence-based PUCCH format 0 transmissions.
[0315] In one embodiment of a non-radio measurement-based LTM procedure, the embodiment may use any of the following actions: (1) WTRU capability transfer for lower layer mobility / LTM handling and related support information, this step may be accompanied by reporting of a set of non-radio measurements, the report may be further augmented with some radio measurements; (2) WTRU receives the LTM configuration with (e.g., preferred) LTM non-radio measurements and (e.g., preferred) events set for such non-radio measurements for reporting purposes; (3) WTRU performs the configured non-radio measurements; (4) WTRU detects changes in non-radio and radio measurements; (5) WTRU determines its zone through the non-radio measurements; (6) evaluate the configured events using conditions set for the measurement of non-radio quantities; (7) in the case of event triggering, event-based WTRU reporting of its configured non-radio measurements such as zone, location / position and orientation. The network may configure the WTRU to report radio measurements as part of the triggered measurement report. (8) The WTRU receives a network command to perform an LTM mobility switchover, where the network can determine the target cell / beam configuration for the WTRU using the WTRU measurement report and other system-level aspects; (9) The WTRU performs the LTM mobility switchover in accordance with the network command; (10) The WTRU performs protocol stack handling in accordance with the network configuration / indication and transmits a UL indication.
[0316] An example of a detailed network-controlled mobility procedure, triggered by WTRU non-radio measurements and subsequent WTRU reporting, is shown in Figure 13.
[0317] Referring to Figure 13, the procedure can be initiated in step 1310, where the WTRU is in the RRC_CONNECTED state. In step 1320, the WTRU can provide the network with its ability to handle different aspects of lower-layer mobility procedures. This ability can be grouped in a format that covers different aspects of handling the maximum number of configurations that the WTRU can thereby configure, including intra-DU configurations, inter-DU configurations, and mobility handling. Of particular interest are WTRU capabilities relating to non-radio measurements (position, location, orientation, panel), related details, and the accuracy of such measurements, which can help the network determine the LTM configuration. Along with LTM-related capabilities in a preferred format, the WTRU can also provide mobility assistance information to the network (e.g., gNB). This information may include measurements and the ability to perform various non-radio measurements. The set of measurements sent to the network for the network to use in preparing the mobility configuration can be lower-layer measurements, legacy L3 measurements, or a combination of both.
[0318] After receiving capability and mobility assistance information, in step 1330, the WTRU may receive coverage information from the network. Coverage information may be a snapshot of the network deployment close to the WTRU location. Coverage information may be provided to the WTRU by the network at a (preferred) granularity, according to the assistance information and the QoS / QoE requirements of the services that the WTRU is using or intends to use. In one embodiment, the WTRU may (for example, simply receive) zone determination information from the network without revealing deployment information.
[0319] In addition to the coverage configuration, in step 1340, the WTRU may receive (for example, preferred) lower-layer mobility configurations from the network. The lower-layer mobility configurations, or LTM configurations, 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 to (for example, preferred) reference configurations. The reference configuration may be configured to be a serving cell configuration or may be provided as a standalone configuration. A subset of LTM candidate configurations may be marked by networks in the ACTIVATED or ENABLE state, while others may be treated as DE-ACTIVATED. The WTRU will monitor ACTIVATED candidates for potential LTM switching.
[0320] One key point is that the network configures the WTRU with non-radiometric measurements as part of the LTM configuration step. Conditions set for such non-radiometric measurements can trigger WTRU measurement reports sent to the network, which form the basis for the network to decide on LTM cell switching. After receiving the LTM configuration, the WTRU can monitor the configured non-radiometric measurements periodically, semi-permanently, aperiodicly, or in an event-triggered fashion, according to the received configuration.
[0321] If the WTRU estimates the degradation of 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, position, and orientation. There may be additional non-radio measurements configured through either local sensors in the WTRU or information received through different interfaces. Link quality degradation detection can be configured for beam-based signals or cell-based signals. Since the goal here is to operate the procedure before there is a beam or link failure, the thresholds configured for degradation determination may differ from those for legacy beam failure detection or radio link failure detection. In an alternative embodiment, the WTRU may receive configuration information from the network indicating that it is monitoring non-radio measurements, either periodically or whenever a change (exceeding a certain threshold) is detected in these quantities.
[0322] After obtaining updated estimates of its non-radio measurements regarding location / position and orientation, in step 1360, the WTRU can determine its current zone according to the coverage information provided by the network. Parameters and constants for determining zone information according to one or more non-radio measurements of position, location, and orientation may be part of the coverage configuration.
[0323] After measuring the configured non-wireless measurement, in step 1370, the WTRU can evaluate the condition set as the measurement reporting trigger. If the condition is met, the WTRU can proceed to the next step 1380, which reports the configured measurement.
[0324] In step 1380, the WTRU may send a report of a configured non-radio measurement for an LTM measurement configuration where the event conditions are met. If the reporting conditions for event-based reporting are not met, the WTRU may not send a corresponding event-based report and may continue to monitor the quantity according to the configuration periodicity. LTM measurement reports can be periodic. In this case, the WTRU may send measurement reports according to the periodicity or timer expiration for which measurement reports should be sent. In compatible designs not shown in this flowchart, reports may be aperiodic and may be triggered by mechanisms such as RRC commands or PDCCH orders by the network sending DCI to the WTRU.
[0325] If the WTRU determines that reporting is necessary, in step 1380, the WTRU may send non-radio measurements to the network, such as its determined zone, location, position, orientation, etc., according to the configured reporting configuration. The network may configure the WTRU to include some radio measurements as part of the measurement report triggered via a non-radio event.
[0326] WTRU reports from non-wireless measurements allow the network to select an LTM candidate from previously configured LTM candidates that are in the ACTIVATED or enabled state. Although not shown in this flowchart, the network can update the LTM configuration using updated measurement reports received from WTRUs. The network can also decide not to perform an LTM switchover.
[0327] If the network switches cells for a WTRU through the LTM procedure, in step 1390, the WTRU may receive a network command to perform the LTM switchover. The LTM switchover command may include an indication of the target LTM candidate configuration. In addition to the target LTM candidate configuration, the LTM switchover network command may indicate WTRU behavior for MAC / RLC reset, and the UL-indicated WTRU type may be sent following the LTM switchover event.
[0328] After receiving an LTM candidate configuration for performing a switchover, in step 1395, the WTRU may perform an LTM switchover to the target candidate. The switchover may include local handling of MAC and RLC entities in the WTRU. In one embodiment, an indication for performing a MAC / RLC entity reset may be provided to the WTRU (e.g., explicitly) as part of the LTM configuration candidate, and the WTRU may perform a MAC and / or RLC entity reset according to the configuration of the selected LTM candidate. In one embodiment, the WTRU may determine such information based on whether the LTM target candidate involves an intra-DU switchover or an inter-DU switchover, and by performing a pre-configured MAC / RLC reset action for each of the intra-DU or inter-DU switchover scenarios. In one embodiment, the MAC / RLC reset handling may be indicated as part of the LTM switchover command.
[0329] Other parts of the LTM switching can relate to providing the network with an indication of the WTRU's LTM switching execution. Both the WTRU and the network can have a common view for communicating with each other after the LTM switching without interruption. The WTRU can send a UL indication on the LTM target candidate provided by the network. This UL indication, the associated sequence selection, and the selection of the transmission resource on which this indication is sent can be part of the LTM configuration itself. In one embodiment, the WTRU can perform the LTM switching by selecting a UL LTM switching indication received in a network command.
[0330] It is important to emphasize that conventional radiometric measurements can require considerable time for estimation, filtering, and reporting purposes, which can simply be unacceptable for achieving service continuity with mobility for high-density deployments of narrow beam systems. Therefore, various embodiments that base lower-layer mobility determination on non-radiometric quantities can offer the advantage of higher latency, which may simply not be achievable due to the instability and latency issues of radiometric measurements. Other benefits lie in mobility and service continuity during shorter interruptions compared to legacy methods.
[0331] In one embodiment, the LTM procedure can be based on location and orientation events without network deployment information.
[0332] In such embodiments, the WTRU can provide the configuration for zone determination but not network deployment information. The WTRU can use its location and orientation information to trigger lower-layer reports to the network configured as part of a mobility procedure triggered by the lower layer. The WTRU report can be through network configuration for location and orientation measurements, triggers, and thresholds. The report can inform the network of cells and beams for the WTRU, which it issues cell switching commands to the WTRU.
[0333] This embodiment may utilize any of the following actions: WTRU capability transfer for lower-layer mobility handling and related support information, supporting the LTM procedure based on non-radio measurements; the WTRU receiving a configuration for determining zone information as well as orientation-specific parameters and references; the WTRU receiving the LTM configuration along with (e.g., preferred) events for reporting purposes set for (e.g., preferred) LTM non-radio measurements and combinations of non-radio measurements. In this embodiment, the network may configure the WTRU for events relating to zone entries (LTM-CM2) and potentially combined with velocity or orientation (LTM-OT1) aligned to a specific location. The network may choose to configure a joint event that captures these two aspects through a single event such as LTM-CM2O1; the WTRU performing configured non-radio measurements on its location and orientation according to configured periodicity; the WTRU detecting changes in non-radio or radio measurements; the WTRU determining its zone through non-radio measurements and zone configuration. WTRU evaluation of configured events using conditions set for location and orientation. Event-based WTRU reporting of its zone, location / position, and potentially radiometric data, according to the configuration, in the case of event triggering for a WTRU to enter a specific zone and have an orientation that matches a given reference location according to the configuration. The WTRU receiving a network command to perform an LTM mobility switch, where the network can determine the target cell / beam configuration for the WTRU using the WTRU report and other system-level aspects. The WTRU performing an LTM mobility switch according to the network command. The WTRU performing protocol stack handling according to network indications.The WTRU can indicate, through an LTM switching command or through a previous configuration, that it will transmit UL indications according to the network configuration / indication, where the network will transmit reference signal (RS) or physical uplink control channel (PUCCH) based indications.
[0334] In one embodiment, the LTM procedure can be based on network topology information and events relating to non-wireless measurements.
[0335] This embodiment may utilize any of the following actions: WTRU capability transfer for lower-layer mobility / LTM handling and associated support information, supporting LTM procedures based on non-radio measurements; the WTRU receiving coverage and deployment topology and associated configuration; and the WTRU receiving the LTM configuration along with (e.g., preferred) LTM non-radio measurements and (e.g., preferred) events for reporting purposes set for combinations of non-radio measurements utilizing network-provided deployment / coverage information.
[0336] In this embodiment, the network may include any of the proposed non-wireless events as part of its configuration, and non-wireless events LTM-OD1, LTM-OD2 may consist of scenarios involving rotational and translational mobility to several specific TRP (e.g., distributed unit) locations. Non-wireless events LTM-CM1, LTM-CM2, LTM-CM2V1 may be configured for potential switching evaluation when a WTRU may be entering a given zone. Non-wireless event LTM-CM2V1 may be configured for potential switching evaluation when a WTRU may be entering a given zone at high speed.
[0337] This embodiment may further utilize any of the following actions: The WTRU performs a configured non-radio measurement; the WTRU detects a change in a non-radio or radio measurement; the WTRU determines its zone through the non-radio measurement; the WTRU evaluates a configured event using conditions set for the measurement of non-radio quantities; in the case of event triggering, event-based WTRU reporting of its zone, location / position, and radio measurement according to the configuration; the WTRU receives a network command to perform an LTM mobility switch, where the network can determine a target cell / beam configuration for the WTRU using the WTRU report and other system-level aspects; the WTRU performs an LTM mobility switch in accordance with the network command; the WTRU performs protocol stack handling according to a network indication embodiment; the WTRU transmits a UL indication according to a network configuration / indication, where the network can indicate, through the LTM switch command or through a previous configuration, that it transmits an RS or PUCCH-based indication.
[0338] In one embodiment, the LTM procedure may be based on the activation / deactivation of LTM measurements associated with the zone.
[0339] In this embodiment, the WTRU may have a zone determination configuration. The WTRU can use its location information to determine its zone according to the network configuration. As part of the LTM procedure, the network may configure the WTRU with LTM candidates. To reduce measurement and tracking overhead, LTM measurements may be mapped to relevant zones. Thus, these measurements may only need to be activated, deactivated, performed, and reported when the WTRU itself determines that it is in those zones. This thus can trigger the WTRU to perform measurements only in preferred zones and then provide a lean mechanism for providing reports to the network according to the reporting and triggers in these measurements. The network can then use the relevant measurement reports to trigger (e.g., preferred) mobility procedures to target LTM candidates.
[0340] This embodiment may utilize any of the following actions: WTRU capability transfer for lower-layer mobility / LTM handling and related support information to support the LTM procedure based on non-radio measurements; the WTRU receiving configurations and parameters to determine zone information; the WTRU receiving an LTM configuration for a candidate cell; the WTRU receiving an LTM-related measurement configuration (associated with the LTM candidate), where the measurement configuration provides associations to several zones; the measurement may be part of a measConfig in an RRCreconfiguration, CSIconfiguration, or through a new information element specifically designed for the LTM procedure; the association of the measurement configuration to a zone may be achieved by explicitly providing a set of zone identification information on which this measurement configuration is activated, or this information may be provided in different information elements; the WTRU performing configured non-radio measurements on its location according to configured periodicity; the WTRU determining its location / zone through non-radio measurements; the WTRU evaluating conditions / events for configured LTM measurements. The WTRU monitors active measurement configurations and provides reports to the network according to their configurations. When a WTRU zone changes, the WTRU can activate measurement configurations that are configured to be activated in the new zone. When a WTRU zone changes, the WTRU deactivates measurement configurations that are not configured to be activated in the new zone.
[0341] An exemplary embodiment of the L1L2 trigger mobility procedure can be described with reference to Figure 13. This procedure can be initiated for a WTRU in an RRC connected state. The WTRU can provide its capability information related to lower-layer mobility / LTM handling, and additional support information. This step may be accompanied by a report of a set of non-radio measurements. Capability and support information transfer can be triggered by the WTRU itself, for example, if its measurements indicate any degradation of coverage, or if the WTRU is running or has started running an application that requires low mobility interruption. In another embodiment, the WTRU can be triggered by the network to send capability and support information. The network can trigger the WTRU by sending a request (e.g., an explicit one) to the WTRU. The network request can be sent, for example, as an RRC message. After receiving the WTRU capability and support information, the network can provide the WTRU with coverage and deployment topology (e.g., in a preferred format). This information can be provided either as WTRU-specific signaling or as system information broadcast signaling. In an alternative design, basic coverage information may be transmitted as a system information broadcast and then refined in WTRU-specific signaling for WTRU application requirements and its capabilities. The WTRU may receive the LTM configuration from the network, along with (e.g., preferred) non-radio measurements and (e.g., preferred) events for reporting purposes. Coverage information and LTM configuration may be transmitted by the network simultaneously or in any order. Once the configuration is completed by the network, the WTRU may begin measuring and monitoring the configured non-radio measurements. In some cases, there may be an additional activation step for the measurement configuration that allows the WTRU to begin measuring and monitoring the configured quantities.A WTRU can be configured by the network to perform periodic measurements of non-radio quantities, or it can be configured to detect changes in its radio or non-radio measurements. In this case, the WTRU can perform new measurements and move on to the next step of evaluating the reporting conditions. The WTRU can estimate its non-radio measurements, allowing it to determine its zone from the coverage topology configuration provided by the network. In the case of an event-based LTM measurement configuration, the WTRU can calculate measurements according to a configured or standardized measurement model, and the measurements can be L1, L3, combined, or biased quantities. After estimating the configured non-radio measurements, the WTRU can evaluate the conditions set as event trigger conditions for measurement reporting. If the conditions are met and result in triggering this event, 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 report received from the WTRU provides information to the network so that it can determine the next (e.g., appropriate) step. A WTRU can be changed by the network from its current serving cell to one of the configured and activated LTM cell configurations that it has visibility from its WTRU measurement report. This decision may be the result of calculations of the measurements reported by the WTRU, combined with network-level optimization considerations such as 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 switching command to the WTRU. When the WTRU receives the network command to perform an LTM mobility switch, it can perform the mobility switch to the target cell configuration commanded by the network.
[0342] LTM switching network commands can include indications for the target LTM candidate configuration. In addition to the target LTM candidate configuration, LTM switching network commands can indicate WTRU behavior for MAC / RLC reset. The type of UL-indicated WTRU can be sent following the LTM switching event.
[0343] After receiving an LTM candidate configuration for performing an LTM switchover, the WTRU will perform an LTM switchover to the target candidate. The LTM switchover may include local handling of MAC and RLC entities in the WTRU. In one embodiment, an indication for performing a MAC / RLC entity reset may be provided to the WTRU (e.g., explicitly) as part of the LTM configuration candidate. The WTRU may perform the MAC and / or RLC entity reset according to the configuration of the selected LTM candidate. In another embodiment, the WTRU may determine such information based on whether the LTM target candidate involves an intra-DU switchover or an inter-DU switchover, and by performing a pre-configured MAC / RLC reset action for each of the intra-DU or inter-DU switchover scenarios. In yet another embodiment, the MAC / RLC reset handling may be indicated as part of the LTM switchover command.
[0344] Other parts of the LTM switching can relate to providing the network with an indication of the WTRU's LTM switching execution. This is necessary so that both the WTRU and the network have a common view for communicating with each other after the LTM switching without interruption. The WTRU can send a UL indication on the LTM target candidate provided by the network. This UL indication, the associated sequence selection, and the selection of the sending resource on which this indication is sent can be part of the LTM configuration itself. In one embodiment, the WTRU can perform the LTM switching by selecting a UL LTM switching indication received in a network command.
[0345] In an LTM procedure embodiment based on location and orientation events without network deployment information, the WTRU is provided with a zone determination configuration but not network deployment information. The WTRU can use its location and orientation information to trigger lower-layer reports to the network configured as part of a mobility procedure triggered by the lower layer. The WTRU report can be through location and orientation measurements, triggers, and network configurations to thresholds. The network can use its report to determine the cell and beam for the WTRU, which it issues cell switching commands to the WTRU.This embodiment includes the following actions: WTRU capability transfer for lower-layer mobility handling and related support information that supports the LTM procedure based on non-radio measurements; the WTRU receiving zone information and orientation-specific parameters and a configuration for determining references (such as reference TRP selection); the WTRU receiving the LTM configuration along with (e.g., preferred) events for reporting purposes set for (e.g., preferred) LTM non-radio measurements and combinations of non-radio measurements; the WTRU performing configured non-radio measurements for its location and orientation according to configured periodicity; the WTRU detecting changes in non-radio or radio measurements; the WTRU determining its zone through non-radio measurements and zone configuration; WTRU evaluation of configured events using conditions set for location and orientation; and the WTRU entering a specific zone and matching to a given reference location according to the configuration. For event triggering to have orientation, this may include event-based WTRU reporting of its zone, location / position, and potentially radiometric data according to the configuration, the WTRU receiving a network command to perform LTM mobility switching, where the network can determine the target cell / beam configuration for the WTRU using the WTRU report and other system-level aspects, the WTRU performing LTM mobility switching according to the network command, the WTRU performing protocol stack handling according to network indications, either through dynamic signaling or as part of the LTM configuration, and the WTRU transmitting UL indications according to network configurations / indications, where the network can indicate, through the LTM switching command or through the previous configuration, that it transmits RS or PUCCH-based indications.
[0346] In the case of an action in which the WTRU receives an LTM configuration along with (for example, a preferred) LTM non-radio metric, the network can configure the WTRU for events relating to zone entries (LTM-CM2) and potentially combined with speed or orientation (LTM-OT1) aligned to a specific location. Furthermore, the network may choose to configure a joint event that captures these two aspects through a single event such as LTM-CM2O1.
[0347] In the case of an embodiment of an LTM procedure that uses network topology information and is based on events relating to non-radio measurements, this embodiment includes the following actions: WTRU capability transfer for lower-layer mobility / LTM handling and related support information that supports the LTM procedure based on non-radio measurements; the WTRU receiving coverage and deployment topology and related configurations; the WTRU receiving the LTM configuration along with (e.g., preferred) events for reporting purposes set for combinations of non-radio measurements that utilize (e.g., preferred) LTM non-radio measurements and deployment / coverage information provided by the network; the WTRU performing the configured non-radio measurements; the WTRU detecting changes in non-radio or radio measurements; the WTRU determining its zone through the non-radio measurements; and the configured events using conditions set for non-radio measurement. The WTRU evaluation of the event and, in the case of event triggering, event-based WTRU reporting of its zone, location / position, and radio metric according to the configuration, the WTRU receiving a network command to perform LTM mobility switching, where the network can determine the target cell / beam configuration for the WTRU using the WTRU report and other system-level aspects, the WTRU performing LTM mobility switching according to the network command, the WTRU performing protocol stack handling according to the network indication, and the WTRU transmitting UL indications according to the network configuration / indications, where the network can indicate through the LTM switching command or through the previous configuration that it transmits RS or PUCCH-based indications.
[0348] If a WTRU is receiving an LTM configuration with (e.g., preferred) LTM non-radio measurements and (e.g., preferred) events for a set reporting purpose, the network may indicate, as part of the configuration, that the following non-radio events may be configured, namely, non-radio events LTM-OD1, LTM-OD2 may be configured for a scenario involving rotational and translational mobility to several specific TRP(DU) locations, non-radio events LTM-CM1, LTM-CM2, LTM-CM2V1 may be configured for a potential switching assessment when the WTRU may be in a given zone, and non-radio event LTM-CM2V1 may be configured for a potential switching assessment when the WTRU is entering a given zone at high speed.
[0349] In embodiments where LTM measurement activation / deactivation is associated with zones, the WTRU is provided with a zone determination configuration. The WTRU can use its location information to determine its zone according to the network configuration. As part of the LTM procedure, the WTRU can be configured by the network with LTM candidates. To reduce measurement and tracking overhead, LTM measurements can be mapped to (e.g., relevant zones). These measurements may need to be activated, deactivated, performed, and reported when (e.g., only when) the WTRU itself determines that it is in those zones. This thus provides a lean mechanism for the WTRU to trigger measurements in (e.g., preferred) zones (e.g., only in that zone) and then provide reports to the network according to the reporting and triggers in these measurements. The network can use the relevant measurement reports to trigger mobility procedures to target LTM candidates.This embodiment may include any of the following actions: WTRU capability transfer for lower-layer mobility / LTM handling and related support information that supports the LTM procedure based on non-wireless measurements; the WTRU receiving configuration and (e.g., preferred) parameters to determine zone information; the WTRU receiving an LTM configuration for a candidate cell; the WTRU receiving an LTM-related measurement configuration (associated with the LTM candidate), where the measurement configuration provides association to several zones; the WTRU performing configured non-wireless measurements for its location according to configured periodicity; the WTRU determining its location / zone through non-wireless measurements; the WTRU evaluating conditions / events for configured LTM measurements; when the WTRU zone changes, the WTRU may activate measurement configurations configured to be activated in the new zone, and the WTRU may deactivate measurement configurations not configured to be activated in the new zone; and the WTRU monitoring active measurement configurations and providing reports to the network according to their configurations.
[0350] If a WTRU receives an LTM-related measurement configuration and that configuration provides associations to several zones, the measurement may be part of measConfig in RRCreconfiguration, CSIconfiguration, or through a new information element specifically designed for the LTM procedure. The association of the measurement configuration to a zone can be achieved by (e.g., explicitly) providing a set of zone identification information on which this measurement configuration is activated, or this information may be provided in a different information element.
[0351] In the case of an embodiment where the LTM procedure is based on periodic reporting of non-radio measurements, this embodiment includes the following key actions: receiving WTRU capability transfers for lower-layer mobility / LTM handling and related support information, coverage and deployment topology, and related configurations, which support the LTM procedure based on non-radio measurements; the WTRU receiving the LTM configuration along with (e.g., preferred) LTM non-radio measurements and periodic reporting configurations; the WTRU performing the configured non-radio measurements; the WTRU determining its zone through the non-radio measurements; and, upon timer expiration, the WTRU reporting the configured non-radio measurements, including its zone, location / position, and radio measurements, according to the configuration; and, upon receiving the WTRU measurement report, the network being able to compare the measurements to thresholds and previous measurements; and the network being able to process the WTRU report and other system-level considerations. This may include determining one of the activated LTM configurations based on the above, the WTRU receiving a network command to perform an LTM mobility switch, where the network can determine a target cell / beam configuration for the WTRU using the WTRU's non-radiometric metering report and other system-level aspects, the WTRU performing an LTM mobility switch in accordance with the network command, the WTRU performing protocol stack handling in accordance with the network indication, and the WTRU transmitting a UL indication in accordance with the network configuration / indication, where the network can indicate, through the LTM switch command or through the previous configuration, that it transmits an RS or PUCCH-based indication.
[0352] In embodiments where the activation of an LTM candidate configuration is based on zone information reported by the WTRU, the network can control the activation and deactivation of (e.g., preferred) LTM candidate configurations. As part of the configuration, the network can provide parameters related to determining the WTRU zone information. The network can also provide necessary measurement information that enables the WTRU to determine its zone information. The zone information can be determined from location information that the WTRU can obtain from local GNSS measurements. This can be done through a local GNSS receiver. The location information can be determined through other non-radio measurements. The WTRU can inform the network (e.g., a priori) of its ability to perform non-3GPP radio measurements and non-radio measurements.
[0353] A WTRU can receive LTM candidate configurations from the network. These candidate configurations may include cell configurations and events and conditions for non-radio measurements that can be used to evaluate whether a WTRU triggers a WTRU report.
[0354] A 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 zone information according to the coverage topology configuration. The WTRU can be configured to report zone information to the network. Reporting can be configured with periodicity according to WTRU mobility and QoS requirements. To reduce reporting overhead, WTRU reporting is event-based and can be reported only when the zone estimated by the WTRU has changed from the previous zone (for example, only in that case). WTRU zone information can be sent to the network as part of the UCI. A new MAC-CE can be designed to provide zone information. Upon receiving updated zone information, the network can update the ACTIVATED LTM configuration. The network can send an "LTM config activate" MAC-CE that can activate the LTM configuration. Two different MAC-CEs can be designed to adapt to different numbers of LTM configurations that may need to be activated for the final LTM procedure. A customized MAC-CE can be designed for this purpose, and the identification information of the LTM configuration can provide a pointer to the configured LTM configuration through RRC signaling. One design for the activation MAC-CE can be bitmap-based, allowing the network to indicate the activation status for each configured LTM configuration. In more reactive situations, PHY-based signaling such as DCI can be used to activate one of the configured LTM configurations.
[0355] Therefore, this embodiment offers significant advantages in terms of reducing resource overhead and latency. The WTRU can monitor configured measurements (e.g., closely) only for the LTM configuration corresponding to its location activated by the network. This avoids the WTRU performing unnecessary measurements for candidate configurations that are not required for its updated location.
[0356] This embodiment is illustrated by the flowchart in Figure 14.
[0357] Referring to Figure 14, the procedure can be initiated in step 1405, when the WTRU is in the RRC_CONNECTED state. In step 1410, the WTRU capability for lower-layer mobility / LTM handling and associated support information, supporting the LTM procedure based on non-radiometric measurements, can be sent to the gNB / cell / base station. In step 1415, the WTRU can receive the coverage and deployment topology and associated configuration to determine zone information. In step 1420, the WTRU can receive the LTM configuration along with (e.g., preferred) LTM non-radiometric measurements and (e.g., preferred) non-radio events for reporting purposes. A subset of the LTM configuration can be indicated as ACTIVATED by the network as part of the configuration / initialization. In step 1425, the WTRU can be configured to periodically determine / estimate its zone information based on non-radiometric measurements to assist in configuration activation / deactivation. In step 1430, in order to determine its zone through non-wireless measurements, the WTRU may perform configured measurements associated with the ACTIVATED LTM configuration, and may perform configured non-wireless measurements for activation / deactivation purposes configured to determine its zone information.
[0358] In step 1435, the WTRU can determine whether the newly determined zone is different from the previous zone. If so, the WTRU can perform the following four steps:
[0359] In step 1440, the WTRU can send a report through UL to the network showing its newly determined zone information.
[0360] In step 1445, the WTRU can receive updated coverage information from the network (for example, an update to the coverage topology).
[0361] 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 list of configured LTM candidates.
[0362] In step 1455, the WTRU can update the activation status of the configured list of LTM candidates and update that status according to network indications.
[0363] Referring to Figure 15, a method 1500 is shown, implemented in a wireless transceiver unit (WTRU) for performing cell switching based on WTRU zone location, according to one embodiment. Method 1500 may include a step 1510 in which the WTRU can transmit a first message to the network containing first information relating to non-radiometric capability. Method 1500 may include a step 1520 in which the WTRU can receive a second message from the network containing second information indicating a first configuration for determining the WTRU's zone location based on non-radiometric capability. Method 1500 may include a step 1530 in which the WTRU can receive a third message from the network containing third information indicating multiple mobility configurations and a second configuration for reporting trigger events based on non-radiometric. Multiple mobility configurations may be multiple lower-layer triggered mobility (LTM) configurations. Method 1500 may include a step 1540 in which the WTRU can determine the WTRU zone location based on a first configuration for the determined zone location. Method 1500 may include a step 1550 in which the WTRU can send a fourth message to the network indicating the determined zone location, provided that a reporting trigger event among the configured reporting trigger events is met. Method 1500 may also include a step 1560 in which, in response to sending the fourth message, the WTRU can receive a command message from the network containing information for performing a cell switch to a target cell associated with one of the multiple mobility configurations. The cell switch may be an LTM mobility cell switch. Method 1500 may also include a step 1570 in which the WTRU can perform a cell switch to the target cell based on the command message.
[0364] Non-wireless measurement may include at least one measurement based on data from a local sensor. The local sensor may be a motion sensor, an environmental sensor, a position sensor, or a speed measuring sensor.
[0365] Each of the multiple mobility configurations may include information indicating the zone location for activating or deactivating the mobility configuration. A fourth message may further indicate the activated mobility configuration among the multiple mobility configurations based on the determined zone location.
[0366] Method 1500 may include steps such as enabling a WTRU to perform non-wireless measurements based on its non-wireless measurement capability, and enabling the WTRU to determine non-wireless measurement quantities based on the performed non-wireless measurements. Performing non-wireless measurements on a WTRU location may follow a configured periodicity. A configured reporting trigger event may include a change in a determined WTRU zone location from a previously determined WTRU zone location.
[0367] Method 1500 may include a step in which the WTRU can perform protocol stack handling based on a single mobility configuration associated with the target cell. Alternatively, Method 1500 may include a step in which the WTRU can perform protocol stack handling based on network indications on dynamic signaling.
[0368] Method 1500 may include a step in which the WTRU can send an uplink UL message to the network that includes an indication of performing a cell switchover.
[0369] Method 1500 may include the step that a second piece of information further indicates a third configuration for determining WTRU orientation based on non-wireless measurement capability, the WTRU can determine WTRU orientation based on the third configuration, and a fourth message further indicates the determined WTRU orientation. The reporting trigger condition may include either (i) a change in the determined WTRU zone location from a previously determined WTRU zone location, or (ii) a change in WTRU orientation exceeding a configured threshold.
[0370] Referring to Figure 16, a method 1600 is provided in a wireless transceiver unit (WTRU) for performing cell switching based on WTRU zone location, according to another embodiment.
[0371] Method 1600 may include a step 1610 in which the WTRU can send a first message to the network containing information about non-radio measurement capabilities. Method 1600 may include a step 1620 in which the WTRU can receive a second message from the network containing information about network coverage and deployment topology. Method 1600 may include a step 1630 in which the WTRU can receive a third message from the network containing information about multiple mobility configurations and (e.g., LTM) non-radio measurements about network coverage and deployment topology. Multiple mobility configurations may be multiple lower-layer triggered mobility (LTM) configurations. Method 1600 may include a step 1640 in which the WTRU can determine one or more changes in (e.g., LTM) non-radio measurements. Method 1600 may include a step 1650 in which the WTRU can determine a WTRU zone location based on non-radio measurements from non-radio measurements, as well as based on network coverage and deployment topology. Method 1600 may include a step 1660 in which the WTRU can transmit a determined zone location to the network. Method 1600 may include a step 1670 in which the WTRU can receive a command message from the network containing information for performing a cell switch to a target cell associated with one of several configurations. The cell switch may be an LTM mobility cell switch. Method 1600 may include a step 1680 in which the WTRU can perform a cell switch to a target cell based on the command message.
[0372] Referring to Figure 17, a method 1700 performed in a WTRU for performing non-wireless measurements based on WTRU zone information is shown according to one embodiment.
[0373] Method 1700 may include a step 1710 in which the WTRU can send a first message to the network containing information about non-radio measurement capabilities. Method 1700 may include a step 1720 in which the WTRU can receive a second message from the network containing information about configurations for determining the WTRU's zone information. Method 1700 may include a step 1730 in which the WTRU can receive a third message from the network containing multiple mobility configurations and multiple (e.g., LTM) non-radio measurement configurations associated with multiple zone information. The multiple mobility configurations may be multiple lower-layer triggered mobility (LTM) configurations. Method 1700 may include a step 1740 in which the WTRU can determine zone information based on the second message. Method 1700 may include a step 1750 in which the WTRU can determine one of multiple non-radio measurements associated with the zone information. Method 1700 may include a step 1760 in which a WTRU can perform a determined (e.g., LTM) non-wireless measurement based on the determined zone information. Each of the multiple zone information may include a zone identifier, each zone identifier may be associated with information indicating the activation or deactivation of a (e.g., LTM) non-wireless measurement.
[0374] While features and elements are provided above in specific combinations, those skilled in the art will understand that each feature or element may 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 examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from its spirit and scope. Elements, actions, or commands used in the description of this application should not be construed as important or essential to the invention unless so expressly provided. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure should be limited only by the terms of the appended claims, together with the entire scope of equivalents to which such claims are granted. It should be understood that this disclosure is not limited to any particular method or system.
[0375] For simplicity, the embodiments described above will be explained in terms of the terminology and structure of infrared-compatible devices, i.e., infrared emitters and receivers. However, the embodiments described are not limited to these systems and may be applied to other systems using other forms of electromagnetic waves, or non-electromagnetic waves such as sound waves.
[0376] Furthermore, it should be understood that the terms used herein are intended solely to describe specific embodiments and are not intended to limit them. As used herein, the terms “video” or “image” may mean a snapshot, a single image, and / or multiple images displayed over a time basis. As another example, when referred to herein, the terms “user device” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of several embodiments of a WTRU, (iii) a wireless-enabled and / or wired (e.g., tetherable) device configured using some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired device configured using less structure and functionality than all of a WTRU, or (iv) similar. Details of exemplary WTRUs that can represent any WTRU enumerated herein are provided herein with respect to Figures 1A to 1D. As another example, the various embodiments disclosed above and below in this specification are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays may be used, and that some or all of the present disclosure and the various embodiments disclosed may be modified as appropriate without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adapted reality experience.
[0377] Furthermore, the methods provided herein may be implemented in computer programs, software, or firmware embedded in computer-readable media 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 such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). A software-related processor may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
[0378] Modifications of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments to which it may be applied, it should be understood that the exemplary embodiments are merely examples and should not be taken as limiting the scope of the following claims. For example, embodiments provided herein include a handheld device that includes, or may be used with, any suitable voltage source, such as a battery, which provides any suitable voltage.
[0379] Furthermore, the embodiments provided above refer to other devices, including processing platforms, computing systems, controllers, and processors. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the conventions of those skilled in computer programming, references to acts and symbolic representations of actions or instructions may be performed by various CPUs and memories. Such acts and actions or instructions may be referred to as "executed," "computer-executed," or "CPU-executed."
[0380] Those skilled in the art will understand that actions and symbolically represented operations or instructions involve the manipulation of electrical signals by the CPU. The electrical system represents data bits, causing the resulting transformation or reduction of electrical signals and the preservation of 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 locations where data bits are preserved are physical locations having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that embodiments are not limited to the platforms or CPUs described above, and that other platforms and CPUs may support the methods provided.
[0381] Data bits may also be maintained on computer-readable media, including magnetic 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. The computer-readable media may include cooperating or interconnected computer-readable media that reside exclusively on a processing system or are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that embodiments are not limited to the memory described above, and that other platforms and memories may support the methods provided.
[0382] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor in a mobile unit, a network element, and / or any other computing device.
[0383] There is little distinction left between hardware and software implementations of a system configuration. The use of hardware or software is generally (but not always) a design selection representing a cost-effectiveness trade-off, given that in certain contexts the choice between hardware and software can be significant. The processes and / or systems and / or other technologies described herein can achieve various means (e.g., hardware, software, and / or firmware). The preferred means may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose primarily hardware and / or firmware means. If flexibility is paramount, the implementer may choose primarily software implementation. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.
[0384] The detailed description above illustrates various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that, insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, several parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, a person skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, in whole or in part, 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 substantially any combination thereof, and that designing circuits and / or writing code for software and / or firmware is well within the skill of a person skilled in the art in light of this disclosure. Furthermore, a person skilled in the art will understand that mechanisms of the subject matter described herein can be distributed as various forms of program products, and that exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-carrying medium used to actually carry out the distribution.Examples of signal-carrying media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).
[0385] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then, using engineering conventions, to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into data processing systems through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, computing entities such as an operating system, a driver, a graphical user interface, and an application program, one or more interaction devices such as a touchpad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.
[0386] The subject matter described herein may include different components contained within or connected to other different components. It should be understood that such presented architectures are merely examples, and in practice, many other architectures can be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” in such a way that the desired functionality can be achieved. Thus, any two components combined herein to achieve a particular functionality, whether in architecture or as intermediate components, can be considered “associated” with one another in such a way that the desired functionality can be achieved. Similarly, any two components thus associated can also be considered “operably connected” or “operably coupled” with one another in order to achieve the desired functionality. Any two components that can be associated in such a way can also be considered “operably coupled” with one another in order to achieve the desired functionality. Specific examples of those that are operably coupled include, but are not limited to, physically matable and / or physically interacting components, as well as / or wirelessly interactable and / or wirelessly interacting components, as well as / or logically interacting and / or logically interactable components.
[0387] With regard to substantially any use of plural and / or singular terms herein, those skilled in the art can translate from plural to singular and / or singular to plural as appropriate to the context and / or use. Various singular / plural substitutions may be explicitly stated herein for clarity.
[0388] In general, it will be understood by those skilled in the art that the terms used herein, in particular in the appended claims (e.g., the text of the appended claims), are generally intended to be “open” terms (for example, the term “including” should be interpreted as “including, but not limited to,” the term “having” should be interpreted as “having at least,” and the term “including” should be interpreted as “including, but not limited to,” etc.). It will further be understood by those skilled in the art that if a certain number of claim descriptions are intended to be introduced, such intention will be explicitly stated in that claim, and if such statement is not present, such intention does not exist. For example, if only one item is intended, the term “single” or similar word may be used. For the sake of understanding, the following appended claims and / or description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim descriptions. However, the use of such a phrase should not be interpreted as implying that the introduction of a claim description by the indefinite article "a" or "an" limits any particular claim containing such introduced claim description to embodiments containing only one such description, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of the definite article used to introduce a claim description. Furthermore, even if a specific number of introduced claim descriptions are explicitly stated, it will be recognized that such a statement should be interpreted as meaning at least the number stated (for example, the mere statement "two descriptions" without other modifiers means at least two descriptions, or two or more descriptions).Furthermore, in cases where a convention similar to "at least one of A, B, and C" is used, such configurations are generally intended to be understood by those skilled in the art (for example, "a system having at least one of A, B, and C" is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or systems having A, B and C together). It will be further understood by those skilled in the art that any substantially disjunctive word and / or phrase presenting two or more alternative terms should be understood, whether in the specification, claims, or drawings, as intended to include the possibility of including one of those terms, either one of those terms, or both of those terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.” Furthermore, the term “any of” as used herein, followed by an enumeration of multiple items and / or multiple categories of items, is intended to include, individually or in combination with other items and / or other categories of items, “any of,” “any combination of,” “any multiple of,” and / or “any combination of multiples of.” Moreover, the term “set” as used herein is intended to include any number of items, including zero. In addition, the term “number” as used herein is intended to include any number, including zero. Furthermore, the term “multiple” as used herein is intended to be synonymous with “a plurality.”
[0389] Furthermore, if any feature or aspect of this disclosure is described in relation to the Markush Group, a person skilled in the art will recognize that this disclosure also describes any individual member or subgroup of a member of the Markush Group.
[0390] As will be understood by those skilled in the art, for all purposes, including providing a specification, all scopes disclosed herein also encompass all possible subscopes and combinations thereof. Any enumerated scope can be readily recognized as fully explaining and enabling that the same scope may be divided into at least two, one-third, one-quarter, one-fifth, one-tenth, and so on. As a non-limiting example, each scope described herein may readily be divided into a lower third, a middle third, an upper third, and so on. Also, as will be understood by those skilled in the art, all words such as “at most,” “at least,” “greater than,” and “less than” include the number stated and refer to scopes that may later be divided into subscopes, as described above. Finally, as will be understood by those skilled in the art, a scope includes each individual member. Thus, for example, a group having one to three cells refers to a group having one, two, or three cells. Similarly, a group having one to five cells refers to a group having one, two, three, four, or five cells, and so on.
[0391] Furthermore, unless otherwise stated, the claims should not be interpreted as being limited to the order or elements provided. In addition, the use of the term “means for” in any claim is intended to implement § 112(6) of the U.S. Patent Act or the means-plus-function claim format, and any claim without the term “means for” is not intended to do so.
Claims
1. A method implemented in a wireless transceiver unit (WTRU), The steps include sending a first message to the network containing first information relating to non-wireless measurement capabilities, The steps include receiving a second message from the network, which includes second information indicating a first configuration for determining at least one zone location of the WTRU based on the non-wireless measurement capability, The steps include receiving a third message from the network, which includes third information indicating a plurality of mobility configurations and a second configuration of one or more reporting trigger events based on non-radiometric measurements, The steps include determining the zone location of the WTRU based on the first configuration described above, The steps include sending a fourth message indicating the determined zone location to the network when one of the one or more reporting trigger events is met, In response to the step of sending the fourth message, the system receives a command message from the network containing information for performing a cell switch to a target cell associated with one of the multiple mobility configurations, A step of performing the cell switching to the target cell based on the command message. A method that includes [a certain feature].
2. The method according to claim 1, wherein the plurality of mobility configurations are a plurality of lower layer trigger mobility LTM configurations, and the cell switching is LTM mobility cell switching.
3. A step of performing the non-wireless measurement based on the non-wireless measurement capability, A step of determining the non-wireless measurement quantity based on the non-wireless measurement performed above. The method according to claim 1 or 2, comprising:
4. The method according to claim 3, further comprising the step of performing the non-wireless measurement on the WTRU location according to the configured periodicity.
5. The method according to any one of claims 1 to 4, wherein the configured reporting trigger event includes a change in the determined WTRU zone location from a previously determined WTRU zone location.
6. The method according to any one of claims 1 to 5, further comprising the step of performing protocol stack handling based on the one mobility configuration associated with the target cell.
7. The method according to claim 1, further comprising the step of performing protocol stack handling based on network indications on dynamic signaling.
8. The method according to any one of claims 1 to 7, further comprising the step of sending an uplink UL message to the network that includes an indication of the implementation of the cell switching.
9. The method according to any one of claims 1 to 8, wherein the non-wireless measurement includes at least one measurement based on data from a local sensor.
10. The method according to claim 9, wherein the local sensor is one of a motion sensor, an environmental sensor, a position sensor, and a speed measuring sensor.
11. The second information further illustrates a third configuration for determining WTRU orientation based on non-wireless measurement capability, and the method is as follows: Steps to determine the WTRU orientation based on the third configuration described above. Furthermore, The method according to any one of claims 1 to 10, wherein the fourth message further indicates the determined WTRU orientation.
12. The method according to claim 11, wherein the reporting trigger condition includes either (i) a change in the determined WTRU zone location from a previously determined WTRU zone location, or (ii) a change in the orientation of the WTRU that exceeds a configured threshold.
13. The method according to any one of claims 1 to 12, wherein each of the plurality of mobility configurations includes information indicating a zone location for activating or deactivating the mobility configuration.
14. The method according to claim 13, wherein the fourth message further indicates an activated mobility configuration among the plurality of mobility configurations based on the determined zone location.
15. A wireless transceiver unit (WTRU) comprising memory and a processor, A first message containing first information regarding non-wireless measurement capabilities is sent to the network. The network receives a second message containing second information indicating a first configuration for determining at least one zone location of the WTRU based on the non-wireless measurement capability, The network receives a third message containing third information, which indicates a plurality of mobility configurations and a second configuration of one or more reporting trigger events based on non-radiometric measurements. Based on the first configuration described above, the zone location of the WTRU is determined, When one of the reporting trigger events among the one or more reporting trigger events is met, a fourth message indicating the determined zone location is sent to the network. In response to sending the fourth message, the network receives a command message containing information for performing a cell switch to a target cell associated with one of the multiple mobility configurations. Based on the command message, the cell switching to the target cell is performed. A well-configured WTRU.
16. The WTRU according to claim 15, wherein the plurality of mobility configurations are a plurality of lower layer trigger mobility LTM configurations, and the cell switching is LTM mobility cell switching.
17. Based on the aforementioned non-wireless measurement capability, the non-wireless measurement is performed. The non-wireless measurement quantity is determined based on the non-wireless measurement performed as described above. The WTRU according to claim 15 or 16, configured as such.
18. The WTRU according to claim 17, configured to perform the non-wireless measurement on the WTRU location according to the configured periodicity.
19. The configured reporting trigger event includes a change in the determined WTRU zone location from a previously determined WTRU zone location, according to any one of claims 15 to 18.
20. The WTRU according to any one of claims 15 to 19, configured to perform protocol stack handling based on the one mobility configuration associated with the target cell.
21. The WTRU according to claim 15, comprising performing protocol stack handling based on network indications on dynamic signaling.
22. The WTRU according to any one of claims 15 to 21, configured to transmit an uplink UL message to the network including an indication of the implementation of the cell switching.
23. The WTRU according to any one of claims 15 to 22, wherein the non-wireless measurement includes at least one measurement based on data from a local sensor.
24. The WTRU according to claim 23, wherein the local sensor is one of a motion sensor, an environmental sensor, a position sensor, and a speed measuring sensor.
25. The second information further illustrates a third configuration for determining WTRU orientation based on non-wireless measurement capability, wherein the WTRU is The system is configured to determine the WTRU orientation based on the third configuration described above. The WTRU according to any one of claims 15 to 24, wherein the fourth message further indicates the determined WTRU orientation.
26. The WTRU according to claim 25, wherein the reporting trigger condition includes either (i) a change in the determined WTRU zone location from a previously determined WTRU zone location, or (ii) a change in the orientation of the WTRU that exceeds a configured threshold.
27. The WTRU according to any one of claims 15 to 26, wherein each of the plurality of mobility configurations includes information indicating a zone location for activating or deactivating the mobility configuration.
28. The WTRU according to claim 27, wherein the fourth message further indicates an activated mobility configuration among the plurality of mobility configurations based on the determined zone location.
29. A method implemented in a wireless transceiver unit (WTRU), The steps include sending a first message to the network containing information about non-wireless measurement capabilities, The steps include receiving a second message from the aforementioned network, which includes information regarding network coverage and deployment topology, The steps include receiving a third message from the network, which includes information indicating multiple mobility configurations and non-radio measurements about network coverage and deployment topology, A step of determining one or more changes in non-wireless metering quantities, The steps include determining the WTRU zone location based on non-wireless measurements from non-wireless measurements, as well as based on network coverage and deployment topology, The steps include transmitting the determined zone location to the network, The steps include receiving a command message from the network containing information for performing a cell switch to a target cell associated with one of the multiple mobility configurations, A step of performing the cell switching to the target cell based on the command message. A method that includes [a certain feature].
30. A wireless transceiver unit (WTRU) comprising memory and a processor, A first message containing information about non-wireless measurement capabilities is sent to the network. A second message containing information about network coverage and deployment topology is received from the aforementioned network. A third message is received from the aforementioned network, which includes information indicating multiple mobility configurations and non-radio measurements about network coverage and deployment topology. Determine the change in one or more non-wireless quantifiers, Based on non-wireless measurements from non-wireless measurements, as well as network coverage and deployment topology, the WTRU zone location is determined. The determined zone location is transmitted to the aforementioned network. The network receives a command message containing information for performing a cell switch to a target cell associated with one of the multiple configurations. Based on the command message, the cell switching to the target cell is performed. A well-configured WTRU.
31. A method implemented in a wireless transceiver unit (WTRU), The steps include sending a first message to the network containing information about non-wireless measurement capabilities, The steps include receiving a second message from the network containing information about the configuration for determining the zone information of the WTRU, The steps include receiving a third message from the aforementioned network, which includes a plurality of mobility configurations and a plurality of non-wireless measurement configurations associated with a plurality of zone information, A step of determining zone information based on the second message, A step of determining one of the plurality of non-wireless measurements associated with the zone information, The steps include: performing the determined non-wireless measurement based on the determined zone information; A method that includes [a certain feature].
32. The method according to claim 31, wherein each of the plurality of zone information includes a zone identifier, and each zone identifier is associated with information indicating the activation or deactivation of non-wireless measurement.
33. A wireless transceiver unit (WTRU) comprising memory and a processor, A first message containing information about non-wireless measurement capabilities is sent to the network. A second message is received from the aforementioned network, which includes information about the configuration for determining the zone information of the WTRU. A third message is received from the aforementioned network, which includes multiple mobility configurations and multiple non-wireless measurement configurations associated with multiple zone information. Based on the second message described above, determine the zone information. Determine one of the multiple non-wireless measurements associated with the zone information, Based on the determined zone information, the determined non-wireless measurement is performed. A well-configured WTRU.
34. The WTRU according to claim 33, wherein each of the plurality of zone information includes a zone identifier, and each zone identifier is associated with information indicating the activation or deactivation of non-wireless measurement.