Methods and apparatus for beam failure management and training machine learning models

Abstract

A method and apparatus (100) for beam fault management of a user equipment (UE) (104) are described. A beam fault instance counter (BFI_counter) is determined, indicating the number of consecutive beam fault instances occurring at the UE (104) at a given time. The location of the UE (104) at that time is determined. A beam fault probability factor is determined based at least on the location of the UE (104) at that time and the BFI_counter. The beam fault probability factor indicates the probability that a beam fault will occur at that location after several other times. Furthermore, the beam fault probability factor is compared with a beam fault threshold probability (beamFailureThresholdProb). Subsequently, if the beam fault probability factor is higher than beamFailureThresholdProb, a beam fault is declared.

Description

Technical Field

[0001] Various example embodiments relate to methods and systems for beam fault management. Background Technology

[0002] In 5G networks, for effective communication, downlink transmissions to different terminal devices located in different directions relative to network equipment are time-separated. Therefore, beam management is used in 5G networks to establish and maintain appropriate beam pairs—that is, the transmitter-side beam direction and the corresponding receiver-side beam direction—which together provide a good connection between the network equipment and the terminal devices. Beam management includes an initial beam setup process, a beam adjustment process, and a beam recovery process. The initial beam setup process includes a set of procedures and functions through which beam pairs are initially established in the downlink and uplink transmission directions, for example, during connection establishment. The beam adjustment process is used to compensate for the movement and rotation of terminal devices and gradual changes in the environment. The beam recovery process is used to restore beam connectivity when the current beam pair is interrupted due to rapid changes in the environment.

[0003] Typically, after the initial phase of beamforming, the movement of the terminal device and changes in the environment can cause the currently established beam pair to become congested due to insufficient time for regular beam adjustments. Therefore, this congestion of the currently established beam pair results in a beam failure event. Furthermore, the terminal device declares a beam failure event when the error probability of the Physical Downlink Control Channel (PDCCH) exceeds a certain value. It should be noted that the concept of beam failure is similar to the concept of Radio Link Failure (RLF), which has been defined for current radio access technologies such as LTE. Similar to RLF, the terminal device declares a beam failure based on measurements of the quality of some reference signal. This is often expressed as an error rate of the measurement assumption. Additionally, the terminal device declares a beam failure based on measurements of the Layer 1 (L1) Reference Signal Received Power (RSRP) of the Periodic Channel State Information Reference Signal (CSI-RS) or Synchronization Signal (SS) block, i.e., L1-RSRP.

[0004] For each moment, a measurement L1-RSRP below the configured value is defined as a beam failure instance. In one case, if the number of consecutive beam failure instances exceeds the configured value, the terminal device declares a beam failure and initiates a beam recovery process. However, in areas with severe attenuation and vulnerable to congestion, the terminal device may wait for N consecutive beam failure instances, thus causing unnecessary delays when declaring a beam failure. Furthermore, in critical events requiring strict latency, such as Ultra-Reliable Low-Latency Communication (URLLC), unnecessary delays in declaring beam failures can disrupt the latency budget.

[0005] Furthermore, in the case of narrow beams, beam failures (i.e., connection loss due to rapid degradation of established beam pairs) are expected to occur more frequently compared to RLF (Remotely Residual Beam Failure), which typically corresponds to the terminal device moving out of the coverage area of ​​the current serving cell. RLF usually means loss of coverage of the current serving cell, in which case a connection to a new cell must be re-established.

[0006] Currently, one or more methods are employed to overcome the aforementioned beam failure events. In one scenario, after a beam failure, a new beam pair within the current cell is often used to re-establish the connection. Therefore, recovery from beam failure can be achieved using lower-layer functions, which results in faster recovery compared to higher-layer mechanisms used for recovery from RLF.

[0007] In another scenario, the New Radio (NR) specification includes a specific procedure for handling such beam failure events, also known as beam failure recovery. The beam failure recovery procedure includes steps of beam failure declaration, candidate beam identification, recovery request transmission, and network response. In the beam failure declaration, the terminal device is configured to declare that a beam failure has occurred. In candidate beam identification, the terminal device is configured to identify new beam pairs to restore connectivity. In the recovery request transmission, the terminal device is configured to send a beam recovery request to the network and then receive the network's response to the beam recovery request. Additionally, the RLF recovery procedure is used to recover from beam failure events.

[0008] However, the aforementioned techniques for declaring beam faults can lead to unnecessary delays. Therefore, an improved method and device are needed to manage beam faults in 5G networks to minimize latency during the beam fault recovery process. Summary of the Invention

[0009] According to an example embodiment, a method for beam fault management for a user equipment (UE) may be disclosed. The method may include determining a beam fault instance counter (BFI_counter) indicating the number of consecutive beam fault instances at the UE at a given time, determining the location of the UE at that time, and determining a beam fault probability factor based at least on the location of the UE and the BFI_counter, wherein the beam fault probability factor indicates the probability that a beam fault will occur at that location of the UE after a plurality of further times.

[0010] In one example embodiment, determining the UE's location at a given moment may include receiving the UE's location from the network device or using radio frequency (RF) fingerprinting to determine the UE's location. In another example embodiment, using RF fingerprinting, UE radio measurements such as Reference Signal Received Power (RSRP) can be correlated with the UE's location. This provides the advantage of eliminating the need for transmission of UE location information from the network device to the UE.

[0011] The method may further include comparing a beam failure probability factor with a beam failure threshold probability beamFailureThresholdProb, and declaring a beam failure if the beam failure probability factor is higher than beamFailureThresholdProb. Declaring a beam failure may include initiating a beam recovery procedure, particularly a random access procedure for beam failure recovery. It should be noted that the beam failure probability factor can be determined using a trainable machine learning (ML) model. This beam failure declaration by the UE helps minimize latency in initiating the beam recovery procedure for beam failure recovery.

[0012] According to another example embodiment, the method can be performed at the UE. The method may include the steps of: receiving a request from a network device to activate an ML-based function, receiving beamFailureThresholdProb and a trainable ML model from the network device, wherein the step of determining the UE's location at that moment may further include: requesting and receiving the UE's location at that moment from the network device if BFI_counter > 0. BFI_counter is determined by counting beam failure instances indicated by the UE. In one example embodiment, BFI_counter can be determined by counting beam failure instances indicated by one or more layers of the UE. These one or more layers may be associated with a Media Access Control (MAC) layer that provides Radio Resource Management (RRM) services to the network device and the UE. Furthermore, these one or more layers may be, but are not limited to, lower layers, higher layers, or MAC layers such as the physical layer.

[0013] According to yet another example embodiment, the method can be performed at the network device and a BFI_counter can be received from the UE.

[0014] According to another example embodiment, a method for training a machine learning (ML) model at a network device can be disclosed. The method may include: receiving from at least one user equipment (UE) multiple UE locations and a threshold beamFailureInstanceMaxCount, the threshold indicating the maximum number of consecutive beam failure instances; determining a training set by labeling pairs including UE locations and a beam failure instance counter BFI_counter using a beam failure probability factor, wherein BFI_counter takes values ​​between 1 and the threshold beamFailureInstanceMaxCount; and training the ML model using the labeled training set.

[0015] It should be understood that, for each UE location and each beam fault instance counter BFI_counter, the beam fault probability factor can be defined at least based on BFI_counter and UE location. Specifically, the beam fault probability factor is defined as:

