Time default transmission configuration indicator state prediction

Abstract

Certain aspects of the present disclosure provide techniques for network and user equipment (UE) based time default transmit configuration indicator (TCI) state prediction in lower layer triggered mobility (LTM). An example method performed at a UE generally includes obtaining information to configure a set of candidate cells for a user equipment, wherein the user equipment supports an LTM that enables communication handover between candidate cells; obtaining a command indicating that the UE is to handover from the one or more source cells to one or more target cells in the set of candidate cells; obtaining a request for a time beam prediction result; outputting a report including the time beam prediction result for transmission; and after obtaining the request, processing at least one communication associated with one or more of the target cells based on the temporal beam prediction result.

Description

Background Technology Technical Field

[0002] Various aspects of this disclosure relate to wireless communications, and more specifically to techniques for predicting the state of the Time Transmission Configuration Indicator (TCI) in lower-layer triggered mobility (LTM).

[0003] Related technical descriptions

[0004] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, broadcasting, or other similar services. These wireless communication systems may employ multiple access technologies that enable communication with several users by sharing available wireless communication system resources.

[0005] Despite significant technological advancements in wireless communication systems over the years, challenges remain. For example, complex and dynamic environments can still attenuate or block signals between wireless transmitters and receivers. Therefore, there is a continuous expectation for improving the technical performance of wireless communication systems, including, for example: improving communication speed and data carrying capacity; improving the efficiency of shared communication media; reducing the power used by transmitters and receivers during communication; improving the reliability of wireless communication; avoiding redundant transmission and / or reception and related processing; improving the coverage area of ​​wireless communication; increasing the number and types of devices that can access the wireless communication system; increasing the ability of different types of devices to communicate with each other; and increasing the number and types of available wireless communication media. Therefore, there is a need for further improvements to wireless communication systems to overcome the aforementioned technical challenges and other obstacles. Summary of the Invention

[0006] One aspect provides a method for wireless communication at a user equipment (UE). The method includes: obtaining information configuring a set of candidate cells for the UE, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells; obtaining a command instructing the UE to handover from one or more source cells to one or more target cells in the candidate cell set; obtaining a request for time beam prediction results; outputting a report including the time beam prediction results for transmission; and, upon receiving the request, processing at least one communication associated with one or more target cells in the target cells based on the time beam prediction results.

[0007] On the other hand, a method for wireless communication at a user equipment (UE) is provided. The method includes: obtaining information configuring a set of candidate cells for the UE, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells; obtaining a command instructing the UE to handover from one or more source cells to one or more target cells in the candidate cell set; obtaining a time beam prediction result; and, after obtaining the command, processing at least one communication associated with one or more target cells in the target cells based on the time beam prediction result.

[0008] On the other hand, a method for wireless communication at a source network entity is provided. The method includes: outputting information configuring a set of candidate cells for a user equipment (UE) for transmission, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells; outputting a command instructing the UE to hand over from one or more source cells to one or more target cells in the candidate cell set for transmission; and outputting time beam prediction results for transmission to one or more target cells in the target cells.

[0009] On the other hand, a method for wireless communication at a target network entity is provided. The method includes: obtaining information instructing a user equipment (UE) to hand over from one or more source cells to at least one target cell in a set of candidate cells, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells, and the at least one target cell is associated with a target network entity; obtaining a time beam prediction result from at least one source cell in the source cells, predicted by at least one of: the UE or one or more source cells; and, after obtaining the information, processing at least one communication associated with the target cell based on the time beam prediction result.

[0010] Other aspects provide: an apparatus capable of operating, configured, or otherwise adapted to perform one or more of the foregoing methods and / or those methods described elsewhere herein; a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors of the apparatus, cause the apparatus to perform the foregoing methods and those methods described elsewhere herein; a computer program product embodied on a computer-readable storage medium comprising: code for performing the foregoing methods and those methods described elsewhere herein; and / or an apparatus comprising components for performing the foregoing methods and those methods described elsewhere herein. By way of example, an apparatus may include a processing system, a device having a processing system, or a processing system cooperating via one or more networks.

[0011] For illustrative purposes, the following description and figures illustrate certain features. Attached Figure Description

[0012] The accompanying drawings depict certain features of the various aspects described herein and should not be considered as limiting the scope of this disclosure.

[0013] Figure 1 An example wireless communication network is depicted.

[0014] Figure 2 An example decomposed base station architecture is described.

[0015] Figure 3 Various aspects of the example base station and example user equipment are described.

[0016] Figure 4A , Figure 4B , Figure 4C and Figure 4D Various example aspects of data structures used in wireless communication networks are described.

[0017] Figure 5 An example beam refinement process according to certain aspects of this disclosure is illustrated.

[0018] Figure 6 This is a diagram illustrating an example operation that can perform beam management.

[0019] Figure 7 This illustrates a general functional framework for AI-enabled RAN intelligence.

[0020] Figure 8 The example depicts mobility (LTM) triggered by layer 1 / 2 (L1 / L2) based on artificial intelligence (AI) / machine learning (ML).

[0021] Figure 9 Example scenarios involving blocking and LTM are depicted.

[0022] Figure 10A and Figure 10B An example timing diagram illustrating a preferred beam over time is depicted.

[0023] Figure 11 A call flow diagram illustrating UE-based time prediction according to certain aspects of this disclosure is depicted.

[0024] Figure 12 A timing diagram based on UE time prediction is depicted in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0025] Figure 13A timing diagram based on UE time prediction is depicted in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0026] Figure 14 A timing diagram based on UE time prediction is depicted, illustrating a non-ideal backhaul latency scenario according to certain aspects of this disclosure.

[0027] Figure 15 A timing diagram based on UE time prediction is depicted, illustrating a non-ideal backhaul latency scenario according to certain aspects of this disclosure.

[0028] Figure 16 Example time prediction results reported by the UE are depicted according to certain aspects of this disclosure.

[0029] Figure 17 A call flow diagram illustrating network-based time prediction according to certain aspects of this disclosure is depicted.

[0030] Figure 18 A timing diagram based on network time prediction is depicted in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0031] Figure 19 A timing diagram based on network time prediction is depicted in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0032] Figure 20 A timing diagram based on network time prediction is depicted, illustrating a non-ideal backhaul delay scenario according to certain aspects of this disclosure.

[0033] Figure 21 A timing diagram based on network time prediction is depicted, illustrating a non-ideal backhaul delay scenario according to certain aspects of this disclosure.

[0034] Figure 22 Example time prediction results reported by the network are depicted according to certain aspects of this disclosure.

[0035] Figure 23 A method for wireless communication is described.

[0036] Figure 24 A method for wireless communication is described.

[0037] Figure 25 A method for wireless communication is described.

[0038] Figure 26 A method for wireless communication is described.

[0039] Figure 27 Various aspects of the example communication device are described. Detailed Implementation

[0040] This disclosure provides apparatus, methods, processing systems, and computer-readable media for predicting the state of a time-default transmission configuration indicator in lower-layer triggered mobility (LTM). The prediction can be performed at the UE and / or a network entity.

[0041] In some wireless communication systems, signal processing (referred to as beamforming or beam steering) can be performed to redirect wireless signals to a specific direction of a beam. In such systems, two or more wireless devices can perform beam management procedures to select the beam with which they will communicate. For beam management purposes, network entities can configure a set of resources for user equipment (UE) for channel measurements, which may be referred to as channel measurement resources (CMR). The network entity can transmit one or more RS (e.g., SSB) on the CMR using the transmit beam set. The UE can measure the RS to select the receive beam and generate a measurement report for the beam management procedure.

[0042] In advanced wireless systems, when a user equipment (UE) moves between coverage areas of different cells, mobility procedures appropriately help maintain the UE's network connectivity. Mobility procedures generally refer to the mechanisms that allow a UE to transition from service to service of a source cell to service of a target cell. In some cases, the handover from the source cell to the target cell can be triggered by physical layer (PHY or Layer 1 / L1) and / or media access control layer (MAC or Layer 2 / L2) signaling; this is often referred to as L1 / L2 triggered mobility (LTM). In LTM, as the UE moves, a new serving cell (e.g., the primary cell (Pcell) can be selected (e.g., reselected) from the set of cells based on L1 measurements against pre-configured candidate cells.

[0043] Temporal beam prediction (also known as time-domain (TD) beam prediction) generally refers to the techniques used in wireless communications to predict and optimize the direction of transmit and / or receive beams over time. Temporal beam prediction may involve predicting a beam that will be suitable (preferably) for future use. The prediction may be based on current measurements of RSs transmitting using different beams, which may or may not include the predicted beam. Temporal beam prediction can be particularly relevant in scenarios where wireless channel conditions change rapidly, such as in high-mobility environments or in the presence of fading effects.

[0044] In wireless communication systems employing beamforming, multiple antennas can be used to transmit and receive signals. By dynamically adjusting the direction of the transmitted beam, the transmitted energy can be focused towards the intended receiver, mitigating interference from other directions. However, due to the dynamic nature of wireless channels, if the beamforming strategy is not continuously and effectively updated, the optimal beam direction may change rapidly, leading to suboptimal performance.

[0045] Temporal beam prediction can utilize historical channel state information (CSI) and leverage the temporal correlations within the wireless channel. By analyzing past channel measurements, such as received signal strength, signal quality, and / or channel characteristics, the future behavior of the wireless channel can be inferred and the optimal beam direction can be predicted.

[0046] In some cases, artificial intelligence (AI) and / or machine learning (ML) models can be used to perform temporal beam prediction and / or spatial beam prediction (e.g., prediction of beam A based on measurements of a different beam (beam B)). For example, such a model can predict the channel characteristics of a first set of beams based on measurements (e.g., historical measurements) of a second set of beams (e.g., different from the first set of beams). Such beam prediction can be performed by models at network entities and / or UEs.

[0047] Certain scenarios may present challenges to the effectiveness of time-based beam prediction. For example, in the first example scenario, potential obstructions in a cell (e.g., the source cell or the target cell) can be predicted / identified by the network, making it beneficial for the UE to hand over (e.g., LTM) to the target cell. However, potential obstructions may affect the UE's preferred beam in the target cell for some time after the UE hands over, and the UE may not have identified / predicted potential obstructions in advance (e.g., due to limited hardware / processing capabilities). In the second example scenario, non-ideal backhaul delays between the source and target cells may cause the UE's preferred beam in the target cell (e.g., which could be notified by the source cell) to become outdated after the UE has already handed over to the target cell.

[0048] Certain aspects of this disclosure provide techniques for predicting network- and / or UE-based time-default TCI states in LTM that can help address these challenges. For example, during potential blocking and / or to compensate for non-ideal backhaul delays, default and alternative future TCI states (e.g., corresponding to beams) in the target cell can be predicted (e.g., for multiple future time occupancy) and used. Utilizing the techniques disclosed herein can reduce power consumption, LTM latency, and throughput interruptions, while improving the efficiency and reliability of the beam management / prediction process.

[0049] An introduction to wireless communication networks

[0050] The techniques and methods described herein can be used in a variety of wireless communication networks. While aspects may be described herein using terms commonly associated with 3G, 4G, and / or 5G wireless technologies, aspects of this disclosure are equally applicable to other communication systems and standards not explicitly mentioned herein.

[0051] Figure 1An example of a wireless communication network 100 in which the aspects described herein can be implemented is depicted.

[0052] Generally, wireless communication network 100 includes various network entities (optionally, network elements or network nodes). Network entities are typically communication devices and / or communication functions performed by communication devices (e.g., user equipment (UE), base station (BS), components of the BS, servers, etc.). For example, various functions of the network and various devices associated with and interacting with the network can be considered network entities. Furthermore, wireless communication network 100 includes terrestrial aspects, such as terrestrial network entities (e.g., BS 102), and non-terrestrial aspects, such as satellite 140 and aircraft 145, which may include onboard network entities (e.g., one or more BSs) capable of communicating with other network elements (e.g., terrestrial BSs) and user equipment.

[0053] In the depicted example, wireless communication network 100 includes BS 102, UE 104 and one or more core networks (such as Evolved Packet Core (EPC) 160 and 5G Core (5GC) network 190) that interoperate to provide communication services over various communication links, including wired and wireless links.

[0054] Figure 1 Various example UEs 104 are depicted, which may more generally include: cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, global positioning systems, multimedia devices, video devices, digital audio players, cameras, game consoles, tablet computers, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, Internet of Things (IoT) devices, always-on (AON) devices, edge processing devices, or other similar devices. UE 104 may also be more generally referred to as mobile devices, wireless devices, wireless communication devices, stations, mobile stations, subscriber stations, mobile subscriber stations, mobile units, subscriber units, wireless units, remote units, remote devices, access terminals, mobile terminals, wireless terminals, remote terminals, mobile phones, and others. In the context of this disclosure, a wireless node may be a UE or a network entity, such as a source cell or a target cell (or its base station / gNB).

[0055] BS 102 communicates wirelessly with UE 104 via communication link 120 (e.g., transmitting or receiving signals to or from UE 104). Communication link 120 between BS 102 and UE 104 may include uplink (UL) (also known as reverse link) transmission from UE 104 to BS 102 and / or downlink (DL) (also known as forward link) transmission from BS 102 to UE 104. In various aspects, communication link 120 may utilize multiple-input multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity.

