High-efficiency beam recovery procedure

Abstract

The present disclosure relates to high-efficiency beam recovery procedures. A user equipment (UE) is configured to determine a probability metric of a likelihood of a beam failure event at the UE, implement a beam management power saving scheme based on the probability metric, and process a portion of a network scheduled beam recovery resource within a time window. The UE can also be configured to generate a radio link monitoring (RLM) block error rate (BLER) metric associated with a beam, determine that the RLM BLER metric is below a threshold, and disable a beam failure detection (BFD) and candidate beam detection (CBD) procedure at the UE in response to determining that the RLM BLER metric is below the threshold.

Description

Background Technology

[0001] Signaling between a User Equipment (UE) and the network can be achieved via beamforming. Beamforming is an antenna technique used to transmit directional signals, which can be referred to as beams. Beam management generally refers to a set of processes configured to acquire and maintain a beam between the UE and a Transmit Receive Point (TRP) deployed by the network. Beam management processes may include various operations related to beam recovery.

[0002] The UE can be configured with a time window during which it monitors different types of network resources associated with beam recovery, such as reference signals and synchronization signal blocks (SSBs). Outside this time window, the UE has the opportunity to sleep and conserve power. Under normal circumstances, the UE processes network resources regardless of how likely beam recovery is to be triggered at the UE. This is an inefficient use of the UE's limited power source. Therefore, techniques are needed to mitigate the inefficient power consumption associated with beam recovery at the UE. Summary of the Invention

[0003] Some exemplary embodiments relate to a processor of a user equipment (UE) configured to perform operations. These operations include determining a probabilistic metric of the likelihood of a beam failure event at the UE, implementing a beam management power-saving scheme based on the probabilistic metric, and processing a portion of network-scheduled beam recovery resources within a time window.

[0004] Other exemplary embodiments relate to a processor of a user equipment (UE) configured to perform operations. These operations include generating a beam-associated radio link monitoring (RLM) block error rate (BLER) metric, determining that the RLM BLER metric is below a threshold, and disabling beam failure detection (BFD) and candidate beam detection (CBD) procedures at the UE in response to determining that the RLM BLER metric is below the threshold.

[0005] Other exemplary embodiments relate to a user equipment (UE) having: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations. These operations include determining a probabilistic metric of the likelihood of a beam failure event at the UE, implementing a beam management power-saving scheme based on the probabilistic metric, and processing a portion of network-scheduled beam recovery resources within a time window.

[0006] Another exemplary embodiment relates to a user equipment (UE) having: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations. These operations include generating a beam-associated Radio Link Monitoring (RLM) Block Error Rate (BLER) metric, determining that the RLM BLER metric is below a threshold, and disabling beam fault detection (BFD) and candidate beam detection (CBD) procedures at the UE in response to determining that the RLM BLER metric is below the threshold. Attached Figure Description

[0007] Figure 1 Exemplary network arrangements according to various exemplary implementations are shown.

[0008] Figure 2 Exemplary UEs according to various exemplary implementations are shown.

[0009] Figure 3 An exemplary base station according to various exemplary embodiments is shown.

[0010] Figure 4 Methods for training beam fault prediction mechanisms according to various exemplary embodiments are shown.

[0011] Figure 5 Methods for high-efficiency beam recovery operations according to various exemplary embodiments are shown.

[0012] Figure 6 Methods for selectively enabling beam recovery processes according to various exemplary embodiments are shown. Detailed Implementation

[0013] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein similar elements have the same reference numerals. The exemplary embodiments relate to beam management. Those skilled in the art will understand that beam management generally refers to a set of processes configured to acquire and maintain a beam between a user equipment (UE) and a transmit-receive point (TRP). Various exemplary techniques configured to reduce the load of beam management activities on the UE are introduced, as will be described in more detail below.

[0014] Exemplary embodiments are described with reference to the UE. However, the reference to the UE is provided for illustrative purposes only. The exemplary embodiments can be used with any electronic component that can establish a connection to a network and is configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE described herein is used to represent any electronic component.

[0015] Exemplary implementations are also described with reference to 5G New Radio (NR) networks. However, the reference to 5G NR networks is provided for illustrative purposes only. The exemplary implementations can be used with any network that utilizes beamforming. Therefore, the 5G NR network described herein can represent any type of network that implements beamforming.

