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

Abstract

Programs, methods, architectures, apparatus, systems, devices, and computer program products are provided for network controlled L1 / L2 triggered mobility (LTM) procedures. An example method includes transmitting information indicating an ability to measure radio and non-radio amounts associated with measurements of one or more rotational or translational motions; receiving configuration information indicating a zone configuration for determining a zone from radio and / or non-radio measurements, and / or a set of mobility configurations and a set of joint events associated with radio and / or non-radio measurements; estimating one or more radio and / or non-radio measurements based on the configuration information; and transmitting, based on a triggered joint event of the set of joint events, a measurement report indicating radio and / or non-radio measurements and zone information derived from the estimated non-radio measurements.

Description

[0001] Cross-references to related applications This application claims priority and benefit to U.S. Provisional Application No. 63 / 464434, filed May 5, 2023, with the United States Patent and Trademark Office, the entire contents of which are incorporated herein by reference, as if fully set forth herein in their entirety and for all applicable purposes. Background Technology

[0002] The development of wireless systems for new applications requiring low latency, high reliability, and high availability has led to greater focus and activity on service continuity during mobility and minimizing service disruptions caused by mobility. To this end, 3GPP has defined and standardized several mechanisms, among which faster switching of beams, cells, and network nodes minimizes mobility disruptions. Summary of the Invention

[0003] In the Radio Access Network (RAN), current mobility procedures can operate at the Radio Resource Control (RRC) layer. The RRC layer can also be referred to as Layer 3 (L3). To improve current mobility procedures, for example in 5G New Radio (NR) systems, WTRUs and / or network entities (e.g., base stations, gNBs) can execute (e.g., control) mobility procedures, such as lower-layer triggered mobility procedures (e.g., L1 / L2 mobility).

[0004] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems for Layer 1 / Layer 2 (L1 / L2) mobility of wireless transmit / receive units (WTRUs), which may be based on radio and / or non-radio measurements. L1 / L2 mobility may be controlled based on radio and / or non-radio measurements.

[0005] In some representative embodiments, procedures for activating and / or deactivating L1 / L2 configuration, radio and / or non-radio measurements can be performed for L1 / L2 triggered mobility (LTM) (e.g., at WTRU and / or network entities).

[0006] In some representative embodiments, L1 / L2 triggered mobility (LTM) procedures are performed for network control. One or more of the LTM procedures may include measurement and triggering via radio and / or non-radio measurements. For example, WTRU capabilities for lower-level mobility transfers or transfers, and / or LTM disposition and associated ancillary information may be used. One or more of the LTM procedures may include or be accompanied by a set of reports of radio and / or non-radio measurements.

[0007] For example, for reporting purposes, the WTRU may receive one or more LTM configurations, along with appropriate LTM radio and non-radio measurements and suitable events. In one example, the WTRU may perform one or more radio and / or non-radio measurements of the configuration. In one example, the WTRU may detect changes in non-radio and / or radio measurements. In one example, the WTRU may determine its zone through non-radio measurements.

[0008] In one example, the WTRU and / or network entity can evaluate one or more configured events using conditions set by radio and / or non-radio quantity measurements (or conditions associated with radio and / or non-radio quantity measurements). In one example, upon event triggering, the WTRU can perform event-based WTRU reporting of its zone, location / position, and radio measurements according to the configuration.

[0009] In one example, the WTRU may receive one or more network commands to perform LTM mobility switching, and the network may use WTRU reports of radio and / or non-radio measurements (and / or other system-level aspects) to determine the appropriate target cell / beam configuration for the WTRU. In one example, the WTRU may perform LTM mobility switching according to network commands or instructions, or according to one or more procedures discussed herein.

[0010] In one example, the WTRU may: send information indicating the ability to measure radio and non-radio quantities associated with one or more rotational or translational motion measurements; receive configuration information indicating a zone configuration for determining a zone based on radio and / or non-radio measurements, and / or a set of mobility configurations associated with the radio and / or non-radio measurements and a set of joint events; estimate one or more radio and / or non-radio measurements based on the configuration information; and transmit a measurement report indicating the radio and / or non-radio measurements and zone information derived from the estimated non-radio measurements based on a joint event triggered in the set of joint events. Attached Figure Description

[0011] A more detailed understanding can be obtained through the following detailed description given by way of example, in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are illustrative. Accordingly, the figures and detailed description should not be considered limiting, and other equally valid examples are possible and probable. Furthermore, the same reference numerals (“ref”) in the figures indicate the same elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system; Figure 1B The illustration can be found Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system shown; Figure 1C The illustration can be found Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown. Figure 1D The illustration can be found Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown; Figure 2 This is a program diagram illustrating an example of switching between gNBs within an NR; Figure 3 This is a program diagram illustrating an example procedure for conditional switching of RAN within NR; Figure 4 This is a system diagram illustrating a first example of multi-TRP transmission using a single DCI and a second example of multi-TRP transmission using multiple DCIs; Figure 5 This is a program diagram of an example program used for initial configuration and configuration updates of overlay information and LTM configuration; Figure 6 This is an example of an LTM measurement framework diagram illustrating the association between LTM measurement identifiers and LTM measurement resource configurations; Figure 7 This is another example of an LTM measurement framework diagram illustrating the association between LTM measurement identifiers and LTM measurement resource configurations; Figure 8 This is another example of an LTM measurement framework diagram illustrating the association between LTM measurement identifiers and LTM measurement resource configurations, LTM measurement quantity configurations, and reporting configurations; Figure 9 This is an LTM measurement diagram illustrating an example LTM measurement model with L1 / L2 filtering; Figure 10 This is an LTM measurement diagram illustrating an example LTM measurement model with events based on L1 and L3. Figure 11 This is an LTM measurement diagram illustrating an example LTM measurement model with measurement bias; Figure 12 This is an LTM measurement diagram illustrating an example LTM measurement model that is consistent with L3-based measurements; Figure 13 This is a procedure diagram illustrating an example of a low-level (L1 / L2) mobility procedure using both radio and non-radio measurements; Figure 14This is a program diagram illustrating an example procedure for activating LTM configuration based on UE reports; Figure 15 This is a procedure diagram illustrating an example procedure for low-layer (L1 / L2) mobility, in which the UE reports one or more target configuration candidates; and Figure 16 This is a program diagram illustrating a representative procedure for using UE signaling on one or more target configuration candidates for low-layer (L1 / L2) mobility. Detailed Implementation

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

[0013] Example Communication System The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. (See reference...) Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, in which various elements of the network can utilize, perform, be arranged according to, and / or be adapted and / or configured for the following: the methods, apparatuses and systems provided herein.

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

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

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

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

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

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

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

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

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

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

[0024] Figure 1A Base station 114b can 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 local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of small cells, picocells, or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN106 / 115.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0068] introduction The following acronyms and abbreviations may be used in this article: 3GPP: Third Generation Partnership Project BFD: Beam Fault Detection BFI: Examples of Beam Failure BFR: Beam Fault Recovery BFDR: Beam Fault Detection and Recovery DAPS: Dual Activity Protocol Stack C-RNTI: Cell RNTI CE: Control Element CFRA: Contention-Free RACH Access CHO: Condition Switching CN: Core Network CORESET: Control Resource Set CSI: Channel State Information CSI-RS: CSI Reference Signal CU: Control Unit DAPS: Dual Activity Protocol Stack DCI: Downlink Control Information DL: Downlink DMRS: Demodulation Reference Signal DRX: Discontinuous Receiver DU: Distributed Unit E-UTRAN: Enhanced Universal Terrestrial Radio Access Network FoV: Field of View FR1: Frequency range 1 FR2: Frequency range 2 GCS: Global Coordinate System gNB: Next-Generation Node B GNSS: Global Navigation Satellite System GPRS: General Packet Radio Service GSM: Global System for Mobile Communications HO: Switch IE: Information Elements ICBM: In-cell beam management Layer 1: L1 Layer 2: L2 Layer 1 / Layer 2: L1 / L2 Level 3: L3 LCS: Local Coordinate System LAN: Local Area Network LMF: Location Management Function LTM: L1 / L2 triggered mobility MAC: Media Access Control MAC-CE: MAC control element MCG: Main Cell Group MIB: Master Information Block MIMO: Multiple Input Multiple Output mmWave: millimeter wave NCJT: Non-coherent Joint Transmission NG-RAN: Next Generation Radio Access Network NR: New Radio NTN: Non-Terrestrial Networks OOO: out of sync PCI: Physical Cell Identifier PDCCH: Physical Downlink Control Channel PDCP: Packet Data Convergence Protocol PDSCH: Physical Downlink Shared Channel PHY: Physics PLMN: Public Land Mobile Network PRACH: Physical Random Access Channel PSS: Primary Synchronization Sequence PUCCH: Physical Uplink Control Channel PUSCH: Physical Uplink Shared Channel QCL: Quasi-colocation QoE: Quality of Experience QoS: Quality of Service RACH: Random Access Channel RAN: Radio Access Network RAT: Radio Access Technology RB: Resource Block RLC: Radio Link Control RLF: Radio link failure RLM: Radio Link Monitoring RLM-RS: Radio Link Monitoring Reference Signal RNA: RAN notification region RNTI: Temporary Identifier for Radio Networks RRC: Radio Resource Control RS: Reference signal RSARP: Reference Signal Antenna Relative Phase RSRP: Reference Signal Received Power RSRQ: Reference Signal Reception Quality RSSI: Reference Signal Strength Indicator RSTD: Reference Signal Time Difference Rx: Receive SCG: Secondary Cell Group SCS: Subcarrier Spacing SIB: System Information Block SINR: Signal-to-Interference-to-Noise Ratio SpCell: Special cell. This is the primary cell in the primary cell group; for dual connectivity operations, this can be the primary cell in the secondary cell group. SRS: Detection Reference Signal SSB: Synchronization Signals and Physical Broadcast Control Channel Block SSS: Secondary Synchronization Sequence TA: Tracking Area TCI: Transmission Configuration Indicator TRP: Transmitter / Receiver Point TTT: Trigger Time Tx: Transfer UE: User Equipment UL: Uplink UTRAN: Universal Terrestrial Radio Access Network WLAN: Wireless LAN.

[0069] Overview NR – Layer 3 Mobility Procedure Typically, WTRU mobility can lead to cell changes that affect service continuity. Traditional mobility procedures primarily operate at the RRC layer (e.g., Layer 3 or L3). The network and WTRU can exchange messages, measurements, and configurations before cell changes occur. An overview of L3 mobility procedures is provided below.

[0070] NR gNB switching procedure Figure 2 This is a program diagram illustrating an example of switching between gNBs within an NR. Figure 2 The procedure illustrated herein may be referred to as a traditional handover. When the UE is in RRC_Connected mode, cell and / or gNB-level mobility may require triggering explicit RRC signaling. The UE can report cell quality measurements to the serving (e.g., source) cell of the WTRU when the quality of neighboring cells is a better offset for a duration known as the Trigger Time To Time (TTT). In 3GPP TS 38.300, different events called A1, A2, A3, A4, A5, etc., are defined for UE measurement reporting triggers. The TTT and cell-specific offset can be specified during the measurement configuration step. If a handover (HO) decision is made based on the measurement report, the source gNB can issue a handover request to the target gNB. If the UE is granted permission by the target gNB, the target gNB can send a handover request confirmation (e.g., containing an RRC message to be sent to the UE) to the source gNB. Next, the source gNB initiates the handover and sends an RRC reconfiguration message to the UE. The source gNB may also include a dedicated set of RACH resources. Afterward, the UE can synchronize to the target cell and complete the RRC handover procedure. Figure 2 The entire HO process is shown in the diagram.

[0071] For example, the HO procedure may fail due to poor channel quality of the target gNB, source gNB, or both. In scenarios with directional links, the handover problem can worsen because the link quality of the target and source gNBs can deteriorate rapidly due to mobile congestion or UE rotation. First, congestion of the target gNB during the handover procedure can lead to a handover failure (HOF). When the UE receives an RRC reconfiguration message, the handover failure timer T304 starts. If the T304 timer expires before the handover is complete, an HOF is declared, and the UE can (e.g., must) perform a connection rebuild, as described in 3GPP TS 38.331. Second, after a sudden UE rotation or congestion, the source gNB may not be able to initiate the handover procedure in a timely manner based on the most recent measurement reports. Even measurement reports from the UE may be lost due to poor link quality. Therefore, without handover assistance from the source gNB, even if a potential target gNB with good channel quality exists, the UE may need to wait for the source gNB to recover from the interruption or declare an RLF.

[0072] Dual Active Protocol Stack (DAPS) Switching As a potential solution to a blocked target gNB, Dual Active Protocol Stack (DAPS) handover is specified in 3GPP 38.300 Rel-16. During DAPS handover, the UE does not advertise a source cell connection until random access to the target gNB is complete. If the target gNB link deteriorates before random access is complete, the UE can fall back to the source gNB.

[0073] Conditional toggle (CHO) Figure 3 This is a flowchart illustrating an example procedure for conditional handover within the NR RAN. To address source gNB congestion, Conditional Handover (CHO) is specified in 3GPP 38.331 Rel-16. In a CHO, the UE can be configured to perform a handover when one or more handover execution conditions are met. The source gNB can actively configure the UE to evaluate the CHO execution conditions defined for candidate gNBs. Once the conditions are met (e.g., when the target gNB is offset better than the source gNB), the UE can initiate a handover to the target gNB without signaling from the source gNB. Therefore, even if the source gNB is interrupted due to sudden congestion or rotation, the UE can still successfully complete the handover to the target gNB if the CHO execution conditions are met. The entire CHO procedure is described in... Figure 3 As shown in the image.

[0074] While CHO (Call On Hitch) is resilient to mobile congestion and can significantly reduce the number of RLFs (Recurrent Link Failures) originating from rapidly deteriorating links, its success depends on the availability of candidate gNBs before the source link fails, the link quality of the target link, and a conditional threshold for the target gNB. Even if candidate gNBs exist, the UE needs to maintain link quality with the selected candidate gNB until handover is complete. Furthermore, the conditional threshold for handover execution may need to be carefully configured. A high threshold may prevent the UE from performing a timely handover to the target gNB, resulting in handover failure. On the other hand, a low threshold may lead to a suboptimal selection of a new serving gNB and, in some cases, potentially useless handover.

[0075] Rel-16 Multi-TRP Operation and Rel-17 Inter-cell Beam Management The multi-TRP transport mechanisms standardized in 3GPP Rel-16 are limited to intra-cell scenarios. These multi-TRP transport mechanisms are specified to support noncoherent joint transport (NCJT), which can improve downlink data rates and spectral efficiency, for example, for users at the cell edge. Considering the various backhaul capabilities in real-world deployments (e.g., ideal backhaul, non-ideal backhaul), two different NCJT-based transport schemes are supported: one based on single downlink control information (DCI) and the other based on multiple DCIs. Figure 4The left figure in the diagram is a system diagram illustrating an example of an NCJT-based transmission with a single DCI. Figure 4 The right figure in the diagram is a system diagram illustrating an example of an NCJT-based transmission with multiple DCIs.

[0076] For example, a Rel-16 single DCI-based transmission scheme might be more suitable for ideal backhaul between TRPs because a single DCI can schedule resources from two TRPs. To receive DL data from different TRPs, the UE can be provided with two TCI states, each corresponding to a TRP, and Quasi-Co-location (QCL) information provided to the corresponding PDSCH layer. Different TCI code points can be activated by the MAC layer, as described in 3GPP 38.321. The DCI scheduling indicates one of the active TCI code points with two TCI states.

[0077] For example, a Rel-16 multi-DCI-based transport scheme can support scenarios with non-ideal backhaul, where each TRP uses its own DCI to schedule its resources. In an RRC configuration, two TRPs can be implicitly represented by two distinct control resource sets (CORESET). Each of these can be identified by the value of the RRC parameter "CORESETPoolIndex".

[0078] The 3GPP standard Inter-Cell Beam Management (ICBM) in Rel-17 extends multi-TRP operation to the inter-cell scenario. It allows defining TCI states from Synchronization Signal Blocks (SSBs) associated with a Physical Cell Identifier (PCI) different from the cell to which the UE RRC_Connected. This enables inter-cell multi-TRP operation through the appropriate configuration and activation of the TCI states associated with any of the PCIs.

[0079] Following the standardization of intra-cell multi-TRP operations in Rel-16 and inter-cell multi-TRP operations in Rel-17, L1 / L2 triggered mobility (LTM) is part of the ongoing 3GPP Rel-18 work.

[0080] For example, in networks employing higher carrier frequencies, narrow beam transmission may occur, requiring very dense deployment. Traditional mobility frameworks based on higher-layer measurement, cell measurement, reporting, cell change, and / or update decisions and execution can involve very high overhead and result in delays far exceeding the timescale of mobility events with narrow beams.

[0081] In some examples, LTM is one of the promising areas for minimizing mobility disruption. Significant reductions in mobility disruption are possible, for example, by combining radio-based and non-radio-based measurements, which leads to more deterministic mobility handling. In some other examples, reductions in mobility disruption can be achieved by minimizing the latency associated with the transmission of measurement reports, decisions, and / or mobility commands.

[0082] For example, some embodiments can implement L1 / L2 mobility characteristics, such as a set of measurements and events on a combination of radio and / or non-radio measurements. For example, a WTRU can be configured to perform LTM procedures based on a combination of radio and non-radio measurements.

[0083] Representative LTM procedures based on joint radio and non-radio signals (location and orientation) without network deployment information In some representative embodiments, the WTRU may be provided with area-determined configurations, but not with network deployment information. In one example, the WTRU uses non-radio signals (particularly location and orientation information) combined with 3GPP radio measurements to trigger a report to the lower layers of the network. This report informs the network of the appropriate cell and beam for the WTRU, for which the cell issues a cell-switching command to the WTRU.

[0084] In one embodiment, the WTRU may be configured with new or updated WTRU capabilities, such as WTRU capability transfer and associated ancillary information for low-level mobility / LTM handling, to support LTM procedures based on radio and / or non-radio measurements.

[0085] In one embodiment, the WTRU may receive configuration to determine area information and orientation-specific parameters and references (e.g., reference TRP selection).

[0086] In one embodiment, the WTRU can receive LTM configuration along with appropriate LTM radio and non-radio measurements and suitable events for setting up reporting purposes on a combination of configured measurements. In this embodiment, non-radio measurements and events concerning area entry (e.g., LTM-CM2) and orientation matching a given TRP (e.g., LTM-OT1) are combined with radio signal measurements. The network can be configured with events capturing radio and non-radio measurements. The network configuration can indicate joint events, such as LTM-J1, LTM-J2, ... LTM-J5. In one example, the network can be configured with a set of separate events, such as LTM-CM2O1 for non-radio measurements and LTM-A3 / LTM-A4 for radio measurements. This configuration can indicate that triggering these events will trigger a WTRU report.

[0087] In one embodiment, the WTRU can perform configured radio and non-radio measurements at its location and orientation based on configured periodicity.

[0088] In one embodiment, the WTRU can detect changes in non-radio or radio measurements.

[0089] In one embodiment, the WTRU can determine its zone using non-radio measurements.

[0090] In one embodiment, the WTRU can evaluate configured events based on conditions set in terms of location and orientation.

[0091] In one embodiment, the WTRU can perform event-based reporting. When the WTRU enters a specific area and has an event triggering that matches the orientation of a given TRP according to its configuration, the WTRU report may include sending / reporting its area information, location / position, and configured radio measurements according to its configuration.

[0092] In one embodiment, the WTRU can receive network commands to perform LTM mobility switching, where the network can use WTRU reports and other system-level aspects to determine the appropriate target cell / beam configuration for the WTRU.

[0093] In one embodiment, the WTRU may perform LTM mobility switching in accordance with one or more network commands or instructions.

[0094] In one embodiment, the WTRU can perform protocol stack disposal based on network indications in dynamic signaling or as part of the LTM configuration.

[0095] In one embodiment, the WTRU can transmit uplink (UL) indications according to network configuration / instructions, wherein the network can indicate the transmission of indications based on reference signals (RS) or UL controls (e.g., PUCCH) via LTM exchange commands or prior configuration.

[0096] LTM based on radio and non-radio measurements, with WTRU autonomous activation based on area-determined measurement configuration determined by WTRU. In some representative embodiments, the WTRU may be provided with a zone-determining configuration, but not with network deployment information. In this case, the WTRU uses its location information based on the network configuration to determine its zone. As part of the LTM procedure, the network configures the WTRU with appropriate LTM candidates. To reduce the measurement and tracking overhead associated with tracking / synchronizing with LTM candidates, LTM measurements are mapped to relevant zones. Therefore, these measurements only need to be estimated and reported when the WTRU determines that it is in these zones. This provides a selection mechanism for the WTRU to activate the appropriate set of measurement configurations. Thus, upon entering a specific location / zone, the WTRU can activate the relevant measurement configuration. This activation causes the WTRU to track radio and non-radio measurements that are part of these active measurement configurations. These measurements can then cause the WTRU to report to the network based on reporting and triggering of these measurements.

[0097] In some representative examples, the WTRU can perform WTRU capability transfer and related ancillary information for low-level mobility and / or LTM disposal based on radio and non-radio measurements to support LTM procedures.

[0098] In some representative examples, the WTRU can receive configuration and appropriate parameters (e.g., from the network) to determine zone information.

[0099] In some representative examples, the WTRU can receive LTM configurations for candidate cells.

[0100] In some representative examples, the WTRU can receive LTM-related measurement configurations. These configurations include, for example, definitions and parameters for radio and non-radio measurements associated with LTM candidate configurations. Furthermore, the measurement configurations provide association information with certain zones in which these measurement configurations are activated and require estimation / monitoring / tracking. This measurement may be part of the `measConfig` in `RRCreconfiguration` or through a new information element (IE) for the LTM program (e.g., specifically designed for LTM programs). The association of a measurement configuration with a zone can be achieved by explicitly providing a set of zone identifiers where the measurement configuration is activated, or this information may be provided in a different information element.

[0101] In some representative examples, the WTRU can perform configured non-radio measurements at its location based on the configured periodicity.

[0102] In some representative examples, the WTRU can detect changes in non-radio or radio measurements.

[0103] In some representative examples, the WTRU can determine its zone using non-radio measurements.

[0104] In some representative examples, when the WTRU's zone changes, the WTRU can activate a measurement configuration that is configured to be active in the new zone. In other cases, the WTRU can deactivate a measurement configuration that is not configured to be active in the new zone.

[0105] In some representative examples, WTRU can estimate radio and non-radio measurements associated with an active measurement configuration.

[0106] In some representative examples, the WTRU can use conditions set on radio and non-radio quantity measurements to evaluate configured radio and non-radio events.

[0107] In some representative examples, the WTRU can perform event-based WTRU reporting on its area information, location / position, and radio measurements, depending on the configuration (e.g., in the case of an event).

[0108] In some representative examples, the WTRU can receive network commands to perform LTM mobility switching, where the network can use WTRU reports and other system-level aspects to determine the appropriate target cell / beam configuration for the WTRU.

[0109] In some representative examples, the WTRU can perform LTM mobility switching based on network commands or instructions.

[0110] In some representative examples, the WTRU can perform protocol stack disposal based on network indications in dynamic signaling or as part of the LTM configuration.

[0111] In some representative examples, the WTRU can transmit UL indications based on network configuration / instructions, where the network can indicate the transmission of indications based on reference signals (RS) or UL controls (e.g., PUCCH) via LTM exchange commands or prior configuration.

[0112] LTM based on joint events of radio and non-radio signals and network deployment information In some representative embodiments, the WTRU may (e.g., to the network) indicate its ability to support low-level mobility and / or LTM procedures, as well as its ability to provide relevant ancillary information (e.g., the ability to receive and / or use relevant ancillary information) to support LTM procedures based on joint radio and non-radio measurements.

[0113] In some representative embodiments, the WTRU may receive information indicating coverage and / or deployment topology. For example, the WTRU may receive one or more relevant configurations and / or indications from the network (e.g., related to area determination).

[0114] In some representative embodiments, the WTRU may receive information indicating one or more LTM configurations, as well as appropriate LTM radio and / or non-radio measurements and appropriate joint events (e.g., for reporting purposes) set by a combination of radio and non-radio measurements. The network may instruct any one of the proposed joint events (e.g., one or more of LTM-J1 to LTM-J6) as part of one or more LTM configurations.

[0115] In some representative embodiments, the WTRU may perform one or more (e.g., configured) radio and / or non-radio measurements based on one or more LTM configurations received from the network.

[0116] In some representative embodiments, the WTRU can detect changes in one or more non-radio and radio measurements.

[0117] In some representative embodiments, the WTRU can determine its area using non-radio measurements.

[0118] In some representative embodiments, the WTRU can evaluate configured joint events by measuring conditions of both radio and non-radio signals.

[0119] In some representative embodiments, the WTRU can perform event-based WTRU reporting on its area information, location / position, and radio measurements, depending on its configuration (e.g., in the case of an event trigger).