[0056] BS 102 may typically include: NodeB, enhanced NodeB (eNB), next-generation enhanced NodeB (ng-eNB), next-generation NodeB (gNB or gNodeB), access point, transceiver base station, radio base station, radio transceiver, transceiver functionality, transmit / receive point, and / or others. Each BS in BS 102 may provide communication coverage for a corresponding geographic coverage area 110, which may sometimes be referred to as a cell, and in some cases may overlap (e.g., a small cell 102' may have a coverage area 110' that overlaps with the coverage area 110 of a macro cell). For example, BS may provide communication coverage for macro cells (covering a relatively large geographic area), pico cells (covering a relatively small geographic area, such as a stadium), femtocells (covering a relatively small geographic area (e.g., a home)), and / or other types of cells.

[0057] Although BS 102 is described as a single communication device in various aspects, it can be implemented in various configurations. For example, to give a few examples, one or more components of the base station can be decomposed, including a central unit (CU), one or more distributed units (DU), one or more radio units (RU), a near real-time (near RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC. In another example, various aspects of the base station can be virtualized. More generally, a base station (e.g., BS 102) can include components located at a single physical location or components located at various physical locations. In examples where the base station includes components located at various physical locations, the various components can each perform functions, such that the various components collectively achieve functionality similar to a base station located at a single physical location. In some aspects, a base station including components located at various physical locations can be referred to as a decomposed radio access network architecture (such as an open RAN (O-RAN) or virtualized RAN (VRAN) architecture). Figure 2 An example decomposed base station architecture is depicted and described.

[0058] Different BSs 102 within the wireless communication network 100 can also be configured to support different radio access technologies (such as 3G, 4G, and / or 5G). For example, a BS 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with EPC 160 via a first backhaul link 132 (e.g., S1 interface). A BS 102 configured for 5G (e.g., 5G NR or Next Generation RAN (NG-RAN)) can interface with 5GC 190 via a second backhaul link 184. BSs 102 can communicate directly or indirectly (e.g., via EPC 160 or 5GC 190) on a third backhaul link 134 (e.g., X2 interface), which can be wired or wireless.

[0059] Wireless communication network 100 can subdivide the electromagnetic spectrum into various categories, bands, channels, or other characteristics. In some aspects, subdivision is provided based on wavelength and frequency, where frequency may also be referred to as carrier, subcarrier, channel, tone, or subband. For example, 3GPP currently defines frequency range 1 (FR1) as including 410MHz to 7125MHz, which is often (interchangeably) referred to as “sub-6GHz”. Similarly, 3GPP currently defines frequency range 2 (FR2) as including 24,250MHz to 71,000MHz, which is sometimes (interchangeably) referred to as “millimeter wave” (“mmW” or “mmWave”). In some cases, FR2 can be further defined according to subranges (such as a first subrange FR2-1 including 24,250MHz to 52,600MHz and a second subrange FR2-2 including 52,600MHz to 71,000MHz). Base stations configured to communicate using mmWave / near mmWave radio bands (e.g., mmWave base stations such as BS 180) can utilize beamforming (e.g., 182) with UEs (e.g., 104) to improve path loss and range.

[0060] The communication link 120 between BS 102 and, for example, UE 104 can be via one or more carriers, which may have different bandwidths (e.g., 5MHz, 10MHz, 15MHz, 20MHz, 100MHz, 400MHz and / or other MHz) and may be aggregated in various ways. The carriers may be adjacent to each other or may not be adjacent to each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL compared to UL).

