Adjustable low layer triggered mobility switch execution window

By introducing a low-level triggered mobility mechanism and AI model to optimize handover conditions, the problems of inter-cell beam management and mobility latency in carrier aggregation scenarios are solved, achieving a more efficient handover process and network adaptability.

CN121533080APending Publication Date: 2026-02-13INTERDIGITAL PATENT HOLDINGS INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202480047214.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-08-02
Filing Date
2024-08-02
Publication Date
2026-02-13

AI Technical Summary

Technical Problem

Existing technologies have failed to effectively support inter-cell beam management and mobility delay optimization in carrier aggregation scenarios, especially in the L1/L2 layer handover process, where they suffer from inefficiency.

Method used

A low-layer triggered mobility (LTM) mechanism is introduced, which indicates the handover window length through configuration information and MAC control elements. Combined with artificial intelligence (AI) models, handover conditions are optimized to achieve dynamic candidate cell selection and handover preparation, including CSI reporting, HARQ feedback, and timed advance management, in order to improve handover efficiency.

Benefits of technology

It reduces inter-cell mobility latency, improves the efficiency and flexibility of handover processes, optimizes radio resource allocation, and enhances network adaptability and stability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121533080A_ABST
    Figure CN121533080A_ABST
Patent Text Reader

Abstract

A wireless transmit / receive unit (WTRU) may receive configuration information. The configuration information may include an indication of a first low layer triggered mobility (LTM) configuration associated with one or more candidate cells. The LTM configuration may indicate a radio resource configuration to be applied when performing a handover to a candidate cell of the plurality of candidate cells. The WTRU may receive an indication that the handover to the candidate cell of the plurality of candidate cells is to be performed. The indication may include a first duration window. The WTRU may determine a second duration window based at least on the first duration window and one or more conditions. The second window of duration may be a subset of the first window of duration. The WTRU may transmit information indicating the second duration window and / or the one or more conditions for determining the second duration window.
Need to check novelty before this filing date? Find Prior Art

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. Provisional Patent Application 63 / 517,254, filed August 2, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Inter-cell beam management can manage one or more beams in carrier aggregation (CA) scenarios, but may not support cell changes / additions.

[0003] One objective of the work project “Further NR Mobility Enhancements” may include developing one or more mechanisms and / or procedures for inter-cell mobility based on L1 / L2 to reduce mobility latency. Developing mechanisms (one or more) and / or procedures (one or more) for L1 / L2-based inter-cell mobility to reduce mobility latency may include one or more of the following: configuration and / or maintenance for one or more (e.g., multiple) candidate cells to enable rapid application of candidate cell configurations (e.g., [RAN2, RAN3]); dynamic handover mechanisms based on L1 / L2 signaling for potential applicable scenarios between candidate serving cells (e.g., including special cells (SpCell) and / or secondary cells (SCell)) (e.g., [RAN2, RAN1]); L1 enhancements for inter-cell beam management, including L1 measurement and reporting, and / or beam indication (e.g., [RAN1, RAN2]); advance timing management (e.g., [RAN1, RAN2]); and / or centralized cell (CU) - distributed cell (DU) interface signaling to support L1 / L2 mobility (e.g., [RAN3] if needed). For example, regarding advance timing management (e.g., including further clarification of the possibility of interaction between advance timing management and L1 enhancements for inter-cell beam management), RAN2 involvement (e.g., early RAN2 involvement) may be included. Frequency range 2 (FR2) specific enhancements may not be excluded (e.g., if any).

[0004] The L1 / L2-based inter-cell mobility process can be applied to the following scenarios: standalone, CA, and NR dual connectivity (DC) scenarios that support serving cell changes within a configured license (CG); intra-DU scenarios and / or intra-CU and inter-DU scenarios (e.g., applicable to standalone and CA scenarios: no new RAN interface is expected); co-frequency and inter-frequency; frequency range 1 (FR1) and FR2; source and / or target cells can be synchronous or asynchronous; and / or may not include inter-CU scenarios. Summary of the Invention

[0005] The Wireless Transmit / Receive Unit (WTRU) can receive configuration information. This configuration information may include lower-layer triggered mobility (LTM) candidates and / or a set of first handover (HO) window lengths. The WTRU can send Channel State Information (CSI) reports to the first cell. The WTRU can receive LTM cell handover medium access control (MAC) elements (CEs). The MAC CE may include an indication of the first window time position and / or an indication of the configured first HO window length set. The WTRU can perform one or more LTM preparation actions. One or more LTM preparation actions may include the WTRU stopping CSI reporting. The WTRU can determine a second window for triggering LTM. The WTRU may, for example, send an indication to the second cell at the determined cell handover time.

[0006] The WTRU can receive configuration information from the network equipment via a first cell. The configuration information may include an indication of a first low-layer triggered mobility (LTM) configuration associated with one or more candidate cells. The LTM configuration may indicate the radio resource configuration to be applied when performing a handover to a candidate cell among the multiple candidate cells. The WTRU can also receive an indication from the network equipment via the first cell for performing a handover (HO) to a candidate cell among the multiple candidate cells. This indication may include a first duration window (e.g., a first LTM HO window). The WTRU may determine a second duration window (e.g., a second LTM HO window) based, for example, at least on the first duration window (e.g., the first LTM HO window) and / or one or more conditions. The second duration window (e.g., the second LTM HO window) may be a subset of the first duration window (e.g., the first LTM HO window). The first duration window (e.g., the first LTM HO window) may be longer than the second duration window (e.g., the second LTM HO window). The second duration window (e.g., the second LTM HO window) may include a start time, duration, and / or end time. The WTRU may send to the network an indication of a second duration window (e.g., a second LTM HO window) and / or an indication of one or more conditions for determining the second duration window (e.g., a second LTM HO window). This indication may be received via a Media Access Control (MAC) element (CE). Cell handover may occur at the end of the second duration window (e.g., the second LTM HO window).

[0007] The WTRU can perform handover based on radio resource configuration. The WTRU can perform LTM preparation during the beginning of a first duration window (e.g., a first LTM HO window). Performing LTM preparation during the first LTM HO window may include one or more of the following: disabling Channel State Information (CSI) reports; transmitting Hybrid Automatic Repeat Request (HARQ) feedback; performing (e.g., early) Timing Advance (TA) acquisition; and / or performing one or more measurements and / or one or more predictions to determine a second duration window. The WTRU may send CSI reports. The indication of the first duration window (e.g., the first LTM HO window) may be associated with the CSI reports.

[0008] The configuration information may include one or more of the following: WTRU-triggered LTM cell handover conditions for triggering cell handover within a first duration window (e.g., a first LTM HO window); one or more conditions to be used to determine a second duration window (e.g., a second LTM HO window); and / or an indication of an artificial intelligence (AI) model to be used to determine the second duration window (e.g., a second LTM HO window). The configuration information may include an indication of the length to be used for the first duration window (e.g., the first LTM HO window) selected from a plurality of predefined lengths. Determining the second LTM HO window may include determining the starting position and / or length of the second duration window (e.g., the second LTM HO window).

[0009] Determining the second duration window (e.g., a second LTM HO window) can be based on one or more conditions. These conditions may include one or more of the following: radio measurements, the number of packets in the HO time buffer, throughput, packet delay, packet loss, location, speed, and / or transmitted but unacknowledged HARQ data packets. Attached Figure Description

[0010] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0011] Figure 1B It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown.

[0012] Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0013] Figure 1DIt is shown that, according to the embodiment, it is possible to Figure 1A The system diagram shows another exemplary RAN and another exemplary CN used within the communication system shown.

[0014] Figure 2 A system diagram is depicted, illustrating the measurement model and measurement results of one or more (e.g., multiple) beams for a wireless transmit / receive unit (WTRU) to measure a cell.

[0015] Figure 3 A schematic diagram of an exemplary Layer 1 (L1) / Layer 2 (L2) triggering mobility (LTM) using carrier aggregation (CA) is depicted.

[0016] Figure 4 An exemplary system flowchart depicts an exemplary LTM benchmarking process.

[0017] Figure 5 An example of time series prediction for Reference Signal Received Power (RSRP) is shown.

[0018] Figure 6 A flowchart is depicted, illustrating an example of optimizing the LTM process using a dual-conditional window combined with artificial intelligence (AI) predictions.

[0019] Figure 7 A process flow is described, which shows an example of using a dual conditional window combined with artificial intelligence (AI) prediction to optimize the LTM process.

[0020] Figure 8 A flowchart is depicted illustrating an exemplary rollback scenario that uses a dual conditional window combined with artificial intelligence (AI) prediction to optimize the LTM process.

[0021] Figure 9 A process flowchart is depicted, illustrating an exemplary rollback scenario for optimizing the LTM process using a dual conditional window combined with artificial intelligence (AI) prediction.

[0022] Figure 10 A schematic diagram is depicted, illustrating an exemplary scenario of selecting one or more (e.g., multiple) target configurations.

[0023] Figure 11 A flowchart is depicted, illustrating an exemplary scenario of selecting one or more (e.g., multiple) target configurations.

[0024] Figure 12 A process flowchart is depicted, illustrating an exemplary scenario of selecting one or more (e.g., multiple) target configurations. Detailed Implementation

[0025] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT-UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0026] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or MiFi 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, etc. Any of the wireless transmit / receive units 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0027] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly connect to at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs, home NodeBs, home eNodeBs, gNBs, NR NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0028] Base station 114a may be part of RAN 104 / 113, and 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 of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. 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 use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

[0031] 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 use Long Term Evolution (LTE) and / or LTE-A Advanced (LTE-A) and / or LTE-A Pro Advanced (LTE-A Pro) to establish air interface 116.

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

[0033] 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, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface used 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).

[0034] In other embodiments, base station 114a and wireless transmission / reception units 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA 2000, CDMA 2000 1X, CDMA 2000 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), GSM EDGE (GERAN), etc.

[0035] Figure 1A Base station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA 2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0036] 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 may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although in Figure 1AAlthough not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0038] 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 to communicate 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 use cellular-based radio technology, and with base station 114b, which can use IEEE 802 radio technology.

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

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

[0041] 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 a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

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

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

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

[0047] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or 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, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0048] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all of the signals (e.g., signals associated with specific subframes for 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 through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all of the signals (e.g., signals associated with specific subframes for uplink (e.g., for transmission) or downlink (e.g., for reception)) are separate.

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

[0050] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers to communicate 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 / or receive radio signals from WTRU 102a.

[0051] 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 UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160C can communicate with each other via the X2 interface.

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

[0053] The MME 162 can connect to each of the eNodes B162a, 162b, and 162c 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, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0054] 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 handover between eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

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

[0056] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 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.

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

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

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

[0060] 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 fixed width (e.g., a 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, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0061] 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 to form a 40 MHz wide channel.

[0062] 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 consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

[0064] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth 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 STA that supports 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 1MHz 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 available.

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

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

[0067] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c includes 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 gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0068] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary 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 varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute times).

[0069] 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 needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially 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 serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0070] 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 fragmentation 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, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0071] 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 may include data networks (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0073] 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 them to route traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

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

[0075] 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) serving as an interface between CN 115 and PSTN 108. Furthermore, CN 115 may 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 can be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local data networks (DNs) 185a and 185b.

[0076] Given Figure 1A-1D and Figure 1A-1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0077] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0078] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can 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).

[0079] For example, under RRC_CONNECTED, the WTRU can measure one or more (e.g., multiple) beams (e.g., at least one beam) of a cell, and / or one or more measurement results (e.g., power values) can be averaged to obtain cell quality. In doing so, the WTRU can be configured to consider a subset of the detected beams. Filtering can be performed at one or more (e.g., two) different levels: at the physical layer to obtain beam quality and / or (e.g., then) at the Radio Resource Control (RRC) layer to obtain cell quality from one or more (e.g., multiple) beams. Cell quality from beam measurements can be derived for serving and / or non-serving cells in the same manner. One or more measurement reports may include measurement results (one or more) of X optimal beams, for example, if the WTRU is configured to do so via a gNB.

