Method and apparatus for predicting uplink cache state in wireless communication

Abstract

A wireless transmit / receive unit (WTRU) may receive configuration information associated with reporting predicted uplink (UL) cache state information from a network. The configuration information may include trigger condition (s). In an example, the trigger condition (s) may include a predicted or current UL cache data threshold, a predicted or current radio signal level threshold, or display information from the network. The configuration information may include a first indication indicating whether to explicitly or implicitly report the predicted UL cache state information. The WTRU may determine at least one of: a current or predicted radio signal level of the cell, a current or predicted UL cache data level, or an explicit indication from the network. The WTRU may monitor trigger condition (s). Based on the trigger condition (s) being satisfied, the WTRU may send a second indication to the network.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 531,166, filed August 7, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth-generation mobile radio access technology (RAT) can be referred to as 5G New Radio (NR). Previous-generation (legacy) mobile communication RATs could be, for example, fourth-generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] The systems, methods, apparatus, and means described herein relate to the enhancement of predictive traffic and radio conditions in wireless systems.

[0004] A Wireless Transmit / Receive Unit (WTRU) can receive configuration information from the network associated with reported predicted uplink (UL) cache state information. In an example, the configuration information can be received via a Radio Resource Control (RRC) reconfiguration message. The configuration information may include at least one trigger condition associated with reporting the predicted UL cache state information. In an example, at least one trigger condition may include a predicted or current UL cache data threshold (e.g., cache values ​​of one or more bearers or subsets of bears associated with the predicted or current UL cache data threshold, cache values ​​of application identifiers (IDs) or subsets of application IDs associated with the predicted or current UL cache data threshold), a predicted or current radio signal level threshold, or explicit information from the network. Explicit information from the network may be a Physical Downlink Control Channel (PDCCH) command instructing the initiation of UL synchronization with neighboring cells, or instructing the transmission of Channel State Information (CSI) reports associated with neighboring cells. The configuration information may include a first indication indicating whether the predicted UL cache state information is reported explicitly or implicitly.

[0005] The WTRU can determine at least one of the following: the current or predicted radio signal level of the cell, the current or predicted UL cache data level, or an explicit indication from the network. The WTRU can monitor at least one trigger condition. Based on the satisfaction of at least one trigger condition, the WTRU can send a second indication to the network. In the example, the WTRU can send a second indication to the network based on the current or predicted UL cache data level meeting a current or predicted UL cache data threshold (e.g., based on one or more predicted cache values ​​associated with a bearer or a subset of bearers(s) or one or more predicted cache values ​​associated with an application ID or a subset of application IDs(s). In the example, the WTRU can send a second indication to the network based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold. In the example, the WTRU can send a second indication to the network based on an explicit indication from the network.

[0006] If the second indication is explicit, the predicted UL cache state information can be indicated using a measurement report. If the second indication is explicit, the predicted UL cache state information can be sent to the source network node. If the second indication is implicit, the predicted UL cache state information can be indicated via UL synchronization, which includes a Random Access Channel (RACH) preamble for different predicted UL cache levels. If the second indication is implicit, the predicted UL cache state information can be sent to the target network node. Attached Figure Description

[0007] A more detailed understanding can be obtained from the following detailed description, given by way of example in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are illustrative. Therefore, the figures and the detailed description should not be considered limiting, and other equally valid examples are possible and appropriate. Furthermore, in the figures, similar reference numerals (“ref.”) indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0008] Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0009] Figure 1C The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0010] Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The illustrated system diagram shows another example RAN and another example CN used in the communication system.

[0011] Figure 2 An example of a measurement model is illustrated.

[0012] Figure 3 The illustration shows an example of inter-cell L1 / 2 triggered mobility (LTM) using carrier aggregation (CA).

[0013] Figure 4 The diagram illustrates an example of the current LTM signaling process.

[0014] Figure 5 An example of the updated LTM baseline process is illustrated.

[0015] Figure 6 The illustration shows an example of time series prediction of the reference power of the reference signal (RSRP). Detailed Implementation

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

[0017] The methods, processes, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Regarding Figures 1A-1D This document provides a summary of various types of wireless devices and infrastructures, in which various elements of the network can utilize, perform, arrange and / or adapt and / or configure the methods, apparatuses and systems provided herein.

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

[0019] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it 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, any of WTRU 102a, 102b, 102c, and 102d may be referred to as a “station” and / or “STA”, may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable device, head-mounted display (HMD), vehicle, drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and so on. Any of WTRU 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0020] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or other networks 112. By way of example, base stations 114a and 114b may be a basic transceiver station (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR NodeB, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

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

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

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

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

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

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

[0032] Figure 1B The following diagram illustrates the system of example WTRU 102. Figure 1BAs shown, among other things, 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 supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

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

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

[0036] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0055] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can be divided into two streams by a segmented parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

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

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

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

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

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

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

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

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

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

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

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

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

[0069] Given Figures 1A-1D as well as Figures 1A-1D The functions described herein with respect to one or more of the following items can be performed by one or more emulation devices (not shown): WTRU 102a-102d, base station 114a-114b, eNode-B 160a-160c, MME 162, SGW164, PGW 166, gNB 180a-180c, AMF182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0072] The timer mentioned in this article can refer to a fixed time or a fixed period of time. The timer expiration mentioned in this article can refer to the arrival of a fixed time or the expiration of a fixed period of time. The timer mentioned in this article can refer to time, period of time, tracking time, tracking period, etc.

[0073] The systems, methods, apparatus, and means described herein relate to the enhancement of predictive traffic and radio conditions in wireless systems.

[0074] A Wireless Transmit / Receive Unit (WTRU) can receive configuration information from the network associated with reported predicted uplink (UL) cache state information. In an example, the configuration information can be received via a Radio Resource Control (RRC) reconfiguration message. The configuration information may include at least one trigger condition associated with reporting the predicted UL cache state information. In an example, at least one trigger condition may include a predicted or current UL cache data threshold (e.g., cache values ​​of one or more bearers or subsets of bears associated with the predicted or current UL cache data threshold, cache values ​​of application identifiers (IDs) or subsets of application IDs associated with the predicted or current UL cache data threshold), a predicted or current radio signal level threshold, or explicit information from the network. Explicit information from the network may be a Physical Downlink Control Channel (PDCCH) command instructing the initiation of UL synchronization with neighboring cells, or instructing the transmission of Channel State Information (CSI) reports associated with neighboring cells. The configuration information may include a first indication indicating whether the predicted UL cache state information is reported explicitly or implicitly.