[0016] Those skilled in the art will understand that beamforming is an antenna technique used to transmit or receive directional signals. From the perspective of a transmitting device, beamforming can refer to the propagation of a directional signal. Throughout this specification, the beamformed signal may be referred to as a "beam" or a "transmitter beam." A transmitter beam is generated by having multiple antenna elements radiate the same signal. Increasing the number of antenna elements radiating the signal reduces the width of the radiation pattern and increases the gain. Therefore, the transmitter beam can vary in width and can propagate in any of several different directions.

[0017] From the perspective of the receiving device, beamforming refers to tuning the receiver to listen in the direction of interest. Throughout this specification, the spatial region enclosed by the receiver listening in the direction of interest may be referred to as a "beam" or "receiver beam." The receiver beam can be generated by configuring the parameters of a spatial filter on the receiver antenna array to listen in the direction of interest and filter out any noise outside that direction. Like the transmitter beam, the receiver beam can also vary in width and can be directed over any of several different regions of interest.

[0018] Furthermore, exemplary embodiments are described with reference to a next-generation node B (gNB) configured with multiple TRPs. Throughout this specification, TRP generally refers to a group of components configured to transmit and / or receive beams. In some embodiments, multiple TRPs may be deployed locally on the gNB. For example, the gNB may include multiple antenna arrays / panels, each configured to generate different beams. In other embodiments, multiple TRPs may be deployed in various locations and connected to the gNB via backhaul connections. For example, multiple small cells may be deployed in different locations and connected to the gNB. However, these examples are provided for illustrative purposes only. Those skilled in the art will understand that TRPs are configured to adapt to a variety of different conditions and deployment scenarios. Therefore, any reference to a TRP as a specific network component or to multiple TRPs deployed in a particular arrangement is merely illustrative. The TRPs described herein can represent any type of network component configured to transmit and / or receive beams.

[0019] In 5G networks, beamforming can occur on the millimeter-wave (mmW) spectrum. The mmW spectrum consists of frequency bands, each with a wavelength of 1-10 millimeters. These bands can be located between approximately 8 GHz and 300 GHz. However, any reference to a particular network or type of base station is provided for illustrative purposes only. Exemplary implementations can be applied to any type of network and any type of base station within that network configured to communicate with the UE on the mmW spectrum, or any other similar concept.

[0020] A UE configured for beamforming may be equipped with various radio frequency (RF) panels (e.g., one or more antenna elements, RF circuitry, etc.), and each RF panel may support a set of beamcodebooks. These components and features may have relatively high power requirements, which can put stress on the UE battery and / or UE temperature limits. Furthermore, beam management processes such as beam fault recovery (BFR), beam fault detection (BFD), and candidate beam detection (CBD) may require monitoring and processing various types of network resources. This type of data exchange processing can cause power consumption for the UE. As will be described in more detail below, exemplary embodiments introduce techniques for reducing the load of beam management processes on the UE.

[0021] The UE can be configured with a power-saving mode and a data exchange processing activity mode. The data exchange processing activity mode can refer to the UE performing operations that enable it to receive information and / or data from the network. For example, in the context of beam management, the UE can be configured with a scheduling time window during which the UE will utilize the data exchange processing activity mode to monitor and process network resources. These resources may include, but are not limited to, Channel State Information (CSI) Reference Signals (RS) and Synchronization Signal Blocks (SSBs). In one example, the scheduling time window during which the UE will utilize the data exchange processing activity mode may be the onDuration of a Discontinuous Receive (DRX) cycle. In another example, the scheduling time window during which the UE will utilize the data exchange processing activity mode may be triggered by a wake-up signal or any other type of signal indicating that the UE is scheduling information and / or data. However, the examples provided above are for illustrative purposes only. Exemplary implementations relate to reducing the data exchange processing activity mode performed for beam management purposes.

[0022] Outside of the scheduled time window, the UE may have the opportunity to utilize an inactive sleep mode and conserve power. References to power-saving modes or inactive sleep modes do not necessarily mean putting the UE's processor, transmitter, and receiver to sleep, hibernate, or disable them. For example, the processor (e.g., baseband and / or applications) may continue to execute other applications or processes. Sleep mode involves conserving power by interrupting continuous processing functions associated with operations that enable the UE to receive data that can be transmitted to the UE and transmit data to the network.