[0120] In some representative embodiments, the WTRU can receive network commands or instructions to perform LTM mobility switching, and the network can use WTRU reports of radio and non-radio measurements and other system-level aspects to determine the appropriate target cell / beam configuration for the WTRU.

[0121] In some representative embodiments, the WTRU can perform LTM mobility switching according to network commands or instructions.

[0122] In some representative embodiments, the WTRU can perform protocol stack processing based on network indications in dynamic signaling or as part of the LTM configuration.

[0123] In some representative embodiments, the WTRU can transmit UL indications according to network configuration / instructions, wherein the network can transmit indications based on reference signals (RS) or UL controls (e.g., PUCCH) via LTM exchange commands or via prior configuration (e.g., to the WTRU).

[0124] LTM based on potential target configuration candidates reported by WTRU In some representative embodiments, a network-controlled LTM switching procedure is provided. In some examples, the WTRU can perform radio and non-radio measurements and can assist LTM switching by providing the network with indications of one or more appropriate LTM target configurations. The selection of appropriate LTM target configurations is performed by the WTRU, for example, by tracking, measuring, and / or evaluating radio and non-radio quantities according to network configurations or indications.

[0125] In some representative embodiments, the WTRU may (e.g., to the network) indicate its ability to support low-level mobility and / or LTM procedures, as well as its ability to provide relevant ancillary information (e.g., the ability to receive and / or use relevant ancillary information) to support LTM procedures based on joint radio and non-radio measurements.

[0126] In some representative embodiments, the WTRU may receive information indicating coverage and / or deployment topology. For example, the WTRU may receive one or more relevant configurations and / or indications from the network (e.g., related to area determination).

[0127] In some representative embodiments, the WTRU may receive information indicating one or more LTM configurations, as well as suitable LTM radio and / or non-radio measurements and suitable joint events (e.g., for configuration selection purposes) through a combination of radio and non-radio measurements. The network may indicate any of the proposed joint events (e.g., one or more of LTM-J1 to LTM-J6) as part of a configuration with suitable parameters and thresholds for selecting candidate configurations.

[0128] In some representative embodiments, the WTRU may perform one or more (e.g., configured) radio and / or non-radio measurements based on one or more LTM configurations received from the network.

[0129] In some representative embodiments, the WTRU can detect changes in one or more non-radio and radio measurements.

[0130] In some representative embodiments, the WTRU can determine its area using non-radio measurements.

[0131] In some representative embodiments, the WTRU can evaluate the joint events of the configuration using conditions set for the radio and non-radio signal measurement settings of one or more active LTM configuration candidates.

[0132] In some representative embodiments, if one or more events associated with a configuration selection are triggered for at least one of the active configuration candidates, the WTRU can select at least one associated configuration candidate for network reporting. The WTRU can, for example, transmit the UL indication of the selected configuration candidate to the network.

[0133] In some representative embodiments, the WTRU may receive network commands or instructions to perform LTM mobility switching. In one example, a network instruction may instruct the WTRU to perform LTM mobility switching to a target candidate, and the indicated target candidate may (or may not) be the same as the target candidate selected by the WTRU (e.g., a configuration candidate selected by the WTRU).

[0134] In some representative embodiments, the WTRU can perform protocol stack processing based on network indications in dynamic signaling or as part of the LTM configuration.

[0135] In some representative embodiments, the WTRU can transmit UL indications according to network configuration or instructions, and the network can transmit indications based on reference signals (RS) or UL controls (e.g., PUCCH) via LTM exchange commands or via prior configuration (e.g., to the WTRU).

[0136] In some representative examples, when more than one candidate configuration triggers a selection event, the WTRU can select the highest priority configuration for indicating the UL to the network, and the priority indication can be part of the LTM candidate configuration.

[0137] In some representative examples, when more than one candidate configuration triggers a selection event, the WTRU can select a candidate configuration from its current distributed unit (DU), and the DU information can be provided as part of the candidate configuration for the LTM configuration.

[0138] In some representative examples, where a selection event is triggered by more than one candidate configuration, the WTRU can provide a set of successful candidates (e.g., a number of "N") as part of the UL indication. For example, the network configuration includes or indicates a number of successful candidates of "N".

[0139] LTM based on WTRU transmitting UL indication on (one or more) target configuration candidates In some representative embodiments, examples of network-controlled LTM switching procedures are provided. For example, the WTRU can perform radio and non-radio measurements and can assist LTM switching by providing indications of a suitable LTM target configuration (e.g., to the network). The selection of a suitable LTM target configuration can be performed by the WTRU by tracking, measuring, and / or evaluating radio and non-radio signals according to the network configuration. In some examples, the WTRU is configured with transmission parameters for candidate configurations such that indications associated with a selected candidate are transmitted over the resources of that selected candidate. Signaling to the selected candidate can be a RACH, a thin RACH preamble, and / or a specific RS (e.g., an SRS). Related QCL parameters can be provided to the WTRU for indication transmission on the configured resource(s).

[0140] In some representative embodiments, the WTRU may (e.g., to the network) indicate its ability to support low-level mobility and / or LTM procedures, as well as its ability to provide relevant ancillary information (e.g., the ability to receive and / or use relevant ancillary information) to support LTM procedures based on joint radio and non-radio measurements.

[0141] In some representative embodiments, the WTRU may receive information indicating coverage and / or deployment topology. For example, the WTRU may receive one or more relevant configurations and / or indications from the network.

[0142] In some representative embodiments, the WTRU may receive information indicating one or more LTM configurations, along with suitable LTM radio and / or non-radio measurements and suitable joint events (e.g., for configuration selection purposes) through a combination of radio and non-radio measurements. The network may indicate any of the proposed joint events (e.g., one or more of LTM-J1 to LTM-J6) as part of its selected configuration. In some examples, each corresponding candidate configuration provides UL indication resources and signaling parameters, through which the WTRU may provide UL indication when selecting a candidate configuration.

[0143] In some representative embodiments, the WTRU may perform one or more (e.g., configured) radio and / or non-radio measurements based on one or more LTM configurations received from the network.

[0144] In some representative embodiments, the WTRU can detect changes in one or more non-radio and radio measurements.

[0145] In some representative embodiments, the WTRU can determine its area using non-radio measurements.

[0146] In some representative embodiments, the WTRU can evaluate the joint events of the configuration using conditions set for the radio and non-radio signal measurement settings of one or more active LTM configuration candidates.

[0147] In some representative embodiments, if one or more events associated with configuration selection are triggered for at least one of the active configuration candidates, the WTRU can select at least one associated configuration candidate. The WTRU can then select a UL indication resource associated with the selected candidate configuration. The WTRU can use signaling parameters associated with the selected candidate configuration to transmit the UL indication on the selected resource (e.g., to the network).

[0148] In some representative embodiments, the WTRU may receive network commands or instructions (e.g., from the serving cell) to perform LTM mobility switching. In one example, the network instruction may instruct the WTRU to perform LTM mobility switching to a target candidate, and the indicated target candidate may (or may not) be the same as the target candidate selected by the WTRU (e.g., the configuration candidate selected by the WTRU).

[0149] In some representative embodiments, the WTRU can perform LTM mobility switching on a target indicated by the network based on a received network command or instruction.

[0150] In some representative embodiments, the WTRU may perform protocol stack processing based on network instructions (e.g., indicated in dynamic signaling or a portion of the LTM configuration).

[0151] In some representative embodiments, the WTRU can transmit UL indications according to network configuration or instructions, and the network can transmit indications based on reference signals (RS) or UL controls (e.g., PUCCH) via LTM exchange commands or via prior configuration (e.g., to the WTRU).

[0152] In some representative examples, when more than one candidate configuration triggers a selection event, the WTRU can select the highest priority configuration for indicating the UL to the network, and the priority indication can be part of the LTM candidate configuration.

[0153] In some representative examples, when more than one candidate configuration triggers a selection event, the WTRU can select a candidate configuration from its current distributed unit (DU), and the DU information can be provided as part of the candidate configuration for the LTM configuration.

[0154] A solution based on combined radio and non-radio measurements for minimizing mobility disruption. The evolution of wireless systems with new applications requiring low latency, high reliability, and / or high availability has led to a greater focus and activity on service continuity while experiencing mobility and / or minimizing service disruptions caused by mobility. To this end, 3GPP has defined and standardized several mechanisms that can minimize mobility disruptions through faster handover of beams, cells, and network nodes.

[0155] In some representative embodiments, the WTRU may use a combination of radio and non-radio measurements to implement and / or control lower-layer (e.g., L1 / L2) triggered mobility to improve mobility procedures (e.g., deterministic mobility). In some examples, the enhanced mobility procedures include a combination of any of the following: (i) knowledge of the network deployment of its nodes / cells / beams, (ii) the WTRU’s ability to perform non-radio measurements in different forms (e.g., tracking their movement and / or determining updated geographic locations / locations and orientations), (iii) a combination of the previously described non-radio measurements with measurements performed via radio signals, (iv) a lower-latency measurement framework for event assessment and measurement reporting, and / or (v) rapid execution of lower-layer triggered mobility procedures on such a framework.

[0156] For example, in some cellular networks (e.g., public cellular networks), operators may be reluctant to fully share deployment configurations with equipment because this could pose a certain level of risk to their installations. One aspect relevant to controlled environments and factory settings (e.g., warehouses) is the fact that communication equipment (e.g., robots, industrial machines, etc.) is also installed and operated by the same owner. This provides confidence that the network topology configuration will not be used for purposes other than those shared with the equipment. To enable broader use of the proposed strategy while still maintaining precise information security, deployment topologies are provided in different forms, where appropriate indications of the cells / beams of interest within the area are provided. The proposed LTM strategy based on joint radio and non-radio measurements can be broadly divided into two main phases. In some examples, the first phase is the LTM preparation phase based on joint radio and non-radio measurements. The preparation phase includes configuration and WTRU capability transfer to support one or more LTM procedures. The second phase is the execution phase, which will be discussed in detail below.

[0157] In some representative embodiments, the ability of the WTRU to quickly detect its location / orientation and geographic coordinates can be used to select the appropriate node / cell / beam to which the WTRU should connect. The network can share an appropriate limited portion of its deployment / coverage topology with the WTRU, which uses this appropriate limited portion to report its precise instantaneous coverage coordinates to the network. This document provides details regarding coverage topology content, configuration, maintenance, signaling mechanisms, and WTRU post-processing.

[0158] Various embodiments relate to L1 / L2 triggered mobility (LTM) procedures, and the design and update procedures for such LTM configurations are provided below. Furthermore, the WTRU capabilities and auxiliary information that the WTRU will provide to the network prior to configuring for LTM are discussed.

[0159] In some representative embodiments, non-radio measurements can be used and / or combined with radio measurements in the LTM procedure. This document describes various embodiments of a measurement framework that combines radio and non-radio measurements. For example, the WTRU can integrate (e.g., combine) measurements on 3GPP radio signals, non-3GPP radio signals, data from local sensors, and other interfaces. To reduce latency and achieve stable measurements, different measurement models are proposed, which can select measurements from L1, L3, or combinations thereof. This document describes various embodiments of a framework for LTM measurements, including measurement modeling, configuration, quantities, and / or event definitions. Various embodiments provide events whose triggering conditions are a combination of radio and non-radio measurements to achieve, for example, zero-disruption mobility.

[0160] In some representative embodiments, if the LTM procedure is run solely based on radio measurements, a ping-pong effect may occur due to noise and fading affecting the quality of radio signal estimation, where the WTRU may be exchanged back and forth between cell groups. Combining non-radio measurements and radio measurements helps to avoid this ping-pong situation.

[0161] In some representative embodiments, the LTM switching procedure may be referred to as network control. For example, the network explicitly issues a command instructing the WTRU to switch from its serving cell to a target cell. In this example, the network instructs the LTM cell switching command and provides information (to the WTRU) indicating how to handle data and the control plane when switching cells using the LTM procedure. Several indication mechanisms are provided, through which the network can configure the WTRU to provide indications about the target cell after the LTM cell switching.

[0162] In some representative embodiments, the LTM cell switching procedure may include one or all of a combination of preparation and execution steps (e.g., assistance, configuration, measurement, WTRU reporting, network commands, and WTRU indications).

[0163] Various embodiments use the terms low-layer triggered mobility or L1 / L2 triggered mobility (LTM) for certain representative procedures, where cell switching triggers, commands, and acknowledgments are exchanged primarily at the lower layers of (one or more) WTRUs and the network, in contrast to conventional mobility procedures that operate via RRC signaling or Layer 3. These lower layers are the PHY layer or the MAC layer (or a combination of both), which will be detailed in the embodiments.

[0164] LTM Preparation Based on Combined Radio and Non-Radio Measurements In some representative embodiments, the preparation phase of an LTM procedure based on joint radio and non-radio measurements may refer to and / or include procedures related to the configuration of the deployment topology, LTM cell configuration, measurement configuration, and signaling the network's WTRU capability to support the LTM procedure.

[0165] Deployment and Coverage Area Typically, cellular networks are planned networks in which operators deploy network nodes in appropriate locations to provide sufficient coverage for their subscribers. Network operators should be expected to have (e.g., very precise) knowledge about their cell deployments, as well as knowledge about the beams within those cells regarding coverage attributes such as the location of the cell and / or transmission point (TRP) (e.g., a reference location), the potential spatial direction of transmission (e.g., defined by the azimuth, elevation, and location coordinates of the TRP), and beamwidth information (e.g., three-dimensional beamwidth information, horizontal and vertical direction information, transmission range information, and / or coverage shape information, such as the location coordinates of points constituting the coverage boundaries of the beam, cell, and / or TRP).

[0166] Deployment Topology In some representative embodiments, the deployment topology may include information indicating the location, beam coverage, and / or beam orientation of the TRP. For example, the location of the TRP can be represented using 2D coordinates (e.g., latitude and longitude coordinates). Alternatively, the location can be represented using 3D coordinates (e.g., adding altitude or height to 2D coordinates). Furthermore, 2D and / or 3D location representations can be in global and / or local coordinate systems.

[0167] In some representative embodiments, azimuth and elevation angles can be used to represent beams from a given TRP. For example, suitable references (such as a base direction and zenith) can be used, or a reference direction can be provided as part of the configuration. These angles can be appropriately refined and / or quantized to meaningfully capture mobility procedures and signal strength within or outside the coverage of a given beam. In addition to angles, beamwidths in these directions can be (e.g., additionally) explicitly provided for the beams. Using TRP location parameters and / or beam angles (e.g., plus width), the UE can prepare a local topology, where it can determine (e.g., view) the coverage of different beams from different TRPs. In some embodiments, additional attributes such as range and / or power can be added to the cell and / or beam information to further refine the deployment topology.

[0168] Coverage Topology In some representative embodiments, the coverage topology may include information indicating geographic coverage from different TRPs (e.g., different beams). For example, the coverage topology may provide coverage boundaries for different TRPs and / or different beams. The coverage topology may incorporate and / or indicate the properties of terrain, topography, buildings, and other geographic parameters on the deployment topology to prepare appropriate areas and boundaries associated with coverage for different TRPs and / or different beams.

[0169] In some representative embodiments, the coverage topology may include information indicating (e.g., provided in a suitable form) the geometry. To indicate the shape defining cell and / or beam-level coverage, different reference shapes may be defined (e.g., predefined). Reference shapes may include (e.g., in the form of) any of a circle, oval, elliptical, and / or ellipsoidal shape or other geometry, for example, with suitable parameterization. For example, these shapes with appropriate properties may be used to indicate the coverage topology. These properties may be associated with (e.g., links to) cell and / or beam identifiers associated with a given shape and / or area.

[0170] Configuration As used herein, the terms deployment topology and coverage topology may be used synonymously (e.g., unless otherwise distinguished).

[0171] In some representative embodiments, coverage topology can be associated with a region, which may be referred to as a coverage topology region. For example, a coverage topology region may correspond to any one of one or more cells, RAN notification regions (RNAs), tracking regions (TAs), and / or PLMNs.

[0172] For example, each coverage topology can be defined at a different granularity. The granularity of the coverage topology can be part of the coverage topology configuration. In one example, the coverage topology can be defined at the cell level. Geographic coverage information from different gNBs and / or TRPs can be indicated to the UE using appropriate signaling. For example, cell-level coverage can be useful for different handover and cell change procedures.

[0173] For example, coverage topology granularity can be represented in the form of coverage areas (e.g., reflected). For cell-level procedures, one or more coverage topology areas can have (e.g., given) cell-level granularity. For beam-level procedures, where, for example, a UE may need to track, maintain, and / or switch beams, coverage topology granularity can be defined, for example, at the beam level (e.g., differently). Areas in the coverage topology can be associated with different beams (e.g., attributed to different beams).

[0174] For example, one or more zones can be attributed to one or more (e.g., given) beams from one or more (e.g., given) TRPs. Granularity (e.g., further refinement) can be achieved by defining zones from any (e.g., each) gNB and / or TRP and associating zones with different directions. Zones in the coverage topology can indicate geographical areas corresponding to a given set of reference signals. For beam-level zones, in one design, each zone can indicate the coverage area of ​​an SSB beam. In another beam-level zone design, each zone can indicate the coverage area of ​​an SSB beam or a CSI-RS beam, where the SSB / CSI-RS beam is the coverage of the corresponding SSB / CSI-RS signal. This configuration can specify one-to-one or one-to-many correspondences, where one-to-many correspondences may exist when the zone demarcation criterion is not SSB but some other signal or GPS coordinates. One-to-many correspondences may also exist for overlapping networks where multiple cells / beams may serve overlapping areas.

[0175] For example, any (e.g., each) area can be identified by an identifier, which may be provided as part of the configuration. For example, any (e.g., each) area identifier can be any (e.g., a deterministic combination) of the identifiers of the cell, TRP, SSB, and / or CSI-RS beam to which it belongs. In some representative embodiments, one or more formulas for calculating the area identifier may be known a priori to the network and / or devices. The network and / or devices may use (e.g., additional) modulation parameters (e.g., the length, width, number, etc. of the SSB beams), which may be part of system information or configuration.

[0176] For example, different granularities of a zone can be at the gNB, TRP, and / or cell level. For a cell-level zone, a zone can indicate an area where the cell has sufficient coverage. Sufficient coverage can be specified based on existing cell selection and reselection criteria, and / or new criteria associated with a suitable reference signal can be specified. For example, a cell-level zone can group any (e.g., all) SSB and / or CSI-RS zones associated with a given cell. A cell-level zone can represent an area where any SSB and / or CSI-RS signal from the cell can be received at known and / or configured quality. For coverage areas based on RNA, TA, and / or PLMN, the zone representation can be extended to (e.g., larger) granularity. A cell-level zone identifier can be a cell identifier. A cell-level zone identifier can be a (e.g., deterministic) modification of a cell identifier by combining it with one or more other parameters. For example, the same design can be used to represent zones representing coverage of RNA, TA, and / or PLMN, etc.

[0177] In some representative embodiments, longitude and latitude values ​​can be used to define a region for any (e.g., each) location. For example, region size (e.g., length) information can be provided as part of the configuration. One or more formulas for calculating the region can be predefined and / or can be signaled as part of the configuration (e.g., based on a predefined set). For example, the UE can calculate the region identifier according to the 3GPP NR Sidelink work standard in Release 16. For example, longitude and latitude values ​​can be geodesic distances from geographic coordinates (0, 0), as used in the NR sidelink framework. Suitable parameters can be provided as part of the configuration to select region modularity along the longitude and latitude directions. A single parameter (e.g., only one) can be used to select the same modularity along the longitude and latitude directions. For example, this parameter can be a fixed value to simplify configuration (e.g., reduce configuration overhead signaling). In some representative embodiments, all devices can calculate their regions as well as the region of any location relative to the longitude and latitude coordinates of that location.

[0178] Network deployment configuration In some representative embodiments, the deployment topology includes information about TRP locations and beam coverage / orientation. For example, the location of one or more TRPs can be represented using 2D coordinates (e.g., latitude and longitude coordinates). Alternatively, the location can be represented using 3D coordinates (such as adding elevation and / or altitude to 2D coordinates). The 2D and / or 3D representations can reference a global or local coordinate system. Area configuration follows a sidelink design, and TRP locations can be provided for the area (e.g., instead of latitude and longitude coordinates).

[0179] For example, azimuth and elevation angles can be used to represent one or more beams from a given TRP. Suitable references (such as a base direction and zenith) can be used, or reference directions can be provided as part of the configuration. These angles can be appropriately refined and / or quantized to meaningfully capture mobility patterns and signal strength within or outside the coverage of a given beam. For example, (e.g., in addition to angles) beamwidths in these directions can be provided, for example, explicitly for the beam.

[0180] Network coverage configuration In some representative embodiments, the network can provide coverage configurations in a (e.g., directly) rich form, capturing any (e.g., all) specific aspects of the local terrain, such as shading from buildings and / or other objects. For example, the network can not only know precisely the deployment of its cells, TRPs, and / or beams, but also access terrain data using navigation systems, cameras, and / or ongoing measurements of cells and / or beams from devices. This allows the network (e.g., advantageously) to have very accurate coverage topology information. For example, cell and / or beam switching can be used to update and / or refine the coverage topology using historical data in the form of network measurements. Disadvantageously, this approach can have large signaling overhead. For example, the amount of information that may need to be exchanged can be enormous, as even accurate coverage of a single beam may require transmitting a set of objects and their attributes to the UE. (e.g., large) signaling overhead may require several message exchanges at the RRC level, resulting in increased configuration latency.

[0181] In some representative embodiments, the area configuration can be designed for sidelinks. For example, the network may (e.g., will) provide different cell and / or beam coverage indications that provide the association between these cells and beams and the area.

[0182] Hybrid configuration In some representative embodiments, topology configuration can be a hybrid of the two methods described herein. For example, a portion of the configuration can be indicated in the form of a network deployment-based configuration, and a portion of the configuration can be indicated using an overlay topology-based configuration.

[0183] Initial configuration of deployment and coverage topology In some representative embodiments, the initial configuration of the coverage topology can be transmitted to the UE in the form of dedicated RRC signaling. For example, the initial coverage topology configuration can be provided to a UE with mobility and in an RRC active state. From the UE's perspective, the signaling can be dedicated, but the network can provide the same information to a group of UEs. These UEs may be adjacent to each other. Therefore, the same coverage topology may be associated with them.

[0184] In some representative embodiments, the network (e.g., a base station) may broadcast coverage topology information. A coverage topology system information block (SIB) may be specified (e.g., a new one). It should be understood that the coverage topology information broadcast by a cell and / or TRP can be configured to reflect the local deployment environment of the cell or TRP broadcasting the coverage topology.

[0185] In some representative embodiments, the initial configuration may provide a coarse coverage topology, which may need to be refined. Refinement of the initial coverage topology to an appropriate granularity and coverage extension (e.g., to full usefulness) can be performed. For example, the coverage topology can be refined (e.g., appropriately) via dedicated signaling. Refinement can be network-initiated, for example, when configuring certain applications and / or flows with QoS constraints (e.g., requiring active mobility). For example, a UE can request (e.g., initiate) the refinement of the coverage topology.

[0186] WTRU processing for achieving efficient coverage topology In some representative embodiments, following the configuration solutions described herein, a network deployment topology can be shared with multiple UEs. For example, additional attributes can be added to cell configurations. For example, configurations with geographical attributes (e.g., new ones) can be added, and TRP and / or beam-level configurations can be linked to legacy cell configurations. For the effective selection of mobility events and beams, cells, and / or TRPs, the UE can be configured (e.g., receive) with a detailed effective coverage topology, which may be referred to as a terrestrial coverage topology. For example, the deployment topology may need to be rich enough (e.g., detailed) to capture all terrain and occlusion aspects. For example, the coverage topology can (e.g., should) consider not only TRP locations and beam attributes, but can (e.g., should also) incorporate the physical properties of the surrounding environment, including details of the terrain, buildings, and their physical properties that may obstruct, block, and / or reflect beams. In some representative embodiments, the UE can acquire and / or construct a terrestrial coverage topology.

[0187] UE processing via the coverage topology provided by the network In some representative embodiments, the deployment configuration provided by the network can be detailed (e.g., very rich) and refined, and provided in a rich array of shapes that can capture any (e.g., all) specific aspects of the local terrain, shading from buildings and / or other objects. Different reference shapes can be defined to indicate the shape defining cell and / or beam-level coverage. For example, reference shapes can be circular, oval, elliptical, ellipsoidal, or other geometries, for example, with appropriate parameterization. The network can indicate these shapes with appropriate attributes and provide links (e.g., associations) to them with cell and / or beam identifiers. One advantage of doing so is that the network can know precisely the deployment details of its cells, TRPs, and / or beams. For example, terrain data can be accessed using any of a navigation system, camera, and / or ongoing measurements of cells and / or beams from the device, allowing it to know a very precise coverage topology. An additional advantage is the use of historical data (e.g., all) in the form of network measurements, cell and / or beam conversions, which can be used to update and refine the detailed coverage topology. A disadvantage is that it can generate significant signaling overhead. For example, the amount of information that may need to be exchanged could be enormous, because (e.g., even) precise coverage of a single beam may require transmitting a set of objects and their attributes to the UE. Large signaling overhead may require several message exchanges at the RRC level, which could also lead to increased configuration latency.

