Methods, architectures, apparatuses and systems for radio access procedure based on aiml prediction

Abstract

Procedures, methods, architectures, apparatuses, systems, devices, and computer program products comprising a wireless transmit / receive unit (WTRU) configured for: receiving, from a network node, configuration information indicating a plurality of candidate and serving cells and triggering conditions for triggering a random access procedure towards a candidate cell, wherein the triggering conditions are at least based on predicted measurements and current measurements; performing current measurements of the plurality of candidate and serving cells and measurement prediction of the plurality of candidate and serving cells; determining a level of confidence associated with the measurement prediction of the plurality of candidate and serving cells; and performing a random access procedure to a target cell, based on the level of confidence associated with the measurement prediction, and wherein the target cell is a candidate cell among the plurality of the candidate and serving cells.

Description

METHODS, ARCHITECTURES, APPARATUSES AND SYSTEMS FOR RADIO ACCESS PROCEDURE BASED ON AIML PREDICTIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 534,671 filed August 25, 2023, which is incorporated herein by reference in its entirety.BACKGROUND

[0002] The present disclosure is generally directed to the fields of communications, software and encoding, including, for example, to methods, architectures, apparatuses, systems directed to mobility enhancements, for example to methods, apparatus and systems using artificial intelligence / machine learning (AIML) based mechanisms to improve the resource utilization of random access channel (RACH) less handover procedure.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures (FIGs.) and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref.") in the FIGs. indicate like elements, and wherein:

[0004] FIG. 1 A is a system diagram illustrating an example communications system;

[0005] FIG. IB is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A;

[0006] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A;

[0007] FIG. ID is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A;

[0008] FIG. 2 illustrates an example of high-level measurement model;

[0009] FIG. 3 depicts an example of a L1 / L2 based inter-cell mobility (LTM) operation;

[0010] FIG. 4 is a diagram illustrating an example of a LTM baseline procedure;

[0011] FIG. 5 illustrates examples of a 2-step and 4-step RACH procedures;

[0012] FIG. 6 illustrates an example of the time series prediction for a reference signal received power;

[0013] FIG. 7 depicts an example procedure for radio access procedure based on AIML prediction;

[0014] FIG. 8 depicts an example procedure for activating / deactivating configured grants for random access channel less handover;

[0015] FIG. 9 depicts an example procedure for performance monitoring for AIML based actions; and

[0016] FIG. 10 depicts another example procedure for radio access procedure based on AIML prediction.DETAILED DESCRIPTION

[0017] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed or otherwise provided explicitly, implicitly and / or inherently (collectively "provided") herein. Although various embodiments are described and / or claimed herein in which an apparatus, system, device, etc. and / or any element thereof carries out an operation, process, algorithm, function, etc. and / or any portion thereof, it is to be understood that any embodiments described and / or claimed herein assume that any apparatus, system, device, etc. and / or any element thereof is configured to carry out any operation, process, algorithm, function, etc. and / or any portion thereof.

[0018] Example Communications System

[0019] The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to FIGs. 1A-1D, where various elements of the network may utilize, perform, be arranged in accordance with and / or be adapted and / or configured for the methods, apparatuses and systems provided herein.

[0020] FIG. 1A is a system diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discreet Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block- filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0021] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or a "STA", may be configured to transmit and / or receive wireless signals and may include (or be) a user equipment (WTRU (e.g., UE)), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a headmounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU (e.g., UE).

[0022] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, e.g., to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the networks 112. By way of example, the base stations 114a, 114b may be any of a base transceiver station (BTS), a Node-B (NB), an eNode-B (eNB), a Home Node-B (HNB), a Home eNode-B (HeNB), a gNode-B (network node (e.g., gNB)), a NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0024] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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

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

[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface 116 using New Radio (NR).

[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b,102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a network node (e.g., gNB)).

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0030] The base station 114b in FIG. 1 A may be a wireless router, Home Node-B, Home eNode- B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0031] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing any of a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0032] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 114 or a different RAT.

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

[0034] FIG. IB is a system diagram illustrating an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0035] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together, e.g., in an electronic package or chip.

[0036] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In an embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0037] Although the transmit / receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0038] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

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

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

[0041] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0042] The processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (e.g., for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The elements / peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0044] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology tocommunicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0045] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0046] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and / or downlink (DL), and the like. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0047] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the CN operator.

[0048] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0049] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0050] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0051] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0052] Although the WTRU is described in FIGs. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0053] In representative embodiments, the other network 112 may be a WLAN.

[0054] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802. l ie DLS or an 802.1 Iz tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc" mode of communication.

[0055] When using the 802.1 lac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense theprimary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0056] High throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadj acent 20 MHz channel to form a 40 MHz wide channel.

[0057] Very high throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse fast fourier transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operation for the 80+80 configuration may be reversed, and the combined data may be sent to a medium access control (MAC) layer, entity, etc.

[0058] Sub 1 GHz modes of operation are supported by 802.1 laf and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.1 laf and 802.1 lah relative to those used in802.1 In, and 802.1 lac. 802.1 laf supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.1 lah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment,802.1 lah may support meter type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0059] WLAN systems, which may support multiple channels, and channel bandwidths, such as802.1 In, 802.1 lac, 802.1 laf, and 802.1 lah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.1 lah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode,even if the AP, and other ST As in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0060] In the United States, the available frequency bands, which may be used by 802.1 lah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 lah is 6 MHz to 26 MHz depending on the country code.

[0061] FIG. ID is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0062] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, 102c. Thus, the network node (e.g., gNB) 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the network node (e.g., gNB) 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from network node (e.g., gNB) 180a and network node (e.g., gNB) 180b (and / or network node (e.g., gNB) 180c).

[0063] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various orscalable lengths (e.g., including a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0064] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non- standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non- standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0065] Each of the network node (e.g., gNB)s 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like. As shown in FIG. ID, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0066] The CN 115 shown in FIG. ID may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0067] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be usedby the AMF 182a, 182b, e.g., to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0068] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU (e.g., UE) IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP -based, non-IP based, Ethernet-based, and the like.

[0069] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, e.g., to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0070] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0071] In view of FIGs. 1 A-1D, and the corresponding description of FIGs. 1 A-1D, one or more, or all, of the functions described herein with regard to any of: WTRUs 102a-d, base stations 114a- b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, network node (e.g., gNB)s 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element(s) / device(s) describedherein, may be performed by one or more emulation elements / devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0072] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0073] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0074] Introduction

[0075] Provided below are acronyms / abbreviations for terms and phrases commonly used in this application:ACK AcknowledgementAl Artificial IntelligenceBLER Block Error RateBWP Bandwidth PartCA Carrier aggregationCAP Channel Access PriorityCAPC Channel access priority classCCA Clear Channel AssessmentCCE Control Channel ElementCE Control ElementCG Configured grant or cell groupCHO Conditional handoverCP Cyclic PrefixCP-OFDM Conventional OFDM (relying on cyclic prefix)CPA Conditional PsCell additionCPAC Conditional PsCell addition / changeCPC Conditional PsCell changeCQI Channel Quality IndicatorCRC Cyclic Redundancy CheckCSI Channel State InformationCW Contention WindowCWS Contention Window SizeCO Channel OccupancyDAI Downlink Assignment IndexDC Dual connectivityDCI Downlink Control InformationDFI Downlink feedback informationDG Dynamic grantDL DownlinkDM-RS Demodulation Reference SignalDRB Data Radio Bearer eLAA enhanced Licensed Assisted AccessFeLAA Further enhanced Licensed Assisted AccessHARQ Hybrid Automatic Repeat RequestLAA License Assisted AccessLBT Listen-Before-TalkLTE Long Term Evolution e.g., from 3GPP LTE R8 and upLTM L 1 / 2 triggered mobilityNACK Negative ACKMCG Master cell groupMAC Medium access controlMCS Modulation and Coding SchemeMIMO Multiple Input Multiple OutputML Machine LearningNR New RadioOFDM Orthogonal Frequency-Division MultiplexingPCell Primary cellPCI Physical cell identityPHY Physical LayerPID Process IDPO Paging OccasionPRACH Physical Random Access ChannelPSCell Primary SCG CellPSS Primary Synchronization SignalRA Random Access (or procedure)RACH Random Access ChannelRAR Random Access ResponseRCU Radio access network Central UnitRF Radio Front endRLC Radio Link ControlRLF Radio Link FailureRLM Radio Link MonitoringRNTI Radio Network IdentifierRO RACH occasionRRC Radio Resource ControlRRM Radio Resource ManagementRS Reference SignalRSRP Reference Signal Received PowerRS SI Received Signal Strength IndicatorSCell Secondary cellSCG Secondary cell groupSDU Service Data UnitSpCell Special Cell*SRS Sounding Reference SignalSS Synchronization SignalSSS Secondary Synchronization SignalSWG Switching Gap (in a self-contained subframe)SPS Semi-persistent schedulingSUL Supplemental UplinkTB Transport BlockTBS Transport Block SizeTRP Transmission / Reception PointTSC Time-sensitive communicationsTSN Time-sensitive networkingUAV Uncrewed Aerial VehicleUCI Uplink control informationUL UplinkURUUC Ultra-Reliable and Uow Uatency CommunicationsWBWP Wide Bandwidth PartWUAN Wireless Uocal Area Networks and related technologies (IEEE 8O2.xx domain)

[0076] In the following description, the term SpCell either refers to the PCell of the MCG or the PSCell of the SCG depending on whether the MAC entity is associated to the MCG or the SCG.

[0077] In the following description, “perform LTM” or “perform LTM” procedures refer to performing any / all of the steps described in FIG. 4. Specifically, early synchronization in DL and / or UL to one or more of the candidate cells, performing LI measurements and reporting on one or more of the candidate cells, switching (i.e., performing handover) between candidate cells (“Perform LTM” can mean that the WTRU (e.g., WTRU (e.g., UE)) moves / switches between multiple candidate cells during the procedure).

[0078] The one or more candidate cell sets may be groups of more than one RRC configuration corresponding to a handover configuration for one or more candidate SpCells and optionally SCells. This may be modelled or received as one or more complete RRC Reconfiguration messages, one or more cell group configurations, or one or more cell configurations. Each of the candidate cell configurations may include a candidate configuration identifier, and each of the candidate cell groups may include a candidate cell group identifier. If the grouping is performed at RRC, the switching between different sets of candidate cells may include updating the serving cell indexes or candidate configuration indexes which are used in LI and MAC signalling to refer to specific indexes (for example a MAC CE triggering the reconfiguration may include a candidate configuration index informing the WTRU (e.g., WTRU (e.g., UE)) which cell to perform the reconfiguration to).

[0079] The one or more candidate cell groups may be configured as a single list or group of candidate cell configurations at RRC. The grouping may occur at the early sync or LTM execution phase rather than the configuration phase - what this means is that the candidate cell set may be considered as a single group in terms of an RRC configuration list or group, while the cells selected for performing early sync, LI measurements, and LTM execution depend on a further grouping into multiple subsets of the overall candidate cell list. In other words, the grouping itself may not be modelled at RRC using candidate configuration identifiers, but the grouping is executed as part of the early sync or the LTM execution procedure.

[0080] Throughout this disclosure, when referring to an LTM candidate configuration, this may apply to any type of preconfigured cell information. For example, a WTRU (e.g., WTRU (e.g., UE)) may be configured with one or more conditional reconfigurations such as conditionalhandover (CHO), conditional PSCell addition (CPA) or conditional PSCell change (CPC) which are valid before and / or after a cell change, or valid in certain cells.

[0081] The terms “candidate cell”, “neighbor cell” and “target cell” are used interchangeably in this disclosure.

[0082] The terms “serving cell”, “current cell” and “source cell” are used interchangeably in this disclosure.

[0083] Unless otherwise specified, the embodiments described in this disclosure are agnostic to whether the source and target cells belong to the network node (e.g., network node (e.g., gNB), DU, etc.) or different network nodes.

[0084] In the following description, a mobility related action may refer to any action performed by the WTRU (e.g., WTRU (e.g., UE)) in preparation or execution of mobility, for example: (1) starting or stopping certain measurements (e.g., measurement of certain candidate cells, frequencies, etc.), starting or stopping measurement reporting concerning certain candidate / neighbor cells (e.g., CSI-RS reporting, L3 measurement reporting, etc.); (2) starting or stopping the evaluation of the triggering conditions of measurement events; (3) performing RACH to a target cell to get a TA (e.g., in anticipation of or during the initial execution phase of a HO, LTM, CHO LTM, L3 HO, L3 CHO, etc.); and (4) executing a HO (e.g., switching to a target candidate set due to the reception of an LTM MAC CE, LTM or L3 CHO triggering conditions being fulfilled, etc.).

[0085] In the following description, an AIML related / based action refers to any action taken by the WTRU (e.g., WTRU (e.g., UE)) or / and associated WTRU (e.g., WTRU (e.g., UE)) behavior that is impacted by a prediction of one or more metrics (e.g., radio link quality, buffer levels, etc.) that was made by an AIML model / functionality. For example, this could be any of the mobility related actions discussed above, where the mobility action was triggered due the fulfilment of the conditions of an event associated the mobility action, and the event conditions are related to thresholds that were compared to one or more predicted values (e.g., predicted radio / buffer measurements at a certain time horizon in the future and at a certain confidence level, etc.).

[0086] In the following description, the terms “RA procedure”, “RACH procedure”, “RACH”, and “RA” are used interchangeably.