[0080] Figure 2An example corresponding to the high-layer measurement model 200 is depicted. One or more RRC measurements can be performed in the new radio (NR). K beams may correspond to one or more measurements on SSB and / or CSI-RS resources detected by the WTRU at Layer 1 (L1) and configured by the gNB for L3 mobility. A may reference one or more measurements within the physical layer (e.g., beam-specific samples). Layer 1 filtering may include internal Layer 1 filtering of one or more inputs measured at point A. How measurements are performed in the physical layer (e.g., practically) by implementation (e.g., input A and / or Layer 1 filtering) is not limited (e.g., by standards). A1 may include one or more measurements (e.g., beam-specific measurements) reported from Layer 1 to Layer 3 based on Layer 1 filtering (e.g., after Layer 1 filtering). Beam combining / selection may include combining beam-specific measurements to derive cell quality. The behavior of beam combining / selection may be standardized and / or the configuration of this module may be provided by RRC signaling. The reporting period at B may be equal to one measurement period at A1. B may include measurement results (e.g., cell quality) determined (e.g., derived) based on beam-specific measurements reported to Layer 3 after beam combining / selection. Layer 3 filtering for cell quality may include filtering performed on measurements provided at point B, the behavior of which may be normalized and / or configured by RRC signaling. The filtering reporting period at C may be equal to one measurement period at B. C may include measurements based on processing in the Layer 3 filter (e.g., after that processing). The reporting rate may be the same as the reporting rate at point B. This measurement is used as input to one or more evaluations for reporting criteria. Evaluation of reporting criteria may determine (e.g., check) whether an actual measurement report is required at point D. This evaluation may be based on multiple measurement streams at reference point C, for example, to compare between different measurements. This can be illustrated by inputs C and C1. WTRU may evaluate reporting criteria (e.g., report new measurement results at least each time at points C and C1). Reporting criteria may be normalized and / or configured by RRC signaling (e.g., WTRU measurements). D may include measurement reporting information (e.g., messages) transmitted on the radio interface. L3 beam filtering may include filtering performed on measurements provided at point A1 (e.g., beam-specific measurements). The behavior of the beam filter may be normalized and / or the configuration of the beam filter may be provided by RRC signaling. The filtering reporting period at E may be equal to one measurement period at A1. E may include measurements processed in the beam filter (e.g., beam-specific measurements). The reporting rate may be the same as the reporting rate at point A1. This measurement result may be used as input to select X measurements to be reported. Beam selection for beam reporting may involve selecting X measurements from the measurements provided at point E, and the behavior of beam selection may be normalized and / or the configuration of this module may be provided by RRC signaling.F may include beam measurement information included in the measurement report on the radio interface (e.g., transmitted).

[0081] Inter-cell beam management can manage one or more beams in carrier aggregation (CA) scenarios, but may not support cell changes / additions.

[0082] This paper describes one or more mechanisms and / or procedures based on L1 / L2 inter-cell mobility for reducing mobility latency. Developing mechanisms (one or more) and / or procedures (one or more) for L1 / L2-based inter-cell mobility to reduce mobility latency may include one or more of the following: configuration and / or maintenance for one or more (e.g., multiple) candidate cells to enable rapid application of candidate cell configurations (e.g., [RAN2, RAN3]); dynamic handover mechanisms based on L1 / L2 signaling for potential applicable scenarios between candidate serving cells (e.g., including special cells (SpCell) and / or secondary cells (SCell)) (e.g., [RAN2, RAN1]); L1 enhancements for inter-cell beam management, including L1 measurement and reporting, and / or beam indication (e.g., [RAN1, RAN2]); advance timing management (e.g., [RAN1, RAN2]); and / or centralized cell (CU) - distributed cell (DU) interface signaling to support L1 / L2 mobility (e.g., [RAN3] if needed). For example, regarding advance timing management (e.g., including further clarification of the possibility of interaction between advance timing management and L1 enhancements for inter-cell beam management), RAN2 involvement (e.g., early RAN2 involvement) may be included. Frequency range 2 (FR2) specific enhancements may not be excluded (e.g., if any).

[0083] The L1 / L2-based inter-cell mobility process can be applied to the following scenarios: standalone networking, CA, and NR dual connectivity (DC) scenarios that support serving cell changes within a configured license (CG); intra-DU scenarios and / or intra-CU inter-DU scenarios (e.g., applicable to standalone networking and CA: no new RAN interface is expected); co-frequency and inter-frequency; frequency range 1 (FR1) and FR2; source and / or target cells can be synchronous or asynchronous; and / or may not include inter-CU scenarios.

[0084] L1 / L2-based mobility can include inter-cell beam management, which addresses intra-DU and / or intra-frequency situations. In this case, the serving cell remains unchanged (e.g., it is not possible to change the serving cell using L1 / L2-based mobility). In FR2 deployments, CA can be used to utilize available bandwidth, for example, to aggregate multiple component carriers (CCs) in a frequency band. These CCs can be transmitted with the same analog beam pairs (e.g., gNB beams and WTRU beams). WTRUs can be configured with Transmission Configuration Indicator (TCI) states (e.g., there can be a considerable number, such as 64) for receiving the Physical Downlink Control Channel (PDCCH) and / or Physical Downlink Shared Channel (PDSCH). Each TCI state can include a Reference Signal (RS) and / or Synchronization Signal Block (SSB), which the WTRU references to set its beam. The SSB can be associated with a non-serving PCI. Media Access Control (MAC) signaling (e.g., TCI state indication for WTRU-specific PDCCH MAC Control Elements (CEs)) activates the TCI state for Coreset / PDCCH. MAC CEs indicating the TCI state associated with a non-serving PCI support PDCCH reception from a non-serving cell. MAC signaling (e.g., TCI state activation / deactivation for WTRU-specific PDSCH) can activate a subset of (e.g., up to) eight TCI states for PDSCH reception. Downlink Control Information (DCI) can indicate which of the eight TCI states. This document describes embodiments for supporting a unified TCI state with or without multiple TRPs, and with different update mechanisms (e.g., DCI-based).

[0085] The goal of LTM can be to improve handover latency. During L3 handover and / or conditional handover (CHO), the WTRU can first send a measurement report using RRC signaling. In response to the measurement report, the network can send (e.g., provide, configure) more measurement configurations and / or conditional handover configurations. For regular handover, after the WTRU reports that the cell meets the configured radio quality criteria using RRC signaling, the network can send (e.g., provide) the configuration for the target cell. For conditional handover, to reduce the handover failure rate due to the delay in sending measurement reports and then receiving RRC reconfiguration, the network can pre-send (e.g., provide) the target cell configuration and the measurement criteria for determining when the WTRU can trigger CHO configuration. However, both of these L3 methods may introduce a certain amount of latency due to sending measurement reports and / or receiving target configurations (e.g., particularly in the case of regular (unconditional) handover).

[0086] The goal of LTM can include the rapid application of candidate cell configurations, including dynamic handovers between SCells and handovers of the primary cell (PCell) (e.g., role switching between SCells and PCells) without performing RRC signaling. Inter-CU scenarios may be excluded, as this could include relocation of Packet Data Convergence Protocol (PDCP) anchors and / or may have already been excluded from the work plan. RRC-based approaches may be included to at least support inter-CU handovers.

[0087] For example, using traditional L3 handover mechanisms, one or more (e.g., any) currently active SCells can be released before the WTRU completes handover to a target cell in the coverage area of ​​another (e.g., a new) site, and / or can be (e.g., only) re-added after a successful handover, which can lead to a decrease in throughput during handover. One of the goals of L1 / 2 may be to enable CA operation instantaneously when the serving cell changes.

[0088] Figure 3 An example of LTM operation 300 is shown. Candidate cell groups can be configured by RRC and / or dynamic handover of PCells and SCells can be implemented using L1 / 2 signaling. For example, RRC can initially configure cells 1-4 as candidates and / or activate PCell1 and / or SCell2. Dynamic SCell handover between cell 2 and cell 3 can be performed (e.g., cell 3 can become the SCell while cell 1 remains the primary cell). Dynamic handover of PCells can be performed (e.g., PCell can switch from cell 1 to cell 2) and / or SCell can switch to cell 4.

[0089] Figure 4 An exemplary system flowchart 400 depicts an exemplary LTM benchmarking process. At 425, WTRU 402 may perform a first part of the LTM benchmarking process (e.g., LTM preparation). At 450, WTRU 402 may perform a second part of the LTM benchmarking process (e.g., early synchronization). At 475, WTRU 402 may perform a third part of the LTM benchmarking process. At 495, WTRU 402 may perform a fourth part of the LTM benchmarking process.

[0090] At 425, the WTRU can perform the first part of the LTM baseline procedure (e.g., LTM preparation). For example, the WTRU can perform LTM preparation during the first duration window (e.g., the first LTM HO window). At 406, WTRU 402 can be in RRC_Connected mode. At 408, WTRU 402 can send to gNB 404. Measurement ReportMessage. At 410, gNB 404 can perform LTM candidate preparation. For example, gNB 404 can determine (e.g., decide) to use LTM and / or can initiate LTM candidate preparation. At 412, gNB 404 can transmit to WTRU RRCReConfiguration The RRC Reconfiguration message 412 may include LTM candidate configurations (e.g., as described herein). For example, the RRCReconfiguration message may include the configurations of one or more (e.g., multiple) LTM candidate target cells. For example, the WTRU may receive configuration information from a network device via a first cell. This configuration information may include a first low-layer triggered mobility (LTM) HO window from the network. At 414, the WTRU 402 may store the configurations of the LTM candidate target cells and / or may transmit them. RRCReconfigurationComplete The message was sent to gNB 404.

[0091] At 450, WTRU 402 can perform the second part of the LTM baseline procedure (e.g., early synchronization). At 416a, WTRU 402 can perform downlink (DL) synchronization and timing advance (TA) acquisition with candidate target cells (one or more) before receiving an LTM cell handover command. For example, the LTM cell handover command can be received via MAC CE. DL synchronization of candidate cells (one or more) can be supported at least based on SSB before the cell handover command. TA acquisition of candidate cells (one or more) before the LTM cell handover command can be supported at least based on the random access channel (RACH) of the PDCCH command, where the PDCCH command is triggered by the source cell. At 416b, WTRU 402 can perform early uplink (UL) synchronization with one or more candidate cells (e.g., sending a RACH preamble to the candidate cells, which the network can use to determine the UL timing advance (TA) required for the WTRU to communicate with the candidate cells if the candidate cells are selected as target cells later in step 420).

[0092] At 418, WTRU 402 can perform L1 measurements on configured LTM candidate target cells (one or more), and / or can transmit low-layer (e.g., L1) measurement reports (one or more) to gNB 404. Low-layer measurement reports can be carried on L1 and / or MAC.

[0093] At 420, gNB 404 can determine (e.g., decide) to perform an LTM cell handover to the target cell.

[0094] At position 422, gNB 404 can transmit cell handover commands. For example, gNB 404 can transmit a MAC CE that triggers LTM cell handover by including a candidate configuration index of the target cell.

[0095] At 424, WTRU 402 can switch to the configuration of the LTM candidate target cell. For example, WTRU 402 can separate and / or apply (e.g., the target cell configuration received at 422) from the source cell.

[0096] At 426, for example, if TA is unavailable, WTRU 402 can perform a random access procedure to the target cell. At 428, WTRU 402 can indicate the successful completion of the handover from the LTM cell to the target cell.

[0097] Artificial intelligence (AI) can include the ability of machines to perceive, synthesize, and / or infer information. Such behavior can, for example, mimic cognitive functions to perceive, reason, adapt, and / or act.

[0098] Machine learning (ML) can refer to a type of algorithm that, for example, learns from experience (e.g., data) without explicitly programming (e.g., configuring a set of rules) to identify patterns and / or infer solutions to problems. Machine learning can be viewed as a subset of AI. Different machine learning paradigms can be envisioned based on the nature of the data and / or feedback available for learning the algorithm(s). For example, supervised learning methods may involve learning a function that maps inputs to outputs based on labeled training examples, where each training example can be a pair including an input and a corresponding output. For example, unsupervised learning methods may involve detecting patterns in data for which no pre-existing labels are present. For example, reinforcement learning methods may involve performing a sequence of actions in an environment to maximize a cumulative reward. Examples can include applying machine learning algorithms using combinations and / or interpolation of the methods mentioned herein. For example, semi-supervised learning methods may use a combination of a small amount of labeled data and a large amount of unlabeled data during training. In this respect, semi-supervised learning can fall between unsupervised learning (e.g., unlabeled training data) and supervised learning (e.g., training data with only labels).

[0099] Deep learning can refer to a class of machine learning algorithms that use artificial neural networks (e.g., specifically, deep neural networks (DNNs)) that may be loosely inspired by biological systems. A deep neural network (DNN) can be a special class of machine learning models inspired by the human brain, where the input is linearly transformed and / or passed through a non-linear activation function one or more times (e.g., multiple times). A DNN can include multiple layers, where each layer includes a linear transformation and / or one or more given non-linear activation functions. A DNN can be trained using training data via a backpropagation algorithm. DNNs can encompass state-of-the-art performance in various domains (e.g., speech, vision, natural language, etc.) and / or be used for various machine learning settings (e.g., supervised, unsupervised, and / or semi-supervised).