[0188] UE processing via the deployment topology provided by the network In some representative embodiments, the network may provide the UE with a snapshot of the network node deployment and (e.g., limited) information about the beams transmitted from them. For example, the network may provide such information as part of the deployment configuration. For instance, the network may provide information about the TRP location, beam angle, and / or beam-specific parameters (e.g., modulating coverage without using characteristics of the local terrain). Since less information is required compared to methods where the network provides detailed coverage topology, signaling overhead and latency performance can be improved.

[0189] In some representative embodiments, the device may receive deployment characteristics and / or parameters of the TRP and / or beams, and may use local knowledge obtained through other technologies (e.g., locally stored terrain, positioning systems, cameras) to prepare a refined coverage topology, which adds terrain aspects to the deployment configuration. For example, after local processing and manufacturing, the UE may have an effective topology that defines different coverage areas associated with different beams and / or cells. The refined coverage topology can be used in the UE's beam and / or cell-level mobility procedures. Mobility and / or additional information obtained from other sensors can be utilized to refine the local physical coverage topology. When the device uses deployment parameters provided by the network combined with information from local sensors to prepare effective topology information, this requires the availability of local sensors, additional storage and / or computing power to prepare an effective topology by combining the network deployment topology with information from local sensors.

[0190] In some representative embodiments, the acquisition of refined coverage topology at a device can be standardized. For example, some devices may not be equipped with the necessary local sensors, or these devices may not have the necessary computing power to process and construct the topology themselves. The network can send refined topology to such devices. For example, devices with the necessary local sensors, computing, and / or storage capabilities may only receive limited deployment features from the network and prepare an effective topology locally. The manner in which the topology is received can depend on the UE's power consumption requirements, battery quality, remaining battery capacity, and / or as a function of active applications and their attributes.

[0191] Deployment and maintenance of coverage topology In some representative embodiments, based on the detection of changes in coverage topology areas, the UE can reacquire the coverage topology of its current location. For example, topology reacquisition can use dedicated RRC signaling. For example, topology reacquisition can use coverage topology SIB. For example, the UE can detect (e.g., determine) changes in coverage topology areas based on any of the following: 1) changes in serving cells and / or (re)selection of cells that do not belong to the current coverage topology area; 2) (re)selection of RNAs that do not belong to and / or do not correspond to the current coverage topology area; 3) execution of RNA update procedures and / or transmission of RNA update messages to the network (e.g., base station); 4) (re)selection of TAs that do not belong to and / or do not correspond to the current coverage topology area; 5) execution of TA update procedures and / or transmission of TA update messages to the network (e.g., core network); and / or 6) (re)selection of PLMNs that do not belong to the current coverage topology area and / or topologies that do not correspond to the current coverage topology area.

[0192] Deployment and coverage topology configuration release In some representative embodiments, the UE may discard topology configuration information, for example, when it becomes outdated. For instance, if the UE changes its coverage area and cannot obtain an updated coverage topology, an outdated indication may be issued. For example, the topology configuration may be associated with the use of one or more time intervals (e.g., explicit timers), which may cause the UE to reissue the configuration if it expires. For example, if the UE remains (e.g., stays) in an area associated with its current coverage topology, the time interval (e.g., the timer) may be refreshed. For example, the coverage topology area may be defined according to RNA, TA, PLMN, and / or other suitable criteria.

[0193] For example, the network can send (e.g., explicit) instructions to the UE to release its coverage topology configuration.

[0194] For example, after the UE transitions out of the RRC active state (e.g., after receiving the RRC Release message), the UE can (e.g., release the coverage topology configuration).

[0195] Network instructions for deployment and coverage topology In some representative embodiments, deployment and / or coverage topology can be provided to the UE (e.g., via a network). Cell and / or beam configurations and / or mobility configurations can be associated with the deployment and / or coverage topology.

[0196] Topology indication as part of cell / beam configuration In some representative embodiments, the topology (e.g., deployment) can be part of a cell configuration. For example, a cell configuration can be part of a conditional (re)configuration associated with a PSCell or SCell. A cell configuration can be part of a conditional switching or conditional PSCell change / addition procedure. The deployment topology can be associated with any serving cell configuration and can be used for any beam management procedure, such as beam switching or beam fault recovery. In some representative embodiments, new attributes can be added to (e.g., included in) a cell configuration that defines the TRPs being transmitted by the cell, the locations of these TRPs in a suitable global or local coordinate system, and / or the beam coverage attributes of the beams transmitted through these TRPs. The cell configuration can provide information about SSB beams and / or CSI-RS beams. Beam attributes can be in the form of azimuth and elevation angles with a suitable reference direction. The reference direction can be taken from a base direction and / or can be indicated as part of the configuration itself. The beam range can be indicated by attributes for each beam or can indicate a single value for unobstructed range (e.g., given transmit power). Beam attributes can (e.g., additionally) define beamwidth in the horizontal and / or vertical directions. For example, a simple deployment might specify a single beamwidth attribute for the horizontal direction and a single beamwidth attribute for the vertical direction, which can be assumed to be the same for any (e.g., all) configured beams. For example, in a deployment with varying beamwidth dimensions, the network might provide a single value for the TRP and incremental values ​​for each beam. For example, the network might provide beamwidth as part of the beam configuration without any TRP or cell-level indication. For example, the coverage of any (e.g., each) beam might be specified as an ellipsoid with appropriate parameterization.

[0197] Topology indication as a separate, dedicated configuration In some representative embodiments, the topology can be provided to the UE as a separate configuration. For example, the coverage topology configuration may not be part of the cell configuration and / or conditional (re)configuration. The coverage topology may depend on geographical deployment and coverage, but the configuration and signaling can be provided by the network independently of cell configuration and / or other conditional (re)configuration.

[0198] For example, coverage topology configurations can take the form of network node deployments and beam attributes. For example, a coverage topology configuration can take the form of detailed ground coverage incorporating terrain and topographic-specific features. Coverage and / or deployment topology configurations can provide links (e.g., associations) from indicated TRP locations and beam attributes to cell identifiers and cell configurations.

[0199] Topology indication as broadcast signaling In some representative embodiments, deployment and / or coverage topology indications can be transmitted by the network in the form of broadcast signaling. This information can be broadcast by the network, and relevant devices can be notified in advance or may have prior knowledge of how to receive and decode the information. For example, control information for locating topology-related broadcast information can be broadcast, such as by notifying all devices of broadcast-based topology information via (e.g., special) paging and / or downlink control information.

[0200] In some representative embodiments, topology indications can be considered as part of system information. For example, a (e.g., a new) System Information Block (SIB) can be designed to carry and convey deployment and / or coverage topology indications. The network can use periodic transmissions of the topology SIB to keep the UE aware of the topology information. A UE that may be initiating a relevant service that requires minimal disruption can send a (e.g., explicit) request to the network to transmit the topology SIB.

[0201] Activation of deployment and coverage topology In some representative embodiments, the network can provide one or more snapshots of the deployed and / or covered topology via RRC signaling. For example, the RRC signaling can be broadcast-based or UE-specific signaling. For example, the network can send a MAC-CE, which may include information indicating one of the deployed / covered topology snapshots considered to be active. The active topology can be used in LTM procedures (such as the LTM procedures described herein).

[0202] In some representative embodiments, any of RRC signaling, MAC-CE, and / or DCI can be used for topology activation. For example, a custom MAC-CE can be designed for this purpose, where the topology identifier provides a pointer to one of the topologies configured via RRC signaling. For example, PHY-based signaling (e.g., DCI) can be used to activate one of the configured topologies.

[0203] LTM Configuration As used herein, the terms LTM configuration, LTM candidate configuration, candidate configuration, target configuration, and configuration are generally used synonymously (e.g., unless otherwise distinguished).

[0204] For example, LTM configuration may include cell configuration (e.g., cell configuration information). The network can provide cell configuration to the UE at various levels of abstraction. For example, the network may provide cell configuration to the UE in the form of a serving cell configuration (e.g., by providing information elements such as "SCellConfig" or "SpCellConfig"). For example, the network may provide cell group configuration. Cell group configuration may include at least one "SpCellConfig". For example, the network may provide cell configuration via RRC reconfiguration. RRC reconfiguration messages may include cell group configuration.

[0205] For example, an LTM configuration may include measurement configurations (e.g., measurement configuration information). Measurement configurations may indicate a set of measurements taken via appropriate radio and non-radio measurements. Measurement configurations may specify conditions that can trigger events when met. For example, an LTM configuration may provide an association between one or more cell configurations and one or more measurement configurations.

[0206] In some representative embodiments, a low-layer triggered mobility procedure can be used to switch the current serving cell to a more suitable target cell. For example, the current serving cell can be the primary cell of a primary cell group, the primary cell of a secondary cell group, or any serving cell in either the primary or secondary cell group. Cell switching may require the application of a cell configuration for a target LTM candidate configuration. For example, the LTM configuration can be provided as part of a cell group configuration, such as having a "CellGroupConfig" information element. For example, the LTM configuration can be provided via "SpCellConfig" or "SCellConfig" information elements (e.g., but certain limitations can be imposed on LTM mobility range).

[0207] For example, a UE can execute procedures related to monitoring and / or evaluating certain appropriate LTM measurements, and events can be triggered based on the satisfaction of certain conditions. Any (e.g., each) event is associated with certain target configurations, and triggering an event can cause the UE to perform movement to the associated target configuration. This document describes details regarding LTM measurements and example events. Events can be linked to certain LTM configurations, and triggering an event can subsequently cause the WTRU to report the configuration to the network. In some cases, the WTRU can perform mobility exchanges to relevant candidate configurations that meet execution conditions.

[0208] In some examples, for LTM, a suitable set of configurations can be provided to the WTRU prior to mobility events, which can be based on (e.g., leveraging) knowledge of the cell (e.g., deployed via the same DU or via different DUs). In some examples, LTW procedures can leverage knowledge of and overlap with cell configurations (e.g., deployed via the same DU or via different DUs).

[0209] For dense networks using access points serving smaller areas via narrow beams, and for the rollout of LTM features, a UE can (e.g., potentially) be configured with several LTM configurations in addition to the higher-layer configurations already supported. Supporting many LTM configurations can provide the advantage of the UE being able to make faster LTM switching to one of the configured LTM candidates. A disadvantage may be that the network needs to provide all these configurations to the UE, which can consume transmission resources. Furthermore, the UE needs to keep all these configurations locally available for application in the case of LTM switching and needs to measure the configuration candidates and report them to the network.

[0210] Here are some methods that can be used to provide configuration from the network to the UE and to maintain configuration on the UE.

[0211] LTM candidate cells and beams configured separately In some representative embodiments, the network may provide (e.g., separate) configurations for any (e.g., each) LTM candidate, for example, at the granularity of cell and / or beam. For example, this could result in (e.g., very) large overhead in terms of transport resources and UE maintaining separate configurations.

[0212] As a separately configured LTM candidate cell In some representative embodiments, the network can provide a separate configuration for any (e.g., each) LTM candidate cell. For example, this configuration can be linked to (e.g., associated with) different beams of the candidate cell. The beam can be identified by any of the SSB index, CSI-RS index, and / or a suitable TCI state (e.g., which represents the QCL relationship with a suitable reference signal).

[0213] LTM candidate cells as incremental configuration In some representative embodiments, the cell configuration of any (e.g., each) LTM candidate cell can be provided as an incremental configuration relative to a suitable reference configuration. For example, the cell configuration can be applied to the configuration beams and / or TCI states of the candidate cells.

[0214] For example, a suitable reference configuration for providing incremental configuration could be the primary serving cell. For instance, with dual connectivity, the reference configuration could be the primary serving cell of the corresponding cell group.

[0215] For example, a reference configuration can be explicitly provided to the UE. The network can select (e.g., indicate) a suitable configuration that can (e.g., take into account the serving DU and / or neighboring DUs) optimally minimize the size and overhead of the incremental configuration.

[0216] For example, to minimize signaling overhead, the network can select (e.g., indicate) a suitable reference configuration as part of the LTM incremental candidate configuration. For instance, the network can provide an LTM configuration for cell C1 as an incremental configuration. Within the incremental configuration of C1, information (e.g., a pointer) can indicate which reference configuration will be used as the reference configuration for candidate C1. The network can appropriately select the reference configuration, for example, by providing a reference to one of the cell configurations that the UE has already been provided with and / or that the cell configuration is a cell configuration on the same DU. If the UE has not received any cell configuration on the same DU as candidate C1, the network can indicate a cell configuration on a different DU (e.g., provide a pointer to a cell configuration on a different DU).

[0217] For example, the network may provide one or more reference DU configurations associated with candidate DUs for which the network intends to provide LTM switching. DU identifiers may be provided as part of these reference configurations in an appropriate format. Any (e.g., each) incremental configuration may be provided as an incremental configuration on top of the reference DU configurations. For example, a reference DU configuration identifier may be used to indicate each candidate incremental configuration.

[0218] In an example with a reference configuration and an incremental configuration, the UE can perform LTM switching and apply the complete configuration derived jointly from the reference configuration and the incremental configuration of the LTM candidates. In the event of conflict and / or overlap, the UE can prioritize configuration values ​​and / or parameters, for example, by using configuration values ​​and / or parameters provided as part of the incremental configuration.

[0219] LTM Configuration Activation and Update LTM configuration activation In some representative embodiments, the network may provide one or more LTM configurations to the WTRU. The WTRU may (e.g., initially) activate a subset of the LTM configurations. Depending on application requirements, WTRU mobility level, WTRU's ability to support simultaneous LTM configurations, WTRU subscription level, and / or other network level considerations, the network may instruct (e.g., selectively) to activate only a subset of the configured LTM configurations.

[0220] For example, the network can use any of RRC signaling, MAC-CE, and / or DCI to activate an LTM configuration. For instance, the network can send a MAC-CE capable of activating one or more LTM configurations. Two different MAC-CEs can be used to accommodate different numbers of LTM configurations that may need to be activated for the final LTM procedure. For example, a custom MAC-CE can be used where the identifier of the LTM configuration provides an indication (e.g., a pointer) of the LTM configuration configured via RRC signaling. For instance, PHY-based signaling (e.g., DCI) can be used to activate one or more of the configured LTM configurations.

[0221] Updates for LTM configurations (one or more) In some representative embodiments, the network may provide a UE, such as one in the RRC_Connected state, with an appropriate (e.g., initial) configuration of LTM candidate cells and / or beams. Before receiving the initial configuration, the UE may send initial mobility assistance information to the network. Assistance information may include radio and / or non-radio measurements. The network may provide the UE with appropriate initial coverage information based on its geographic location and / or network deployment. The network may also provide an initial mobility configuration that may be associated with L1 / L2 triggered mobility. For example, the initial LTM configuration may include appropriate LTM configurations that can be triggered (e.g., based on L1 / L2 measurements). For example, the selection of appropriate configuration candidates may be based on any of the following: the UE's capabilities for LTM mobility (e.g., as indicated to the network), the UE's mobility requirements for active services and / or applications (e.g., QoS and / or QoE), UE non-radio measurements (e.g., geographic coordinates and / or orientation), and / or network dynamics (e.g., cell load, active traffic with different QoS levels, subscription levels, differentiated services). For example, the network can provide an initial configuration of LTM candidates to a given UE based on any of the above (e.g., a combination thereof).

[0222] Figure 5 This is a program diagram of an example procedure for initial coverage and / or LTM configuration and coverage and / or LTM configuration updates. In some representative embodiments, Figure 5The procedures can be executed by a UE in the RRC_Connected state (e.g., after sending RRCResumeComplete and / or RRCSetupComplete messages). The UE can send initial mobility assistance information to a base station (e.g., a gNB). For example, assistance information may include radio and / or non-radio measurements (e.g., location, position, panel, and / or field of view). For example, the UE may send assistance information when a vehicle starts (e.g., panning) and / or a game begins (e.g., rotating and / or blocking). The UE can receive initial coverage information from the network. For example, initial information may include identification of the coverage area and / or TRP, cell, and / or beam identifier service area. The UE can receive information from the network indicating one or more initial LTM configurations. For example, LTM candidates may be associated with configuration, priority, execution conditions (e.g., using radio and / or non-radio measurements), and / or activation status. For example, a subset of LTM candidates may be indicated as "activated" for active monitoring by the UE. The UE can monitor the configured radio and / or non-radio measurements. The UE can determine whether a reporting decision has been triggered and can continue reporting information indicating the configured radio and / or non-radio measurements. The network can determine whether to provide updated information, such as updates associated with existing LTM configurations (e.g., initial and / or active LTM configurations). For example, the network can send information to the UE indicating updated coverage information. For example, the network can send information to the UE indicating one or more updated LTM configurations. For example, the network can update by adding and / or removing and / or changing the activation status of one or more LTM configurations and / or mobility candidates.

[0223] In some representative embodiments, the initial configuration associated with coverage information and / or LTM candidates may no longer be suitable, for example, when a UE moves from its previously reported location to a new location that may have a different set of suitable LTM candidate configurations. Therefore, if reported measurements from the UE for radio and / or non-radio measurements change, rendering the previously configured LTM candidates unsuitable, the network can update the configuration. As described herein, the update process can be an update of the network coverage information and / or LTM candidate configuration. For example, the update can be an incremental addition and / or removal of previously provided configurations. For instance, the network may decide to provide a new configuration.

[0224] Although not shown in the flowchart, the network can decide to update the configuration without explicit reporting from the UE. One scenario is that the network can estimate changes in the UE's location / location through uplink signals. These uplink signals can be UE uplink transmissions such as PUSCH, PUCCH, or some suitable reference signals, such as probe reference signals.

[0225] In some representative embodiments, the network can decide to update the LTM configuration independently of information reported by the UE. Updates can occur without any reports from the UE and / or after a UE report (e.g., when it indicates that the UE's location and / or address has not changed). Network updates can be triggered based on dynamic network changes in terms of active services and / or active devices. This can lead to situations where some previously configured LTM candidates may lack the resources to support an incoming UE through the LTM procedure. The network can remove some previously configured LTM candidates and provide the UE with the configuration of additional LTM candidates.

[0226] LTM Measurement Based on Combined Radio and Non-Radio Signals In some representative embodiments, radio measurements and / or non-radio measurements (e.g., any combination thereof) can be used in low-level mobility procedures. For example, measurement frameworks, configurations, quantities, and reporting mechanisms can be used to provide one or more measurement reports to the network, and the network uses this information, which may be combined with other network / device information, to perform network-controlled and / or network-triggered mobility procedures. In these procedures, the network can send commands to the target WTRU for LTM switching to a given target cell and / or (one or more) beams, whereby the target cell and / or (one or more) beams can be broadcast by the network from the same DU (e.g., intra-DU scenario) or different DUs (e.g., inter-DU scenario) compared to the currently serving cell and / or (one or more) beams. In some examples, the LTM measurement framework can implement appropriate configuration of LTM measurement, triggering, and execution conditions, which can be used to trigger WTRU-managed LTM mobility to the target cell / beam. For example, cells and / or beams, execution conditions and / or measurements can be pre-configured by the network.

[0227] In some representative embodiments, LTM measurements may (e.g., primarily) be low-layer measurements, where processing, necessary filtering (e.g., when configured), and / or reporting (e.g., when configured) occur at the low layer. For example, the low layer may refer to L1 and / or L2. For example, L3 (e.g., the RRC layer of the radio protocol stack) may provide configuration for the low layers (e.g., the PHY and MAC layers), and the low layers may perform and process measurements according to the configuration received via RRC. In some representative embodiments, as described herein, the LTM procedure may include participation from L3.

[0228] In some representative embodiments, one or more UEs may be equipped with interfaces from any non-3GPP RAT, local sensors, and / or environmental information and / or quantities that can be acquired from certain accumulation points. The use of these quantities and their integration with measurements on 3GPP standardized RATs can be provided within a (e.g., harmonized) framework, whereby the UE can use data from one or more non-3GPP RATs individually, or in combination with data and / or measurements on one or more 3GPP RATs. For example, the amount of measurement and / or data from non-3GPP RATs and / or sensors can be used for beam-changing and / or cell-changing procedures.

[0229] While the measurement framework can be described in the context of low-level mobility using (e.g., 3GPP radio signals, non-3GPP radio signals, and / or local sensors), some representative embodiments can be applied to (e.g., other procedures and / or scenarios besides LTM). For example, measurements and / or events can be used to adjust certain aspects of low-level procedures, such as channel state information feedback. For example, measurements and / or events can be used to initiate monitoring of certain frequencies, cells, TRPs, and / or beams upon the triggering of certain events. For example, measurements and / or events can be used in higher-level procedures, such as any of legacy handover, conditional handover, and / or conditional PSCell change and / or addition procedures.

[0230] UE capability for LTM PHY measurement In some representative embodiments, the UE may provide information indicating one or more capabilities of the UE to perform PHY layer measurements of radio signals and / or non-radio signals and / or sources. For example, the capabilities may be provided (e.g., initiated) by the UE itself when attached to a network and / or during a transition to an RRC state. For example, the network may (e.g., also explicitly) request the UE's capabilities to perform PHY layer and / or LTM measurements, and the UE may respond with information indicating one or more of the UE's capabilities.

[0231] For example, one or more relevant PHY layer measurements used in an LTM procedure are quantities calculated on one or more reference signals. For example, a reference signal can refer to (e.g., a secondary) synchronization sequence (SS), channel state information reference signal (CSI-RS), positioning reference signal (PRS), and / or sounding reference signal (SRS). For example, resources and reference antenna connectors can be defined similarly to 3GPP 38.215, such as those used in the calculation of reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-noise ratio (SINR), and / or received signal strength indicator (RSSI).

[0232] Measurement of 3GPP radio quantities: In some representative embodiments, the UE may be able to measure one or more quantities at the PHY layer and may be able to indicate the UE's ability to measure any of these quantities, multiple measurements within and between frequencies, and / or multiple frequencies and / or bands that it may support for simultaneous measurement. In some representative embodiments, any of SSB, CSI-RS, PRS, and / or SRS may be used to determine (e.g., estimate) PHY measurement quantities.

[0233] In some representative embodiments, the UE may perform measurements to determine radio quantities, which may include 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 ratio and interference ratio (SS-SINR); CSI signal-to-noise ratio and 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); UERx–Tx time difference; and / or SS reference signal antenna relative phase (SS-RSARP). The UE may determine other radio quantities besides those listed above.

[0234] Measurement of non-3GPP radio signals: In some representative embodiments, the UE may be provided with information indicating the UE's ability to measure and report one or more non-3GPP signals via other available receivers on the device (e.g., the UE's receiver). For example, non-3GPP signals may be based on GNSS, WLAN, and / or Bluetooth-related measurements, and any of the like.

[0235] GNSS code measurement: For example, GNSS measurement may include GNSS code phase measurement (e.g., integer and / or fractional parts) of the spread spectrum code of a GNSS satellite signal, provided, for example, by configuration or with reference power.

[0236] GNSS carrier phase measurement: For example, GNSS measurement may include multiple carrier phase period measurements of GNSS satellite signals (e.g., integer and / or fractional parts), provided by configuration or with reference power.

[0237] WLAN RSSI: For example, WLAN measurements may include IEEE 802.11 WLAN RSSI measurements.

[0238] Bluetooth measurements: For example, Bluetooth measurements may include any Bluetooth signal power and / or source ID measurements.

[0239] Measurements based on RF pattern recognition and matching: For example, other non-3GPP radio measurements may include measurements for RF pattern recognition and / or matching.

[0240] Land beacon systems: For example, other non-3GPP radio measurements may include measurements of land beacon signals.

[0241] Non-radio measurements obtainable from local sensors: In some representative embodiments, the UE may have one or more (e.g., local) sensors that can provide (e.g., additional) non-radio measurements. Some examples are motion sensors (e.g., accelerometers, gyroscopes), environmental sensors (e.g., barometers or atmospheric pressure sensors), position sensors (e.g., magnetometers, orientation sensors), and / or velocity measurement sensors. For example, the sensors may provide any of the following measurements: linear acceleration and / or changes in linear acceleration; velocity and / or changes in velocity; orientation and / or changes in orientation; angular velocity and / or changes in angular velocity; atmospheric pressure and / or changes in atmospheric pressure; and / or magnetic field and / or changes in magnetic field.

[0242] In some representative embodiments, the UE can obtain quantities through a non-3GPP interface. For example, a UE capability indication can provide information associated with and / or identifying one or more sensors, one or more measurements available through the sensors, and / or an indication of the accuracy of these measurements.