[0087] Most of the embodiments described in the following description refer to a confidence level of a prediction (and associated WTRU (e.g., WTRU (e.g., UE)) and / or actions that may use (e.g., depend on) the level of confidence. Some embodiments are equally applicable wherein instead of confidence level, the predictions are associated with a confidence error margin instead of or in addition to the confidence level (e.g., WTRU (e.g., WTRU (e.g., UE)) predicting a signallevel of a cell being x + / - a certain error margin, WTRU (e.g., WTRU (e.g., UE)) predicting a signal level of a cell being x + / - a certain error margin and a certain confidence level, etc.). The thresholds could be based on the prediction error margin (e.g., if the error margin is small, action 1 is taken, while if the error margin is large, action 2 is taken, etc.).

[0088] An LI measurement herein may comprise (e.g., consist of) a measurement of RSRP, RSRP, RSSI, etc., performed by a WTRU (e.g., WTRU (e.g., UE)) of a cell, beam, set of cells, or set of beams. Such LI measurement may be similar to L3 measurements reported in RRM, with differences in the filtering, reference signals measured, reporting mechanisms, etc.

[0089] Herein, measurements may refer to LI measurements for LTM. Certain embodiments herein may apply also to RRM / L3 measurements, as well as other measurements (e.g., measurements of speed, location, height, traffic, etc.).

[0090] Herein, the LTM scenario is mainly used to describe the embodiments. The embodiments may equally be applicable to mobility triggered by L3 (e.g., RRC), either by explicit HO command, or via CHO configured at RRC level.

[0091] In RRC CONNECTED, the WTRU (e.g., WTRU (e.g., UE)) may measure multiple beams (at least one) of a cell and the measurements results (power values) are averaged to derive the cell quality. The WTRU (e.g., WTRU (e.g., UE)) may be configured to consider a subset of the detected beams. Filtering may take place at two different levels: at the physical layer to derive beam quality and then at RRC level to derive cell quality from multiple beams. Cell quality from beam measurements is derived in the same way for the serving cell(s) and for the non-serving cell(s). Measurement reports may contain the measurement results of the X best beams if the WTRU (e.g., WTRU (e.g., UE)) is configured to do so by the network node (e.g., gNB).

[0092] The corresponding high-level measurement model is described in FIG. 2 (Figure 9.2.4-1 from 3GPP TS 38.300).

[0093] More detail of RRC measurements in NR can be found, for example, in 3GPP TS 38.300 subclause 9.2.

[0094] Currently (R17) can use inter-cell beam management which can manage the beams in CA case, but no cell change / add is supported.

[0095] In R18 one of the objectives of the work item “Further NR Mobility Enhancements ” in RP-213565 is to specify mechanism and procedures of L1 / L2 based inter-cell mobility for mobility latency reduction:_ _

[0096] L1 / L2 based mobility was originally started in R17 and inter-cell beam management in R17 addresses intra-DU and intra-frequency scenarios. In this case the serving cell remains unchanged (i.e., there is no possibility to change the serving cell using Ll / 2 based mobility). In FR2 deployments, CA is typically used in order to exploit the available bandwidth, e.g., to aggregate multiple component carriers (CCs) in one band. These CCs are typically transmitted with the same analog beam pair (network node (e.g., gNB) beam and WTRU (e.g., WTRU (e.g., UE)) beam). The WTRU (e.g., WTRU (e.g., UE)) is configured with transmission configuration indication (TCI) states (can have fairly large number, e.g., 64) for reception of PDCCH and PDSCH. Each TCI state includes a RS or SS block (SSB) that the WTRU (e.g., UE) refers to for setting its beam. For R17, the SSB can be associated with a non-serving PCI. MAC signaling (“TCI state indication for WTRU (e.g., UE)-specific PDCCH MAC CE”) activates the TCI state for a Coreset / PDCCH. Reception of PDCCH from a non-serving cell is supported by MAC CE indicating a TCI state associated to non-serving PCI. MAC signaling (“TCI States Activation / Deactivation for WTRU (e.g., UE)-specific PDSCH”) activates a subset of (up to) 8 TCI states for PDSCH reception. DCI indicates which of the 8 TCI states. R17 also supports “unified TCI state” with a different updating mechanism (DCLbased), but without multi-TRP. R18 will support unified TCI state with multi-TRP.

[0097] The overall objective of LTM is to improve handover latency; with a conventional L3 handover or conditional the WTRU (e.g., UE) will typically first send a measurement report using RRC signalling. In response to this the network may provide a further measurement configuration and potentially a conditional handover configuration. With a conventional handover the network provides a configuration for a target cell after the WTRU (e.g., UE) reports using RRC signalling that the cell meets a configured radio quality criteria. With conditional handover, in order to reduce the handover failure rate due to the delay in sending a measurement report then receiving an RRC reconfiguration the network provides, in advance, a target cell configuration as well as a measurement criteria which determines when the WTRU (e.g., UE) should trigger the CHO configuration. Both of these L3 methods, however, do suffer from some amount of delay due to the sending of measurement reports and receiving of target configurations, particularly in case of the conventional (non-conditional) handover.

[0098] In particular, the aim of LTM is to allow a fast application of configurations for candidate cells, including dynamically switching between SCells and switching of the PCell (e.g., switch the roles between SCell and PCell) without performing RRC signalling. The inter-CU case is not included, as this may use (e.g., require) relocation of the PDCP anchor and has already been excluded from the work item. Therefore, an RRC based approach is needed at least to support inter-CU handover.

[0099] Furthermore, with the legacy L3 handover mechanisms, any currently active SCell(s) are released before the WTRU (e.g., UE) moves completes the handover to a target cell in the coverage area of a new site, and can only be added back after successful handover, which leads to throughput degradation during handover. One of the aims of Ll / 2 is therefore to enable CA operation to be enabled instantaneously upon serving cell change.

[0100] FIG. 3 shows an example of LTM operation, whereby the candidate cell group is configured by RRC and a dynamic switch of PCell and SCell is achieved using Ll / 2 signalling.

[0101] In May 2023 RAN2 the following baseline procedure for LTM, illustrated in FIG. 4, has been provided in a (draft) running CR.

[0102] The procedure for LTM may be as follows.

[0103] The WTRU (e.g., UE) may send MeasurementReport message to the network node (e.g., gNB). The network node (e.g., gNB) may decide to use LTM and initiates LTM candidate preparation (step 4.1).

[0104] The network node (e.g., gNB) may transmit an RRCReconfiguration message to the WTRU (e.g., UE) including the configuration of one or multiple LTM candidate target cells (step 4.2).

[0105] The WTRU (e.g., UE) stores the configuration of LTM candidate target cell(s) and may transmit a RRCReconfigurationComplete message to the network node (e.g., gNB) (step 4.3).

[0106] The WTRU (e.g., UE) may perform DL synchronization and timing advance (TA) acquisition with candidate target cell(s) before receiving the LTM cell switch command (steps 4.4a and 4.4b). DL synchronization for candidate cell(s) before cell switch command is supported, at least based on SSB. TA acquisition of candidate cell(s) before LTM cell switch command is supported, at least based on PDCCH ordered RACH, where the PDCCH order is only triggered by source cell.

[0107] The WTRU (e.g., UE) may perform LI measurements on the configured LTM candidate target cell(s), and may transmit lower-layer measurement reports to the network node (e.g., gNB). The lower-layer measurement reports may be carried on LI or MAC (step 4.5).

[0108] The network node (e.g., gNB) may decide to execute LTM cell switch to a target cell and may transmit a MAC CE triggering LTM cell switch by including the candidate configuration index of the target cell. The WTRU (e.g., UE) may switch to the configuration of the LTM candidate target cell (step 4.6).

[0109] The WTRU (e.g., UE) may perform random access procedure towards the target cell, if TA is not available (step 4.7).

[0110] The WTRU (e.g., UE) may indicate successful completion of the LTM cell switch towards target cell (step 4.8).[OHl] An uplink signal or message after the WTRU (e.g., UE) has switched to the target cell may be used to indicate successful completion of the LTM cell switch.

[0112] Random access can be performed either in a contention-based fashion (i.e., contention based random access (CBRA) and contention free (i.e., contention free random access (CFRA)). Two types of random access are supported in NR: 4-step RA, and 2-step RA.

[0113] The 2-step and 4-step procedures are briefly described below:

[0114] 4-Step random access may begin with the WTRU (e.g., UE) transmitting MSG1, which contains a preamble on PRACH. Upon MSG1 transmission, the WTRU (e.g., UE) may monitor for a random-access response (e.g., RAR / Msg2) from the network within a configured window.

[0115] Upon reception of the RAR, which may contain an UL grant and a timing advance command, the WTRU (e.g., UE) may apply the timing advance command and may send Msg3 using the UL grant provided in RAR.

[0116] Upon Msg3 transmission, the WTRU (e.g., UE) may monitor for a network response (e.g., Msg4) containing contention resolution information.

[0117] If contention resolution is successful, random access may be complete and the WTRU (e.g., UE) may begin connection. If contention resolution fails, the WTRU (e.g., UE) may restart random access via transmission of Msgl.

[0118] 2-step random access may begin with transmission of MsgA, which includes a preamble on PRACH and a payload on PUSCH. After MsgA transmission, the WTRU (e.g., UE) may monitor for a response (e.g., MsgB) from the network within a configured window containing information regarding contention resolution.

[0119] If contention resolution is successful, the WTRU (e.g., UE) may terminate the randomaccess procedure. If contention resolution fails and a fallback indication may be provided in MsgB, the WTRU (e.g., UE) may perform Msg3 transmission using an UL grant contained within the MsgB fallback indication and may begin to monitor for contention resolution. If contention resolution again fails after Msg3 transmission, the WTRU (e.g., UE) may revert to MsgA transmission. If the MsgA transmission fails a configured number of times, the WTRU (e.g., UE) may revert to 4-step Random access.

[0120] The messaging exchange for 2 and 4-step RACH can be seen in FIG. 5 ((left) 4-step contention-based random access; (right) 2-step contention-based random access).

[0121] Which type of random access may be used may be selected upon initiation of the random access procedure based on network configuration. When contention free random access resources are configured, the WTRU (e.g., UE) may perform 4-step or 2-step random access depending on whether the random access resources correspond to 2-step or 4-step. If contention free random access resources are not provided, the WTRU (e.g., UE) selects between 4-step and 2-step random access based on an RSRP threshold (e.g., 2 step selected if the RSRP may be above a certain threshold).

[0122] RA procedure may be triggered upon request of a PRACH transmission by higher layers (e.g., during initial access, retransmission, HO, etc.) or by an explicit PDCCH order from the network node (e.g., gNB).

[0123] The WTRU (e.g., UE) may be configured with several parameters that control the RACH operation. Some of these parameters are shown below (the details of all the different RACH related parameters can be found in TS 38.321).

[0124] prach-Configurationlndex'. the available set of PRACH occasions for the transmission of the Random Access Preamble for Msgl. These are also applicable to the MSGA PRACH if the PRACH occasions are shared between 2-step and 4-step RA types.

[0125] msgA-PRACH-Configurationlndex'. the available set of PRACH occasions for the transmission of the Random Access Preamble for MSGA in 2-step RA type.

[0126] preambleReceivedTargetPower'. initial Random Access Preamble power for 4-step RA type.

[0127] msgA-PreambleReceivedTargetPowe . initial Random Access Preamble power for 2-step RA type.

[0128] rsrp-ThresholdSSB'. an RSRP threshold for the selection of the SSB for 4-step RA type. If the Random Access procedure may be initiated for beam failure recovery, rsrp-ThresholdSSB used for the selection of the SSB within candidateBeamRSList refers to rsrp-ThresholdSSB in BeamFailur eRecoveryConfig IE.

[0129] rsrp-ThresholdCSI-RS'. an RSRP threshold for the selection of CSI-RS for 4-step RA type. If the Random Access procedure may be initiated for beam failure recovery, rsrp- ThresholdCSI-RS may be equal to rsrp-ThresholdSSB in BeamFailur eRecoveryConfig IE.

[0130] msgA-RSRP-ThresholdSSB'. an RSRP threshold for the selection of the SSB for 2-step RA type.

[0131] msgA-RSRP -Threshold, an RSRP threshold for selection between 2-step RA type and 4- step RA type when both 2-step and 4-step RA type Random Access Resources are configured in the UL BWP.

[0132] rsrp-ThresholdMsg3'. an RSRP threshold for MSG3 repetition.

[0133] msgA-TransMax'. The maximum number of MSGA transmissions when both 4-step and 2-step RA type Random Access Resources are configured.

[0134] candidateBeamRSList'. a list of reference signals (CSI-RS and / or SSB) identifying the candidate beams for recovery and the associated Random Access parameters.

[0135] power RampingStep'. the power-ramping factor.

[0136] msgA-PreamblePowerRampingStep'. the power ramping factor for MSGA preamble.

[0137] powerRampingStepHighPriority. the power-ramping factor in case of prioritized Random Access procedure.

[0138] scalingFactorBL. a scaling factor for prioritized Random Access procedure.

[0139] ra-Preamblelndex'. Random Access Preamble.

[0140] ra-OccasionList'. defines PRACH occasion(s) associated with a CSI-RS in which the MAC entity may transmit a Random Access Preamble.

[0141] preambleTransMax'. the maximum number of Random Access Preamble transmission.

[0142] numberOfPreamblesForThisPartition'. the number of consecutive preambles associated with the set of Random Access Resources applicable to the Random Access procedure.

[0143] msgA-PUSCH-ResourceGroupA : defines MSGA PUSCH resources that the WTRU (e.g., UE) shall use when performing MSGA transmission using Random Access Preambles group A.

[0144] msgA-PUSCH-ResourceGroupB'. defines MSGA PUSCH resources that the WTRU (e.g., UE) shall use when performing MSGA transmission using Random Access Preambles group B.

[0145] In the UL, the WTRU (e.g., UE) can be granted resources for UL data transmission either dynamically (dynamic grants, DG) or (semi-) statically, where the latter may be referred to as Configured Scheduling (CS) or Configured Grants (CG).

[0146] In DG, the network may indicate to the WTRU (e.g., UE) (using a DCI), the immediate UL resources that it can use for UL transmission. For every PUSCH transmission, network may send the DCI indicating the allocated resources and the resources can change from one UL transmission to another.

[0147] With CG, the network does not need to send a DCI in the PDCCH for every PUSCH transmission, and instead the WTRU (e.g., UE) may be pre-configured (e.g., using RRC signaling) with the resources (e.g., frequency / time) that it can use in a periodic manner. There are two types of CGs, type 1 and type 2.

[0148] In Type 1 CG, the resources are activated immediately after the WTRU (e.g., UE) may be configured with them, and available until the network releases them (both the activation / release performed via RRC signaling). Here, activated may be referred to indicate that the resources are available for the WTRU (e.g., UE).

[0149] In Type 2 CG, the resources are not activated immediately after the WTRU (e.g., UE) may be configured with them, and additional signaling (e.g., DCI) may be required to activate / deactivate the resources for a given WTRU (e.g., UE). That is, the WTRU (e.g., UE) may be configured with the resources first (i.e., location of the time / frequency resources), and when the network determines the resources are better used by that particular WTRU (e.g., UE), it activates the resources for that WTRU (e.g., UE) and after a certain time duration it can deactivate the resources for that WTRU (e.g., UE) (e.g., when it may be more beneficial to allocate the resources for another WTRU (e.g., UE)). That way, network can configure a multitude of WTRUs (e.g., UEs) with the same type 2 CG configuration but activates the CG for only one of the WTRUs (e.g., UEs) at a given time duration (e.g., based on the traffic needs of the WTRU (e.g., UE), radio conditions of the WTRU (e.g., UE) to best utilize the resources, etc.).

[0150] 3 GPP has been studying AIML related enhancements even before rel-18, but the focus was mainly on enabling network automation / optimization (e.g., SON, self-optimizing networks, MDT, Mobility Drive Test, etc.) and associated data collection.

[0151] In Rel-17, a RAN3-led study on further enhanced data collection investigated the high- level principles of RAN intelligence enabled by Al (see TR 37.817). Based on this study, a Rel-18 RAN3 work item was approved that focused on enhancements to data collection and signalling to support AI / ML based Network Energy Savings, Load Balancing and Mobility Optimizations.

[0152] In RANI, a study on AI / ML for NR Air Interface is ongoing in rel-18 (RP-221348), and the following three main use cases are being investigated: (1) channel state information (CSI), (2) beam management, and (3) positioning.

[0153] CSI related enhancements may comprise any of: CSI compression (frequency domain), time-domain prediction, etc.

[0154] BM may be related to any of: temporal prediction (predicting of a beam’s quality based on earlier beam quality), spatial prediction (prediction of a certain beam’s quality based on the quality of other beams), etc.

[0155] Positioning may be related to any of: Direct AI / ML positioning (e.g., fingerprinting) and AI / ML assisted positioning (e.g., the output of the AI / ML model inference may be a new measurement and / or an enhancement of an existing measurement).

[0156] The AI / ML model can be operating / running at the WTRU (e.g., UE), the network node (e.g., gNB), other network node (e.g., LMF, Location Management Function, for positioning), or even outside the wireless network domain (e.g., OTT server). There could be also use cases where there could be a model running at more than one entity for a certain function (e.g., for CSL Compression use case, there could be a need for a model in the WTRU (e.g., UE) as well as a model in the network, where the model at the WTRU (e.g., UE) may be providing compression related functionality while the model at the network may be providing the decompression, etc.).

[0157] Another aspect that is being investigated in conjunction with the three use cases discussed above is the lifecycle management (LCM) of AIML operations (this is being studied in joint collaboration across multiple RAN groups, RAN1 / 2 / 3), which constitutes functionalities such as: (1) model inference; (2) Model training (offline training, online training, etc.); (3) Model storage / transfer; (4) model update; (5) model validation; (6) performance monitoring; (7) data collection (for inference, training, performance monitoring); (8) model selection; and (9) model activation / deactivation / fallback to legacy operation.

[0158] Overview

[0159] The basic procedure of LTM, as agreed so far in 3GPP rel-18, is that the network first pre-configures multiple target cell candidates in RRC, then the WTRU (e.g., UE) may perform LI measurements and reporting, the WTRU (e.g., UE) may be triggered to perform DL and UL sync on one or more target cells, before finally receiving a MAC CE which triggers the reconfiguration / handover.

[0160] In R19, one improvement that is being considered is conditional LTM to improve robustness, where the handover can also be performed RACH-less. That is, the WTRU (e.g., UE) is provided beforehand with grants (e.g., configured grants, CG), that it can use to directly send the HO complete message to the target cell and continue the service without interruption.

[0161] The WTRU (e.g., UE) may be provided with a CHO configuration for several candidate cells, and associated CGs on one or more (e.g., each) cell. However, it is expensive to allocate the CG on multiple cells, specially when it is not known exactly when the conditions for a CHO target are fulfilled. If the network (e.g., concerned candidate cells) are not loaded, this may not be an issue. However, in most cases, there will be other users that are currently being served by the target cell and one or more (e.g., each) CG that was configured for a WTRU (e.g., UE) in a neighbouring cell that is expected to perform CHO that is not used is taking away resources from these users.

[0162] As such, mechanisms are needed to ensure the RACH less CHO will not lead to wastage of radio resources due to unutilized CGs in multiple target cell.

[0163] This disclosure will discuss on how AIML based mechanisms can be used to improve the resource utilization of RACH less CHO procedure, the RA procedure that can be performed in early preparation of a possible HO / CHO target, and performance monitoring of the AIML operations to ensure that WTRU (e.g., UE) level and system level performance is not impacted in a negative way (e.g., as compared to legacy operation with no AIML).

[0164] Methods and apparatus for mobility enhancements with AIML are provided. In one embodiment, the WTRU (e.g., WTRU (e.g., UE)) may be configured to trigger a RA procedure (e.g., sending a request for a PDCCH order, directly perform the RA procedure, etc.) based on predicted / current measurements. The WTRU (e.g., UE) may perform such RA procedure differently as compared to legacy RA triggered due to, e.g., initial access, PDCCH order, etc., (e.g., different power ramping levels, number of tries, etc.), and this can also further may use (e.g., depend on) the confidence level of the measurement prediction and prediction time horizon.

[0165] In one embodiment, the WTRU (e.g., WTRU (e.g., UE)) may be configured with a multitude of LTM / CHO candidate cells and associated type 2 configured grants (CG) to use for RACHless CHO in these cells. The WTRU (e.g., UE) may be configured with conditions to trigger CG activation and conditions for triggering the CHO. The conditions to trigger CG activation can be based on current and / or predicted measurements. The WTRU (e.g., UE) may monitor the conditions for triggering CG activation and may send a CG activation request when the conditions are fulfilled. When the conditions for the triggering of the CHO are fulfilled later, if the activated CG occasions are still valid, the WTRU (e.g., UE) uses the CG(s) to perform a RACH-less CHO.

[0166] In one embodiment, the WTRU (e.g., WTRU (e.g., UE)) may be configured to receive a configuration on how to determine the accuracy of AIML related actions (e.g., has the WTRU (e.g., UE) performed a HO to a given target after doing a pre-emptive RACH to the target based on prediction, etc.), metrics to be used for doing performance monitoring (e.g., number of consecutive inaccurate actions, number / percentage of inaccurate actions within a given duration, etc.), thresholds / conditions for triggering performance monitoring related actions (e.g., number of consecutive inaccurate actions greater than nl, etc.), and the performance monitoring action to be applied when the triggering conditions are fulfilled (e.g., prohibit the usage of the AIML related action / model / function for a given time, retrain the model, switch to another model, stop using AIML for the concerned functionality, etc.). The WTRU (e.g., UE) may monitor the performance of AIML related actions according to the received configuration, and when the thresholds / conditions for triggering a performance monitoring related action are fulfilled, may execute the action associated with the fulfilled conditions, and informs the network about the action taken and / or may send a performance report.

[0167] In LTM, it has been agreed that the WTRU (e.g., UE) may receive a PDCCH order from the source to initiate a RA with a candidate cell (e.g., the source triggering the PDCCH order upon noticing that candidate cell is likely to be a HO target for the WTRU (e.g., UE) soon, based on received L1 / L3 measurements). This way, the WTRU (e.g., UE) will be in synch with the target (e.g., receive the TA for the target via the source in response to the RACH preamble sent), and if an LTM is triggered to the target later, it can be performed without RACH (e.g., via grant provided along with the HO command).

[0168] If the RA is triggered too soon, there is a likelihood that the WTRU (e.g., UE) may still end up being handed over to a different cell. Also, the TA for a given target cell is expected to be valid (e.g., only) with a certain configured Timing Advance Timer (TAT), and thus, even if the WTRU (e.g., UE) ends up handing over to that cell, RA procedure may have to be performed again.

[0169] If the RA is triggered too late, then it is questionable how much latency saving this results in as compared to the normal RACH based HO.

[0170] According to embodiments, the following procedure may be applied, wherein a WTRU (e.g., UE) may be configured to trigger a RA procedure (e.g., sending a request for a PDCCH order, directly trigger the RA procedure, etc.) based on predicted / current measurements. The WTRU (e.g., UE) may perform such RA procedure differently as compared to legacy RA triggered due to, e.g., initial access (e.g., different power ramping levels, number of tries, etc.), and this can also further may use (e.g., depend on) the confidence level of the measurement prediction andprediction time horizon (e.g., the more accurate the confidence level of the prediction, the more aggressive the WTRU (e.g., UE) can be in the RA procedure, Contention Based Random Access, CBRA, for less confident prediction, Contention Free Random Access (CFRA) for more confident prediction, preamble partitioning for different levels of prediction confidence, etc.,.).

[0171] The above procedure is described below in more details.

[0172] A WTRU (e.g., UE) may receive a configuration that includes one or more of the following: (1) configuration of LTM candidate cells, and a configuration for triggering RA procedure or sending a request to initiate the RA procedure based on predicted measurements (e.g., a first L1 / L3 predicted measurement threshold + a second L1 / L3 threshold based on actual measurements, etc.); (2) configuration related to RA operation if RA is triggered based on measurement prediction (this could be dependent on prediction confidence or prediction time horizon); (3) CBRA vs CFRA based on prediction confidence level (and further partitioning of the RACH preambles for CFRA for different ranges of confidence); and (4) different levels of power ramping, max RACH attempts, etc for confidence level intervals, etc., depending on, e.g., prediction confidence level.

[0173] The WTRU (e.g., UE) may perform current measurements of candidate / serving cells and may perform measurement prediction of candidate / serving cells (e.g., based on location, current serving cells being measured, mobility / trajectory, etc.). The WTRU (e.g., UE) may determine the confidence levels of one or more (e.g., each) measurement prediction (e.g., if confidence level of prediction is variable).

[0174] The WTRU (e.g., UE) may monitor the conditions for triggering RA to at least one candidate cell based on measurement predictions.

[0175] In the case where (e.g., when) the conditions for triggering RA to a candidate cell based on predicted measurements are fulfilled, the WTRU (e.g., UE) may: (1) determine to send a request / indication to the source cell (e.g., requesting permission, e.g., PDCCH order, to perform RA to the candidate) or may perform the RA to the candidate cell autonomously; (2) perform the RA according to the confidence level of the measurement prediction and the configuration that may be associated with the confidence level of the measurement prediction.; and (3) indicate explicitly the measurement prediction details that led to the decision to the triggering of the RA.

[0176] The WTRU (e.g., UE) may receive the TA (from the source / target).

[0177] Dynamic / autonomous activation / deactivation of CGs for RACH less CHO is described below.

[0178] RACH less CHO is being discussed in the context of LTM, where the WTRU (e.g., UE) will have up to date TA of an LTM candidate cell and associated UL grant (e.g., CG) before theCHO conditions are fulfilled. One problem with configuring CGs may be that not knowing when to provide them (or activate them, in the case of type 2 CG). Activating / configuring the CGs way before the WTRU (e.g., UE) may be ready to execute the CHO will lead to resource wastage, while activating / configuring them too late will lead to HO latency.

[0179] According to some embodiments, the following procedure may be applied: a WTRU (e.g., UE) may be configured with a multitude of LTM / CHO candidate cells and associated configured grants (type 2) to use for RACHless CHO in these cells. The WTRU (e.g., UE) may be configured with conditions to trigger CG activation and conditions for triggering the CHO. The conditions to trigger CG activation can be based on current and / or predicted measurements. The WTRU (e.g., UE) may monitor the conditions for triggering CG activation and may send a CG activation request when the conditions are fulfilled. When the conditions for the triggering of the CHO are fulfilled later, if the activated CG occasions are still valid, The WTRU (e.g., UE) uses the CG(s) to perform a RACH-less CHO.

[0180] The above procedure is described below in more details.

[0181] A WTRU (e.g., UE) may receive a configuration of LTM candidate cells, further including one or more of the following: (1) one or more CG configurations for RACH less HO for one or more (e.g., each) candidate cell (e.g., type 2 CG), where the CG configurations for one or more (e.g., each) candidate cell may have a configuration ID; and (2) a configuration related to Conditional Handover (CHO) (e.g., a first threshold associated with an L1 / L3 A3 / A4 / A5 event, i.e., when the CHO is to be executed towards a target).

[0182] The WTRU (e.g., UE) may receive AIML related configuration for CG activation of a candidate cell. The configuration may comprise parameters related to autonomous CG activation (e.g., a second threshold associated with an A3 / A4 / A5 event, where the thresholds are related to predicted measurements of serving / candidate cells). The configuration may comprise parameters related to actions / conditions how to perform the CG activation (e.g., expected time between CG activation request and response, expected time saving in performing the mobility action with a CG, maximum waiting time to defer / postpone a mobility action to use a CG, RSRP threshold of serving cell for enabling waiting for a CG occasion without risking a radio link failure, max number of CG occasions that can be requested by the WTRU (e.g., UE), indexes for identifying different prediction confidence levels and / or prediction time horizons, etc.).

[0183] The WTRU (e.g., UE) may perform current measurements of candidate / serving cells and may perform measurement prediction of candidate / serving cells (e.g., based on location, current serving cells being measured, mobility / trajectory, etc.). The WTRU (e.g., UE) may determine theconfidence levels of one or more (e.g., each) measurement prediction (e.g., if confidence level of prediction is variable).

[0184] The WTRU (e.g., UE) may monitor the conditions for CG activation of one or more candidate cells based on the CG activation configuration and current / predicted measurements.

[0185] If / when the conditions are fulfilled for activating a CG for a candidate cell based on predicted measurements, the WTRU (e.g., UE) may send a CG activation request to the network. This may include additional information such as the confidence / time horizon of the measurement predictions that triggered the CG activation condition, CG occasions to be activated, etc.

[0186] The WTRU (e.g., UE) may receive from the network an implicit / explicit approval or rejection of the activation of requested CGs (or CGs to be activated that are different from the requested CGs).

[0187] The WTRU (e.g., UE) may determine if / when the conditions are fulfilled for performing the CHO towards a target cell.

[0188] If there is an activated CG in the target cell (e.g., within the configured maximum waiting time for postponing the CHO for the sake of utilizing a CG) and / or the signal level of the serving cell may be above the configured RSRP threshold, the WTRU (e.g., UE) uses the concerned CG to complete the CHO without RA.

[0189] Else (e.g., no CG activated, CG was activated but its occasion has already passed, CG is activated / available, but it is occasion is farther away in time than the maximum configured waiting time, signal level of serving cell may be below the configured threshold, etc.), the WTRU (e.g., UE) may perform RA first to complete the CHO execution.

[0190] Before an activated CG occasion, the WTRU (e.g., UE) may send an indication to the network if that CG occasion is going (or expected) to be used or not (i.e., conditions are not fulfilled or are not expected to be fulfilled at the next CG occasion).

[0191] When allowing / configuring the WTRU (e.g., UE) to perform LTM related actions based on measurement predictions (e.g., initiating RACH, RACH less HO, etc.), care should be taken to ensure that the decision taken by the WTRUs (e.g., UEs) are leading to optimal performance. Some WTRUs (e.g., UEs) may be using an AIML model that is not accurate enough and leading to actions that waste network resources. For example, WTRUs (e.g., UEs) with less accurate prediction models may trigger RACH unnecessarily, leading to RACH collisions. Another example, WTRUs (e.g., UEs) may activate CG incorrectly for RACH less CHO, but end up not using the CGs if the predicted radio conditions of the target are not fulfilled, and CHO may be not triggered.

[0192] According to some embodiments, the following procedure may be applied: a WTRU (e.g., UE) may receive a configuration on how to determine the accuracy of AIML related actions (e.g., has the WTRU (e.g., UE) performed a HO to a given target after doing a pre-emptive RACH to the target based on prediction, has the WTRU (e.g., UE) ended up using the CGs that it has activated in advance in anticipation of a CHO to a target, etc.), metrics to be used for doing performance monitoring (e.g., number of consecutive inaccurate actions, number / percentage of inaccurate actions within a given duration, etc.), thresholds / conditions for triggering performance monitoring related actions (e.g., number of consecutive inaccurate actions greater than nl, etc.), and the performance monitoring action to be applied when the triggering conditions are fulfilled (e.g., prohibit the usage of the AIML related action / model / function for a given time, retrain the model, switch to another model, stop using AIML for the concerned functionality, etc.). The WTRU (e.g., UE) may monitor the performance of AIML related actions according to the received configuration, and when the thresholds / conditions for triggering a performance monitoring related action are fulfilled, may execute the action associated with the fulfilled conditions.

[0193] The above procedure is described below in more details:

[0194] A WTRU (e.g., UE) may receive a configuration related to performance monitoring of AIML related actions.

[0195] The configuration may comprise parameters on how to determine whether a predictionbased AIML related action was accurate or not.

[0196] The configuration may comprise parameters related to metrics to be monitored (e.g., number of consecutive inaccurate actions, number of or percentage of inaccurate actions within a given time duration, etc.).

[0197] The configuration may comprise parameters related to thresholds / conditions for triggering performance monitoring actions for the different performance metrics being monitored (e.g., action to be triggered when the number of consecutive inaccurate actions may be above nl, etc.).

[0198] The configuration may comprise parameters related to performance monitoring action to be taken (e.g., prohibition of the AIML related action / model / function for a certain configured prohibit time duration, triggering of model retraining, switching to a more accurate / most costly model, switching to a different AIML functionality, switching to legacy, i.e., non AIML based, operation, send performance monitoring report, etc.).

[0199] Depending on the level of inaccuracy detected, the same action can be applied with different parameters (e.g., longer prohibit timer for higher number of inaccuracies, etc.).

[0200] The WTRU (e.g., UE) may determine the accuracy of a prediction-based action based on the performance monitoring configuration (e.g., whether the action did lead to an anticipated outcome or not, etc.).

[0201] The WTRU (e.g., UE) may monitor the triggering conditions for performance monitoring action based on the determined accuracy of at least one prediction-based action (e.g., count the number of inaccurate prediction-based actions within a configured time duration and compare with the configured maximum threshold, etc.).

[0202] If the triggering conditions for a certain performance monitoring action are fulfilled, the WTRU (e.g., UE) may execute the performance monitoring action (e.g., pause the related prediction-based action for a configured prohibit timer, retrain the model, request the network to retrain the model, switch to another model, switch to legacy, etc.). The WTRU (e.g., UE) may update some of the parameters that affect the performance monitoring action based on the fulfilled triggering conditions (e.g., longer prohibit timer applied for higher level of inaccuracies with a given time, etc.).

[0203] The WTRU (e.g., UE) may transmit indication of status of a prediction-based action (e.g., inform network about performance monitoring actions taken, transmit a performance monitoring report for one or more prediction-based actions within a given configured time duration, etc.).

[0204] Some embodiments provided herein enable the network to use AIML predictions to enhance the operations of LTM, e.g., by optimizing the RA procedure, UL resource utilization (e.g., dynamic CG allocation). Mechanisms are also proposed to ensure a proper performance management of the AIML operation (e.g., switch to a better performing model, retrain a model that is not performing well, switch to a better performing model, stop using AIML operation for a certain functionality if there is no model that is performing well, etc.).

[0205] Apart from resource utilization enhancements, some embodiments proposed here also have benefits in terms of latency, especially in scenarios like NTN (non-terrestrial networks), where there is an inherently long round trip time (RTT) between the network node (e.g., gNB) and the WTRU (e.g., UE) (via the NTN satellite). Considerable HO latency improvements can be made (or / and reduced HO interruption time) in using a proactive approach of performing CHO / HO / LTM and related operation (e.g., target cell preparation, facilitating the CG utilization, etc.) based on AIML prediction as compared to the reactive approach of using (e.g., only) curr ent / actual measurements.

[0206] The network node (e.g., gNB) (e.g., a CU in case of CU / DU split architecture - note: RRC resides in CU) configures potential LTM candidates using RRC signaling. According to some embodiments, the WTRU (e.g., UE) may receive the LTM candidate configurations using an RRCReconfiguration message, for example during the “LTM preparation” phase shown in FIG. 4. The WTRU (e.g., UE) may store the LTM candidate configurations to later apply upon receiving an indication using Ll / 2 signaling (e.g., MAC CE) to perform a cell switch, for example in the “LTM execution” phase shown in FIG. 4.

[0207] According to some embodiments, the configuration of potential LTM candidates may include candidate sets, for example a first set which may e.g., be suitable for a first path (for example, a WTRU (e.g., UE) turns left and takes first road) and a second set which may e.g., be suitable for a second path (e.g., WTRU (e.g., UE) turns right and takes second road)

[0208] According to some embodiments, some or all of the candidate set’s information is broadcast in system information, and the WTRU (e.g., UE) enables the pre-configuration of these broadcast configurations upon receiving an indication in dedicated signalling (e.g., RRC Reconfiguration) which refers to the broadcast one or more configurations (e.g., using an index or identifier)

[0209] According to some embodiments, the configuration may include all or a subset of the potential cells in a specific area (for example all cells belonging to the CU with which the WTRU (e.g., UE) may be currently connected or cells within a particular geographical area). These cells may not yet have been detected or measured by the WTRU (e.g., UE) but are configured in advance. According to some embodiments, after the initial configuration of LTM candidate configurations, the WTRU (e.g., UE) may receive an update to the configuration to modify, add, remove, or replace any part of the LTM candidate configurations.

[0210] According to some embodiments, the WTRU (e.g., UE) may receive an indication to enable or disable some or all the LTM configurations. For example, if it may be predicted that the WTRU (e.g., UE) mobility would be better handled using L3 (e.g., RRC measurement report, RRC reconfiguration, conditional reconfiguration) then LTM may be disabled, and on the other hand if it is predicted that LTM would better suit the WTRU (e.g., UE) mobility then LTM may be enabled (e.g., a previously configured and disabled LTM configuration may be re-enabled).

[0211] The configuration may in one or more embodiments be based on a prediction model internal to, and determined by, the network (e.g., network node (e.g., gNB)). This prediction may, for example, be based on what it (the NW prediction model) may determine to be the WTRUs (e.g., UEs) most likely paths.

[0212] According to some embodiments, the candidate cell configurations contain all or part of the information necessary to complete a reconfiguration (e.g., handover) to the candidate cell, such as channel configurations (e.g., PRACH, DPCCH, DPSCH), CORESET, BWP, security parameters, L2 parameters (e.g., MAC, RLC, PDCP), radio bearer configurations, and so on.

[0213] Certain embodiments may be agnostic / independent to the AIML model / technique that is being used (e.g., the algorithm used, the mechanism such as neural network or what kind of neural network, e.g., depth and parameters / weights of the network, etc.).

[0214] The WTRU (e.g., UE) experienced conditions today come from real measurements the WTRU (e.g., UE) may perform over time. In a simple mobility scenario, a WTRU (e.g., UE) in mobility will read that the current serving cell’s RSRP and report it to the NW. If the WTRU (e.g., UE) is moving to an area approaching the serving cell’s edge, it will record that RSRP values are decreasing. These values are communicated to the NW via measurement reports for the NW to make a decision.

[0215] According to some embodiments, the WTRU (e.g., UE) is assumed to have a pre-trained AI / ML model that can produce predictions of air-interface measurements (RSRP, RSRQ, SINR, etc.) of serving and / or neighbor cells. FIG. 6 illustrates the time series prediction for RSRP as an example, for example at time t, one RSRP prediction point may be predicted per time step from time t+1 until t+t_fb.

[0216] The predictions can also be done for one point in time (e.g., only) and can extend over several time steps. In many scenarios, prediction with time series output may be beneficial than single value predictions as it may be difficult to match the prediction with e.g., a NW configured event with a single prediction point.

[0217] This leads to a practical issue, which is the granularity of the timestamp associated with a prediction. If the WTRU (e.g., UE) predicts one or more future values, a timestamp will in principle be associated with that prediction, e.g., a timestamp for t+1, t+2, etc. The granularity of that timestamp may use / depend on the AIML model in use and other ML related settings. Terminology like “predicted value”, “inferred value”, “future value” and others are used in this document to refer to future predicted values that may or not have an associated timestamp, and if they do, the timestamp can be considered a small delta time interval within which the predicted value is considered to be accurate, valid, either completely or with a certain degree of confidence. In all WTRU (e.g., UE)-NW exchanges, we consider therefore that predictions can be represent by a tuple such as [“predicted value”; timestamp - delta; timestamp + delta],

[0218] A WTRU (e.g., UE) may be configured to predict future measurements based on current and / or historical measurements. For example, the WTRU (e.g., UE) may be configured with a trained AIML model that is able to produce predictions for radio interface radio signal levels. In an embodiment, the AIML model at the WTRU (e.g., UE) may be implementation based. In another embodiment, the WTRU (e.g., UE) may obtain the AIML model from the NW. According to some embodiments, the AIML model may be configured to take as an input current and / orhistorical RSRP measurements. In another embodiment, the AIML model may be configured to take additional inputs such as WTRU (e.g., UE) location information, WTRU (e.g., UE) mobility etc. According to some embodiments, the AIML model may be configured to produce single value predictions - i.e., RSRP at a future time instant t. In another embodiment the AIML model may be configured to predict a series of RSRP values corresponding to future time instances t+1, t+2 so on up to t+t_fb.

[0219] A model may be offline trained, or online, and may be exchanged in a pre-configuration step, not detailed in this document.

[0220] For any predicted value, either by the NW or the WTRU (e.g., UE), the predicted value itself may be associated and / or represented by a confidence or error value, and may be represented by an average, peak, minimum value, etc. along a short time window representing the validity of that prediction.

[0221] According to some embodiments, there is some WTRU (e.g., UE) capability communication between the WTRU (e.g., UE) and the network about AIML capability (e.g., where the WTRU (e.g., UE) can indicate to the network the supported AIML models / functions, confidence level of predictions, e.g., of measurements, time horizon of predictions (how far along in the future are the prediction being made), etc.).

[0222] According to some embodiments, the WTRU (e.g., UE) may support several AIML models for a certain functionality (e.g., with different prediction time horizons, prediction confidence levels, processing requirements, trained under / for operation in different frequencies / cells / location / times of day, etc.).

[0223] According to some embodiments, a given AIML model can operate in different modes (e.g., with different levels of prediction confidence levels at different prediction time horizons, etc.).

[0224] According to some embodiments, the WTRU (e.g., UE) may choose the AIML model to use for a certain functionality (e.g., network may decide for which functionalities the WTRU (e.g., UE) can use AIML based operation, and the WTRU (e.g., UE) chooses the AIML model to use) or the network may explicitly control this (e.g., WTRU (e.g., UE) provides details of AIML models and their capabilities, network may determine which model to activate for a particular functionality).

[0225] According to some embodiments, the AIML models can be available at the WTRU (e.g., UE) already trained, or the WTRU (e.g., UE) may be provided with an untrained AIML model and may perform the training by itself.

[0226] According to some embodiments, the AIML model may be available at the WTRU (e.g., UE) already trained, and the WTRU (e.g., UE) may be enabled / configured to perform further training (e.g., for different conditions such as frequencies / cells / location / times of day, for the same conditions as the initial training but for increasing the level of confidence or / and the prediction time horizon, etc.).

[0227] According to some embodiments, a given AIML model can provide one output (e.g., predicted measurement of a certain cell / beam after Xms or n slots), or a multitude of output (e.g., a predicted time series of measurements). In the case of a time series of output, the prediction confidence may be variable from one output to the other (e.g., higher confidence level for prediction that are Xms away as compared to predictions Yms away, where Y>X, etc.).

[0228] According to some embodiments, the prediction confidence level can be in percentage confidence (e.g., expected likelihood of this prediction will come true) or / and in terms of error margin (e.g., in Xms, the predicted measurement for cell l may be expected to be between RSRP value -lower error margin and RSRP value+upper error margin, with a confidence of 95%).

[0229] According to some embodiments, for a given time horizon of prediction, there could be different ranges of predicted values with different confidence levels or error margins (e.g., in Xms, the predicted measurement for cell l is expected to be between RSRP valuel - lower error marginl and RSRP valuel+upper error marginl, with a confidence of 95%, between RSRP_value2 -lower_error_margin2 and RSRP_value2+upper_error_margin2, with a confidence of 85%, etc.).

[0230] The WTRU (e.g., UE) may be configured with condi tions / events that are based on predicted and / current radio conditions to determine / trigger mobility related actions.

[0231] According to some embodiments, the WTRU (e.g., UE) may be configured to perform / trigger a mobility related action (e.g., RA towards a target cell) based on current radio link quality measurements. For example, the WTRU (e.g., UE) may be configured with an event (e.g., any of the Ax / Bx events) regarding a candidate cell where the conditions can be RSRP / RSRQ thresholds (e.g., absolute thresholds, relative thresholds as compared to a serving cell, relative thresholds as compared to other candidate cells, etc.) and when the current radio conditions of the candidate cell (and the associated serving / neighbor cells, in case of relative thresholds) fulfill the thresholds, thee WTRU (e.g., UE) will perform the mobility related action (e.g., RACH to the concerned candidate cell).

[0232] According to some embodiments, the WTRU (e.g., UE) may be configured to perform / trigger a mobility related action (e.g., RA towards a target cell) based on predicted radiolink quality measurements. For example, the WTRU (e.g., UE) may be configured with an event (e.g., any of the Ax / Bx events) regarding a candidate cell where the conditions can be RSRP / RSRQ thresholds (e.g., absolute thresholds, relative thresholds as compared to a serving cell, relative thresholds as compared to other candidate cells, etc.) and when the predicted radio conditions of the candidate cell (and the associated serving / neighbor cells, in case of relative thresholds) fulfill the thresholds, the WTRU (e.g., UE) will perform the mobility related action (e.g., RACH to the concerned candidate cell).

[0233] According to some embodiments, the WTRU (e.g., UE) may be configured to perform / trigger RACH operation towards a target cell based on a combination of predicted and current radio link quality measurements. For example, the WTRU (e.g., UE) may be configured with an event (e.g., like any of the Ax / Bx events, but with two conditions, first condition concerning current measurements and second condition concerning predicted measurements) regarding a candidate cell where the first condition is concerning the current radio conditions and the second condition is concerning the current radio conditions, and the conditions can be RSRP / RSRQ thresholds (e.g., absolute thresholds, relative thresholds as compared to a serving cell, relative thresholds as compared to other candidate cells, etc.). When both conditions concerning the current measurements and predicted measurements are fulfilled, the WTRU (e.g., UE) will perform the mobility related action (e.g., RACH to the concerned candidate cell).

[0234] According to some embodiments, the event configuration that has conditions related to predicted measurements contains additional time horizon and / or confidence level related conditions (e.g., Ax expected to be fulfilled within the next xms, Ax expected to be fulfilled from xms onwards for at least yms, etc., where one or more (e.g., each) event can also be associated with a minimum confidence level).

[0235] According to some embodiments, the WTRU (e.g., UE) may be configured to perform the mobility related action towards a target cell based on predicted radio link quality measurements at several time instances in the future. For example, the WTRU (e.g., UE) may be configured with an event that will be triggered if the radio quality towards a target cell is at least threshl within timel from now, and the radio quality towards the same target cell is at least thresh2 within timel+deltal from now on, and so on. This is equally applicable to the case where the thresholds are relative thresholds comparing the candidate cell to a serving cell, or even comparing different candidate cells.

[0236] According to some embodiments, the event configuration does not contain explicit time horizon or confidence level related conditions. For example, there has been an earlier communication between the WTRU (e.g., UE) and network, e.g., during the WTRU (e.g., UE)capability exchange, and the network already knows the time horizon and the confidence level of the prediction that led to the event triggering.

[0237] According to some embodiments, the predicted radio conditions could refer to the radio conditions of the source cell, the radio conditions of the target cell, or both.

[0238] According to some embodiments, the events may be based on comparing current / predicted radio conditions of the target cell with one or more thresholds.

[0239] According to some embodiments, the events may be based on comparing current / predicted radio conditions of the source cell with one or more thresholds.

[0240] According to some embodiments, the events may be based on comparing current radio conditions of the source cell with predicted radio conditions of the source cell (e.g., predicted signal level of the source cell within a given time horizon are expected to be lower than the current serving cell signal level by more than a certain threshold).

[0241] According to some embodiments, the events may be based on comparing current radio conditions of the source with predicted radio conditions of the source (e.g., predicted signal level of the target cell within a given time horizon are expected to be better than the target cell signal level by more than a certain threshold).

[0242] According to some embodiments, the events may be based on comparing current / predicted radio conditions of the source cell and the target cell with each other (e.g., when the predicted target cell signal level may be better than the predicted source cell signal level by more than a certain threshold, when the predicted target cell signal level may be better than the current source signal level by more than a certain threshold, etc.).

[0243] According to some embodiments, measurements may refer to radio link quality measurements such as RSRP and RSRQ. The embodiments may be equally applicable if measurements refer to also other metrics such as UL / DL buffer levels. For example, events that contain conditions such as any of those listed below can be used to trigger a mobility related action: (1) the current UL buffer level exceeds a certain threshold; (2) the predicted UL buffer level at a given time horizon may be expected to exceed a certain threshold with more than a certain confidence level; (3) two conditions, one concerning current UL buffer level, another concerning predicted UL buffer levels; and (4) a condition that compares current and predicted buffer levels (e.g., predicted buffer level may be expected to higher / lower than current level by more than a certain threshold).

[0244] Events can also be envisioned where both radio quality related conditions and non-radio quality related are considered for triggering mobility related actions. For example, an event can be defined where the conditions for triggering the events may be any of the following: (1) firstcondition regarding current radio quality of serving / candidate cells, (2) second condition regarding predicted radio quality of serving / candidate cells, (3) third condition regarding current UL buffer levels, (4) fourth condition regarding predicted UL buffer levels, (5) fifth condition regarding current UL throughput levels, and(6) sixth condition regarding predicted UL throughput levels.

[0245] When the conditions concern UL buffer / throughput levels, the buffer / throughput levels could be the total UL buffer / throughput level or the buffer / throughput level of certain bearers or logical channels or logical channel groups (e.g., only the buffer level or throughput of the bearers with guaranteed bit rates are considered). It could also be envisioned that there could be several buffer / throughput related conditions / thresholds, each concerning different bearers or sets of bearers.

[0246] WTRU (e.g., UE) may be configured to trigger a RA procedure (e.g., sending a request for a PDCCH order, directly trigger the RA procedure, etc.) based on predicted / current measurements. The WTRU (e.g., UE) may perform such RA procedure differently as compared to legacy RA triggered due to, e.g., initial access (e.g., different power ramping levels, number of tries, etc.), and this can also further may use (e.g., depend on) the confidence level of the measurement prediction and prediction time horizon (e.g., the more accurate the confidence level of the prediction, the more aggressive the WTRU (e.g., UE) can be in the RA procedure, Contention Based Random Access, CBRA, for less confident prediction, Contention Free Random Access (CFRA) for more confident prediction, preamble partitioning for different levels of prediction confidence, etc.).

[0247] According to some embodiments, the procedure may comprise any of the following steps.

[0248] A WTRU (e.g., UE) may receive a configuration.

[0249] The configuration may comprise parameters related to LTM candidate cells, and for triggering RA procedure or sending a request to initiate the RA procedure based on predicted measurements (e.g., a first L1 / L3 predicted measurement threshold + a second L1 / L3 threshold based on actual measurements, etc.).

[0250] The configuration may comprise parameters related to RA operation if RA is triggered based on measurement prediction (this could be dependent on prediction confidence or prediction time horizon).

[0251] The configuration may comprise parameters related to CBRA vs CFRA based on prediction confidence level (and further partitioning of the RACH preambles for CFRA for different ranges of confidence).

[0252] The configuration may comprise parameters related to different levels of power ramping, max RACH attempts, etc. for confidence level intervals, etc., depending on, e.g., prediction confidence level.

[0253] The WTRU (e.g., UE) may perform current measurements of candidate / serving cells and may perform measurement prediction of candidate / serving cells (e.g., based on location, current serving cells being measured, mobility / trajectory, etc.). The WTRU (e.g., UE) may determine the confidence levels of one or more (e.g., each) measurement prediction (e.g., if confidence level of prediction is variable).

[0254] The WTRU (e.g., UE) may monitor the conditions for triggering RA to at least one candidate cell based on measurement predictions.

[0255] In a case where (e.g., when) the conditions for triggering RA to a candidate cell based on predicted measurements are fulfilled, the WTRU (e.g., UE) may determine to send a request / indication to the source cell (e.g., requesting permission, e.g., PDCCH order, to perform RA to the candidate) or may perform the RA to the candidate cell autonomously.

[0256] In a case where (e.g., when) the conditions for triggering RA to a candidate cell based on predicted measurements are fulfilled, the WTRU (e.g., UE) may perform the RA according to the confidence level of the measurement prediction and the configuration that is associated with the confidence level of the measurement prediction.

[0257] In a case where (e.g., when) the conditions for triggering RA to a candidate cell based on predicted measurements are fulfilled, the WTRU (e.g., UE) may indicate explicitly the measurement prediction details that led to the decision to the triggering of the RA.

[0258] The WTRU (e.g., UE) may receive the TA (from the source / target).

[0259] The WTRU (e.g., UE) may be configured with different RACH related parameters to apply depending on prediction confidence or / and time horizon.

[0260] According to some embodiments, the WTRU (e.g., UE) may be configured with an event that considers current and / or predicted measurements of serving / candidate cells, and upon the fulfillment of the conditions, the WTRU (e.g., UE) may perform RACH to the concerned target cell (e.g., the WTRU (e.g., UE) may transmit a RACH preamble to the target cell).

[0261] According to some embodiments, the WTRU (e.g., UE) may be configured with different RACH preambles or RACH partitions, where one or more (e.g., each) preamble or RACH partition corresponds to different confidence levels of the measurement prediction that led to the fulfillment of the event conditions. For example, the WTRU (e.g., UE) may be provided with one or more preambles that are grouped under group X and other preambles under group Y, and configured touse a RACH preamble within group X if the confidence level of the prediction that led to the event triggering was below a certain threshold, but otherwise use a preamble within group Y.

[0262] According to some embodiments, the WTRU (e.g., UE) may be configured to use contention-based RACH if the confidence level of the prediction that led to the event triggering is below a certain threshold.

[0263] According to some embodiments, the WTRU (e.g., UE) may be configured with different sets of parameters related to the initial power (e.g., preambleReceivedTargetPower, msgA- PreambleReceivedTargetPower, etc.) to be used for RACH that may use (e.g., depend on) the confidence level of the prediction that led to the event triggering. For example, the WTRU (e.g., UE) may be provided to use a higher power level for RACH when the confidence level of the prediction is above a certain threshold, and use a lower power level when the confidence level of the prediction is below a certain threshold, etc.

[0264] According to some embodiments, the WTRU (e.g., UE) may be configured with different set of parameters related to the power ramping to be used during RACH retries (PreamblePowerRampingStep, MsgA-PreamblePowerRampingStep, etc.) that may use (e.g., depend on) the confidence level of the prediction that led to the event triggering. For example, the WTRU (e.g., UE) may be provided to use a higher power ramping step for RACH when the confidence level of the prediction is above a certain threshold, and use a lower power ramping step when the confidence level of the prediction is below a certain threshold, etc.

[0265] According to some embodiments, the WTRU (e.g., UE) may be configured with different set of parameters related to the number of retries of the RACH power ramping to be used during RACH retries (e.g., preambleTransMax, msgA-TransMax, etc.) that may use (e.g., depend on) the confidence level of the prediction that led to the event triggering. For example, the WTRU (e.g., UE) may be provided to use a higher power ramping step for RACH when the confidence level of the prediction is above a certain threshold, and use a lower power ramping step when the confidence level of the prediction is below a certain threshold, etc.

[0266] The WTRU (e.g., UE) may be configured with different behavior depending on whether it is the source or target that provides the RAR / TA.

[0267] According to some embodiments, the WTRU (e.g., UE) may be configured to receive the Random Access Response (RAR) from the target cell in response to the RACH preamble that it has sent to the target (i.e., as in legacy RACH).

[0268] According to some embodiments, the WTRU (e.g., UE) may be configured to receive the RAR from the source cell in response to the RACH pre-amble that it has sent to the target.

[0269] According to some embodiments, if the WTRU (e.g., UE) may be configured to receive the RAR from the source cell, it may be further configured with some condition (e.g., waiting time) before retrying to send the RACH pre-amble.

[0270] The WTRU (e.g., UE) may be configured with different behavior related to actions when RACH fails for more than the configured RACH retries count.

[0271] In legacy MAC operation, the WTRU (e.g., UE), upon determining that it has failed to receive a RAR / TA after transmitting a RACH pre-amble after the configured maximum number of retries, will indicate a Random Access problem to the RRC. This will be interpreted as a radio link failure (RLF) by the RRC, and radio link re-establishment may be triggered.

[0272] For the WTRU (e.g., UE), re-establishment may cause a considerable service interruption because most of the WTRU (e.g., UE) context may be released, the PDCP / RLC may be reestablished, MAC may be reset, etc.

[0273] For the network, re-establishment, especially when several WTRUs (e.g., UEs) trigger it, will cause high signaling overhead (both at the air interface for full reconfiguration, and possible X2 interactions between source and target, if the WTRU (e.g., UE) context is to be fetched to avoid involving CN).

[0274] Triggering re-establishment while RACH may be performed based on predictions is thus highly undesirable.

[0275] According to some embodiments, the WTRU (e.g., UE) may be configured not to consider it an RA failure if the RA procedure that failed was performed based on events that were dependent on predicted conditions. This can be accomplished, for example, by the MAC not sending the indication of failure to the RRC in these cases, or the MAC indicating to the RRC that the problem occurred during RA procedure that was triggered due conditions related to predictions, and RRC deciding not to triggering re-establishment.

[0276] According to some embodiments, the WTRU (e.g., UE) may be configured not consider the failure of prediction based RA procedure as an RA failure based on the confidence level of the prediction that led to the triggering of the RA procedure. For example, if the confidence level was below a certain level, then RA problem may be ignored, while if the confidence level was above a certain level, then RA problem could be acknowledged by the WTRU (e.g., UE) and RLF declared (and associated re-establishment or RLF recovery procedure triggered).

[0277] The WTRU (e.g., UE) may be configured to send a request for PDCCH order to trigger RACH.

[0278] According to some embodiments, it may be assumed that the WTRU (e.g., UE) will perform the RA immediately upon the fulfillment of the events that were related to current and / or predicted measurements.

[0279] According to some embodiments, upon the fulfilment of the conditions for performing RA are fulfilled, the WTRU (e.g., UE) may transmit a request to the serving cell (e.g., current PCell or PSCell), requesting a PDCCH order to initiate the RA operation with the target. This request could be indicated in a UCI, MAC CE, etc., and may further include the identity (e.g., cell ID, PCI, etc.) of the concerned cell. If a subsequent PDCCH order is received from the serving cell, the WTRU (e.g., UE) may perform the RA to the target cell.

[0280] According to some embodiments, the WTRU (e.g., UE) may transmit the request for a PDCCH order for more than one candidate cell (e.g., including the identity, e.g., cell ID, of several candidate cells, in a MAC CE). The WTRU (e.g., UE) may be configured with the maximum number of cells that can be included in this indication or / and a signal level threshold (e.g., cells that have predicted signal level above this threshold). Further information regarding the preference of the WTRU (e.g., UE) among these candidates can be included in the indication (e.g., preference may be related to the relative difference among the predicted signal levels of the candidates). This preference / priority level can be indicated either explicitly or implicitly (e.g., the cells indicated in the MAC CE are ordered according to the radio signal level of these cells and / or the time horizon duration for which the conditions are fulfilled for the cells, etc.).

[0281] According to some embodiments, the WTRU (e.g., UE) may indicate the confidence level(s) or time horizon(s) of the prediction of the one or more cells indicated in the request for PDCCH order. This could be an explicit indication, or an implicit indication (e.g., some index values may be preconfigured indicating confidence levels and / or time horizons, and WTRU (e.g., UE) will include the concerned index value(s)).

[0282] According to some embodiments, the WTRU (e.g., UE), upon the PDCCH order, may apply a similar RACH configurations / behavior as discussed above for the case of immediate RA triggering.

[0283] According to some embodiments, the WTRU (e.g., UE) may be provided with further configuration in the PDCCH order regarding the RACH configuration / behavior to apply. For example, the WTRU (e.g., UE) may be pre-configured with different RACH configurations, and the PDCCH order may include an indication to the RACH configuration to apply.

[0284] According to some embodiments, the WTRU (e.g., UE) may determine whether to send the RACH preamble immediately or request for a PDCCH order using (e.g., depending on) the confidence level or / and time horizon of the prediction that triggered the event. For example, for ahigh confidence level, the WTRU (e.g., UE) may send the RACH preamble to the target immediately, for a low confidence level, the WTRU (e.g., UE) may send the request for PDCCH order to the source.

[0285] According to some embodiments, the WTRU (e.g., UE) may be configured to determine whether to perform the RA to the target immediately or send a request to the source using (e.g., depending on)the confidence level of the prediction that led to the triggering of the RA or the time horizon of the prediction (e.g., if confidence is above a certain threshold, perform RA to the target immediately, otherwise, send a request to the source for a PDCCH order, etc.).

[0286] It should be noted that the above RACH parameters that were discussed to be configurable dependent on prediction confidence levels are not an exhaustive list. That is, the embodiments for RACH configurations can be applied to any RACH parameter that is configurable as specified in TS 38.331 and TS 38.321.

[0287] Certain embodiments for RACH configuration that is dependent on confidence level of prediction can also be made for different time horizon predictions. For example, a different RACH partition is used depending on whether the prediction was for a shorter time horizon as compared to a longer time horizon. As another example, both confidence level and time horizon conditions can be associated with different RACH configurations.

[0288] Certain embodiments are not limited to LTM and applicable to any situation the WTRU (e.g., UE) need to perform RA (e.g., initial access, HO / CHO with RACH, adding / changing of secondary cell group for dual connectivity, etc.). For example, if the WTRU (e.g., UE) is performing a RA towards a target cell for preparing the target cell during in anticipation of the conditions being fulfilled for CHO or conditional secondary cell addition / change based on predicted measurement of serving / target cells, the WTRU (e.g., UE) may indicate to the network that the RA may be being triggered based on predicted conditions. According to some embodiments, this indication could be implicit, based on pre-configured RACH preambles for RA performed based on predicted measurements.

[0289] According to some embodiments, the WTRU (e.g., UE) may consider current or predicted UL / DL traffic volume in deciding when to perform the RA based on predicted measurements. For example, if the RA is being performed in anticipation of a handover, and the WTRU (e.g., UE) cannot perform the RA to the target while at the same time as UL / DL transmission with the source (e.g., due to limited WTRU (e.g., UE) capability), the WTRU (e.g., UE) may wait until there is a break in the UL / DL data traffic flow (and the break is predicted to last long enough to finish the RA procedure) to send the RACH preamble.

[0290] According to some embodiments, the WTRU (e.g., UE) may indicate, in the RA (msgl), whether it prefers the RAR via the source or the target.

[0291] According to some embodiments, the WTRU (e.g., UE) may be able to receive the RAR either from the source or target, whichever may be received first. In this case, the WTRU (e.g., UE) may ignore / discard the second RAR, if received at all.

[0292] RACH partitioning for different levels of confidence levels or time horizons of predictions as discussed above could be expensive.

[0293] According to some embodiments, the WTRU (e.g., UE) may determine to trigger a 2 step RACH or 4 step RACH depending on current and predicted radio conditions of the target / serving cells (absolute thresholds, relative thresholds, etc.).

[0294] According to some embodiments, the WTRU (e.g., UE) may send a message (e.g., MAC CE) to the serving PCell or target cell simultaneously as initiating the RA (e.g., wherein the MAC CE includes the confidence level, time horizon, etc.). To make the MAC CE simple and smaller in size, the WTRU (e.g., UE) may receive a configuration index for different confident interval levels and / or prediction time horizons and include the concerned index value(s) in the MAC CE.

[0295] According to some embodiments, the WTRU (e.g., UE) may include the additional information about the prediction in MsgA (if 2 step RACH is used).

[0296] According to some embodiments, the WTRU (e.g., UE) may be configured with dedicated preamble(s) to use for CFRA when performing RA based on predictions that further contains validity time. If a RA procedure is not performed / triggered within the validity time, the WTRU (e.g., UE) will perform the RA using CBRA.

[0297] Methods and procedures related to dynamic / autonomous activation / deactivation of CGs for RACH less CHO are described below.

[0298] WTRU (e.g., UE) may be configured with a multitude of LTM / CHO candidate cells and associated configured grants (type 2) to use for RACHless CHO in these cells. The WTRU (e.g., UE) may be configured with conditions to trigger CG activation and conditions for triggering the CHO. The conditions to trigger CG activation can be based on current and / or predicted measurements. The WTRU (e.g., UE) may monitor the conditions for triggering CG activation and may send a CG activation request when the conditions are fulfilled. When the conditions for the triggering of the CHO are fulfilled later, if the activated CG occasions are still valid, The WTRU (e.g., UE) uses the CG(s) to perform a RACH-less CHO.

[0299] According to some embodiments, the procedure may comprise any of the following steps.

[0300] A WTRU (e.g., UE) may receive a configuration of LTM candidate cells, further including one or more of the following: one or more CG configurations for RACH less HO forone or more (e.g., each) candidate cell (e.g., type 2 CG), where the CG configurations for one or more (e.g., each) candidate cell may have a configuration ID; and (2) a configuration related to Conditional Handover (CHO) (e.g., a first threshold associated with an L1 / L3 A3 / A4 / A5 event, i.e., when the CHO is to be executed towards a target)

[0301] The WTRU (e.g., UE) may receive AIML related configuration for CG activation of a candidate cell, that contain one or more of the following: (1) configuration related to autonomous CG activation (e.g., a second threshold associated with an A3 / A4 / A5 event, where the thresholds are related to predicted measurements of serving / candidate cells); and (2) configuration related to actions / conditions how to perform the CG activation (e.g., expected time between CG activation request and response, expected time saving in performing the mobility action with a CG, maximum waiting time to defer / postpone a mobility action to use a CG, RSRP threshold of serving cell for enabling waiting for a CG occasion without risking a radio link failure, max number of CG occasions that can be requested by the WTRU (e.g., UE), indexes for identifying different prediction confidence levels and / or prediction time horizons, etc.).

[0302] The WTRU (e.g., UE) may perform current measurements of candidate / serving cells and may perform measurement prediction of candidate / serving cells (e.g., based on location, current serving cells being measured, mobility / trajectory, etc.). The WTRU (e.g., UE) may determine the confidence levels of one or more (e.g., each) measurement prediction (e.g., if confidence level of prediction is variable)

[0303] The WTRU (e.g., UE) may monitor the conditions for CG activation of one or more candidate cells based on the CG activation configuration and current / predicted measurements.

[0304] If / when the conditions are fulfilled for activating a CG for a candidate cell based on predicted measurements, The WTRU (e.g., UE) may send a CG activation request to the network. This may include additional information such as the confidence / time horizon of the measurement predictions that triggered the CG activation condition, CG occasions to be activated, etc.

[0305] The WTRU (e.g., UE) may receive from the network an implicit / explicit approval or rejection of the activation of requested CGs (or CGs to be activated that are different from the requested CGs)

[0306] The WTRU (e.g., UE) may determine if / when the conditions are fulfilled for performing the CHO towards a target cell.

[0307] If there is an activated CG in the target cell (e.g., within the configured maximum waiting time for postponing the CHO for the sake of utilizing a CG) and / or the signal level of the serving cell is above the configured RSRP threshold, the WTRU (e.g., UE) uses the concerned CG to complete the CHO without RA.

[0308] Else (e.g., no CG activated, CG was activated but its occasion has already passed, CG is activated / available, but it is occasion is farther away in time than the maximum configured waiting time, signal level of serving cell is below the configured threshold, etc.), the WTRU (e.g., UE) may perform RA first to completes the CHO execution.

[0309] Before an activated CG occasion, the WTRU (e.g., UE) may send an indication to the network if that CG occasion is going (or expected) to be used or not (i.e., conditions are not fulfilled or are not expected to be fulfilled at the next CG occasion).

[0310] The WTRU (e.g., UE) may be configured to request the activation of one or more CG occasions in anticipation of an imminent HO / CHO.

[0311] According to some embodiments, the WTRU (e.g., UE) may be configured with an event that considers current and / or predicted measurements of serving / candidate cells, and upon the fulfillment of the conditions, the WTRU (e.g., UE) may send an indication / request to the network to activate previously configured type 2 CG occasions (e.g., this is in anticipation of a mobility related event, such as a CHO).

[0312] According to some embodiments, the activation indication / request may be sent by the WTRU (e.g., UE) using a UCI signaling.

[0313] According to some embodiments, the activation indication / request may be sent by the WTRU (e.g., UE) using a MAC CE.

[0314] According to some embodiments, the activation indication / request may be sent by the WTRU (e.g., UE) using RRC signalling.

[0315] According to some embodiments, the WTRU (e.g., UE) includes additional information indicating the reason / cause for the activation request. For example, if the WTRU (e.g., UE) is sending the request in anticipation of a mobility related event such as a CHO based on predicted / current measurements, the WTRU (e.g., UE) may indicate that in the request (e.g., include event ID, measurement ID, etc.).

[0316] According to some embodiments, the WTRU (e.g., UE) may be previously configured with a lead time (e.g., in ms, in number of slots, etc.) information, indicating on how late it can request for a particular CG occasion (e.g., the WTRU (e.g., UE) can request an activation of a CG (e.g., only) if that CG occasion is occurring at least after the configured lead time from the time the request is sent by the WTRU (e.g., UE)).

[0317] According to some embodiments, the WTRU (e.g., UE) may be configured with the maximum CG occasions it can request to be activated.

[0318] According to some embodiments, the WTRU (e.g., UE) may include one or more of the following in the CG activation request: (1) number of CG occasions to be activated, (2) the firstCG occasion to be activated, (3) the last CG occasion to be activated, (4) earlier slot / time the CG may be needed by the WTRU (e.g., UE), and (5) latest slot / time the CG may be needed by the WTRU (e.g., UE).

[0319] According to some embodiments, the WTRU (e.g., UE) waits for an explicit response from the network before it assumes the requested CG occasions are activated. The response can be either positive or negative (i.e., approval or rejection of the request).

[0320] According to some embodiments, the WTRU (e.g., UE) will implicitly consider the CG occasions as activated if it does not get a negative response from the network within a given time (e.g., a given configured time duration).

[0321] According to some embodiments, the WTRU (e.g., UE) will implicitly consider the CG occasions as not activated if it does not get a positive response from the network within a given configured time (e.g., a given length of actual time, e.g., milliseconds, a given number of slots, etc.).

[0322] For the rest of the disclosure, the terminology “CG activation approved” may be used to indicate that the WTRU (e.g., UE) has determined that the network has either explicitly or implicitly confirmed the request as discussed above. Similarly, the terminology “CG activation denied” may be used to indicate that the WTRU (e.g., UE) has determined that the network has either explicitly or implicitly rejected the request as discussed above.

[0323] According to some embodiments, if the WTRU (e.g., UE) has indicated (e.g., only) the first CG occasion to be activated and its request has been approved, it considers all subsequent CG occasions after the requested first CG occasion are available / activated until / unless it gets an explicit deactivation signal from the network.

[0324] According to some embodiments, if the WTRU (e.g., UE) has indicated the start and end of the CG occasions that it needs to be activated (e.g., first CG occasion and number of CG occasions required, first CG occasion and last CG occasion, first CG occasion and time periodic the CGs are required to be activated, etc.) and the request has been approved, it considers the CG occasions after the last requested CG occasions to be deactivated (unless it gets an indication to activate them from the network, e.g., before the last requested CG occasion).

[0325] According to some embodiments, the WTRU (e.g., UE) may get a partial approval from the network, where (e.g., only) a subset of the CG occasions that it has requested are approved. For example, the WTRU (e.g., UE) may send a request to activate n CG occasions after CG occasion x, and the network may respond by approving (e.g., only) n-1 of those CG occasions.

[0326] According to some embodiments, the WTRU (e.g., UE) may be configured with a multitude of CG configurations (e.g., each with CG configuration IDs), and the WTRU (e.g., UE)may simply indicate the ID of the configuration in the CG activation request (i.e., network will implicitly know the first occasion, CG periodicity / duration, last occasion etc., from the CG configuration ID).

[0327] According to some embodiments, the WTRU (e.g., UE) may receive an approval of a CG configuration activation that has a different ID than requested by the WTRU (e.g., UE) (e.g., WTRU (e.g., UE) requesting the activation of CG configuration ID1, network approving configuration ID 2, etc.).

[0328] According to some embodiments, the WTRU (e.g., UE) may include information in the CG activation request, such as any of: (1) the confidence level of the prediction of the one or more metrics of the event that led to triggering of the CG activation request, and (2) the prediction time horizon.

[0329] According to some embodiments, the WTRU (e.g., UE) may be configured with indexes that are associated with certain prediction confidence levels and prediction time horizons, and the WTRU (e.g., UE) includes that index in the CG activation request. For example: (1) if confidence level is above 95%, index =0; (2) if confidence level is between 90% and 95%, index =1; (3) if confidence level is between 80% and 90%, index =3; and (4) if confidence level is below 80%, index = 4.

[0330] According to some embodiments, the WTRU (e.g., UE) may be configured to include, within one CG activation request, several options depending on the prediction confidence level. For example, the WTRU (e.g., UE) may indicate any of the following in one CG activation request message:(1) U_ID=1, first CG occasion xl, number of CG occasion nl, confidence level index =indexl.(2) U_ID=2, first CG occasion x2, number of CG occasion n2, confidence level index =index3.(3) U_ID=3, first CG occasion x2, number of CG occasion n2, confidence level index =index5.

[0331] Here, the U_ID refers to a WTRU (e.g., UE)-assigned identity of the requested CG occasion(s), and not necessarily the same as the confidence level index, or any pre-configured CG configuration ID discussed above.

[0332] According to some embodiments, if the WTRU (e.g., UE) has indicated several WTRU (e.g., UE) assigned CG IDs as in the example above, it may receive a response from the network that indicate the U_ID of the CG that is being approved.

[0333] The WTRU (e.g., UE) may be configured to cancel / update approved activations.

[0334] If the request to activate one or more CGs was based on predicted measurements, the WTRU (e.g., UE) may later find out that the predictions were not correct (e.g., the WTRU (e.g., UE) may have predicted, at time tl, that the CHO conditions to be fulfilled at time t2, but at timet3 before t2, the WTRU (e.g., UE) may have determined that the previous prediction was not correct, etc.).

[0335] According to some embodiments, the WTRU (e.g., UE) considers the predictions were not correct if the first approved CG occasion was not used (e.g., the current measurement at the time of the first CG occasion were below the level that they were predicted to be to fulfill the mobility related action conditions etc.).

[0336] According to some embodiments, the WTRU (e.g., UE) considers the predictions were not correct if a certain number of approved CG occasions were not used.

[0337] According to some embodiments, the WTRU (e.g., UE) considers the predictions were not correct even before the occurrence of the first approved CG occasion if it determines that the current measurements differ significantly from predicted measurements (e.g., based on a configured error margin level). For example, the WTRU (e.g., UE) may continuously or periodically perform the predictions and compare the predicted values with the actual values as time passes, and if it determines that the predicted and actual values differ significantly even before the occasion of the first CG, it may send the cancelation request. This decision may be made by considering (e.g., only) one pair of actual and predicted measurements, or the WTRU (e.g., UE) may be configured with some filtering parameters. For example, the WTRU (e.g., UE) may compare the average error level of the last n predicted and actual measurements (or the predicted and actual measurements within a sliding window of time duration t) with some threshold, where the averaging can be a linear averaging or a weighted one where the more recent measurements have more averaging weight assigned to them.

[0338] According to some embodiments, the WTRU (e.g., UE) may send an indication to cancel a previously approved CG occasion(s).

[0339] According to some embodiments, the WTRU (e.g., UE) may include additional indication regarding the cancelation (e.g., measurement prediction was not correct / accurate).

[0340] According to some embodiments, the WTRU (e.g., UE) may send an update to a previously approved CG occasion (e.g., modify the first requested CG occasion, the number / duration of CG occasions, etc.).

[0341] According to some embodiments, if the WTRU (e.g., UE) was preconfigured with multiple CG configurations, each with an ID as discussed in some of the previous embodiments, and it was approved to use one of these CG configurations (e.g., IDx), and may determine that the prediction that led to the choosing of that configuration may be not correct / accurate, it may send an update / switching to another CG configuration (e.g., IDy).

[0342] Mobility related action triggering conditions may be fulfilled before or after the approved CGs.

[0343] According to some embodiments, if the triggering conditions for the mobility related action (e.g., for the sake of which the CG activation request was sent by the WTRU (e.g., UE) beforehand) are fulfilled before the first approved CG occasion, the WTRU (e.g., UE) may wait until that CG occasion before performing the mobility related action. For example, if the CHO conditions based on current measurement get fulfilled even before the predicted / expected time, the WTRU (e.g., UE) waits until the first CG occasion to execute the CHO.

[0344] According to some embodiments, if the triggering conditions for the mobility related action are fulfilled before the first approved CG occasion, the WTRU (e.g., UE) may not wait until that CG occasion before performing the mobility related action. For example, if the CHO conditions based on current measurement get fulfilled even before the predicted / expected time, the WTRU (e.g., UE) may execute the CHO using RACH.

[0345] According to some embodiments, if the triggering conditions for the mobility related action are fulfilled before the first approved CG occasion, the WTRU (e.g., UE) may determine to wait until that CG occasion or directly execute the mobility related action depending on some preconfigured condition.

[0346] If the time before the first CG occasion is less than a certain threshold, wait for the first CG occasion, otherwise, execute the action immediately.

[0347] If the time before the first CG occasion is less than the amount of extra time needed to execute the mobility action without a CG (e.g., RA to the CHO target), wait for the first CG occasion, otherwise, execute the action immediately. This comparison can be left to WTRU (e.g., UE) implementation, or the network may have configured the WTRU (e.g., UE) with expected RA procedure times, e.g., different time duration for different candidate cells / frequencies, etc.

[0348] All the above considerations are also applicable to the case where the first approved CG occasion has passed but there are one or more subsequent CG occasions that also have been approved. For example, if two CG occasions were approved for a WTRU (e.g., UE) and the triggering conditions for the mobility related action get fulfilled after the first CG occasion has passed but before the second CG occasion, the WTRU (e.g., UE) may make similar determinations as the previous embodiments above regarding whether to wait for the occurrence of the second CG occurrence or execute the mobility related action immediately.

[0349] According to some embodiments, if the triggering conditions for the mobility related action are fulfilled after the first approved CG occasion, the WTRU (e.g., UE) may execute the mobility related action immediately without (e.g., start with RA when executing the CHO).

[0350] According to some embodiments, if the triggering conditions for the mobility related action are fulfilled after the last approved CG occasion, the WTRU (e.g., UE) may execute the mobility related action immediately without (e.g., start with RA when executing the CHO).

[0351] According to some embodiments, if the triggering conditions for the mobility related action are fulfilled after the last approved CG occasion, the WTRU (e.g., UE) may send a request to the network for approval of new CG occasion(s). This approval request can include an indication that this request is being made not based on predictions but based on actual measurements (i.e., there is a guarantee that the resources will be used by the WTRU (e.g., UE).).

[0352] According to some embodiments, the WTRU (e.g., UE) may send a new request for an activation of one or more CG occasions after the mobility event conditions have actually been fulfilled if the expected time for performing a RA with the target is less than a certain configured threshold.

[0353] According to some embodiments, the WTRU (e.g., UE) may send a new request for an activation of one or more CG occasions after the mobility event conditions have actually been fulfilled if the radio conditions with the source are above a certain configured threshold.

[0354] Methods and procedures for performance monitoring for AIML based actions are described below.

[0355] WTRU (e.g., UE) may receive a configuration on how to determine the accuracy of AIML related actions (e.g., has the WTRU (e.g., UE) performed a HO to a given target after doing a preemptive RACH to the target based on prediction, has the WTRU (e.g., UE) ended up using the CGs that it has activated in advance in anticipation of a CHO to a target, etc.), metrics to be used for doing performance monitoring (e.g., number of consecutive inaccurate actions, number / percentage of inaccurate actions within a given duration, etc.), thresholds / conditions for triggering performance monitoring related actions (e.g., number of consecutive inaccurate actions greater than nl, etc.), and the performance monitoring action to be applied when the triggering conditions are fulfilled (e.g., prohibit the usage of the AIML related action / model / function for a given time, retrain the model, switch to another model, stop using AIML for the concerned functionality, etc.). The WTRU (e.g., UE) may monitor the performance of AIML related actions according to the received configuration, and when the thresholds / conditions for triggering a performance monitoring related action are fulfilled, may execute the action associated with the fulfilled conditions.

[0356] According to some embodiments, the procedure may comprise any of the following steps.

[0357] A WTRU (e.g., UE) may receive a configuration related to performance monitoring of AIML related actions: (1) configuration on how to determine whether a prediction-based AIMLrelated action was accurate or not; (2) metrics to be monitored (e.g., number of consecutive inaccurate actions, number of or percentage of inaccurate actions within a given time duration, etc.); (3) thresholds / conditions for triggering performance monitoring actions for the different performance metrics being monitored (e.g., action to be triggered when the number of consecutive inaccurate actions is above nl, etc.); and (4) performance monitoring action to be taken (e.g., prohibition of the AIML related action / model / function for a certain configured prohibit time duration, triggering of model retraining, switching to a more accurate / most costly model, switching to a different AIML functionality, switching to legacy, i.e., non AIML based, operation, send performance monitoring report, etc.).

[0358] Depending on the level of inaccuracy detected, the same action can be applied with different parameters (e.g., longer prohibit timer for higher number of inaccuracies, etc.).

[0359] The WTRU (e.g., UE) may determine the accuracy of a prediction-based action based on the performance monitoring configuration (e.g., whether the action did lead to an anticipated outcome or not, etc.).

[0360] The WTRU (e.g., UE) may monitor the triggering conditions for performance monitoring action based on the determined accuracy of at least one prediction-based action (e.g., count the number of inaccurate prediction-based actions within a configured time duration and compare with the configured maximum threshold, etc.).

[0361] If the triggering conditions for a certain performance monitoring action are fulfilled, the WTRU (e.g., UE) may execute the performance monitoring action (e.g., pause the related prediction-based action for a configured prohibit timer, retrain the model, request the network to retrain the model, switch to another model, switch to legacy, etc.). The WTRU (e.g., UE) may update some of the parameters that affect the performance monitoring action based on the fulfilled triggering conditions (e.g., longer prohibit timer applied for higher level of inaccuracies with a given time, etc.).

[0362] The WTRU (e.g., UE) may transmit indication of status of a prediction-based action (e.g., inform network about performance monitoring actions taken, transmit a performance monitoring report for one or more prediction-based actions within a given configured time duration, etc.).

[0363] Most of the embodiments may be made using a model-based LCM assumption (e.g., multiple models available for a given AIML function / action, and the WTRU (e.g., UE) switching between the models based on performance monitoring, either autonomously or on getting a confirmation / command form the network, etc.). However, certain embodiments are equally applicable to functionality-based LCM (e.g., only one model for a given AIML function / action, or even if multiple models are available used for a given function / action, the control by the networkmay be made at a functionality level and it may leave up to the WTRU (e.g., UE) to decide among the models, etc.).

[0364] The WTRU (e.g., UE) may be configured with performance monitoring configuration for an AIML related action.

[0365] According to some embodiments, the WTRU (e.g., UE) may be configured to monitor the performance of one or more AIML related actions, and may be provided with one or more performance monitoring metrics, and related actions (henceforth referred to as performance monitoring related actions, or PMA, to distinguish form AIML related actions, with are actions triggered based on AIML, e.g., prediction based on AIML model) that may be associated with conditions / thresholds related to the one or more performance monitoring metrics.

[0366] The performance monitoring metrics can be one or more of the following: (1) total / Average / Minimum number of times that an AIML related action was inaccurate (e.g., within a given time duration); (2) total / Average / Minimum number of times that an AIML related action was accurate (e.g., within a given time duration, after a certain number of inaccurate AIML actions, etc.); (3) fraction / percentage of times that an AIML related action was accurate / inaccurate (e.g., within a given time duration); (4) consecutive number of times that an AIML related action was inaccurate (e.g., within a given time duration); and (5) consecutive number of times that an AIML related action was accurate (e.g., within a given time duration, after a certain number of consecutive inaccurate actions, etc.).

[0367] It should be noted that the above are just examples and any statical measure that consider the occurrences of the accurate and inaccurate AIML related actions can be configured as a performance monitoring metrics (e.g., standard deviations, mode, ranges, rate of variations, etc.).

[0368] There could be interdependence between the metrics. For example, the WTRU (e.g., UE) may not monitor the consecutive number of accurate actions unless it has already determined there has been a certain number of consecutive inaccurate actions. If the configured number of consecutive accurate actions are performed before any inaccurate action, a PMA may not be triggered.

[0369] According to some embodiments, the WTRU (e.g., UE) may be configured with the counter and timer variables to keep the performance monitoring. For example, one or more counters can be defined, with initial values of zero, and incremented every time an accurate or inaccurate AIML related action may be determined (if the counters are related to consecutive accurate / inaccurate actions, the counters may be reset to zero when the accuracy / inaccuracy streak may be broken, e.g., when detecting an inaccurate action after a sequence or accurate actions orvice versa). Similarly, timers with specific time values can be started to keep track of a specific performance monitoring epoch (e.g., time duration for sequence of inaccurate actions, etc.).

[0370] According to some embodiments, the WTRU (e.g., UE) may be configured with one or more threshold values concerning the performance metric that is to be monitored that trigger the AIML related action. For example, the WTRU (e.g., UE) may be configured with a threshold corresponding to the maximum number of times an AIML related action was found to be inaccurate to trigger the associated PMA. As another example, the WTRU (e.g., UE) may be configured with a threshold corresponding to the maximum number of consecutive inaccurate AIML related actions before a PMA is triggered. There could also be cases where the PMA may use (e.g., depend on) a combination of more than one or more metrics. For example, a PMA could be triggered if less than n2 consecutive accurate AIML related actions are taken after it has been detected that there were nl consecutive inaccurate AIML related actions (that is, if n2-l consecutive accurate actions were taken but the n2th one was determined to be inaccurate, a PMA will be triggered).

[0371] An AIML related action may be considered to be accurate if the action that was taken by a prediction comes true (e.g., within a given time duration after the action was taken) and / or was not reverted within a given duration).

[0372] A WTRU (e.g., UE) performed a RACH to a candidate set in anticipation of a HO (e.g., based on predicted measurements), and it was determined that the WTRU (e.g., UE) indeed performed the HO to that target within a given time.

[0373] A WTRU (e.g., UE) that activated one or more CGs in a candidate cell in advance for RACH less HO / LTM / CHO used the one or more CGs to complete / execute the HO (e.g., send the HO complete using one of the CGs, sent data using one of the CGs, etc.).

[0374] A WTRU (e.g., UE) that triggered a CHO to candidate cell based on measurement predictions did not handover back again to the source cell (or another candidate cell) within a given time duration after that (i.e., ping pong HO or too short HO was not performed due to prediction errors).

[0375] A WTRU (e.g., UE) has triggered a report based on prediction (radio measurement report, buffer status report, etc.), and when the prediction time horizon arrives, the current measurement / buffer are within a small error margin of the previously predicted value that was reported to the network, etc.

[0376] An AIML related action may be considered to be inaccurate if subsequent actions / measurements taken by the WTRU (e.g., UE) show that the action taken was not the correctone (e.g., the AIML related action was reverted, another action was taken within a given time duration, etc.).

[0377] A WTRU (e.g., UE) performed a RACH to a candidate set in anticipation of a HO (e.g., based on predicted measurements), and it was determined that the WTRU (e.g., UE) didn’t perform a HO to that target within a given time or the WTRU (e.g., UE) did perform a HO to another cell instead.

[0378] A WTRU (e.g., UE) that activated one or more CGs in a candidate cell in advance for RACH less HO / LTM / CHO but none of the CGs were used to complete / execute the HO (e.g., WTRU (e.g., UE) didn’t execute the HO to that cell, or it did execute the HO to that candidate cell but (e.g., only) after the CGs occasion has passed, etc.).

[0379] A WTRU (e.g., UE) that triggered a CHO to candidate cell based on measurement predictions hands over back again to the source cell (or another candidate cell) within a given time (i.e., ping pong HO or too short HO was performed due to prediction errors).

[0380] A WTRU (e.g., UE) has triggered a report based on prediction (radio measurement report, buffer status report, etc.), where the report is either sent to the network or logged for later data collection by the network, and when the prediction time horizon arrives, the current measurement / buffer are outside a big error margin of the previously predicted value that was reported to the network or logged at the WTRU (e.g., UE) (e.g., the current measurements are lower than or greater than by a certain margin as compared with the measurements that were predicted, etc.).

[0381] According to some embodiments, the performance monitoring may be done together for all AIML related actions, and all actions are considered to have the same importance. For example, the WTRU (e.g., UE) will not distinguish between AIML related action A and AIML related action B, when counting the number of times an AIML related action was accurate.

[0382] According to some embodiments, the performance monitoring may be done together for all AIML related actions, but the different actions may have different levels of importance. For example, AIML related action that triggers measurement reports can be considered of lower importance than an AIML related action that triggers the execution of a CHO, etc. The WTRU (e.g., UE) may be preconfigured with the network with the importance level of the different AIML actions (e.g., this could be based on how the inaccuracy of an AIML related action by the WTRU (e.g., UE) can degrade WTRU (e.g., UE) or system level performance). Alternatively, or additionally, the WTRU (e.g., UE) may also inform the network about the importance level from its point of view (e.g., based on how expensive the procedure is from WTRU (e.g., UE) processingpower or battery consumption point of view), and network may take that into consideration to set the importance level of the different AIML related actions.

[0383] According to some embodiments, if the different AIML related actions have different importance levels, the WTRU (e.g., UE) may consider (e.g., only) the top n important (or top x percentage) of the AIML related actions during performance monitoring. For example, the WTRU (e.g., UE) may be capable of performing 5 AIML related actions, with priorities 1 to 5, 1 being the most important. At a particular time, the WTRU (e.g., UE) may not have all the 5 AIML related actions activated. If the WTRU (e.g., UE) is configured to consider (e.g., only) the top 2 important AIML related actions in the performance monitoring, as an example, the following will happen:

[0384] If all the AIML actions are activated, the WTRU (e.g., UE) will consider (e.g., only) the two top priority ones in the performance monitoring.

[0385] If (e.g., only) 2 AIML actions are activated, and these were the two lowest priority ones, the WTRU (e.g., UE) will still consider them in the performance monitoring.

[0386] According to some embodiments, if the different AIML related actions have different importance levels, the WTRU (e.g., UE) may perform weighted averaging when monitoring the performance of AIML related actions. For example, if the WTRU (e.g., UE) has 3 AIML related actions of importance levels 1, 2 and 3, then detection of one inaccurate instance of the top priority AIML related action may count as equivalent to 3 inaccurate instances of the lowest priority AIML related action. Fractional weighting can also be used instead where the highest priority one has a weighing factor of 1, while the others will have a weighting factor that has a fractional value equivalent to 1 / p, where p may be the priority of the concerned AIML related action, and p may be greater than one (i.e., 1 is the highest priority).

[0387] According to some embodiments, the WTRU (e.g., UE) may monitor the performance of AIML related actions independently for one or more (e.g., each) action and related PMA may be also performed independently for one or more (e.g., each) action.

[0388] According to some embodiments, the WTRU (e.g., UE) may monitor the performance of AIML related actions independently for one or more (e.g., each) action, but the PMA affects all AIML related actions.

[0389] According to some embodiments, the WTRU (e.g., UE) may monitor the performance of AIML related actions independently for one or more (e.g., each) action, but the PMA affects all AIML related actions that have a lower / higher / equivalent priority as compared to the AIML related action that triggered the PMA (e.g., if the maximum number of consecutive inaccurate AIML related actions for action A may be reached, the WTRU (e.g., UE) may be configured to take anaction that affects all AIML related actions that have priority equal or smaller than that of action A).

[0390] According to some embodiments, the WTRU (e.g., UE) may monitor the performance of AIML related actions independently, but some or all of the performance monitoring configurations (e.g., thresholds for the metrics being monitored to trigger a PMA) may be shared by the different AIML related actions. For example, the thresholds such as the maximum counter values for consecutive inaccurate actions, the time duration for calculating the inaccuracy rates / percentages, the minimum number of consecutive accurate actions after a certain number of consecutive inaccurate actions, etc.).