[0100] An autoencoder can be a category-specific DNN that emerges in the context of an unsupervised machine learning setting, where a DNN-based encoder non-linearly transforms high-dimensional data into lower-dimensional latent vectors, and (e.g., then) uses the lower-dimensional latent vectors to regenerate the high-dimensional data using a non-linear decoder. The encoder can be represented as... Where x is high-dimensional data and These represent the parameters of the encoder. The decoder can be represented as... , where z is a low-dimensional latent representation and This represents the encoder's parameters. Additionally, training data is used. This can be achieved by solving the following optimization problem. To train an autoencoder, the backpropagation algorithm can be used to approximate the solution. The trained encoder... It can be used to compress high-dimensional data and / or a trained decoder. It can be used to decompress latent representations.

[0101] The terms Artificial Intelligence (AI), Machine Learning (ML), Deep Learning (DL), and DNN are used interchangeably. The methods described herein can be illustrated based on learning within wireless communication systems. The methods are not limited to such scenarios, systems, and / or services; they can be applied to one or more (e.g., any) types of transport and / or services.

[0102] Recurrent Neural Networks (RNNs) are algorithms particularly effective for modeling sequential data. RNNs can include internal memory, allowing the model to remember previous inputs as well as the current input to aid in sequence modeling. The output of any step within the neural network can be based on the current input and / or the output generated at one or more previous steps. Examples of how RNNs can track dynamically changing conditions for a given task include tracking the effects of channel / radio variations, latency variations, bit rate, jitter, etc., to determine, for instance, how to apply Quality of Service (QoS) treatment per packet for a given flow.

[0103] In the example, the term rule-based processing can refer to specified WTRU behaviors and / or requirements that are (e.g., explicitly) outlined (e.g., defined) in the form of process text, signaling syntax, etc. Rule-based processing can also refer to any processing based on one or more (e.g., conventional) algorithms, which can be (e.g., substantially) based on non-AI. For example, a Logical Channel Priority (LCP) process may include (e.g., can be defined as) one or more (e.g., a series of) process steps. Entities performing AI processing can be referred to as rule-based components.

[0104] In the example, the term AI processing can refer to a specified WTRU behavior and / or processing and / or a portion thereof learned based on training using data. AI processing can involve one or more classical machine learning techniques and / or deep learning techniques. AI processing can apply one or more AI model architectures to perform one or more of the following: classification, prediction, pattern recognition, dimensionality reduction, estimation, interpolation, clustering, regression, compression, recommendation, approximation of arbitrary functions, etc. AI processing can utilize supervised, unsupervised, reinforcement learning, and / or combinations or variations thereof. For example, an AI model applying AI processing can be trained using various techniques such as offline training, online refinement, and / or combinations thereof. For example, such training can be performed on the WTRU (e.g., locally), partially on the WTRU, and / or downloaded from a network. The entity performing AI processing can be referred to as an AI component and / or an AI filter.

[0105] A WTRU can be configured with one or more (e.g., multiple) AI models. Each AI model can be associated with a context. For example, a context can refer to a set of conditions under which (e.g., and / or during) the performance of the AI ​​model is expected to be satisfactory. The performance of an AI component can be correlated with, for example, the inference accuracy of the AI ​​model used by the AI ​​component for a given task.

[0106] A contextual AI model may include an AI model associated with a specific context. The inference accuracy of a contextual model may be based on (e.g., dependent on) the context in which the model is executed. The size, training time, inference latency, complexity, and / or power consumption associated with a contextual AI model may be (e.g., significantly) lower than the size, training time, inference latency, complexity, and / or power consumption of an AI model expected to execute in one or more (e.g., all) contexts.

[0107] The L1 / 2 triggered mobility (LTM) procedure, which is being standardized, can improve mobility latency by, for example, by: pre-configuring multiple target cells before handover; using L1 measurement reports for mobility purposes; and / or using MACCE to indicate cell handover.

[0108] Cell handover time can be based on (e.g., primarily depending on) one or more radio conditions. The reduction in outage time and measurement reporting latency provided by the introduction of LTM can offer greater flexibility in the precise timing of cell handover, and due to the improved latency, there can be a lower probability of radio link failure (RLF) at the source and / or a lower probability of handover failure (HOF) at the destination.

[0109] AI / ML, together with LTM, can provide opportunities to optimize throughput during handover (e.g., further). Throughput can be optimized during handover by leveraging improved mobility latency and / or reduced failure probability, along with predictive models of traffic volume and / or radio conditions, to determine the optimal cell handover time, for example, by using inputs from WTRU and the network.

[0110] Optimal cell handover time can be based on (e.g., depending on) real-time radio conditions (e.g., the precise moment when cell B becomes better than cell A, which is impossible to determine even using L1 / 2 signaling based on traditional report / execution commands due to delays caused by the transmission of measurement reports and / or the reception of triggers for reconfiguration). Optimal cell handover time can also be based on (e.g., depending on) traffic volume. For example, to complete the retransmission of larger Protocol Data Units (PDUs) on the source before handover, it may be beneficial to perform the handover later and / or earlier before initiating the initial PDU transmission.

[0111] LTM can be based on (e.g., dependent on) frequent L1 reports to achieve optimal cell handover time, resulting in excessive resource (e.g., Physical Uplink Control Channel (PUCCH)) overhead and / or WTRU measurement processing.

[0112] The systems, methods, and / or apparatuses provided herein may be about how to achieve dynamic control over optimal cell handover time so that the WTRU can perform cell handover time decisions to achieve an optimal trade-off between throughput, latency / robustness, and measurement reporting overhead.

[0113] This document provides a system, method, and / or apparatus for adjusting the execution window of an LTM switching (HO) mechanism.

[0114] The initial HO execution time window selection can be performed on the gNB side and / or indicated to the WTRU using, for example, an index of a pre-configured window position and / or length during MAC CE-triggered LTM cell handover. This can be based on reported and / or predicted radio conditions in, for example, cell A (e.g., the source cell) and B (e.g., the target cell), and the network can determine and / or indicate (e.g., appropriate) limits to minimize HO failures and / or RLFs and / or avoid excessively long waits (e.g., long resource reservations in the target cell).