[0243] Combination of Radio and Non-Radio Measurements: In some representative embodiments, one or more measurements can be defined, which can be obtained by combining one or more radio measurements and / or one or more non-radio measurements. For example, a measurement can be a combination of the UE's orientation relative to a reference TRP. For example, the UE's self-orientation can be defined in a suitable manner (e.g., the principal angle of its main antenna (or antenna array) and can be obtained from local sensors). For example, the UE's self-orientation can be known at the network or can be transmitted as part of capability exchange information. In some representative embodiments, the UE's orientation (e.g., relative to a reference TRP) can be defined as the angle between the UE's self-orientation and the line connecting the UE to the reference TRP. This determination can then be made using various sources and methods. For example, the UE can use GPS signals processed at the UE's local sensors (e.g., hardware, firmware, and / or software), combined with the TRP location provided by the network via 3GPP radio signals. For example, the UE can process 3GPP radio signals transmitted by the TRP and perform local estimations of these signals (e.g., angle of arrival) to determine the angle of the reference TRP from the principal or lateral angle of its antenna array. In addition to the processing performed via 3GPP radio signals, this determination can use local sensors, such as magnetometers and / or other orientation sensors. This information can be used at the UE along with its self-orientation information to estimate the UE's orientation relative to a reference TRP. For example, such measurements can be used as (e.g., stored as) a subgroup of non-radio measurements.

[0244] In some representative embodiments, the UE can be a multi-panel UE, and a reference panel can be used on the UE side. For example, the reference panel may have a larger number of antenna elements, better sensitivity, and / or become the primary antenna panel through its implementation and / or better connectivity with the UE's Tx / Rx chain. For multi-panel UEs, reference panel information can be shared with the network, for example, when the UE provides information about its antenna panel implementation.

[0245] In some representative embodiments, multiple TRP transmissions can occur, and a reference TRP can be used, for example, for orientation determination purposes. The reference TRP can be a TRP transmission DCI used for multiple TRP transmissions based on a single DCI. For multiple TRPs based on multiple DCIs, a reference TRP can be identified, for example, a TRP with a lower CORESETPoolndex. For example, the network can explicitly indicate the reference TRP. For UE-based selection, in the case of a multi-panel UE, the UE can select the TRP received through its reference antenna panel. For example, the reference TRP selection can be left to the UE, and the UE can provide information indicating the reference TRP to the network via appropriate signaling.

[0246] For measurement configurations as part of 3GPP positioning and location services, an RRC request to the Location Management Function (LMF) can be used to obtain positioning services for the target UE. The UE can then be configured with appropriate reference signals and methods for positioning purposes, the results of which can be used in LTM-based procedures. For example, the RRC layer can be allowed to request the target UE to initiate positioning services with the LMF, and the LMF can then provide the UE's RRC layer with information related to positioning signals and procedures.

[0247] Configuration for LTM measurements In some representative embodiments, LTM measurements can be defined for each cell group. For example, in a dual-connectivity scenario, one configuration can be provided for the primary cell group (MCG) and another configuration can be provided for the secondary cell group (SCG).

[0248] LTM Configuration as Part of Cell Group Configuration: In some representative embodiments, LTM measurement configuration can be provided as part of the cell group configuration. For example, a (e.g., new) structure for "LTM_meas_config" can be defined in "CellGroupConfig". Providing LTM measurement configuration in the CG configuration may be advantageous because it eliminates the need to provide this configuration with each cell change.

[0249] LTM configuration as part of RRC configuration: In some representative embodiments, LTM measurement configuration can be provided via RRC_Reconfiguration signaling. For example, a UE can associate one configuration with the MCG and another configuration with the SCG. These configurations can be advantageously maintained after the cell group configuration is updated.

[0250] LTM configuration as part of the serving cell configuration: In some representative embodiments, the LTM measurement configuration may be embedded within the serving cell configuration. The serving cell configuration can provide configuration for LTM measurements. For example, a (e.g., new) structure of "LTM_meas_config" within "ServingCellConfig" can be provided. Each cell can advantageously be configured with associated LTM measurements. The size of the serving cell configuration may increase, and updates to the serving cell configuration may result in higher overhead.

[0251] In some representative embodiments, the LTM measurement configuration may include information indicating the configuration of LTM measurement resources and / or LTM reporting configuration. For example, the configuration may include quantity configuration. The quantity configuration may (e.g., prior to reporting according to the reporting configuration) provide low-level filtering, processing, and / or other measurement criteria applied to the LTM measurement.

[0252] In some representative embodiments, LTM measurement configurations can provide multiple (e.g., different) LTM measurement resources and / or LTM measurement reporting configurations. This can incur high overhead for the UE in performing measurements, processing them, and reporting them to the network. For example, the UE may (e.g., only) perform measurements on LTM candidates that have been indicated and / or determined to be active. Activation of an LTM candidate configuration can be accomplished through explicit network configuration, conditional on radio or non-radio conditions, and / or after a timer expires.

[0253] LTM Measurement Resources In some representative embodiments, a set of measurement resources may be associated with radio measurement resources transmitted from 3GPP RATs (e.g., NG-RAN, EUTRAN, UTRAN, GPRS, and / or GSM). For example, the sources can be configured with appropriate parameterization. These sources may include any of SSB, CSI-RS, PRS, SRS, and / or other reference signals (e.g., signals designed for measurement purposes). In addition to resource identification, a suitable resource mapping may be provided in terms of time and frequency, subcarrier spacing (SCS), power control-related parameters, periodicity of periodic resources, cell identification associated with the measurement resources, and / or QCL information of the measurement resources.

[0254] For example, one or more (e.g., new and / or additional) parameters may be provided to measurement resources that can be used in the LTM procedure. For example, parameters may include any one of the following: a DU identifier or a suitable DU identifier, a CU identifier or a suitable CU identifier, and / or a TRP identifier or identifier. In some embodiments, these parameters may be provided where such information is required in some aspects of the LTM procedure and is known at the UE (e.g., based on which the UE anticipates taking certain actions).

[0255] LTM Report Configuration In some representative embodiments, the reporting configuration can provide reporting attributes based on the periodicity, semi-persistence, and aperiodicity of the configured measurement reports. For example, one or more reporting attributes can be provided based on the periodicity, semi-persistence, and / or aperiodicity of the configured measurement reports. The reporting configuration may include resources to be used to provide reports to the network. LTM reporting resources may include PUCCH resources, PUSCH resources, and / or service requests (SRs) sent to the network when reporting conditions or triggering conditions are met. This can reduce latency because reporting can be configured to occur through the PHY layer or MAC layer (in the form of MAC CE), which can be customized to deliver reports of the configured quantities.

[0256] For some scenarios and procedures where latency may not be an issue or the report size may be large, the report can be based on RRC (or L3).

[0257] The report configuration provides the LTM triggering and execution conditions for the measurement associated with a given report configuration.

[0258] Reporting configurations can provide sub-selections of measurement resources based on one or more criteria. For example, a reporting configuration can instruct reporting of the N quantities that are measured as the strongest and / or largest during a configured measurement period. For instance, a reporting configuration can provide reports of the N largest quantities, such as when they exceed a configured threshold. The value of N can be configurable. In some cases, N can take values ​​of 1, 2, 3, or larger. For example, when N is configured to 1, only the strongest measurement among those performed on the configured resource can be reported.

[0259] LTM measurements used for reporting In some representative embodiments, the LTM measurement framework can provide measurements for reporting purposes. The configuration of these measurements can provide additional processing and / or filtering to be applied to the raw measurements prior to reporting. For example, this processing may include thresholding, quantization in a specific format, mapping to any of certain formats and / or bit ranges. For example, filter coefficients can be specified to implement specific levels of noise and / or channel variation filtering. For example, to achieve seamless mobility over shorter time intervals, filtering can be configured to be enabled and / or disabled. For example, filter coefficients can be set to values ​​that enable them for raw measurement reporting.

[0260] For example, an LTM measurement configuration may include 3GPP-based radio measurements such as any of the SSB-index-RSRP, SSB-index-RSRQ, SSB-index-SINR, CRI-RSRP, CRI-RSRQ, CRI-CQI, CRI-SINR, PRS, and / or SRS quantities described herein.

[0261] For example, an LTM measurement configuration may include a reporting amount of non-radio measurements and associated post-processing / filtering amounts (e.g., non-3GPP radio signals that can be obtained from local sensors and / or other interfaces).

[0262] LTM Measurement Frame In some representative embodiments, LTM measurements can use an identifier from the LTM reporting configuration as the LTM measurement identifier. For example, the reporting configuration may include information indicating the LTM measurement resource configuration and LTM quantity configuration (e.g., pointers to the LTM measurement resource configuration and LTM quantity configuration). For example, LTM measurements can be enabled, disabled, activated, deactivated, or triggered via signaling (e.g., using a DCI with the identifier from the LTM reporting configuration).

[0263] Figure 6 This is an example LTM measurement framework diagram illustrating the association between LTM measurement identifiers and LTM measurement resource configurations. Figure 6 In this context, an LTM measurement report configuration with the identifier 'x' can include information indicating one or more LTM measurement resource configurations with identifiers 'a' and 'b'. For example... Figure 6 As shown, LTM measurement resource configuration 'a' may include a first set of radio 3GPP measurement types, radio non-3GPP measurement types, and non-radio measurement types (e.g., from sensors and / or other interfaces), while LTM measurement resource configuration 'b' may include a second set (e.g., different) of radio 3GPP measurement types, radio non-3GPP measurement types, and non-radio measurement types (e.g., from local sensors).

[0264] In some representative embodiments, LTM measurements can use separate configurations for LTM measurement resources and LTM reports. For example, a separate LTM measurement identifier may include information indicating two configurations (e.g., providing two pointers). For example, one indicator (e.g., a pointer) points to a set(s) of LTM measurement resource identifiers, and another indicator (e.g., a pointer) points to an LTM report configuration. For example, using LTM measurement identifiers, report configuration identifiers (e.g., objects) may not be distinguishable (e.g., unique) because LTM measurement identifiers can link a given report configuration to different sets of measurement resources to generate multiple LTM measurements. For example, an LTM measurement report configuration may include another indicator (e.g., a pointer) for configuring appropriate LTM measurement quantities. Figure 7 This is another example of an LTM measurement framework diagram illustrating the association between LTM measurement identifiers and LTM measurement resource configurations. (See diagram below.) Figure 7 As shown, the LTM measurement report configuration 'y' can include an association with the LTM measurement quantity configuration 'b'. In another example, parameters for the quantity configuration can be specified directly within the report configuration.

[0265] In some representative embodiments, the report configuration can provide all parameters related to a list or set of indications (e.g., pointers) of the report, quantity configuration, and LTM measurement resource configuration identifiers. Figure 8This is another example of an LTM measurement framework diagram illustrating the relationships between LTM measurement identifiers and LTM measurement resource configurations, LTM measurement quantity configurations, and reporting configurations.

[0266] In some representative embodiments, it is possible to... Figure 6 , Figure 7 and Figure 8 The framework shown can be modified and / or combined to provide associations between different configurations.

[0267] Activation and deactivation of measurements associated with non-radio signals and events In some representative embodiments, LTM measurements associated with LTM candidate configurations may be associated with non-radio signals and / or events.

[0268] For example, an LTM measurement configuration can use one or more non-radio signals to provide one or more activation conditions. Non-radio signals can be specified as conditional events with appropriate definitions for thresholds and / or offsets used to determine the conditions. For example, activation of the LTM measurement configuration can be conditional on an ab event when the UE enters a specific area. This document describes the various events that can be used.

[0269] For example, LTM measurement configuration activation can be based on (e.g., conditionally) an event when the UE device approaches (e.g., moves closer to) a transmission point deployed in the network (e.g., and its orientation is aligned with the transmission point). For example, activation conditions can be achieved by evaluating a set of events as described herein.

[0270] For example, one or more deactivation conditions (e.g., explicitly) can be specified as part of the LTM measurement configuration. For example, when an activation condition is not met, the UE can (e.g., will) deactivate the corresponding measurement configuration. For example, if the activation condition is based on the UE entering a specific area (e.g., conditional on the UE entering a specific area), then if the UE exits the active area, the UE can be configured to use exit as the deactivation condition and can (e.g., will) stop measuring the corresponding measurement configuration.

[0271] For example, activation and / or deactivation conditions for LTM measurement configurations can be specified as part of the reporting configuration.

[0272] For example, activation conditions can be specified as part of a measurement identifier or the measurement identifier can be used.

[0273] For example, activation conditions can be specified as part of a resource identifier or the resource identifier can be used.

[0274] Integration of non-3GPP and non-radio measurements in LTM measurement reports In some representative embodiments, the LTM measurement framework can be enhanced to report radio measurements performed via non-3GPP radio signals and / or non-radio measurements.

[0275] For example, non-radio quantities can refer to measurements that can be obtained through local sensors and / or other non-radio interfaces.

[0276] For example, non-3GPP-based radio measurements can refer to radio measurements performed via (e.g., using) non-3GPP signals. Non-3GPP-based radio measurements can refer to measurements defined for positioning and NTN ephemeris data. Non-3GPP-based radio measurements can include measurements from GNSS, WLAN, Bluetooth, and / or signals from other radio technologies that the UE can measure and report.

[0277] In some representative embodiments, the LTM measurement framework can be enhanced using a reporting identifier that provides reporting configuration for non-radio measurements. The reporting configuration can provide a combination of radio measurement resources (indicating their identifiers) and non-radio measurement quantities through appropriate parameterization. This configuration may (e.g., only) include non-radio quantities, and LTM reporting may (e.g., only) include non-radio measurements. For non-radio measurements, the reporting configuration can provide information about quantities of events that need to be evaluated, reported, and used to make decisions for performing LTM exchanges, or otherwise broadly apply to some form of condition assessment that may lead to an exchange or reconfiguration. These measurements can also indicate the type of filtering to be applied to the non-radio measurement quantities through appropriate parameters of the quantity configuration. The filtering operation can be specified using existing filtering mechanisms and / or coefficients for radio measurements, or additional (e.g., new) filtering procedures and / or coefficients suitable for non-radio measurements can be provided.

[0278] Measurements available from local sensors: In some representative embodiments, the UE may have local sensors that can provide additional measurements, in addition to those described above. Some examples are gyroscopes, accelerometers, barometric pressure sensors, and / or velocity measurement sensors, which can provide measurements such as velocity, acceleration, direction, atmospheric pressure, and the like. These measurements can be further processed to calculate other (e.g., more refined) quantities. For example, some of these quantities may also be available via a non-3GPP interface.

[0279] LTM Measurement Model and Processing Measurement modeling Figure 9 This is an LTM measurement plot illustrating an example LTM measurement model with L1 / L2 filtering. In some representative embodiments, L1 filtering may be left to the UE implementation, for example, according to specified performance requirements. Figure 9In this process, the beam combining and filtering procedures for cells can be specified by the RRC layer. Then, the L1 / L2 filter values ​​can be used to evaluate the triggering conditions of the LTM procedure and / or reporting procedure.

[0280] exist Figure 9 In this context, the LTM measurement model includes the following characteristics: -A: Measurements inside the physical layer (beam-specific samples); - Layer 1 filtering: Internal layer 1 filtering of the input measured at point A. The accuracy of the filtering may depend on the implementation. For example, how the measurement is actually performed at the physical layer by the implementation (input A and layer 1 filtering) is not subject to standard constraints; -A 1 : Measurements reported from L1 to L3 after L1 filtering (e.g., beam-specific measurements). - Beam combining / selection: Combines beam-specific measurements to derive cell quality. Beam combining / selection behavior can be standardized, and configuration can be provided by RRC signaling. The reporting period at point B may be equal to that at point A. 1 One measurement cycle at the location; -B: Measurements derived from beam-specific measurements reported to L3 after beam combining / selection (e.g., cell quality). - L1 / L2 filtering for cell quality: Filtering is performed on measurements provided at point B. The behavior of L1 / L2 filtering can be configured by the network. The filtering reporting period at point C can be equal to one measurement period at point B; -C: Measurement after processing in the L1 / L2 filter. The reporting rate can be the same as the reporting rate at point B. This measurement can be used as input to one or more evaluations of the reporting criteria; - Evaluation of Reporting Standards: Examine whether reporting actual measurements at point D is necessary. This evaluation can be based on more than one measurement stream at reference point C (e.g., to compare between different UE measurements). This is determined by points C and C... 1 This can be illustrated by the input. The UE can at least at point C, C' each time. 1 When reporting new measurement results, evaluation criteria are conducted. Reporting criteria can be standardized, and configuration can be provided by RRC signaling. -D: Measurement report information (messages) sent on the radio interface; -L1 / L2 beam filtering: For point A 1 The provided measurements (e.g., beam-specific measurements) perform filtering. The behavior of the L1 / L2 beam filters can be part of the configuration. The filtering reporting period at E can be equal to A. 1 One measurement cycle at the location; -E: Measurements processed in a beam filter (e.g., beam-specific measurements). The reporting rate can be compared with point A. 1 The reporting rate is the same. This measurement can be used as input to select the X measurement to be reported; - Beam selection for beam reporting: Select measurement X from the measurements provided at point E. The behavior of beam selection can be standardized, and the configuration of this module can be provided by RRC signaling; -F: Beam measurement information included in or containing measurement report information transmitted on the radio interface.

[0281] In some representative embodiments, the LTM measurement configuration can provide a framework by which the network can configure LTM measurements, including radio and / or non-radio measurements. The configured measurements can be candidates for periodic, semi-persistent, non-periodic, and / or event-triggered reporting, as indicated in the "LTM Measurement Reporting Configuration." For example, once an event is triggered, it can further trigger the reporting of the event and the execution of associated LTMs exchanged to the target candidate cell and / or beam. For example, one or more conditions, events, or thresholds can be provided as part of the "LTM Measurement Reporting Configuration."

[0282] While configuration of lower layers can (e.g., primarily) be managed through the RRC layer, configuration measurements based on radio and non-radio measurements can be configured with appropriate conditions to trigger certain LTM-related events at the PHY layer. Several example conditions and events are described in this paper. In PHY-based evaluations, after measurements are taken and / or obtained from other interfaces and local sensors, the PHY layer itself can (e.g., will) perform configured post-processing and filtering.

[0283] In some representative embodiments, condition evaluation can be performed to generate events at the MAC layer and trigger certain procedures. For example, the PHY layer can remain simple, and measurements can be passed to the MAC layer at appropriate intervals according to configuration. Post-processing and filtering can be configured to be performed at the PHY layer or the MAC layer, or partially at both layers (e.g., L1 and L2). For example, the MAC layer can be responsible for evaluating the conditions of the processed quantities and generating appropriate events. One advantage of this approach is that by disabling MAC processing / filtering, the delay can be similar to the PHY delay.

[0284] In some representative embodiments, the configuration may specify the periodicity of filtering and post-processing to be performed, as specified and / or indicated. The implementation of filtering and post-processing in any layer of the UE may depend on how it is implemented. For example, the processing and timing availability of the final quantities used to evaluate LTM triggering may be independent of which layer and / or block they are implemented in.

[0285] Figure 10 This is an LTM measurement plot illustrating an example LTM measurement model with events based on L1 and L3. Figure 10 In this context, the LTM measurement model can include models that are typically related to... Figure 9 Same characteristics.

[0286] In some representative embodiments, the LTM measurement framework can combine measurements filtered by L1 and L3, and LTM events can be set to evaluate based on either L1 or L3 measurements, or a combination of measurements (e.g., L1 and L3). For example, as... Figure 10 As shown, the combination can be specified by the network and configured by the RRC layer. Figure 10 As shown, L1 beamcombining measurements can be provided to an evaluation block (e.g., indicated by the thick black line), which also receives L3 filtering quantities. For example, event triggering and execution conditions may require specifying whether the quantity to be evaluated is L1, L3, or both.

[0287] Figure 11 An LTM measurement plot is shown for an example LTM measurement model with measurement bias. Figure 11 In this context, the LTM measurement model can include models that are typically related to... Figure 9 and Figure 10 Same characteristics.

[0288] In some representative embodiments, L1 and L3 measurements can be combined before evaluating the event. For example, it can be done by... Figure 11 The biasing block performs the combination. This block can be configured with appropriate configuration parameters, allowing lower-layer measurements to be biased using L3-filtered quantities. The biasing block can be configured to apply a bias to lower-layer measurements based on the L3-filtered measurements according to the configuration parameters. The biasing block can be modeled as a weighted combination of L1 and L3 measurements. For example, the weights can be provided as part of the configuration. In another example, the biasing block can be considered as a combination and filtering of input L1 and L3 quantities. The network can provide control over a suitable stable operating point for the bias measurement (e.g., using RRC configuration), which can be used to evaluate execution conditions before triggering reporting and / or LTM cell switching procedures.

[0289] Figure 12 An LTM measurement diagram is shown to illustrate an example LTM measurement model that is unified for LTM and L3 measurements. Figure 12 In this context, the LTM measurement model can include models that are typically related to... Figures 9-11 Same characteristics.