[0391] According to some embodiments, performance monitoring for a given AIML related action may be agnostic to the actual model being used (i.e., if the concerned AIML functionality may switch from one model to another, the performance monitoring will be unaffected, and all counters and timers used for performance monitoring will continue as is).

[0392] According to some embodiments, performance monitoring for a given AIML related action may be dependent on the actual model being used (i.e., if the concerned AIML functionality may switch from one model to another, the performance monitoring will be affected, e.g., all counters and timers used for performance monitoring may be reset).

[0393] According to some embodiments, the WTRU (e.g., UE) may be configured to not trigger a PMA before a certain number of AIML related actions have been taken (e.g., since the first time AIML related actions has been activated, since the last time a PMA was taken, etc.).

[0394] According to some embodiments, the WTRU (e.g., UE) may be configured to not trigger a PMA before a certain time duration (e.g., PMA prohibit timer) has elapsed (e.g., since the first time AIML related actions has been activated, since the last time a PMA was taken, etc.).

[0395] According to some embodiments, the WTRU (e.g., UE) may perform a moving average / weighted filtering of the performance metrics being monitored, within a given window, where the window can be a time duration window or / and the number of actions being considered. Two different values can be assigned to accurate and inaccurate actions (e.g., 1 for accurate, 0 for inaccurate), or a more granular approach can be used where a fractional value can be used for the inaccurate ones, where the value depends on how inaccurate the action was (e.g., how different was the predicted measurement from the actual value, by how many slots after the configured CG occasion for RACH less HO did the WTRU (e.g., UE) perform the RACH based CHO to the same target, etc.).