[0061] Compared to lower-frequency communication, communication using higher frequency bands may have higher path loss and shorter range. Therefore, some base stations (e.g., Figure 1 The BS 180 (180) can utilize beamforming 182 with the UE 104 to improve path loss and range. For example, the BS 180 and UE 104 may each include multiple antennas, such as antenna elements, antenna panels, and / or antenna arrays, to facilitate beamforming. In some cases, the BS 180 may transmit beamformed signals to the UE 104 in one or more transmit directions 182''. The UE 104 may receive beamformed signals from the BS 180 in one or more receive directions 182''. The UE 104 may also transmit beamformed signals to the BS 180 in one or more transmit directions 182''. The BS 180 may also receive beamformed signals from the UE 104 in one or more receive directions 182''. The BS 180 and UE 104 can then perform beamforming training to determine the optimal receive and transmit directions for each of the BS 180 and UE 104. It is worth noting that the transmit and receive directions of the BS 180 may be the same or different. Similarly, the sending and receiving directions of UE 104 can be the same or different.

[0062] The wireless communication network 100 also includes a Wi-Fi AP 150 that communicates with a Wi-Fi station (STA) 152 via a communication link 154 in, for example, unlicensed spectrum in 2.4 GHz and / or 5 GHz.

[0063] Some UEs 104 may use device-to-device (D2D) communication links 158 to communicate with each other. The D2D communication link 158 may use one or more sidelink channels, such as physical sidelink broadcast channel (PSBCH), physical sidelink discovery channel (PSDCH), physical sidelink shared channel (PSSCH), physical sidelink control channel (PSCCH), and / or physical sidelink feedback channel (PSFCH).

[0064] EPC 160 may include various functional components, including: Mobility Management Entity (MME) 162, other MMEs 164, Serving Gateway 166, Multimedia Broadcast Multicast Service (MBMS) Gateway 168, Broadcast Multicast Service Center (BM-SC) 170, and / or Packet Data Network (PDN) Gateway 172, as in the illustrated example. MME 162 may communicate with Home Subscriber Server (HSS) 174. MME 162 is the control node that handles signaling between UE 104 and EPC 160. Generally, MME 162 provides bearer and connectivity management.

[0065] Generally, user Internet Protocol (IP) packets are transmitted through Serving Gateway 166, which is itself connected to PDN Gateway 172. PDN Gateway 172 provides UE IP address allocation and other functions. PDN Gateway 172 and BM-SC 170 are connected to IP services 176, which may include, for example, the Internet, intranets, IP Multimedia Subsystem (IMS), packet-switched (PS) streaming services, and / or other IP services.

[0066] The BM-SC 170 provides functionality for MBMS user service dispatch and delivery. The BM-SC 170 can serve as an entry point for content provider MBMS transmissions, can be used to authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and / or can be used to schedule MBMS transmissions. The MBMS gateway 168 can be used to distribute MBMS services to BS 102 belonging to a Broadcast-Specific Service Single Frequency Network (MBSFN) area, and / or can be responsible for session management (start / stop) and collecting eMBMS-related billing information.

[0067] 5GC 190 may include various functional components, including: Access and Mobility Management Function (AMF) 192, other AMFs 193, Session Management Function (SMF) 194, and User Plane Function (UPF) 195. AMF 192 can communicate with Unified Data Management (UDM) 196.

[0068] AMF 192 is the control node that handles signaling between UE 104 and 5GC 190. AMF 192 provides services such as Quality of Service (QoS) flow and session management.

[0069] Internet Protocol (IP) packets are transmitted via UPF 195, which connects to IP service 197 and provides the UE with IP address allocation and other functions for 5GC 190. IP service 197 may include, for example, the Internet, intranet, IMS, PS streaming service, and / or other IP services.

[0070] In various aspects, to give a few examples, network entities or network nodes can be implemented as aggregated base stations, decomposed base stations, components of base stations, integrated access and backhaul (IAB) nodes, relay nodes, and sidelink nodes.

[0071] Figure 2An example decomposed base station 200 architecture is depicted. The decomposed base station 200 architecture may include one or more central units (CUs) 210, which may communicate directly with the core network 220 via a backhaul link, or indirectly with the core network 220 through one or more decomposed base station units, such as a near real-time (near-RT) RAN Intelligent Controller (RIC) 225 via an E2 link, or a non-real-time (non-RT) RIC 215 associated with a Service Management and Orchestration (SMO) framework 205, or both. CUs 210 may communicate with one or more distributed units (DUs) 230 via corresponding midhaul links (such as F1 interfaces). DUs 230 may communicate with one or more radio units (RUs) 240 via corresponding fronthaul links. RUs 240 may communicate with a corresponding UE 104 via one or more radio frequency (RF) access links. In some specific implementations, UE 104 may be served simultaneously by multiple RUs 240.

[0072] Each unit in a cell (e.g., CU 210, DU 230, RU 240, and near-RT RIC 225, non-RT RIC 215, and SMO frame 205) may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the cells, or an associated processor or controller that provides instructions to the cell's communication interface, may be configured to communicate with one or more other cells via the transmission medium. For example, these cells may include a wired interface configured to receive signals or transmit signals to one or more other cells via a wired transmission medium. Additionally or alternatively, a cell may include a wireless interface that may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) configured to receive signals on a wireless transmission medium or transmit signals to one or more other cells, or both.

[0073] In some aspects, CU 210 can host one or more higher-level control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Serving Data Adaptation Protocol (SDAP), etc. Each control function can be implemented using an interface configured to signal to other control functions hosted by CU 210. CU 210 can be configured to handle user plane functions (e.g., Central Unit-User Plane (CU-UP)), control plane functions (e.g., Central Unit-Control Plane (CU-CP)), or combinations thereof. In some implementations, CU 210 can be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, CU-UP units can communicate bidirectionally with CU-CP units via an interface such as an E1 interface. CU 210 can be implemented to communicate with DU 230 for network control and signaling, as needed.

[0074] DU 230 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RU 240s. In some aspects, DU 230 may host one or more of the Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) at least in part according to functional splits (such as those defined by the 3rd Generation Partnership Project (3GPP). In some aspects, DU 230 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by DU 230 or with control functions hosted by CU 210.

[0075] Lower-layer functionality can be implemented by one or more RU 240s. In some deployments, an RU240 controlled by a DU 230 may correspond to a logical node that hosts RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, or both, based at least in part on functional decomposition (such as lower-layer functional decomposition). In such architectures, the RU 240 may be implemented to handle over-the-air (OTA) communications with one or more UE 104s. In some specific implementations, the real-time and non-real-time aspects of control plane and user plane communications with the RU 240 may be controlled by the corresponding DU 230. In some scenarios, this configuration allows the DU 230 and CU 210 to be implemented in cloud-based RAN architectures such as vRAN architectures.

[0076] SMO framework 205 can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network elements. For non-virtualized network elements, SMO framework 205 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via operation and maintenance interfaces such as the O1 interface. For virtualized network elements, SMO framework 205 can be configured to interact with a cloud computing platform such as Open Cloud (O-Cloud) 290 to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface such as the O2 interface. Such virtualized network elements may include, but are not limited to, CU 210, DU 230, RU 240, and near-RT RIC 225. In some implementations, SMO framework 205 can communicate with hardware aspects of the 4G RAN, such as Open eNB (O-eNB) 211, via the O1 interface. Additionally, in some implementations, SMO framework 205 can communicate directly with one or more RU 240s via the O1 interface. SMO framework 205 may also include a non-RT RIC 215 configured to support the functionality of SMO framework 205.

[0077] The non-RT RIC 215 can be configured to include logical functions that enable non-real-time control and optimization of RAN elements and resources, including artificial intelligence / machine learning (AI / ML) workflows for model training and updates, or policy-based guidance for applications / features in the near-RT RIC 225. The non-RT RIC 215 can be coupled to or communicate with the near-RT RIC 225, such as via an A1 interface. The near-RT RIC 225 can be configured to include logical functions that enable near real-time control and optimization of RAN elements and resources via an interface, such as an E2 interface, through data collection and action, connecting one or more CU 210s, one or more DU 230s, or both, and O-eNBs to the near-RT RIC 225.

[0078] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 225, the non-RT RIC 215 may receive parameters or external enrichment information from an external server. This information can be utilized by the near-RT RIC 225 and may be received from non-network data sources or network functions at the SMO framework 205 or the non-RT RIC 215. In some examples, the non-RT RIC 215 or the near-RT RIC 225 may be configured to modulate RAN behavior or performance. For example, the non-RT RIC 215 may monitor long-term trends and patterns in performance and use AI / ML models to perform corrective actions via the SMO framework 205 (such as reconfiguration via O1) or by creating RAN management policies (such as A1 policies).

[0079] Figure 3 Various aspects of examples BS 102 and UE 104 are described.

[0080] Generally, BS 102 includes various processors (e.g., 320, 330, 338, and 340), antennas 334a-334t (collectively referred to as 334), transceivers 332a-332t (collectively referred to as 332) including modulators and demodulators, and other aspects that enable the wireless transmission of data (e.g., data source 312) and the wireless reception of data (e.g., data sink 339). For example, BS 102 can transmit and receive data between BS 102 and UE 104. BS 102 includes a controller / processor 340 that can be configured to implement the various functions described herein related to wireless communication.

[0081] Generally, UE 104 includes various processors (e.g., 358, 364, 366, and 380), antennas 352a-352r (collectively referred to as 352), transceivers 354a-354r (collectively referred to as 354) including modulators and demodulators, and other aspects that enable the wireless transmission of data (e.g., retrieved from data source 362) and the wireless reception of data (e.g., provided to data sink 360). UE 104 includes a controller / processor 380 that can be configured to implement the various functions described herein related to wireless communication.

[0082] Regarding example downlink transmission, BS 102 includes a transmission processor 320 that can receive data from data source 312 and control information from controller / processor 340. The control information may be for a Physical Broadcast Channel (PBCH), Physical Control Format Indicator Channel (PCFICH), Physical HARQ Indicator Channel (PHICH), Physical Downlink Control Channel (PDCCH), Group Shared PDCCH (GC PDCCH), and / or others. In some examples, this data may be for a Physical Downlink Shared Channel (PDSCH).

[0083] The transmitter processor 320 can process (e.g., encode and symbol map) data and control information to obtain data symbols and control symbols, respectively. The transmitter processor 320 can also generate reference symbols (such as those for the primary synchronization signal (PSS), secondary synchronization signal (SSS), PBCH demodulation reference signal (DMRS), and channel state information reference signal (CSI-RS)).

[0084] The transmit (TX) multiple-input multiple-output (MIMO) processor 330 can perform spatial processing (e.g., pre-decoding) on ​​data symbols, control symbols, and / or reference symbols where applicable, and can provide the output symbol stream to the modulators (MODs) in transceivers 332a-332t. Each modulator in transceivers 332a-332t can process its corresponding output symbol stream to obtain an output sample stream. Each modulator can further process (e.g., convert to analog, amplify, filter, and up-convert) the output sample stream to obtain a downlink signal. The downlink signal from the modulators in transceivers 332a-332t can be transmitted via antennas 334a-334t respectively.

[0085] To receive downlink transmissions, UE 104 includes antennas 352a-352r that receive downlink signals from BS 102 and provide the received signals to demodulators (DEMODs) in transceivers 354a-354r respectively. Each demodulator in transceivers 354a-354r can adjust (e.g., filter, amplify, down-convert, and digitize) the corresponding received signal to obtain an input sample. Each demodulator can further process the input sample to obtain the received symbols.

[0086] The MIMO detector 356 acquires received symbols from all demodulators in transceivers 354a-354r, performs MIMO detection on the received symbols where applicable, and provides the detected symbols. The receive processor 358 can process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide the decoded data for UE 104 to data sink 360, and provide the decoded control information to controller / processor 380.

[0087] Regarding example uplink transmission, UE 104 also includes a transmit processor 364 that receives and processes data from data source 362 (e.g., for PUSCH) and control information from controller / processor 380 (e.g., for Physical Uplink Control Channel (PUCCH)). Transmit processor 364 may also generate reference symbols for reference signals (e.g., for Sounding Reference Signal (SRS)). Symbols from transmit processor 364 may be pre-decoded by TX MIMO processor 366, where applicable, further processed by modulators in transceivers 354a-354r (e.g., for SC-FDM), and transmitted to BS 102.

[0088] At BS 102, uplink signals from UE 104 can be received by antennas 334a-t, processed by demodulators in transceivers 332a-332t, detected by MIMO detector 336 where applicable, and further processed by receiver processor 338 to obtain decoded data and control information transmitted by UE 104. Receiver processor 338 can provide the decoded data to data sink 339 and the decoded control information to controller / processor 340.

[0089] Memory 342 and memory 382 can store data and program code for BS 102 and UE 104, respectively.

[0090] Scheduler 344 can schedule UE to transmit data on the downlink and / or uplink.

[0091] In various respects, BS 102 can be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, "transmitting" can refer to various mechanisms that output data, such as from data source 312, scheduler 344, memory 342, transmit processor 320, controller / processor 340, TX MIMO processor 330, transceiver 332a-332t, antenna 334a-334t, and / or other aspects described herein. Similarly, "receiving" can refer to various mechanisms that acquire data, such as from antenna 334a-334t, transceiver 332a-332t, RX MIMO detector 336, controller / processor 340, receive processor 338, scheduler 344, memory 342, and / or other aspects described herein.

[0092] In various respects, UE 104 can also be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, “transmitting” can refer to various mechanisms that output data, such as from data source 362, memory 382, ​​transmit processor 364, controller / processor 380, TX MIMO processor 366, transceiver 354a-354t, antenna 352a-352t, and / or other aspects described herein. Similarly, “receiving” can refer to various mechanisms that acquire data, such as from antenna 352a-352t, transceiver 354a-354t, RX MIMO detector 356, controller / processor 380, receive processor 358, memory 382, ​​and / or other aspects described herein.

[0093] In some respects, one or more processors may be configured to perform various operations (such as those associated with the methods described herein) and respectively send (output) data to another interface configured to send data or receive (obtain) data from another interface configured to receive data.

[0094] Figure 4A , Figure 4B , Figure 4C and Figure 4D Describes the use of wireless communication networks (such as Figure 1 All aspects of the data structure of the wireless communication network 100.

[0095] Specifically, Figure 4A Figure 400 is an example of the first subframe within a 5G (e.g., 5G NR) frame structure. Figure 4B Figure 430 illustrates an example of a DL channel within a 5G subframe. Figure 4C Figure 450 illustrates an example of the second subframe within a 5G frame structure, and Figure 4D Figure 480 illustrates an example of a UL channel within a 5G subframe.

[0096] Wireless communication systems can utilize Orthogonal Frequency Division Multiplexing (OFDM) with a cyclic prefix (CP) on both the uplink and downlink. Such systems can also support half-duplex operation using Time Division Duplex (TDD). OFDM and Single-Carrier Frequency Division Multiplexing (SC-FDM) will (e.g., as...) Figure 4B and Figure 4D The system bandwidth (as depicted in the text) is divided into multiple orthogonal subcarriers. Each subcarrier can be modulated with data. Modulation symbols can be transmitted in the frequency domain using OFDM and / or in the time domain using SC-FDM.

[0097] Wireless communication frame structures can be frequency division duplex (FDD), where for a specific set of subcarriers, subframes within that set are dedicated to either deep (DL) or ultra-low (UL). Wireless communication frame structures can also be time division duplex (TDD), where for a specific set of subcarriers, subframes within that set are dedicated to both DL and UL.

[0098] exist Figure 4A and Figure 4CIn this example, the wireless communication frame structure is TDD, where D stands for DL, U for UL, and X is flexibly used between DL and UL. The UE can configure the time slot format via the received Slot Format Indicator (SFI) (dynamically configured via DL Control Information (DCI) or semi-statically / statically configured via Radio Resource Control (RRC) signaling). In the depicted example, a 10ms frame is divided into 10 equal-sized 1ms subframes. Each subframe may include one or more time slots. In some examples, each time slot may include 7 or 14 symbols, depending on the time slot format. Subframes may also include micro-slots, which typically have fewer symbols than the entire time slot. Other wireless communication technologies may have different frame structures and / or different channels.

[0099] In some respects, the number of time slots within a subframe is based on the time slot configuration and parameter set. For example, for time slot configuration 0, different parameter sets (μ) 0 to 6 allow 1, 2, 4, 8, 16, 32, and 64 time slots per subframe, respectively. For time slot configuration 1, different parameter sets 0 to 2 allow 2, 4, and 8 time slots per subframe, respectively. Therefore, for time slot configuration 0 and parameter set μ, there are 14 symbols per time slot and 2µ time slots per subframe. The subcarrier spacing and symbol length / duration are functions of the parameter set. The subcarrier spacing can be equal to... kHz, where μ is the parameter set from 0 to 6. Therefore, the parameter set... It has a subcarrier spacing of 15 kHz and a parameter set It has a subcarrier spacing of 960 kHz. The symbol length / duration is negatively correlated with the subcarrier spacing. Figure 4A , Figure 4B , Figure 4C and Figure 4D It provides slot configuration 0 with 14 symbols per slot and parameter set with 4 slots per subframe. Example: The time slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs.

[0100] like Figure 4A , Figure 4B , Figure 4C and Figure 4D As depicted, the resource grid can be used to represent the frame structure. Each time slot includes a resource block (RB) (also known as a physical RB (PRB)) extending for, for example, 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0101] like Figure 4A As illustrated in the example, some REs in the RE carry information for the UE (e.g., Figure 1 and Figure 3The reference (pilot) signal (RS) for the UE (104) may include a demodulation RS (DMRS) and / or a channel state information reference signal (CSI-RS) for channel estimation at the UE. The RS may also include a beam measurement RS (BRS), a beam refinement RS (BRRS), and / or a phase tracking RS (PT-RS).

[0102] Figure 4B Examples of various DL channels within a subframe of a frame are illustrated. The Physical Downlink Control Channel (PDCCH) carries the DCI within one or more Control Channel Elements (CCEs), each CCE comprising, for example, nine RE groups (REGs), each REG comprising, for example, four consecutive REs in an OFDM symbol.

[0103] The Primary Synchronization Signal (PSS) can be located within symbol 2 of a specific subframe of the frame. The PSS is generated by the UE (e.g., Figure 1 and Figure 3 104) is used to determine subframe / symbol timing and physical layer identifier.

[0104] The secondary synchronization signal (SSS) can be located in symbol 4 of a specific subframe of the frame. The SSS is used by the UE to determine the physical layer cell identifier group number and radio frame timing.

[0105] Based on the Physical Layer Identifier and Physical Layer Cell Identifier Group Number, the UE can determine the Physical Cell Identifier (PCI). Based on the PCI, the UE can determine the location of the aforementioned DMRS. The Physical Broadcast Channel (PBCH), carrying the Master Information Block (MIB), can be logically grouped with the PSS and SSS to form a Synchronization Signal (SS) / PBCH block. The MIB provides the System Frame Number (SFN) and the number of Restricted Frames (RBs) in the system bandwidth. The Physical Downlink Shared Channel (PDSCH) carries user data, broadcast system information (such as System Information Blocks (SIBs)) not transmitted via the PBCH, and / or paging messages.

[0106] like Figure 4C As illustrated, some REs in the REs carry DMRS for channel estimation at the base station (indicated as R for a particular configuration, but other DMRS configurations are possible). The UE can transmit DMRS for PUCCH and DMRS for PUSCH. PUSCH DMRS can be transmitted, for example, in the first or second symbol before the PUSCH. PUCCH DMRS can be transmitted in different configurations depending on whether a short or long PUCCH is being transmitted and depending on the specific PUCCH format used. UE104 can transmit a Sounding Reference Signal (SRS). SRS can be transmitted, for example, in the last symbol of a subframe. SRS can have a comb structure, and the UE can transmit SRS on one of the comb teeth. SRS can be used by the base station for channel quality estimation to enable frequency-dependent scheduling of the UL.

[0107] Figure 4D Examples of various UL channels within a subframe of a frame are illustrated. The PUCCH can be located as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), pre-decoding matrix indicators (PMI), rank indicators (RI), and HARQ ACK / NACK feedback. The PUSCH carries data and may additionally be used to carry buffer status reports (BSR), power clearance reports (PHR), and / or UCI.

[0108] Example beam refinement process

[0109] In mmWave systems, beamforming can be important for overcoming high path loss. As described herein, beamforming refers to establishing a link between a BS and a UE, where the two devices form beams corresponding to each other. Both the BS and the UE find at least one sufficient beam to form a communication link. The BS beam and the UE beam form a so-called beampuppet link (BPL). As an example, on a DL, the BS can use a transmit beam, and the UE can use a receive beam corresponding to the transmit beam to receive the transmission. The combination of the transmit beam and the corresponding receive beam can be a BPL.

[0110] As part of beam management, the beam used by the BS and UE must be refined periodically due to changing channel conditions (e.g., due to movement of the UE or other objects). Additionally, the performance of the BPL may suffer from fading due to Doppler spread. Because of the changing channel conditions over time, the BPL should be updated or refined periodically. Therefore, it can be beneficial for the BS and UE to monitor the beam and the new BPL.

[0111] At least one BPL must be established for network access. As described above, new BPLs may need to be discovered later for different purposes. The network may decide to use different BPLs for different channels, or for communicating with different BSs (TRPs), or as a fallback BPL in case an existing BPL fails.

[0112] The UE typically monitors the quality of the BPL, and the network can refine the BPL from time to time.

[0113] Figure 5 Example 500 is illustrated for BPL discovery and refinement. In 5G-NR, P1, P2, and P3 procedures are used for BPL discovery and refinement. The network uses the P1 procedure to enable the discovery of new BPLs. In the P1 procedure, as... Figure 5As illustrated, the BS transmits different symbols of a reference signal, with each beam formed in a different spatial direction, so that it reaches several (e.g., most or all) relevant locations in the cell. In other words, the BS uses different transmit beams in different directions over time to transmit the beams.

[0114] In order to successfully receive at least one symbol of the “P1 signal”, the UE must find a suitable receive beam. It uses the available receive beams and applies different UE beams to search during each occurrence of the periodic P1 signal.

[0115] Once the UE successfully receives a symbol of the P1 signal, it has discovered a BPL. The UE may not want to wait until it has found the optimal UE receive beam, as this could delay subsequent actions. The UE can measure the Reference Signal Received Power (RSRP) and report the symbol index along with the RSRP to the BS. Such reports will typically include the discovery of one or more BPLs.

[0116] In one example, the UE can identify a received signal with a high RSRP. The UE may not know which beam the BS is using to transmit; however, the UE can report to the BS the time it observed a signal with a high RSRP. The BS can receive this report and determine which BS beam the BS used at that given time.

[0117] Then, the BS can provide P2 and P3 procedures to refine the individual BPL. The P2 procedure refines the BS beam of the BPL. For example, the BS can use different BS beams that are spatially close to the BPL to transmit several symbols of the reference signal (the BS uses adjacent beams around the selected beam to perform scanning). In P2, the UE maintains its beam constant. Therefore, when the UE uses the same beam as in the BPL (e.g., ...), Figure 5 (As illustrated in the P2 process). The BS beams used for P2 may differ from those used for P1, as they may be closer together or more focused. The UE can measure the RSRP of each BS beam and indicate the optimal RSRP to the BS.

[0118] The P3 process refines the UE beamforming of BPL (see...). Figure 5 (P3 procedure in the BS). When the BS beam remains constant, the UE uses different receive beams for sweeping (the UE uses adjacent beams to perform the scan). The UE can measure the RSRP of each beam and identify the best UE beam. Afterward, the UE can use the best UE beam for the BPL and report the RSRP to the BS.

[0119] After a timeout, the BS and UE establish several BPLs. When the BS transmits a specific channel or signal, it informs the UE which BPL will be involved, allowing the UE to tune in the correct direction of its receive beam before the signal begins. In this way, each sample of the signal or channel can be received by the UE using the correct receive beam. In one example, the BS may indicate which BPL is involved for the scheduled signal (e.g., SRS, CSI-RS) or channel (e.g., PDSCH, PDCCH, PUSCH, PUCCH). In NR, this information may be referred to as Quasi-Co-location (QCL) indication.

[0120] Two antenna ports are quasi-co-located (QCL) if the properties of a channel that transmits symbols on one antenna port can be inferred from the properties of a channel that transmits symbols on another antenna port. A QCL at least supports beam management functionality, frequency / timing offset estimation functionality, and radio resource management (RRM) functionality.

[0121] The BS can use BPLs that the UE has previously received. The transmit beams for the signal to be transmitted and the previously received signals are all pointing in the same direction, or in a QCL (Quick Response Line). The UE may need a QCL indication (before the signal to be received) so that the UE can use the correct receive beam for each signal or channel. Sometimes some QCL indications may be needed when the BPL for a signal or channel changes, and some QCL indications are needed for each scheduled instance. QCL indications can be sent in downlink control information (DCI) that may be part of the PDCCH channel. Because DCI is needed for control information, it may be expected that the number of bits required to indicate the QCL is not too large. QCLs can be sent in Media Access Control-Control Element (MAC-CE) or Radio Resource Control (RRC) messages.

[0122] As an example, whenever a UE reports that it has received a BS beam with sufficient RSRP and the BS decides to use the BPL in the future, the BS assigns it a BPL tag. Therefore, two BPLs with different BS beams can be associated with different BPL tags. BPLs based on the same BS beam can be associated with the same BPL tag. Thus, according to this example, the tag is a function of the BS beam of the BPL.

[0123] As noted above, wireless systems (such as millimeter-wave (mmW) systems) bring gigabit speeds to cellular networks due to the availability of vast amounts of bandwidth. However, the unique challenge of severe path loss faced by such wireless systems necessitates new technologies such as hybrid beamforming (analog and digital), which are absent in 3G and 4G systems. Hybrid beamforming can enhance the link budget / signal-to-noise ratio (SNR) available during RACH.

[0124] In such systems, Node B (NB) and User Equipment (UE) communicate via active beamforming transmit beams. An active beam can be considered a paired transmit (Tx) and receive (Rx) beam between the NB and UE, carrying data and control channels such as PDSCH, PDCCH, PUSCH, and PUCCH. As noted above, the transmit beam used by the NB for downlink transmission and the corresponding receive beam used by the UE for downlink transmission can be referred to as a beamp-pair link (BPL). Similarly, the transmit beam used by the UE for uplink transmission and the corresponding receive beam used by the NB for uplink transmission can also be referred to as a BPL.

[0125] Since the direction of the reference signal is unknown to the UE, the UE can evaluate several beams to obtain the optimal Rx beam for a given NB Tx beam. However, if the UE must “scan” through all its Rx beams to perform measurements (e.g., to determine the optimal Rx beam for a given NB Tx beam), the UE may incur significant measurement latency and battery life impacts. Furthermore, the resource efficiency of having to scan through all Rx beams is extremely low. Therefore, aspects of this disclosure provide techniques to assist the UE when performing measurements of the serving cell and neighboring cells using Rx beamforming.

[0126] Example Beam Management

[0127] In wireless communication, various processes can be performed for beam management. Figure 6 This is a diagram illustrating an example operation of beam management. In initial access 602, the network can, for example, scan through several beams via a synchronization signal block (SSB), as described in this document. Figure 4B As further described, the network can utilize the Random Access Channel (RACH) resources associated with the beamforming SSB to configure the UE to facilitate initial access via the RACH resources. In some respects, the SSB can have a wider beamform compared to other reference signals, such as the Channel State Information Reference Signal (CSI-RS). The UE can use SSB detection to identify the RACH timing (RO) for transmitting the RACH preamble (e.g., as part of a contention-based random access (CBRA) procedure).

[0128] In connection mode 604, the network and UE can perform hierarchical beam refinement, which includes beam selection (e.g., a process referred to as P1), beam refinement for the transmitter (e.g., a process referred to as P2), and beam refinement for the receiver (e.g., a process referred to as P3). For example, in beam selection (P1), the network can scan through beams, and the UE can report the beam with the best channel properties. In beam refinement for the transmitter (P2), the network can scan through narrower beams, and the UE can report the beam with the best channel properties among the narrow beams. In beam refinement for the receiver (P3), the network can repeatedly use the same beam for transmission, and the UE can refine spatial reception parameters (e.g., spatial filters) for receiving signals from the network via the beam. In some aspects, the network and UE can perform complementary processes (e.g., U1, U2, and U3) for uplink beam management.

[0129] In certain cases where a beam fault occurs (e.g., due to beam misalignment and / or obstruction), the UE may perform a beam fault recovery (BFR) procedure 606, which allows the UE to return to connected mode 604 without performing a radio link failure procedure 608. For example, the UE may be configured using candidate beams for beam fault recovery. In response to detecting a beam fault, the UE may request the network to perform beam fault recovery via one of the candidate beams (e.g., a candidate beam with a reference signal received power (RSRP) above a certain threshold). In certain cases where a radio link failure (RLF) occurs, the UE may perform an RLF procedure 608 (e.g., a RACH procedure) to recover from the radio link failure.

[0130] Example framework for AI / ML in radio access networks

[0131] Figure 7 An example of an AI / ML functional framework 700 for RAN intelligence is depicted, in which the aspects described herein can be implemented.

[0132] The AI / ML functional framework includes data collection function 702, model training function 704, model inference function 706, and participant function 708. These functions interoperate to provide a platform for collaboratively applying AI / ML to various processes in RAN.

[0133] Data collection function 702 typically provides input data to model training function 704 and model inference function 706. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting and transformation) may not be performed in data collection function 702.