[0023] As described above, exemplary embodiments introduce techniques for reducing the load on beam management processes on a UE. This may include reducing the amount of time the UE spends in active modes of data exchange processing performing beam management-related operations. In one aspect, exemplary embodiments introduce filters that enable the UE to adequately balance beam recovery performance with dynamic UE power and / or UE temperature constraints. For example, when a beam failure event is possible, the UE may handle all network-scheduled beam recovery resources. When a beam failure event is unlikely, the UE may utilize only a portion of the network-scheduled beam recovery resources, and thus the UE may reduce the amount of active data exchange processing performed for beam management operations. In another aspect, exemplary embodiments may enable the UE to temporarily and completely suspend certain beam management processes. The exemplary techniques described herein may partially or completely enable the UE to control certain beam management processes on a UE-needed basis, rather than solely relying on network scheduling. Each of these exemplary aspects will be described in more detail below. The exemplary techniques described herein may be used in conjunction with currently implemented beam management processes, future implementations of beam management processes, or independently of other beam management processes.

[0024] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is illustrated. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet, desktop computer, smartphone, phablet, embedded device, wearable device, Internet of Things (IoT) device, etc. It should also be understood that a practical network arrangement can include any number of UEs used by any number of users. Therefore, for illustrative purposes, only an example with a single UE 110 is provided.

[0025] UE 110 can be configured to communicate with one or more networks. In the example of network configuration 100, the network with which UE 110 can wirelessly communicate is the 5G NR radio access network (RAN) 120. However, UE 110 can also communicate with other types of networks (e.g., 5G cloud RAN, next-generation RAN (NG-RAN), LTE RAN, legacy cellular networks, WLAN, etc.), and UE 110 can also communicate with the network via a wired connection. Referring to an exemplary embodiment, UE 110 can establish a connection with 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with NR RAN 120.

[0026] The 5G NR RAN 120 can be part of a cellular network that can be deployed by network operators (e.g., Verizon, AT&T, T-Mobile, etc.). The 5G NR RAN 120 may include, for example, cells or base stations (Node B, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base station, microcell base station, small cell base station, femtocell base station, etc.) configured to send and receive communication traffic from UEs equipped with appropriate cellular chipsets.

[0027] In network deployment 100, the 5G NR RAN 120 includes a gNB 120A configured to have multiple TRPs. Each TRP may represent one or more components configured to transmit and / or receive beams. In some implementations, multiple TRPs may be deployed locally on the gNB 120A. In other implementations, multiple TRPs may be distributed at different locations and connected to the gNB 120A via backhaul connections. In any configuration, each TRP may transmit a beam to and / or receive a beam from the UE 110. However, the gNB 120A may be configured to control the TRPs and perform operations such as, but not limited to, scheduling resources, implementing beam management techniques, etc. Those skilled in the art will understand that 5G NR TRPs are suitable for a variety of different conditions and deployment scenarios. Actual network deployments may include any number of base stations and / or TRPs of different types, deployed by any number of RANs in any suitable arrangement. Therefore, Figure 1 The example of a single gNB 120A is provided for illustrative purposes only.

[0028] UE 110 can connect to 5G NR-RAN 120 via gNB 120A. Those skilled in the art will understand that any relevant procedures can be performed for UE 110 to connect to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 can be associated with a specific cellular provider, where UE 110 and / or its user have protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 can transmit the corresponding credential information to associate with 5G NR-RAN 120. More specifically, UE 110 can be associated with a specific base station (e.g., gNB 120A). However, as described above, the reference to 5G NR-RAN 120 is for illustrative purposes, and any suitable type of RAN can be used.

[0029] Network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 can be viewed as an interconnected set of components that manage the operation and traffic of the cellular network. The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network services backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 can generally be described as a set of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 to communicate with various networks.

[0030] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1 The network layout 100 is used to describe UE 110. UE 110 may include a processor 205, a memory layout 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, power sources, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, etc.

[0031] Processor 205 can be configured to execute multiple engines of UE 110. For example, engines may include beam failure prediction mechanism 235, beam management power saving scheme engine 240, and RLM BLER beam recovery activation engine 245. Beam failure prediction mechanism 235 can be trained to generate beam failure probability metrics that indicate to UE 110 the likelihood of subsequent beam failure events. Beam management power saving scheme engine 240 can control whether beam recovery resources are processed by UE 110. RLM BLER beam recovery activation engine 245 can enable and disable certain beam recovery operations based on RLM BLER metrics.