[0016]

[0017] Where beamFailureProb is the beam failure probability factor, BFI_COUNTER is the beam failure instance counter, and location (X, Y) is the UE location. In one example embodiment, the UE location may correspond to the area surrounding location (X, Y).

[0018] In addition, an ML model can be trained to minimize a loss function that defines the relationship between a beam failure probability factor and a beam failure probability, which indicates the probability that a beam failure will occur at the UE location after a given value of beamFailureInstanceMaxCount for BFI_counter.

[0019] According to yet another example embodiment, an apparatus for beam fault management may be disclosed. The apparatus may include components for performing: determining a beam fault instance counter (BFI_counter) indicating the number of consecutive beam fault instances occurring at a user equipment (UE) at a given time; determining the location of the UE at that time; and determining a beam fault probability factor based at least on the location of the UE and the BFI_counter, wherein the beam fault probability factor indicates the probability of a beam fault occurring at that location of the UE after a plurality of further times.

[0020] In one example embodiment, determining the UE's location at a given moment may include receiving the UE's location from the network device or using radio frequency (RF) fingerprinting to determine the UE's location. In another example embodiment, using RF fingerprinting, UE radio measurements such as Reference Signal Received Power (RSRP) can be correlated with the UE's location. This provides the advantage of eliminating the need for transmission of UE location information from the network device to the UE.

[0021] The device may also include components for performing: comparing a beam failure probability factor with a beam failure threshold probability beamFailureThresholdProb, and declaring a beam failure if the beam failure probability factor is higher than beamFailureThresholdProb. Declaring a beam failure may include components for performing: initiating a beam recovery process, particularly a random access procedure for beam failure recovery. It should be noted that the beam failure probability factor can be determined using a trainable machine learning (ML) model. This declaration of a beam failure for the UE helps minimize latency during the beam recovery process initiating beam failure recovery.

[0022] According to another example embodiment, the device may be a UE and may be configured to: receive a request from a network device for activating an ML-based function, receive beamFailureThresholdProb and a trainable ML model from the network device, wherein the step of determining the UE's position at that moment may further include: requesting and receiving the UE's position at that moment from the network device if BFI_counter > 0. BFI_counter is determined by counting beam failure instances indicated by the UE. In one example embodiment, BFI_counter may be determined by counting beam failure instances indicated by one or more layers of the UE. One or more layers may be associated with a Media Access Control (MAC) layer that provides Radio Resource Management (RRM) services to the network device and the UE. Furthermore, one or more layers may be, but are not limited to, lower layers, higher layers, or MAC layers such as the physical layer.

[0023] According to yet another example embodiment, the device may be a network device and may also be configured to receive a BFI_counter from a UE.

[0024] According to another example embodiment, an apparatus for training a machine learning (ML) model may be disclosed. The apparatus may include components for performing: receiving from at least one user equipment (UE) a plurality of UE locations and a threshold beamFailureInstanceMaxCount, the threshold indicating the maximum number of consecutive beam failure instances; determining a training set by labeling pairs including UE locations and a beam failure instance counter (BFI_counter) using a beam failure probability factor, wherein BFI_counter takes values ​​between 1 and a threshold; and training an ML model using the labeled training set.

[0025] It should be understood that, for each UE location and each beam fault instance counter BFI_counter, a beam fault probability factor can be defined at least based on BFI_counter and UE location, specifically defined as:

[0026]

[0027] Where beamFailureProb is the beam failure probability factor, BFI_COUNTER is the beam failure instance counter, and location (X, Y) is the UE location. In one example embodiment, the UE location may correspond to the area surrounding location (X, Y).

[0028] In addition, an ML model can be trained to minimize a loss function that defines the relationship between a beam failure probability factor and a beam failure probability, which indicates the probability of a beam failure occurring at the UE location after a given value of beamFailureInstanceMaxCount for BFI_counter.

[0029] According to another example embodiment, a non-transient computer-readable medium may be disclosed. This non-transient computer-readable medium may include instructions for causing a processor to perform functions, including determining a beam failure instance counter (BFI_counter) indicating the number of consecutive beam failure instances occurring at a user equipment (UE) at a certain time, determining the location of the UE at that time, and determining a beam failure probability factor based at least on the location of the UE and the BFI_counter, wherein the beam failure probability factor indicates the probability that a beam failure will occur at that location after a plurality of other times.

[0030] In one example embodiment, determining the UE's location at a given moment may include receiving the UE's location from the network device or using radio frequency (RF) fingerprinting to determine the UE's location. In another example embodiment, using RF fingerprinting, such as UE radio measurements of Reference Signal Received Power (RSRP), can be correlated with the UE's location. This provides the advantage of eliminating the need for transmission of UE location information from the network device to the UE.

[0031] Furthermore, the non-transient computer-readable medium includes instructions for causing the processor to perform functions, including comparing a beam failure probability factor with a beam failure threshold probability beamFailureThresholdProb, and declaring a beam failure if the beam failure probability factor is higher than beamFailureThresholdProb. Declaring a beam failure may include initiating a beam recovery procedure, particularly a random access procedure for beam failure recovery. It should be understood that the beam failure probability factor can be determined by a trainable machine learning (ML) model. This declaration of a beam failure for the UE helps minimize the latency of initiating the beam recovery procedure for beam failure recovery.

[0032] According to another example embodiment, the non-transient computer-readable medium includes instructions for causing a processor to perform functions at the UE. The non-transient computer-readable medium includes instructions for causing the processor to perform functions including receiving a request from a network device to activate an ML-based function, receiving a beamFailureThresholdProb and a trainable ML model from the network device, wherein the step of determining the UE's location at that moment may further include: requesting and receiving the UE's location at that moment from the network device if BFI_counter > 0. BFI_counter is determined by counting beam failure instances indicated by the UE. In one example embodiment, BFI_counter can be determined by counting beam failure instances indicated by one or more layers of the UE. One or more layers may be associated with a Media Access Control (MAC) layer that provides Radio Resource Management (RRM) services to the network device and the UE. Furthermore, one or more layers may be, but are not limited to, lower layers, higher layers, or MAC layers such as the physical layer.

[0033] According to yet another example embodiment, a non-transient computer-readable medium includes instructions for causing a processor to perform a function at a network device and including receiving a BFI_counter from a UE.

[0034] According to yet another example embodiment, the non-transient computer-readable medium includes instructions for causing a processor to perform functions including: receiving from at least one user equipment (UE) a plurality of UE locations and a threshold beamFailureInstanceMaxCount, the threshold indicating the maximum number of consecutive beam failure instances; determining a training set by labeling pairs including UE locations and beam failure instance counters (BFI_counter) with a beam failure probability factor, wherein BFI_counter takes a value between 1 and the threshold beamFailureInstanceMaxCount; and training an ML model using the labeled training set.

[0035] It should be noted that for each UE location and each beam fault instance counter BFI_counter, the beam fault probability factor can be defined at least based on BFI_counter and UE location. In particular, the beam fault probability factor is defined as:

[0036]

[0037] Where beamFailureProb is the beam failure probability factor, BFI_COUNTER is the beam failure instance counter, and location (X, Y) is the UE location. In one example embodiment, the UE location may correspond to the area surrounding location (X, Y).