[0290] In some representative embodiments, a (e.g., unified) model of L3 and LTM measurements can be used. Each of the blocks (e.g., beam combining, L3 filtering of cells / beams, and / or event assessment parameters, such as offset and hysteresis) can be configured with two sets of configuration parameters. One set can be used for L3 conventional measurements, and the second set can be used for LTM-related measurement processing and event assessment and / or monitoring. For example, in Figure 12 A unified model for L3 and LTM measurements is shown, in which (e.g., LTM measurement configuration parameters and L3 measurement configuration parameters are provided separately. Although in Figures 11-14 Not shown in the text, but candidate quantities may include radio and non-radio measurements as described herein.

[0291] As described herein, the network may share (e.g., a single) deployment and / or coverage information, and one or more UEs may be configured with appropriate LTM measurements, including radio and non-radio quantities toward a target cell and / or beam. The UE may monitor and evaluate the configured quantities and, upon triggering certain events, perform LTM switching toward the target candidate cell and / or beam to which the configuration conditions are met.

[0292] In some representative embodiments, the reporting configuration can be extended to include (e.g., new) events based on non-radio measurements, where the UE will use data from local sensors. These events can utilize cell and beam properties such as those provided by network configuration (from the primary or secondary cell group), neighboring cells / beams, and / or deployment attributes of candidate cells / beams in the LTM configuration. That is, events can be created based on non-data measurements. These events can then be combined with radio measurement-based events to verify the suitability of cells and / or beams (e.g., for satisfactory signal strength).

[0293] In some representative embodiments, composite events can be used where conditions are specified for both non-radio measurements (e.g., location, position, orientation) and radio measurements (e.g., RSRP, RSRQ, SINR of SSB, CSI-RS, or other reference signals), and these composite events can be triggered when suitable conditions from both radio and non-radio measurement groups are met. The triggering of composite events can be used to trigger the execution of certain UE procedures and actions. For example, events from (e.g., radio- and non-radio-based) LTM measurements can be used to trigger procedures such as, but not limited to, LTM switching to a suitable target cell and / or beam.

[0294] Post-processing and filtering In some representative embodiments, the configuration can provide the selection of suitable parameters related to one or more additional post-processing and / or filtering coefficients that can be applied to (e.g., the original) LTM measurements. For example, post-processing and / or filtering can be configured for any (e.g., all) LTM measurements. For example, post-processing and / or filtering can be fully applied to any of 3GPP radio, non-3GPP radio, and / or non-radio measurements. Filtering and / or post-processing (e.g., as additional processing) can be applied to make the measurements suitable for use in LTM procedures, such as for any of the following: intra-cell and / or beam-switching, inter-cell and / or beam-switching, and / or inter-cell and / or beam-switching. The measurement framework described herein can be used in other cell and / or beam-level procedures (e.g., non-LTM procedures).

[0295] Deriving cell quantity from beam measurement In some representative embodiments, the LTM measurement framework may include (e.g., in addition to post-processing and / or filtering) deriving cell-level quantities from beam-level measurements. Parameters and / or thresholds for deriving cell-level quantities from beam-level measurements for reporting and / or event assessment purposes (e.g., when configured) may be specified as part of an "LTM Measurement Quantity Configuration". For example, an association (e.g., an identifier) ​​from an "LTM Measurement Reporting Configuration" may be used to indicate the "LTM Measurement Quantity Configuration". For example, mappings (e.g., mapping rules and associated parameters) may be provided (e.g., directly) as part of the "LTM Measurement Reporting Configuration".

[0296] LTM measurement events and triggers for condition reporting In some representative embodiments, a UE configured with LTM measurements can monitor and evaluate events configured through an appropriate combination of radio and non-radio measurements. The measurements on which event conditions are set can follow the measurement model described herein. For example, a reference measurement model may include cases where event conditions can be set on any of the following: L1 measurements only; L3 measurements only; joint events involving L1 and L3 measurements; and / or L1 measurements biased with L3 measurements.

[0297] In some representative embodiments, filtering information can be specified separately for non-radio measurements, or non-radio measurements can be configured to be processed using the LTM measurement model described herein. For example, (e.g., after processing and / or filtering) non-radio measurements are fed (e.g., input) to an event evaluation block.

[0298] This article describes program examples that use these event examples. For example, some exemplary events may be based on the use of radio, non-radio, and / or combined measurements.

[0299] As described below, several events related to radio and / or non-radio quantities from 3GPP and / or non-3GPP RATs are provided. Several joint events on these quantities are also described. For example events, triggering conditions may use offset and / or hysteresis values ​​(e.g., which may not always be used) for LTM measurements. For example, triggering conditions without offset and / or hysteresis values ​​can allow the UE to react quickly to changing channel conditions. For example, tuning parameters, offset, and / or hysteresis values ​​can be removed together from the condition definition, and / or they can be assigned zero or appropriate values ​​to achieve the desired delay.

[0300] LTM events measured using 3GPP radio signals In some representative embodiments, the prefix LTM-Ax may be used to refer to a set of events. These events may be named similarly to those defined in TS 38.331. For example, this set of events may be performed on measurements that are LTM measurements (e.g., which may be low-layer measurements with or without filtering as indicated in the "LTM Measurement Configuration"). For example, this set of events may be evaluated at lower layers (e.g., L1, L2) and / or may trigger LTM measurement reports or appropriate LTM cell switching procedures.

[0301] LTM event LTM-A1 (Service better than threshold) In some representative embodiments, event LTM-A1 can be used to mitigate LTM-based measurement monitoring and reporting. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition A1-1 (as specified below) is met; and / or When condition A1-2 (as specified below) is met, the exit condition of the event is considered to be satisfied; For this measurement, consider the NR serving cell corresponding to the associated measObjectNR associated with the event.

[0302] For example, the inequality A1-1 (e.g., the entry condition) can be defined as Ms>Thresh.

[0303] For example, inequality A1-2 (e.g., the departure condition) can be defined as Ms <Thresh。

[0304] For example, the above conditions can be defined using some hysteresis values ​​(e.g., which can be provided as part of the measurement configuration).

[0305] For example, the inequality A1-1 (e.g., the entry condition) can be defined as Ms - Hys > Thresh.

[0306] For example, inequality A1-2 (e.g., the departure condition) can be defined as Ms + Hys <Thresh。

[0307] For example, any of the aforementioned variables can be defined as follows: Ms can be the measurement result of the serving cell, without considering any offset; Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Thresh can be a threshold parameter for the event (e.g., the a1-threshold defined for the event in reportConfigNR). Ms can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Hys can be expressed in dB; and / or Thresh can be expressed in the same units as Ms.

[0308] LTM event LTM-A2 (Service becomes worse than the threshold) In some representative embodiments, event LTM-A2 can be used to trigger rapid reporting and / or periodic changes in LTM measurements. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition A2-1 (as specified below) is met; and / or When condition A2-2 (as specified below) is met, the exit condition of the event is considered to be satisfied; For this measurement, consider the serving cell indicated by the measObjectNR associated with the event.

[0309] For example, inequality A2-1 (e.g., the entry condition) can be defined as Ms + Hys <Thresh。

[0310] For example, inequality A2-2 (e.g., the departure condition) can be defined as Ms - Hys > Thresh.

[0311] For example, any of the aforementioned variables can be defined as follows: Ms can be a measurement of the serving cell (e.g., without considering any offset). Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Thresh can be a threshold parameter for the event (e.g., the a2-threshold defined for the event in reportConfigNR). Ms can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Hys can be expressed in dB; and / or Thresh can be expressed in the same units as Ms.

[0312] LTM event LTM-A3 (Neighbors become better offset than SpCell) In some representative embodiments, event LTM-A3 can be used to conditionally trigger UE reporting and / or cause LTM switching. This event can be used to increase the measurement and / or reporting periodicity of target neighbor candidates. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition A3-1 (as specified below) is met; and / or When condition A3-2 (as specified below) is met, the exit condition of the event is considered to be satisfied; Use SpCell for Mp, Ofp, and Ocp.

[0313] For example, any cell(s) that triggers an event may have a reference signal indicated in the measObjectNR associated with that event, which may be different from the NR SpCell measObjectNR.

[0314] For example, inequality A3-1 (e.g., the entry condition) can be defined as Mn+Ofn+Ocn-Hys>Mp+Ofp+Ocp+Off.

[0315] For example, inequality A3-2 (e.g., leaving the condition) can be defined as Mn + Ofn + Ocn + Hys <Mp + Ofp+ Ocp +Off。

[0316] For example, any of the aforementioned variables can be defined as follows: Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of the reference signal of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to the neighboring cell). Ocn can be a cell-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within measObjectNR corresponding to the frequency of the neighboring cell), and is set to zero if no neighboring cell is configured. Mp can be a measurement result from SpCell (e.g., without considering any offset); Ofp can be a measurement object-specific offset of the SpCell (e.g., offsetMO defined within the measObjectNR corresponding to the SpCell). Ocp can be a cell-specific offset of the SpCell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the SpCell), and is set to zero if not configured for the SpCell; Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Off can be the offset parameter for the event (e.g., the a3-offset defined for the event in reportConfigNR). Mn and Mp can be expressed in dBm under RSRP conditions, or in dB under RSRQ and RS-SINR conditions; and / or Ofn, Ocn, Ofp, Ocp, Hys, and Off can be expressed in dB.

[0317] LTM event LTM-A4 (Neighbors become better than the threshold) In some representative embodiments, the LTM-A4 event can be used to conditionally trigger a UE report and / or cause an LTM exchange. This event can also be used to increase the measurement and / or reporting periodicity of target neighbor candidates. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition A4-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition A4-2 (as specified below) is met.

[0318] For example, inequality A4-1 (e.g., the entry condition) can be defined as Mn+Ofn+Ocn-Hys>Thresh.

[0319] For example, inequality A4-2 (e.g., leaving the condition) can be defined as Mn + Ofn + Ocn + Hys <Thresh。

[0320] For example, any of the aforementioned variables can be defined as follows: Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a measurement object-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and can be set to zero if no neighboring cell is configured. Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Thresh can be a threshold parameter for the event (e.g., the a4-threshold defined for the event in reportConfigNR). Mn can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Ofn, Ocn, Hys are expressed in dB; and / or Thresh can be expressed using the same units as Mn.

[0321] LTM event LTM-A5 (SpCell becomes worse than threshold 1, and its neighbors become better than threshold 2) In some representative embodiments, event LTM-A5 can be used to conditionally trigger UE reporting and / or cause LTM switching. This event can also be used to increase the measurement and / or reporting periodicity of target neighbor candidates. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when both conditions A5-1 and A5-2 (as specified below) are met; and / or The departure condition of the event is considered to be met when either condition A5-3 or condition A5-4 (for example, at least one of them, as specified below) is met. Use SpCell for Mp.

[0322] For example, the parameters of one or more reference signals of one or more cells that triggered the event can be indicated in the event-related measObjectNR, which may be different from the measObjectNR of NR SpCell.

[0323] For example, inequality A5-1 (e.g., entering condition 1) can be defined as Mp + Hys <Thresh1。

[0324] For example, inequality A5-2 (e.g., entering condition 2) can be defined as Mn+Ofn+Ocn-Hys>Thresh2.

[0325] For example, inequality A5-3 (e.g., leaving condition 1) can be defined as Mp-Hys>Thresh1.

[0326] For example, inequality A5-4 (e.g., leaving condition 2) can be defined as Mn + Ofn + Ocn + Hys <Thresh2。

[0327] For example, any of the aforementioned variables can be defined as follows: Mp can be a measurement of NR SpCell (e.g., without considering any offset); Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a cell-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and is set to zero if no neighboring cell is configured. Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Thresh1 can be the threshold parameter for the event (e.g., a5-Threshold1 defined for the event in reportConfigNR). Thresh2 can be the threshold parameter for the event (e.g., a5-Threshold2 defined for the event in reportConfigNR). Mn and Mp can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Ofn, Ocn, and Hys can be expressed in dB; Thresh1 can be expressed in the same units as Mp; and / or Thresh2 can be expressed in the same units as Mn.

[0328] LTM event LTM-A6 (Neighbors become better offset than SCell) In some representative embodiments, event LTM-A6 can be used to conditionally trigger UE reporting and / or cause LTM switching for SCell replacement. This event can also be used to increase the measurement and / or reporting periodicity of target neighbor candidates. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition A6-1 (as specified below) is met; and / or When condition A6-2 (as specified below) is met, the exit condition of the event is considered to be satisfied; For this measurement, the (sub)cell corresponding to the measObjectNR associated with the event is considered the serving cell.

[0329] For example, the reference signals of (one or more) neighbors and (one or more) Scells are indicated in the associated measObjectNR.

[0330] For example, inequality A6-1 (e.g., the entry condition) can be defined as Mn+Ocn-Hys>Ms+Ocs+Off.

[0331] For example, inequality A6-2 (e.g., leaving the condition) can be defined as Mn + Ocn + Hys <Ms + Ocs +Off。

[0332] For example, any of the aforementioned variables can be defined as follows: Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ocn can be a cell-specific offset of a neighboring cell (e.g., cellIndividualOffset as defined in the associated measObjectNR), and is set to zero if no neighboring cell is configured. Ms can be a measurement of the serving cell (e.g., without considering any offset). Ocs can be a cell-specific offset of the serving cell (e.g., cellIndividualOffset as defined in the associated measObjectNR), and is set to zero if no such offset is configured for the serving cell. Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Off can be the offset parameter for the event (e.g., the a6-offset defined for the event in reportConfigNR). Mn and Ms can be expressed in dBm under RSRP conditions, or in dB under RSRQ and RS-SINR conditions; and / or Ocn, Ocs, Hys, and Off can be expressed in dB.

[0333] LTM events using non-3GPP radio and non-radio measurements In some representative embodiments, LTM events can utilize information from local sensors and / or non-3GPP interfaces, such as non-3GPP and / or non-radio measurements. In some embodiments, 3GPP radio signals can be used to improve the quality of the measurement, for example, for location-related measurements. For example, the UE may be able to obtain non-3GPP and / or non-radio measurements through processing without using 3GPP radio signals.

[0334] For example, mobility disruptions can be minimized through low-level cell switching, where additional benefits and deterministic mobility aspects can be gained by utilizing information from non-3GPP radio signals. Other interfaces can achieve this effect, for example, by combining non-3GPP radio signals and information data from local sensors. Any of the following events can be used in LTM procedures.

[0335] LTM non-radio event LTM-V1 (speed becomes greater than threshold) In some representative embodiments, LTM-V1 events can be used. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition V1-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition V1-2 (as specified below) is met.

[0336] For example, the inequality V1-1 (e.g., the entry condition) can be defined as Mv-Hys>Thresh1.

[0337] For example, inequality V1-2 (e.g., the departure condition) can be defined as Mv + Hys <Thresh2。

[0338] For example, any of the aforementioned variables can be defined as follows: Mv can be the UE velocity estimated by the UE through its local sensors (e.g., without considering any offset); Hys can be a hysteresis parameter for the event (e.g., a hysteresis as defined in the event's configuration). Thresh1 can be the threshold for the event, which is defined as a reference velocity within the configuration of the event and is used as the velocity threshold for entering the event; Thresh2 can be the threshold for the event, which is defined as a reference speed within the configuration of the event and is used as the speed threshold for exiting the event; Mv can be expressed in kilometers per hour; Hys can be expressed in the same units as Mv; and / or Thresh1 and Thresh2 can be expressed in the same units as Mv.

[0339] LTM non-radio event LTM-R1 (the amount of equipment rotation that occurred exceeds the threshold). In some representative embodiments, LTM-R1 events can be used. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition R1-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition R1-2 (as specified below) is met.

[0340] For example, the inequality R1-1 (e.g., the entry condition) can be defined as Mr-Hys>Thresh1.

[0341] For example, inequality R1-2 (e.g., the departure condition) can be defined as Mr + Hys <Thresh2。

[0342] For example, any of the aforementioned variables can be defined as follows: Mr can be the UE rotation estimated by the UE through its local sensors (e.g., without considering any offset), where the rotation estimation is performed over a duration not exceeding the duration Td configured as part of the configuration; Hys can be a hysteresis parameter for the event (e.g., a hysteresis as defined in the event's configuration). Thresh1 can be the threshold of the event, which is defined as the reference rotation amount within the configuration of the event and is used as the rotation threshold to enter the event; Thresh2 can be the threshold for the event, which is defined as a reference rotation amount within the configuration of the event and is used as the rotation threshold to exit the event; Mr can be expressed in degrees. Mr can also be expressed in radians. The unit used for Mr can be configured as part of the configuration. Hys can be expressed in the same units as Mr; and / or Thresh1 and Thresh2 can be expressed in the same units as Mr.

[0343] LTM non-radio event LTM-O1 (device orientation changes from current direction greater than threshold) In some representative embodiments, event LTM-O1 can be used. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when condition O1-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition O1-2 (as specified below) is met.

[0344] For example, the inequality O1-1 (e.g., the entry condition) can be defined as Mo-Hys>Thresh1.

[0345] For example, the inequality O1-2 (e.g., the departure condition) can be defined as Mo + Hys <Thresh2。

[0346] For example, any of the aforementioned variables can be defined as follows: Mo can be a change in UE orientation estimated by the UE through its local sensors (e.g., without considering any offset), where the orientation estimation is performed over a duration not exceeding the duration Td configured as part of the configuration; Hys can be a hysteresis parameter for the event (e.g., a hysteresis as defined in the event's configuration). Thresh1 can be the threshold of the event, which is defined as the amount of change in reference orientation within the configuration of the event and is used as the threshold for entering the event; Thresh2 can be the same threshold as Thresh1 and used as the rotation threshold to exit the event; Mo can be expressed in degrees. Mo can also be expressed in radians. The unit of Mo can be configured as part of the configuration settings. Hys can be expressed in the same units as Mo; and / or Thresh1 and Thresh2 can be expressed in the same units as Mo.

[0347] LTM non-radio event LTM-OT1 (equipment orientation matching the direction of a given TRP / cell within a threshold) In some representative embodiments, the event LTM-OT11 can be used.

[0348] For example, the conditional assessment of the event evaluates whether the UE orientation is aligned with a given TRP within a configured threshold. For example, the UE's self-orientation can be defined in a suitable manner (e.g., its main antenna, the main angle of its antenna array) and / or obtained from local sensors. For example, the UE's orientation relative to a reference TRP can be defined as the angle at the UE between its own orientation and the line connecting the UE to the reference TRP. This determination can then be made using various sources and methods. For example, the UE can use GPS signals processed by its local sensors (e.g., hardware, firmware, and / or software) in conjunction with the TRP location provided by the network. In another example, the UE can process the 3GPP radio signals transmitted by the TRP and determine the angle of the reference TRP relative to the main or side angle of its antenna array by performing local estimations (e.g., angle of arrival) on these signals. This information can then be used at the UE along with its self-orientation information to estimate the UE's orientation relative to the reference TRP.

[0349] In some representative embodiments, the current event LTM-OT1 can be configured such that the network provides a reference location for evaluating the orientation alignment of the UE relative to a reference orientation. For example, the network can ensure the orientation alignment of the UE relative to any reference orientation and / or direction that may not be linked to any deployment topology.

[0350] For example, a UE can (e.g., should): The entry condition for the event is considered satisfied when condition OT1-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition OT1-2 (as specified below) is met.

[0351] For example, the inequality OT1-1 (e.g., entry condition) (such as the device having an absolute orientation that matches the target cell beam) can be defined as abs(Ou - Thresh1). <Hys1。

[0352] For example, the inequality OT1-2 (e.g., the departure condition) can be defined as abs(Ou - Thresh1)>Hys1.

[0353] For example, any of the aforementioned variables can be defined as follows: Ou is the UE orientation estimated by the UE using its local sensors (e.g., without considering any offset). The reference for this orientation estimation can be the TRP location of the target cell and / or TRP, or a suitable RS (e.g., beam). Using the TRP location and / or signals from the TRP as a reference, the orientation estimation is aligned relative to a given TRP. The reference TRP indication, location, and / or signal used as a reference from a given TRP can be provided as part of the network configuration; Hys1 can be a hysteresis parameter for the orientation condition of the event; Thresh1 can be the threshold of the event, which is defined as a quantity of reference orientation within the configuration of the event and is used as the rotation threshold for entering the event. Ou can be expressed in degrees relative to a configured measurement reference. Ou can also be expressed in radians. The unit of Ou can be configured as part of the settings. Hys1 can be expressed in the same units as Ou; and / or Thresh1 can be expressed in the same units as Ou.

[0354] LTM non-radio event LTM-OD1 (equipment orientation and distance match the location of a given TRP / cell coverage within a threshold). In some representative embodiments, event LTM-OD1 can be used. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when both condition OD1-1 and condition OD1-2 (as specified below) are met; and / or The departure condition of the event is considered to be satisfied when either condition OD1-3 or condition OD1-4 (as specified below) is met.

[0355] For example, the inequality OD1-1 (e.g., entry condition 1) (e.g., where the device has an absolute orientation that matches the target element beam) can be defined as abs(Ou - Thresh1). <Hys1。

[0356] For example, the inequality OD1-2 (e.g., entry condition 2) (e.g., where the device is within a suitable distance of the target TRP) can be defined as Ml + Hys2 <Thresh2。

[0357] For example, the inequality OD1-3 (e.g., leaving condition 1) can be defined as abs(Ou - Thresh1)>Hys1.

[0358] For example, the inequality OD1-4 (e.g., leaving condition 2) can be defined as Ml + Hys2>Thresh2.

[0359] For example, any of the aforementioned variables can be defined as follows: Ml can be the UE location, which is represented by the distance between the UE and the reference location parameter of the event (e.g., the reference location of the candidate TRP of the event and / or without considering any offset); Ou can be the UE orientation estimated by the UE through its local sensors (e.g., without considering any offset). The reference used for orientation estimation for this event can be a suitable RS (e.g., beam) of the target TRP; Hys1 can be a hysteresis parameter for the orientation condition of the event; Thresh1 can be the threshold of the event, which is defined as a quantity of reference orientation within the configuration of the event and is used as the rotation threshold for entering the event. Thresh2 can be the threshold of the event, defined as the distance from the reference position configured in the event's configuration; Ou can be expressed in degrees relative to a configured measurement reference. Ou can also be expressed in radians. The unit of Ou can be configured as part of the settings. Hys1 can be expressed in the same units as Ou; Thresh1 can be expressed in the same units as Ou; Ml can be expressed in meters; Hys2 can be expressed in the same units as Ml, and / or Thresh2 can be expressed in the same units as Ml.

[0360] LTM non-radio event LTM-OD2 (based on configured thresholds, the location where the device orientation and distance better match the coverage of a given TRP / cell than the serving TRP / cell) In some representative embodiments, LTM-R1 events can be used. For example, the UE can (e.g., should): The entry condition for the event is considered satisfied when both condition OD2-1 and condition OD2-2 (specified below) are met; and / or The departure condition of the event is considered to be satisfied when either condition OD2-3 or condition OD2-4 (as specified below) is met.

[0361] For example, the inequality OD2-1 (e.g., entry condition 1) (such as where the absolute orientation of the device is aligned with the target cell TRP more than the serving cell orientation) can be defined as abs(Ou - On) - Hys1 <abs(Ou - Op)。

[0362] For example, the inequality OD2-1 (e.g., entry condition 2) (e.g., where the device is within a suitable distance of the target TRP) can be defined as Dn - Hys2 <Dp。

[0363] For example, the inequality OD2-3 (e.g., leaving condition 1) can be defined as abs(Ou - On) + Hys1 > abs(Ou - Op).

[0364] For example, the inequality OD2-4 (e.g., leaving condition 2) can be defined as Dn + Hys2>Dp.

[0365] For example, any of the aforementioned variables can be defined as follows: Ou can be the UE reference orientation in absolute units estimated by the UE through its local sensors (e.g., without considering any offset). Op can be the orientation of the service TRP relative to the absolute unit of the UE, estimated by the UE using the location of the service TRP received in the configuration; On can be the orientation of the neighbor TRP relative to the absolute unit of the UE, estimated by the UE using the location of the neighbor TRP received in the configuration; Hys1 can be a hysteresis parameter for the orientation condition of the event; Dp can be the distance between the UE's location and the location of the serving TRP, where the location of the serving TRP is part of the configuration. Dn can be the distance between the UE's location and the location of the neighboring TRP, where the location of the neighboring TRP is part of the configuration; Hys2 may be a hysteresis parameter used for the distance condition of this event; Ou can be expressed in degrees relative to a configured measurement reference. Ou can also be expressed in radians. The unit of Ou can be configured as part of the settings. Op, On, and Hys1 can be expressed using the same units as Ou; Dn can be expressed in meters; and / or Dp and Hys2 can be expressed in the same units as Dn.

[0366] LTM non-radio event LTM-CM1 (equipment crossing the boundary of a specific area in the coverage topology). In some representative embodiments, LTM-CM1 events can be used. For example, the UE can (e.g., should): The entry condition for this event is considered satisfied when condition CM1-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition CM1-2 (as specified below) is met.

[0367] For example, the inequality CM1-1 (e.g., an entry condition) (such as where a device crosses a boundary in an overlay topology) can be defined as Ml1-Hys>Thresh1.

[0368] For example, the inequality CM1-2 (e.g., the departure condition) can be defined as Ml1 + Hys <Thresh1。

[0369] For example, any of the aforementioned variables can be defined as follows: Ml1 can be the location of the UE, which is represented by the distance between the UE and the reference location parameter of the event (e.g., without considering any offset); Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Thresh1 can be a threshold for the event, defined as the distance from a reference location (e.g., the serving TRP) to the coverage topology boundary. Depending on the configuration, the UE can (e.g., will) derive Thresh1 from the coverage topology using information about its current location, the serving TRP location, and / or the boundary definition. The boundary definition can correspond to the coverage of an RNA, TA, PLMN, and / or TRP. This configuration can provide information such as whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the serving TRP and the UE) or whether to use information calculated differently. Ml1 can be expressed in meters; Hys can be expressed in the same units as Ml1; and / or Thresh1 can be expressed in the same units as Ml1.

[0370] LTM non-radio event LTM-CM2 (equipment enters a specific area) In some representative embodiments, the LTM-CM2 event can be used.

[0371] In some representative embodiments, this event can assess whether a UE has entered a specific area. The area identifier can be provided to the UE through configuration. For example, the network can provide the coordinates of the area center, its shape, and / or the length of the defined area. For example, the area can be hexagonal, square, or rectangular. The network can provide center coordinates, one length parameter for a square area, two length parameters for a rectangular area, or more parameters for other precisely shaped areas. For example, an area can represent a sidelink-type area obtained by configuring GPS coordinates. The network can provide the UE with the configuration for calculating the area. The UE can obtain its position and / or position estimate through local sensors. The UE's position information can be aided by using radio and / or non-radio signals. The calculated position allows the UE to calculate its distance from the area center. Knowing the area boundary, the UE can determine whether it has entered the area.

[0372] In some representative embodiments, a zone may be associated with network deployment and / or coverage. For example, the network may designate the zone center as the deployed TRP. Zone boundaries can be provided by appropriately selecting parameters, which can be constrained to be square, rectangular, or hexagonal by specifying associated parameters as described herein.

[0373] In some representative embodiments, the network may, for example, associate the configuration area with its cell, beam, and / or TRP effective coverage information by obtaining past measurement reports from the UE, drive tests, and the like.

[0374] For example, a UE can (e.g., should): The entry condition for the event is considered satisfied when condition CM2-1 (as specified below) is met; and / or The exit condition of the event is considered to be satisfied when condition CM2-2 (as specified below) is met.

[0375] For example, the inequality CM2-1 (e.g., entry conditions) (such as where a device crosses a specific area in the coverage topology) can be defined as Ml1-Hys <Thresh1。

[0376] For example, the inequality CM1-2 (e.g., the departure condition) can be defined as Ml1 + Hys > Thresh1.

[0377] For example, any of the aforementioned variables can be defined as follows: Ml1 can be the location of the UE, represented by the distance between the UE and a reference location parameter for the event (e.g., without considering any offset). The reference location belongs to a specific area associated with the event; Hys can be the hysteresis parameter for the event (e.g., the hysteresis defined for the event in reportConfigNR). Thresh1 can be a threshold for the event, defined as the distance from a reference location (e.g., the reference gNB / TRP location of the reference area) to the boundary of the coverage topology. Depending on the configuration, the UE can (e.g., will) derive Thresh1 from the coverage topology using information about its current location, the reference gNB / TRP location, and / or the boundary definition. The boundary definition can correspond to the coverage of the RNA, TA, PLMN, and / or gNB / TRP. This configuration can provide information such as whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the reference TRP and the UE) or whether to use a different calculation. The network can provide a value for Thresh1 that matches the area configuration. If the area configuration is sufficient, the network can expect the UE to derive the value of this threshold. Ml1 can be expressed in meters; Hys can be expressed in the same units as Ml1; and / or Thresh1 can be expressed in the same units as Ml1.

[0378] LTM non-radio event LTM-CM2V1 [LTM-CM2&<M-V1] (The device enters a specific area in the coverage topology and the speed becomes greater than the configured threshold) In some representative embodiments, the event LTM-CM2V1 can be used.

[0379] The LTM-CM2V1 event can be used to conditionally trigger UE reporting of LTM exchanges based on non-radio measurements (such as location coordinates and / or velocity estimates). This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0380] For example, the joint event is set on both location estimation (e.g., which can be obtained through non-radio measurements) and velocity estimation (e.g., non-radio measurements). For instance, the event can be specified solely by non-radio measurements. In other examples, a configuration can be provided where location estimation is obtained (e.g., individually) through radio measurements, measurements via 3GPP radio signals, or any combination of the foregoing.