[0032] The engines 235-245 referred to above are provided for illustrative purposes only as applications (e.g., programs) executed by processor 205. The functionality associated with engines 235-245 may also be represented as separate integrated components of UE 110, or as modular components coupled to UE 110, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is distributed among two or more processors, such as a baseband processor and an application processor. Exemplary implementations may be implemented according to any of these or other configurations of the UE.

[0033] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling user input. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen). Transceiver 225 may be a hardware component configured to establish a connection with 5G NR-RAN 120 and / or any other suitable type of network. Therefore, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies).

[0034] Figure 3 An exemplary base station 300 according to various exemplary embodiments is shown. Base station 300 may represent any access node (e.g., gNB 120A, etc.) that UE 110 can use to establish connections and manage network operations.

[0035] Base station 300 may include processor 305, memory arrangement 310, input / output (I / O) devices 315, transceiver 320, and other components 325. Other components 325 may include, for example, a battery, data acquisition equipment, ports for electrically connecting base station 300 to other electronic devices, etc.

[0036] The processor 305 can be configured to execute multiple engines of the base station 300. For example, the engines may include a beam recovery resource engine 330. The beam recovery resource engine 330 can perform various operations related to scheduling and transmitting beam recovery resources, such as, but not limited to, CBD-SSB, CBD-CSI-RS, BFD-SSB, and BFD-CSI-RS.

[0037] The engine 330 described above, as an application (e.g., a program) executed by the processor 305, is merely exemplary. Functions associated with the engine 330 may also be represented as separate components of the base station 300, or as modular components coupled to the base station 300, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. Furthermore, in some base stations, the functions described for the processor 305 are distributed among multiple processors (e.g., a baseband processor, an application processor, etc.). Exemplary implementations can be implemented according to any of these or other configurations of the base station.

[0038] Memory 310 may be a hardware component configured to store data related to operations performed by base station 300. I / O device 315 may be a hardware component or port enabling a user to interact with base station 300. Transceiver 320 may be a hardware component configured to exchange data with UE 110 and any other UE in system 100. Transceiver 320 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). Therefore, transceiver 320 may include one or more components (e.g., radio components) to enable data exchange with various networks and UEs.

[0039] As described above, the exemplary implementation involves beam management. The term "beam management" can encompass a variety of different processes, including but not limited to BFD, BFR, and CBD. For BFD, a base station (e.g., gNB 120A) can configure a BFD reference signal, and UE 110 can collect measurement data based on the BFD reference signal. When a beam failure trigger condition has been met, UE 110 can declare a beam failure. For example, a beam failure condition may include a configured threshold being reached before a configured timer expires, indicating that the number of beam failure instances from the physical layer has reached a configured threshold. The beam failure instance indication may be based at least in part on measurement data collected from the BFD reference signal.

[0040] To distinguish between different beam management procedures, the reference signal used for BFD may be referred to as BFD-CSI-RS and BFD-SSB. However, the use of the terms "BFD-CSI-RS" and "BFD-SSB" is provided for illustrative purposes only. Exemplary embodiments can be applied to BFD performed based on any suitable type of reference signal.

[0041] After declaring a beam failure event, UE 110 may identify candidate beams and trigger a BFR procedure. For a CBD, the beam may be configured with a CBD reference signal, and UE 110 may collect measurement data based on the CBD reference signal. UE 110 may then identify one or more beams and report the candidate beam information to the network by transmitting a BFR request. UE 110 may then monitor responses to the BFR request transmitted on one of the candidate beams identified by UE 110. The BFR request and the response to the BFR request may be part of a Random Access Channel (RACH) procedure. When the RACH procedure is completed, BFR can be considered complete. The above example is provided for illustrative purposes only, and the term "CBD" may refer to any procedure in which UE 110 searches for beams that can be used by the network to provide information and / or data to UE 110.

[0042] To distinguish between different beam management procedures, the reference signal used for CBD may be referred to as CBD-CSI-RS and CBD-SSB. However, the use of the terms "CBD-CSI-RS" and "CBD-SSB" is provided for illustrative purposes only. Exemplary embodiments can be applied to CBD performed based on any suitable type of reference signal.