[0038] In addition, an ML model can be trained to minimize a loss function that defines the relationship between a beam failure probability factor and a beam failure probability, which indicates the probability of a beam failure occurring at the UE location after a given value of beamFailureInstanceMaxCount for BFI_counter.

[0039] In summary, the apparatus and algorithm according to the exemplary embodiments described herein allow for the proactive triggering of the random access procedure specified in 3GPP TS38.321. When a beam failure is imminent, a random access procedure is triggered for a UE with ML capabilities (i.e., a UE supporting trainable ML models), instead of waiting for the BFI_counter to reach the predefined beamFailureInstanceMaxCount. While storing ML models requires significant memory and running them demands additional computational power, such an ML-capable UE can operate in intelligent environments. Preferably, to proactively declare beam failures, the disclosed method introduces a beam failure probability factor indicating the probability of a beam failure occurring at a specific UE location. This allows for improved beam failure management in 5G networks, at least based on UE location history, using machine learning (ML) or artificial intelligence (AI) models. The UE location history, as input to the ML model, can help determine aspects of UE mobility and trajectory. Furthermore, such methods and apparatus offer the advantage of minimizing any unnecessary delays in declaring beam failures in areas with deep attenuation or easily congested regions. Additionally, the UE does not wait for predefined consecutive beam failures. Furthermore, the disclosed method improves the performance of existing methods in locations where UEs frequently suffer beam failures. Without using a beam failure probability factor, the UE must wait for a predefined beamFailureInstanceMaxCount, which results in unnecessary time delays in declaring beam failures.

[0040] To achieve the foregoing and related objectives, one or more aspects include the features specifically highlighted in the following description. The following description and figures provide a detailed overview of certain illustrative aspects and indicate only a few of the various ways in which the principles of these aspects can be employed. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the accompanying drawings, and the disclosed aspects are intended to encompass these aspects and their equivalents. Attached Figure Description

[0041] Further embodiments, details, advantages, and modifications of this example embodiment will become apparent from the following detailed description of the embodiments taken in conjunction with the accompanying drawings, wherein

[0042] Figure 1 A network diagram of an apparatus for beam fault management for a user equipment (UE) according to an example embodiment of the subject matter described herein is illustrated.

[0043] Figure 2 The illustration shows a flowchart of a method for beam fault management for a UE, illustrating an example embodiment of the subject matter described herein.

[0044] Figure 3 The diagram illustrates a high-level operation of a method for beam fault management at a user equipment (UE) for initiating a beam recovery process, according to an example embodiment of the subject matter described herein.

[0045] Figure 4A and Figure 4B A flowchart illustrating a method for beam fault management at a user equipment (UE) using a machine learning (ML) model, based on an example embodiment of the subject matter described herein, is shown.

[0046] Figure 4C The diagram illustrates a block diagram of ML model inference based on an example embodiment of the subject described herein.

[0047] Figure 5 The illustration shows a flowchart of a method for training a machine learning (ML) model at a network device, illustrating an example embodiment of the subject matter described herein.

[0048] Figure 6 The diagram illustrates a method for training an ML model at a network device and using the trained ML model for inference, based on an example embodiment of the subject matter described herein.

[0049] Figure 7 The diagram illustrates a signaling diagram for implementing the training of an ML model according to an example embodiment of the subject matter described herein.

[0050] Figure 8The diagram illustrates a signaling diagram of a method for beam fault management according to an example embodiment of the subject matter described herein, wherein ML model inference is performed at the user equipment (UE).

[0051] Figure 9 The diagram illustrates a signaling diagram of a method for beam fault management according to an example embodiment of the subject matter described herein, wherein ML model inference is performed at a network device.

[0052] Figure 10 The diagram illustrates a signaling diagram of a method for beam fault management according to an alternative embodiment of the subject matter described herein, wherein radio measurement-based ML model inference is performed at the user equipment (UE).

[0053] Figure 11 The figure illustrates an example embodiment of the subject matter described herein, showing a scenario in which the beam failure probability factor varies according to the beam failure instance counter (BFI_counter).

[0054] Figure 12 The diagram illustrates another example embodiment of the subject matter described herein, showing a scenario of actively predicting beam failure.

[0055] Figure 13 The diagram illustrates another example embodiment of the subject matter described herein, showing a scenario where the method for beam fault management provides instantaneous gain. Detailed Implementation

[0056] Some embodiments of this disclosure that illustrate its features will now be discussed in detail. The terms “comprising,” “having,” “including,” and “including,” as well as other forms of the term, are equivalent in meaning and are open-ended, because one or more items following any of these terms are not intended to be an exhaustive list of such items or items, or to be limited to the listed items.

[0057] It should also be noted that, as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context otherwise requires. Although any apparatus and methods similar to or equivalent to those described herein may be used in the practice or testing of embodiments of this disclosure, such apparatus and methods are described hereafter.

[0058] Embodiments of the present disclosure will be described more fully below with reference to the accompanying drawings, in which the same numerals denote the same elements in multiple figures, and exemplary embodiments are illustrated in the drawings. However, embodiments of the claims may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. The examples set forth herein are non-limiting examples and are merely examples of other possible examples.

[0059] By referring to the attached figures Figures 1 to 13 To understand the exemplary embodiments of this disclosure and their potential advantages, the same reference numerals are used for the same and corresponding parts of the various figures.

[0060] Figure 1 The illustration shows a network diagram of an apparatus 100 for beam fault management according to an example embodiment. Apparatus 100 includes a network device 102 connected to a terminal device 104 via a communication network (not shown). The communication network can be implemented using at least one communication technology selected from, but not limited to, the following: Visible Light Communication (VLC), Global Microwave Access Interoperability (WiMAX), Long Term Evolution (LTE), Wireless Local Area Network (WLAN), Infrared (IR) Communication, Public Switched Telephone Network (PSTN), radio waves, and any other wired and / or wireless communication technology.

[0061] Network device 102 may be, but is not limited to, a Wi-Fi access point, a base station, a gNb, an eNodeB (eNB), or a radio station. Network device 102 may send information to terminal device 104. In one example embodiment, this information may be related to the location of terminal device 104. Furthermore, network device 102 may host the training and learning of models, such as, but not limited to, machine learning (ML) models and deep learning models. Additionally, network device 102 may include multiple antennas, which can be used to generate different beams for terminal device 104 using these antennas placed in different directions. In one example embodiment, network device 102 may be a 3GPP 5G Next Generation Base Station (gNB or gNodeB) supporting 5G New Radio (NR), such as... Figure 1 As shown.