[0134] Examples of input data to data collection function 702 (or other functions) may include measurements from the UE or different network entities, feedback from participant functions, and outputs from AI / ML models. In some cases, data analysis required at model training function 704 and model inference function 706 may be performed at data collection function 702. As illustrated, data collection function 702 may deliver training data to model training function 704 and inference data to model inference function 706.

[0135] The model training function 704 can perform AI / ML model training, validation, and testing, which can generate model performance metrics as part of the model testing process. If needed, the model training function 704 can also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the training data delivered by the data collection function 702.

[0136] The model training function 704 can provide model deployment / update data to the model interface function 706. The model deployment / update data can be used to initially deploy trained, validated, or tested AI / ML models to the model inference function 706 or to deliver updated models to the model inference function 706.

[0137] As illustrated, model inference function 706 may provide AI / ML model inference output (e.g., prediction or decision) to participant function 708, and may sometimes provide model performance feedback to model training function 704. Model inference function 706 may also sometimes be responsible for data preparation (e.g., data preprocessing and cleaning, formatting and transformation) based on inference data delivered by data collection function 702.

[0138] The inference output of the AI / ML model can be generated by the model inference function 706. The specific details of this output can be specific in terms of use cases. Sometimes, model performance feedback can be used to monitor the performance of the AI / ML model. In some cases, for example, if certain information derived from the model inference function is applicable to improving the AI / ML model trained in the model training function 704, model performance feedback can be delivered to the model training function 704.

[0139] Model inference function 706 can signal the model's output to nodes that have requested the model's output (e.g., via subscription) or to nodes that take action based on the output from the model inference function. Before deployment, the AI / ML model used in model inference function 706 may need to be initially trained, validated, and tested by model training function. Model training function 704 and model inference function 706 can request specific information that will be used to train or execute AI / ML algorithms and avoid receiving unnecessary information. The nature of such information can depend on the use case and the AI / ML algorithm.

[0140] Participant function 708 can receive output from model inference function 706, which can trigger or execute corresponding actions. Participant function 708 can trigger actions against other entities or against itself. Feedback generated by participant function 708 can provide information for deriving training data, inference data, or for monitoring the performance of AI / ML models. As noted above, input data for data collection function 702 may include this feedback from participant function 708. Feedback from participant function 708 or other network entities (e.g., via data collection functions) can also be used at model inference function 706.

[0141] The AI / ML functional framework 700 can be deployed in a variety of RAN intelligence-based use cases. Such use cases can include CSI feedback enhancement, enhanced beam management (BM), positioning and location (Pos-Loc) accuracy enhancement, and a variety of other use cases.

[0142] Aspects related to target beam identification used for temporal beam prediction

[0143] As noted above, certain mobility procedures can be in place to help maintain the UE's network connectivity when it moves between coverage areas of different cells. For example, such mobility procedures can allow the UE to switch from service from a source cell to service from a target cell. With LTM, when the UE moves, a new serving cell (e.g., primary cell (Pcell) can be selected (e.g., reselected) from the set of cells based on L1 measurements for pre-configured candidate cells. LTM procedures can provide improved robustness against blocking, higher rank opportunities for improvements across different cells, and reduced latency across different cells.

[0144] In some cases, a large number of reference signals (RS) may be monitored in LTM candidate cells. In order for network entities (e.g., gNBs) to dynamically signal updates about which RSs should be monitored, the complexity and / or overhead may increase and may become excessive as the number of RSs increases.