[0075] The WTRU can determine at least one of the following: the current or predicted radio signal level of the cell, the current or predicted UL cache data level, or an explicit indication from the network. The WTRU can monitor at least one trigger condition. Based on the satisfaction of at least one trigger condition, the WTRU can send a second indication to the network. In the example, the WTRU can send a second indication to the network based on the current or predicted UL cache data level meeting a current or predicted UL cache data threshold (e.g., based on one or more predicted cache values ​​associated with a bearer or a subset of bearers(s) or one or more predicted cache values ​​associated with an application ID or a subset of application IDs(s). In the example, the WTRU can send a second indication to the network based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold. In the example, the WTRU can send a second indication to the network based on an explicit indication from the network.

[0076] If the second indication is explicit, the predicted UL cache state information can be indicated using a measurement report. If the second indication is explicit, the predicted UL cache state information can be sent to the source network node. If the second indication is implicit, the predicted UL cache state information can be indicated via UL synchronization, which includes a Random Access Channel (RACH) preamble for different predicted UL cache levels. If the second indication is implicit, the predicted UL cache state information can be sent to the target network node.

[0077] The WTRU can be configured with one or more trigger conditions (e.g., one or more predicted / current radio conditions, predicted / current buffer levels, explicit indications from the network for performing neighbor cell preparation (such as UL synchronization),) to send an indication to the network regarding the predicted UL buffer level. The WTRU can monitor the trigger conditions. If the trigger conditions are met, the WTRU can send an indication to the network, indicating (e.g., explicitly or implicitly) one or more current / predicted buffer status reports (BSRs). The WTRU can be configured with one or more trigger conditions (e.g., one or more predicted / current radio conditions, predicted / current buffer levels, etc.) to initiate actions (e.g., UL synchronization with neighboring cells, Channel State Information (CSI) / Channel Quality Indicator (CQI) reports from neighboring cells, evaluation of conditional reconfiguration criteria, etc.). The WTRU can monitor one or more trigger conditions. If one or more trigger conditions are met, the WTRU can initiate the corresponding action. The WTRU can be configured with one or more conditions for delaying handover (HO) (e.g., a time window from receiving an HO command or satisfying one or more Conditional Handover (CHO) conditions, current / predicted UL buffer level, current / predicted signal level of the source / target cell, etc.). If (e.g., as long as) the conditions for delaying HO are met, the WTRU can delay HO and transmit data via the source. If the conditions are not met (e.g., when the conditions are no longer met), the WTRU can perform HO and transmit data via the target. The WTRU can determine the optimal target cell based on the current UL buffer and the grant at targets.

[0078] This article provides an example describing the measurement process in the Radio Access Network (RAN) and the mobility process in RAN2, referred to as L1 / L2 triggered mobility (LTM).

[0079] Figure 2 An example of a measurement model is illustrated. In RRC_CONNECTED, the WTRU can measure multiple beams (e.g., at least one) of a cell. The measurement results (e.g., power values) can be averaged to derive cell quality. The WTRU can be configured to consider a subset of the detected beams. Filtering can be performed at two different levels: at the physical layer to derive beam quality, and (e.g., and then) at the RRC level to derive cell quality from multiple beams. For serving cells(one or more) and non-serving cells(one or more), cell quality from beam measurements can be derived in the same manner. If the WTRU is configured as such by the gNB, the measurement report can include measurement results for X best beams.

[0080] Figure 3 The illustration shows an example of inter-cell L1 / 2 triggered mobility (LTM) using carrier aggregation (CA). Figure 3 In this context, candidate cell groups can be configured by RRC, and L1 / 2 signaling can be used to achieve dynamic handover between PCell and SCell.

[0081] Examples of inter-cell beam management can be used, which can manage beams in CA scenarios, but may not support cell changes / additions. This paper provides examples of mechanisms and procedures for specifying L1 / L2-based inter-cell mobility to reduce mobility latency.

[0082] To specify mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency, the configuration and maintenance of multiple candidate cells can allow for the rapid application of candidate cell configurations (e.g., RAN2, RAN1). To specify mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency, dynamic handover mechanisms between candidate serving cells (e.g., including SpCell and SCell) with potential applicability based on L1 / L2 signaling (e.g., RAN2, RAN1) can be provided. To specify mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency, L1 enhancements (including L1 measurement and reporting) and beam indications (e.g., RAN1, RAN2) for inter-cell beam management can be provided (e.g., early RAN2 involvement may be necessary, including further clarification of the possibility of interaction between the bullet and the previous bullet). To specify mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency, examples of timed advance management (e.g., RAN1, RAN2) can be provided. To specify the mechanisms and procedures for reducing mobility latency based on L1 / L2 inter-cell mobility, central unit distributed cell (CU-DU) interface signaling that supports L1 / L2 mobility (e.g., RAN3 if needed) can be provided.

[0083] The L1 / L2-based inter-cell mobility process can be applied to one or more of the following scenarios: independent, CA, and dual connectivity (DC) cases with serving cell changes within a cell group (CG); intra-DU and intra-CU / inter-DU cases (e.g., applicable to independent and CA: no new RAN interface expected); both intra-frequency and inter-frequency cases; both FR1 and FR2 cases; source and target cells that may be synchronized or unsynchronized; or whether inter-CU cases are excluded.

[0084] L1 / L2-based mobility and inter-cell beam management can address intra-DU and intra-frequency scenarios. The serving cell can remain unchanged (e.g., it's impossible to change the serving cell using L1 / 2-based mobility). In FR2 deployments, CA can be used to utilize available bandwidth (e.g., aggregating multiple CCs in one band). These component carriers (CCs) can be transmitted using the same analog beam pairs (e.g., gNB beams and WTRU beams). The WTRU can be configured with Transmission Configuration Indicator (TCI) states (e.g., a considerable number, such as 64) for receiving the Physical Downlink Control Channel (PDCCH) and Physical Data Sharing Channel (PDSCH). Each TCI state (e.g., each TCI state) can include a Reference Signal (RS) or Synchronization Signal Block (SSB) that the WTRU references to set its beam. The SSB can be associated with a non-serving Physical Cell ID (PCI). Medium Access Control (MAC) signaling (WTRU-specific PDCCH MAC CE TCI state indication) can activate the TCI state of the CORESET / PDCCH. A MAC CE indicating the TCI state associated with a non-serving PCI can support PDCCH reception from a non-serving cell. MAC signaling (TCI state activation / deactivation for WTRU-specific PDSCH) can activate a subset of up to eight TCI states for PDSCH reception. Downlink control information (DCI) can indicate which of the eight TCI states. A unified TCI state can (e.g., may also) be supported by different update mechanisms (e.g., DCI-based), but without multiple transmit / receive points (multiple TRPs). A unified TCI state with multiple TRPs can (e.g., may also) be supported.

[0085] LTM can improve handover latency. For regular L3 handover or conditional handover, the WTRU typically first sends a measurement report using RRC signaling. In response to the measurement report, the network can provide further measurement configurations and potential conditional handover configurations. For regular handover, the network can provide the target cell configuration (e.g., after the WTRU reports using RRC signaling that the cell meets the configured radio quality criteria). For conditional handover, to reduce the handover failure rate due to delays in sending measurement reports and then receiving RRC reconfigurations from the network, the target cell configuration and measurement criteria (e.g., which can determine whether the WTRU should trigger a CHO configuration) can be provided (e.g., in advance). Both regular and conditional L3 handover examples may involve a certain amount of latency due to sending measurement reports and receiving target configurations (e.g., especially in the case of regular (unconditional) handover).

[0086] LTM allows for the rapid application of configurations to candidate cells, including dynamic handovers between SCells and PCells (e.g., switching roles between SCells and PCells), without the need for RRC signaling. Inter-CU handovers may not be included, as this could require repositioning the Packet Data Convergence Protocol (PDCP) anchor. At least an RRC-based approach can be provided to support inter-CU handovers. Using the legacy L3 handover mechanism, any currently active(one or more) SCells may be released before the WTRU completes the handover to the target cell in the coverage area of ​​the new site. After a successful handover, the currently active(one or more) SCells may (e.g., may only) be added back, potentially leading to throughput degradation during handover. L1 / 2 allows CA operations to be enabled immediately when the serving cell changes.

[0087] Figure 4 The diagram illustrates an example of the current LTM signaling process. Figure 5 An example of an updated LTM baseline procedure (e.g., RAN2) is illustrated. The procedure can use resources from L1 and L2 to perform mobility procedures and is named L1 / L2 triggered mobility (LTM). Figure 4 The updated LTM process is described in this document. The updated LTM process can provide enhancements to relevant information from the baseline mechanism. The updated process operates by activating mobility via L2 signaling, i.e., via the MAC control element (CE). The WTRU can be configured with a set of target cells using L3 signaling (e.g., LTM preparation) and can (e.g., then can) perform HO based on L2 MAC CE signaling (e.g., LTM execution), which can be faster than the L3 legacy mobility. A synchronization phase (e.g., not shown herein) may exist between the preparation and execution phases.

[0088] like Figure 5As shown, the updated LTM process is as follows: At point 1, the WTRU can send a MeasurementReport message to the gNB. The gNB can decide to use LTM and initiate LTM candidate preparation. At point 2, the gNB can transmit an RRCReconfiguration message to the WTRU, which includes the configuration of one or more LTM candidate target cells. At point 3, the WTRU can store the configuration of one or more LTM candidate target cells and transmit an RRCReconfigurationComplete message to the gNB. At point 4, before receiving an LTM cell handover command, the WTRU can perform downlink (DL) synchronization and TA acquisition with one or more candidate target cells. DL synchronization of one or more candidate cells before a cell handover command can be supported (e.g., at least based on SSB). It can support the acquisition of TAs for one or more candidate cells (e.g., at least RACH based on PDCCH commands, where PDCCH commands can only be triggered by the source cell) before an LTM cell handover command. At point 5, the WTRU can perform L1 measurements on the configured LTM candidate target cells (one or more) and can transmit lower-layer measurement reports to the gNB (e.g., whether the lower-layer measurement reports are carried on L1 or MAC). At point 6, the gNB can decide to perform an LTM cell handover to the target cell and can transmit the MAC CE that triggers the LTM cell handover by including the candidate configuration index of the target cell. The WTRU can switch to the configuration of the LTM candidate target cell. At point 7, the WTRU can perform a random access procedure toward the target cell (e.g., if the TA is unavailable). At point 8, the WTRU can indicate the successful completion of the LTM cell handover toward the target cell (e.g., whether uplink signals or messages after the WTRU has switched to the target cell can be used to indicate the successful completion of the LTM cell handover).

[0089] This article provides an example of Conditional Handover (CHO). When a user is moving (e.g., if a handover between cells fails, or if a connection fails even before the handover (HO) is triggered), a CHO can reduce the number of failures. In a CHO (e.g., instead of preparing a target cell as in the legacy HO scenario), the network can prepare multiple candidate target cells in advance. This allows HO commands to be sent to the WTRU earlier than usual, while radio conditions are still good (e.g., instead of when conditions begin to degrade as in the legacy HO).

[0090] If a CHO command is received, the WTRU may store the command (e.g., instead of applying it immediately). If the conditions configured in the WTRU are met for one of the configured candidate target cells, the WTRU may (e.g., may only) apply the stored command. The WTRU may execute (e.g., and then may execute) the HO and connect to the target cell, as in a legacy HO.

[0091] In the context of Mobility Robustness Optimization (MRO), CHO and Dual Access Protocol Stack (DAPS) can be applied to attempt to reduce the number of failed HOs (e.g., primarily for WTRUs in mobility). CHO may aim for this, while DAPS may target consecutive Tx / Rx in the source cell (e.g., even after an HO has been decided but not yet completed, attempting to reduce HO outage time in URLLC).

[0092] In the CHO, the RAN can specify the conditions that the WTRU should monitor. This could be an event CondEvent_A3 (current cell measurement below threshold #1) or CondEvent_A5 (current cell measurement below threshold #1 and candidate target cell measurement above threshold #2). The WTRU may also be able to monitor (e.g., also monitor) whether conditions from other cells besides those notified by the RAN are better; and whether radio conditions are good enough and provide sufficient stability among other cells in the list provided by the RAN, but with lower priority.

[0093] The characteristics of DAPS HO (Direct Access Request) may include: continuing transmission in the source cell after receiving an HO request; simultaneously receiving user data from both the source and target cells; and uplink transmission of user data switched to the target cell during the random access procedure at the target cell. To enable downlink user data transmission from both the source and target cells, the network can forward duplicate user data between the source and target cells. Simultaneously receiving user plane (UP) data from both the source and target cells on the WTRU can be a significant burden on RAN elements (e.g., the gNB). Effective strategies for data forwarding can be challenging, given that (e.g., in many cases) the next target cell for the WTRU during mobility may be difficult to predict.

[0094] This document provides an example of a Buffered Status Report (BSR). The BSR procedure can be used to provide the serving gNB with information about the amount of UL data in a MAC entity. The RRC can be configured with one or more of the following parameters to control the BSR: periodicBSR-Timer; retxBSR-Timer; logicalChannelSR-DelayTimerApplied; logicalChannelSR-DelayTimer; logicalChannelSR-Mask; logicalChannelGroup; logicalChannelGroupIAB-Ext; or sdt-LogicalChannelSR-DelayTimer. Logical channels (e.g., each logical channel) can be assigned to logical channel groups (LCGs) using logicalChannelGroup. The maximum number of LCGs can be 8, except for IAB-MTs configured with logicalChannelGroupIAB-Ext, whose maximum number of LCGs can be 256. The MAC entity can determine the amount of UL data available for a logical channel based on the data volume calculation procedure.

[0095] The cache status report has several triggering mechanisms. The content of these reports is described below. Fields in BSR MAC CE can be defined as LCG ID, LCGi, and cache size.

[0096] For LCG ID, the Logical Channel Group ID field can identify the packet of one or more logical channels whose buffer status is being reported. For short BSR and short truncated BSR formats, the field length can be 3 bits. For extended short BSR and extended short truncated BSR formats, the field length can be 8 bits.

[0097] For LCGi, for the long BSR format, extended long BSR format, preemptive BSR format, and extended preemptive BSR format, this field indicates the presence of the buffer size field for logical channel group i. An LCGi field set to 1 indicates that the buffer size field for logical channel group i has been reported. An LCGi field set to 0 indicates that the buffer size field for logical channel group i has not been reported. For the long truncated BSR format and extended long truncated BSR format, this field indicates whether logical channel group i has available data. An LCGi field set to 1 indicates that logical channel group i has available data. An LCGi field set to 0 indicates that logical channel group i does not have available data.

[0098] For buffer size, after the MAC Packet Data Unit (PDU) has been established (e.g., after the logical channel prioritization process, which can reduce the value of the buffer size field to zero), the buffer size field identifies the total amount of available data based on the data volume calculation process across logical channels (e.g., all logical channels) of the logical channel group. The data volume can be indicated in bytes. The size of the Radio Link Control (RLC) header and MAC subheader can be disregarded in the buffer size calculation. For short BSR and short truncated BSR formats, the field length can be 5 bits. For extended short BSR and extended short truncated BSR formats, the field length can be 8 bits. For long BSR, long truncated BSR, extended long BSR, and extended long truncated formats, the field length can be 8 bits. For long BSR, long truncated BSR, extended long BSR, and extended long truncated formats, the buffer size field can be included in ascending order based on LCGi. For long truncated BSR and extended long truncated formats, the number of included buffer size fields can be maximized without exceeding the number of padding bits. For both the preemptive BSR format and the extended preemptive BSR format, the cache size field can indicate the total amount of data expected to reach the IAB-MT of the node where the preemptive BSR / extended preemptive BSR is triggered, and may not include the amount of data currently available in the IAB-MT. The preemptive BSR format can be the same as the long BSR format. The extended preemptive BSR format can be the same as the extended long BSR format.

[0099] Legacy mobility procedures (HO, CHO, etc.) can be based on reconfiguration-related radio measurements (e.g., neighboring cells becoming better than the serving cell by a certain threshold) collected by the network from the WTRU or measured and applied to the CHO context. The network can (e.g., it may also) trigger handover based on load considerations of the serving and neighboring cells, but these aspects can be left to the network to implement. Legacy approaches can be reactive and slow to react to rapidly changing conditions at the WTRU / network. If the WTRU or network can predict data traffic and / or signal levels of the serving / neighboring cells (e.g., based on AI / ML models), the network can operate independently of reactive mechanisms. Mobility decisions can be made proactively, reducing the risk of radio link failures, handover failures, sudden / frequent overloads, and ensuring that bearer QoS requirements are met (e.g., those with stringent latency requirements). This paper provides an example of enhancing WTRU mobility mechanisms by using predictions of UL traffic and radio conditions.

[0100] Executing LTM or the LTM execution process can refer to the execution of LTM. Figure 4Any / all of the processes described herein. Specifically, for early synchronization with one or more candidate cells in DL and / or UL, performing LTM or the LTM procedure can refer to performing L1 measurements and reporting to one or more candidate cells and / or performing handover between candidate cells (e.g., performing a handover). In the example, performing LTM might mean that the WTRU moves / handovers between multiple candidate cells during the procedure.

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

[0102] One or more candidate cell groups can be configured as a single list or group of candidate cell configurations at the RRC. Grouping can occur during the early synchronization or LTM execution phase, rather than the configuration phase. This means that the candidate cell set can be viewed as a single group in relation to the RRC configuration list or group, and the cells selected for performing early synchronization, L1 measurements, and LTM execution can depend on further grouping into multiple subsets of the entire candidate cell list. The grouping itself may not be modeled using candidate configuration identifiers at the RRC, but the grouping can be performed as part of the early synchronization or LTM execution process.

[0103] If LTM candidate configurations are involved, they can be applied to any type of pre-configured cell information. For example, a WTRU can be configured with one or more conditional reconfigurations, such as conditional handover (CHO), conditional PSCell addition (CPA), or conditional PSCell change (CPC), which can be effective before and / or after a cell change, or can be effective in certain cells.

[0104] L1 measurements can include measurements of RSRP, RSRP, RSSI, etc., of cells, beams, sets of cells, or sets of beams performed by the WTRU. Such L1 measurements may be similar to L3 measurements reported in RRM, differing in filtering, reference signals for the measurement, reporting mechanisms, etc. The term "measurement" can refer to L1 measurements used for LTM. The examples in this document can (e.g., may also) be applied to RRM / L3 measurements, as well as other measurements (e.g., measurements of speed, position, altitude, flow, etc.).

[0105] The conditions experienced by the WTRU may stem from real-world measurements performed by the WTRU over time. In mobility scenarios, a moving WTRU can read the RSRP of the current serving cell and report it to the network. If the WTRU is moving towards an area near the edge of the serving cell, it may record that the RSRP value is decreasing. These values ​​can be passed to the network via measurement reports for network decision-making.

[0106] It can be assumed that the WTRU or network has a pre-trained AI / ML model capable of generating predictions of air interface measurements (RSRP, RSRQ, SINR, etc.) for serving and / or neighboring cells (e.g., any cell). Prediction is a tool that can be used to anticipate the radio conditions the WTRU will experience, rather than waiting for the WTRU to report them.

[0107] Figure 6 The illustration shows an example of time series forecasting for RSRP. In this example, starting from the moment the network forecasting is triggered, WTRU can generate several forecast outputs at a certain granularity or time span over future time spans.

[0108] Predictions can (for example, or) be made for a single point in time and can continue for several times. In some scenarios, predictions with time-series outputs may be more beneficial than single-value predictions because it can be difficult to match predictions (e.g., events configured by the network) with a single prediction point.

[0109] The granularity of the timestamp associated with a prediction can be problematic. If a WTRU or network predicts one or more future values, a timestamp can be associated with that prediction (e.g., timestamps for t+1, t+2, etc.). The granularity of this timestamp can depend on the AI / ML model used and other ML-related settings. Terms like predicted value, inferred value, and future value can refer to future predicted values ​​that may or may not have associated timestamps. If a future predicted value has an associated timestamp, the timestamp can be considered a small incremental time interval within which the predicted value is considered accurate or valid, or perfectly accurate or with some degree of confidence. In (e.g., all) WTRU network exchanges, predictions can be represented by tuples such as ["predicted value"; timestamp-increment; timestamp+increment].

[0110] The WTRU can be configured to predict future measurements based on current and / or historical measurements. In the example, the WTRU can be configured with a trained AI / ML model capable of generating predictions about the radio signal level of the radio interface. In the example, the AI / ML model at the WTRU can be implementation-based. In the example, the WTRU can obtain the AI / ML model from the network. In the example, the AI / ML model can be configured to take current and / or historical RSRP measurements as input. In the example, the AI / ML model can be configured to acquire inputs (e.g., additional inputs), such as WTRU location information, WTRU mobility, etc. In the example, the AI / ML model can be configured to produce a single-value prediction (e.g., RSRP at a future time t). In the example, the AI / ML model can be configured to predict a series of RSRP values ​​corresponding to future times t+1, t+2, etc., up to t+t_fb. The model can be trained offline or online and can be exchanged in a pre-configured manner.

[0111] For predictions made via a network or WTRU, the prediction itself may be associated with and / or represented by a confidence level or error value. The prediction itself may (e.g., it may also) be represented by the average, peak, minimum, etc., along a small time window representing the validity of the prediction.

[0112] The example here could provide increased mobility robustness and cache refresh options prior to the HO.

[0113] The gNB (e.g., in a CU / DU split architecture, where the CU resides within the CU) can use RRC signaling to configure potential LTM candidates. For example, the WTRU can use RRC reconfiguration messages to receive LTM candidate configurations, e.g., in... Figure 5 During the LTM preparation phase, as shown. For example, in Figure 5During the LTM execution phase shown, if an indication is received to perform cell handover using L1 / 2 signaling (e.g., MAC CE), the WTRU can store LTM candidate configurations for later application.

[0114] In the example, the configuration of potential LTM candidates can include candidate sets, such as a first candidate set and a second candidate set. The first candidate set may be suitable for the first path (e.g., the WTRU turns left and takes the first road). The second candidate set may be suitable for the second path (e.g., the WTRU turns right and takes the second road).

[0115] In the example, some or all candidate set information can be broadcast in system information. If an indication (e.g., RRC reconfiguration) is received in dedicated signaling, the WTRU can enable pre-configuration of these broadcast configurations, which can refer to the broadcast of one or more configurations (e.g., using an index or identifier). In the example, the configuration may include all or a subset of potential cells in a specific region (e.g., all cells belonging to the CU currently connected to the WTRU or cells within a specific geographic region). These cells may not yet have been detected or measured by the WTRU, but can be configured in advance. For example (e.g., after the initial configuration of the LTM candidate configuration), the WTRU may receive updates to the configuration to modify, add, remove, or replace any part of the LTM candidate configuration.

[0116] In the example, the WTRU can receive instructions to enable or disable some or all LTM configurations. For example, if it is predicted that using L3 (e.g., RRC measurement reporting, RRC reconfiguration, conditional reconfiguration) will better handle WTRU mobility, then LTM can then be disabled. If it is predicted that LTM will be better suited to WTRU mobility, then LTM can be enabled (e.g., previously configured and disabled LTM configurations can be re-enabled). The configuration can be based on a predictive model within the network (e.g., gNB) and determined by the network. This prediction can be based on the most likely path for the WTRU determined by it (e.g., the network predictive model).

[0117] Candidate cell configuration may include all or part of the information necessary to complete reconfiguration (e.g., handover) to a candidate cell, such as channel configuration (e.g., PRACH, DPCCH, DPSCH), CORESET, BWP, security parameters, L2 parameters (e.g., MAC, RLC, PDCP), radio bearer configuration, etc.

[0118] An LTM trigger can refer to a condition or set of conditions used to perform an LTM (e.g., a conditional switchover trigger or a measurement report trigger), which can be configured or indicated by the network to the WTRU, or estimated / determined by the WTRU.

[0119] Triggers can be based on one or more of the following: time; radio quality measurements or predicted radio quality of one or more serving or target cells; location; L3 measurement events; L1 measurement events or conditions; any predicted events; explicit indications from the network; or measured, predicted, or estimated throughput, error rate, buffer status, or QoS parameters.

[0120] Time can be an absolute or relative time measured at the WTRU, a system frame number (SFN), or a subframe number.

[0121] Radio quality measurements or predictions for one or more serving cells or target cells can refer to any cell and / or any beam or reference signal (e.g., RSRP (beam or cell), RSRQ (beam or cell), cri-RI-PMI-CQI, cri-RI-i1, cri-RI-i1-CQI, cri-RI-CQI, cri-RSRP, ssb-Index-RSRP, cri-RI-LI-PMI-CQI).

[0122] Location can be a region (e.g., defined by a reference point and radius), a coordinate range, or a distance threshold from a reference location.

[0123] L3 measurement events can be event A1 (service becomes better than the threshold), event A2 (service becomes worse than the threshold), event A3 (neighborhood becomes better than SpCell offset), event A4 (neighborhood becomes better than the threshold), event A5 (SpCell becomes worse than threshold 1 and neighborhood becomes better than threshold 2), event A6 (neighborhood becomes better than SCell offset); event B1 (RAT neighborhood becomes better than the threshold), or event B2 (PCell becomes worse than threshold 1 and RAT neighborhood becomes better than threshold 2).

[0124] L1 measurement events or conditions can be any event defined as being used to evaluate whether criteria or conditions are met using L1 beam measurements.

[0125] Any predicted event can use any measurement previously listed under the measured or predicted CSI information.

[0126] The WTRU can enable CSI reporting based on explicit indications received from the network (e.g., MAC CE). (For example, if a second MAC CE is received from the network, then the WTRU can then perform LTM cell handover.)

[0127] The trigger may include one or more conditions that allow the WTRU to perform any mobility-related action (e.g., any action related to LTM). In the example, the WTRU may perform one or more of the following processes: early TA acquisition; disabling CSI reporting; enabling or updating CSI reporting configuration; performing LTM cell handover; monitoring the PDCCH on the target cell; performing BFR or RLM on the target cell; activating or deactivating certain SCells; initiating a BSR indicating the amount of traffic data, or initiating a report indicating the amount of traffic data (e.g., another amount of traffic data).

[0128] For early TA acquisition, the WTRU can trigger a RACH to the target LTM cell. The WTRU can receive the TA value in the Random Access Response (RAR), which may come from the target cell or via the source cell. The WTRU can receive the Timed Acquisition (TA) value in the MAC CE that triggers cell handover. If no RAR / MAC CE is received, the WTRU can perform a power ramp and preamble retransmission on the target.

[0129] To disable CSI reporting, the WTRU can be permitted or required to disable CSI reporting in order to reduce reporting overhead in the uplink. CSI reporting can be reduced rather than disabled (e.g., by reducing the number of reporting cells or beams, or by reducing the reporting frequency). If the conditions are no longer met, the WTRU can resume CSI reporting.

[0130] To enable or update the CSI reporting configuration, the WTRU can be required to perform and report CSI measurements on an LTM candidate cell or a subset of LTM candidate cells during the window period.

[0131] For performing LTM cell handover, conditions or criteria can be provided to allow WTRU to trigger LTM cell handover.

[0132] For monitoring the PDCCH on the target cell, the WTRU can be configured to monitor the DCI scheduling PDSCH on the target cell or indicate one or more actions on the target cell (e.g., to initiate a cell handover process).

[0133] For performing BFR or RLM on the target cell, the WTRU can be configured to monitor beam failure detection (BFD) resources on the target cell or perform radio link monitoring (RLM) on the target cell during the window period.

[0134] WTRU can be configured with one or more specific SCells to activate or deactivate certain SCells, which can be active or inactive during the window.

[0135] For initiating a BSR or report indicating another volume of traffic data: WTRU can be configured as part of the LTM process to perform a BSR; WTRU can be configured to indicate current or predicted MAC, RLC, or PDCP data volume; or WTRU can be configured to indicate current or predicted application data volume.

[0136] WTRU can report the predicted UL cache state based on one or more trigger conditions (e.g., implicitly or explicitly).

[0137] The WTRU can receive configuration information (e.g., predicted UL cache state information) with different monitoring conditions used to trigger the predicted UL cache state. Reports can be implicit or explicit. For explicit reporting, the WTRU may not yet have commands from the network to perform a cell handover or mobility procedure. The explicit report (e.g., if so) can target the source network node before mobility. For implicit reporting, the WTRU can implicitly report the predicted cache state based on the RACH preamble used by the WTRU for UL synchronization. If this action is taken by the WTRU, then the WTRU can then direct the report to the target cell (e.g., the target network node) within the context of the mobility procedure.

[0138] Criteria that can be given to the WTRU can be combined in different ways. The WTRU may be able to report predicted cache states. If the WTRU triggers a report, this may not exclude criteria specific to the cache state that cannot be linked to other criteria (e.g., radio measurements) with options (e.g., additional options). Conditions (e.g., additional conditions) can be optional, but it is assumed that configurations (e.g., all possible configurations) can be linked. The conditions provided in this document can be associated with new, enhanced, or legacy examples. This document may also provide examples of how configurations can work.

[0139] An example of how different configurations can be applied is that the WTRU can receive configurations for different packets. For example, the WTRU can receive a first set of configurations where one or more UL caches are evaluated for different bearers, along with the radio conditions to be monitored. The WTRU can receive (e.g., simultaneously) a second set of configurations where one or more specific application IDs will be monitored, along with predictive measurement criteria for one or more cells. The evaluation of different packets is provided in the example presented herein. The WTRU can receive a set of packets that include monitoring criteria, and considers a monitoring criterion satisfied as long as any packet criterion is met. In the example, the WTRU can obtain the start time and / or effective time for each packet, which will serve as an opportunity window for the WTRU to monitor relevant conditions. This aspect can be provided to the WTRU in a form different from time (e.g., RSRP range, distance, geographic location, the amount of UL data starting from any network-indicated time or UL cache report, the amount of DL data, etc.).

[0140] For conditions related to the current radio signal levels of the serving cell and neighboring cells (e.g., current radio signal level thresholds, absolute thresholds, relative thresholds, etc.), the WTRU can be configured using existing radio measurement configurations. Existing radio measurement configurations can link reporting triggering to previously configured measurements, where the WTRU can perform measurements and their evaluations based on pre-configured MeasIDs. The WTRU can (e.g., may also) be configured with additional measurement criteria specifically for LTM purposes. These configurations (e.g., additional configurations) can (e.g., for LTM purposes) be transmitted to the WTRU prior to the mobility process (e.g., before or after receiving the LTM candidate set list). This means that the WTRU can configure different thresholds for this evaluation for both LTM purposes and for RRM measurements.

[0141] In examples where additional measurement configurations exist for LTM purposes, it can be assumed that new and specific thresholds can be given to the WTRU in different forms. These different forms could be absolute thresholds, increments of the current configuration (e.g., relative thresholds), offsets between configurations, etc. In the latter case, assuming two different measurement configuration criteria for serving cells with different RSRP thresholds, the configuration can be considered as the difference between the two RSRP thresholds.

[0142] Different radio measurements can (e.g., may also) be combined. An example of this could be criteria used to evaluate both RSRP (Radio Responsibility Parameter) and Radio Signal Quality (RSRQ) of a serving cell. If both conditions are met, then the criteria can (e.g., may only be met).

[0143] Existing measurement configurations can (e.g., may also) be associated with the current serving cell, any neighboring cells, or even any detectable cell. This allows the combination (e.g., as provided herein) to be a mixing criterion between one or more radio signals from the serving cell and other radio signals from neighboring cells.

[0144] The assessment of radio quantity may not exclude L3. WTRU can (e.g., it may also) be configured with monitoring conditions for L1 radio quantity. L1 may be more prone to fast fading and may not be used for RRM purposes (e.g., this may not exclude the possibility of cross-layer and different measurement criteria for different cell combinations).

[0145] The configuration information received by the WTRU can implicitly or explicitly instruct the WTRU to activate an inference process to predict radio signals, based on conditions related to the predicted radio signal levels of the serving cell and neighboring cells (e.g., predicted signal level thresholds, absolute thresholds, relative thresholds, etc.). The WTRU can perform the inference process any number of times. The WTRU may be able to predict any radio signal and be used for many future scenarios (e.g., the WTRU can generate multiple future data points). The inferred values ​​may belong to different cells and can be evaluated equivalently in conjunction with any other criteria received in the configuration.

[0146] The WTRU can be given different configuration options (e.g., after inferring new values). In the example, the WTRU can be configured to predict radio frequencies of one or more cells (e.g., detectable cells, serving cells, or neighboring cells). The WTRU can be given a specific time or time window for the future prediction value, and any thresholds that may be associated with that time or window. For example, the WTRU can receive a threshold for the maximum future time period of the serving cell, while also receiving (e.g., also receiving) another threshold for one or more neighboring or detectable cells. The second threshold can be associated with a different time window. A third and / or fourth threshold can be associated with different predictions and different cells.

[0147] For conditions related to the current UL cache level (e.g., the current UL cache data threshold, cache values ​​of a specific bearer or subset of bearers associated with the current UL cache data threshold, cache values ​​of a specific application ID or subset of application IDs associated with the UL cache data threshold, etc.), the UL cache value may be known first by the WTRU and, in some cases, reported to the network. The UL cache value can currently be reported based on an index from a table. The index can represent the amount of data the WTRU is to transfer in bytes in the cache. Criteria used for reporting can be given by the WTRU in various forms, such as an index, a threshold in bytes, or an incremental value in bytes from the last or any previous cache state report (e.g., in cases where the network will have to implicitly or explicitly configure the WTRU for evaluation). With regard to what is associated with the cache value, the WTRU can be configured to evaluate criteria in various ways, such as considering the cache value of a specific bearer or subset of bearers, a specific application ID or subset of application IDs, etc.

[0148] Configurations can include different combinations of options (e.g., considering all of the above), such as a threshold in bytes (e.g., for a subset of the bearers) and another threshold (e.g., for one or more application IDs). Criteria that will be evaluated by WTRU can (e.g., and then may need to) be considered together (e.g., if all the single conditions will be met simultaneously, then the criteria can be considered satisfied).

[0149] For conditions associated with the predicted UL cache level (e.g., the predicted UL cache data threshold, predicted cache values ​​of a specific bearer or subset of bears(one or more) associated with the predicted UL cache data threshold, cache values ​​of a specific application ID or subset of application IDs(one or more) associated with the predicted UL cache data threshold, etc.), the configuration relates to predictions triggered by WTRUs. Examples given for radio condition predictions can (e.g., may also) be applied to these examples. Predictions can be associated with one or more specific radio bearers, application IDs(one or more), network slices, etc.

[0150] In examples specific to WTRU inference, the WTRU can predict a value or a set of values ​​for the UL cache level. The number of data points generated by the WTRU via inference can vary for one or more radio bearers, application IDs(one or more), network slices, etc.

[0151] As described above, prediction triggering can be associated with other conditions. In the example, prediction triggering can be based on wireless signals, where the WTRU can be configured to infer values ​​based on (e.g., current and / or predicted) RSRP values. In the example, the WTRU can trigger prediction based on the current RSRP value or based on one or more predicted future RSRP values ​​that may fall within the range.

[0152] The evaluation of the criteria can be accomplished using thresholds or other options. The WTRU can receive absolute and / or relative thresholds for evaluating the predicted UL cache values. The thresholds can be relative to an existing configuration or a configuration received for the purposes of the LTM process. The WTRU can receive other conditions, such as an averaging condition for the inferred UL cache values. The averaging condition can be a weighted average condition that can be applied to a subset of the inferred values.

[0153] The WTRU can be configured with one or more absolute and / or relative thresholds for evaluating predicted UL cache values. This configuration enables the WTRU to evaluate and combine predicted UL cache values ​​with current / predicted radio quantity values. The WTRU can perform the evaluation of predicted cache values ​​in different ways (e.g., considering conditions / thresholds).

[0154] In the example, the WTRU can apply different averaging configurations to different subsets of the predicted UL cache values. The WTRU can consider different ranges of prediction assessment (e.g., configuration thresholds based on current and / or predicted radio quantities). The WTRU can rely on the configuration of explicitly reporting cache values ​​to the source cell.

[0155] For explicit indications from the network (e.g., a PDCCH command to initiate UL synchronization with a neighboring cell, or to perform a CSI report from a neighboring cell), this can be associated with implicit reporting to the target cell (e.g., the target network node). The WTRU can (e.g., in this case) use a RACH preamble as an implicit indicator of its current cache state. The WTRU's determination of the RACH preamble sequence can be based on different parameters. These parameters can result in distinct and unique RACH preamble sequences, and can be mapped to a specific UL cache state value.

[0156] If a preamble sequence is sent to the network during UL synchronization, the mapping itself can be an implicit indication of the WTRU to the UL cached value. By knowing and configuring the WTRU with the appropriate mapping of values, the network may (e.g., and then possibly) be able to decode. If the number of possible sequences varies with the cell, some cells may be able to map to more intervals or absolute values ​​(e.g., in bytes for a given RACH configuration index).

[0157] In the example, the maximum number of bytes reported for the BSR in WTRU can be equally divided by the number of possible RACH sequence indices and mapped accordingly. In the example, the byte intervals of the UL cache can be unequal (e.g., they can be weighted over the possible number of RACH sequences). An example could be mapping a certain number x entries from the UL cache table to the first index of the RACH sequence table. The second index can (e.g., then) be mapped to intervals in bytes (e.g., greater than or less than x). The same applies to the third and / or fourth entries, and so on (e.g., only from there a uniformly distributed mapping). In the example, UL cache values ​​can be split in two (e.g., high or low cache values). In the example, UL cache values ​​can be divided into y values, clustered by byte count, and mapped to a total of p sequence index values ​​(e.g., clustering them into very low, low, and medium categories).

[0158] The WTRU can determine at least one of the following: current or predicted UL data traffic / (one or more) current or predicted UL cached data levels, or current or predicted radio signal levels of (one or more) cells (e.g., serving cell and neighboring cells (e.g., predictions based on AIML models)). To monitor (one or more) triggering conditions, the WTRU can monitor reported criteria. If it is determined that (one or more) triggering conditions are met, the WTRU can send an indication to the network. In the example, the WTRU can send an indication to the network based on the current or predicted UL cached data level meeting a current or predicted UL cached data threshold (e.g., based on (one or more) predicted cached values ​​associated with a subset of bearers or (one or more) bearers, or based on (one or more) predicted cached values ​​associated with an application ID or a subset of (one or more) application IDs meeting a current or predicted UL cached data threshold). In the example, the WTRU can send an indication based on the current or predicted radio signal level of a cell meeting a current or predicted radio signal level threshold. In the example, the WTRU can send an indication based on an explicit indication from the network. Instructions can be explicit reports (e.g., via L3 signaling, L1 reports, MAC CE, UCI, etc.). Instructions can also be implicit instructions (e.g., during a RA process with a neighboring cell, using a RACH preamble associated with the current / predicted UL cache state).

[0159] If one or more conditions are met, the WTRU can notify the network of anticipated UL traffic. Based on the fulfillment of one or more conditions, the network can provide the WTRU with the UL authorization required to transmit the anticipated UL data. If UL authorization cannot be provided in the current serving cell / node, the WTRU can trigger mobility to another cell / node.

[0160] The WTRU can be configured with one or more trigger conditions (e.g., predicted / current radio conditions, predicted / current buffer level, explicit indications from the network for performing neighbor cell preparation (such as UL synchronization), etc.) to send an indication to the network regarding the predicted UL buffer level. The WTRU can monitor one or more trigger conditions. If one or more trigger conditions are met, the WTRU can send an indication to the network that indicates (e.g., explicitly or implicitly) one or more of the current / predicted BSRs.

[0161] The WTRU can receive configuration information from the network for reporting current or predicted UL cache state information (e.g., via an RRC reconfiguration message). The configuration information may include at least one trigger condition for sending the report. At least one trigger condition may be associated with reporting current or predicted UL cache state information and includes one or more of the following: conditions related to the current radio signal levels of the serving cell and neighboring cells (e.g., absolute threshold, relative threshold, current radio signal level threshold, etc.); conditions related to the predicted radio signal levels of the serving cell and neighboring cells (e.g., absolute threshold, relative threshold, predicted signal level threshold, etc.); conditions related to the current UL cache level (e.g., current UL cache data threshold, cache values ​​of a specific bearer or subset of bearers(one or more) associated with the current UL cache data threshold, cache values ​​of a specific bearer(one or more) associated with the current UL cache data threshold, etc.). Application ID or cached values ​​of one or more subsets of application IDs, etc.; conditions associated with the predicted UL cache level (e.g., predicted UL cache data threshold, predicted cached values ​​of one or more subsets of a specific bearer or bearer associated with the predicted UL cache data threshold, predicted cached values ​​of one or more subsets of a specific application ID or application ID associated with the predicted UL cache data threshold, etc.); or explicit instructions from the network (e.g., PDCCH commands to initiate UL synchronization with neighboring cells or to execute CSI reports for neighboring cells (e.g., sending CSI reports associated with neighboring cells).

[0162] The WTRU can receive configuration information including indications (e.g., a first indication) of whether the indication is explicit (e.g., performed using or indicated by a measurement report) or implicit (e.g., performed or indicated via a UL synchronization, which includes RACH preambles for different predicted UL cache levels) to report predicted UL cache status information. The WTRU can determine at least one of the following: current or predicted UL data traffic / (one or more) current or predicted UL cache data levels; or (one or more) current or predicted radio signal levels of (one or more) cells (e.g., serving cell and neighboring cells (e.g., predictions based on AIML models)).

[0163] The WTRU can monitor at least one triggering condition. If at least one triggering condition is met, the WTRU can send an indication (e.g., a second indication) to the network. In the example, the WTRU can send an indication (e.g., a second indication) to the network based on the current or predicted UL cached data level meeting a current or predicted UL cached data threshold (e.g., based on one or more predicted cached values ​​associated with a bearer or a subset of bearers(s) or one or more predicted cached values ​​associated with an application ID or a subset of application IDs(s). In the example, the WTRU can send an indication (e.g., a second indication) based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold. In the example, the WTRU can send an indication (e.g., a second indication) based on an explicit indication from the network. The indication (e.g., the second indication) can be one or more of the following: an explicit report sent to the source network node (e.g., via L3 signaling, L1 report, MAC CE, UCI, etc.), including information related to the current / predicted UL cache state, the current / predicted radio signal levels of the serving cell and neighboring cells; or an implicit indication sent to the target network node (e.g., using a RACH preamble associated with the current / predicted UL cache state during the RA process with neighboring cells).

[0164] The WTRU can perform mobility-related actions based on one or more triggering conditions related to current / predicted UL traffic and radio signal levels. The WTRU may receive configuration information (e.g., via an RRC reconfiguration message) containing a set of different conditions (one or more) to be monitored, which the WTRU can use as triggers if it determines that one or more conditions are met. If at least one or more triggering conditions are met, the WTRU can determine the mobility-related action to take (e.g., initiating a RACH procedure with the target cell, starting to send CSI reports for neighboring cells, starting to evaluate conditional reconfiguration, etc.). At any given point in time when a decision is made, the mobility-related action performed by the WTRU is likely to be most appropriate (e.g., action selection is important). The WTRU may take more than one action (e.g., depending on whether the criteria for that action are met). For example, the WTRU may start an evaluation of conditional reconfiguration, and while the evaluation is in progress, the WTRU may send (e.g., a CSI report, or a CSI report with the following information) information about neighboring cells.

[0165] Criteria configured in the WTRU can be associated with different actions in a variety of ways. In different solutions for initiating a RACH procedure to a target cell, the WTRU can trigger the action based on any given criterion. Criteria can be combined (e.g., the WTRU can initiate a RACH procedure based on criteria of current radio measurements and predicted UL buffer state values).

[0166] Criteria can have associated timers or other forms of validity conditions. Different criteria associated with one or more actions may have different validitys. For example, the WTRU may receive a configuration where the validity of one or more criteria for a particular action may expire. The WTRU may begin monitoring a second criterion based on a second validity. The same applies to third, fourth, and so on. Validities may overlap or may not overlap. The WTRU (e.g., in some cases) may begin monitoring a second criterion while the evaluation of the first criterion is still valid. Validity can be assumed in forms other than time. In the example, validity can be evaluated as a timer. In the example, validity can be evaluated as the amount of UL data starting from (e.g., as indicated in a previous cache status report) a range defined by the difference between the time the configuration was received and the detected radio quantity of some increment of that quantity. In the example, validity can be evaluated as the amount of DL data. In the example, validity can be evaluated as the rate of change of throughput in the UL or DL, distance, etc.

[0167] If its criteria are met, the WTRU may not be able to prevent the triggering of multiple actions. The WTRU may determine to perform a series of actions (e.g., activating the SCell and updating the CSI reporting configuration of that cell) based on predicted radio conditions associated with the candidate LTM target cell. The WTRU may initiate early TA acquisition for the target cell and, based on predicted radio conditions and UL cache status, may deactivate the measurement configuration of a subset of LTM candidate cells, disable CSI reporting on the source cell, and / or trigger the BSR reporting process. Based on predicted radio conditions for both the source and candidate cells, the WTRU may determine that radio conditions are conducive to seamless cell handover and may reduce CSI reporting content to limit UL signaling overhead. Based on UL cache predictions and current radio measurement assessments, the WTRU may enable CSI reporting for one or more LTM candidate cells. Based on one or more of the following: current CSI measurements of the source cell; current and / or predicted UL cache levels; current and / or predicted radio quantities; or current and / or predicted CSI measurements, the WTRU may perform LTM cell handover. The WTRU can begin monitoring the PDCCH channel on one or more target cells, triggering a BSR, and / or updating the CSI report of the source cell.

[0168] WTRU can determine at least one of the following: current or predicted UL data traffic / (one or more) current or predicted UL cached data levels; or (one or more) current or predicted radio signal levels of cells (e.g., serving cell and neighboring cells (e.g., based on AI / ML models)).

[0169] The WTRU can monitor criteria used for reporting, which may include at least one trigger condition. If it is determined that one or more trigger conditions are met, the WTRU can select a mobility-related action (e.g., initiating a RACH procedure with the target cell, starting to send CSI reports for neighboring cells, starting to evaluate conditional reconfiguration, etc.). In the example, the WTRU can select a mobility-related action based on the current or predicted UL cache data level meeting a current or predicted UL cache data threshold (e.g., based on one or more predicted cache values ​​associated with a bearer or a subset of bearers or one or more bearers, or one or more predicted cache values ​​associated with an application ID or a subset of application IDs). In the example, the WTRU can select a mobility-related action based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold. The WTRU can execute the selected mobility-related action.

[0170] WTRUs can facilitate the preparation of target cells (e.g., for handover, as secondary cells for carrier aggregation, as secondary cell groups for dual connectivity, etc.), and UL traffic is expected to increase.

[0171] The WTRU can be configured with trigger conditions (e.g., predicted / current radio conditions, predicted / current buffer levels, etc.) to initiate actions (e.g., UL synchronization with neighboring cells, CSI / CQI reporting from neighboring cells, evaluation of conditional reconfiguration criteria, etc.). The WTRU can monitor one or more trigger conditions. If one or more trigger conditions are met, the WTRU can initiate the corresponding action.

[0172] The WTRU can receive configuration information (e.g., via RRC reconfiguration messages) associated with initiating mobility-related actions (e.g., performing UL synchronization with neighboring cells, initiating the transmission of CSI / CQI reports related to neighboring cells, etc.). The configuration information may include at least one triggering condition for initiating the mobility-related action. At least one triggering condition may include one or more of the following: conditions related to the current radio signal levels of the serving cell and neighboring cells (e.g., absolute threshold, relative threshold, current radio signal level threshold, etc.); conditions related to the predicted radio signal levels of the serving cell and neighboring cells (e.g., absolute threshold, relative threshold, predicted radio signal level threshold, etc.); conditions related to the current UL cache level (e.g., current UL cache data threshold, cache values ​​of a specific bearer or subset of bearers(one or more) associated with the current UL cache data threshold, a specific application ID or (one or more) associated with the current UL cache data threshold). (e.g., cached values ​​of one or more subsets of application IDs); conditions associated with the predicted UL cache level (e.g., predicted UL cache data threshold, predicted cached values ​​of one or more subsets of a specific bearer or bearer(s) associated with the predicted UL cache data threshold, predicted cached values ​​of one or more subsets of a specific application ID or application ID(s) associated with the predicted UL cache data threshold); or conditions specific to the WTRU to determine the action to be taken (e.g., initiating a RACH procedure with the target cell, starting to send CSI reports of one or more neighboring cells, starting an assessment of conditional reconfiguration, etc.).

[0173] The WTRU can determine at least one of the following: current or predicted UL data traffic / (one or more) current or predicted UL cached data levels; or (one or more) current or predicted radio signal levels of (one or more) cells (e.g., serving cell and neighboring cells (e.g., based on AIML models)).

[0174] The WTRU can monitor at least one trigger condition. If at least one trigger condition is met, the WTRU can select a mobility-related action based on the met trigger condition(s) (e.g., initiating a RACH procedure with the target cell, starting to send CSI reports to one or more neighboring cells, starting to evaluate conditional reconfiguration, etc.). In the example, the WTRU can select a mobility-related action based on the current or predicted UL cache data level meeting a current or predicted UL cache data threshold (e.g., based on one or more predicted cache values ​​associated with a bearer or a subset of bearers or one or more bearers, or one or more predicted cache values ​​associated with an application ID or a subset of application IDs). In the example, the WTRU can select a mobility-related action based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold. The WTRU can execute the selected mobility-related action.

[0175] If certain conditions are met, the WTRU can defer the HO (House Opening) and can perform a transfer via the source cell. Based on one or more conditions (e.g., deferral conditions or criteria) monitored by the WTRU, the WTRU can defer LTM cell handover or HO, or can perform a conditional reconfiguration. The examples described herein may apply to one or more conditions related to current and / or predicted radio measurements and buffer states. The WTRU can be configured with different possible combinations of criteria related to these aspects and can monitor the criteria to determine HO, reconfiguration, UL handover, deferral time, etc. A concept such as a maximum deferral time may be assumed to exist, but the WTRU may not perform this action (e.g., perform a cell handover when the maximum deferral time expires). The WTRU can trigger an action based on the satisfaction of one or more received criteria or via instructions from the network to do so.

[0176] The examples in this article can (for example, may also) apply to concurrent configurations and the validity of configurations. For example, if the second criterion has already been met (e.g., even if monitoring of the second criterion begins after monitoring of the first criterion), the WTRU can trigger an action (e.g., or postpone the action). The same applies to the third, fourth, and so on criteria.

[0177] If a WTRU might need to satisfy more than one criterion to perform an action, it can assume that different criteria can be grouped together. In the example, the WTRU can receive grouped criteria with their associated validity, where (e.g., all) (one or more) conditions in the group can be satisfied. In the example, the different criteria in the group can have associated hard and soft thresholds. In these cases, the hard threshold can be evaluated for the satisfaction of (one or more) conditions, but if multiple soft thresholds are satisfied, the criterion can be considered satisfied (e.g., then it can be). For example, the WTRU can receive grouped criteria with hard and soft thresholds for predicted measurements and current and predicted cache states. If, for a future time period, both the predicted values ​​of the measurement and the cache state are below / above the soft threshold, but the current cache state is above / below the hard threshold, the criterion can be considered satisfied.

[0178] The WTRU may receive configuration information (e.g., via an RRC reconfiguration message) that includes at least one triggering condition associated with a delayed mobility process. The at least one triggering condition may include at least one of the following: a current or predicted UL cached data level threshold, a current or predicted radio signal level threshold, or a maximum mobility process delay time.

[0179] The examples described herein may be applicable to conditions used to postpone mobility processes associated with current and predicted radio signal levels of the source and target cells (e.g., current radio signal level thresholds, predicted radio signal level thresholds, absolute thresholds, relative thresholds, etc.). The examples described herein may also be applicable to conditions used to postpone mobility processes associated with current and predicted UL cache levels (e.g., current UL cache data thresholds, predicted UL cache data thresholds, total cache level, cache level of a subset of radio bearers, predicted cache values ​​of a specific bearer or subset of bearers(one or more) associated with the current or predicted UL cache data thresholds, predicted cache values ​​of a specific application ID or subset of application IDs(one or more), etc.).

[0180] The maximum delay time can be represented in various forms, such as by one or more of the following: a timer; a time window; a small time window extracted from the validity of the prediction; geographic location; distance; the amount of UL and / or DL ​​data; or a subframe number or system frame number. If the current UL cache is below or equal to a certain threshold, the WTRU can perform a HO before the delay time.

[0181] For configurations used to refresh UL data before the maximum delay time expires (e.g., via activating a pre-configured or newly configured authorization), the WTRU can be configured with previously unconfigured authorizations, or may include an indication of a pre-configured authorization to be used by the WTRU before the delay time. The WTRU can be activated and transferred in the UL with one or more configured authorizations. In the example, each authorization can be associated with a different timer, such that if a first timer corresponding to a first authorization expires, the WTRU can activate a second authorization. Authorization activation can stop here, or it can continue to a third and / or fourth authorization. Authorizations can (e.g., may also) be associated with the conditions described herein, and their activation can be selective. For example, based on current / predicted cached values ​​within certain limits, and in the case of predicted values, if they are within the limits at some future time, the WTRU can be configured to activate a specific authorization.

[0182] The WTRU can receive an HO command or determine that one or more conditions (e.g., one or more measured radio conditions) for performing a CHO are met. The WTRU can determine at least one of the predicted UL buffer data level, the predicted radio signal level, or the mobility process delay time. The WTRU can perform the HO action based on network indications or based on WTRU monitoring criteria and determining that the received criteria have been met.

[0183] If (e.g., provided that) at least one condition for delaying a mobility procedure is met (e.g., at least one triggering condition) (e.g., sending a BSR to the source if needed / triggered), the WTRU may delay the execution of the mobility procedure and continue its connection with the source cell. In the example, the WTRU may delay the mobility procedure and continue its connection with the source cell based on the current or predicted UL cache data level meeting a current or predicted UL cache data threshold (e.g., based on one or more predicted cache values ​​associated with a bearer or subset of bearers(s) or one or more predicted cache values ​​associated with an application ID or subset of application IDs(s)). In the example, the WTRU may delay the mobility procedure and continue its connection with the source cell based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold. In the example, the WTRU may delay the mobility procedure and continue its connection with the source cell based on the mobility procedure delay time meeting a maximum mobility procedure delay time. The delay time may be determined by the WTRU based on these descriptions and may occur before or at most at the time corresponding to the maximum delay time. If the deferral conditions are met and the WTRU maintains connectivity with the source cell, the WTRU can trigger a BSR to support the network's evaluation of the current UL grant configuration based on the UL cache state. The WTRU may receive (e.g., additional) grant configurations and / or indications from the network to activate alternative grant configurations during that period. The WTRU may have already received a similar configuration (e.g., for this purpose) but associates it with the triggering of the BSR during the deferral evaluation window.

[0184] The WTRU can transmit signals to the source cell during the mobility procedure delay period (e.g., the signals may include a BSR if triggered). The WTRU can determine which one or more grants will be used as details and can trigger the transmission of a BSR to the source cell during the delay window. The delay window can have a start time and an end time. At any point during this time period, the WTRU can transmit a BSR. One or more BSRs that can be triggered by the WTRU can be the same as one or more previously used BSRs(s).

[0185] If it is determined that the conditions for delaying the mobility procedure are no longer met, the WTRU may perform a HO / CHO with the target cell and may send indications of the current BSR and the predicted BSR to the target cell. The WTRU may perform an action (e.g., HO). Optionally, sending a BSR to the network can be used for further resource allocation and management at the target cell. The WTRU may trigger a BSR toward the network. The WTRU (e.g., for this purpose) may have already received a similar configuration, but associates it with triggering a BSR that will be sent concurrently with the HO action.

[0186] If one or more of the conditions are not met, the WTRU can perform a HO to carry out the transfer to the target. The WTRU can ensure that UL data currently in the WTRU buffer and expected to arrive at the WTRU soon can be transferred via the source before the handover to the target is performed (e.g., and thus avoid UL data interruption).

[0187] The WTRU can be configured with one or more conditions for deferring the HO (e.g., a time window from receiving the HO command or meeting the CHO conditions, the current / predicted UL buffer level, the current / predicted signal level of the source / target cell, etc.). If (e.g., as long as) the conditions for deferring the HO are met, the WTRU can defer the HO and transmit data via the source. If the conditions (one or more) are not met (e.g., when the conditions are no longer met), the WTRU can perform the HO and transmit data via the target. The WTRU can determine the optimal target cell based on the current UL buffer and grant at the target cell (one or more) of the target cells.

[0188] The WTRU may receive configuration information (e.g., via an RRC reconfiguration message) that includes one or more conditions associated with delaying a mobility process from the source cell to the target cell (e.g., delaying source release, delaying HO, delaying CHO, or delaying a portion of an HO process, such as switching UL from the source to the target during a DAP HO). The configuration information may include at least one triggering condition associated with delaying the mobility process. At least one triggering condition may include one or more of the following: conditions for delaying the mobility process related to the current and predicted radio signal levels of the source and target cells (e.g., current radio signal level threshold, predicted radio signal level threshold, absolute threshold, relative threshold, etc.); conditions for delaying the mobility process related to the current and predicted UL cache levels (e.g., current UL cache data threshold, predicted UL cache data threshold total cache level, cache level of a subset of radio bearers, predicted cache value of a specific bearer or subset of bearers associated with the current or predicted UL cache data threshold, predicted cache value of a specific application ID or subset of application IDs, etc.); or maximum mobility process delay time.

[0189] The WTRU can receive an HO command or determine that one or more conditions (e.g., one or more measured radio conditions) are met for performing a CHO. The WTRU can determine at least one of a predicted UL cache data level, a predicted radio signal level, or a mobility procedure delay time. If (e.g., provided) at least one condition for delaying the mobility procedure is met (e.g., at least one triggering condition) (e.g., sending a BSR to the source if needed / triggered), the WTRU can delay the execution of the mobility procedure and continue its connection with the source cell. In the example, based on the current or predicted UL cache data level meeting a current or predicted UL cache data threshold (e.g., based on one or more predicted cache values ​​associated with a bearer or a subset of bearers or one or more bearers, or one or more predicted cache values ​​associated with an application ID or a subset of application IDs meeting a current or predicted UL cache data threshold), the WTRU can delay the mobility procedure and continue its connection with the source cell. In the example, based on the current or predicted radio signal level of the cell meeting a current or predicted radio signal level threshold, the WTRU can delay the mobility procedure and continue its connection with the source cell. In the example, based on the mobility procedure delay time meeting the maximum mobility procedure delay time, the WTRU can delay the mobility procedure and continue the connection with the source cell. The WTRU can transmit signals to the source cell during the mobility procedure delay time (e.g., the signals may include a BSR if triggered). Based on the fact that at least one triggering condition is no longer met, a HO with the target cell can be initiated, and indications of the predicted BSR and the current BSR can be sent to the target cell.

[0190] The WTRU can report the predicted UL cache status based on one or more triggering conditions (e.g., implicitly or explicitly). If one or more conditions are met, the WTRU can notify the network of anticipated UL traffic. Based on the satisfaction of one or more conditions, the network can provide the WTRU with the UL authorization required to transmit the anticipated UL data. If UL authorization is not available in the current serving cell / node, the network or the WTRU can trigger mobility to another cell / node.

[0191] The WTRU can be configured with one or more trigger conditions (e.g., one or more predicted / current radio conditions, predicted / current buffer levels, explicit indications from the network for performing neighbor cell preparation (such as UL synchronization), etc.) to send an indication to the network regarding the predicted UL buffer level. The WTRU can monitor one or more trigger conditions. If one or more trigger conditions are met, the WTRU can send an indication to the network that indicates (e.g., explicitly or implicitly) one or more of the current / predicted BSRs.

[0192] The WTRU can receive configuration information (e.g., first configuration information) for reporting current or predicted UL cache status information. The configuration information may include one or more triggering conditions for sending the report. These triggering conditions may include one or more of the following: one or more conditions related to the current radio signal levels of the serving cell and neighboring cells (e.g., absolute thresholds, relative thresholds, etc.); one or more conditions related to the predicted radio signal levels of the serving cell and neighboring cells (e.g., absolute thresholds, relative thresholds, etc.); one or more conditions related to the current UL cache level (e.g., cache values ​​for a specific bearer or subset of bearers, a specific application ID or subset of application IDs, etc.); one or more conditions related to the predicted UL cache level (e.g., predicted cache values ​​for a specific bearer or subset of bearers, a specific application ID or subset of application IDs, etc.); or explicit indications from the network (e.g., a PDCCH command initiating UL synchronization with neighboring cells, or performing a CSI report for a neighboring cell).

[0193] The WTRU can receive configuration information (e.g., second configuration information) indicating whether to report predicted UL buffer status information explicitly (e.g., using measurement reports) or implicitly (e.g., in UL synchronization, where RACH preambles are divided for different predicted UL buffer levels). The WTRU can determine the current or predicted UL data traffic and the current or predicted radio signal levels of the serving cell and neighboring cells (e.g., predictions based on AIML models).

[0194] The WTRU can monitor one or more triggering conditions. If one or more triggering conditions are met, the WTRU can send an indication to the network. This indication can be one or more of the following: explicit reporting (e.g., via L3 signaling, L1 reporting, MACCE, UCI, etc.), including information related to the current / predicted UL cache state, the current / predicted radio signal levels of the serving cell and neighboring cells; or implicit indication (e.g., using a RACH preamble associated with the current / predicted UL cache state during a RA process with neighboring cells).

[0195] Although the features and elements described above are described in a specific combination, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0196] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and can be applied to other wireless systems. For example, although the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and can also be applied to other wireless systems.

[0197] The above processes can be implemented in computer programs, software, and / or firmware, which are incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as optical disc (CD)-ROMs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information associated with the uplink (UL) cached state information predicted by the report from the network, wherein the configuration information includes: At least one trigger condition associated with the predicted UL cache state information reported in the report, wherein the at least one trigger condition includes a UL cache data threshold, and The first indication is whether the predicted UL cache state information is reported explicitly or implicitly; Determine the predicted UL cache data level; Determine that the predicted UL cache data level meets the UL cache data threshold; and At least based on meeting the UL cache data threshold, a second indication is sent to report the predicted UL cache status information to the network, wherein the second indication is an explicit indication or an implicit indication.

2. The WTRU according to claim 1, wherein, The at least one triggering condition further includes a predicted radio signal level threshold, and wherein the processor is further configured to: Determine the predicted radio signal level of the cell, and The predicted radio signal level of the cell is determined to meet the predicted radio signal level threshold, wherein a second indication is further sent to report the predicted UL cache state information to the network based on meeting the predicted radio signal level threshold.

3. The WTRU of claim 1, wherein the at least one triggering condition further includes an explicit indication from the network, and wherein a second indication for reporting the predicted UL cache state information to the network is further sent based on the explicit indication from the network.

4. The WTRU of claim 3, wherein the explicit indication from the network is a Physical Downlink Control Channel (PDCCH) command indicating the start of UL synchronization with a neighboring cell, or indicating the transmission of a Channel State Information (CSI) report associated with the neighboring cell.

5. The WTRU according to claim 1, wherein, If the second instruction is an explicit instruction, then: The measurement report is used to indicate the predicted UL cache status information, and The predicted UL cache state information is sent to the source network node.

6. The WTRU according to claim 1, wherein, If the second instruction is an implicit instruction, then: The predicted UL cache state information is indicated via UL synchronization, which includes a random access channel (RACH) preamble divided for different predicted UL cache levels, and... The predicted UL cache state information is sent toward the target network node.

7. The WTRU according to claim 1, wherein, The predicted UL cache data level is determined to meet the UL cache data threshold based on either a value associated with the bearer or a value associated with the application identifier (ID).

8. A method associated with a wireless transmit / receive unit (WTRU), comprising: Receive configuration information associated with the uplink (UL) cached state information predicted by the report from the network, wherein the configuration information includes: At least one trigger condition associated with the predicted UL cache state information reported in the report, wherein the at least one trigger condition includes a UL cache data threshold, and The first indication is whether the predicted UL cache state information is reported explicitly or implicitly; Determine the predicted UL cache data level; Determine that the predicted UL cache data level meets the UL cache data threshold; and At least based on meeting the UL cache data threshold, a second indication is sent to report the predicted UL cache status information to the network, wherein the second indication is an explicit indication or an implicit indication.

9. The method of claim 8, wherein the at least one triggering condition further comprises a predicted radio signal level threshold, further comprising: Determine the predicted radio signal level of the cell; and The predicted radio signal level of the cell is determined to meet the predicted radio signal level threshold, wherein a second indication is further sent to report the predicted UL cache state information to the network based on meeting the predicted radio signal level threshold.

10. The method of claim 8, wherein the at least one triggering condition further includes an explicit indication from the network, and wherein a second indication for reporting the predicted UL cache state information to the network is further sent based on the explicit indication from the network.

11. The method of claim 10, wherein the explicit indication from the network is a Physical Downlink Control Channel (PDCCH) command indicating the start of UL synchronization with a neighboring cell, or indicating the transmission of a Channel State Information (CSI) report associated with the neighboring cell.

12. The method according to claim 8, wherein, If the second instruction is an explicit instruction, then: The measurement report is used to indicate the predicted UL cache status information, and The predicted UL cache state information is sent to the source network node.

13. The method of claim 8, wherein, If the second instruction is an implicit instruction, then: The predicted UL cache state information is indicated via UL synchronization, which includes a random access channel (RACH) preamble divided for different predicted UL cache levels, and... The predicted UL cache state information is sent toward the target network node.

14. The method according to claim 8, wherein, The predicted UL cache data level is determined to meet the UL cache data threshold based on either a value associated with the bearer or a value associated with the application identifier (ID).

Images