[0396] According to some embodiments, the accuracy determination for a given AIML related action / model / function can be done at higher granularity, where the details of the current WTRU(e.g., UE) / network conditions are also considered. For example, the WTRU (e.g., UE) may be configured to have independent performance monitoring metrics for different frequencies / cells / RAN areas / time of the day, etc. For example, assume the AIML related action is reporting of predicted measurements. The WTRU (e.g., UE) may be configured to keep different metric counter / values for predictions regarding cells of frequency range x and cells of frequency range y. That is, an inaccurate prediction of the measurement of a cell belonging to frequency range x will (e.g., only) affect the performance metric associated with frequency range y. The WTRU (e.g., UE) may be configured to reset the current values of the performance metrics of a given AIML related function when it may perform a HO from a first cell to a second cell, if the two cells use different frequency range, operate in different RATs, do not belong to a given RAN / Tracking area, etc., Alternatively, the WTRU (e.g., UE) may store the current performance metric value s / counters in a WTRU (e.g., UE) variable during the HO, and if it is later handed over to a cell that has the same characteristics as the first cell (e.g., same frequency range, same RAN / tracking area, same RAT, etc.), the WTRU (e.g., UE) may restore the performance metric values that were stored on handing over from the first cell to the second cell.

[0397] According to some embodiments, the PMA may be the sending of a performance report to the network.