[0381] For example, a UE can (e.g., should): The entry condition for the event is considered satisfied when conditions CM2V1-1 and CM2V1-2 (as specified below) are met; and / or The exit condition of the event is considered satisfied when either condition CM2V1-3 or CM2V1-4 (as specified below) is satisfied.

[0382] For example, the inequality CM2V1-1 (e.g., entry condition 1) (such as where a device crosses a specific area in the coverage topology) can be defined as Ml-Hys1 <Thresh1。

[0383] For example, the inequality CM2V1-1 (e.g., entering condition 2) can be defined as Mv-Hys2>Thresh2.

[0384] For example, the inequality CM2V1-3 (e.g., the departure condition) can be defined as Ml + Hys1>Thresh1.

[0385] For example, the inequality CM2V1-4 (e.g., the departure condition) can be defined as Mv + Hys2 <Thresh2。

[0386] For example, any of the aforementioned variables can be defined as follows: Ml can be the location of the UE, represented by the distance between the UE and a reference location parameter for the event (e.g., without considering any offset). The reference location belongs to a specific area associated with the event; Hys1 can be a hysteresis parameter for the event in the location condition (e.g., a hysteresis defined for the event in reportConfigNR). Thresh1 can be a threshold for the event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference area) to the boundary of the coverage topology. Depending on the configuration, the UE can (e.g., will) derive Thresh1 from the coverage topology using information about its current location, the reference gNB / TRP location, and / or the boundary definition. The boundary definition can correspond to the coverage of the RNA, TA, PLMN, and / or gNB / TRP. This configuration can provide information such as whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the reference TRP and the UE) or whether to use information calculated differently. Mv can be the UE velocity estimated by the UE through its local sensors (e.g., without considering any offset); Hys2 can be a hysteresis parameter for the event used for velocity condition evaluation (e.g., a hysteresis as defined in the configuration of the event). Thresh2 can be a threshold for the event, defined as a reference speed within the event's configuration, and used as the speed threshold for entering / exiting the event. For example, two separate thresholds can be configured for entry and exit conditions; Ml can be expressed in meters; Hys1 can be expressed in the same units as Ml1 (or Ml); Thresh1 can be expressed in the same units as Ml1 (or Ml); Mv can be expressed in kilometers per hour or miles per hour; Hys2 can be expressed in the same units as Mv; and / or Thresh2 can be expressed in the same units as Mv.

[0387] LTM non-radio event LTM-CM2O1 [LTM-CM2&<M-OT1] (The device enters a specific area in the coverage topology, and the orientation matches the configuration orientation within the threshold). In some representative embodiments, the event LTM-CM2O1 can be used.

[0388] In some representative embodiments, the event LTM-CM2O1 can be used to trigger UE reporting based on non-radio measurements, such as location coordinates providing area access information and / or orientation for a given TRP of a candidate configuration. This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0389] For example, the joint event is set on both location estimation (e.g., which can be obtained through non-radio measurements) and orientation estimation (e.g., non-radio measurements). For instance, the event can be specified solely by non-radio measurements. In other examples, a configuration can be provided where location and / or orientation estimates are obtained (e.g., individually) through radio measurements, measurements via 3GPP radio signals, or any combination of the foregoing.

[0390] For example, a UE can (e.g., should): The entry condition for this event is considered satisfied when conditions CM2O1-1 and CM2O1-2 (as specified below) are met; and / or The exit condition of the event is considered satisfied when either CM2O1-3 or CM2O1-4 (as specified below) is satisfied.

[0391] For example, the inequality CM2O1-1 (e.g., entry condition 1) (such as where a device crosses a specific region in the coverage topology) can be defined as Ml - Hys1 <Thresh1。

[0392] For example, the inequality CM2O1-2 (e.g., entering condition 2) can be defined as abs(Mo - Hys2). <Thresh2。

[0393] For example, the inequality CM2O1-3 (e.g., the departure condition) can be defined as Ml + Hys1>Thresh1.

[0394] For example, the inequality CM2O1-4 (e.g., the departure condition) can be defined as abs(Mo + Hys2)>Thresh2.

[0395] For example, any of the aforementioned variables can be defined as follows: Ml can be the location of the UE, represented by the distance between the UE and a reference location parameter for the event (e.g., without considering any offset). The reference location belongs to a specific area associated with the event; Hys1 can be a hysteresis parameter for the event in the location condition (e.g., a hysteresis defined for the event in reportConfigNR). Thresh1 can be a threshold for the event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference area) to the boundary of the coverage topology. Depending on the configuration, the UE can (e.g., will) derive Thresh1 from the coverage topology using information about its current location, the reference gNB / TRP location, and / or the boundary definition. The boundary definition can correspond to the coverage of the RNA, TA, PLMN, and / or gNB / TRP. This configuration can provide information such as whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the reference TRP and the UE) or whether to use information calculated differently. Mo can be the UE orientation estimated by the UE using its local sensors (e.g., without considering any offset), where the orientation estimation is performed over a duration not exceeding a duration Td configured as part of the configuration. The reference for the orientation estimation of this event can be one of the basic directions, a suitable location from the UE antenna (e.g., GPS coordinates), and / or a suitable RS (e.g., beam) of the target TRP. The orientation estimation can (e.g., will) provide a measure of how close the UE is to the reference UE antenna or antenna panel aligned with the reference location and / or direction. The reference location and / or direction, as well as the reference UE antenna used for the orientation estimation, can both be provided as part of the configuration. Hys2 can be a hysteresis parameter for the event (e.g., a hysteresis as defined in the event's configuration). Thresh2 can be the threshold for the event, which is defined as the amount of change in reference orientation within the configuration of the event and is used as the threshold for entering the event; Ml can be expressed in meters; Hys1 can be expressed in the same units as Ml; Thresh1 can be expressed in the same units as Ml; Mo can be expressed in degrees. Mo can also be expressed in radians. The unit of Mo can be configured as part of the configuration settings. Hys2 can be expressed in the same units as Mo; and / or Thresh2 can be expressed in the same units as Mo.

[0396] LTM joint events using conditions on radio and non-radio measurements In some representative embodiments, LTM events can use triggering conditions set on radio and non-radio measurements (e.g., using radio and non-radio measurement evaluation). For example, non-radio measurements utilize information from local sensors and / or non-3GPP interfaces. For example, 3GPP radio signals can be used to improve (e.g., modify) the quality of non-radio measurements. For example, LTM events can be radio and non-radio measurements to help find accurate time, location, and / or area for when reporting should be made for (e.g., to assist) LTM procedures. For example, a combination of radio and non-radio measurements with known deployment, coverage, and / or environmental condition information and / or statistical radio measurement may be beneficial in avoiding mobility disruptions.

[0397] Joint event LTM-J1 [LTM-CM2 & <M-A4] (The device enters a specific area in the coverage topology, and the reference cell in that area becomes better than a threshold) In some representative embodiments, the joint event LTM-J1 can be used.

[0398] In some representative embodiments, the joint event LTM-J1 can be used to trigger the reporting of LTM exchanges initiated by the WTRU based on radio measurements and location coordinates. This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0399] For example, the Joint Event LTM-J1 can be used for (e.g., set on) location estimation (e.g., which can be obtained by non-radio measurements) and reference cell quality (e.g., radio measurements).

[0400] For example, WTRU can (e.g., should): The entry condition for the event is considered satisfied when conditions J1-1 and J1-2 (as specified below) are met; and / or The exit condition of the event is considered to be satisfied when condition J1-3 or J1-4 (as specified below) is met.

[0401] For example, inequality J1-1 (e.g., entry conditions) (such as where a device crosses a specific area in the coverage topology) can be defined as Ml - Hys1 <Thresh1。

[0402] For example, inequality J1-2 (e.g., the entry condition) can be defined as Mn+Ofn+Ocn-Hys2>Thresh2.

[0403] For example, inequality J1-3 (e.g., the departure condition) can be defined as Ml + Hys1>Thresh1.

[0404] For example, inequality J1-4 (e.g., leaving the condition) can be defined as Mn + Ofn + Ocn + Hys2 <Thresh2。

[0405] For example, any of the aforementioned variables can be defined as follows: Ml can be the location of the UE, represented by the distance between the UE and a reference location parameter for the event (e.g., without considering any offset). The reference location belongs to a specific area associated with the event; Hys1 can be a hysteresis parameter for the event in the location condition (e.g., a hysteresis defined for the event in reportConfigNR). Thresh1 can be a threshold for the event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference area) to the boundary of the coverage topology. Depending on the configuration, the UE can derive Thresh1 from the coverage topology using information about its current location, the reference gNB / TRP location, and / or the boundary definition. The boundary definition can correspond to the coverage of the RNA, TA, PLMN, and / or gNB / TRP. This configuration provides information on whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the reference TRP and the UE) or whether to use information calculated differently. Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a measurement object-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and is set to zero if not configured for a neighboring cell; Hys2 can be the hysteresis parameter of the event that will be used in the cell measurement conditions (e.g., the hysteresis defined for the event in reportConfigNR). Thresh2 can be the threshold parameter for the event (e.g., the a4-threshold defined for the event in reportConfigNR). Ml can be expressed in meters; Hys1 can be expressed in the same units as Ml1; Thresh1 can be expressed in the same units as Ml1; Mn can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Ofn, Ocn, Hys2 can be expressed in dB; and / or Thresh2 can be expressed in the same units as Mn.

[0406] Joint event LTM-J2 [LTM-OD2&<M-A4] (Based on configured thresholds, the location of the device orientation and distance matches the location of a given TRP better than the serving TRP) In some representative embodiments, the joint event LTM-J2 can be used.

[0407] In some representative embodiments, the joint event LTM-J2 can be used to trigger a WTRU-initiated report of an LTM exchange based on radio measurements and local estimates of orientation and / or distance. This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0408] For example, the joint event LTM-J2 can be set on location plus orientation estimation (e.g., which can be obtained by radio, non-radio, or a combination of radio and non-radio measurements) and reference cell quality (e.g., radio measurements). For example, when a UE should move from one LTM cell to another, this event can provide (e.g., very) granular control (e.g., under network control or by the UE controlling itself through prior configuration).

[0409] For example, a UE can (e.g., should): When conditions J2-1, J2-2, and J2-3 (as specified below) are met, consider meeting the entry conditions for the event; and / or The exit condition for the event is considered to be met if any of conditions J2-4, J2-5, or J2-6 (as specified below) are satisfied.

[0410] For example, inequality J2-1 (e.g., entry condition 1) (e.g., where the absolute orientation of the device is aligned with the target cell TRP, which is superior to the serving cell orientation) can be defined as abs(Ou - On) - Hys1 <abs(Ou - Op)。

[0411] For example, inequality J2-2 (e.g., entry condition 2) (e.g., where the device is within a suitable distance of the target TRP) can be defined as Dn - Hys2 <Dp。

[0412] For example, inequality J2-3 (e.g., entering condition 3) can be defined as Mn+Ofn+Ocn-Hys3>Thresh3.

[0413] For example, inequality J2-4 (e.g., leaving condition 1) can be defined as abs(Ou - On) + Hys1 > abs(Ou - Op).

[0414] For example, inequality J2-5 (e.g., leaving condition 2) can be defined as Dn + Hys2 > Dp.

[0415] For example, inequality J2-6 (e.g., leaving condition 3) can be defined as Mn + Ofn + Ocn + Hys3 <Thresh3。

[0416] For example, any of the aforementioned variables can be defined as follows: Ou can be the UE reference orientation in absolute units estimated by the UE through its local sensors (e.g., without considering any offset). Op can be the orientation of the service TRP relative to the absolute unit of the UE, estimated by the UE using the location of the service TRP received in the configuration; On can be the orientation of the neighbor TRP relative to the absolute unit of the UE, estimated by the UE using the location of the neighbor TRP received in the configuration; Hys1 can be a hysteresis parameter for the orientation condition of the event; Dp can be the distance between the UE's location and the location of the serving TRP, where the location of the serving TRP is part of the configuration. Dn can be the distance between the UE's location and the location of the neighboring TRP, where the location of the neighboring TRP is part of the configuration; Hys2 may be a hysteresis parameter used for the distance condition of this event; Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a measurement object-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and is set to zero if not configured for a neighboring cell; Hys3 can be the hysteresis parameter of the event used in cell measurement conditions (e.g., the hysteresis defined for the event in reportConfigNR). Thresh3 can be the threshold parameter for the event (e.g., the a4-threshold defined for the event in reportConfigNR). Ou can be expressed in degrees relative to a configured measurement reference. Ou can also be expressed in radians. The unit of Ou can be configured as part of the configuration.

[0417] Op, On, and Hys1 can be expressed using the same units as Ou; Dn can be expressed in meters; Dp and Hys2 can be expressed in the same units as Dn; Mn can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Ofn, Ocn, Hys3 can be expressed in dB; and / or Thresh3 can be expressed in the same units as Mn.

[0418] Joint event LTM-J3 [LTM-CM2 & <M-A3] (The device enters a specific area in the coverage topology, and the reference cell in that area becomes superior to SpCell) In some representative embodiments, the joint event LTM-J3 can be used.

[0419] In some representative embodiments, the joint event LTM-J3 can be used to trigger a report initiated by the WTRU, causing LTM switching to replace the SpCell based on radio measurements and / or location coordinates according to coverage information from the network. This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0420] For example, the joint event LTM-J3 can be set on location estimation (e.g., which can be obtained through non-radio measurements) and comparison of cell quality with SpCell quality (e.g., radio measurements).

[0421] For example, a UE can (e.g., should): The entry condition for the event is considered satisfied when conditions J3-1 and J3-2 (as specified below) are met; and / or The exit condition of the event is considered to be satisfied when condition J3-3 or J3-4 (as specified below) is met.

[0422] For example, inequality J3-1 (e.g., entry conditions) (such as where a device crosses a specific area in the coverage topology) can be defined as Ml - Hys1 <Thresh1。

[0423] For example, inequality J3-2 (e.g., the entry condition) can be defined as Mn+Ofn+Ocn-Hys2>Mp+Ofp+Ocp+Off.

[0424] For example, the inequality J3-3 (e.g., the departure condition) can be defined as Ml + Hys1>Thresh1.

[0425] For example, inequality J3-4 (e.g., leaving the condition) can be defined as Mn + Ofn + Ocn + Hys2 <Mp +Ofp + Ocp + Off。

[0426] For example, any of the aforementioned variables can be defined as follows: Ml can be the location of the UE, represented by the distance between the UE and a reference location parameter for the event (e.g., without considering any offset). The reference location belongs to a specific area associated with the event; Hys1 can be a hysteresis parameter for the event in the location condition (e.g., a hysteresis defined for the event in reportConfigNR).

[0427] Thresh1 can be a threshold for the event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference area) to the boundary of the coverage topology. Depending on the configuration, the UE can derive Thresh1 from the coverage topology using information about its current location, the reference gNB / TRP location, and / or the boundary definition. The boundary definition can correspond to the coverage of the RNA, TA, PLMN, and / or gNB / TRP. This configuration provides information on whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the reference TRP and the UE) or whether to use information calculated differently. Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a measurement object-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and is set to zero if not configured for a neighboring cell; Mp can be a measurement result from SpCell (e.g., without considering any offset); Ofp can be a measurement object-specific offset of the SpCell (e.g., offsetMO defined within the measObjectNR corresponding to the SpCell). Ocp can be a cell-specific offset of the SpCell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the SpCell), and is set to zero if not configured for the SpCell; Off can be the offset parameter for the event (e.g., the a3-offset defined for the event in reportConfigNR). Hys2 can be the hysteresis parameter of the event that will be used in the cell measurement conditions (e.g., the hysteresis defined for the event in reportConfigNR). Ml can be expressed in meters; Hys1 can be expressed in the same units as Ml1; Thresh1 can be expressed in the same units as Ml1; Mn and Mp can be expressed in dBm under RSRP conditions, or in dB under RSRQ and RS-SINR conditions; and / or Ofn, Ocn, Ofp, Ocp, Hys2, and Off can be expressed in dB.

[0428] Joint event LTM-J4 [LTM-OD2&<M-A3] (Based on configured thresholds, the device orientation and distance match the location of a given TRP / cell better than the serving TRP / cell, and the reference cell in the area becomes better than SpCell) In some representative embodiments, the joint event LTM-J4 can be used.

[0429] In some representative embodiments, the joint event LTM-J4 can be used to trigger a report initiated by the WTRU, resulting in an LTM exchange based on radio measurements, equipment orientation, and / or location coordinates that provide a distance estimate. This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0430] For example, the joint event LTM-J4 can be set on location and orientation estimation (e.g., which can be obtained by radio, non-radio, or a combination of radio and non-radio measurements) and comparison of cell quality with SpCell quality (e.g., radio measurements). This event can provide (e.g., very) granular control (e.g., under network control or by the UE controlling itself through prior configuration) when the UE should move from one LTM cell to another.

[0431] For example, a UE can (e.g., should): When conditions J4-1, J4-2, and J4-3 (as specified below) are met, consider the fulfillment of the entry conditions for this event; and / or The exit condition for the event is considered to be met if any of conditions J4-4, J4-5, or J4-6 (as specified below) are satisfied.

[0432] For example, inequality J4-1 (e.g., entry condition 1) (e.g., where the absolute orientation of the equipment is aligned with the target cell TRP, which is superior to the serving cell orientation) can be defined as abs(Ou - On) - Hys1 <abs(Ou - Op)。

[0433] For example, inequality J4-2 (e.g., entry condition 2) (e.g., where the device is within a suitable distance of the target TRP) can be defined as Dn - Hys2 <Dp。

[0434] For example, inequality J4-3 (e.g., the entry condition) can be defined as Mn+Ofn+Ocn-Hys3>Mp+Ofp+Ocp+Off.

[0435] For example, inequality J4-4 (e.g., leaving condition 1) can be defined as abs(Ou - On) + Hys1 > abs(Ou - Op).

[0436] For example, inequality J4-5 (e.g., leaving condition 2) can be defined as Dn + Hys2 > Dp.

[0437] For example, inequality J4-6 (e.g., leaving condition 3) can be defined as Mn + Ofn + Ocn + Hys3 <Mp +Ofp + Ocp + Off。

[0438] For example, any of the aforementioned variables can be defined as follows: Ou can be the UE reference orientation in absolute units estimated by the UE through its local sensors (e.g., without considering any offset). Op can be the orientation of the service TRP relative to the absolute unit of the UE, estimated by the UE using the location of the service TRP received in the configuration; On may be the orientation of the neighbor TRP relative to the absolute unit of the UE, estimated by the UE using the location of the neighbor TRP received in the configuration; Hys1 can be a hysteresis parameter for the orientation condition of the event; Dp can be the distance between the UE's location and the location of the serving TRP, where the location of the serving TRP is part of the configuration. Dn can be the distance between the UE's location and the location of the neighboring TRP, where the location of the neighboring TRP is part of the configuration; Hys2 may be a hysteresis parameter used for the distance condition of this event; Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a measurement object-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and is set to zero if not configured for a neighboring cell; Mp can be a measurement result from SpCell (e.g., without considering any offset); Ofp can be a measurement object-specific offset of the SpCell (e.g., offsetMO defined within the measObjectNR corresponding to the SpCell). Ocp can be a cell-specific offset of the SpCell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the SpCell), and is set to zero if not configured for the SpCell; Off can be the offset parameter for the event (e.g., the a3-offset defined for the event in reportConfigNR). Thresh3 is the threshold parameter for this event (e.g., the a4-threshold defined for this event in reportConfigNR). Ou can be expressed in degrees relative to a configured measurement reference. Ou can also be expressed in radians. The unit of Ou can be configured as part of the settings. Op, On, and Hys1 can be expressed using the same units as Ou; Dn can be expressed in meters; Dp and Hys2 can be expressed in the same units as Dn; Mn and Mp can be expressed in dBm under RSRP conditions, or in dB under RSRQ and RS-SINR conditions; and / or Ofn, Ocn, Ofp, Ocp, Hys3, and Off can be expressed in dB.

[0439] Joint event LTM-J5 [LTM-CM2&<M-V1&<M-A4] (The device enters a specific area in the coverage topology at a speed greater than the configured threshold, and the reference cell in that area becomes better than the threshold.) In some representative embodiments, the joint event LTM-J5 can be used.

[0440] In some representative embodiments, the joint event LTM-J5 can be used to trigger a report initiated by the UE, resulting in LTM exchange based on radio measurements and / or location coordinates. This event can also be used to increase the periodicity of measurement and / or reporting of target neighbor candidates.

[0441] For example, the Joint Event LTM-J5 can be set on location estimation (e.g., which can be obtained by radio, non-radio, or a combination of radio and non-radio measurements), velocity estimation (e.g., non-radio measurements), and reference cell quality (e.g., radio measurements).

[0442] For example, this event can be triggered when a UE enters a specific area at a speed greater than a threshold, and the cell quality of the reference cell is better than another threshold. For instance, this event could be used to determine the UE's location on a highway, and the network could switch cells deployed after the reference cell (e.g., due to a highway indication as part of the event setup).

[0443] For example, a UE can (e.g., should): The entry condition for the event is considered satisfied when conditions J5-1, J5-2, and J5-3 (specified below) are met; and / or The exit condition of the event is considered to be satisfied when condition J5-4, J5-5, or J5-6 (as specified below) is met.

[0444] For example, inequality J5-1 (e.g., entry condition 1) (such as where a device crosses a specific area in the coverage topology) can be defined as Ml - Hys1 <Thresh1。

[0445] For example, inequality J5-2 (e.g., entering condition 2) can be defined as Mn+Ofn+Ocn-Hys2>Thresh2.

[0446] For example, inequality J5-3 (e.g., entering condition 3) can be defined as Mv - Hys3 > Thresh3.

[0447] For example, inequality J5-4 (e.g., leaving condition 1) can be defined as Ml + Hys1 > Thresh1.

[0448] For example, inequality J5-5 (e.g., leaving condition 2) can be defined as Mn + Ofn + Ocn + Hys2 <Thresh2。

[0449] For example, inequality J5-6 (e.g., leaving condition 3) can be defined as Mv + Hys1 <Thresh3。

[0450] For example, any of the aforementioned variables can be defined as follows: Ml can be the location of the UE, represented by the distance between the UE and a reference location parameter for the event (e.g., without considering any offset). The reference location belongs to a specific area associated with the event; Hys1 can be a hysteresis parameter for the event in the location condition (e.g., a hysteresis defined for the event in reportConfigNR). Thresh1 can be a threshold for the event, defined as the distance from the reference location (e.g., the reference gNB / TRP location of the reference area) to the boundary of the coverage topology. Depending on the configuration, the UE can derive Thresh1 from the coverage topology using its current location, the reference gNB / TRP location, and / or boundary definition information. The boundary definition can correspond to the coverage of the RNA, TA, PLMN, and / or gNB / TRP. This configuration provides whether Thresh1 is the LOS distance (in this case, Thresh1 is the distance to the coverage boundary on the line connecting the reference TRP and the UE) or whether to use information calculated differently. Mn can be a measurement result from a neighboring cell (e.g., without considering any offset); Ofn can be a measurement object-specific offset of a neighboring cell (e.g., offsetMO defined within the measObjectNR corresponding to a neighboring cell). Ocn can be a measurement object-specific offset of a neighboring cell (e.g., cellIndividualOffset defined within the measObjectNR corresponding to the neighboring cell), and is set to zero if not configured for a neighboring cell; Hys2 can be the hysteresis parameter of the event that will be used in the cell measurement conditions (e.g., the hysteresis defined for the event in reportConfigNR). Thresh2 can be the threshold parameter for the event (e.g., the a4-threshold defined for the event in reportConfigNR). Mv can be the UE velocity estimated by the UE through its local sensors (e.g., without considering any offset); Hys3 can be a hysteresis parameter for the event used for velocity condition evaluation (e.g., a hysteresis as defined in the configuration of the event). Thresh3 can be a threshold for the event, defined as a reference speed within the event's configuration, and used as the speed threshold for entering / exiting the event. Two separate thresholds can be configured for entry and exit conditions; Ml can be expressed in meters; Hys1 can be expressed in the same units as Ml1; Thresh1 can be expressed in the same units as Ml1; Mn can be expressed in dBm in the case of RSRP, or in dB in the cases of RSRQ and RS-SINR; Ofn, Ocn, and Hys2 can be expressed in dB; Thresh2 can be expressed in the same units as Mn; Mv can be expressed in kilometers per hour; Hys3 can be expressed in the same units as Mv; and / or Thresh3 can be expressed in the same units as Mv.