[0062] In addition, network device 102 may include a processor (not shown) and memory (not shown). The processor includes appropriate logic, circuitry, and / or interfaces that can be used to execute instructions stored in the memory to perform various functions. The processor may execute algorithms stored in the memory for beam fault management. The processor may also be configured to decode and execute any instructions received from one or more other electronic devices or servers. The processor may include one or more general-purpose processors (e.g., or Advanced Micro (AMD) microprocessors) and / or one or more dedicated processors (e.g., digital signal processors or The processor can also be configured to execute one or more computer-readable program instructions, such as program instructions that perform any of the functions described herein.

[0063] Memory stores a set of instructions and data. Furthermore, memory includes one or more instructions that can be executed by a processor to perform specific operations. Some common known memory implementations include, but are not limited to, fixed (hard disk) drives, magnetic tape, floppy disks, optical disks, compact disc read-only memory (CD-ROM) and magneto-optical disks, semiconductor memories such as ROM, random access memory (RAM), programmable read-only memory (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, magnetic cards or optical cards, cloud computing platforms (such as Microsoft Azure and Amazon Web Services, AWS), or other types of media / machine-readable media suitable for storing electronic instructions.

[0064] Terminal device 104 may be a user equipment (UE) directly used by an end user for communication. Hereinafter, terminal device 104 may be referred to as UE 104. In an example embodiment, UE 104 corresponds to a smartphone, such as... Figure 1 As shown. UE 104 can be, but is not limited to, a computer, telephone, desktop computer, personal digital assistant (PDA), or laptop computer. Furthermore, UE 104 may include input or output interfaces, such as a display screen, touchscreen, antenna, and / or microphone. In one example embodiment, the touchscreen may correspond to at least one of a resistive touchscreen, a capacitive touchscreen, or a thermal touchscreen.

[0065] Furthermore, UE 104 may include processor 106 and memory 108. Processor 106 includes appropriate logic, circuitry, and / or interfaces operable to execute instructions stored in memory 108 to perform various functions. Processor 106 may execute algorithms for beam fault management stored in memory 108. Processor 106 may also be configured to decode and execute any instructions received from one or more other electronic devices or servers. Processor 106 may include one or more general-purpose processors (e.g., or Advanced Micro (AMD) microprocessors) and / or one or more dedicated processors (e.g., digital signal processors or The processor 106 can also be configured to execute one or more computer-readable program instructions, such as program instructions that perform any of the functions described herein.

[0066] Memory 108 stores a set of instructions and data. Furthermore, memory 108 includes one or more instructions executable by processor 106 to perform specific operations. Some common known memory implementations include, but are not limited to, fixed (hard disk) drives, magnetic tape, floppy disks, optical discs, optical disc read-only memory (CD-ROM) and magneto-optical discs, semiconductor memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, magnetic cards or optical cards, cloud computing platforms (such as Microsoft Azure and Amazon Web Services, AWS), or other types of media / machine-readable media suitable for storing electronic instructions.

[0067] It will be apparent to those skilled in the art that the above-described components of network device 102 and UE 104 are provided for illustrative purposes and without departing from the scope of this disclosure.

[0068] refer to Figure 1 Network device 102 and UE 104 can communicate with each other using beam pairs. A beam pair may include a transmitter-side beam direction 110 and a corresponding receiver-side beam direction 112, which together provide good connectivity between network device 102 and UE 104. It should be noted that such communication can occur in a 5G network without departing from the scope of this disclosure. Beam pairs can be established in both downlink and uplink transmission directions, for example, using a set of procedures and functions performed by beam management when a connection is established. After the beam pair is established, movement and rotation of UE 104, as well as gradual changes in the communication network, may cause obstruction of the established beam pair. Therefore, such obstruction of the beam pair may lead to beam failure.

[0069] Figure 2 Flowchart 200 is illustrated, showing the high-level operation of a beam fault management method for UE 104 according to an example embodiment. Combined with... Figure 1 To describe Figure 2 .

[0070] First, in step 202, a beam fault instance counter (BFI_counter) can be determined. The BFI_counter can indicate the number of consecutive beam fault instances at UE 104 at a given time. Subsequently, in step 204, the location of UE 104 at that time can be determined. In one example embodiment, the location of UE 104 can be received from network device 102. In another example embodiment, the location of UE 104 can be determined using a radio frequency (RF) fingerprint. In yet another example embodiment, an RF fingerprint can be used to correlate UE radio measurements, such as Reference Signal Received Power (RSRP), with the location of UE 104. The UE radio measurement can be the Layer 1 (L1) Reference Signal Received Power (RSRP) from the best beam of the serving cell, i.e., L1-RSRP, or L1-RSRP from both the serving cell and neighboring cells. This use of UE radio measurements eliminates the need to receive the location of UE 104 from network device 102. Another advantage of this embodiment is that it eliminates the need to transmit the location of UE 104 from network device 102 to UE 104. Furthermore, UE radio measurements in 5G NR can be performed locally by UE 104. It should be noted that such radio measurements provide a tight mapping between radio measurements and the location of UE 104.

[0071] Subsequently, in step 206, a beam failure probability factor can be determined at least based on the location of UE 104 and the BFI_counter. In one example embodiment, the beam failure probability factor can be determined using a trainable machine learning (ML) model. Furthermore, the beam failure probability factor can indicate the probability of a beam failure occurring at the location of UE 104 after multiple additional time points. Then, in step 208, the beam failure probability factor can be compared with a beam failure threshold probability beamFailureThresholdProb. Based at least on this comparison, if the beam failure probability factor is higher than beamFailureThresholdProb, a beam failure can be declared in step 210. In one example embodiment, beamFailureThresholdProb can be set to a very high value (i.e., 0.9–1) to ensure that the active beam recovery process only begins when the ML model confidence is very high. Thereafter, the beam recovery process can be initiated in step 212. Specifically, a random access procedure can be initiated for beam failure recovery.

[0072] Figure 3 Block diagram 300 is shown, illustrating the high-level operation of a method for beam fault management at UE 104 according to an example embodiment. Figure 3 Combination Figure 1The preferred steps of the method for beam fault management at UE 104 according to a further embodiment are described below. Figure 4A , Figure 4B and Figure 4C As shown in the image.

[0073] First, in block 302, location information of UE 104 is received from network device 102 at a certain moment. In one example embodiment, processor 106 may receive the location information of UE 104 from network device 102. The location information may include the location coordinates of UE 104. Furthermore, in block 304, a BFI_counter is determined at UE 104. In one example embodiment, processor 106 may determine the BFI_counter at UE 104. The BFI_counter may indicate the number of consecutive beam failure instances at the location of UE 104. Subsequently, based at least on the location information of UE 104 at that moment and the BFI_counter, a beam failure probability factor (beamFailureProb) may be determined at block 306. In one example embodiment, beamFailureProb may be determined using a trainable machine learning (ML) model. Furthermore, beamFailureProb may be compared with a beam failure threshold probability (beamFailureThresholdProb). Based at least on this comparison, a beam failure can be declared if the beam failure probability factor is higher than beamFailureThresholdProb. Subsequently, a beam recovery procedure can be initiated in box 308. The beam recovery procedure may include a random access procedure for beam failure recovery. It should be understood that the beam recovery procedure can be used to restore beam connectivity between network device 102 and UE 104 when the current beam pair is interrupted.

[0074] Figure 4A and 4B Flowchart 400 is shown, illustrating a method for beam fault management at UE 104 using a machine learning (ML) model according to an example embodiment. Combined with... Figure 4C Come to Figure 4A and Figure 4B Describe it.

[0075] First, the processor 106 may determine in step 402 whether a beam fault instance indication has been received by the UE 104. In an example embodiment, the beam fault instance indication can be received from a layer (e.g., Figure 4C(As shown in 426). These layers (according to IEEE standards) can describe or control how information moves between two entities (in this case, network device 102 and UE 104). Furthermore, these layers can be associated with the Media Access Control (MAC) layer that provides Radio Resource Management (RRM) services to network device 102 and UE 104. Moreover, these layers can be, but are not limited to, lower layers such as the physical layer, application layer, MAC layer, or higher layers. Subsequently, processor 106 can determine in step 404 whether the beam failure instance counter (BFI_counter) is equal to 0. In one case, if BFI_counter is equal to 0, processor 106 can start or restart the beamFailureDetectionTimer in step 406. The beamFailureDetectionTimer can indicate beam failure detection timing. Then, in step 408, BFI_counter is incremented by 1. In one example embodiment, processor 106 can increment BFI_counter by 1.

[0076] In another scenario, if BFI_counter is not equal to 0, processor 106 may increment BFI_counter by 1 in step 408. Then, in step 410, ML model inference is performed to determine the beam failure probability factor (beamFailureProb). In an example embodiment, processor 106 may perform ML model inference (in...) Figure 4C The value shown in the image is 430) to determine beamFailureProb (in Figure 4C (As shown in Figure 432). In another example embodiment, ML model inference can be performed at UE 104 to declare beam failure. In one example embodiment, beamFailureProb can be determined at least based on the location of UE 104 and BFI_counter. The location of UE 104 can be received from network device 102. In another example embodiment, it can be determined at least based on UE location history and BFI_counter (e.g., 432). Figure 4C (As shown in 428) to determine beamFailureProb. UE location history can include location (X, Y) at time t, location (X, Y) at time t-1, location (X, Y) at time t-2, and so on.

[0077] In another example embodiment, for each set of locations (X(t), Y(t) and X(t-1), Y(t-1)), a vector of beamFailureProb can be determined corresponding to each possible BFI_counter = [1, 2, 3, ... beamFailureInstanceMaxCount]. beamFailureInstanceMaxCount can indicate the maximum number of consecutive beam failure instances. It should be understood that for the same location variable, a higher BFI_counter value may result in a larger beamFailureProb. In one example embodiment, an ML model such as a supervised learning model can be used, where data is collected for each location and UE 104 can be observed at consecutive time points to determine whether a UE beam failure has occurred. Furthermore, the ML model uses each new beam failure instance to predict beamFailureProb. Additionally, the number of instances of beam failure experienced by UE 104 can be determined to calculate the probability. beamFailureProb can be defined as:

[0078] beamFailureProb

[0079] =Pr(beam failure occurs after beamFailureInstanceMaxCount instances | assuming BFI at location (X, Y)) counter =n)

[0080] With the help of the ML model, beamFailureProb can assess the probability of a beam failure occurring after beamFailureInstanceMaxCount based on the UE's current location and BFI_counter. Next, processor 106 can determine in step 412 whether beamFailureProb is greater than or equal to the beam failure threshold probability (beamFailureThresholdProb) or whether BFI_counter is greater than or equal to the maximum count of beam failure instances (beamFailureInstanceMaxCount). In one case, beamFailureThresholdProb can be set to a very high value (i.e., 0.9-1) to ensure that the active beam recovery process only begins when the ML model confidence is very high. In another case, beamFailureInstanceMaxCount can be defined as a threshold for the maximum number of consecutive beam failure instances. In one example embodiment, such a condition can be actively enforced. The following condition can be defined as:

[0081] BFI_COUNTER>=beamFailureInstanceMaxCount

[0082] or

[0083] beamFailureProb>=beamFailureThresholdProb

[0084] In one example embodiment, at location (X, Y), if the consecutive number of beam failures represented by BFI_counter is less than beamFailureInstanceMaxCount, a predicted beam failure with a high probability can be identified. Furthermore, an instance of (beamFailureInstanceMaxCount - BFI_counter) can know in advance that a beam failure will occur after beamFailureInstanceMaxCount beam failure instances.

[0085] Next, if the above conditions are met, a random access procedure is initiated in step 414. In one example embodiment, processor 106 may initiate a random access procedure for beam failure recovery. It should be noted that a beam recovery procedure, i.e., a random access procedure, may be initiated after beamFailureInstanceMaxCount consecutive beam failures. This use of beamFailureInstanceMaxCount ensures the initiation of the beam recovery procedure and prevents any delays beyond beamFailureInstanceMaxCount. Subsequently, processor 106 may determine in step 416 whether the random access procedure has been successfully completed. Based at least on this determination, processor 106 may set BFI_counter to zero and stop beamFailureRecoveryTimer in step 418. Thereafter, in step 420, the beam failure recovery procedure is successfully completed. In one example embodiment, UE 104 may be notified of the completion of the beam failure recovery procedure.

[0086] In another scenario, if the above conditions are not met, then in step 412, processor 106 may determine in step 422 whether beamFailureDetectionTimer has expired. In one scenario, if beamFailureDetectionTimer has expired, processor 106 may reset BFI_counter in step 424. Thereafter, in step 402, processor 106 may again determine whether a beam failure instance indication has been received from the UE 104's layer. In another scenario, if the beam failure detection timer has not expired, processor 106 may directly proceed to step 402.

[0087] Therefore, the performance of the current method is limited to the existing solutions in 3GPP. This use of beamFailureProb eliminates the need to wait for BFI_counter to reach beamFailureInstanceMaxCount.

[0088] Figure 5 A flowchart 500 according to an example embodiment is illustrated, which shows a method for training a machine learning (ML) model at network device 102. First, in step 502, multiple UE locations and a threshold (beamFailureInstanceMaxCount) are received. Multiple UE locations and thresholds can be received from at least one user equipment (UE) 104. The threshold can indicate the maximum number of consecutive beam failure instances. Subsequently, in step 504, a training set can be determined by labeling a pair including UE location and beam failure instance counter BFI_counter using a beam failure probability factor. BFI_counter can take a value between 1 and the threshold. In one example, the threshold (beamFailureInstanceMaxCount) is set to 10 at location (X, Y), and BFI_counter is set to 6. The beam failure probability factor is then determined by observing the number of times a beam failure occurs after more than four time points. Furthermore, if a beam failure occurs, the beam failure probability factor is increased at both the BFI_counter value and the location (X, Y). It is important to note that this method can be repeated for each sampling point location (X, Y) and different values ​​of the UE location and BFI_counter to determine the labeled training set used to train the ML model. In an alternative embodiment, for a specific location, the ML model can be trained using beam failure probability factors from multiple UEs.

[0089] In one example embodiment, training of the ML model can be performed using one or more parameters listed in Table 1. These parameters may include, but are not limited to, position X(t), position Y(t), position X(t-1), position Y(t-1), BFI_counter, and the labeled output beamFailureProb.

[0090]

[0091] Table 1

[0092] As shown in Table 1, during training, for each pair of current and past locations, i.e., UE location history, the beamFailureInstanceMaxCount value of beamFailureProb is determined. Subsequently, for the same current location, different past locations are selected, and the beamFailureInstanceMaxCount value of beamFailureProb is determined again. In an example embodiment, for each UE location and each BFI_counter, the beam failure probability factor can be determined at least based on the BFI_counter and the location (X, Y) of UE 104. The beam failure probability factor can be defined as:

[0093]

[0094] Where beamFailureProb is the beam failure probability factor, BFI_counter is the beam failure instance counter, and position (X, Y) is the UE position.

[0095] In one example embodiment, the UE location may correspond to the region surrounding the location (X, Y) of UE 104. It should be noted that the labeled training set can be populated with more past samples, such as X(t-2), Y(t-2), X(t-3), Y(t-3), etc., to improve the accuracy of the ML model, but at the cost of significant complexity. Subsequently, in step 506, the labeled training set can be used to train the ML model. It should be noted that the definition of the beam failure probability factor described above is provided for illustrative purposes only and does not depart from the scope of this disclosure.

[0096] Figure 6 A block diagram 600 according to an example embodiment is shown, illustrating a method for training an ML model and performing inference using the trained ML model. Combined with... Figure 3 , Figure 4A , Figure 4B , Figure 4C and Figure 5 To describe Figure 6 According to a further embodiment, preferred steps of the method for declaring a beam fault at UE 104 are as follows: Figure 6 As shown in the image.

[0097] This method can be performed in two phases: an offline training phase and an ML model inference phase. First, an offline training phase can be performed at network device 102, where information includes: ML model inputs, such as, but not limited to, UE location history (shown as 602) and BFI_counter (shown as 604), and ML model outputs, such as beamFailureProb (shown as 606). This information can be provided as input to ML model training (shown as 608). The UE location history (shown as 602) as input to the ML model may help determine aspects of the mobility and trajectory of UE 104. Subsequently, a training set 1 can be determined as described above by labeling pairs including UE location and beamfailure instance counter BFI_counter using a beamfailure probability factor. BFI_counter can take values ​​between 1 and a threshold. Afterward, an ML model can be trained based at least on the ML model inputs and ML model outputs to obtain a trained ML model.

[0098] The trained ML model can then be used for inference (shown as 610) and for ML model inputs such as UE location history (shown as 602) and BFI_counter (shown as 604). Based at least on the UE location history (shown as 602), BFI_counter (shown as 604), and the trained ML model, a beam failure probability factor (beamFailureProb) (shown as 612) can be determined. beamFailureProb (shown as 612) can then be used for beam failure management. It should be noted that beamFailureProb (shown as 612) can be used to train the ML model (shown as 608) and may help optimize beam failure management. Therefore, such an ML model can be trained to minimize the error between the proposed decision and the actual beam failure event and the beam failure claim made before waiting for beamFailureInstanceMaxCount consecutive beam failures.

[0099] In one example embodiment, an ML model can be trained to minimize a loss function that defines the relationship between a beam failure probability factor and a beam failure probability. The beam failure probability can indicate the probability of a beam failure occurring at the UE location after time steps `beamFailureInstanceMaxCount` for a given value of `BFI_counter`. The trained ML model can then be used for inference, where `beamFailureProb` can be inferred based on the UE location history and `BFI_counter`. The loss function can include, but is not limited to, minimum mean squared error (MSE) or entropy.

[0100] Subsequently, beamFailureProb can be compared with the beamfailure threshold probability (beamFailureThresholdProb). beamFailureThresholdProb can be configured at UE 104. Furthermore, the value of beamFailureThresholdProb can be optimized during the training phase. In one example embodiment, a very high beamFailureThresholdProb value minimizes the gain of the disclosed method, while a very low value can increase false beamfailure indications. Subsequently, if the beamfailure probability factor is higher than the beamfailure threshold probability beamFailureThresholdProb, a beamfailure can be declared and a beam recovery process can be initiated, regardless of the BFI_counter value. It should be noted that this independence from the BFI counter can provide proactive beamfailure declarations in areas where beamfailures occur too frequently for most UEs, and waiting for beamFailureInstanceMaxCount results in a delay in initiating the beam recovery process. Therefore, an ML-based approach is used to provide proactive beamfailure declarations and trigger the beam recovery process to identify and establish new beam pairs for communication between network device 102 and UE 104.

[0101] In one example embodiment, pseudocode for ML-assisted beam fault management at UE 104 is given below:

[0102] If a beam failure instance indication is received from a lower layer:

[0103] If BFI_counter = 0

[0104] Start beamFailureDetectionTimer;

[0105] BFI_counter=BFI_counter+1;

[0106] beamFailureProb = ML(UE position, BFI_counter)

[0107] If beamFailureProb >= beamFailureThresholdProb or BFI_counter >= beamFailureInstanceMaxCount;

[0108] Initiate the random access process.

[0109] It should be noted that the UE location history and BFI_counter mentioned above as inputs to the ML-assisted beam fault declaration are for illustrative purposes only. In another example embodiment, if other information, such as, but not limited to, radio propagation-related parameters, increases the probability of a beam fault declaration, such additional information can be added to the input features without departing from the scope of this disclosure. Furthermore, a beam fault is declared after the trained ML model infers beamFailureProb and beamFailureProb is greater than beamFailureThresholdProb, rather than waiting for beamFailureInstanceMaxCount beam fault instances.

[0110] Figure 7 The diagram illustrates signaling diagram 700 for training an ML model according to an example embodiment. First, when BFI_counter is greater than zero, UE 104 can send the value of BFI_counter to network device 102, i.e., gNB 102, in step 702. It should be noted that the training of the ML model can be performed at gNB 102. Furthermore, UE location information, i.e., UE 104's location data and BFI_counter, can be combined into a feature vector. UE 104's location data can be available at gNB 102. In one example embodiment, the UE location information can be obtained from minimized drive test (MDT) tracking. Additionally, to label the location data, if BFI_counter is increasing, it may be necessary to observe UE 104 for multiple instances, and then initiate a beam recovery procedure by UE 104 in step 704. In one example embodiment, if BFI_counter is reset before beamFailureInstanceMaxCount is reached, the location data associated with UE 104 can be marked as zero to count beamFailureProb. It should be noted that when BFI_counter is greater than zero, BFI_counter can be sent continuously to gNB 102.

[0111] Figure 8The diagram illustrates a signaling diagram 800 illustrating a method for beam failure management according to an example embodiment, wherein ML model inference is performed and hosted at UE 104. First, UE 104 may expose ML-based auxiliary capabilities and functions to the radio access network (RAN) and core network. Then, UE 104 may receive a request from gNB 104 in step 802 for activating ML-based functions. Subsequently, in step 804, UE 104 may respond to the request at least based on UE-ML processing resource availability or radio measurement / condition detection, indicating whether the requested ML-based function is available. It should be noted that the ML-based auxiliary capabilities and functions of UE 104, and the corresponding inference reports, may be activated by network device 102 (i.e., the serving gNB 102). Next, in step 806, gNB 102 may transmit the trained ML model to UE 104 and may configure beamFailureThresholdProb in UE 104. The trained ML model may then be stored in UE 104.

[0112] Subsequently, in step 808, when BFI_counter > 0, UE 104 can request the UE location from gNB 102 and can perform inference. Next, in step 810, when BFI_counter > 0, UE 104 can request the UE location from gNB 102. Next, in step 812, UE 104 can receive the UE's current location (X, Y) at this time. Then, UE 104 can perform ML model inference based at least on the UE's current location (X, Y) and BFI_counter. Subsequently, UE 104 can check whether a condition is met. The condition can be whether beamFailureProb is higher than the beamfailure threshold probability (beamFailureThresholdProb) or whether BFI_counter is greater than or equal to the maximum beamfailure instance count (beamFailureInstanceMaxCount). This condition is defined as:

[0113] If BFI_COUNTER >= beamFailureInstanceMaxCount

[0114] or

[0115] beamFailureProb>=beamFailureThresholdProb

[0116] Subsequently, if the conditions are met, UE 104 can initiate beam fault recovery in step 814.

[0117] Figure 9 The diagram illustrates a signaling diagram 900 illustrating a method for beam fault management according to an example embodiment, wherein ML model inference is performed at the network device, namely gNB 102. First, in step 902, gNB 102 may receive a BFI_counter from UE 104. It should be noted that whenever the BFI_counter increments, UE 104 may send information related to the BFI_counter to gNB 102. Next, gNB 102 may perform ML model inference in step 904 based at least on the UE location information and the BFI_counter. Subsequently, gNB 102 may trigger a beam recovery procedure in step 906. It should be noted that UE 104 does not make an explicit request. This implementation of performing ML model inference at network device 102 (i.e., the network side, gNB) offers several advantages, such as, but not limited to, that UE 104 does not need to have ML-based assistance capabilities, gNB 102 does not need to send location information to UE 104, and the network performs ML model inference and begins beam recovery immediately when needed without waiting for a beam recovery request from UE 104.

[0118] For those skilled in the art, the purpose of using deep learning ML models for training and inference is obvious; however, this approach to beam failure management is not limited to using any specific ML model and input features. In one example, reinforcement learning can be used as an efficient ML algorithm. Similarly, other UE input features can be used to better predict the probability of beam failures. This uses “soft” continuous information for the probability function, rather than making hard decisions after beamFailureInstanceMaxCount beam failure instances, when the probability function can quickly predict that the probability of beam failures will not change much after a few initial beam failure instances.

[0119] Figure 10 The diagram 1000 illustrates a signaling diagram for beam failure management according to an example embodiment, wherein radio measurement-based ML model inference is performed at UE 104. First, in step 1002, UE 104 may receive a request from gNB 102 to activate an ML-based function. Subsequently, in step 1004, UE 104 may respond to the request based at least on the availability of UE-ML processing resources or radio measurement / condition detection, indicating whether the requested ML-based function is available. Next, in step 1006, gNB 102 may transfer the trained ML model to UE 104 and may configure beamFailureThresholdProb in UE 104.

[0120] Subsequently, in step 1008, when BFI_counter > 0, UE 104 can perform ML model inference using local radio measurements (i.e., UE radio measurements). UE radio measurements can be the Layer 1 (L1) Reference Received Signal Power (RSRP) from the best beam of the serving cell, i.e., L1-RSRP, or L1-RSRP from serving and neighboring cells. In one example embodiment, a radio frequency (RF) fingerprint-based method can be used, where radio measurements associated with the UE location are used to determine the location of UE 104. Furthermore, radio measurements in 5G NR can be performed locally by UE 104. It should be noted that these radio measurements can provide a tight mapping between radio measurements and the location of UE 104. The UE radio measurements can then be used to determine the beam failure probability factor. UE 104 can then check whether a condition is met. The condition can be whether beamFailureProb is higher than the beam failure threshold probability (beamFailureThresholdProb) or whether BFI_counter is greater than or equal to the beam failure instance maximum count (beamFailureInstanceMaxCount). This condition is defined as:

[0121] If BFI_COUNTER >= beamFailureInstanceMaxCount

[0122] or

[0123] beamFailureProb>=beamFailureThresholdProb

[0124] Subsequently, if the conditions are met, UE 104 can initiate beam fault recovery in step 814. This use of UE radio measurements eliminates the need to receive UE location information from gNB 102. Another advantage of this embodiment is that gNB 102 no longer needs to send location information to UE 104 to determine the beam fault probability factor.

[0125] Figure 11The figure illustrates graph 1100 according to an example embodiment, showing a scenario where the beam failure probability factor varies based on the beam failure instance counter (BFI_counter). In Figure 1100, one line (shown by 1102) represents a linear probability increase in 3GPP, one line (shown by 1104) represents a possible probability function, and one line (shown by 1106) represents beamFailureThresholdProb. Initially, beamFailureInstanceMaxCount is configured to 10, while beamFailureThresholdProb is configured to 95%. Figure 1100 further illustrates the hypothetical beamFailureThresholdProb based on the BFI_counter, where UE 104 moves slowly and performs inferences continuously after each beam failure instance. It should be noted that with each increment of BFI_counter, the probability of beam failure detection increases linearly by 1 / beamFailureInstanceMaxCount. For certain cases, beamFailureProb may increase monotonically but not rapidly, as shown in Figure 1100. In this scenario, beamFailureProb is greater than beamFailureThresholdProb only in the 10th consecutive beamfailure instance; therefore, ML-based detection does not improve beamfailure claims. This scenario might be an example of a geographical area with limited information for training the ML model, or an environment that is relatively stable and beamfailures are not very common.

[0126] Figure 12Figure 1200 illustrates a scenario of actively predicting beam failures according to an example embodiment. In Figure 1200, one line (shown by 1202) represents a linear probability increase in 3GPP, one line (shown by 1204) represents a possible probability function, and one line (shown by 1206) represents beamFailureThresholdProb. Initially, after two consecutive failures, the ML model predicts a beam failure probability factor close to 40% based on the position (X1, Y1) and a BFI_counter equal to 4. Furthermore, after the next failure, the ML model predicts beamFailureProb to be 75% based on the new position (X2, Y2) and a BFI_counter equal to 5. It should be noted that beamFailureProb reaches 98% after the 6th instance. Since the beamFailureProb value is high for the 6th instance, a beam failure will occur after 10 consecutive beam failure instances, i.e., there is no need to wait for 10 failure instances. Thereafter, the beam recovery process is initiated 4 instances ahead of schedule. Such an implementation could be an example of a geographically congested area where most UEs suffer from beam failures and the past experience of other UEs can help predict beam failures.

[0127] Figure 13 Graph 1300 illustrates a scenario where the method for beam failure management according to an example embodiment provides immediate benefits. In Graph 1300, one line (shown by 1302) represents a linear probability increase in 3GPP, one line (shown by 1304) represents a possible probability function, and one line (shown by 1306) represents beamFailureThresholdProb. First, at location (X1, Y1), if BFI_counter is small, beamFailureProb does not increase much. Furthermore, if BFI_counter is large, beamFailureProb increases rapidly. This occurs if the congestion at a location is not significant. In one case, if BFI_counter is small, UE 104 is expected to overcome the congestion quickly and beam recovery is not required. In another case, when BFI_counter is large at location (X1, Y1), a very high probability from the ML model predicts that UE 104 will not be able to overcome the congestion before beamFailureInstanceMaxCount. After this, the beam recovery process is initiated. It's important to note that beamFailureInstanceMaxCount and BFI_counter may not be very large, but they can help reduce latency during the beam recovery process.

[0128] It should be noted that the disclosed method can provide active beam failure detection in 5G New Radio (NR). Instead of waiting for beamFailureInstanceMaxCount instances, the disclosed method predicts the probability of a beam failure occurring after beamFailureInstanceMaxCount instances. beamFailureInstanceMaxCount is configured as a fixed value in UE 104, and UE beam failure is detected. Furthermore, latency gain can be achieved using ML-based intelligent prediction based on the history of other UEs and the environment. Moreover, the disclosed method facilitates timely data delivery for UE 104 operating latency-constrained services in areas with significant predictable congestion. Additionally, active beam failure detection helps time-sensitive services initiate UE beam recovery without waiting for N consecutive beam failure events, thus contributing to maintaining the connectivity of UE 104.

[0129] Embodiments of this disclosure can be provided as a computer program product, which may include a computer-readable medium having instructions tangibly embodied thereon, which can be used to program a computer (or other electronic device) to perform a process. The computer-readable medium may include, but is not limited to, fixed (hard disk) drives, magnetic tape, floppy disks, optical disks, optical disc read-only memory (CD-ROM) and magneto-optical disks, semiconductor memories such as ROM, random access memory (RAM), programmable read-only memory (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, magnetic cards or optical cards, or other types of media / machine-readable media suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware). Furthermore, embodiments of this disclosure can also be downloaded as one or more computer program products, wherein the program can be transmitted from a remote computer to the requesting computer via a communication link (e.g., a modem or network connection) via data signals contained in a carrier wave or other propagation medium.

[0130] The detailed description section of this application should clarify that the order of the method steps is not important. Such references will later support the argument that the order of steps in the method statement is not critical or fixed. Features described and / or illustrated with respect to one embodiment may be used in the same or similar manner in one or more other embodiments and / or combined with or substituted for features of other embodiments.

[0131] Although the embodiments described above have been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the exemplary embodiments. For example, aspects of the subject matter disclosed herein can be employed on alternative operating systems. Therefore, the scope of the exemplary embodiments is not limited by the disclosure of the embodiments. Rather, the exemplary embodiments should be determined entirely by reference to the appended claims.

Claims

1. A method for beam fault management of a user equipment (UE) (104), the method comprising: Determine the beam fault instance counter BFI_counter, which indicates the number of consecutive beam fault instances occurring at the user equipment UE (104) at a given time; Determine the position of the user equipment (UE) (104) at the time; as well as A beam failure probability factor is determined at least based on the location of the user equipment (UE) (104) and the beam failure instance counter (BFI_counter), wherein the beam failure probability factor indicates the probability of a beam failure occurring at the location of the user equipment (UE) (104) after a plurality of additional times, wherein for each UE location and each beam failure instance counter (BFI_counter), the beam failure probability factor is defined at least based on the beam failure instance counter (BFI_counter) and the UE location.

2. The method of claim 1, wherein determining the position of the user equipment (UE) (104) at the time comprises: The location of the user equipment UE (104) is received from the network device (102), or the location of the user equipment UE (104) is determined using a radio frequency (RF) fingerprint.

3. The method according to claim 2, further comprising: The beam failure probability factor is compared with the beam failure threshold probability beamFailureThresholdProb, and a beam failure is declared if the beam failure probability factor is higher than the beam failure threshold probability beamFailureThresholdProb.

4. The method of claim 3, wherein declaring a beam fault includes initiating a beam recovery process.

5. The method of claim 3, wherein the declared beam fault includes a random access procedure for beam fault recovery.

6. The method of claim 4, wherein the beam failure probability factor is determined by a trainable machine learning (ML) model.

7. The method of claim 6, wherein the method is performed at a user equipment (UE) (104), and further comprises the step of: Receive a request from the network device (102) to activate the ML-based function; and The beam failure threshold probability beamFailureThresholdProb and the trainable ML model are received from the network device (102). Determining the position of the user equipment (UE) (104) at the specified time includes: If the beam fault instance counter BFI_counter>0, the network device (102) requests and receives the location of the user equipment (UE) (104) at the time.

8. The method of claim 7, wherein the beam fault instance counter BFI_counter is determined by counting beam fault instances indicated by the user equipment UE (104).

9. The method of claim 6, wherein the method is performed at the network device (102) and the beam fault instance counter BFI_counter is received from the user equipment UE (104).

10. A method for training a machine learning ML model at a network device (102), the method comprising: Receive multiple UE locations and a threshold beamFailureInstanceMaxCount from at least one user equipment (UE) (104), the threshold beamFailureInstanceMaxCount indicating the maximum number of consecutive beam failure instances; The training set is determined by labeling pairs including UE location and beam failure instance counter BFI_counter using a beam failure probability factor, wherein the beam failure instance counter BFI_counter takes a value between 1 and the threshold beamFailureInstanceMaxCount, wherein for each UE location and each beam failure instance counter BFI_counter, the beam failure probability factor is defined at least based on the beam failure instance counter BFI_counter and the UE location. as well as The ML model is trained using the labeled training set.

11. The method of claim 10, wherein the beam failure probability factor is defined as: Where beamFailureProb is the beam failure probability factor, BFI_counter is the beam failure instance counter, and position (X,Y) is the UE position.

12. The method of any one of claims 10 and 11, wherein the machine learning ML model is trained to minimize a loss function that defines the relationship between the beam failure probability factor and the beam failure probability, the beam failure probability indicating the probability that a beam failure will occur at the UE location after time steps beamFailureInstanceMaxCount for a given value of the beam failure instance counter BFI_counter.

13. A communication device, comprising components for performing: Determine the beam fault instance counter BFI_counter, which indicates the number of consecutive beam fault instances occurring at the user equipment UE (104) at a given time; Determine the position of the user equipment (UE) (104) at the time; and A beam failure probability factor is determined at least based on the location of the user equipment (UE) (104) and the beam failure instance counter (BFI_counter), wherein the beam failure probability factor indicates the probability of a beam failure occurring at the location of the user equipment (UE) (104) after a plurality of additional times, wherein for each UE location and each beam failure instance counter (BFI_counter), the beam failure probability factor is defined at least based on the beam failure instance counter (BFI_counter) and the UE location.

14. The apparatus of claim 13, wherein determining the position of the user equipment (UE) (104) at the time comprises: The location of the user equipment UE (104) is received from the network device (102), or the location of the user equipment UE (104) is determined using a radio frequency (RF) fingerprint.

15. The apparatus of claim 14, wherein the apparatus is the user equipment UE (104), and is further configured to: Receive a request from network device (102) to activate a machine learning (ML) based function; and Receive beam fault threshold probability and trainable machine learning (ML) model from the network device (102). Determining the position of the user equipment (UE) (104) at the specified time includes: If the beam fault instance counter BFI_counter>0, the network device (102) requests and receives the location of the user equipment (UE) (104) at the time.

16. The apparatus of claim 13, wherein the apparatus is a network device (102) and is further configured to receive the beam fault instance counter BFI_counter from the user equipment (UE) (104).

17. An apparatus for training a machine learning (ML) model, comprising components for performing: Receive multiple UE locations and a threshold beamFailureInstanceMaxCount from at least one user equipment (UE) (104), the threshold beamFailureInstanceMaxCount indicating the maximum number of consecutive beam failure instances; A training set is determined by labeling pairs including UE location and beam failure instance counter BFI_counter using a beam failure probability factor, wherein the beam failure instance counter BFI_counter takes a value between 1 and the threshold beamFailureInstanceMaxCount, wherein for each UE location and each beam failure instance counter BFI_counter, the beam failure probability factor is defined at least based on the beam failure instance counter BFI_counter and the UE location; and The ML model is trained using the labeled training set.

18. The apparatus of claim 17, wherein the beam failure probability factor is defined as: Where beamFailureProb is the beam failure probability factor, BFI_counter is the beam failure instance counter, and position (X,Y) is the UE position.

19. The apparatus of claim 17 or 18, wherein the machine learning ML model is trained to minimize a loss function that defines the relationship between the beam failure probability factor and the beam failure probability, the beam failure probability indicating the probability that a beam failure will occur at the UE location after beamFailureInstanceMaxCount time points for a given value of the beam failure instance counter BFI_counter.

Images