[0398] According to some embodiments, the performance report may be sent to the network immediately.

[0399] According to some embodiments, the WTRU (e.g., UE) logs the performance report, and sends them to the network periodically (e.g., based on a configured periodicity).

[0400] According to some embodiments, the WTRU (e.g., UE) logs the performance report and may send them when the report reaches a certain size.

[0401] According to some embodiments, the WTRU (e.g., UE) logs the performance report and may send them when the network requests it.

[0402] According to some embodiments, the WTRU (e.g., UE) may send the logged performance report opportunistically when it has a grant that is more than other user plane or control plane data (e.g., as a padding in the current transport block).

[0403] According to some embodiments, the WTRU (e.g., UE) may send the logged performance report using the user plane (e.g., via a DRB).

[0404] According to some embodiments, the WTRU (e.g., UE) may send the logged performance report using the control plane (e.g., via an SRB, a NAS message encapsulated via an SRB).

[0405] According to some embodiments, the WTRU (e.g., UE) may send the logged performance report in several parts / transmissions / segments.

[0406] According to some embodiments, the WTRU (e.g., UE) may be not configured with thresholds regarding the performance monitoring metrics, but keeps monitoring / counting / measuring the metrics, and may log / send the performance monitoring periodically at a configurated periodicity.

[0407] According to some embodiments, the first step of a PMA may be the generation of a performance report related to one or more AIML related actions at the WTRU (e.g., UE). For example, the current status could be the indication that a certain number of AIML related actions have been detected to be inaccurate for a given time duration, a certain number of consecutive accurate / inaccurate AIML related actions have been detected, etc.