[0451] Additional examples of non-radio events and joint events In some representative embodiments, any of the foregoing events can be used in the procedures described herein. For example, these events can combine measurements obtained through radio and non-radio measurements, which can be used to update LTM-related measurements, trigger reports, trigger network-controlled LTM switching, and / or trigger LTM switching locally at the UE. These examples can be used to jointly create additional events through radio and non-radio measurements. For example, additional events can identify target scenarios in a very precise manner and / or allow the UE to select the most suitable candidate among intra-DU, inter-DU, and / or inter-CU scenarios.

[0452] In some representative embodiments, events can be defined (e.g., new or additional) on a set of non-radio measurements. This can be advantageous, for example, in situations where the environment is controlled and / or the network may have comprehensive knowledge of the wireless environment in terms of terrain, buildings, and / or other objects.

[0453] In the example of combined events, events LTM-A3 and LTM-A4 can be combined with non-radio measurements (e.g., combined device orientation, distance, and / or area identification).

[0454] In one example, event LTM-A5 can be combined with non-radio measurements.

[0455] For example, the joint events LTM-J1, LTM-J2, LTM-J3, and LTM-J4 can be further combined with speed and / or speed conditions (e.g., as used in event LTM-V1) to separate high-speed and low-speed scenes and trigger appropriate actions based on the given scene.

[0456] For devices with strong rotational mobility, LTM-R1 or LTM-O1 events can be combined with radio measurement events (e.g., LTM-A3, LTM-A4, and / or LTM-A5) to create conditional LTM events focused on rotation, which can be used to trigger appropriate actions leading to reporting, report updates, and / or monitoring updates.

[0457] In some representative embodiments, joint events can be used, where execution conditions are set on a combination of conventional L3 measurements and LTM measurements as described herein.

[0458] In some representative embodiments, events and / or conditions based on wireless LAN, Bluetooth, and / or other radio access technologies may be used (e.g., added). Such events and / or conditions can be defined where network operators may be aware of the (e.g., public) deployment of such access points. For example, any of WLAN, Bluetooth, and / or other RAT-based measurements can be combined with other wireless and non-wireless signals to derive additional (e.g., further refined) joint events as described above.

[0459] WTRU Capability Based on LTM Mobility (Combined Radio and Non-Radio Measurements) In some representative embodiments, LTM mobility configuration and subsequent monitoring may require additional tracking at the UE of cells and / or beams that could be potential targets of LTM mobility, such as whether they are active or deactivated. LTM mobility features may require additional (e.g., new) UE capabilities in receiving and maintaining LTM configurations, handling candidate LTM exchanges within and between DUs, and / or monitoring and reporting LTM measurements.

[0460] With the dense deployment of network access points (e.g., TRPs) and beam-based transmissions, and considering the more frequent changes in cell and / or beam characteristics and equipment compared to traditional systems, the amount of measurement required for different cells and / or beams may increase for the UE. In addition to all measurements required for channel state information and MIMO, and / or higher-level measurements of traditional cell change procedures, the UE may (e.g., needs to) perform measurements at different levels compared to the serving cell, the cell configured for LTM mobility, and the active LTM cell versus the deactivated LTM cell. In some representative embodiments, LTM measurements can be intra-cell or inter-cell, for example, where inter-cell measurements can be performed at different frequencies within the same frequency band or on different frequency bands.

[0461] For beam-based transmissions, the UE may require measurement gaps, such as inter-frequency measurements. The UE may (e.g., needs to) apply appropriate beamforming; that is, the UE may need to receive signals with different QCL relationships, and the UE may not be able to simultaneously receive signals from different QCL relationships (e.g., even within the same frequency range). The UE may need appropriate measurement gaps to apply the appropriate QCL relationships and perform measurements. For example, the measurement gap may potentially (e.g., just) be larger than the measurement time to accommodate beam-switching timing.

[0462] In some representative embodiments, in-frequency LTM measurements may be distributed over any of the following: active cells in the L1 / L2 mobility configuration set; deactivated cells in the L1 / L2 mobility configuration set; and / or the current serving cell as an L1 / L2 mobility candidate for PsCell.

[0463] In some representative embodiments, inter-frequency LTM measurements may be distributed over any of the following: active cells in the L1 / L2 mobility configuration set; deactivated cells in the L1 / L2 mobility configuration set; and / or the current serving cell as an L1 / L2 mobility candidate for PsCell.

[0464] In some representative embodiments, the minimum UE capability can be defined based on the intra-frequency and / or inter-frequency LTM measurements that the UE must support to enable and / or activate LTM features.

[0465] In some representative embodiments, for more capable UEs, additional capabilities can be defined (e.g., used) for any UE that is able to support a greater number of intra-frequency and / or inter-frequency LTM measurements than the minimum UE capability for LTM measurements.

[0466] In some representative embodiments, any UE with multiple antenna panels may be able to support and measure a large number of intra-frequency and / or inter-frequency LTM measurements. For example, when these UEs are able to perform these measurements using panels they are not using, they may require less interruption to perform LTM measurements associated with intra-frequency and / or inter-frequency LTM measurements. For example, a capability can be defined for a UE with multiple antenna panels to specify the number of intra-frequency and / or inter-frequency LTM measurements it supports and / or details about which of these measurements can (e.g., are able to) be performed without measurement gaps. For example, the LTM measurement capability of a multi-panel UE can increase the number of supported measurements (e.g., proportional to the number of antenna panels implemented). For example, the number of supported measurements can be explicitly defined for a multi-panel UE. For example, one table can specify (e.g., indicate) the number of supported intra-frequency and / or inter-frequency LTM measurements for a 2-panel UE, another table can be used for a 4-panel UE, and / or another table can be used for an 8-panel UE. For example, a table can specify (e.g., indicate) the measurements supported by different numbers of panels that a UE may (e.g., potentially) be equipped with.

[0467] In some representative embodiments, measurements of radio and non-radio quantities, as well as joint events, are discussed. In addition to capabilities based on 3GPP radio signals, the UE may (e.g., needs to) inform the network of its capabilities related to non-3GPP radio signals, local sensors, and / or other interfaces, which can be used or are applicable to LTM procedures based on joint radio and non-radio measurements. The UE may provide capability information to the network, and based on this knowledge, the network can select a suitable set of joint radio and non-radio measurements as part of LTM measurement and configuration. For example, the UE may provide sources of these non-3GPP RATs, local sensors and / or other interfaces, and / or other relevant parameters (e.g., availability and / or accuracy levels) to help the network select the appropriate set of quantities to use in LTM procedures based on joint radio and non-radio measurements.

[0468] LTM-Execution Based on Combined Radio and Non-Radio Measurements In some representative embodiments, an execution phase for an LTM procedure based on joint radio and non-radio measurements is provided. In one example, the execution phase of the LTM procedure may include UE monitoring and reporting based on joint radio and non-radio measurements, network decisions regarding cell switching and issuing cell switching commands, and UE actions to perform cell switching.

[0469] WTRU monitoring, assessment, and reporting for radio and non-radio measurements In some representative embodiments, once configured, the UE can (e.g., will) begin monitoring the configured measurements. In some examples, there may be an activation phase based on a timer or via explicit command. The LTM reporting configuration provides the necessary parameters for reporting LTM measurements to the network. The measurement report includes radio and non-radio measurements configured as part of the LTM measurement configuration.

[0470] The LTM reporting configuration can be configured to allow LTM measurements to be reported as part of the UCI. In this design, LTM measurements are reported via PUCCH or PUSCH with appropriate parameters and periodicity, as specified in the LTM reporting configuration.

[0471] LTM reporting configurations can be set for certain quantities, allowing LTM measurements to be reported as RRC messages. This design may be more suitable when latency is not an issue.

[0472] LTM reporting configuration can be provided as a hybrid reporting configuration. In a hybrid design, LTM measurement reporting can be partially configured as a UCI transmitted via PUCCH / PUSCH (or used to trigger lower-layer events) and partially reported via RRC messages. In a variant of the hybrid design, LTM reporting is configured such that it is reported via RRC when certain conditions are met. If these conditions are not met, the UE begins reporting LTM measurements as part of the UCI (PUCCH / PUSCH). The RRC configuration and UCI (PUCCH / PUSCH) configuration for reporting LTM measurements are part of the LTM reporting configuration. The LTM reporting configuration also provides the conditions for the UE to select a particular reporting type and the conditions for switching to another reporting type. These conditions can be specified based on when the UE enjoys good channel conditions in its serving cell / beam. When the serving cell / beam quality is better than the configured threshold, the UE can be configured to report LTM measurements via RRC. Since the UE is in good channel conditions, the associated latency may not be an issue. When channel conditions deteriorate, the UE will switch to more flexible lower-layer reporting based on the conditions and thresholds provided as part of the configuration. In low-level reports, the cycle time may be shorter and the resource overhead may be greater, but this may be reasonable because the UE may be at risk of link degradation, and these measurements can enable fast LTM switching to appropriate neighboring cells and beams.

[0473] LTM Cell Switching Command For network-controlled LTM procedures, the network determines when a given UE should switch from its serving cell to the LTM target cell, which is either the serving cell or the primary cell of any of its cell groups. The network can configure appropriate measurements to aid its decision, which are discussed in this paper. In addition to UE measurements and feedback, the network can use other criteria and system-level aspects to make mobility decisions.

[0474] Once the network decides to move the UE from the serving cell to the target LTM cell, it provides the UE with a cell switching indication or command. A key aspect of the LTM procedure is that the cell switching command is transmitted over lower layers (e.g., L1 or L2). The cell switching command is provided to the UE along with the necessary information to enable switching to the target cell. The cell switching command includes the LTM target configuration and beam indication. The beam indication can be provided as an SSB index, CSI-RS index, or a suitable QCL identifier, where the QCL has been configured by the network at the UE providing the reference signal and is set for that reference signal. The beam indication can be explicit or implicit. When performing a cell switch, the cell switching command can also provide indications on how to handle the data and control plane at the UE. This indication can be provided as an explicit indication, such as when MAC / RLC entities need to be reset and PDCP needs to be data restored, etc. In another compatible design, the network can indicate whether the cell switch is within a DU or between DUs, and the UE can be a priori programmed to perform MAC / RLC / PDCP handling according to the inter-DU / intra-DU indication. In one example, whenever the network transmits an inter-DU indication, the MAC and RLC entities can be reset, and the PDCP can perform data recovery. In the case of an internal DU, no reset or data recovery is initiated. Furthermore, the cell switching command can indicate the type of signaling the UE should use on the target cell when performing cell switching. For example, the cell switching command can provide whether the UE should transmit RACH, a specific PUCCH, or another signal on the target cell. These signaling mechanisms are detailed here. In a compatible design, this information can be implicitly a function of other parameters configured for the LTM target cell. These may include, for example, whether the target cell is already a serving cell or an active cell. The cell switching command can also provide timing advance in an explicit or implicit manner. For example, if the deployment is for a very small cell, the UE may not need to apply timing advance. This can be known from the configuration or explicitly indicated. In another example without timing advance, the target cell may have the same timing as the current serving cell, potentially within the cyclic prefix margin. In other instances, the network can explicitly indicate the timing advance value that the UE should apply when transmitting to the target cell in the uplink direction.

[0475] The network can transmit cell switching commands in MAC-CE. The advantage of MAC-CE-based instructions is that it can easily provide the UE with other relevant information required for the cell switching command.

[0476] In a compatible design, cell switching commands can be provided via PHY signaling. This can be achieved by designing a downlink control indication (DCI) with special fields suitable for carrying LTM cell switching command parameters as described above. PHY signaling can have lower latency and can further reduce mobility disruptions.

[0477] In a hybrid design, the network can maintain a design based on both MAC and PHY. Therefore, the UE is configured to receive LTM cell switching commands via both MAC and PHY signaling. Depending on the circumstances, the network can choose either MAC or PHY signaling to provide the appropriate LTM cell switching commands to the UE in a timely manner, considering UE application requirements, UE reports of radio and non-radio measurements, and the availability of transmission timing.

[0478] UE data and control plane processing during LTM switching In some representative embodiments, when a UE performs an LTM switch to an LTM target candidate, the UE applies the configuration of the LTM target candidate. Two main use cases for LTM switching are when an LTM switch is performed on a target cell and / or candidate beam that is being served by the same DU (e.g., intra-DU switching) or by a different DU compared to the cell (or beam) it replaces (e.g., inter-DU switching). As a function of intra-DU or inter-DU LTM switching, the UE may need to handle internal control and data plane entities, such as MAC entities, RLC entities, and PDCP, in different ways.

[0479] For LTM switching within a DU, the UE can be configured to keep the MAC, RLC, and PDCP entities unchanged (e.g., not reset).

[0480] For inter-DU LTM switching, the UE can reset its MAC and RLC entities and create new MAC and RLC entities based on the configuration of the target LTM candidate. For the PDCP layer, the UE may need to initiate data recovery (or reconstruction), for example, if the RLC (e.g., buffered data) is reset.

[0481] For example, the determination of the behavior of applying MAC, RLC, and PDCP layer resets (or during LTM switching events) can be made by the UE, for example, as a function of whether an intra-DU or inter-DU LTM switch occurs. The UE can derive information about whether the LTM switch is intra-DU or inter-DU by the configuration of the serving cell and the applied candidate LTM configuration.

[0482] For example, each LTM configuration can provide an indication of whether the MAC and / or RLC entities need to be reset, and whether PDCP recovery is required.

[0483] In one example, for network-controlled LTM switching, the LTM switching command can instruct the UE whether it needs to reset the MAC and RLC entities, and whether it needs to restore PDCP.

[0484] UL indication of the network during LTM switching When a UE performs an LTM switch to an LTM target candidate, the UE can (e.g., will) transmit an indication to the LTM target candidate so that both the UE and the LTM target candidate have the same understanding of which cell / beam the UE is performing the LTM switch for. The selection of the UL indication can be part of the LTM configuration.

[0485] For network-controlled LTM switching, the LTM switching command can instruct the UE which type of UL indication to transmit during an LTM switching event.

[0486] The design details of the uplink indication transmitted from the UE to the network during LTM switching are described below.

[0487] Indication based on PRACH transmission In some representative embodiments, the UE may (e.g., will) perform PRACH procedures on LTM candidate cells and / or beams. Contention-free RACH configurations may be provided for LTM candidates (e.g., to accelerate RACH procedures).

[0488] In some cases, this can be helpful when there is a significant timing advance difference, and this type of signaling allows the network to determine and provide the correct timing advance value to the UE in the target cell.

[0489] Indication based on RACH preamble In some representative embodiments, the UE may (e.g., will) (e.g., only) perform the transmission of the RACH preamble. Preamble identifiers and / or resources can be allocated for LTM candidate cells and / or beams. The entire RACH procedure may not be necessary if the network has already provided the necessary cell configuration and the timing advance is zero or known to be within cyclic prefix constraints. For example, transmitting the RACH preamble only to LTM target candidates can save transmission resources and accelerate reliable data communication on the selected target candidate. This latency saving can be crucial for improving latency when cell and / or beam switching is required during mobility procedures.

[0490] Indication based on reference signal In some representative embodiments, the UE can be configured to transmit one or more reference signals to the LTM target candidate cell and / or beam. For example, the reference signals can be one or more Sounding Reference Signals (SRSs). Configuration parameters for SRS transmissions, including sequence, power, and / or time-frequency resources, can be provided to the UE as part of the LTM configuration. For example, the source cell may have already transmitted and coordinated SRS transmission probabilities and related parameters to the LTM target candidate, which can be intra-DU or inter-DU exchange. Here, the LTM target candidate can (e.g., will) identify RS (e.g., SRS) transmissions from the UE and can register that the UE has already performed LTM switching locally.

[0491] PUCCH-based instructions In some representative embodiments, when an LTM switch is performed to a target LTM candidate, the UE can be configured to perform a PUCCH transmission to the target LTM candidate. The configuration of the PUCCH transmission (e.g., including PUCCH format allocation, sequence allocation, and / or PUCCH time-frequency resources) can be specific to the target LTM candidate. Here, the configured PUCCH transmission can (e.g., indicate to the LTM target that the UE has performed an LTM switch).

[0492] For example, the UE can be configured to send a transmission scheduling request (SR) to an LTM target candidate via a configured PUCCH resource. For example, the transmission can be limited to short PUCCHs (e.g., sequence-based PUCCH format 0 transmission).

[0493] LTM program based on combined radio and non-radio measurements In some representative embodiments, as part of an LTM procedure based on joint radio and non-radio measurements, the UE may perform any (e.g., all) of the following steps or actions. For example, it can be assumed that the UE begins the LTM procedure from the RRC_Connected state.

[0494] For example, the UE can send capability information and related auxiliary information related to low-level mobility / LTM (LTM) handling. For instance, the capability information may be accompanied by measurement report information associated with a set of radio and / or non-radio measurements. Along with (e.g., in a suitable format) LTM-related capability information, the UE can also provide mobility assistance information to the network.

[0495] For example, the UE may receive coverage and / or deployment topology information and / or its related configuration.

[0496] For example, a UE may receive LTM configuration information, which may include one or more LTM configurations, appropriate LTM radio and / or non-radio measurements, and / or one or more events for reporting purposes.

[0497] For example, the UE can perform configured radio and / or non-radio measurements, such as location and / or orientation information.

[0498] For example, a UE can detect changes in radio and / or non-radio measurements (e.g., based on their measurements).

[0499] For example, a UE can determine its (e.g., current) zone based on (e.g., non-radio) measurements.

[0500] For example, the UE can use conditions set on radio and non-radio quantity measurements to evaluate configured events.

[0501] For example, in the event-triggered case, the UE can perform event-based UE reporting of its area, location / position, and radio measurements according to its configuration.

[0502] For example, a UE can receive network commands to perform LTM mobility switching, where the network can use UE reports of radio and non-radio measurements and other system-level aspects to determine the appropriate target cell / beam configuration for the UE.

[0503] For example, a UE can perform LTM mobility switching based on network commands.

[0504] Figure 13 This document illustrates various embodiments and examples related to the low-level mobility procedures described herein, in which the UE assists mobility by reporting radio and non-radio measurements. Black text in all blocks indicates UE actions, while blue text provides UE status, or additional details and auxiliary information related to the UE actions in the associated blocks. For a UE in the RRC_CONNECTED state, the procedure begins with the UE providing its ability to handle different aspects of the low-level mobility procedures. This capability can be grouped in an appropriate format, covering different aspects such as handling intra-DU, inter-DU configurations and mobility handling, the maximum number of configurations the UE can configure, and the number of intra-frequency and inter-frequency measurements the UE can perform. More details are available regarding the UE capabilities for LTM procedures. Along with LTM-related capabilities in an appropriate format, the UE can also provide mobility assistance information. This information may include appropriate measurements and the ability to perform various non-radio measurements. The set of measurements sent to the network for the network to prepare appropriate mobility configurations can be low-level measurements, traditional L3 measurements, or a combination thereof.

[0505] After receiving capability and mobility assistance information, the network can provide coverage information to the UE. Coverage information is an appropriate snapshot of the network deployment near the UE's location. Coverage information is provided to the UE at an appropriate granularity based on the assistance information and the QoS / QoE requirements of the services the UE is using or intends to use. This document provides details on coverage information configuration and appropriate granularity.

[0506] In addition to coverage configuration, the network also provides the UE with appropriate low-layer mobility configurations. Low-layer mobility configurations, or LTM configurations, can include several candidate configurations. These configurations can be provided as serving cell configurations, cell group configurations, or larger RRC reconfiguration messages. Furthermore, these candidate configurations can be provided as individual configurations or incremental configurations relative to a suitable reference configuration. The suitable reference configuration can be configured as the serving cell configuration or provided as an independent configuration. Different configuration messages and styles for LTM target configurations are proposed. A suitable subset of LTM candidate configurations can be marked as active or enabled by the network, while other subsets can be considered deactivated. The UE will monitor active candidates for potential LTM switching.

[0507] One of the key inventive steps in this disclosure is that the network configures appropriate radio and non-radio measurements and associated reports for the UE as part of the LTM configuration step. This document discusses the low-layer LTM measurement framework, appropriate radio and non-radio measurements, filtering, events, and reporting conditions / triggers. After receiving the appropriate LTM configuration, the UE will monitor the configured radio and non-radio measurements periodically, semi-persistently, non-periodically, or event-triggered, according to the received configuration.

[0508] When a UE estimates degradation of the current serving link, where link / beam quality degradation determination is part of the configuration itself, the UE estimates its current location, position, and orientation. Additional non-radio measurements may be configured via local sensors at the UE device or information received through different interfaces. Link quality degradation detection can be configured on beam-based or cell-based signals. The thresholds configured for degradation determination differ from traditional beam failure detection or radio link failure detection because the purpose here is to run the procedure before a beam or link failure occurs. In a compatible design, the UE can be configured to periodically perform non-radio measurements without any explicit determination of link quality degradation.

[0509] After obtaining an updated estimate of its non-radio measurements based on location / position and orientation, the UE determines its current area based on coverage information provided by the network. The parameters and constants that derive the area information as a function of one or more of the non-radio measurements of location, position, and orientation are part of the coverage configuration.

[0510] After measuring the configured radio and non-radio measurements, the UE will evaluate the conditions set to trigger a measurement report. If the conditions are met, the UE will proceed to the next step of reporting the configured measurements.

[0511] In this step, the UE will transmit reports of configured radio and non-radio measurements for LTM measurements that meet the reporting event conditions. If the reporting conditions for event-based reporting are not met, the UE will not send the corresponding event-based report and will continue monitoring the quantity according to the configured period. LTM measurement reports can be periodic. In this case, the UE can send measurement reports according to the period for which it should transmit measurement reports or the expiration of a timer. In a compatible design not shown in this flowchart, reports can be non-periodic and may have already been triggered by a suitable mechanism such as an RRC command or PDCCH sequence via DCI transmission.

[0512] Once the UE has determined that a report is required, it will send non-radio measurements to the network according to the configured reporting settings, such as its determined area, location, position, orientation, and other radio measurements.

[0513] UE reports of both radio and non-radio measurements allow the network to select an appropriate LTM candidate from a previously configured pool of candidates, in an active or enabled state. Although not shown in the flowchart, the network can update the LTM configuration using updated measurement reports received from the UE. The network can also choose not to perform LTM switching.

[0514] If the network chooses to switch cells for the UE via an LTM procedure, the UE receives a network command to perform an LTM switch. The LTM switch command includes an indication of the target LTM candidate configuration. In addition to the target LTM candidate configuration, the network command for the LTM switch may indicate UE behavior for MAC / RLC reset and the type of UL indication the UE will transmit after the LTM switch event.

[0515] After receiving the LTM candidate configuration for performing the switch, the UE will perform an LTM switch on the target candidate. This switch may include handling MAC and RLC entities locally within the UE. In one design, an instruction to reset MAC / RLC entities can be explicitly provided to the UE as part of the LTM configuration candidate, and the UE performs the MAC and / or RLC entity resets according to the configuration of the selected LTM candidate. In another design, the UE can derive this information based on whether the LTM target candidate involves intra-DU or inter-DU switching, and by performing a pre-configured MAC / RLC reset action for each intra-DU or inter-DU switching scenario. In yet another design, MAC / RLC reset handling can be instructed as part of an LTM switch command. Details regarding MAC / RLC resets and different intra-DU / inter-DU scenarios are provided.

[0516] Another part of LTM switching involves providing the network with an indication that the UE will perform the LTM switch. This is necessary so that both the UE and the network have a common field of view to communicate with each other after the LTM switch without any interruption. The UE transmits 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 resources in which the indication is transmitted are part of the LTM configuration itself. In a compatible design, the UE selects the UL LTM switch indication received in the network command to perform the LTM switch. Details regarding the UL indication after the LTM switch are provided.

[0517] It is important to emphasize the following: conventional radio measurements can require significant time for estimation, filtering, and reporting, which is unacceptable for maintaining service continuity to achieve mobility in densely deployed narrow-beam systems. Therefore, the proposed strategy of jointly basing low-level mobility decisions on both radio and non-radio measurements offers a greater latency advantage, which may be impractical for procedures operating solely on either radio or non-radio measurements. Consequently, the proposed procedure delivers significant benefits in terms of service continuity, mobility, and reduced downtime compared to conventional methods.