[0115] The WTRU can determine the precise cell handover time within a configured window, taking into account factors such as real-time / instantaneous radio condition measurements, predicted measurements, and / or service / traffic forecasts. The WTRU can select the optimal time to perform LTM (Low-Time Measuring) to maximize throughput based on predicted throughput at cell A and / or cell B during the configured window. The WTRU can (e.g., further) determine a more precise window within the network (NW) configured window during which cell handover would be optimal (e.g., throughput and / or failure probability within a certain tolerance limit and better than the throughput and / or failure probability offered by the NW's configured window), and / or can report this to the NW to aid in AI model training.

[0116] The WTRU can receive configurations of LTM candidate cells and / or configurations of the allowed first handover window length. The configurations of LTM candidate cells and / or the allowed first handover window length can include an explicit list of length values ​​and / or enable one of multiple predefined tables. The window size can correspond to, for example, cell size / coverage / time / speed within the cell. The window size can be defined according to time, service and / or target cell RSRP range, location, etc. The configuration can include WTRU-triggered LTM cell handover conditions / criteria for triggering cell handover within the first window. The configuration can include conditions to be used for selecting a second window, and / or indications of the AI ​​model to be used for a specific indication of the first or second window length. The configuration can include an indication of the second window. The indication of the second window can include different actions taken by the WTRU during the first and second windows (e.g., a first window for LTM preparation steps, a second window for LTM execution).

[0117] WTRU can transmit Channel State Information (CSI) reports.

[0118] The WTRU can receive from the network equipment an indication of a first cell to perform a handover and / or cell handover to a candidate cell among multiple candidate cells. This indication may include a first duration window. For example, the WTRU may receive an LTM cell handover MAC CE, which includes an indication of the first window's time position (e.g., time offset and / or system frame number (SFN)) and / or an indication of one of multiple predefined lengths. Determination can be performed on the NW side, for example, based on CSI reports and / or constraints based on NW-predicted radio conditions / traffic. The offset may include (e.g., a pointer to a list of preconfigured values), an explicit SFN indication, an increment from the current time, etc.

[0119] The WTRU may perform specific (e.g., first) LTM preparation actions during a first duration window. For example, the WTRU may perform LTM preparation at the beginning of the first duration window (e.g., a first LTM HO window). The WTRU may disable and / or minimize (e.g., report fewer beams and / or report less frequently) candidate cell CSI reports during the first window (e.g., HO execution may be based on WTRU measurements and / or predictions without CSI reporting). Performing LTM preparation during the first duration window (e.g., a first LTM window) may include disabling CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing Early Timing Advance (TA) acquisition, and / or performing one or more measurements and / or one or more predictions to determine a second duration window. For example, the WTRU may transmit acknowledgments before / when CSI reporting is suspended / reduced. The WTRU may perform early TA acquisition (e.g., random access channel to target (RACH)) during the first window. For example, the WTRU may receive a random access response (RAR) including TA from the target cell and / or from the source cell. The WTRU may perform measurements and / or predictions to determine the location of the second window. For example, determining the second window by the WTRU may include: the WTRU determining the start position and / or length of the second duration window.

[0120] The WTRU can determine (e.g., selectively) the location and / or length of a second HO window within a first HO window to determine the optimal cell handover time range, and / or the WTRU can select a time within the second window to perform cell handover. For example, the WTRU can determine the second duration window based at least on a first duration window and / or one or more conditions (e.g., as described herein). The second duration window can be a subset of the first duration window. The second duration window can include a variable location and / or a second (shorter) length. For example, the second duration window can be based on updated radio conditions and / or traffic forecasts (e.g., compared to reported and / or NW-determined forecasts). For example, the purpose of the second window can be to maximize throughput during the HO window. Alternatively or concurrently, the second window can be determined (e.g., selected) based on explicit NW indications (e.g., NW configuration). The WTRU can determine (e.g., select) different AI measurement prediction models and / or window length selection criteria based on (e.g., depending on) the window length. For example, a shorter window can use (e.g., only) radio conditions. For example, a longer window can (e.g., allow) consideration of service aspects.

[0121] The WTRU can perform other (e.g., second) LTM actions during the second window. For example, the WTRU can monitor LTM triggering conditions to be met during the second window.

[0122] The WTRU can perform cell handover and / or handover at a determined time, and / or can transmit indications (e.g., to a new cell). For example, the WTRU can perform cell handover and / or handover based on radio resource (re)configuration. The WTRU can report the location of the determined second window, and / or the conditions used to make the determination (e.g., radio measurements, number of packets or throughput in the buffer during HO time, packet delay, packet loss, location, speed, etc.). For example, the WTRU can send information to network equipment indicating the second duration window and / or one or more conditions used to determine the second duration window. The WTRU can send indications (e.g., one or more sequence numbers) of Hybrid Automatic Repeat Request (HARQ) and / or Radio Link Control (RLC) data PDUs that have been transmitted but whose respective acknowledgments have not yet been received (e.g., transmitted but not ACKed). The WTRU can indicate the reason for the HO time determination.

[0123] This document provides systems, methods, and / or apparatus for rollback and / or reporting in cases where predicted LTM HO conditions are not met.

[0124] The NW can determine the backoff cell based on radio conditions and / or determine the target cell based on prediction. The gNB can indicate an LTM handover to the target cell before the conditions are met, and / or can indicate backoff conditions (e.g., it could be the third cell, or it could be the original source cell).

[0125] For example, if the predicted conditions are met during the time window (e.g., as described herein), the WTRU can trigger a cell handover to the indicated target cell. If the conditions are not met (e.g., then), the WTRU can trigger a backoff. The WTRU can indicate failure to the backoff cell.

[0126] The WTRU can receive the configuration of LTM candidate cells and / or the configuration of one or more predefined backoff / failure conditions. The conditions (one or more) may include measured and / or predicted radio quality metrics, and / or one or more time window lengths. The conditions (one or more) may be based on whether the window determined by the WTRU falls within the NW prediction window.

[0127] WTRU can transmit (e.g., measured and / or predicted) CSI reports. For example, an indication of the first duration window can be associated with a CSI report.

[0128] The WTRU can receive an LTM cell handover MAC CE, which includes indications of one or more target cells, indications of triggering conditions (one or more), and / or indications of backoff actions. The backoff action may be to a candidate target cell that triggered the LTM, and / or it may be to back off to the source cell + send a measurement report. The triggering conditions, target cells, and / or backoff cells can be pre-configured (e.g., the NW can pre-configure the WTRU). The association between the target / backoff / conditions (e.g., in between) can be partially and / or fully pre-configured and / or dynamically indicated in the MAC CE.

[0129] The WTRU can perform LTM preparation actions (e.g., the WTRU can disable CSI reporting and / or perform early TA acquisition during the window). For example, the WTRU can perform LTM preparation during a first duration window. Performing LTM preparation during the first LTM window may include disabling CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing early timing advance (TA) acquisition, and / or performing one or more measurements and / or one or more forecasts to determine a second duration window.

[0130] The WTRU can determine whether backoff / failure conditions are met. For example, the WTRU can determine whether a measured radio condition criterion is not met and / or whether a TA was not successfully obtained and / or is no longer valid for one of the target cells within the indicated time window (e.g., measurement mismatch with indicated prediction).

[0131] The WTRU can determine, based on WTRU measurements / predictions, an alternative window (e.g., an alternative to the indicated window) where the switching is estimated to be successfully completed, and / or can indicate windows (one or more) determined by the WTRU.

[0132] The WTRU can trigger LTM to the fallback cell and / or can transmit reports on at least the radio conditions, window calculations, etc. of the indicated / failed target cell as measured within the time window.

[0133] For example, if the fallback cell is the original cell, the WTRU can resume LTM preparation actions (e.g., the WTRU can resume CSI reporting).

[0134] This document describes embodiments of different target configurations (e.g., active Scells) windows based on (e.g., depending on) the selection (e.g., determination) of WTRUs within a main window (e.g., PCell switching time). WTRUs can be provided (e.g., NW can be configured) with one or more (e.g., multiple) target configurations (e.g., which Scells can be activated), which are determined (e.g., selected) based on (e.g., depending on) the precise WTRU conditions that trigger SpCell changes, thereby enabling the achievement of an optimal target configuration.

[0135] The WTRU can receive configurations of LTM candidate cells, first SpCell change conditions, and / or configurations of one or more (e.g., multiple) target (e.g., active SCell) configurations, where each configuration can be associated with a second condition (e.g., a time window and / or RSRP range) applied based on (e.g., depending on) when the first SpCell change condition is met. For example, different sets of Scells (e.g., one or more different configurations) can be activated based on (e.g., depending on) the time when the SpCell handover criterion (first condition) is met (second condition). For example, the SpCell cell handover decision can be based on the current SpCell being below a threshold, and the set of activated SCells can be based on (e.g., depending on) one or more of the target cells (e.g., if the target SpCell is in range 1, then SCell 1 is activated, and if it is in range 2, then SCell 2 is activated). For example, the WTRU can be provided with a SpCell change window. Based on (e.g., depending on) the actual cell handover decision time (e.g., based on predictions made by the system, method, and / or apparatus provided herein), (e.g., then) the WTRU can activate one or more different sets of SCells.

[0136] WTRUs can transmit CSI reports. For example, a WTRU can send a CSI report. The indication of the first duration window can be associated with the CSI report.

[0137] The WTRU can receive cell handover commands, which include an indication of the PCell handover time window.

[0138] WTRU can determine the optimal PCell switching time within the indicated window. WTRU can also consider the optimal SCell in AI / ML model evaluation and / or (e.g., also) determine (e.g., select) the HO trigger time based on the SCell.

[0139] For example, based on (e.g., depending on) the determined (e.g., selected) PCell switching time (e.g., and / or other conditions), the WTRU can determine (e.g., select) the appropriate target configuration. For example, if a PCell switch is performed during a first duration within a window, (e.g., then) a first Scell ​​set can be activated; otherwise, (e.g.,) a second (e.g., Scell) set can be activated.

[0140] The WTRU can perform cell handover at a predetermined time and / or can transmit instructions to other (e.g., new) cells with the selected configuration.

[0141] Executing LTM and / or executing the LTM procedure may refer to executing this document (e.g., Figure 4The process described in the text refers to one or more of the following (e.g., any one, each). Specifically, it involves early synchronization to one or more candidate cells in the downlink (DL) and / or uplink (UL), performing L1 measurements and / or reporting on one or more of the candidate cells, and handover between candidate cells (e.g., performing a handover). (For example, performing LTM may include the WTRU moving / handover between multiple candidate cells during the process.)

[0142] One or more candidate cell sets can be a group of multiple RRC configurations corresponding to handover configurations for one or more candidate SpCells and / or SCells. This can be modeled and / or received as one or more complete RRC reconfiguration messages, one or more cell group configurations, and / or one or more cell configurations. Each of the candidate cell configurations may include a candidate configuration identifier, and / or each of the candidate cell groups may include a candidate cell group identifier. If the packet is performed in RRC, for example, a handover between different candidate cell sets may include updating the serving cell index and / or candidate configuration index used in L1 and / or MAC signaling to reference a specific index (e.g., the MAC CE that triggers the reconfiguration may include a candidate configuration index that notifies the WTRU which cell to perform the reconfiguration for).

[0143] One or more candidate cell groups can be configured as a single candidate cell configuration list and / or candidate cell configuration group at the RRC. Grouping can occur during the early synchronization and / or LTM execution phase (e.g., not the configuration phase). With respect to the RRC configuration list and / or configuration group, the set of candidate cells can be considered a single group, and the cells selected for performing early synchronization, L1 measurement, and / or LTM execution can be based on (e.g., depending on) further grouping of the overall candidate cell list into one or more (e.g., multiple) subsets. Grouping itself may not be modeled using candidate configuration identifiers at the RRC; grouping can be performed as part of the early synchronization and / or LTM execution process.

[0144] LTM candidate configurations can be applied to one or more (e.g., any) types of pre-configured cell information. For example, a WTRU can be configured with one or more conditional reconfigurations, such as Conditional Handover (CHO), Conditional PSCell Addition (CPA), and / or Conditional PSCell Change (CPC), which are effective before and / or after cell changes, and / or in certain cells.

[0145] The L1 measurements described herein may include measurements of the Reference Signal Received Power (RSRP), RSRQ, Received Signal Strength Indicator (RSSI), etc., performed by the WTRU of a cell, beam, cell set, and / or beam set. Such L1 measurements (one or more) may be similar to Layer 3 (L3) measurements reported in Radio Resource Management (RRM), differing in filtering, the reference signal used for measurement, reporting mechanisms, etc.

[0146] Here, measurement may refer to L1 measurement for LTM. The methods, systems and / or apparatus described herein can also be applied to RRM / L3 measurement and other measurements (e.g., speed, position, height, traffic volume, etc.).

[0147] The conditions experienced by the WTRU can stem from one or more actual measurements performed by the WTRU over time. In an exemplary (e.g., simple) mobility scenario, a moving WTRU can read the RSRP of the current serving cell and / or report the RSRP of the current serving cell to the NW. For example, if the WTRU is moving to an area near the edge of the serving cell, the WTRU can record that the RSRP value is decreasing. The RSRP value can be transmitted to the NW via the NW's measurement report for determination (e.g., decision).

[0148] NW can have a pre-trained AI / ML model that is capable of generating predictions of air interface measurements (RSRP, RSRQ, signal-to-interference-to-noise ratio (SINR), etc.) for serving and / or neighboring cells (e.g., any cell). The predictions can determine (e.g., anticipate) the radio conditions that the WTRU is likely to experience (e.g., instead of waiting for the WTRU to report).

[0149] To generate more (e.g., meaningful) predictions in this context, NW can predict one or more measurements (e.g., RSRP) in a time-series manner. This can include generating one or more (e.g., several) prediction outputs at a specific granularity and / or time step over future time spans, starting from the moment the NW prediction is triggered.

[0150] Figure 5An example of time series forecasting for RSRP is shown. Historical RSRP and / or current RSRP and / or one or more other (e.g., related) inputs can be included as inputs in the AI ​​model and / or ML model. NW (e.g., via ML) can forecast the RSRP at time t (e.g., 502, 504). NW can forecast one RSRP prediction point per time step starting from time t+1 until t+t_fb (e.g., at 506). The variable fb can represent the end of the time range used for forecasting(one or more). When the forecast is output as a time series, another variable n can be used to represent the forecast window, such that when the forecast is triggered at time t, the window will last n(fb) and the total window time can be t+n. Each RSRP forecast can correspond to a corresponding error. For example, NW can forecast the RSRP at t+1; error1. ML can forecast the RSRP at t+2; error2. ML can forecast the RSRP at t+t_fb; errort_fb.

[0151] Predictions can also be made (e.g., only) for a single point in time, and / or can extend over several time steps. In the example, predictions with time-series outputs can be (e.g., more) beneficial than single-value predictions because it may be difficult to match predictions with, for example, NW configuration events with a single prediction point.

[0152] This can lead to practical issues regarding the granularity of the timestamps associated with the prediction. For example, if WTRU and / or NW predict one or more future values, a timestamp can (e.g., in principle) be associated with that prediction (e.g., timestamps of t+1, t+2, etc.). The granularity of this timestamp can be based on (e.g., depending on) the AI / ML model in use and / or one or more other ML-related settings. Terms such as predicted value, inferred value, future value, and / or others can be used to refer to future predicted values ​​that may have associated timestamps. For example, if a future predicted value does indeed have an associated timestamp, the timestamp can be considered a small incremental time interval within which the predicted value can be considered accurate and / or valid (e.g., completely or with a certain level of confidence). In one or more (e.g., all) WTRU-NW exchanges, the prediction can be represented by tuples such as ["predicted value"; timestamp-increment; timestamp+increment].

[0153] NW and / or WTRU predictions can be performed in response to one or more triggers. For example, the WTRU can be configured to predict future measurements based on current and / or historical measurements. For example, the WTRU can be configured with a trained AI / ML model capable of generating predictions for radio signal levels at the radio interface. In the example, the AI / ML model at the WTRU can be implementation-based. In the example, the WTRU can obtain the AI / ML model from the NW. In the example, the AI / ML model can be configured to take current and / or historical RSRP measurements as input. In the example, the AI / ML model can be configured to take additional inputs, such as WTRU location information, WTRU mobility, etc. In the example, the AI / ML model can be configured to produce a single-value prediction (e.g., RSRP at a future time t). In the example, the AI / ML model can be configured to predict a series of RSRP values ​​corresponding to future times (e.g., t+1, t+2, etc. up to t+t_fb).

[0154] The model can be trained offline and / or online, and / or can be swapped in a pre-configuration step.

[0155] The systems, methods, and apparatuses proposed herein can provide a network with an opportunity to provide a range (e.g., a window) of one or more criteria (e.g., time, radio quality measurements, location) within which a handover is expected to be (e.g., fully) successful (e.g., with a minimum probability of handover failure and / or radio link failure); the WTRU can adjust the precise timing of the handover based on updated (e.g., compared to NW configuration time) measurements and / or AI predictions to maximize performance (e.g., maximize throughput, minimize outages, and / or latency) during handover execution. Additionally or alternatively, this can provide opportunities to improve robustness (e.g., by enabling WTRU-triggered handover execution) while limiting the network resource overhead of doing so (e.g., retaining resources on the target cell only for a limited duration). Some embodiments may include an NW AI model trained and / or fine-tuned using WTRU feedback and / or reports for future handovers. Some embodiments may provide a backoff mechanism to support a more aggressive approach to predicting handover events by (e.g., further) improving the robustness of the mechanism. Some embodiments may include (e.g., support) the ability of the WTRU to determine (e.g., select) the most appropriate switching trigger timing and / or determine (e.g., select) the most appropriate and / or most efficient configuration to be applied when performing a switch (e.g., providing the highest estimated throughput, the fewest errors, the lowest failure rate, etc.).

[0156] The gNB (e.g., the CU in a CU / DU split architecture scenario, where the RRC can reside in the CU) can use RRC signaling to configure (e.g., potential) LTM candidates. In the example, the WTRU can receive LTM candidate configurations (e.g., such as during the LTM preparation phase) using RRC reconfiguration messages. Figure 4 (As shown). The WTRU can store LTM candidate configurations to be applied (e.g., later) based on receiving an indication to perform cell handover using L1 / 2 signaling (e.g., MAC CE) (after receiving L1 / 2 signaling), for example, during the LTM execution phase (e.g., as shown). Figure 4 (As shown).

[0157] In the example, the configuration of a potential LTM candidate may include a set of candidates. For example, a first set may be applicable to a first path (e.g., the WTRU may turn left and / or may take the first route), while a second set may be applicable to a second path (e.g., the WTRU may turn right and take the second route).

[0158] In the example, one or more (e.g., some and / or all) candidate set information can be broadcast in system information. The WTRU can enable the pre-configuration of these broadcast configurations based on an indication received in dedicated signaling (e.g., RRC reconfiguration), which may relate to the broadcast of one or more configurations (e.g., using an index or identifier).

[0159] In the example, the configuration may include one or more potential cells in a specific region (e.g., all cells or a subset of cells) (e.g., all cells belonging to the CU currently connected to the WTRU and / or cells within a specific geographic region). These cells may not yet have been detected and / or measured by the WTRU, but are pre-configured. In the example, based on the initial configuration of the LTM candidate configuration (e.g., afterward), the WTRU may receive updates to that configuration to modify, add, remove, and / or replace one or more (e.g., any) parts of the LTM candidate configuration.

[0160] In the example, the WTRU can receive an instruction to enable or disable one or more (e.g., some and / or all) LTM configurations. For example, if it is predicted that using L3 (e.g., RRC measurement reporting, RRC reconfiguration, conditional reconfiguration) will better handle WTRU mobility (e.g., then), LTM can be disabled. If it is predicted that LTM will better adapt to WTRU mobility, for example, (e.g., previously configured and / or disabled LTM configurations can be re-enabled).

[0161] This configuration can be based on a prediction model that is internal to the network (e.g., gNB) and / or determined by the network. The prediction can, for example, be the most likely path for the WTRU determined by a prediction model (NW prediction model).

[0162] In the example, candidate cell configuration may include one or more (e.g., all and / or some) pieces of information (e.g., necessary information) required to complete the reconfiguration (e.g., handover) of the candidate cell, such as channel configuration (e.g., physical RACH (PRACH), dedicated physical control channel (DPCCH), dedicated physical shared channel (DPSCH)), control resource set (CORESET), bandwidth portion (BWP), security parameters, L2 parameters (e.g., MAC, RLC, PDCP), radio bearer configuration, etc.

[0163] An example of using WTRU reporting information for NW model training is described. In the example, WTRU may report the selected window size and / or information used for determination (e.g., selection). For example, the reported information may include one or more of the following: The reported information may include the window start time (e.g., SFN and / or subframe) and / or offset (e.g., offset from the configured start time).

[0164] The reported information may include: window length (e.g., the number of subframes and / or the number of milliseconds) and / or offset (e.g., offset relative to the configuration length). The reported information may include measured and / or predicted CSI information: RSRP (beam and / or cell); RSRQ (beam and / or cell); CSI Reference Signal Resource Indicator (CRI) - Rank Indicator (RI) - Precoding Matrix Indicator (PMI) - Channel Quality Indicator (CQI); cri-RI - Single Wideband Indicator (i1); cri-RI-i1-CQI; cri-RI-CQI; CRI-RSRP; ssb - Index - RSRP; and / or CRI-RI Layer Indicator (LI) - PMI-CQI.

[0165] The reported information may include the predicted LTM cell handover execution time and / or time range. The reported information may include an indication of the predicted optimal SCell to be activated during SpCell handover. The reported information may include one or more beam and / or cell identifiers that are predicted and / or measured. The reported information may include one or more LTM candidate cell and / or cell set identifiers. The reported information may include an index to one of a plurality of predefined measurements. The reported information may include explicit cell quality measurements. The reported information may include an indication of whether one or more reported values ​​are predicted and / or actually measured. The reported information may include an indication of the model used for prediction. The reported information may include an indication of the time scale used for prediction. The reported information may include failure information, such as: a cell on which the WTRU detects a beam failure or radio link failure; measurements associated with failure conditions (e.g., the cell meets specific configuration criteria such as a cell quality threshold, and / or an absolute measurement such as RSRP); and / or one or more (e.g., multiple) and / or retransmissions in the case of a failed RACH process.

[0166] The reported information may include: location information (e.g., GPS coordinates, cell fingerprint, location history, speed, altitude, device orientation, etc.).

[0167] The reported information may include throughput (e.g., regarding the source and / or destination). The reported information may include packet error rate (e.g., regarding the source and / or destination). The reported information may include packet delay (e.g., regarding the source and / or destination). The reported information may include cause values, such as an indication that WTRU has determined (e.g., selected) a second window based on one or more of the information types provided herein.

[0168] The LTM execution window here may refer to a range that is configured by the network and / or indicated by the network to the WTRU and / or estimated / determined by the WTRU.

[0169] The range can be based on one or more of the following (e.g., any of them): The range can be based on time (e.g., absolute or relative time measured at the WTRU, SFN, and / or subframe number). The range can be based on radio quality measurements and / or predicted radio quality (e.g., RSRP (beam and / or cell), RSRQ (beam and / or cell), cri-RI-PMI-CQI, cri-RI-i1, cri-RI-i1-CQI, cri-RI-CQI, cri-RSRP, ssb-index-RSRP, cri-RI-LI-PMI-CQI, etc.) of one or more of the serving cell and / or target cell. The range can be based on location. For example, location can include a region of coordinates (e.g., defined by a reference point and / or radius) and / or range. Location can include a distance threshold from a reference location. The range can be based on data (e.g., correlated data). For example, the range can be based on the amount of data to be received in the downlink since the start of the window. For example, the range could be based on the amount of data to be transmitted in the uplink since the start of the window. For example, the range could be based on the total amount of data exchanged with the network. The range could be based on QoS-related metrics (e.g., the WTRU could predict several relevant QoS metrics, such as packet loss, packet error rate, and / or throughput, and / or the range of the window could be set based on this). For example, the window could start with one or more (e.g., any) options described herein and end when the WTRU predicts that throughput will fall below a threshold, or when the WTRU predicts that packet loss / packet error rate will exceed a threshold. The range could be based on multiple conditional methods; for example, the WTRU could determine the start of the window immediately upon receiving relevant signaling from the NW (e.g., as described herein), and / or consider a specific SFN, and / or determine the end of the window based on one or more (e.g., another) time-independent conditions (e.g., predicted radio conditions).

[0170] This window allows you to define a range of conditions under which the WTRU can determine (e.g., select) a specific time to perform actions related to LTM. For example, the WTRU can perform one or more of the following processes.

[0171] The WTRU can perform early TA acquisition. For example, the WTRU can trigger a RACH to the target LTM cell. The WTRU can receive the TA value in the RAR. The RAR can be from the target cell and / or forwarded via the source cell. The WTRU can receive the TA value in the MAC CE that triggers cell handover. If no RAR / MAC CE is received, the WTRU can perform power adjustment and / or preamble retransmission to the target.

[0172] The WTRU can disable CSI reporting. A configured and / or defined window can indicate the time period (e.g., allowed and / or required) for the WTRU to disable CSI reporting to reduce uplink reporting overhead (and / or other conditions). CSI reporting can be reduced rather than disabled. For example, reduced CSI reporting may include a reduced number of cell and / or beam reports, and / or a reduced reporting frequency. CSI reporting to be disabled and / or reduced may include the target PCell, other candidate LTM cells, and / or one or more (e.g., all) LTM cells. When the window closes, the UE can resume CSI reporting.

[0173] The WTRU can enable CSI reporting. For example, the WTRU can (e.g., be required) perform and / or report CSI measurements on one or a subset of LTM candidate cells during a window.

[0174] The WTRU can perform LTM cell handover. A window can include (e.g., define) a time range and / or a condition range within which the WTRU can (e.g., is permitted) trigger LTM cell handover. The window can define the boundaries of the condition range and / or can be associated with one or more additional conditions. For example, if radio quality criteria measured within the time range are met, the window can include (e.g., define) the time range within which the WTRU can trigger LTM cell handover.

[0175] The WTRU can monitor the PDCCH on the target cell. The WTRU can be configured to monitor the scheduling PDSCH and / or the DCI that indicates one or more actions on the target cell, such as initiating a cell handover procedure.

[0176] The WTRU can perform beamforming request (BFR) and / or radio link monitoring (RLM) on the target cell. The WTRU can be configured to monitor beam failure detection (BFD) resources on the target cell during a window, and / or perform RLM on the target cell.

[0177] A WTRU can activate and / or deactivate one or more (e.g., certain) SCells. A WTRU can be configured with one or more specific SCells that should be active or inactive during the window.

[0178] After sending an LTM cell handover command, the WTRU / network behavior can be the same as in a traditional HO. That is, the serving cell / node may release WTRU resources / context and / or may not have DL / UL communication with the source cell after correctly receiving the LTM cell handover command. To implement modified execution time window behavior (e.g., as proposed herein), the source cell / node can retain WTRU resources / context at least until the maximum configured cell handover time / window so that communication between the source cell / node and the WTRU can be maintained. In the examples, the systems, methods, and apparatuses provided herein may include LTM conditional cells, wherein the source cell / WTRU can maintain connectivity with the source while the conditions for actually performing the LTM cell handover are being monitored.

[0179] This document provides examples of LTM execution triggers. In these examples, the WTRU can be provided with specific triggers for performing one or more of the aforementioned processes. These specific triggers can be provided in addition to using range configuration and / or a defined window. For example, the WTRU can perform LTM cell handover, trigger early TA acquisition (e.g., sending a random access preamble to the target cell), and / or can perform reduced CSI reporting, provided that it is within the range defined by the window and additionally meets one or more of the following criteria (e.g., it can be based on one or more measurements and / or predictions): one or more L3 measurement events; one or more (e.g., any) L1 measurement events and / or conditions; one or more (e.g., any) predicted L1 / L3 events; explicit indications from the network; and / or measured, predicted, or estimated throughput, error rate, buffer status, or QoS parameters.

[0180] The WTRU can perform LTM cell handover, trigger early TA acquisition (e.g., sending a random access preamble to the target cell), and / or can perform reduced CSI reporting, provided it is within the range defined by the window and meets one or more L3 measurement events. L3 measurement events may include one or more of the following: Event A1 (e.g., the serving cell becomes better than a threshold); Event A2 (e.g., the serving cell becomes worse than a threshold); Event A3 (neighboring cells become better than SpCell by an offset); Event A4 (neighboring cells become better than a threshold); Event A5 (SpCell becomes worse than threshold 1, while neighboring cells become better than threshold 2); Event A6 (neighboring cells become better than SCell by an offset); Event B1 (inter-RAT neighboring cells become better than a threshold); and / or Event B2 (Pcell becomes worse than threshold 1, and inter-RAT neighboring cells become better than threshold 2).

[0181] The WTRU may perform LTM cell handover, trigger early TA acquisition (e.g., send a random access preamble to the target cell), and / or perform reduced CSI reporting, provided that it is within the range defined by the window and meets one or more (e.g., any) L1 measurement events and / or conditions. For example, one or more (e.g., any events) provided (e.g., defined) herein (e.g., above) but using L1 / beam measurement to evaluate whether criteria or conditions are met.

[0182] The WTRU can perform LTM cell handover, trigger early TA acquisition (e.g., send a random access preamble to the target cell), and / or can perform reduced CSI reporting, provided it is within the range defined by the window and satisfies one or more (e.g., any) predicted L1 / L3 events. For example, using one or more of the measurements described herein (e.g., any measurements) (e.g., measurements listed below the measured and / or predicted CSI information / measurements associated with the measured and / or predicted CSI information).

[0183] The WTRU can perform LTM cell handover, trigger early TA acquisition (e.g., sending a random access preamble to the target cell), and / or can perform reduced CSI reporting, provided it is within the range defined by the window and meets explicit instructions from the network. For example, the WTRU can disable CSI reporting during a configured window, and / or (e.g., then) perform LTM cell handover based on the receipt of a MAC CE from the network (e.g., after receiving a MAC CE from the network).

[0184] This document provides an embodiment for an adjustable LTM handover (HO) execution window. The initial HO execution time window selection can be performed on the gNB side and / or indicated to the WTRU using, for example, an index of a pre-configured window position and / or length in the MAC CE that triggers the LTM cell handover. This can be based on reported and / or predicted radio conditions in, for example, cell A (e.g., the source cell) and B (e.g., the target cell), and the network can determine and / or indicate (e.g., appropriate) limits to minimize HO failures and / or RLFs and / or avoid excessively long waits (e.g., long resource reservations in the target cell).

[0185] The WTRU can determine the precise cell handover time within a configured window, taking into account factors such as real-time / instantaneous radio condition measurements, predicted measurements, and / or service / traffic forecasts. The WTRU can select the optimal time to perform LTM (Level Measure) to maximize throughput based on predicted throughput at cell A and / or cell B during the configured window. The WTRU can (e.g., further) determine a more precise window within the network (NW) configured window during which cell handover can be performed (e.g., throughput and / or failure probability are within a tolerance better than that provided by the NW configured window), and / or can report this to the NW to assist in AI model training.

[0186] The WTRU can receive configurations of LTM candidate cells and / or configurations of the allowed first handover window length. The configurations of LTM candidate cells and / or the allowed first handover window length can include an explicit list of length values ​​and / or enable one of multiple predefined tables. The window size can correspond to, for example, cell size / coverage / time / speed within the cell. The window size can be defined according to time, service and / or target cell RSRP range, location, etc. The configuration can include WTRU-triggered LTM cell handover conditions / criteria for triggering cell handover within the first window. The configuration can include conditions for selecting a second window and / or indications for the AI ​​model of a specific indicated first or second window length. The configuration can include an indication of the second window. The indication of the second window can include different actions taken by the WTRU during the first and second windows (e.g., a first window for LTM preparation steps, a second window for LTM execution).

[0187] WTRU can transmit Channel State Information (CSI) reports.

[0188] The WTRU can receive an LTM cell handover MAC CE, which includes an indication of the first window time position (e.g., time offset and / or system frame number (SFN)) and / or an indication of one of a plurality of predefined lengths. This can be determined on the NW side, for example, based on CSI reports and / or constraints on radio conditions / traffic volume based on NW predictions. The time offset can include (e.g., a pointer to a list of preconfigured values), an explicit SFN indication, an increment from the current time, etc.

[0189] The WTRU may perform specific LTM actions (e.g., preparation actions) during the first window. The WTRU may disable and / or minimize candidate cell CSI reporting during the first window (e.g., reporting on fewer beams and / or less frequently) (e.g., HO execution may be based on WTRU measurements and / or predictions without CSI reporting). For example, the WTRU may transmit acknowledgments before / when CSI reporting is suspended / reduced. The WTRU may perform early TA acquisition (e.g., random access channel (RACH) to the target) during the first window. For example, the WTRU may receive a random access response (RAR) including TA from the target cell and / or from the source. The WTRU may perform measurements and / or predictions to determine the location of the second window. For example, performing LTM preparation during the first duration window may include: disabling CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing early timing advance (TA) acquisition, and / or performing one or more measurements and / or one or more predictions to determine the second duration window.

[0190] The WTRU can determine (e.g., select) the location and / or length of a second HO window within a first HO window to determine the optimal cell handover time range, and / or the WTRU can determine (e.g., select) the time within the second window to perform cell handover. For example, the WTRU can determine the second duration window based at least on a first duration window and / or one or more conditions (e.g., as described herein). The second duration window can be a subset of the first duration window. The second window can include a variable location and / or a second (e.g., shorter) length. For example, the second window can be based on updated radio conditions and / or traffic forecasts (e.g., compared to reported and / or NW-determined forecasts). For example, the objective of the second window can be to maximize throughput during the HO window. Alternatively or alternatively, the second window can be determined (e.g., selected) based on explicit NW indications (e.g., NW configuration). The WTRU can determine (e.g., select) different AI measurement prediction models and / or window length selection criteria based on (e.g., depending on) the window length. For example, a shorter window can use (e.g., only) radio conditions. For example, a longer window can (e.g., allow) consideration of service aspects.

[0191] The WTRU can perform a second LTM action during the second window. For example, the WTRU can monitor the LTM triggering conditions to be met during the second window.

[0192] The WTRU can perform cell handover at a determined time and / or can transmit indications to other (e.g., new) cells. The WTRU can report the location of the determined second window and / or the conditions used for determination (e.g., radio measurements, number of packets or throughput in the HO time buffer, packet delay, packet loss, location, speed, etc.). The WTRU can send indications (e.g., one or more sequence numbers) of Hybrid Automatic Repeat Request (HARQ) and / or Radio Link Control (RLC) data PDUs that have been transmitted but whose respective acknowledgments have not yet been received (e.g., transmitted but not ACKed). The WTRU can indicate the reason for the HO time determination.

[0193] Figure 6 A flowchart is depicted, illustrating an example of optimizing the LTM process 600 using a dual-conditional window combined with artificial intelligence (AI) predictions.

[0194] At 608, WTRU 602 can receive messages (e.g., RRC reconfiguration) from cell A 604. RRC reconfiguration message 608 may include information for pre-configuring a list of LTM candidates (one or more) and / or HO window lengths. For example, the WTRU may receive configuration information from a network device via a first cell. The configuration information may include a low-layer triggered mobility (LTM) configuration associated with one or more candidate cells. The LTM configuration may indicate the radio resource (re)configuration to be applied when performing cell handover and / or handover to candidate cells among multiple candidate cells. This configuration may include WTRU-triggered LTM cell handover conditions for triggering cell handover within a first duration window, one or more conditions to be used to determine a second LTM window, and / or an indication of an artificial intelligence (AI) model to be used to determine the second duration window. The configuration information may include an indication of the length to be used for the first duration window selected from a plurality of predetermined lengths.

[0195] At 610, WTRU 602 can send a message (e.g., an RRC reconfiguration complete message) to, for example, cell A 604. At 612, as described herein, WTRU 602 can transmit a CSI report to cell A 604. For example, the WTRU can send a CSI report. The indication of the first LTM HO window can be associated with the CSI report.

[0196] At 614, WTRU 602 may receive a control MAC CE. WTRU may receive from the network equipment via a first cell an indication to perform a cell handover and / or a handover to a candidate cell among a plurality of candidate cells. This indication may include a first duration window. For example, the control MAC CE may include a cell handover indication, which may include a pointer to a target configuration and / or an indication of at least the length of the first window. WTRU 602 may perform one or more LTM preparation actions (e.g., disabling CSI reporting, triggering early TA acquisition on the target). Performing LTM preparation during the first duration window may include disabling CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing early timing advance (TA) acquisition, and / or performing one or more measurements and / or one or more predictions to determine a second duration window.

[0197] WTRU 602 can determine a second LTM HO window. WTRU 602 can determine a second window 615, in which LTM can be triggered, based on, for example, predicted CSI. WTRU 602 can determine the time for triggering LTM within the second window 615, for example, based on current radio conditions. For example, WTRU can determine a second duration window based at least on a first LTM HO window and / or one or more conditions (e.g., as described herein). WTRU can determine the start position and / or length of the second duration window. WTRU can determine the second duration window based on one or more conditions (e.g., as described herein). The one or more conditions may include: radio measurements (one or more); one or more packets (e.g., multiple) in the HO time buffer; throughput; packet delay; packet loss; location; velocity; and / or transmitted but unacknowledged HARQ data packets. The second duration window may be a subset of the first duration window. For example, the second duration window being a subset of the first duration window may include the first duration window being longer than the second duration window. The second duration window may include a start time, duration, and / or end time. Cell handover and / or handover (e.g., as described herein) may occur at the end of the second duration window.

[0198] At 616, WTRU 602 may send an indication to a second cell (e.g., cell B 606). The indication 616 to the second cell (e.g., cell B 606) may include MAC and / or RRC (e.g., may be sent via MAC and / or RRC). For example, WTRU may send information to network devices indicating a second duration window and / or one or more conditions for determining the second duration window.

[0199] Figure 7A process flow is described, which shows an example of using a dual conditional window combined with artificial intelligence (AI) prediction to optimize the LTM process 700.

[0200] At 702, the WTRU may receive the configuration of LTM candidate cells and / or the configuration of the allowed first handover window length. The WTRU may receive the configuration of LTM candidate cells (e.g., as described herein). The WTRU may be pre-configured with one or more LTM candidates (e.g., may include a list of HO window lengths). For example, the WTRU may receive configuration information from the network equipment via a first cell. The configuration information may include a low-layer triggered mobility (LTM) configuration associated with one or more candidate cells. The LTM configuration may indicate the radio resources to be (re)configured when performing cell handover and / or handover to candidate cells among multiple candidate cells. Additionally or alternatively, the WTRU may receive the configuration of a list of allowed first and / or second window lengths. Predefined window configurations (e.g., windows as described herein) may include explicit indications of length / range values, and / or enable one of multiple predefined tables and / or may correspond to, for example, cell size / coverage / time / speed within the cell. This configuration may include LTM cell handover conditions triggered by the WTRU, such as one or more conditions described herein.

[0201] The configuration may include one or more conditions to be used to determine (e.g., select) a second window, and / or indications of the AI ​​model to be used for a specific indication of the length of the first and / or second window. For example, the conditions for determining (e.g., selecting) the second window may be based on one or more (e.g., any) of the conditions described herein for triggering an LTM procedure. The configuration may include LTM cell handover conditions triggered by a WTRU for triggering a cell handover within a first duration window, one or more conditions to be used to determine the second duration window, and / or indications of the artificial intelligence (AI) model to be used to determine the second duration window. The configuration information may include an indication of the length to be used for the first duration window, selected from a plurality of predetermined lengths.

[0202] This configuration may include explicit instructions for configuring a second window. The configuration may include different actions to be taken during the first and second windows. For example, if criteria are met, the WTRU may (e.g., be required) perform LTM preparation steps (e.g., changes to CSI reporting behavior, early TA acquisition) in the first window, and the WTRU may be configured to perform LTM execution in the second window. Performing LTM preparation during the first duration window may include disabling CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing early timing advance (TA) acquisition, and / or performing one or more measurements and / or one or more predictions to determine the second duration window.

[0203] At position 704, the WTRU can transmit CSI reports. For example, the WTRU can send a CSI report. The indication of the first LTM HO window can be associated with the CSI report. The WTRU can perform CSI measurements on one or more candidate cell beams according to the received configuration and / or can report CSI measurements to the serving cell.

[0204] At 706, the WTRU may receive an LTM cell handover MAC CE, which includes an indication of a first window time position (e.g., time offset and / or SFN) and / or an indication of one or more (e.g., multiple) predefined lengths. For example, an indication associated with LTM cell handover and / or handover may be received via the MAC CE. The WTRU may receive from the network device via a first cell an indication of a cell handover and / or handover to be performed to a candidate cell among a plurality of candidate cells. This indication may include a first duration window. The WTRU may receive a MAC CE indicating a target configuration (e.g., including SpCell and / or one or more SCell configurations). The MAC CE may include an indication of window position and length. This indication may be a pointer, index, and / or reference to one or more of the values, parameters, and / or configurations provided herein (e.g., when receiving configuration information). For example, this document may provide an index to a list of window configurations (e.g., provided in 3), which is provided when the configuration of the LTM candidate cells and / or the configuration of the allowed first handover window length are received.

[0205] At 708, the WTRU can perform one or more first LTM actions during the first window. The WTRU can perform one or more first LTM actions, for example, according to this configuration. For instance, during the first window, the WTRU can stop reporting CSI measurements for the configured candidate cells and / or beams to reduce uplink resource overhead. When the WTRU stops CSI reporting, it can continue performing measurements to determine whether the conditions for LTM cell handover and / or the conditions for selecting the second window are met.

[0206] Additionally or alternatively, the WTRU may change the CSI measurement and / or reporting configuration during the first window. For example, measurements may be performed and / or reported based on a reduced frequency and / or the use of a reduced number of cells and / or beams.

[0207] In the example, the WTRU can be configured to perform early DL and / or UL synchronization procedures. For instance, the WTRU can be configured to perform a TA acquisition procedure, which may involve transmitting one or more PRACH preambles to the target cell(s) so that the gNB can estimate the TA value provided to the WTRU.

[0208] In the example, WTRU can monitor LTM cell handover conditions throughout the first window.

[0209] At 710, the WTRU can determine a second LTM HO window. The WTRU can select the location and / or length of the second HO window within the first HO window. The WTRU can determine (e.g., select) the location and / or length of the second window. For example, the WTRU can determine the second duration window based at least on the first duration window and / or one or more conditions (e.g., as described herein). The WTRU can determine the start location and / or length of the second duration window. The WTRU can determine the second duration window based on one or more conditions (e.g., as described herein). The one or more conditions may include: radio measurements (one or more); one or more packets in the HO time buffer; throughput; packet delay; packet loss; location; velocity; and / or transmitted but unacknowledged HARQ data packets. The second duration window can be a subset of the first duration window. For example, the second duration window being a subset of the first duration window may include the first duration window being longer than the second duration window. The second duration window may include a start time, duration, and / or end time. Cell handover (e.g., as described herein) may occur at the end of the second duration window.

[0210] In the example, the WTRU can utilize one or more AI predictions to determine the size and / or location of the second window, for example, using one or more (e.g., any) inputs listed herein. The AI ​​model can be based on (e.g., dependent on) the characteristics of the first window (e.g., length). The AI ​​model can be explicitly instructed by the gNB, for example, in MAC CE-triggered cell handover and / or in RRC configuration.

[0211] In the example, additionally or alternatively, WTRU may determine (e.g., select) the characteristics of the second window (e.g., start time, duration, etc.) based on explicit network indications (e.g., the second window may be indicated in a manner similar to the first window).

[0212] In the example, additionally or alternatively, the WTRU may use radio quality measurements (such as any of those listed in this article) to determine the second window.

[0213] In the example, WTRU uses one or more (e.g., any) other types of information (e.g., any of those listed in this article) to determine the second window.

[0214] At 712, the WTRU can perform a second LTM action during the second window. The WTRU can perform one or more second LTM actions, for example, according to this configuration. For example, the WTRU can monitor (e.g., specific) one or more LTM candidate cells and / or beams to determine whether LTM execution conditions (one or more) (e.g., any of the conditions listed herein) are met.

[0215] At point 714, the WTRU may perform a cell handover at a determined time and / or may transmit indications to other (e.g., new) cells. The WTRU may trigger an LTM cell handover and / or may be reconfigured (e.g., handover) to a target candidate SpCell (e.g., and / or SCell, if configured). Additionally or alternatively, the WTRU may transmit reports as described herein (e.g., information reported by the WTRU). For example, the WTRU may send to network devices an indication of a second duration window (e.g., information indicating a second duration window) and / or an indication of one or more conditions for determining the second duration window.

[0216] NW may impose one or more restrictions, for example, based on key performance indicators (KPIs) of system performance (e.g., HOF, RLF based on radio conditions), while including (e.g., allowing) WTRU the freedom to make optimal decisions based on internal forecasts (e.g., based on forecasted traffic volume and / or updated radio conditions).

[0217] NW can adapt the window based on the latest / current situation and / or provide dynamic indications. WTRU can (e.g., further) adapt the window and / or send (e.g., provide) feedback to improve NW predictions.

[0218] During the AI / ML-based optimization transition, throughput can be maximized.

[0219] The amount of CSI reporting overhead can be reduced; LTM can be based on (e.g., dependent on) frequent L1 reports to achieve optimal cell handover time. If CSI reporting can be turned off during HO execution, resource overhead can be reduced.

[0220] Using the embodiments described herein (e.g., an adjustable LTM HO execution window), the NW can be allowed to control the appropriate handover time range based on (e.g., primarily) conventional methods (e.g., radio conditions can primarily indicate the appropriate cell handover time), and the WTRU can be allowed to (e.g., further) adjust based on service and / or other considerations. AI prediction models can be improved (e.g., for training the NW model) and / or the overall handover performance in the system can be improved. The NW can optimize the timing of PDCCH commands to obtain TA. If an outage occurs, such as the WTRU having to retune to the target frequency to transmit RA, the NW may be able to adjust the timing based on feedback from the WTRU and / or from machine learning to minimize the outage.

[0221] This article provides examples for rollback and / or reporting when the predicted LTM HO condition is not met.

[0222] The NW can determine the backoff cell based on radio conditions and / or determine the target cell based on prediction. The gNB can indicate an LTM handover to the target cell before the conditions are met, and / or can indicate backoff conditions (e.g., it could be a third cell, and / or it could be the original source cell).

[0223] For example, if the predicted conditions are met during the time window (e.g., as described herein), the WTRU can trigger a cell handover to the indicated target cell. If the conditions are not met (e.g., then), the WTRU can trigger a backoff. The WTRU can indicate failure to the backoff cell.

[0224] The WTRU can receive the configuration of LTM candidate cells and / or the configuration of one or more predefined backoff / failure conditions. The conditions (one or more) may include measured and / or predicted radio quality metrics, and / or one or more time window lengths. The conditions (one or more) may be based on whether the window determined by the WTRU falls within the NW prediction window.

[0225] WTRU can transmit CSI reports (e.g., measured and / or predicted).

[0226] The WTRU can receive an LTM cell handover MAC CE, which includes indications of one or more target cells, indications of triggering conditions (one or more), and / or indications of backoff actions. The backoff action may be to a candidate target cell that triggered the LTM, and / or it may be to back off to the source cell + send a measurement report. The triggering conditions, target cells, and / or backoff cells can be pre-configured (e.g., the NW can pre-configure the WTRU). The association between the target / backoff / conditions (e.g., in between) can be partially and / or fully pre-configured and / or dynamically indicated in the MAC CE.

[0227] The WTRU can perform LTM preparation actions (e.g., the WTRU can disable CSI reporting and / or perform early TA acquisition during the window). Performing LTM preparation during the first duration window may include disabling CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing early timing advance (TA) acquisition, and / or performing one or more measurements and / or one or more forecasts to determine the second duration window.

[0228] The WTRU can determine whether backoff / failure conditions are met. For example, the WTRU can determine whether a measured radio condition criterion is not met and / or whether a TA was not successfully obtained and / or is no longer valid for one of the target cells within the indicated time window (e.g., measurement mismatch with indicated prediction).

[0229] The WTRU can determine, based on WTRU measurements / predictions, an alternative window (e.g., an alternative to the indicated window) where the switching is estimated to be successfully completed, and / or can indicate windows (one or more) determined by the WTRU.

[0230] The WTRU can trigger LTM to the fallback cell and / or can transmit reports on at least the radio conditions, window calculations, etc. of the indicated / failed target cell as measured within the time window.

[0231] For example, if the fallback cell is the original cell, the WTRU can resume LTM preparation actions (e.g., the WTRU can resume CSI reporting).

[0232] Figure 8 A flowchart is depicted illustrating an exemplary rollback scenario for optimizing LTM process 800 using a dual conditional window combined with artificial intelligence (AI) prediction.

[0233] At 810, WTRU 802 can receive configuration information (e.g., RRC configuration) from cell A 804 (e.g., the source cell). The configuration information may include information associated with pre-configured LTM candidates and / or may include backoff triggering conditions. For example, the WTRU may receive configuration information from a network device via a first cell. The configuration information may include low-layer triggered mobility (LTM) configurations associated with one or more candidate cells. The LTM configuration may indicate the radio resource (re)configuration to be applied during cell handover and / or handover to candidate cells among multiple candidate cells.

[0234] At 812, WTRU 802 can send a reconfiguration message (e.g., via an RRC reconfiguration complete message) to cell A 804. At 814, WTRU 802 can send a CSI report to cell A 804.

[0235] At 816, WTRU 802 can receive a control MAC CE from cell A 804. For example, the WTRU can receive an indication from the network equipment via a first cell to perform a cell handover and / or handover to a candidate cell among a plurality of candidate cells. This indication may include a first duration window. HO decision 815 may include a gNB indication of the target cell and / or conditions (one or more) to be met (e.g., RSRP is higher than a threshold within the time window). The gNB and / or HO determination may indicate a fallback cell (e.g., the source cell or another cell). Control MAC CE 816 may include a cell handover indication that includes a pointer to the target configuration, associated conditions, and / or a fallback cell in case the handover to the target cell is unsuccessful. WTRU 802 may stop and / or reduce CSI reporting. WTRU 802 may determine whether the fallback conditions are met within the time window. If this condition is met, WTRU 802 can trigger a CSI report for cell handover to the fallback cell (e.g., cell C 808) and / or the target cell (e.g., cell B 806) and / or recovery to the source cell (e.g., cell A 804).

[0236] At 818, WTRU 802 can send an indication to the fallback cell that the intended handover to the target cell has failed. For example, the handover might fail based on one or more conditions not being met within a time window.

[0237] At 820, WTRU 802 can send indications to the fallback cell (e.g., cell C808) via indication messages (e.g., MAC and / or RRC). WTRU 802 can report the optimal window calculated by WTRU (e.g., occurring before or after the optimal window indicated by NW).

[0238] Figure 9A process flowchart is depicted, illustrating an exemplary rollback scenario for optimizing LTM process 900 using a dual conditional window combined with artificial intelligence (AI) prediction.

[0239] At 902, the WTRU may receive the configuration of LTM candidate cells and / or the configuration of one or more predefined failure conditions. The WTRU may receive the configuration of LTM candidate cells (e.g., as described herein). Alternatively or additionally, the WTRU may receive the configuration of conditions, windows (e.g., as described herein), and / or one or more failure conditions for performing WTRU-triggered LTM cell handover. For example, the WTRU may receive configuration information from a network device via a first cell. The configuration information may include low-layer triggered mobility (LTM) configurations associated with one or more candidate cells. The LTM configuration may indicate the radio resource (re)configuration to be applied when performing cell handover and / or handover to candidate cells among multiple candidate cells. Failure conditions may include one or more of the following: the cell handover time determined by the WTRU may not fall within the indicated window; the window determined by the WTRU may not match the window indicated by the NW; the window determined by the WTRU may differ from the window indicated by the NW by a predefined threshold (e.g., a threshold relative to the window length or location); the WTRU may detect beam failure and / or radio link failure on the source or target cell; the WTRU may be unable to obtain TA from the target cell; the measured radio quality of the target cell may not meet the configured threshold within the window; and / or the WTRU may fail to complete the handover within a configured time limit (e.g., it may fail to decode the PDCCH on the target, and / or the random access procedure may fail).

[0240] At position 904, the WTRU can transmit CSI reports. The WTRU can perform CSI measurements on one or more candidate cell beams and / or report CSI measurements to the serving cell, depending on the received configuration.

[0241] At 906, the WTRU may receive an LTM cell handover MAC CE, which includes an indication of one or more target cells, an indication of triggering conditions (one or more), and / or an indication of fallback behavior. The WTRU may receive a MAC CE indicating a target configuration (e.g., including SpCell and / or one or more SCell configurations). For example, the WTRU may receive from a network device via a first cell an indication to perform a cell handover and / or handover to a candidate cell among a plurality of candidate cells. This indication may include a first duration window. The MAC CE may (e.g., further) include an indication of fallback behavior. This fallback behavior indication may be a pointer, index, and / or reference to one or more of the values, parameters, and / or configurations provided herein. The fallback behavior indication may include an identifier of the fallback (e.g., alternative) cell to which a cell handover to be performed if a failure condition is met.

[0242] At 908, the WTRU can perform one or more LTM preparation actions (e.g., stop CSI reporting). The WTRU can perform LTM preparation actions for the indicated target based on this configuration. For example, during the first window, the WTRU can stop reporting configured candidate cell and / or beam CSI measurements to reduce uplink resource overhead, as described herein. Performing LTM preparation during the first duration window may include stopping CSI reporting, transmitting Hybrid Automatic Repeat Request (HARQ) feedback, performing Early Timing Advance (TA) acquisition, and / or performing one or more measurements and / or one or more predictions to determine a second duration window.

[0243] At 910, the WTRU can determine that backoff / failure conditions are met. For example, the WTRU can determine whether a measured radio condition criterion is not met and / or whether a TA was not successfully obtained and / or is no longer valid for one of the target cells within the indicated time window (e.g., measurement mismatch with indicated prediction). The WTRU can determine that one or more failure condition configurations have been met (e.g., as described herein).

[0244] At 912, the WTRU can determine, based on WTRU measurements / predictions, an alternative window (e.g., a replacement for the indicated window) where the switching is estimated to be successfully completed, and / or an indication of the window (one or more) determined by the WTRU. The WTRU can determine, for example, an alternative window that the WTRU may have already calculated during its period, based on one or more (e.g., any) of the predicted and / or measured metrics described herein, which would achieve a successful switching (e.g., avoiding detected failure conditions by considering the causes of failure).

[0245] At point 914, the WTRU can trigger LTM to the fallback cell and / or can transmit a report at least regarding the radio conditions, window calculations, etc., of the indicated / failed target cell as measured within the time window. The WTRU can trigger a configured fallback, which can be a return to the original (e.g., source) cell and / or a reconfiguration to an alternative target cell. The WTRU can transmit a report to the fallback cell including information related to the failure (e.g., as described herein), which has an indication of the window determined by the WTRU.

[0246] At point 916, if the fallback cell is the original cell, the WTRU can resume LTM preparation actions (e.g., resume CSI reporting). If the fallback cell is the original cell, the WTRU can resume one or more (e.g., any) LTM preparation actions. For example, if the WTRU stops reporting CSI measurements during the window, the WTRU can resume CSI measurement reporting upon detecting a failure, allowing the gNB to use the measurements to configure alternative mobility targets.

[0247] If the predicted LTM HO condition is not met, backoff and reporting can include the NW attempting a faster handover by using a predicted event that occurs in the future. If the event is not met, backoff can be used for, for example, a conventional method for macro / coverage cells. For example, if the system, method, and apparatus include an indication of condition not being met sent to the source cell, the NW can use measurement reporting to trigger a handover at the appropriate time. The systems, methods, and apparatus of this invention can reduce CSI reporting overhead and / or attempt to perform a handover triggered by the WTRU, but if the CSI report is unsuccessful within the indicated time, CSI reporting is resumed to perform a (e.g., more conventional) handover based on the UL report. The systems, methods, and apparatus of this invention can attempt a more aggressive handover to a smaller cell, but if this is unsuccessful, trigger a handover to another target, such as a larger, more stable cell with greater coverage. The systems, methods, and apparatus of this invention can use this approach for model training, such as attempting to predict handovers and / or collecting information about the causes of errors.

[0248] This document describes embodiments of different target configurations (e.g., active Scells) windows based on (e.g., depending on) the selection (e.g., determination) of WTRUs within a main window (e.g., PCell switching time). WTRUs can be provided with (e.g., NW can be configured) one or more target configurations (e.g., which Scells can be activated), which are determined (e.g., selected) based on (e.g., depending on) the precise WTRU conditions that trigger SpCell changes, thereby enabling the achievement of an optimal target configuration.

[0249] The WTRU can receive configurations of LTM candidate cells, first SpCell change conditions, and / or configurations of one or more (e.g., multiple) target (e.g., active SCell) configurations, where each configuration can be associated with a second condition (e.g., a time window and / or RSRP range) to be applied based on (e.g., depending on) when the first SpCell change condition is met. For example, different sets of Scells (e.g., one or more different configurations) can be activated based on (e.g., depending on) the time when the SpCell handover criterion (e.g., the first condition) is met (the second condition). For example, the SpCell cell handover decision can be based on the current SpCell being below a threshold, and the set of activated SCells can be based on (e.g., depending on) one or more of the target cells (e.g., if the target SpCell is in range 1, then SCell 1 is activated, and if it is in range 2, then SCell 2 is activated). For example, the WTRU can be provided with a SpCell change window. Based on (e.g., depending on) the actual cell handover decision time (e.g., based on predictions made by the system, method, and / or apparatus provided herein), (e.g., then) the WTRU can activate one or more different sets of SCells.

[0250] WTRU can transmit CSI reports.

[0251] The WTRU can receive cell handover commands, which include an indication of the PCell handover time window.

[0252] WTRU can determine the optimal PCell switching time within the indicated window. WTRU can also consider the optimal SCell in AI / ML model evaluation and / or (e.g., also) determine (e.g., select) the HO trigger time based on the SCell.

[0253] For example, based on (e.g., depending on) the determined (e.g., selected) PCell switching time (e.g., and / or other conditions), the WTRU can determine (e.g., select) the appropriate target configuration. For example, if a PCell switch is performed during a first duration within a window, (e.g., then) a first Scell ​​set can be activated; otherwise, (e.g.,) a second (e.g., Scell) set can be activated.

[0254] The WTRU can perform cell handover at a defined time and / or can transmit instructions to other (e.g., new) cells with the selected configuration.

[0255] Figure 10A potential scenario is illustrated where one or more (e.g., multiple) target configurations can be provided, and / or selected based on (e.g., depending on) the Pcell handover timing 1000. For example, consider a scenario where the WTRU can be served by PCell 11001 (e.g., the source cell) and / or has been configured to evaluate conditions for triggering an LTM cell handover to PCell 2 1002 (e.g., the target cell). A (e.g., a first) window 1004 (e.g., as described herein) can be provided to the WTRU 1003 to evaluate and / or determine (e.g., select) the most suitable handover time. For example, the first duration window can include potential target SCells. The optimal SCell can be different based on the PCell handover time. Based on (e.g., depending on) the WTRU determination (e.g., selection), one or more different SCells can be available / suitable (e.g., because the WTRU 1003 can move within the coverage of multiple smaller SCells). It may be advantageous for the WTRU 1003 to (e.g., automatically) apply the most suitable configuration for the selected PCell handover time.

[0256] Figure 11 A flowchart is depicted illustrating an exemplary scenario of selecting one or more (e.g., multiple) target configurations 1100. At 1108, WTRU 1102 may receive a message (e.g., RRC configuration) from cell A 1104. This message may include pre-configured LTM candidates and / or may include a list of HO window lengths. For example, the WTRU may receive configuration information from a network device via a first cell. The configuration information may include low-layer triggered mobility (LTM) configurations associated with one or more candidate cells. The LTM configuration may indicate the radio resource (re)configuration to be applied when performing cell handover and / or handover to candidate cells among the multiple candidate cells. At 1110, WTRU 1102 may send a message (e.g., RRC reconfiguration complete) to cell A 1104. At 1112, WTRU 1102 may send a CSI report (e.g., to cell A 1104). At 1114, WTRU 1102 can receive a control MAC CE, which may include a cell handover indication (e.g., a pointer to a target configuration and / or an indication of the window length). Figure 11As shown, the network (e.g., the currently serving cell A1104) can make cell handover decisions and / or can indicate the decisions for performing cell handover in the MAC CE. The determination on the WTRU side can consider the timing (e.g., the exact timing) of when to perform the handover, and / or, based on that timing, what additional configurations to apply (e.g., adding cell 2 as a secondary cell if the handover to the target is completed within window 1; adding cell 3 as a secondary cell instead of cell 2 if the handover is completed within window 2, etc.). At 1115, WTRU 1102 can determine the HO trigger time within the first window. At 1116, WTRU 1102 can send indications (e.g., MAC and / or RRC) to cell B 1106. For example, if the determined (e.g., the selected) PCell handover time is within the second window, WTRU 1102 can activate the first target configuration (e.g., SCell 1). For example, if the determined (e.g., selected) PCell switching time is within the third window, WTRU 1102 can activate the second target configuration (e.g., SCell 2).

[0257] Figure 12 A process flowchart is depicted, illustrating an exemplary scenario of selecting one or more (e.g., multiple) target configurations.

[0258] At 1202, the WTRU may receive configurations of LTM candidate cells, first (e.g., SpCell) change conditions, and / or configurations of one or more (e.g., multiple) target (e.g., active SCell) configurations, wherein each configuration may be associated with a second condition (e.g., time window and / or RSRP range) to be applied based on (e.g., depending on) when the first SpCell change condition is met. The WTRU may receive configurations of LTM candidate cells (e.g., as described herein) and / or the first condition (e.g., LTM execution triggering as described herein). For example, the WTRU may receive configuration information from a network device via a first cell. This configuration information may include a first low-layer triggered mobility (LTM) HO configuration associated with one or more candidate cells. The LTM configuration may indicate the radio resource (re)configuration to be applied during cell handover and / or handover to candidate cells among multiple candidate cells. For at least one of the LTM candidate SpCells, the WTRU may be provided with one or more (e.g., multiple) target configurations associated with the second condition. For example, the WTRU may be provided with one or more (e.g., multiple) SCell configurations, and / or the active SCell may be based on (e.g., depending on) the LTM cell handover time selected within the configured window.

[0259] In the example, one or more (e.g., multiple) target configurations may include one or more of the following: SCell activation / deactivation state; one or more of RRCReconfiguration, CellGroupConfig, SpCellConfig and / or SCellConfig (e.g., all and / or any part); measurement configuration (e.g., SSB and / or CSI-RS resource configuration, CSI report configuration (one or more), RRC measurement event configuration, RRC measurement report configuration and / or neighboring cell / carrier list); MAC configuration; RLC configuration; PDCP configuration; radio bearer configuration; physical channel configuration (e.g., PDCCH, PDSCH); discontinuous reception (DRX) / discontinuous transmission (DTX) configuration; cell group configuration (e.g., secondary cell group (SCG), primary cell group (MCG)); configuration grant configuration; modulation and coding scheme (MCS); and / or random access parameters (e.g., preamble allocation, 2-step / 4-step procedure).

[0260] At 1204, the WTRU can transmit CSI reports. The WTRU can perform CSI measurements on one or more candidate cell beams and / or report CSI measurements to the serving cell, depending on the received configuration.

[0261] At 1206, the WTRU can receive an LTM cell handover MAC CE, which includes an indication of the first window. The WTRU can also receive a MAC CE indicating the target configuration (e.g., including SpCell and / or one or more SCell configurations).

[0262] At 1208, the WTRU can determine the optimal SpCell handover time within the indicated first window, for example, based on a first condition. The WTRU can use (e.g., based on the conditions described herein) a configured LTM trigger (e.g., the first) condition to select the optimal cell handover time.

[0263] The WTRU can, for example, determine (e.g., select) the target SCell configuration corresponding to the determined optimal SpCell switchover time based on a second condition. The WTRU can also determine (e.g., select) the target configuration corresponding to the selected optimal LTM trigger based on a second condition (e.g., based on the conditions described herein).

[0264] At 1210, WTRU may determine (e.g., select) LTM handover time based on a first condition (e.g., based on predicted throughput or based on source and / or target cell RSRP) or may determine (e.g., select) target SCell configuration based on a second condition (e.g., based on target cell RSRP and / or based on the handover time of the selected cell within the first window falling within the second window).

[0265] At 1212, the WTRU may (e.g., by using a selected configuration) perform an LTM cell handover at a determined time and / or may transmit an indication of the selected configuration to the new cell. The WTRU may perform an LTM cell handover at a selected time using the selected target configuration, and / or may transmit a report to the network that at least indicates the selected configuration. In the example, the report may also include one or more of the WTRU reporting information described herein.

[0266] One or more target CA (e.g., PCell + SCell) configurations can be provided, and / or the optimal target CA configuration (e.g., a CA configuration used to achieve throughput) can be activated based on (e.g., depending on) (e.g., to achieve coverage) the selected PCell switching time.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Configuration information is received from a network device via a first cell, wherein the configuration information includes an indication of a first low-layer triggered mobility (LTM) configuration associated with one or more candidate cells, wherein the LTM configuration indicates the radio resource configuration to be applied when a handover to a candidate cell among a plurality of candidate cells is performed; The network device receives an indication from the first cell to perform a handover to one of the plurality of candidate cells, wherein the indication includes a first duration window; A second duration window is determined based at least on the first duration window and one or more conditions, wherein the second duration window is a subset of the first duration window; as well as The network device is sent information indicating the second duration window and one or more conditions for determining the second duration window.

2. The WTRU of claim 1, wherein the processor is configured to perform the handover according to the radio resource configuration, and wherein the processor is configured to perform LTM preparation during the beginning of the first duration window.

3. The WTRU of claim 2, wherein the processor is configured to perform LTM preparation during the first duration window, comprising: The processor is configured to: Turn off Channel State Information (CSI) reporting. Transmit Hybrid Automatic Repeat Request (HARQ) feedback. Perform early timing advance (TA) fetch, or Perform one or more measurements or one or more predictions to determine the second duration window.

4. The WTRU of claim 1, wherein the configuration information includes LTM cell handover conditions triggered by the WTRU for triggering cell handover within the first duration window, one or more conditions to be used to determine the second duration window, or an indication of an artificial intelligence (AI) model to be used to determine the second duration window.

5. The WTRU of claim 1, wherein the configuration information includes an indication of the length to be used for the first duration window, selected from a plurality of predefined lengths.

6. The WTRU of claim 1, wherein the instruction is received via a Media Access Control (MAC) control element (CE).

7. The WTRU of claim 1, wherein the processor is configured to determine the second duration window by: The processor is configured to determine the start position and length of the second duration window.

8. The WTRU of claim 1, wherein the second duration window being a subset of the first duration window comprises: The first duration window is longer than the second duration window, and the second duration window includes a start time, a duration, or an end time, and cell handover occurs at the end time of the second duration window.

9. The WTRU of claim 1, wherein the processor is configured to transmit a Channel State Information (CSI) report, wherein an indication of a first LTM HO window is associated with the CSI report.

10. The WTRU of claim 1, wherein the processor is configured to determine the second duration window based on one or more conditions, wherein the one or more conditions include one or more of the following: radio measurements, number of packets in the HO time buffer, throughput, packet delay, packet loss, location, speed, and transmitted but unacknowledged Hybrid Automatic Repeat Request (HARQ) data packets.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Configuration information is received from a network device via a first cell, wherein the configuration information includes an indication of a first low-layer triggered mobility (LTM) configuration associated with one or more candidate cells, wherein the LTM configuration indicates the radio resource configuration to be applied when a handover to a candidate cell among a plurality of candidate cells is performed; The network device receives an indication to perform a handover to one of the plurality of candidate cells via a first cell, wherein the indication includes a first duration window; A second duration window is determined based at least on the first duration window and one or more conditions, wherein the second duration window is a subset of the first duration window; as well as The network device is sent information indicating the second duration window and one or more conditions for determining the second duration window.

12. The method of claim 11, further comprising performing a handover based on the radio resource configuration, and further comprising performing LTM preparation during the start of the first duration window.

13. The method of claim 12, wherein performing LTM preparation during the first duration window comprises: Turn off Channel State Information (CSI) reporting. Transmit Hybrid Automatic Repeat Request (HARQ) feedback. Perform early timing advance (TA) fetch, or Perform one or more measurements or one or more predictions to determine the second duration window.

14. The method of claim 11, wherein the configuration information includes LTM cell handover conditions triggered by a WTRU for triggering cell handover in the first duration window, one or more conditions to be used to determine the second duration window, or an indication of an artificial intelligence (AI) model to be used to determine the second duration window.

15. The method of claim 11, wherein the configuration information includes an indication of the length to be used for the first duration window, selected from a plurality of predefined lengths.

16. The method of claim 11, wherein the instruction is received via a Media Access Control (MAC) control element (CE).

17. The method of claim 11, wherein determining the second duration window comprises: Determine the starting position and length of the second duration window.

18. The method of claim 11, wherein the second duration window being a subset of the first duration window comprises: The first duration window is longer than the second duration window, and the second duration window includes a start time, a duration, or an end time, and cell handover occurs at the end time of the second duration window.

19. The method of claim 11, further comprising transmitting a channel state information (CSI) report, wherein an indication of the first LTMHO window is associated with the CSI report.

20. The method of claim 1, wherein the second duration window is determined based on one or more conditions, wherein the one or more conditions include one or more of the following: radio measurements, number of packets in the HO time buffer, throughput, packet delay, packet loss, location, speed, and transmitted but unacknowledged Hybrid Automatic Repeat Request (HARQ) data packets.