[0145] Figure 8The target scenario involving LTM is described. For example, as a UE moves within LTM candidate cell 810, network entities (e.g., the UE or gNB) can use AI / ML to determine, recommend, and / or report certain information. For example, such as... Figure 8 As illustrated in Objective-1, AI / ML can be used to determine / recommend / report whether monitoring / reporting of RS for LTM candidate cells is triggered. For example... Figure 8 As illustrated in Objective-2, AI / ML can also be used to determine / recommend / report which LTM candidate cells (set 820) the UE should monitor / report (e.g., based on the UE's location relative to the candidate cells). Figure 8 As illustrated in Objective-3, AI / ML can also be used to determine / recommend / report which RS / beams 830 to monitor / report (e.g., within the set of LTM candidate cells 820), and / or when / how to report the quality of the monitored beams. In the illustrated example, shading (filling) indicates the RS / beams that have been selected for monitoring / reporting.

[0146] AI / ML-based LTM can offer certain advantages. For example, from the UE's perspective, it can reduce power consumption for mobility. From the network's perspective (e.g., when the UE does not report / recommend certain information), less dynamic signaling may be needed to reconfigure RS measurements.

[0147] Various aspects related to Time Default Sending Configuration Indicator (TCI) state prediction in LTM

[0148] As noted above, when a UE needs to hand over to an LTM target cell (e.g., due to mobility), potential obstructions in the target cell can be identified / predicted by one or more network entities (e.g., based on NW-side beam prediction or infrastructure-side RF / LiDAR / camera sensing). For example, due to mobility, a UE may have to detach from the source cell and hand over to the LTM target cell. In such cases, the UE may have already identified its preferred beam in the target cell and notified the source cell before the handover. The source cell can also notify the target cell of such beam preferences.

[0149] However, potential obstructions may affect the UE's preferred beam in the target cell for some duration after the UE has switched to the target cell (e.g., tens or hundreds of ms due to vehicle or pedestrian movement), and the UE may not have identified / predicted potential obstructions in advance (e.g., due to limited HW / processing capabilities, limited transmit power for RF sensing, or limited field of view (FoV) for visually assisted obstruction detection).

[0150] Figure 9An example scenario 900 involving obstruction in an LTM deployment is depicted. As illustrated at 902, the UE may be served by a serving beam in one or more source cells. As illustrated at 904, due to UE mobility, the UE may need to hand over from one or more source cells to one or more target cells. However, an impending obstruction (indicated at 906) may block the UE's preferred beam in the target cell (indicated at 908). As noted above, obstruction can be predicted / identified based on UE / NW-side beam prediction and infrastructure-side RF / LiDAR / camera sensing (e.g., based on over-the-air (OTA) ray tracing).

[0151] Various aspects of this disclosure provide techniques for additional network and / or UE-based time prediction of default and alternative future TCI states (e.g., corresponding beams) in a target cell. For example, default and alternative future TCI states (e.g., corresponding beams) in a target cell can be predicted (e.g., for multiple future time points) for use during potential UE / network blocking. Such predictions can be used to determine the optimal action for a particular scenario. For example, in some cases, if an alternative beam cannot be identified during the blocking period (e.g., if the blocking party causes complete overall coverage), it may be better to remain in the source cell for a certain duration (e.g., because lower throughput may be better than zero throughput).

[0152] As noted above, non-ideal backhaul between the source and target cells (e.g., backhaul latency) can cause the UE's preferred beam in the target cell (e.g., which may be notified by the source cell) to become outdated (ineffective) after the UE has already switched to the target cell. Non-ideal backhaul between the source and target cells (e.g., backhaul latency) can be caused by variable end-to-end (E2E) latency, variable traffic load, and associated packet queuing in the backhaul between the source and target cells. Depending on the traffic load, such backhaul latency can vary significantly (e.g., from several milliseconds to hundreds of milliseconds).

[0153] If such backhaul delay is too large (e.g., greater than a threshold), the UE's preferred beam in the target cell (e.g., the preferred beam that the source cell can report to the target cell) may become obsolete (e.g., no longer preferred) when the UE has already switched to the target cell.

[0154] For reference Figure 10A To understand this scenario, see example timing diagram 1000. As illustrated at 1002, when the backhaul latency is relatively short (e.g., about 20 ms), the preferred beam for the UE (e.g., in the target cell) can be determined based on real-time measurements.

[0155] However, as illustrated at 1004, for non-ideal backhaul, the backhaul delay can vary greatly and may be long enough (e.g., 80ms-320ms) to make the preferred beam of the UE in the target cell (e.g., which may be notified by the source cell) obsolete (no longer preferred) when the UE has already switched to the target cell.

[0156] As illustrated at 1006, in some aspects, the preferred beam for the UE for such long backhaul delays (e.g., 80ms-320ms) can be predicted by the UE or by the source cell to compensate for the long backhaul delay. In such cases, the source cell can notify the target cell of the UE's preferred beam.

[0157] As noted above, aspects of this disclosure can provide additional network and / or UE-based timing prediction techniques for default and alternative future TCI states (e.g., corresponding beams) in a target cell. For example, default and alternative future TCI states (e.g., corresponding beams) in a target cell can be predicted to compensate for non-ideal backhaul delays. These predicted TCI states can be used to help facilitate the handover of the UE to one of the target cells (e.g., the predicted beams can be used to transmit / receive uplink and / or downlink transmissions in the target cell).

[0158] Depending on the prior distribution of the non-ideal backhaul delay, the UE or source cell may need to predict the preferred beam in the target cell for multiple future time points. In some cases, for example, the non-ideal backhaul delay may follow a Poisson distribution, which can be represented by the following equation: ms.

[0159] To prevent or compensate for long delays when delivering the UE to the preferred beam in the target cell (where the final delay may be uncertain), the UE and / or network can predict the timing of events at multiple future times (e.g., up to 100,000). The preferred beam for the future (after ms).

[0160] Such predicted future preferred beams can be signaled (reported) from the source cell to the target cell. Depending on when information about such target beams (e.g., along with other LTM notifications) is ultimately delivered to the target cell, the UE may be able to receive PDCCH / PDSCH from the target cell via an appropriately selected beam.

[0161] Additional signaling (or signaling support) is referenced above. Figure 9 In the described obstruction scenario and in the references above Figure 10AThis could be beneficial in the described non-ideal backhaul latency scenarios. For example, in some aspects, a series of beam / TCI state predictions about various future time points in the target cell can be reported to the source cell before the UE finally hands over to the target cell (e.g., and the source cell can forward such predictions to the target cell).

[0162] As noted above, in potential obstruction scenarios, the prediction results can be used to identify alternative beams to be used in the target cell during the period when the optimal beam is identified / predicted to be obstructed.

[0163] As noted above, in scenarios with non-ideal backhaul latency, the prediction results can be used to prepare for various potential moments when such results can be delivered to the target cell.

[0164] In some aspects, for potential obstruction scenarios and / or non-ideal backhaul latency scenarios, such as when obstruction is predicted or when non-ideal backhaul latency instability is recently observed, the network / gNB may signal the timing associated with the prediction (e.g., beam / TCI state prediction results). In other aspects, the UE may independently determine / report such timing (e.g., when the UE has already predicted obstruction).

[0165] In some cases, such beam / TCI state prediction results can be delivered to the target cell along with other cell handover information from the source cell. Once this information is delivered to the target cell, the target cell can begin transmitting PDCCH according to the UE's predicted beam sequence during the corresponding time period.

[0166] Once the UE needs to search / monitor the PDCCH in the target cell, it can adaptively identify the Type D-QCL (spatial filtering) assumptions associated with its reported beam preferences at different future times. For potential obstruction scenarios, when the potential obstruction does not cause severe coverage problems (e.g., coverage impact exceeds a threshold), such Type D-QCL sequences can be rewritten by dynamic TCI state handover commands in the target cell. In some respects, such predictions can be performed at the source cell, and the prediction results can be sent to both the UE and the target cell (and used to assist handover).

[0167] Temporal beam prediction can be used selectively only in certain situations. For example, in some cases, the probability of extremely long backhaul delays may be small, and temporal beam prediction for the (e.g., distant) future may have excessively high computational complexity. Therefore, in some respects, the source cell can signal the UE to the recently observed backhaul delay distribution, thereby allowing the UE more flexibility in determining whether to (e.g., or not) predict beams for the (distant) future.

[0168] For reference Figure 10B Example timing diagram 1050 is used to understand potential obstruction scenarios (e.g., referenced above). Figure 9 Potential use of preferred beams in the described scenario.

[0169] As noted above, the UE may additionally report its predictions regarding the time beam / TCI state of its source cell. In such cases, the network (e.g., gNB) may decide whether to temporarily hold / delay the cell handover until the obstruction / obstructor passes through the target cell, or decide whether to continue the LTM handover and use an alternative beam in the target cell.

[0170] For example, as illustrated at 1052, the beam associated with the source cell may be preferred in the early part of the predicted blocking period / duration. However, as illustrated at 1054, the non-blocking beam associated with the target cell may be preferred in the later part of the predicted blocking period / duration. For example, at a first timing, the first beam (beam #1 at the source cell) may be preferred. At a second timing, the second beam (beam #2 at the target cell) may be preferred because it is not (e.g., is predicted to) be blocked. As illustrated, at the third and fourth timings, the fifth beam (beam #5 at the target cell) may be preferred.

[0171] Figure 10B Timing diagram 1050 is used as an illustrative example and is not intended to be limiting. In some cases, for example, the beam at the source cell (or the beam at the target cell) may be preferred for the entire blocking period / duration. In some cases, for example, the non-blocking beam associated with the target cell may be preferred in the early part of the predicted blocking period / duration, and the beam associated with the source cell may be preferred in the late part of the predicted blocking period / duration (but this example may incur additional signaling overhead for LTM handover to the target cell and return to the original source cell).

[0172] In some cases, such as when potential obstruction has been identified / predicted, the BFR process can be temporarily disabled in the target cell to reduce UE power consumption. In other cases, the prediction results can be used by the network to remove beams identified / predicted as obstructed in the target cell (e.g., when obstruction is identified / predicted by the network / infrastructure).

[0173] Figure 11 A call flow diagram 1100 illustrating a UE-based time prediction according to certain aspects of this disclosure is depicted.

[0174] In some respects, Figure 11 and Figure 17 The UE shown can be about Figure 1 and Figure 3Examples of UE 104 depicted and described. In some respects, Figure 11 and Figure 17 The source cell and / or target cell shown can be about Figure 1 and Figure 3 The BS 102 (e.g., gNB) depicted and described or related to Figure 2 Examples of decomposed base stations depicted and described.

[0175] As illustrated at 1102, one or more network entities (e.g., gNBs associated with one or more source cells) can configure a set of candidate cells for the UE for LTM.

[0176] As illustrated, the source cell can send an LTM handover command to indicate the target cell to which the UE should hand over. As illustrated at 1104, the source cell can also send a request for the UE to report the time beam / TCI state prediction results (e.g., it can be sent in MAC-CE along with the LTM handover command).

[0177] As illustrated at 1106, in response to this request, the UE can detect / receive / measure RS from one or more target cells and can perform time beam prediction based on RS. As illustrated at 1108, the UE can report the time beam / TCI state prediction results to the source cell.

[0178] As illustrated at location 1110, the source cell can send time beam / TCI state prediction results and LTM handover information to one or more target cells via backhaul.

[0179] As illustrated at 1112, the UE can process communications associated with the target cell based on the time beam / TCI state prediction results. For example, the UE can process PDCCH transmissions based on the time beam / TCI state prediction results.

[0180] Requests to report time beam prediction results may be transmitted along with the LTM handover command or separately. In some aspects, after the UE receives the LTM cell handover command (e.g., via MAC-CE), the source cell may further request the UE to report the strongest SSB / CSI-RS among one or more candidate SSB / CSI-RS associated with the source cell (e.g., in a potential obstruction scenario) or the target cell (e.g., for a potential obstruction scenario or a non-ideal backhaul delay scenario) for a range of future TD windows. This technique is particularly applicable to potential obstruction scenarios, where the potential obstruction is identified after the cell handover command has been transmitted (but this technique is also applicable to other scenarios, such as non-ideal backhaul delay scenarios).

[0181] According to certain aspects of this disclosure, the UE may start a timer after receiving an LTM cell handover MAC-CE command (e.g., after the UE has transmitted a prediction result), such that when the timer expires, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or transmitting the PUSCH in the target cell. In some aspects, such a timer may be defined by certain wireless communication standards (e.g., 3GPP) or may be configured by the network.

[0182] In some respects, unless the UE receives a separate TCI state switching command from the target cell for rewriting such a default QCL, the default QCL associated with such a channel in the target cell (e.g., Type D-QCL) can be determined based on the strongest SSB / CSI-RS reported during the corresponding TD window.

[0183] Figure 12 Example timing diagram 1200 depicts a UE-based time prediction in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0184] As illustrated at 1202, a UE may send an LTM L1 report to one or more source cells. The report may be based on RS measurements of the target candidate cells. The network (e.g., the serving source cell) may make a handover decision based on the LTM L1 report.

[0185] As illustrated at location 1204, the source cell can send a cell handover command to the UE, which can be based on the LTML1 report and may include TCI state assumptions in the target cell.

[0186] As illustrated at 1206, blocking can be identified by a network / infrastructure entity. As illustrated at 1208, the source cell can request time prediction results from the UE. In some aspects, this request can indicate restrictions on candidate beams. For example, such restrictions can exclude beams predicted / identified as blocked in candidate cells and / or include only the currently serving beam in the source cell.

[0187] As illustrated at 1210, the UE can perform time beam / TCI state prediction and can send the time prediction results to the source cell. As illustrated at 1212, the source cell can send / forward the beam / TCI state prediction results (e.g., handover information with other cells) to the target cell via backhaul.

[0188] As illustrated at 1214, in some cases, the UE may start a timer after receiving an LTM cell handover command (e.g., or after the UE has transmitted a prediction result). As illustrated, when the timer expires and / or the cell handover is complete, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or transmitting the PUSCH in the target cell (e.g., during the identification / predicted blocking period of the preferred beam in the target cell). As illustrated, unless the UE receives a separate TCI state handover command from the target cell for rewriting such a default QCL, the default TCI state used for communicating with the target cell may be based on the beam reported by the UE.

[0189] Figure 13 Another example timing diagram 1300 depicts a UE-based time prediction in a potential obstruction scenario that illustrates certain aspects of this disclosure.

[0190] In some respects, as illustrated at 1302, the request for time prediction can be received directly from the LTM cell handover MAC-CE command (e.g., both the LTM cell handover command and the request can be included in a single MAC-CE). This may be applicable, for example, when a potential obstruction has been identified before the cell handover command is transmitted, and when the UE must be handed over to a target cell due to UE mobility. It may also be applicable, for example, when a potential long backhaul delay has been identified before the cell handover command is transmitted.

[0191] Figure 14 Timing diagram 1400 depicts a UE-based time prediction in a non-ideal backhaul latency scenario with relatively short actual latency, exemplified by certain aspects of this disclosure.

[0192] As illustrated at 1402, the UE may send an LTM L1 report to one or more source cells. As illustrated at 1404, the source cell may send a cell handover command to the UE (e.g., which may include TCI state assumptions in the target cell and a request for time beam / TCI state prediction results). As illustrated at 1406, the UE may perform time beam / TCI state prediction and may send the time prediction results to the source cell. As illustrated at 1408, the source cell may send / forward the beam / TCI state prediction results (e.g., along with other cell handover information) to the target cell via backhaul. As illustrated at 1410, the UE may start a timer after receiving an LTM cell handover command (e.g., or after the UE has already transmitted the prediction results).

[0193] As illustrated at 1412, when the timer expires and / or the cell handover is complete, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or transmitting the PUSCH in the target cell. The default TCI state for communication in the target cell may be based on the beam reported / predicted by the UE, unless / until the target cell provides an update / command. As illustrated at 1414, for example, the target cell may control TCI state updates. In other words, for example, in scenarios with relatively short actual latency, the predicted future TCI state may not be used.

[0194] Figure 15 A timing diagram 1500 based on UE time prediction is depicted in a non-ideal backhaul latency scenario with a relatively long actual latency according to certain aspects of this disclosure.

[0195] As illustrated at 1502, the UE may send an LTM L1 report to one or more source cells. As illustrated at 1504, the source cell may send a cell handover command to the UE (e.g., which may include TCI state assumptions in the target cell and a request for time beam / TCI state prediction results). As illustrated at 1506, the UE may perform time beam / TCI state prediction and may send the time prediction results to the source cell. As illustrated at 1508, the source cell may send / forward the beam / TCI state prediction results (e.g., along with other cell handover information) to the target cell via backhaul. As illustrated at 1510, the UE may start a timer after receiving an LTM cell handover command (e.g., or after the UE has already transmitted the prediction results).

[0196] As illustrated at 1512, when the timer expires and / or the cell handover is completed, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or sending the PUSCH in the target cell.

[0197] As illustrated at 1514, throughput may be interrupted when the target cell does not know the preferred beam of the UE in the target cell (e.g., due to actual long backhaul delay).

[0198] The default TCI state for communication in the target cell may be based on the beam reported / predicted by the UE, unless / until the target cell provides an update / command. As illustrated at 1516, for example, the target cell may control the TCI state updates. In other words, if the target cell provides a TCI state update that overrides the predicted default TCI state, the predicted future TCI state may not be used.

[0199] In some aspects, the time beam / TCI state prediction results may include the strongest SSB / CSI-RS ID associated with the corresponding future time window, which may be requested by the network. In some aspects, reserved locations (e.g., via certain wireless communication standards) may be predefined to indicate that no prediction is given for certain future time windows / opportunities. For example, due to limited UE computing resources and / or the low probability (e.g., less than the configured threshold) of long (e.g., exceeding a configured threshold) backhaul delays from network guidance / instruction (e.g., due to low severity of obstruction), the UE may prefer not to make predictions for such time windows.

[0200] For such unpredictable windows, the associated default QCL during such a window in the target cell can be predefined based on neighboring and previously predicted windows. In some cases, the associated default QCL during such a window in the target cell can be based on the UE's preferred beam (e.g., it can be indicated by the LTM cell handover MAC-CE command).

[0201] In some respects, the time beam / TCI state prediction results may include other UE auxiliary information. For example, in some respects, the time beam / TCI state prediction results may indicate the UE's expected direction of movement, positioning, and / or location. In some respects, the time beam / TCI state prediction results may indicate the UE's predicted obstruction information (e.g., obstruction severity, obstruction duration, etc.).

[0202] Figure 16 Example timing prediction results reported by a UE according to certain aspects of this disclosure are depicted. As illustrated, the timing beam / TCI state prediction results may include preferred beams for various timings. However, as illustrated at timing 1602, the timing prediction results may not include preferred beams for certain timings (e.g., to reduce power consumption and / or computational complexity).

[0203] As noted above, in some cases, the probability of extremely long backhaul delays may be very small, and beam prediction for (e.g., distant) future times may have excessively high computational complexity. Therefore, in some respects, the source cell can signal the UE to the recently observed backhaul delay distribution, allowing the UE more flexibility in determining whether (e.g., whether or not) to predict beams for the (distant) future. In other respects, the UE may prefer not to predict beams for certain (distant) future times.

[0204] Figure 17 A call flowchart 1700 illustrating network-based time prediction according to certain aspects of this disclosure is depicted. Figure 17 The call flowchart 1700 is similar to Figure 11The call flow diagram is 1100, but time beam prediction is performed on the network side rather than on the UE side.

[0205] As illustrated at 1702, one or more network entities (e.g., gNBs associated with one or more source cells) can configure a set of candidate cells for the UE for LTM.

[0206] As illustrated at location 1704, the source cell can detect / receive / measure RS from one or more target cells and can perform time beam prediction based on RS.

[0207] As illustrated, the source cell can send an LTM handover command to indicate the target cell the UE wants to hand over to. As illustrated at 1706, the source cell can report the time beam / TCI state prediction results to the UE. In some cases, for example, the report and the LTM handover command can be sent together in the MAC-CE.

[0208] As illustrated in location 1708, the source cell can send time beam / TCI state prediction results and LTM handover information to one or more target cells via backhaul.

[0209] As illustrated at 1710, the UE can process communications associated with the target cell based on the time beam / TCI state prediction results.

[0210] According to certain aspects of this disclosure, after the UE receives an LTM cell handover command (e.g., via MAC-CE), the UE may receive one or more default TCI state assumptions about a series of future TD windows from the source cell (respectively).

[0211] This technology is particularly suitable for potential obstruction scenarios, where the obstruction is identified after the cell handover command has been transmitted (but it is also suitable for other scenarios, such as non-ideal backhaul latency scenarios).

[0212] According to certain aspects of this disclosure, the UE may start a timer after receiving an LTM cell handover MAC-CE command (e.g., after the UE has received default TCI state assumption information), such that when the timer expires, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or transmitting the PUSCH in the target cell. In some aspects, such a timer may be defined by certain wireless communication standards (e.g., 3GPP) or may be configured by the network.

[0213] In some respects, unless the UE receives a separate TCI state switching command from the target cell for rewriting such a default QCL, the UE can determine the TCI state in the target cell during the corresponding TD window based on such gNB indications of default TCI state assumption information.

[0214] Figure 18 A timing diagram 1800 based on network time prediction is depicted in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0215] As illustrated at 1802, the UE may send an LTM L1 report to one or more source cells. As illustrated at 1804, the source cell may send a cell handover command to the UE (e.g., which may include TCI state assumptions in the target cell). As illustrated at 1806, the blockage may be identified by a network / infrastructure entity.