[0043] The exemplary implementation introduces a technique for reducing the amount of time that the data exchange processing activity modes of UE 110 are used for beam management processes (e.g., BFD, CBD, BFR, etc.) related to beam recovery. For example, under normal circumstances, network-scheduled BFD and CBD resources can be processed by UE 110 regardless of the likelihood of a beam failure event. Therefore, UE 110 often utilizes the data exchange processing activity modes to monitor and process BFD and CBD resources, even when a beam failure event is unlikely to occur. This is an inefficient use of UE 110's power source. The exemplary implementation enables UE 110 to partially or fully enable certain beam recovery-related processes (e.g., BFD, BFR, CBD) based on UE 110 alone, rather than solely relying on network-scheduled resources.

[0044] As will be described in detail below, multiple observation points and / or measurement data points can be used in a heuristic approach to filter network-scheduled beam recovery resources (e.g., BFD-CSI-RS, BFD-SSB, CBD-CSI-RS, CBD-SSB, etc.). For example, different combinations of observation points and / or measurement data points can be used to predict the likelihood or probability of a beam failure event during a subsequent time window. When a beam failure event is likely to occur, all network-scheduled beam recovery resources can be processed by UE 110 during that time window. When a beam failure event is unlikely to occur, a portion of the beam recovery resources can be processed by UE 110 during that time window. The extent of partial processing can be based on predefined conditions related to UE 110 power source and UE 110 temperature. Therefore, in some implementations, when UE 110 is concerned about its power source and / or temperature, UE 110 can exclude more beam recovery resources from processing and utilize inactive sleep modes to save power and / or for thermal recovery.

[0045] When deployed, each individual UE may have different sensitivities to beam failures. For example, the characteristics of each UE (e.g., UE size, number of RF panels, etc.) may make the device more or less susceptible to beam failures. Additionally, how the UE will be used may also have an impact on beam failure events, as UE movement (e.g., mobility, rotation, etc.) may make the device more susceptible to beam failures. An exemplary implementation introduces a beam failure prediction mechanism that can be trained to predict the timing of beam failures for devices with certain characteristics or that will be used in a particular manner.

[0046] Figure 4 A method 400 for training a beam fault prediction mechanism is illustrated according to various exemplary embodiments. As mentioned above, each individual UE may have different sensitivities to beam faults. Method 400 demonstrates how to train a beam fault prediction mechanism 235 to predict beam fault events for a specific UE or a specific type of UE. (See reference...) Figure 5 As shown in method 500, once trained, this beam fault prediction mechanism 235 can be used by UE 110 to determine whether to utilize the active mode of data exchange processing for beam recovery purposes.

[0047] The training of beam fault prediction mechanism 235 will be described from the perspective of UE 110. In one example, this training may occur before UE 110 is deployed by the end user. For example, the manufacturer or a third party may train mechanism 235 based on certain device characteristics (e.g., size, number of RF panels, etc.) and / or simulate the motions expected to be experienced by a particular type of device (e.g., mobility, rotation, etc.). Once trained, UE 110 can be configured with beam fault prediction mechanism 235 trained for the device characteristics and expected behavior of UE 110. In another example, beam fault prediction mechanism 235 may be trained when UE 110 is deployed by the end user. For example, training may be performed in the background when UE 110 is deployed by the end user, or training may be based on data collected by UE 110 at the time of deployment. Training may be a continuous process throughout the lifecycle of UE 110, or UE 110 may be pre-configured with a trained beam fault prediction mechanism 235 that may or may not be updated remotely. However, any references to training occurring in a particular manner are provided for illustrative purposes only. Exemplary implementations may train and / or configure beam fault prediction mechanism 235 in any suitable manner.

[0048] In step 405, a subset of parameters is selected for the supervised learning phase. For example, beam failure prediction mechanism 235 may be initially deployed during the training phase to learn the dependencies of parameters on beam failure timing. To provide an example, UE 110 can be deployed and interact with the network in several different ways. Upon deployment, UE 110 can monitor beam failure indications and record observations and / or measurement data points associated with a set of parameters. This information can indicate which parameters are relevant to beam failure recovery for a specific UE or UE type (e.g., UE 110, etc.).