[0518] General framework and implementation examples Based on Figure 13This describes a current embodiment of an L1 / L2 triggered mobility procedure. This procedure can begin for a UE in an RRC connected state. The UE can provide capability information related to its low-level mobility / LTM disposition, along with additional ancillary information. This step may be accompanied by a report of a set of radio and non-radio measurements. The transmission of capability and ancillary information can be triggered by the UE itself, for example, when its radio or non-radio measurements indicate some degradation in coverage, or when the UE is running or starting to run an application that requires low mobility interruption. In another design, the network can trigger the UE to transmit capability and ancillary information by sending an explicit request to the UE. For example, the network request can be sent as an RRC message. After receiving the UE's capability and ancillary information, the network can provide the UE with coverage and deployment topology in a suitable format. This information can be provided as UE-specific signaling or system information broadcast signaling. In another design, basic coverage information can be transmitted as a system information broadcast and then refined in UE-specific signaling. The network then provides the UE with LTM configuration, appropriate LTM radio and non-radio measurements, and appropriate events for reporting purposes. The network can transmit coverage information and LTM configuration simultaneously or in any order. Once the network is configured, the UE begins measuring and monitoring the configured radio and non-radio measurements. In some cases, there may be an additional activation step for measuring the configuration, based on which the UE will begin measuring and monitoring the configured quantities. If the UE detects a change in its radio or non-radio measurements, it can move to the next step of refreshing the measurement and evaluation reporting conditions. The UE can estimate its radio and non-radio measurements, allowing it to determine its area based on the coverage topology configuration provided by the network. For event-based LTM measurement configurations, the UE uses measurements according to the configured or standardized measurement model, where the measurements can be L1, L3, combined quantities, or bias quantities. After estimating the radio and non-radio measurements, the UE evaluates the conditions set as event triggering conditions for measurement reporting. If the conditions are met (resulting in the triggering of the event in question), the UE will continue to report the measurement back to the network for a report of the triggering event. The UE will report the radio and non-radio measurements configured as part of the measurement configuration to the network. The reports received at the UE allow the network to select the appropriate next step. The network can choose to move the UE from its current serving cell to one of the LTM cell configurations that it has obtained visibility from the UE measurement reports and that is active. If the network decides to change the UE's serving cell to one of the LTM candidate cells, it sends an LTM cell switching command to the UE. Once the UE receives the network command to perform LTM mobility switching, whereby the network can use the radio and non-radio measurements reported by the UE, as well as other system-level aspects, to determine a suitable target cell / beam configuration for the UE, the UE will perform mobility switching to the target cell configuration commanded by the network.

[0519] LTM switching commands include indications of the target LTM candidate configuration. In addition to the target LTM candidate configuration, the network commands for LTM switching can indicate UE behavior for MAC / RLC reset and the type of UL indication that the UE will transmit after the LTM switching event.

[0520] After receiving an LTM candidate configuration to perform a switch, the UE will perform an LTM switch to the target candidate. This switch may include local handling of MAC and RLC entities at the UE. In one design, an instruction to reset MAC / RLC entities can be explicitly provided to the UE as part of the LTM configuration candidate, and the UE performs the MAC and / or RLC entity resets according to the configuration of the selected LTM candidate. In another design, the UE can derive this information based on whether the LTM target candidate involves intra-DU or inter-DU switching, and by performing a pre-configured MAC / RLC reset action for each intra-DU or inter-DU switching scenario. In yet another design, MAC / RLC reset handling can be instructed as part of an LTM switch command. Details regarding MAC / RLC resets and different intra-DU / inter-DU scenarios are provided below.

[0521] Another part of LTM switching involves providing the network with an indication that the UE will perform the LTM switch. This is necessary to ensure that the UE and the network have a shared understanding that they can communicate with each other without any interruption after the LTM switch. The UE transmits 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 resources in which the indication is transmitted are part of the LTM configuration itself. In a compatible design, the UE selects the UL LTM switch indication received in the network command to perform the LTM switch. Details regarding the UL indication after the LTM switch are provided below.

[0522] LTM procedures based on joint radio and non-radio signals (location and orientation) without network deployment information In this embodiment, the UE is provided with a region-determined configuration, but not with network deployment information. The UE uses non-radio signals (particularly location and orientation information) combined with 3GPP radio measurements to trigger a low-level report to the network. This report informs the network of the appropriate cell and beam for the UE, for which it issues a cell-switching command to the UE.

[0523] UE capability transfer and related ancillary information for low-level mobility / LTM handling support LTM procedures based on radio and non-radio measurements.

[0524] The UE can receive this configuration to determine area information and orientation-specific parameters and references (e.g., reference TRP selection).

[0525] The UE can receive LTM configuration along with appropriate LTM radio and non-radio measurements and suitable events for reporting the intended setup on the combined configured measurements. In this embodiment, non-radio measurements and events on area entry (LTM-CM2) and orientation matching a given TRP (LTM-OT1) are combined with radio signal measurements. The network can configure the UE with events capturing radio and non-radio measurements. The network configuration can indicate joint events, such as LTM-J1, LTM-J2, ...LTM-J5. In an alternative design, the network can configure a set of separate events, such as LTM-CM2O1 for non-radio measurements and LTM-A3 / LTM-A4 for radio measurements. This configuration can indicate that triggering these events will trigger a UE report.

[0526] Depending on the periodicity of the configuration, the UE can perform configured radio and non-radio measurements at its location and orientation.

[0527] The UE can detect changes in non-radio or radio measurements.

[0528] The UE can determine its area through non-radio measurements.

[0529] The UE can use conditions set in terms of location and orientation to evaluate configured events.

[0530] When a UE enters a specific area and an event triggers that matches the orientation of a given TRP according to the configuration, the event-based UE reports its area, location / position, and configured radio measurements according to the configuration.

[0531] The UE can receive network commands to perform LTM mobility switching, where the network can use UE reports and other system-level aspects to determine the appropriate target cell / beam configuration for the UE.

[0532] The UE can perform LTM mobility switching according to network commands.

[0533] The UE can perform protocol stack processing based on network indications in dynamic signaling or a portion of the LTM configuration.

[0534] The UE can transmit UL indications according to network configuration / instructions, whereby the network can instruct the transmission of RS- or PUCCH-based indications via LTM exchange commands or via prior configuration.

[0535] LTM based on radio and non-radio measurements, with UE autonomous activation based on UE-determined area-determined measurement configuration. In this embodiment, the UE is provided with a zone-determined configuration, but not with network deployment information. The UE determines its zone using its location information based on the network configuration. As part of the LTM procedure, the network configures the UE with appropriate LTM candidates. To reduce measurement and tracking overhead associated with LTM candidate tracking / synchronization, LTM measurements are mapped to relevant zones. Therefore, these measurements only need to be estimated and reported when the UE determines it is in these zones. This provides the UE with a selection mechanism to activate the appropriate set of measurement configurations. Thus, upon entering a specific location / zone, the UE activates the relevant measurement configuration. This activation causes the UE to track radio and non-radio measurements as part of these active measurement configurations. These measurements can then lead the UE to report to the network based on reporting and triggering of these measurements.

[0536] UE capability transfer and related ancillary information for low-level mobility / LTM handling support LTM procedures based on radio and non-radio measurements.

[0537] The UE receives configuration and appropriate parameters to determine the area information.

[0538] The UE receives the LTM configuration of the candidate cell.

[0539] The UE receives LTM-related measurement configurations. These configurations include definitions and parameters of radio and non-radio measurements associated with LTM candidate configurations. Furthermore, the measurement configurations provide association information with certain areas where these measurement configurations are activated and require estimation / monitoring / tracking. Measurements can be part of the `measConfig` in `RRCreconfiguration` or through new information elements specifically designed for LTM procedures. The association of a measurement configuration with an area can be achieved by explicitly providing a set of area identifiers where the measurement configuration is activated, or this information can be provided in a different information element.

[0540] The UE performs configured non-radio measurements at its location according to the configured periodicity.

[0541] The UE detects changes in non-radio or radio measurements.

[0542] The UE determines its area through non-radio measurements.

[0543] When the UE region changes, the UE activates a measurement configuration that is set to be active in the new region. The UE deactivates measurement configurations that are not set to be active in the new region.

[0544] The UE estimates the radio and non-radio measurements associated with the activated measurement configuration.

[0545] The UE uses conditions set on radio and non-radio quantity measurements to evaluate configured radio and non-radio events.

[0546] When an event is triggered, the event-based UE reports its district, location / position, and radio measurements according to its configuration.

[0547] The UE receives network commands to perform LTM mobility switching, where the network can use UE reports and other system-level aspects to determine the appropriate target cell / beam configuration for the UE.

[0548] The UE performs LTM mobility switching according to network commands.

[0549] The UE performs protocol stack processing based on network instructions in dynamic signaling or as part of the LTM configuration.

[0550] The UE transmits UL indications according to network configuration / instructions, whereby the network may instruct the transmission of RS-based or PUCCH-based indications via LTM exchange commands or via prior configuration.

[0551] LTM based on radio and non-radio measurements, where the processing of radio measurements [e.g., filter duration, coefficients] depends on the non-radio measurements. In this embodiment, the UE is provided with a zone-determined configuration, but not with network deployment information. Based on the network configuration, the UE uses its location information to determine its zone and orientation relative to a reference TRP.

[0552] In this embodiment, the UE is configured with non-radio events related to the UE's location entering a specific area, and / or the UE's distance from a reference TRP, and / or the UE's orientation relative to the reference TRP. If these quantities fall within a first set of configured thresholds, the UE measures the radio quantities and processes them with a first set of periods, filter durations, and coefficients, etc. Similarly, if the non-radio measurements meet a second set of thresholds, the second set of radio measurement processing is used. This sub-selection can be extended to a larger granularity. If the non-radio quantities do not meet any configured threshold set, the UE can be configured not to perform the associated radio measurements. A brief overview of this embodiment is as follows: UE measures and evaluates non-radio quantities; Non-radio measurements meet the first set of thresholds - the UE applies the first set of parameters to measure and process radio measurements; Non-radio measurements meet the second set of thresholds - the UE applies the second set of parameters to measure and process radio measurements; and / or If non-radio measurements do not meet the first or second set of thresholds, the UE will not measure and track radio measurements.

[0553] This embodiment illustrates the application of sub-selection to radio measurements using non-radio measurements, and the selection of appropriate processing for radio measurements.

[0554] LTM based on joint events of radio and non-radio signals and network deployment information UE capability transfer and related ancillary information for low-level mobility / LTM handling are based on joint radio and non-radio measurements to support LTM procedures.

[0555] The UE receives coverage and deployment topology, as well as related configurations, from the network.

[0556] The UE receives the LTM configuration, along with appropriate LTM radio and / or non-radio measurements and suitable joint events set for reporting purposes through a combination of radio and non-radio measurements. As part of the configuration, the network may indicate any of the proposed joint events (e.g., LTM-J1 to LTM-J6).

[0557] The UE performs configured radio and non-radio measurements.

[0558] The UE detects changes in non-radio and radio measurements.

[0559] The UE determines its area through non-radio measurements.

[0560] The UE uses conditions set on radio and non-radio quantity measurements to evaluate the configured joint events.

[0561] When an event is triggered, the event-based UE reports its district, location / position, and radio measurements according to its configuration.

[0562] The UE receives network commands to perform LTM mobility switching, whereby the network can use radio and non-radio measurements reported by the UE, as well as other system-level aspects, to determine the appropriate target cell / beam configuration for the UE.

[0563] The UE performs LTM mobility switching according to network commands.

[0564] The UE performs protocol stack processing based on network instructions in dynamic signaling or as part of the LTM configuration.

[0565] The UE transmits UL indications according to network configuration / instructions, whereby the network may instruct the transmission of RS-based or PUCCH-based indications via LTM exchange commands or via prior configuration.

[0566] LTM based on periodic reports of radio and non-radio signals UE capability transfer and related ancillary information for low-level mobility / LTM handling are based on joint radio and non-radio measurements to support LTM procedures.

[0567] The UE receives coverage and deployment topology and related configurations.

[0568] The UE receives LTM configuration, as well as appropriate LTM radio and non-radio measurements and appropriate periodic reporting configuration.

[0569] The UE performs configured radio and non-radio measurements.

[0570] The UE determines its area through non-radio measurements.

[0571] When the timer expires, the UE reports non-radio measurements based on its configuration, such as its area, location / position, and radio measurements.

[0572] Upon receiving a UE measurement report, the network compares radio and non-radio measurements with thresholds and previous measurements.

[0573] The network can select one of the appropriate LTM configurations to activate based on UE reports and other system-level considerations.

[0574] The UE receives network commands to perform LTM mobility switching, where the network can use UE reports and other system-level aspects to determine the appropriate target cell / beam configuration for the UE.

[0575] The UE performs LTM mobility switching according to network commands.

[0576] The UE performs protocol stack processing based on network instructions in dynamic signaling or as part of the LTM configuration.

[0577] The UE transmits UL indications according to network configuration / instructions, whereby the network may instruct the transmission of RS-based or PUCCH-based indications via LTM exchange commands or via prior configuration.

[0578] Activate LTM candidate configuration based on UE report The current embodiment proposes network control activation and deactivation for a suitable LTM candidate configuration. As part of the configuration, the network provides coverage topology information, as well as parameters related to deriving UE area information. The network also provides necessary measurement information, which allows the UE to derive its area information. Area information can be derived from location information obtained by the UE from local GNSS measurements. This can be done using a local GNSS receiver. Location information can be derived or its accuracy improved through other 3GPP-based or non-3GPP-based measurements. The UE has prior notification to the network of its ability to perform non-3GPP radio and non-radio measurements.

[0579] The network provides the UE with LTM candidate configurations. These candidate configurations include cell configurations, as well as events and conditions for radio and non-radio measurements, which the UE will evaluate and use to report these measurements.

[0580] The UE will closely monitor the active L1 / L2 configurations and report them to the network. Therefore, activating the appropriate configuration is crucial for L1 / L2 mobility. The network can configure the UE to periodically estimate certain radio and non-radio measurements, such as its location. Based on the location estimation, the UE derives its area information according to the coverage topology configuration. The UE is configured to report the configured measurement and area information to the network. The reporting frequency can be configured according to UE mobility and QoS requirements. To reduce reporting overhead, UE reporting can be event-based and only reported if the area estimated by the UE differs from the previous area. UE reports can be transmitted to the network as part of the UCI. A new MAC-CE can be designed to provide this information. Once updated measurement and area information is received, the network can update the set of active LTM configurations. The network can send an "LTM Configuration Activation" MAC-CE, which can activate the appropriate LTM configuration. Two different MAC-CEs can be designed to accommodate different numbers of LTM configurations that may need to be activated for the final LTM procedure. For this purpose, a custom MAC-CE can be designed where the identifier of the LTM configuration provides a pointer to the LTM configuration configured via RRC signaling. One design for activating MAC-CE could be bitmap-based, where the network can indicate the activation status of each configured LTM configuration. For a more reactive approach, PHY-based signaling (e.g., DCI) could be used to activate one of the configured LTM configurations.

[0581] Therefore, this scheme offers significant advantages in reducing resource overhead and latency. The UE will continue to perform configuration radio and non-radio measurements only for the appropriate LTM configuration corresponding to the location of its active configuration selected by the network. This eliminates the need for the UE to perform unnecessary measurements for candidate configurations that are no longer suitable for its updated location.

[0582] The current embodiment is shown as Figure 14 The flowchart in the document, and it uses one or more of the following operations.

[0583] UE capability transfer and related ancillary information for low-level mobility / LTM handling are based on joint radio and non-radio measurements to support LTM procedures.

[0584] The UE receives coverage and deployment topology and related configurations.

[0585] The UE receives the LTM configuration, along with appropriate LTM radio and non-radio measurements and suitable joint events for reporting. As part of the configuration / initialization, a subset of the LTM configuration can be indicated as activated by the network. The UE can be configured with an additional set of periodic measurements to aid in the activation / deactivation configuration. These measurements can be a combination of radio and non-radio measurements, with particular focus on UE area information.

[0586] The UE performs radio and non-radio measurements associated with the activated LTM configuration.

[0587] The UE performs configuration measurements for the purpose of configuration activation / deactivation.

[0588] The UE determines its area through non-radio measurements.

[0589] If the newly determined area differs from the previous area, the UE transmits the configured measurement UL report and its newly estimated area information to the network. The UE receives network updates to the coverage topology. The UE receives an updated list of activated and deactivated LTM configurations. The network can add or remove some of the configured LTM candidates. The UE updates the activation status of the configured LTM candidates, thereby updating the status according to network instructions.

[0590] LTM based on potential target configuration candidates reported by UE The current embodiment proposes a network-controlled LTM switching procedure in which the UE performs radio and non-radio measurements and assists LTM switching by providing the network with an indication of an appropriate LTM target configuration. The selection of an appropriate LTM target configuration is performed by the UE according to the network configuration by tracking, measuring, and evaluating radio and non-radio signals.

[0591] As part of the proposed procedure configuration, the network provides coverage topology information, as well as parameters related to deriving UE area information. The network also provides necessary measurement information, which allows the UE to derive its area information. Area information can be derived from location information obtained by the UE from local GNSS measurements. This can be done using a local GNSS receiver. Location information can be derived or its accuracy improved through other 3GPP-based or non-3GPP-based measurements. The UE has prior notification to the network of its ability to perform non-3GPP radio and non-radio measurements.

[0592] The network uses a set of LTM candidate configurations to configure the UE. These candidate configurations include cell configurations. The network configuration also provides events and conditions on radio and non-radio measurements that the UE will measure and evaluate. The triggering of a configuration event indicates that an LTM candidate configuration meets selection criteria; therefore, the UE reports the indication of the LTM candidate configuration to the network that triggered the event. The UE can be configured to provide the network with periodic reports on configuration measurements for the active configuration. To reduce reporting overhead, UE reports can be event-based and reported only if at least one of the active configurations meets the selection criteria. UE reports can be transmitted to the network as part of the UCI via resources configured for the UCI. This can be achieved by defining the configuration indication as part of the UCI. In a compatible design, a new MAC-CE can be designed to provide this information. Two MAC CEs can be designed. A short MAC-CE can only provide the selected configuration identifier to the network where the selection event was triggered. A long MAC-CE can provide the configuration identifier with other relevant measurements. Once the network receives indications of candidate configurations that meet the selection criteria, along with possible other radio and non-radio measurements, from the UE, it can select a suitable LTM candidate target. The network selection for the target configuration can be combined with other system-level aspects, such as load balancing, cell capabilities, and other aspects that may not be visible to the UE. The network sends LTM switching commands to the UE using other relevant switching parameters as described above. The UE performs LTM switching according to the configuration and the network switching commands sent by the network to the target.

[0593] The current embodiment is shown as Figure 15 The flowchart in the document, and it uses one or more of the following operations.

[0594] UE capabilities can be transferred to lower-layer mobility / LTM handling and related ancillary information to support LTM procedures based on joint radio and non-radio measurements.

[0595] The UE receives coverage and deployment topology, as well as related configurations, from the network.

[0596] The UE receives the LTM configuration, along with appropriate LTM radio and non-radio measurements and suitable joint events for configuration selection purposes, using a combination of radio and non-radio measurements. The network may indicate any of the proposed joint events (e.g., LTM-J1 to LTM-J6) as part of a configuration with appropriate parameters and thresholds for selecting candidate configurations.

[0597] The UE performs configured radio and non-radio measurements.

[0598] The UE detects changes in non-radio and radio measurements.

[0599] The UE determines its area through non-radio measurements.

[0600] The UE uses the conditions set for the radio and non-radio signal measurement settings for the active LTM configuration candidate to evaluate the joint events of the configuration.

[0601] If an event associated with configuration selection is triggered for at least one of the active configuration candidates, the UE selects the associated configuration candidate for network reporting. The UE transmits the UL indication of the selected configuration candidate.

[0602] The UE receives a network command to perform LTM mobility switching to a target candidate, where the target indicated by the network may be the same as or different from the target selected by the UE.

[0603] The UE performs protocol stack processing based on network instructions in dynamic signaling or as part of the LTM configuration.

[0604] The UE transmits UL indications according to network configuration / instructions, whereby the network may instruct the transmission of RS-based or PUCCH-based indications via LTM exchange commands or via prior configuration.

[0605] The above embodiments may include one or more of the following operations.

[0606] When more than one candidate configuration triggers a selection event, the UE selects the highest priority configuration for UL indication to the network, where the priority indication can be part of the LTM candidate configuration.

[0607] When more than one candidate configuration triggers a selection event, the UE selects a candidate configuration from its current DU, where DU information can be provided as part of the candidate configuration for LTM configuration.

[0608] In the event that a selection event is triggered by more than one candidate configuration, the UE provides N successful candidates as part of the UL indication, where N is part of the network configuration.

[0609] LTM based on UE's target configuration candidate transmission UL indication The current embodiment proposes a network-controlled LTM switching procedure in which the UE performs radio and non-radio measurements and assists LTM switching by providing indications of a suitable LTM target configuration. The selection of a suitable LTM target configuration is performed by the UE by tracking, measuring, and evaluating radio and non-radio quantities according to the network configuration. A key aspect of this embodiment is that the UE is configured with transmission parameters for candidate configurations such that indications associated with a selected candidate are transmitted through the resources of that candidate. Signaling to ...

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: It transmits information indicating the ability to measure radio and non-radio quantities associated with one or more rotational or translational movements; Receive configuration information, which indicates 1) a zone configuration for determining the zone based on radio and / or non-radio measurements, and / or 2) a set of mobility configurations associated with radio and / or non-radio measurements and a set of joint events; Based on the configuration information, estimate one or more radio and / or non-radio measurements; and Based on the joint events triggered in this set of joint events, a measurement report is transmitted, which indicates 1) radio and / or non-radio measurements, and 2) area information derived from the estimated non-radio measurements.

2. The method according to claim 1, further comprising: Receive instructions for mobility exchange using the target candidate configuration.

3. The method according to claim 2, further comprising: Mobility switching to the network is performed based on the instructions.

4. The method according to any one of claims 1-3, further comprising: The current zone of the WTRU is determined based on the second set of non-radio measurements; and The current area based on WTRU selects at least one of a set of L1 / L2 triggered mobility (LTM) configurations. The first set of radio and non-radio measurements is performed based on at least one LTM configuration, and mobility switching is performed based on at least one LTM configuration.

5. The method according to any one of claims 1-4, further comprising: Perform radio and / or non-radio measurements.

6. The method according to any one of claims 1-5, further comprising: Detect changes in radio and / or non-radio measurements.

7. The method according to any one of claims 1-6, further comprising: The area is determined by non-radio measurements.

8. The method according to any one of claims 1-7, further comprising: The coverage area is derived from the coverage topology using non-radio measurement estimation.

9. The method according to any one of claims 1-8, further comprising: The combined events in radio and non-radio quantities are evaluated using one or more estimated radio and / or non-radio measurements.

10. A wireless transmit / receive unit (WTRU) including circuitry, the circuitry comprising a transmitter, a receiver, a processor, and a memory, the WTRU being configured to: It transmits information indicating the ability to measure radio and non-radio quantities associated with one or more rotational or translational movements; Receive configuration information, which indicates 1) a zone configuration for determining the zone based on radio and / or non-radio measurements, and / or 2) a set of mobility configurations associated with radio and / or non-radio measurements and a set of joint events; Based on the configuration information, estimate one or more radio and / or non-radio measurements; and Based on the joint events triggered in this set of joint events, a measurement report is transmitted, which indicates 1) radio and / or non-radio measurements, and 2) area information derived from the estimated non-radio measurements.

11. The WTRU of claim 10, wherein the WTRU is further configured to: Receive instructions for mobility exchange using the target candidate configuration.

12. The WTRU of claim 11, wherein the WTRU is further configured to: Mobility switching to the network is performed based on the instructions.

13. The WTRU of claim 10, wherein the WTRU is further configured to: The current zone of the WTRU is determined based on the second set of non-radio measurements; and The current area based on WTRU selects at least one of a set of L1 / L2 triggered mobility (LTM) configurations. The first set of radio and non-radio measurements is performed based on at least one LTM configuration, and mobility switching is performed based on at least one LTM configuration.

14. The WTRU of claim 10, wherein the WTRU is further configured to: Perform radio and / or non-radio measurements.

15. The WTRU of claim 10, wherein the WTRU is further configured to: Detect changes in radio and / or non-radio measurements.

16. The WTRU of claim 10, wherein the WTRU is further configured to: The area is determined by non-radio measurements.

17. The WTRU of claim 10, wherein the WTRU is further configured to: The coverage area is derived from the coverage topology using non-radio measurement estimation.

18. The WTRU of claim 10, wherein the WTRU is further configured to: The combined events in radio and non-radio quantities are evaluated using one or more estimated radio and / or non-radio measurements.

Images