[0216] As illustrated at 1808, the source cell can perform time beam / TCI state prediction and can send the time prediction result to the UE. As illustrated at 1810, the source cell can also send the beam / TCI state prediction result (e.g., handover information with other cells) to the target cell via backhaul. As illustrated at 1812, the UE can start a timer after receiving an LTM cell handover command (e.g., after the UE has received the prediction result or after the UE has initiated a cell handover).

[0217] As illustrated at 1814, when the timer expires and / or the cell handover is complete, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or transmitting the PUSCH in the target cell (e.g., during the identification / predicted blocking period of the preferred beam in the target cell). As illustrated, unless the UE receives a separate TCI state switching command from the target cell for rewriting such a default QCL, the default TCI state used for communicating with the target cell may be based on the reported / indicated beam.

[0218] Figure 19 A timing diagram 1900 based on network time prediction is depicted in a potential obstruction scenario exemplified by certain aspects of this disclosure.

[0219] In some respects, as illustrated at 1902, certain information (e.g., predictions of time beam / TCI state for a series of future TD windows and / or default TCI state assumptions) can be received directly in the LTM cell handover command (e.g., this information can be received together with the LTM cell handover command in a single MAC-CE). This may be applicable, for example, when potential obstructions have been identified before transmitting the cell handover command, and when the UE must be handed over to the target cell due to UE mobility. This may also be applicable, for example, when potential long backhaul delays have been identified before transmitting the cell handover command.

[0220] Figure 20 Timing diagram 2000 depicts a network-based time prediction in a non-ideal backhaul delay scenario, illustrating certain aspects of this disclosure.

[0221] As illustrated in section 2002, the UE may send an LTM L1 report to one or more source cells. As illustrated in section 2004, the source cell may perform time beam / TCI state prediction and may send a cell handover command to the UE (e.g., which may include TCI state assumptions and / or time beam / TCI state prediction results in the target cell). As illustrated in section 2006, the source cell may send time prediction results (e.g., along with other cell handover information) to the target cell via backhaul. As illustrated in section 2008, the UE may start a timer after receiving an LTM cell handover command (e.g., after the UE has received the prediction results or after the UE has initiated a cell handover).

[0222] As illustrated in section 2010, when the timer expires and / or the cell handover is complete, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or transmitting the PUSCH in the target cell. The default TCI state for communication in the target cell may be based on the beam reported / predicted by the gNB, unless / until the target cell provides an update / command. As illustrated in section 2012, for example, the target cell may control TCI state updates. In other words, for example, in scenarios with relatively short actual latency, the predicted future TCI state may not be used.

[0223] Figure 21 Timing diagram 2100 depicts a network-based time prediction in a non-ideal backhaul delay scenario exemplified by certain aspects of this disclosure.

[0224] As illustrated at 2102, the UE may send an LTM L1 report to one or more source cells. As illustrated at 2104, the source cell may perform time beam / TCI state prediction and may send a cell handover command to the UE (e.g., which may include TCI state assumptions in the target cell and / or time beam / TCI state prediction results). As illustrated at 2106, the source cell may send the time prediction results (e.g., and other cell handover information) to the target cell via backhaul. As illustrated at 2108, the UE may start a timer after receiving an LTM cell handover command (e.g., after the UE has received the prediction results or after initiating a cell handover).

[0225] As illustrated at 2110, when the timer expires and / or the cell handover is completed, the UE may begin monitoring the PDCCH, receiving the PDSCH, and / or sending the PUSCH in the target cell.

[0226] As illustrated at 2112, throughput may be interrupted when the target cell does not know the preferred beam of the UE in the target cell (e.g., due to actual long backhaul delay).

[0227] The default TCI state for communication in the target cell may be based on the beam reported / predicted by the gNB, unless / until the target cell provides an update / command. As illustrated at 2114, for example, the target cell may control the TCI state updates. In other words, if the target cell provides a TCI state update that overrides the predicted default TCI state, the predicted future TCI state may not be used.

[0228] In some respects, the time beam / TCI state prediction results indicated from the source cell may include the strongest SSB / CSI-RS ID associated with the corresponding future time window. Such future time windows may also be indicated by the time prediction results, or they may be indicated separately (e.g., via RRC from the LTM configuration with respect to the target cell, or via separate MAC-CE / DCI).

[0229] In some respects, the time beam / TCI state prediction results indicated from the source cell can also indicate whether UE-side time prediction is needed / requested (e.g., or may be beneficial). In some respects, the time beam / TCI state prediction results indicated from the source cell can be used as confirmation of (e.g., or modification / replacement) of prediction results reported by the UE.

[0230] Figure 22 Example time prediction results reported by a network (e.g., a source cell) according to certain aspects of this disclosure are depicted. As illustrated, the time beam / TCI state prediction results may include preferred beams for various times. However, as illustrated at time 2202, the time prediction results may not include preferred beams for certain times (e.g., to reduce power consumption and / or computational complexity).

[0231] As noted above, in some cases, the probability of extremely long backhaul delays may be very small, and beam prediction for (e.g., distant) future times may have excessively high computational complexity. Therefore, in some respects, the source cell may decide not to predict beams for certain (distant) future times. Similarly, in some respects, the source cell may signal the UE to the recently observed backhaul delay distribution, thereby allowing the UE more flexibility in determining whether to (e.g., or not to) predict beams for the (distant) future.

[0232] Example Operation

[0233] Figure 23 This illustrates the use of user equipment (UE) such as Figure 1 and Figure 3 An example of a method 2300 for wireless communication at UE 104.

[0234] Method 2300 begins at step 2305: Information is obtained to configure a set of candidate cells for the user equipment, wherein the user equipment supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells. In some cases, this step refers to the operation as described in reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0235] Method 2300 then proceeds to step 2310: obtaining a command instructing the UE to hand over from one or more source cells to one or more target cells in the candidate cell set. In some cases, this step refers to the operation as described in reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0236] Method 2300 then proceeds to step 2315: obtaining a request for the time beam prediction results. In some cases, this step refers to the operation as described in the reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0237] Method 2300 then proceeds to step 2320: outputting a report including the time beam prediction results for transmission. In some cases, this step refers to the operation as described in the reference... Figure 27 The circuitry described for output and / or the code for output, or the circuitry and / or the code that can be executed.

[0238] Method 2300 then proceeds to step 2325: after receiving the request, processing at least one communication associated with one or more target cells in the target cells based on the time beam prediction results. In some cases, the operation of this step involves, as referenced... Figure 27 The circuitry and / or code described for processing, or that can be executed by the circuitry and / or the code.

[0239] In some respects, at least one of the commands or requests is obtained via a Media Access Control (MAC) control element (CE).

[0240] In some respects, the request is obtained after the command has been received.

[0241] In some respects, requests and commands are obtained through the same MAC CE.

[0242] In some respects, time beam prediction results are based on predicted values ​​of measurements of reference signals (RS) associated with at least one or more target cells in the target cell.

[0243] In some respects, RS includes at least one of Channel State Information (CSI) RS or Synchronization Signal Block (SSB).

[0244] In some respects, at least one communication in one or more target cells includes at least one of the following: transmission of a physical downlink control channel (PDCCH); transmission of a physical downlink shared channel (PDSCH); or transmission of a physical uplink shared channel (PUSCH).

[0245] In some aspects, processing is based on default spatial quasi-co-location (QCL) information, which is determined based on beam prediction results.

[0246] In some respects, method 2300 also includes another command for obtaining the default space QCL information. In some cases, this step refers to the operation as described in the reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0247] In some respects, at least one communication is processed after a duration following the receipt of a command, wherein the duration is based on a timer started after the command is received.

[0248] In one aspect, method 2300 or any aspect thereof may be made by means of a device (such as...) Figure 27 The communication device 2700 is used to perform the method 2300, which includes various components capable of operating, being configured, or adapted to perform the method. The communication device 2700 is described in more detail below.

[0249] It should be noted that Figure 23 This is merely one example of a method, and other methods that include fewer, additional, or alternative steps may also be consistent with this disclosure.

[0250] Figure 24 This illustrates the use of user equipment (UE) such as Figure 1 and Figure 3 An example of a method 2400 for wireless communication at UE 104.

[0251] Method 2400 begins at step 2405: Information is obtained to configure a set of candidate cells for the user equipment, wherein the user equipment supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells. In some cases, this step refers to the operation as described in reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0252] Method 2400 then proceeds to step 2410: obtaining a command instructing the UE to hand over from one or more source cells to one or more target cells in the candidate cell set. In some cases, this step refers to the operation as described in reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0253] Method 2400 then proceeds to step 2415: obtaining the time beam prediction result. In some cases, this step refers to the operation as described in the reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0254] Method 2400 then proceeds to step 2420: after receiving the command, at least one communication associated with one or more target cells in the target cells is processed based on the time beam prediction results. In some cases, the operation of this step involves, as referenced... Figure 27 The circuitry and / or code described for processing, or that can be executed by the circuitry and / or the code.