[0408] According to some embodiments, the WTRU (e.g., UE) adds additional information to the performance report such as the time of the day, the location of the WTRU (e.g., UE) when the conditions / thresholds were fulfilled (where location could be actual GNSS location, or information about the serving cell), the list of cells that are relevant to the concerned performance report (e.g., list of cells that the WTRU (e.g., UE) has traversed during the time the conditions for the AIML related action were being monitored, e.g., all the cells where the consecutive inaccurate AIML related actions were detected, and further information such as the number of inaccurate actions in each cell, time stamps, etc.), measurement of serving and neighbor cells at the time of the fulfillment of the conditions / thresholds, etc.

[0409] According to some embodiments, the performance report contains separate parts for the different AIML related actions (e.g., the number of accurate / inaccurate actions are reported / logged separately for the different AIML related actions).

[0410] According to some embodiments, the performance report may be agnostic to the different AIML related actions (e.g., the log just contains the number of accurate / inaccurate actions within the reporting / logging time, without specific indication of the different AIML related actions that were relevant).

[0411] According to some embodiments, the PMA may be the prohibit! on / pausing of an AIML related action for a certain configured duration. For example, if the conditions for a given performance metrics for triggering a PMA are fulfilled (e.g., a certain number of consecutive inaccurate AIML related actions detected within a given time), the WTRU (e.g., UE) pauses the AIML related action for the configured prohibit timer duration (e.g., fallback to legacy operation where the WTRU (e.g., UE)’s decisions / actions are based on actual measurements and not on predictions for the functions that are related to the concerned AIML related action).