[0049] This set of parameters includes, but is not limited to, the status of the lookup table for candidate beams used for the serving cell in Radio Resource Control (RRC) connectivity mode, temperature sensor parameters, power source parameters, UE 110 battery status, motion sensor parameters (e.g., gyroscope, accelerometer), CSI-SSB-based Layer 1 (L1) reference signal received power (RSRP), CSI-SSB-based L1 signal-to-interference-plus-noise ratio (SINR), CSI-RS-based L1-RSRP, CSI-RS-based L1-RSRP, BFD-SSB-based hypothetical physical downlink control channel BLER, BFD-CSI-RS-based hypothetical physical downlink control channel BLER, RLM-SSB-based hypothetical physical downlink control channel BLER, RLM-CSI-RS-based hypothetical physical downlink control channel BLER, UE channel parameters estimated based on tracking reference signal (TRS), and demodulation reference signal (DMRS) resources for indication of Doppler / delay spread. A subset of these parameters can then be selected for further training. The example parameters above are provided for illustrative purposes only, and the exemplary implementation can utilize any appropriate parameters to train the beam failure prediction mechanism 235.

[0050] In step 410, beam failure prediction mechanism 235 is trained based on a subset of parameters. This can be referred to as the supervised learning phase. Here, beam failure prediction mechanism 235 can learn combinations and / or weights of parameters to predict beam failure events dependent on the device and / or user. For example, parameters such as L1-RSRP, L1-SINR, TRS, DMRS, motion sensor data, RLM BLER, and BFD BLER measurements can be used to learn relevant weights for beam failure events for a specific UE or UE type (e.g., UE 110, etc.).

[0051] In step 415, trained coefficients are generated to predict the probability of beam failure events. These trained coefficients can be generated from a supervised learning phase and represent the relevant weights corresponding to the subset of parameters. Reference will be made below. Figure 5 The trained coefficients described herein can be used to predict beam failure events when the UE 110 is deployed by the end user.

[0052] Figure 5 A method 500 for high-efficiency beam recovery operation according to various exemplary embodiments is shown. (Refer to...) Figure 2 UE 110 and Figure 1 The network layout is described by method 500 using 100.

[0053] In step 505, UE 110 receives beam failure prediction configuration information. This configuration information can be used by beam failure prediction mechanism 235 to determine a probability metric for potential beam failure events. For example, the beam failure prediction configuration information may include parameters, observation points, and / or measurement data points that indicate a beam failure event will occur. Additionally, the beam failure prediction configuration information may include trained coefficients, thresholds, counters, or frequency values ​​that can be used in association with the parameters, observation points, and / or measurement data points to determine the probability metric for potential beam failure events.

[0054] As described above, UE 110 may be configured with this configuration information, UE 110 may receive this configuration information from a network or a third party, and / or UE 110 may generate this configuration information itself. Exemplary implementations are suitable for providing beam fault prediction configuration information to UE 110 in any appropriate manner.

[0055] In 510, UE 110 monitors various parameters associated with beam failure events. In this example, parameters may include L1-RSRP, L1-SINR, TRS, DMRS, motion sensor data, RLM BLER, and BFD BLER. However, these parameters are provided for illustrative purposes only, and exemplary embodiments can be applied to predict the occurrence of beam failure events using one or more parameters of any type.

[0056] In 515, UE 110 determines a probability metric for the occurrence of beam failure events. The probability metric can be based on observation points and / or measurement data points associated with parameters tracked in 510. Additionally, the parameters can be weighted using trained coefficients. Observation points and / or measurement data points can be monitored over time at specific frequencies for alarm indications, threshold crossings, and / or gradient crossings to determine the probability metric. The probability metric can be dynamically updated based on changing observation points.

[0057] Throughout this specification, probability measures can be characterized as “high probability,” “medium probability,” and “low probability.” Each of these categories can represent a range of values ​​or conditions. However, reference to the three categories is provided merely for illustrative purposes. Exemplary embodiments can characterize the likelihood of beam failure events in any suitable manner.

[0058] In section 520, UE 110 determines power source metrics. For example, UE 110 may monitor battery life and determine the amount of power available to UE 110. As will be described in more detail below, power source metrics can be used to control the amount of active data exchange processing performed by UE 110 for beam recovery purposes.