[0255] In some respects, at least one of the command or time beam prediction results is obtained via a Media Access Control (MAC) control element (CE).

[0256] In some respects, time beam prediction results are obtained after receiving the command.

[0257] In some respects, the time beam prediction results and commands are obtained via the same MAC CE.

[0258] In some respects, at least one communication in one or more target cells includes at least one of the following: transmission of a physical downlink control channel (PDCCH); transmission of a physical downlink shared channel (PDSCH); or transmission of a physical uplink shared channel (PUSCH).

[0259] In some aspects, processing is based on default spatial quasi-co-location (QCL) information, which is determined based on beam prediction results.

[0260] In some respects, method 2400 also includes another command for obtaining the default space QCL information. In some cases, this step refers to the operation as described in the reference... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0261] In some respects, at least one communication is processed after a duration following the receipt of a command, wherein the duration is based on a timer started after the command is received.

[0262] In one aspect, method 2400 or any aspect thereof may be made by means of a device (such as...) Figure 27 The communication device 2700 is used to perform the method 2400, which includes various components capable of operating, being configured, or adapted to perform the method. The communication device 2700 is described in more detail below.

[0263] It should be noted that Figure 24 This is merely one example of a method, and other methods that include fewer, additional, or alternative steps may also be consistent with this disclosure.

[0264] Figure 25 This shows the source network entities (such as...) Figure 1 and Figure 3 (BS 102) or as per BS 102) Figure 2 An example of the method 2500 for wireless communication at the decomposed base station discussed.

[0265] Method 2500 begins at step 2505: The output is information configuring a candidate cell set for the User Equipment (UE) for transmission, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells. In some cases, the operation of this step refers to... (See reference...) Figure 27 The circuitry described for output and / or the code for output, or the circuitry and / or the code that can be executed.

[0266] Method 2500 then proceeds to step 2510: An output command instructing the UE to switch from one or more source cells to one or more target cells in the candidate cell set is provided for transmission. In some cases, this step refers to the operation as described in reference [reference needed]. Figure 27 The circuitry described for output and / or the code for output, or the circuitry and / or the code that can be executed.

[0267] Method 2500 then proceeds to step 2515: outputting the time beam prediction results for transmission to one or more target cells in the target cell. In some cases, this step refers to the operation as described in the reference... Figure 27 The circuitry described for output and / or the code for output, or the circuitry and / or the code that can be executed.

[0268] In some aspects, method 2500 further includes: outputting a request from the UE for time beam prediction results for transmission. In some cases, this step refers to the operation as described in reference... Figure 27The circuitry described for output and / or the code for output, or the circuitry and / or the code that can be executed.

[0269] In some respects, method 2500 also includes obtaining a report that includes time beam prediction results. In some cases, this step refers to, as referenced... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0270] In some respects, at least one of the commands or requests is output via a Media Access Control (MAC) control element (CE) for transmission.

[0271] In some respects, the request is output after the output command is used for sending.

[0272] In some respects, requests and commands are sent via the same MAC CE output.

[0273] In some aspects, method 2500 also includes obtaining temporal beam prediction results based on predictions at the source network entities. In some cases, this step refers to operations such as... Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0274] In one aspect, method 2500 or any aspect thereof may be made by means of a device (such as...) Figure 27 The communication device 2700 is used to perform the method 2500, which includes various components capable of operating, being configured, or adapted to perform the method. The communication device 2700 is described in more detail below.

[0275] It should be noted that Figure 25 This is merely one example of a method, and other methods that include fewer, additional, or alternative steps may also be consistent with this disclosure.

[0276] Figure 26 This shows the target network entity (such as Figure 1 and Figure 3 (BS 102) or as per BS 102) Figure 2 An example of the method 2600 for wireless communication at the decomposed base station discussed.

[0277] Method 2600 begins at step 2605: obtaining information instructing the user equipment (UE) to hand over from one or more source cells to at least one target cell in a candidate cell set, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between candidate cells, and the at least one target cell is associated with a target network entity. In some cases, the operation of this step refers to, as referenced Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0278] Method 2600 then proceeds to step 2610: obtaining a time beam prediction result predicted by at least one of the following from at least one source cell in the source cells: the UE or one or more source cells in the source cells. In some cases, this step refers to the operation as described in reference Figure 27 The circuit and / or code described for obtaining, or that can be executed by the circuit and / or the code.

[0279] Method 2600 then proceeds to step 2615: after obtaining the information, at least one communication associated with the target cell is processed based on the time beam prediction results. In some cases, the operation of this step involves, as referenced... Figure 27 The circuitry and / or code described for processing, or that can be executed by the circuitry and / or the code.

[0280] In some respects, time beam prediction results are based on predicted values ​​of measurements of reference signals (RS) associated with at least one or more target cells in the target cell.

[0281] In some respects, RS includes at least one of Channel State Information (CSI) RS or Synchronization Signal Block (SSB).

[0282] In some respects, at least one communication in one or more target cells includes at least one of the following: transmission of a physical downlink control channel (PDCCH); transmission of a physical downlink shared channel (PDSCH); or transmission of a physical uplink shared channel (PUSCH).

[0283] In some aspects, processing is based on default spatial quasi-co-location (QCL) information, which is determined based on beam prediction results.

[0284] In one aspect, method 2600 or any aspect thereof may be made by means of a device (such as...) Figure 27 The communication device 2700 is used to perform the method 2600, which includes various components capable of operating, being configured, or adapted to perform the method. The communication device 2700 is described in more detail below.

[0285] It should be noted that Figure 26 This is merely one example of a method, and other methods that include fewer, additional, or alternative steps may also be consistent with this disclosure.

[0286] Example communication device

[0287] Figure 27 Various aspects of the example communication device 2700 are described. In some aspects, the communication device 2700 is user equipment, such as those mentioned above. Figure 1 and Figure 3 The UE 104 is described. In some respects, the communication device 2700 is a network entity, such as... Figure 1 and Figure 3 BS 102 or as about Figure 2 The decomposed base station under discussion.

[0288] Communication device 2700 includes a processing system 2705 coupled to transceiver 2755 (e.g., transmitter and / or receiver). In some aspects (e.g., when communication device 2700 is a network entity), processing system 2705 may be coupled to network interface 2765, which is configured to communicate via a communication link (such as, as described herein, regarding...). Figure 2 The described backhaul link, midhaul link, and / or fronthaul link receive and transmit signals for communication device 2700. Transceiver 2755 is configured to transmit and receive signals for communication device 2700, such as the various signals described herein, via antenna 2760. Processing system 2705 may be configured to perform processing functions of communication device 2700, including processing signals received by communication device 2700 and / or to be transmitted by the communication device.

[0289] Processing system 2705 includes one or more processors 2710. In various aspects, the one or more processors 2710 may represent one or more of a receive processor 358, a transmit processor 364, a TX MIMO processor 366, and / or a controller / processor 380, as per [reference to...]. Figure 3 As described. In various respects, one or more processors 2710 may represent one or more of the following: receive processor 338, transmit processor 320, TX MIMO processor 330, and / or controller / processor 340, as per [reference to...]. Figure 3 As described. One or more processors 2710 are coupled to a computer-readable medium / memory 2730 via a bus 2750. In some aspects, the computer-readable medium / memory 2730 is configured to store instructions (e.g., computer-executable code) that, when executed by the one or more processors 2710, cause the one or more processors 2710 to perform actions related to... Figure 23 The described method 2300 or any aspect thereof; regarding Figure 24 The described method 2400 or any aspect thereof; regarding Figure 25 The described method 2500 or any aspect thereof; and regarding Figure 26The method 2600 described herein or any aspect thereof. It should be noted that references to processors performing the functions of communication device 2700 may include one or more processors 2710 performing those functions of communication device 2700.

[0290] In the depicted example, computer-readable medium / memory 2730 stores code (e.g., executable instructions), such as code 2735 for acquisition, code 2740 for output, and code 2745 for processing. Processing the code 2735 for acquisition, the code 2740 for output, and the code 2745 for processing enables the communication device 2700 to perform actions related to acquisition. Figure 23 The described method 2300 or any aspect thereof; regarding Figure 24 The described method 2400 or any aspect thereof; regarding Figure 25 The described method 2500 or any aspect thereof; and regarding Figure 26 The method described 2600 or any aspect thereof.

[0291] One or more processors 2710 include circuitry configured to implement (e.g., execute) code stored in a computer-readable medium / memory 2730, the circuitry including acquisition circuitry 2715, output circuitry 2720, and processing circuitry 2725. Processing using the acquisition circuitry 2715, output circuitry 2720, and processing circuitry 2725 enables the communication device 2700 to perform actions related to... Figure 23 The described method 2300 or any aspect thereof; regarding Figure 24 The described method 2400 or any aspect thereof; regarding Figure 25 The described method 2500 or any aspect thereof; and regarding Figure 26 The method described 2600 or any aspect thereof.

[0292] The various components of the communication device 2700 provide parts for performing: about Figure 23 The described method 2300 or any aspect thereof; regarding Figure 24 The described method 2400 or any aspect thereof; regarding Figure 25 The described method 2500 or any aspect thereof; and regarding Figure 26 The described method 2600 or any aspect thereof. For example, components for sending, transmitting, or outputting for transmission may include... Figure 3 The transceiver 354 and / or antenna 352 of UE 104 illustrated herein Figure 3 The transceiver 332 and / or antenna 334 of BS 102 illustrated herein Figure 27 The communication device 2700 includes a transceiver 2755 and an antenna 2760. Components for receiving or acquiring data may include... Figure 3 The transceiver 354 and / or antenna 352 of UE 104 illustrated herein Figure 3 The transceiver 332 and / or antenna 334 of BS 102 illustrated herein Figure 27 The communication device 2700 includes a transceiver 2755 and an antenna 2760. The components for acquiring data, for outputting data, and for processing data can be implemented using any suitable circuitry or processor, including... Figure 3 and Figure 27 The processors and components are illustrated.

[0293] Example Terms

[0294] Specific implementation examples are described in the following numbered clauses: Clause 1: A method for wireless communication at a wireless node, the method comprising: obtaining information for configuring a set of candidate cells for user equipment, wherein the user equipment supports lower-layer triggered mobility (LTM) for enabling communication handover between the candidate cells; obtaining a command instructing the wireless node to handover from one or more source cells to one or more target cells in the set of candidate cells; obtaining a request for time beam prediction results; outputting a report including the time beam prediction results for transmission; and, upon obtaining the request, processing at least one communication associated with one or more target cells in the set of target cells based on the time beam prediction results.

[0295] Clause 2: The method described in Clause 1, wherein at least one of the command or the request is obtained via a Media Access Control (MAC) control element (CE).

[0296] Clause 3: The method described in Clause 1, wherein the request is obtained after the command is received.

[0297] Clause 4: The method described in Clause 1, wherein the request and the command are obtained via the same MAC CE.

[0298] Clause 5: The method according to any one of Clauses 1 to 4, wherein the time beam prediction result is based on the predicted value of a measurement of a reference signal (RS) associated with at least one or more of the target cells.

[0299] Clause 6: The method according to Clause 5, wherein the RS includes at least one of Channel State Information (CSI) RS or Synchronization Signal Block (SSB).

[0300] Clause 7: The method according to any one of Clauses 1 to 6, wherein the at least one communication in one or more target cells includes at least one of the following: physical downlink control channel (PDCCH) transmission; physical downlink shared channel (PDSCH) transmission; or physical uplink shared channel (PUSCH).

[0301] Clause 8: According to the method described in Clause 7, the processing of said at least one communication is further based on default spatial quasi-co-location (QCL) information, which is determined based on beam prediction results.

[0302] Clause 9: The method described in Clause 8 further includes obtaining another command for overwriting the default space QCL information.

[0303] Clause 10: The method according to any one of Clauses 1 to 9, wherein the at least one communication is processed after a duration following the receipt of the command, wherein the duration is based on a timer started after the receipt of the command.

[0304] Clause 11: A method for wireless communication at a wireless node, the method comprising: obtaining information configuring a set of candidate cells for user equipment, wherein the user equipment supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells; obtaining a command instructing the wireless node to handover from one or more source cells to one or more target cells in the set of candidate cells; obtaining a temporal beam prediction result; and, after obtaining the command, processing at least one communication associated with one or more target cells in the set of target cells based on the temporal beam prediction result.

[0305] Clause 12: The method according to Clause 11, wherein at least one of the command or the time beam prediction result is obtained via a Media Access Control (MAC) control element (CE).

[0306] Clause 13: The method according to Clause 11, wherein the time beam prediction result is obtained after the command is received.

[0307] Clause 14: The method according to Clause 11, wherein the time beam prediction result and the command are obtained via the same MAC CE.

[0308] Clause 15: The method according to any one of Clauses 11 to 14, wherein the at least one communication in one or more target cells comprises at least one of the following: Physical Downlink Control Channel (PDCCH) transmission; Physical Downlink Shared Channel (PDSCH) transmission; or Physical Uplink Shared Channel (PUSCH).

[0309] Clause 16: The method according to Clause 15, wherein the processing of the at least one communication is further based on Default Spatial Quasi-Co-location (QCL) information, which is determined based on beam prediction results.

[0310] Clause 17: The method described in Clause 16 further includes obtaining another command for overwriting the default space QCL information.

[0311] Clause 18: The method according to any one of Clauses 11 to 17, wherein the at least one communication is processed after a duration following the receipt of the command, wherein the duration is based on a timer started after the receipt of the command.