[0412] According to some embodiments, the prohibit time may be a fixed / constant time duration.

[0413] According to some embodiments, all AIML related actions share the same prohibit timer duration configuration, and the starting of the prohibit timer due to one AIML related action affects all other AIML related actions (e.g., if one AIML related action was determined to be inaccurate for more than a certain number of consecutive times and the prohibit timer may be started, all other AIML related actions are paused during the prohibit duration).

[0414] According to some embodiments, the prohibit time duration configuration may be the same for all AIML actions, but the pausing affects (e.g., only) the concerned AIML action regarding which the triggering conditions for the PMA were fulfilled (i.e., only that AIML related action will be affected).

[0415] According to some embodiments, the prohibit time duration configuration may be different for different AIML actions, but the pausing affects all the AIML related actions.

[0416] According to embodiments, the prohibit time duration configuration may be different for different AIML actions, and the pausing affects (e.g., only) the action that triggered the PMA.

[0417] According to some embodiments, if an AIML related action of a certain configured priority may be paused, all AIML related actions of the same priority level as the concerned AIML related actions are also paused.

[0418] According to some embodiments, if an AIML related action of a certain configured priority may be paused, all AIML related actions with a priority level lower than the concerned AIML related actions are also paused.

[0419] According to some embodiments, if an AIML related action of a certain configured priority may be paused, all AIML related actions with a priority level higher than the concerned AIML related actions are also paused.

[0420] According to some embodiments, there may be inter-relationship between the different AIML related actions (e.g., configured by the network, based on WTRU (e.g., UE) capability / implementation, etc.), and if one AIML related action is paused, all related / associated AIML related actions are also paused. According to embodiments, there is no hierarchy in the association (e.g., if action A, B, and C are inter-related, the pausing of A will lead to the pausing of B and C, the pausing of B will lead to the pausing of A and C, and the pausing of C will lead to the pausing of A and B). In another embodiment, the association can be hierarchical (e.g., A, B and C are inter-related, the pausing of A affects B and C, the pausing of B, affects only C, and the pausing of A affects only A, etc.).

[0421] According to some embodiments, the pausing of an AIML related action affects all components of the AIML related action. For example, if the AIML related action was performing some action based on predicted measurements (e.g., send a measurement report when the predictedmeasurements fulfill a certain threshold), the WTRU (e.g., UE) pauses even the performing of the measurement prediction during the prohibition duration.

[0422] According to some embodiments, the pausing of an AIML related action affects (e.g., only) the last (i.e., action) component of the AIML related action. For example, if the AIML related action was performing some action based on predicted measurements (e.g., send a measurement report when the predicted measurements fulfill a certain threshold), the WTRU (e.g., UE) may keep performing of the measurement prediction, but it may not perform the comparison of the predicted measurements and the associated thresholds / conditions.

[0423] According to some embodiments, the prohibition duration can be divided into different sub-durations, where during one or more (e.g., each) duration, a particular component of the AIML related action may be paused / activated. For example, assume the AIML related action is the sending of measurement reports based on predictions, and the prohibit timer duration was T total. During the first T1 duration of the prohibit duration, both measurement prediction and reporting can be paused, while after T1 has elapsed, measurement prediction may be started but the predicted measurement reporting can remain paused for the remaining prohibit duration (e.g., T total - Tl).

[0424] According to some embodiments, the WTRU (e.g., UE) may keep doing the performance monitoring for one or more AIML related actions while the AIML related action may be being paused and trigger a PMA action based on that. For example, assume a predicted measurement reporting action was prohibited for Xms. During this time, the WTRU (e.g., UE) may keep on performing all the components of the AIML related action, except for sending the measurement reporting, and could keep comparing the predicted measurements with actual measurements during the prohibition period. If the WTRU (e.g., UE) detects a certain number of consecutive inaccurate predictions during the prohibition duration, it may re-start / elongate the prohibition period. The duration of this additional prohibition could be the same as the prohibition time that was applied when the AIML related action was initially paused, or it could be different. Also, the conditions for triggering further prohibition while the AIML related action may be paused (e.g., the number of consecutive inaccurate predictions) could be different from the conditions for triggering prohibition first while the AIML related action was active / running.

[0425] According to some embodiments, the WTRU (e.g., UE) may be configured with a baseline prohibit timer duration (e.g., minimum duration, maximum duration, average duration, etc.) and the actual prohibit timer duration may be determined based on this baseline value and the level of inaccuracy detected for the AIML related action(s).

[0426] If the percentage of inaccurate AIML related actions within a given time is between pl and p2, the WTRU may apply the minimum prohibit timer duration.

[0427] If the percentage of inaccurate AIML related actions within a given time is between p2 and p3 (p3 >p2), the WTRU may apply a prohibit timer duration equal to minimum_prohibit_timer_duration * (p3-p2) / p2 (or add some offset to the minimum duration). This can be further constrained to be below the maximum prohibit duration (e.g., minimum of the determined value and the maximum prohibit duration).

[0428] If the percentage of inaccurate AIML related actions within a given time is above p3, the WTRU may apply the maximum prohibit timer duration.

[0429] Alternative to or in addition to the level of inaccuracy, the prediction time horizon and the confidence level of the predictions that led to the PMA can also be considered to determine the prohibit time duration. For example, if the AIML related action was using an AIML related model making predictions that have a higher confidence level and still several inaccurate decisions were made, the prohibit timer duration can be made to be longer or shorter than the case where the model being used has a lower confidence level. Similarly, models with a longer prediction time horizon could lead to a longer prohibit duration as compared to those with shorter prediction timer horizons, or vice versa.

[0430] According to some embodiments, when a prohibit timer is started due to the fulfillment of the conditions for the prohibition of an AIML related action(s), the WTRU (e.g., UE) may send an indication to the network (e.g., UCI, MAC CE, RRC message, etc.). The indication may include information such as the concerned AIML related action(s) (e.g., Action IDs), the duration of the prohibition, the threshold / condition that were fulfilled that triggered the prohibition, etc.

[0431] According to some embodiments, the WTRU (e.g., UE) must wait until the prohibition timer duration has elapsed before enabling / re-stating the AIML related action(s).

[0432] In another embodiment, the WTRU (e.g., UE) may enable / restart the AIML related action(s) even before the prohibition time duration has elapsed, if certain other configured condition gets fulfilled.

[0433] For example, the WTRU (e.g., UE) may have kept the monitoring of the AIML related action while the action was paused and has determined the accuracy has improved (e.g., a certain number of accurate measurement predictions were made while prediction-based measurement reporting was prohibited / paused).

[0434] For example, the WTRU (e.g., UE) may have performed other actions that change some aspects of the AIML related action (e.g., WTRU (e.g., UE) has performed a HO to another cell while the prohibit timer is running, WTRU (e.g., UE) has detected it has moved a certain distance away from the location where the prohibition has started, etc.).

[0435] The retraining of the model may be based on performance monitoring.

[0436] According to some embodiments, the PMA may be the triggering of the retraining of the model.

[0437] According to some embodiments, the WTRU (e.g., UE) may stop the AIML related action and start the retraining of the relevant AIML related model(s) by itself (e.g., collecting of data / measurements for the training)

[0438] According to some embodiments, the WTRU (e.g., UE) may send a request to the network (e.g., network node (e.g., gNB), CN, OTT server, etc.) to retrain the relevant AIML related model(s) and may receive the trained model later. The WTRU (e.g., UE) may request for the updated model, or the network may proactively send the model to the WTRU (e.g., UE) when the training is complete.

[0439] According to some embodiments, the WTRU (e.g., UE) may keep using the AIML model while the re-training is being performed at the WTRU (e.g., UE).

[0440] According to some embodiments, the WTRU (e.g., UE) may be configured to refrain from using the AIML model while the re-training is being performed at the WTRU (e.g., UE).

[0441] According to some embodiments, the WTRU (e.g., UE) may keep using the AIML model while the re-training is being performed at the network.

[0442] According to some embodiments, the WTRU (e.g., UE) may be configured to refrain from using the AIML model while the re-training is being performed at the network.

[0443] According to some embodiments, if the WTRU (e.g., UE) is retraining the model, it may send an indication to the network that retraining is started. This indication, for example, could be used by the network to initiate some additional actions that can help the retraining of the model at the WTRU (e.g., UE) (e.g., start transmitting additional reference signals such as CSLRSs, etc.).