[0059] In 525, UE 110 determines thermal metrics. For example, UE 110 may be equipped with a sensor that monitors the thermal level of UE 110. As will be described in more detail below, thermal metrics can be used to control the amount of active data exchange processing performed by UE 110 for beam recovery purposes.

[0060] In section 530, UE 110 determines an existing list of candidate beams. For example, UE 110 can be configured by the network to evaluate certain candidate beams relative to the measured RSRP. This can be used for a fallback solution if the probability metric indicates that a beam failure is unlikely to occur, such as a high probability of beam failure. Therefore, even if some beam recovery procedures may be disabled or suppressed, UE 110 will have the opportunity to trigger a recovery procedure on previously measured candidate beams.

[0061] In 535, UE 110 implements a beam management power saving scheme. UE 110 can be configured with multiple different beam management power saving schemes and can select one of the power saving schemes based on probability metrics, power source metrics, thermal metrics, and / or any other appropriate information. The beam management power saving scheme determines the amount of time UE 110 uses for the beam recovery process based on the activity mode of data exchange processing.

[0062] As described above, method 500 is a continuous and dynamic process. Therefore, probability metrics, thermal metrics, and power source metrics can be monitored and updated during operation. Consequently, the beam management power saving scheme can also be updated to adapt to the current conditions of UE 110. This allows UE 110 to find a sufficient balance between beam recovery, performance, and power saving.

[0063] In 540, UE 110 performs the beam recovery process according to a beam management power saving scheme. The beam management power saving scheme provides a trade-off between the probability of beam failure and an existing list of candidate beams relative to the power and temperature alarms of UE 110, in order to select the activity level for candidate beam detection and beam recovery.

[0064] When there is a high probability of a beam failure event, UE 110 can perform the beam recovery process in a default manner. Therefore, UE 110 can utilize the activity mode of data exchange processing to monitor and process beam recovery resources scheduled by the network (e.g., CBD-SSB, CBD-CSI-RS, BFD-SSB, BFD-CSI-RS, etc.).

[0065] When a moderate or low probability exists, partial processing of beam recovery resources can be performed. Therefore, instead of using the active mode of data exchange processing to monitor and process network-scheduled resources, UE 110 can utilize an inactive sleep mode when network-scheduled beam recovery resources (e.g., CBD-SSB, CBD-CSI-RS, BFD-SSB, BFD-CSI-RS, etc.) are expected to arrive at UE 110. In some implementations, instead of utilizing the inactive sleep mode, UE 110 can omit or discard network-scheduled beam recovery resources.

[0066] For example, during CBD-SSB transmission, four Orthogonal Frequency Division Multiplexing (OFDM) symbols may be occupied without any other data. Therefore, only CBD-SSB symbols can be repeatedly occupied over time. In some cases, up to 56 candidate beams may be scheduled by the network, and each candidate beam may require multiple CBD-SSBs to allow for time filtering. Therefore, a large number of OFDM symbols need to be processed for beam failure recovery. A beam management power-saving scheme allows UE110 to process these symbols only when necessary for beam recovery.

[0067] On the other hand, exemplary implementations involve enabling and disabling certain beam management procedures based on RLM. For example, an RLM-BLER condition can be implemented to trigger a temporary and complete suspension of BFD and CBD procedures on UE 110.

[0068] Figure 6 A method 600 for selectively enabling a beam recovery process is illustrated according to various exemplary embodiments. (Refer to...) Figure 2 UE 110 and Figure 1 The network layout is described by method 600 using 100.

[0069] In 605, UE 110 generates an RLM BLER metric. The RLM BLER metric can be an instantaneous or average BLER value during a time window.

[0070] In 610, UE 110 determines that the RLM BLER metric meets predetermined conditions. For example, UE 110 may be configured with a threshold. If the RLM BLER metric is below this threshold, this can indicate to UE 110 that a beam failure event is unlikely to occur.

[0071] In 615, UE 110 temporarily disables certain beam fault recovery procedures (e.g., CBD, BFD, etc.). This allows UE 110 to utilize an inactive sleep mode even when network resources (such as, but not limited to, CBD-SSB, CBD-CSI-RS, BFD-SSB, BFD-CSI-RS) are scheduled by the network. In some implementations, instead of utilizing an inactive sleep mode, UE 110 may omit or discard network-scheduled beam recovery resources.