[0312] Clause 19: A method for wireless communication at a wireless node, the method comprising: outputting information configuring a set of candidate cells for a user equipment (UE) for transmission, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells; outputting a command instructing the UE to handover from one or more source cells to one or more target cells in the set of candidate cells for transmission; and outputting time beam prediction results for transmission to one or more target cells in the set of target cells.

[0313] Clause 20: The method according to Clause 19 further includes: outputting a request from the UE for the time beam prediction result for transmission; and obtaining a report including the time beam prediction result.

[0314] Clause 21: The method according to Clause 20, wherein at least one of the command or the request is output via a Media Access Control (MAC) Control Element (CE) for transmission.

[0315] Clause 22: The method described in Clause 21, wherein the request is output for sending after the command is output for sending.

[0316] Clause 23: The method described in Clause 21, wherein the request and the command are transmitted via the same MAC CE output.

[0317] Clause 24: The method according to any one of Clauses 19 to 23, the method further comprising: obtaining the time beam prediction result based on the prediction at the wireless node.

[0318] Clause 25: A method for wireless communication at a radio node, the method comprising: obtaining information instructing a user equipment (UE) to hand over from one or more source cells to at least one target cell in a set of candidate cells, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells, and the at least one target cell is associated with the radio node; obtaining a time beam prediction result from at least one of the source cells: the UE or one or more source cells; and, after obtaining the information, processing at least one communication associated with the target cell based on the time beam prediction result.

[0319] Clause 26: The method according to Clause 25, wherein the time beam prediction result is based on a predicted value of a measurement of a reference signal (RS) associated with at least one or more of the target cells.

[0320] Clause 27: The method according to Clause 26, wherein the RS includes at least one of Channel State Information (CSI) RS or Synchronization Signal Block (SSB).

[0321] Clause 28: The method according to any one of Clauses 25 to 27, wherein the at least one communication in one or more target cells comprises at least one of the following: physical downlink control channel (PDCCH) transmission; physical downlink shared channel (PDSCH) transmission; or physical uplink shared channel (PUSCH).

[0322] Clause 29: The method described in Clause 28, wherein the processing is based on Default Spatial Quasi-Co-location (QCL) information, which is determined based on beam prediction results.

[0323] Clause 30: An apparatus comprising: a memory including executable instructions; and a processor configured to execute the executable instructions and cause the apparatus to perform a method according to any one of Clauses 1 to 29.

[0324] Clause 31: An apparatus comprising components for performing the method according to any one of Clauses 1 to 29.

[0325] Clause 32: A non-transitory computer-readable medium comprising executable instructions that, when executed by a processor of a device, cause the device to perform the method according to any one of Clauses 1 to 29.

[0326] Clause 33: A computer program product embodied on a computer-readable storage medium, said computer-readable storage medium including code for performing the method according to any one of Clauses 1 to 29.

[0327] Clause 34: A user equipment (UE) comprising: at least one transceiver; at least one memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the UE to perform a method according to any one of Clauses 1 to 11, wherein the at least one transceiver is configured to receive the information, the command, and the request and to send the report.

[0328] Clause 35: A user equipment (UE) comprising: at least one transceiver; at least one memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the UE to perform a method according to any one of Clauses 12 to 16, wherein the at least one transceiver is configured to receive the information, the command, and the time beam prediction result.

[0329] Clause 36: A network entity comprising: at least one transceiver; at least one memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the network entity to perform a method according to any one of Clauses 19 to 24, wherein the at least one transceiver is configured to transmit the information, the command, and the time beam prediction result.

[0330] Clause 37: A network entity comprising: at least one transceiver; at least one memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the network entity to perform a method according to any one of Clauses 25 to 29, wherein the at least one transceiver is configured to receive the information and the time beam prediction result.

[0331] Additional Notes

[0332] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. The examples discussed herein do not limit the scope, applicability, or aspects set forth in the claims. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. For example, the function and arrangement of the elements discussed may be changed without departing from the scope of this disclosure. Various processes or components may be omitted, substituted, or added as appropriate in the various examples. For example, the described methods may be performed in a different order than described, and various actions may be added, omitted, or combined. Furthermore, features described with respect to some examples may be combined in some other examples. For example, any number of aspects set forth herein may be used to implement an apparatus or practice. Moreover, the scope of this disclosure is intended to cover such apparatuses or methods practiced using other structures, functionalities, or structures and functionalities that complement or replace the various aspects of this disclosure set forth herein. It should be understood that any aspect of the disclosure herein may be embodied by one or more elements of the claims.

[0333] The various exemplary logic blocks, modules, and circuits described in this disclosure can be implemented or executed using a general-purpose processor, digital signal processor (DSP), ASIC, field-programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic unit, discrete hardware component, or any combination thereof designed to perform the functions described herein. While the general-purpose processor may be a microprocessor, in alternative embodiments, the processor may be any commercially available processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors working in conjunction with a DSP core, a system-on-a-chip (SoC), or any other such configuration.

[0334] As used herein, "processor," "at least one processor," or "one or more processors" generally refers to a single processor configured to perform one or more operations, or multiple processors configured to collectively perform one or more operations. In the case of multiple processors, the execution of one or more operations may be divided among different processors, but one processor may perform multiple operations, and multiple processors may collectively perform a single operation. Similarly, "memory," "at least one memory," or "one or more memory" generally refers to a single memory configured to store data and / or instructions, or multiple memories configured to collectively store data and / or instructions.

[0335] As used in this article, the phrase “at least one of” in a list of items refers to any combination of these entries, including a single member. As an example, “at least one of a, b, or c” is intended to cover: a, b, c, ab, ac, bc, and abc, as well as any combination with multiple identical elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0336] As used herein, the term "determine" encompasses a wide variety of actions. For example, "determine" can include calculation, operation, processing, deduction, investigation, lookup (e.g., searching in a table, database, or other data structure), assertion, etc. Additionally, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. Furthermore, "determine" can include parsing, selecting, picking, building, etc.

[0337] The methods disclosed herein include one or more actions for implementing the methods. These actions may be interchanged without departing from the scope of the claims. In other words, unless a specific order of actions is specified, the order and / or use of a particular action may be modified without departing from the scope of the claims. Furthermore, the various operations of the methods described above may be performed by any suitable component capable of performing the corresponding function. This component may include various hardware and / or software components and / or modules, including but not limited to circuits, application-specific integrated circuits (ASICs), or processors.

[0338] The following claims are not intended to be limited to the aspects shown herein, but should be given the full scope consistent with the language of the claims. Within the claims, unless specifically stated otherwise, reference to the singular form of an element is not intended to mean “one and only one,” but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No element of any claim shall be interpreted in accordance with 35 USC §112(f) unless that element is explicitly stated using the phrase “for a component of.” All structural and functional equivalents of the elements throughout the various aspects described herein that are known to a person of ordinary skill in the art, or will later be known, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is explicitly recited in the claims.

Claims

1. An apparatus for wireless communication, the apparatus comprising: At least one memory, said at least one memory including executable instructions; and one or more processors, said one or more processors being configured to execute the executable instructions and cause the device to: Information is obtained to configure a set of candidate cells for user equipment, wherein the user equipment supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells. Obtain a command instructing the UE to switch from one or more source cells to one or more target cells in the candidate cell set; Requesting the results of time beam prediction; The output includes a report of the time beam prediction results for transmission; as well as Upon receiving the request, at least one communication associated with one or more target cells in the target cells is processed based on the time beam prediction result.

2. The apparatus of claim 1, wherein at least one of the command or the request is obtained via a Media Access Control (MAC) control element (CE).

3. The apparatus of claim 1, wherein the request is obtained after the command is received.

4. The apparatus of claim 1, wherein the request and the command are obtained via the same MAC CE.

5. The apparatus of claim 1, wherein the time beam prediction result is based on a predicted value of a measurement of a reference signal (RS) associated with at least one or more of the target cells.

6. The apparatus of claim 5, wherein the RS comprises at least one of channel state information (CSI) RS or synchronization signal block (SSB).

7. The apparatus of claim 1, wherein the at least one communication in one or more target cells comprises at least one of the following: physical downlink control channel (PDCCH) transmission; physical downlink shared channel (PDSCH) transmission; or physical uplink shared channel (PUSCH).

8. The apparatus of claim 1, wherein the processing of the at least one communication is further based on default spatial quasi-co-location (QCL) information, the default spatial quasi-co-location (QCL) information being determined based on beam prediction results.

9. The apparatus of claim 8, wherein the one or more processors are configured to execute processor-executable instructions and further cause the apparatus to: Obtain another command for overwriting the default space QCL information.

10. The apparatus of claim 1, wherein the at least one communication is processed after a period of time following the receipt of the command, wherein the period of time is based on a timer started after the receipt of the command.

11. The apparatus of claim 1, further comprising at least one transceiver configured to receive the information, the command, and the request and to transmit the report, wherein the apparatus is configured as a user equipment (UE).

12. An apparatus for wireless communication, the apparatus comprising: At least one memory, said at least one memory including executable instructions; and one or more processors, said one or more processors being configured to execute the executable instructions and cause the device to: Information is obtained to configure a set of candidate cells for user equipment, wherein the user equipment supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells. Obtain a command instructing the UE to switch from one or more source cells to one or more target cells in the candidate cell set; Obtain time beam prediction results; as well as After receiving the command, at least one communication associated with one or more target cells in the target cells is processed based on the time beam prediction result.

13. The apparatus of claim 12, wherein at least one of the command or the time beam prediction result is obtained via a media access control (MAC) control element (CE).

14. The apparatus of claim 12, wherein the time beam prediction result is obtained after the command is received.

15. The apparatus of claim 12, wherein the time beam prediction result and the command are obtained via the same MAC CE.

16. The apparatus of claim 12, wherein the at least one communication in one or more target cells comprises at least one of the following: physical downlink control channel (PDCCH) transmission; physical downlink shared channel (PDSCH) transmission; or physical uplink shared channel (PUSCH).

17. The apparatus of claim 12, wherein the processing of the at least one communication is further based on default spatial quasi-co-location (QCL) information, the default spatial quasi-co-location (QCL) information being determined based on beam prediction results.

18. The apparatus of claim 17, wherein the one or more processors are configured to execute processor-executable instructions and further cause the apparatus to: Obtain another command for overwriting the default space QCL information.

19. The apparatus of claim 12, wherein the at least one communication is processed after a period of time following the receipt of the command, wherein the period of time is based on a timer started after the receipt of the command.

20. The apparatus of claim 12, further comprising at least one transceiver configured to receive the information, the command, and the time beam prediction result and to transmit the report, wherein the apparatus is configured as a user equipment (UE).

21. An apparatus for wireless communication, the apparatus comprising: At least one memory, said at least one memory including executable instructions; and one or more processors, said one or more processors being configured to execute the executable instructions and cause the device to: The output is information for configuring a set of candidate cells for transmission for a user equipment (UE), wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells. Output a command instructing the UE to switch from one or more source cells to one or more target cells in the candidate cell set for transmission; as well as Output time beam prediction results for transmission to one or more target cells in the target cell.

22. The apparatus of claim 21, wherein the one or more processors are configured to execute processor-executable instructions and further cause the apparatus to: Output a request from the UE for the time beam prediction result for transmission; and Obtain a report that includes the time beam prediction results.

23. The apparatus of claim 22, wherein at least one of the command or the request is output via a Media Access Control (MAC) control element (CE) for transmission.

24. The apparatus of claim 23, wherein the request is output for transmission after the command for transmission is output.

25. The apparatus of claim 23, wherein the request and the command are transmitted via the same MAC CE output.

26. The apparatus of claim 21, wherein the one or more processors are configured to execute processor-executable instructions and further cause the apparatus to: The temporal beam prediction result is obtained based on the prediction at the source network entity.

27. The apparatus of claim 21, further comprising at least one transceiver configured to transmit the information, the command, and the time beam prediction result, wherein the apparatus is configured as a network entity.

28. An apparatus for wireless communication, the apparatus comprising: At least one memory, said at least one memory including executable instructions; and one or more processors, said one or more processors being configured to execute the executable instructions and cause the device to: Obtain information instructing a user equipment (UE) to switch from one or more source cells to at least one target cell in a set of candidate cells, wherein the UE supports lower-layer triggered mobility (LTM) to enable communication handover between the candidate cells, and the at least one target cell is associated with a target network entity; Obtain a time beam prediction result predicted by at least one of the following from at least one of the source cells: the UE or one or more of the source cells; as well as After obtaining the information, at least one communication associated with the target cell is processed based on the time beam prediction result.

29. The apparatus of claim 28, wherein the time beam prediction result is based on a predicted value of a measurement of a reference signal (RS) associated with at least one or more of the target cells.

30. The apparatus of claim 29, wherein the RS comprises at least one of channel state information (CSI) RS or synchronization signal block (SSB).

31. The apparatus of claim 28, wherein the at least one communication in one or more target cells comprises at least one of the following: physical downlink control channel (PDCCH) transmission; physical downlink shared channel (PDSCH) transmission; or physical uplink shared channel (PUSCH).

32. The apparatus of claim 28, wherein the processing of the at least one communication is further based on default spatial quasi-co-location (QCL) information, the default spatial quasi-co-location (QCL) information being determined based on beam prediction results.

33. The apparatus of claim 28, further comprising at least one transceiver configured to receive the information and the time beam prediction result, wherein the apparatus is configured as a network entity.

Images