[0444] According to some embodiments, the WTRU (e.g., UE) may have to send a request for starting the retraining by itself and starts the retraining (e.g., only) if it gets a confirmation / response from the network. The response from the network could contain additional information such as whether the WTRU (e.g., UE) can start the retraining immediately or after a certain duration or some other conditions are fulfilled (e.g., network may inform the WTRU (e.g., UE) to do the retraining (e.g., only) if the WTRU (e.g., UE) performs a HO to a certain cell / frequency, (e.g., only) if the UL / DL data rate is below a certain level, if certain cells / beams / reference signals are detected or have a signal level strength above a certain value, etc.).

[0445] Model / functionality deactivation / switching / fallback to legacy is described below.

[0446] The WTRU (e.g., UE) may have several models that can be used for a given AIML related action / functionality, each with different requirements (e.g., processing power, memory, etc.) and capabilities (e.g., prediction confidence, prediction time horizon, etc.). The different models mayalso have associated priority levels (e.g., based on the cost vs benefit of the models, which can be set by the WTRU (e.g., UE) based on implementation or configured by the network).

[0447] According to some embodiments, the PMA may be the triggering of a switching to another model for the concerned AIML related action.

[0448] According to some embodiments, the WTRU (e.g., UE) may switch to another model that may be expected to provide a better accuracy (e.g., but with some extra cost in terms of processing). The switching can be done one step up (i.e., to the next best model) or it can be left to the WTRU (e.g., UE) to choose any of the models that have a better expected accuracy.

[0449] According to some embodiments, the WTRU (e.g., UE) may switch to another model that has a longer / shorter prediction time horizon (e.g., WTRU (e.g., UE) was using a model with a longer prediction time horizon but lower confidence level and may switch to a one with a shorter time horizon but higher confidence level). The switching can be done one step up (i.e., to the model with the next longer / shorter time horizon) or it can be left to the WTRU (e.g., UE) to choose any of the models that have a longer / shorter time horizon.

[0450] According to some embodiments, the WTRU (e.g., UE) may switch to another model that has a lower / higher priority. The switching can be done one step up (i.e., to the model with the next lower / higher priority) or it can be left to the WTRU (e.g., UE) to choose any of the models that have a lower / higher priority.

[0451] According to some embodiments, the WTRU (e.g., UE) may have one model that can operate under different modes (e.g., depending on the setting of the model parameters, it can make predictions with different time horizons or / and prediction confidence levels). In these cases, the model switching embodiments described above can be accomplished by adjusting the configuration of the given model.

[0452] According to some embodiments, the model switching can be further combined with model prohibition. For example, the WTRU (e.g., UE) may be prohibited from using the first model that was being used when the PMA was triggered, switch to a second model according to any of the embodiments above, and when the prohibit timer has elapsed, switch back to the first model, etc.

[0453] According to some embodiments, the WTRU (e.g., UE) may be configured to apply model switching based on gradual degradation. For example, the WTRU (e.g., UE) may be configured to start using the model that has the longest prediction time horizon or / and lowest prediction confidence level and / or lowest cost (e.g., processing / memory requirements) and / or higher priority. If a PMA is triggered while using this model (e.g., model was determined to be not accurate enough according to the PMA triggering conditions such as consecutive inaccuratedecisions, etc.), then it may switch to another model (e.g., a shorter time horizon / better confidence level / lower priority / more costly, etc.) and so on, until the most expensive / higher confidence level / lowest priority model is used. Even if that model is determined to be not accurate enough, the WTRU (e.g., UE) may switch to legacy (i.e., non AIML based) operation.

[0454] According to some embodiments, the switching can be done at a functionality level instead of model level. For example, if the WTRU (e.g., UE) was performing spatial beam management / prediction and a PMA was triggered (e.g., the prediction has led to a certain number of inaccurate decisions), the WTRU (e.g., UE) may switch to temporal beam management (e.g., WTRU (e.g., UE) may need to start using current measurements of the beam that is being predicted instead of trying to predict it based on other beams). The WTRU (e.g., UE) may have several models for spatial based beam management and temporal beam management, and it may be left to WTRU (e.g., UE) implementation to use any of the models from the temporal ones when switching, or it can use any of the embodiments discussed above to determine the model (e.g., choose the highest priority first, choose the one with the shortest / longest prediction time horizon, choose the one with the lowest / highest confidence level, etc.).

[0455] According to some embodiments, the WTRU (e.g., UE) may inform the network about the switching (e.g., indicating the identity of the model / functionality being switched to, reason for switching, etc.).

[0456] According to some embodiments, the WTRU (e.g., UE) may perform the model switching (e.g., only) if the network approves it (e.g., send a request for model switching indicating the identity of the model, reason for switching, etc.).

[0457] It should be noted that the performance monitoring embodiments discussed above are applicable to any AIML based function / model / operation. The mobility related AIML actions used in the description are just used as examples and as such do not limit the embodiment scope to AIML related / based actions / functions / models that are not related mobility.

[0458] FIG. 7 is a flowchart illustrating a representative method 700 implemented by a WTRU 102. Referring to FIG. 7, the representative method 700 may include, at block 710, receiving, from a network node, configuration information indicating a plurality of candidate / serving cells and triggering conditions, based on predicted and current measurements, for triggering a random access procedure towards a candidate cell. At block 720, the representative method 700 may include performing current measurements of the plurality of candidate / serving cells and measurement prediction of the plurality of candidate / serving cells. At block 730, the representative method 700 may include performing a random access procedure to a target cell, wherein the target cell is a candidate cell among the plurality of the candidate / serving cells, on condition that thetriggering conditions are satisfied by the current and predicted measurements of the target cell and the serving cell.

[0459] According to certain embodiments, the representative method 700 may further comprise: receiving, from the network node, information indicating a timing advance value.

[0460] According to certain embodiments, the representative method 700 may further comprise: sending, to a source cell, a request to perform the random access procedure to the target cell.

[0461] According to certain embodiments, the representative method 700 may further comprise: sending, to a source cell, information indicating the measurement prediction of the target cell and the source cell.

[0462] According to certain embodiments, the representative method 700 may further comprise: determining a level of confidence associated with the measurement prediction of the plurality of candidate / serving cells.

[0463] According to certain embodiments, the representative method 700 may further comprise: performing a random access procedure to a target cell may be based on the level of confidence associated with the measurement prediction.

[0464] According to certain embodiments, the measurement prediction of the plurality of candidate / serving cells uses artificial intelligence / machine learning.

[0465] FIG. 8 is a flowchart illustrating a representative method 800 implemented by a WTRU 102. Referring to FIG. 8, the representative method 800 may include, at block 810, receiving, from a network node, configuration information indicating any of: (1) a plurality of candidate / serving cells and associated configured grants on the candidate cells, (2) handover trigger conditions and (3) at least a grant activation trigger condition associated to one or more (e.g., each) candidate cell of the plurality of candidate cells, wherein the at least grant activation trigger condition may be based on current and predicted measurements of the candidate cell and serving cell. At block 820, the representative method 800 may include performing current measurements of the plurality of candidate / serving cells and measurement prediction of the plurality of candidate / serving cells. At block 830, the representative method 800 may include performing a handover procedure to a target cell, wherein the target cell may be a candidate / serving cells of the plurality of candidate / serving cells, on condition that the grant activation trigger condition is satisfied by the measurement prediction of the target cell, and on condition that the handover trigger condition is satisfied.

[0466] According to certain embodiments, the representative method 800 may further comprise: receiving an indication from the network the requested configured grant cannot be activated.

[0467] According to certain embodiments, the representative method 800 may further comprise: determining an occasion wherein the activated configured grant has elapsed.

[0468] According to certain embodiments, the representative method 800 may further comprise: performing a random access procedure to the target cell upon performing the handover.

[0469] According to certain embodiments, the representative method 800 may further comprise: determining a level of confidence associated with the measurement prediction of the plurality of candidate / serving cells.

[0470] According to certain embodiments, the requesting of the activation of the configured grant on a target cell may be based on the level of confidence associated with the measurement prediction of the target / serving cell.

[0471] According to certain embodiments, the representative method 800 may further comprise: performing a handover to a target cell may be based on the level of confidence associated with the measurement prediction of the target cell / serving cell.

[0472] According to certain embodiments, the associated configured grants are type 2 configured grants.

[0473] According to certain embodiments, the measurement prediction of the plurality of candidate / serving cells uses artificial intelligence / machine learning.

[0474] FIG. 9 is a flowchart illustrating a representative method 900 implemented by a WTRU 102. Referring to FIG. 9, the representative method 900 may include, at block 910 receiving configuration information for determining an accuracy of prediction-based action and at least a condition for triggering a performance monitoring action, wherein the performance monitoring action may be any of: (1) prohibition of the performing of the prediction-based action for a certain time duration, (2) stop performing the prediction-based action, (3) triggering a retraining of the model used for prediction, (4) switching to a more accurate / most costly prediction model, and (5) sending performance monitoring report. At block 920, the representative method 900 may include determining the accuracy of a prediction-based action based on the configuration information. At block 930, the representative method 900 may monitoring the triggering condition for performance monitoring action based on the determined accuracy of a prediction-based action. At block 940, the representative method 900 may include performing the performance monitoring action, on condition that the triggering condition is satisfied.

[0475] According to certain embodiments, the representative method 900 may further comprise: updating parameters that affect the performance monitoring action based on the fulfilled triggering conditions.

[0476] According to certain embodiments, the configuration information may indicate metrics to be used for doing the performance monitoring.

[0477] According to certain embodiments, the configuration information may indicate thresholds / conditions for triggering performance monitoring related actions.

[0478] According to certain embodiments, the configuration information may indicate performance monitoring action to be applied when the triggering conditions are fulfilled.

[0479] FIG. 10 is a flowchart illustrating a representative method 1000 implemented by a WTRU 102. Referring to FIG. 10, the representative method 1000 may include, at block 1010 receiving, from a network node, configuration information indicating a plurality of candidate and serving cells and triggering conditions for triggering a random access procedure towards a candidate cell, wherein the triggering conditions are at least based on predicted measurements and / or current measurements.

[0480] At block 1020, the representative method 1000 may include performing current measurements of the plurality of candidate and serving cells and measurement prediction of the plurality of candidate and serving cells;

[0481] At block 1030, the representative method 1000 may include determining a level of confidence associated with the measurement prediction of the plurality of candidate and serving cells.

[0482] At block 1040, the representative method 1000 may include performing a random access procedure to a target cell, based on the level of confidence associated with the measurement prediction, on condition that the triggering conditions are satisfied by the current and predicted measurements of the target cell and the serving cell, and wherein the target cell is a candidate cell among the plurality of the candidate and serving cells.

[0483] According to certain embodiments, the representative method 1000 may further comprise: receiving, from the network node, information indicating a timing advance value.

[0484] According to certain embodiments, the representative method 1000 may further comprise: sending, to a source cell, a request to perform the random access procedure to the target cell.

[0485] According to certain embodiments, the representative method 1000 may further comprise: sending, to a source cell, information indicating the measurement prediction of the target cell and of the source cell.

[0486] According to certain embodiments, the measurement prediction of the plurality of candidate and serving cells is based on an artificial intelligence / machine learning model.

[0487] According to certain embodiments, performing a random access procedure to a target cell is based on a prediction of time horizon of the measurement prediction.

[0488] According to certain embodiments, the configuration information further comprises: one or more random access parameters associated with any of the level of confidence and the prediction of time horizon.

[0489] According to certain embodiments, the representative method 1000 may further comprise: the random access procedure according to the one or more random access parameters associated with any of: the level of confidence and the prediction of time horizon.

[0490] According to certain embodiments, the one or more random access parameters indicate any of: (1) one or more random access preambles, (2) one or more random access power ramping levels, and (3) one or more numbers of random access preamble transmission.

[0491] Conclusion

[0492] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0493] The foregoing embodiments are discussed, for simplicity, with regard to the terminology and structure of infrared capable devices, i.e., infrared emitters and receivers. However, the embodiments discussed are not limited to these systems but may be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0494] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, single image and / or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "WTRU (e.g., UE)", the term "remote" and / or the terms "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU);(ii) any of a number of embodiments of a WTRU; (iii) a wireless-capable and / or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU; (iii) a wireless-capable and / or wired-capable device configured with less than all structures and functionality of a WTRU; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to FIGs. 1 A-1D. As another example, various disclosed embodiments herein supra and infra are described as utilizing a head mounted display. Those skilled in the art will recognize that a device other than the head mounted display may be utilized and some or all of the disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other device may include a drone or other device configured to stream information for providing the adapted reality experience.

[0495] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, WTRU (e.g., UE), terminal, base station, RNC, or any host computer.

[0496] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0497] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0498] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0499] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

[0500] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0501] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost versus efficiency tradeoffs. There may be various vehicles by which processes and / or systems and / or other technologies described herein may be effected (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary with the context in which the processes and / or systems and / or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and / or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and / or firmware.

[0502] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such blockdiagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, or examples may be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and / or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0503] Those skilled in the art will recognize that it is common within the art to describe devices and / or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizingany suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0504] The herein described subject matter sometimes illustrates different components included within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0505] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0506] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and / or the descriptions herein may include usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim including such introduced claim recitation to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an"(e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of' followed by a listing of a plurality of items and / or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of the items and / or the categories of items, individually or in conjunction with other items and / or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. And the term "multiple", as used herein, is intended to be synonymous with "a plurality".

[0507] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0508] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may bereadily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

[0509] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §112, 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

Claims

CLAIMSWhat is claimed is:

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving, from a network node, configuration information indicating a plurality of candidate and serving cells and triggering conditions for triggering a random access procedure towards a candidate cell, wherein the triggering conditions are at least based on predicted measurements and current measurements; performing current measurements of the plurality of candidate and serving cells and measurement prediction of the plurality of candidate and serving cells; determining a level of confidence associated with the measurement prediction of the plurality of candidate and serving cells; and performing a random access procedure to a target cell, based on the level of confidence associated with the measurement prediction, on condition that the triggering conditions are satisfied by the current and predicted measurements of the target cell and the serving cell, and wherein the target cell is a candidate cell among the plurality of the candidate and serving cells.

2. The method according to claim 1, further comprising: receiving, from the network node, information indicating a timing advance value.

3. The method according to any of claims 1-2, further comprising sending, to a source cell, a request to perform the random access procedure to the target cell.

4. The method according to any of claims 1-3, further comprising sending, to a source cell, information indicating the measurement prediction of the target cell and of the source cell.

5. The method according to any of claims 1-4, wherein the measurement prediction of the plurality of candidate and serving cells is based on an artificial intelligence / machine learning model.

6. The method according to any of claims 1-5, wherein performing a random access procedure to a target cell is based on a prediction of time horizon of the measurement prediction.

7. The method according to claim 6, wherein the configuration information further comprises one or more random access parameters associated with any of: the level of confidence and the prediction of time horizon.

8. The method according to claim 7, further comprising performing the random access procedure according to the one or more random access parameters associated with any of: the level of confidence and the prediction of time horizon.

9. The method according to claim 8, wherein the one or more random access parameters indicate any of: (1) one or more random access preambles, (2) one or more random access power ramping levels, and (3) one or more numbers of random access preamble transmission.

10. A wireless transmit / receive unit (WTRU) comprising circuitry, including a transmitter, a receiver, a processor and memory, the WTRU configured to: receive, from a network node, configuration information indicating a plurality of candidate and serving cells and triggering conditions for triggering a random access procedure towards a candidate cell, wherein the triggering conditions are at least based on predicted measurements and current measurements; perform current measurements of the plurality of candidate and serving cells and measurement prediction of the plurality of candidate and serving cells; determine a level of confidence associated with the measurement prediction of the plurality of candidate and serving cells; and perform a random access procedure to a target cell, based on the level of confidence associated with the measurement prediction, on condition that the triggering conditions are satisfied by the current and predicted measurements of the target cell and the serving cell, and wherein the target cell is a candidate cell among the plurality of the candidate and serving cells.

11. The WTRU according to claim 10, further configured to: receive, from the network node, information indicating a timing advance value.

12. The WTRU according to any of claims 10-11, further configured to: send, to a source cell, a request to perform the random access procedure to the target cell.

13. The WTRU according to any of claims 10-12, further configured to: send, to a source cell, information indicating the measurement prediction of the target cell and of the source cell.

14. The WTRU according to any of claims 10-13, wherein the measurement prediction of the plurality of candidate and serving cells is based on an artificial intelligence / machine learning model.

15. The WTRU according to any of claims 10-14, wherein the WTRU is configured to perform a random access procedure to a target cell based on a prediction of time horizon of the measurement prediction.

16. The WTRU according to claim 15, wherein the configuration information further comprises one or more random access parameters associated with any of: the level of confidence and the prediction of time horizon.

17. The WTRU according to claim 16, further configured to: perform the random access procedure according to the one or more random access parameters associated with any of: the level of confidence and the prediction of time horizon.

18. The WTRU according to claim 17, wherein the one or more random access parameters indicate any of: (1) one or more random access preambles, (2) one or more random access power ramping levels, and (3) one or more numbers of random access preamble transmission.

Images