[0072] In step 620, UE 110 determines that the RLM BLER metric no longer meets predetermined conditions. For example, if the RLM BLER metric is higher than a threshold, this can indicate to UE 110 that a beam failure event may have occurred.

[0073] In 625, UE 110 activates the disabled beam fault recovery procedure. Therefore, the BFD and CBD procedures can be selectively enabled and disabled to provide power savings to UE 110 or to reduce equipment temperature.

[0074] Those skilled in the art will understand that the exemplary embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Exemplary embodiments of the methods described above may be embodied as programs comprising lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0075] Although this patent application describes various combinations of various embodiments, each with different features, those skilled in the art will understand that any feature of an embodiment can be combined with features of other embodiments or features that are not functionally or logically inconsistent with the operation or function of the device of the disclosed embodiment of the invention in any manner not explicitly denied.

[0076] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0077] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A method executed by a user equipment (UE), the method comprising: A probability metric for determining the likelihood of a beam failure event at the UE, wherein the probability metric is based on coefficients trained over time, and the coefficients are determined based on at least one parameter associated with a measured characteristic of at least one signal received by the UE. Based on at least one of power source metric and thermal metric and the probability metric, a beam management power saving scheme is selected from multiple beam management power saving schemes; Trigger the selected beam management power saving scheme; as well as Within a time window, a portion of the network-scheduled beam recovery resources are processed based on the triggered beam management power.

2. The method of claim 1, wherein processing the portion of the beam recovery resources scheduled by the network includes utilizing an inactive dormant mode when one or more beam recovery resources are scheduled by the network.

3. The method of claim 1, wherein the beam recovery resource includes a channel state information (CSI) reference signal (RS) or a synchronization signal block (SSB) configured for beam fault detection (BFD).

4. The method of claim 1, wherein the beam recovery resource includes a channel state information (CSI) reference signal (RS) or a synchronization signal block (SSB) configured for candidate beam detection (CBD).

5. The method of claim 1, wherein the at least one parameter includes at least one of the following: Layer 1 L1 reference signal received power RSRP, L1 signal-to-interference-plus-noise ratio SINR, tracking reference signal TRS, demodulation reference signal DMRS, motion sensor parameters, radio link monitoring RLM block error rate BLER, and beam fault detection BFD BLER.

6. The method of claim 1, wherein the portion of the beam recovery resources scheduled by the network is based on a power source metric associated with the UE.

7. The method of claim 1, wherein the portion of the beam recovery resources scheduled by the network is based on thermal metrics associated with the UE.

8. A user equipment (UE), comprising: A transceiver configured to communicate with a network; as well as A processor, communicatively coupled to the transceiver and configured to perform operations including: A probability metric for determining the likelihood of a beam failure event at the UE, wherein the probability metric is based on coefficients trained over time, and the coefficients are determined based on at least one parameter associated with a measured characteristic of at least one signal received by the UE over time. The triggered management power saving scheme is implemented based on the probability metric, wherein the triggered management power saving scheme is selected from a plurality of beam management power saving schemes based on at least one of the power source metric and the thermal metric. as well as Within a time window, a portion of the network-scheduled beam recovery resources are processed based on the triggered beam management power.

9. The UE of claim 8, wherein processing a portion of the beam recovery resources scheduled by the network includes utilizing an inactive sleep mode when one or more beam recovery resources are scheduled by the network.

10. The UE of claim 8, wherein the beam recovery resource includes a channel state information (CSI) reference signal (RS) or a synchronization signal block (SSB) configured for beam fault detection (BFD).

11. The UE of claim 8, wherein the beam recovery resource includes a channel state information (CSI) reference signal (RS) or a synchronization signal block (SSB) configured for candidate beam detection (CBD).

12. The UE of claim 8, wherein the at least one parameter includes at least one of the following: Layer 1 L1 reference signal received power RSRP, L1 signal-to-interference-plus-noise ratio SINR, tracking reference signal TRS, demodulation reference signal DMRS, motion sensor parameters, radio link monitoring RLM block error rate BLER, and beam fault detection BFD BLER.

13. The UE of claim 8, wherein the portion of the beam recovery resources scheduled by the network is based on a power source metric associated with the UE.

14. The UE of claim 8, wherein the portion of the beam recovery resources scheduled by the network is based on thermal metrics associated with the UE.

Images