Relationship between beam group beam failure recovery and cell level beam failure recovery

Abstract

In operation, a UE in a cell (SpCell / SCell) can be configured to operate with beam group-specific BFR, cell-level BFR, or a combination thereof under a beam failure configuration determined according to various rules. A method of wireless communication performed by a user equipment (UE) and the UE are disclosed. The method includes determining a beam failure configuration for a serving cell, the beam failure configuration including at least one of a beam failure parameter for a beam group or a beam failure parameter for the cell, and detecting, in the serving cell, a beam failure recovery (BFR) based at least in part on the beam failure configuration, the BFR based at least in part on the beam failure configuration. The beam failure configuration is determined based on various rules that control operation of the BFR.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to U.S. Patent Application No. 17 / 448,640, filed September 23, 2021, and U.S. Provisional Patent Application No. 63 / 085,141, filed September 29, 2020, the entire contents of which are incorporated herein by reference as fully set forth herein and for all applicable purposes. Technical Field

[0003] This application relates to wireless communication systems, and more particularly to the relationship between beamgroup beam fault recovery and cell-level beam fault recovery.

[0004] introduction

[0005] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, message sending and receiving, broadcasting, and so on. These systems can support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Wireless multiple access communication systems may include several base stations (BSs), each supporting communication from multiple communication devices simultaneously, which may also be referred to as user equipment (UEs).

[0006] To meet the growing demand for extended mobile broadband connectivity, wireless communication technologies are evolving from Long Term Evolution (LTE) to Next Generation New Radio (NR), often referred to as fifth generation (5G). For example, NR is designed to offer lower latency, higher bandwidth or throughput, and greater reliability compared to LTE. NR is designed to operate across a wide range of frequency bands, from low-frequency bands below approximately 1 GHz and mid-frequency bands from approximately 1 GHz to approximately 6 GHz, to high-frequency bands such as millimeter wave (mmWave) bands. NR is also designed to operate across different spectrum types, from licensed spectrum to unlicensed and shared spectrum. Spectrum sharing allows operators to opportunistically pool spectrum to dynamically support high-bandwidth services. Spectrum sharing can extend the benefits of NR technology to operating entities that may not have access to licensed spectrum.

[0007] In some wireless communication systems, a UE and a base station can communicate over a communication link using directional beams. Changes in the radio environment between the UE and the base station can degrade the quality of the beams used by the UE and the base station, potentially leading to communication failures between the UE and the serving cell (e.g., primary cell (Pcell), secondary cell (Scell), or both). The UE may attempt to perform a beam fault recovery (BFR) procedure to re-establish a connection with the serving cell. Additionally, in some wireless communication systems, a UE may communicate with more than one transmit-receive point (TRP) of the serving cell (e.g., in a multi-TRP configuration). Each of these multiple TRPs may transmit downlink transmissions to the UE according to a beam configuration, and the UE may decode downlink transmissions from each of these multiple TRPs according to these beam configurations. Efficiently detecting and recovering from beam faults in a multi-TRP configuration can help enhance multi-TRP communication.

[0008] A brief overview of some examples

[0009] The following outlines some aspects of this disclosure to provide a basic understanding of the techniques discussed. This overview is not an exhaustive summary of all conceived features of this disclosure, and is neither intended to identify all key or decisive elements of all aspects of this disclosure, nor to define the scope of any or all aspects of this disclosure. Its sole purpose is to provide, in an overview form, some concepts of one or more aspects of this disclosure as a prelude to the more detailed description that follows.

[0010] In some aspects, a wireless communication method performed by a user equipment (UE) includes: receiving from a base station (BS) communication indicating a beam fault configuration for a serving cell, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of the cell; and detecting beam faults in the serving cell at least in part based on the beam fault configuration. The beam fault configuration is determined based on various rules controlling the operation of the BFR.

[0011] In some aspects, a UE includes: a memory; a processor coupled to the memory; and a transceiver coupled to the processor and configured to: receive from a base station (BS) communication indicating a beam fault configuration for a serving cell, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell, wherein the processor is configured to: detect beam faults in the serving cell based at least in part on the beam fault configuration.

[0012] In some aspects, a non-transient computer-readable medium is provided having program code thereon for operation by a UE, the program code including: code for causing the UE to receive from a base station (BS) communication indicating a beam fault configuration for a serving cell, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell; and code for causing the UE to detect a beam fault in the serving cell at least in part based on the beam fault configuration.

[0013] In some aspects, a UE includes: means for receiving from a base station (BS) a communication indicating a beam fault configuration for a serving cell, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell; and means for detecting a beam fault in the serving cell based at least in part on the beam fault configuration.

[0014] Other aspects, features, and embodiments of the invention will become apparent to those skilled in the art after reading the following description of specific exemplary embodiments of the invention in conjunction with the accompanying drawings. While features of the invention may be discussed below with reference to certain embodiments and drawings, all embodiments of the invention may include one or more advantageous features discussed herein. In other words, while one or more embodiments may be discussed having certain advantageous features, one or more such features may also be used according to various embodiments of the invention discussed herein. Similarly, although exemplary embodiments may be discussed below as embodiments of devices, systems, or methods, it should be understood that such exemplary embodiments can be implemented in various devices, systems, and methods. Brief description of the attached diagram

[0016] Figure 1 The present disclosure explains some aspects of wireless communication networks.

[0017] Figure 2A An example of a wireless communication system that supports beam fault recovery techniques for multiple transmit receiver points (TRPs) in a primary or secondary cell, according to some aspects of this disclosure, is described.

[0018] Figure 2B The present disclosure explains various aspects of beam fault recovery.

[0019] Figure 3A An example of a process flow supporting beam fault recovery techniques for multiple transmit and receive points, based on some aspects of this disclosure, is explained.

[0020] Figure 3BAn example of a process flow supporting beam fault recovery techniques for multiple transmit and receive points, based on some aspects of this disclosure, is explained.

[0021] Figure 3C The various aspects of beam fault recovery according to some aspects of this disclosure are further explained.

[0022] Figure 4 This is a block diagram of user equipment (UE) based on some aspects of this disclosure.

[0023] Figure 5 This is a block diagram of an exemplary base station (BS) according to some aspects of this disclosure.

[0024] Figure 6 A flowchart illustrating some aspects of the communication methods according to this disclosure is provided.

[0025] Figure 7 A flowchart illustrating some aspects of the communication methods according to this disclosure is provided.

[0026] Figure 8 An example of beam fault configuration determined according to some aspects of this disclosure is explained.

[0027] Figures 9A to 9D This disclosure explains some beam fault configuration options based on certain aspects of this disclosure.

[0028] Figure 10 A flowchart illustrating some aspects of the communication methods according to this disclosure is provided.

[0029] Figure 11 A flowchart illustrating some aspects of the communication methods according to this disclosure is provided.

[0030] Figure 12 A flowchart illustrating some aspects of the communication methods according to this disclosure is provided.

[0031] Detailed description

[0032] The detailed description that follows, taken in conjunction with the accompanying drawings, is intended as a description of various configurations and is not intended to represent the only configuration in which the concepts described herein can be practiced. This detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0033] This disclosure generally relates to wireless communication systems (also known as wireless communication networks). In various embodiments, technologies and apparatus can be used in wireless communication networks such as Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, Single Carrier FDMA (SC-FDMA) networks, LTE networks, Global System for Mobile Communications (GSM) networks, 5G or New Radio (NR) networks, and other communication networks. As described herein, the terms "network" and "system" may be used interchangeably.

[0034] OFDMA networks can implement radio technologies such as Evolved UTRA (E-UTRA), IEEE 802.11, IEEE 802.16, IEEE 802.20, and flash-OFDM. UTRA, E-UTRA, and GSM are part of the Universal Mobile Telecommunications System (UMTS). Specifically, Long Term Evolution (LTE) is a UMTS version using E-UTRA. UTRA, E-UTRA, GSM, UMTS, and LTE are described in documents from an organization called the 3rd Generation Partnership Project (3GPP), while cdma2000 is described in documents from an organization called 3rd Generation Partnership Project 2 (3GPP2). These various radio technologies and standards are known or under development. For example, the 3rd Generation Partnership Project (3GPP) is a collaboration between various telecommunications association groups that aims to define globally applicable third-generation (3G) mobile phone specifications. 3GPP Long Term Evolution (LTE) is a 3GPP project aimed at improving the UMTS mobile phone standard. 3GPP defines specifications for next-generation mobile networks, mobile systems, and mobile devices. This disclosure focuses on the evolution of wireless technologies from LTE, 4G, 5G, NR, and beyond, which features shared access to the radio spectrum between networks using new and different sets of radio access technologies or radio air interfaces.

[0035] Specifically, 5G networks envision diverse deployments, diverse spectrum, and diverse services and devices that can be achieved using a unified air interface based on OFDM. To achieve these goals, in addition to developing new radio technologies for 5G NR networks, further enhancements to LTE and LTE-A are also considered. 5G NR will be able to scale to: (1) provide ultra-high density (e.g., approximately 1M nodes / km) 2(1) Provide coverage for large-scale Internet of Things (IoT) with ultra-low complexity (e.g., approximately tens of bits / second), ultra-low energy (e.g., approximately 10+ years of battery life), and deep coverage capable of reaching challenging locations; (2) Provide coverage with strong security (to protect sensitive personal, financial, or confidential information), ultra-high reliability (e.g., approximately 99.9999% reliability), ultra-low latency (e.g., approximately 1 ms), and mission-critical control for users with wide range of mobility or lack thereof; and (3) Provide coverage with enhanced mobile broadband, including extremely high capacity (e.g., approximately 10 Tbps / km). 2 Extreme data rates (e.g., multi-Gbps rates, 100+Mbps user experience rates), and deep insights with advanced discovery and optimization.

[0036] 5G NR can achieve: optimized OFDM-based waveforms with scalable parametric design and transmission time intervals (TTI); a shared, flexible framework for efficiently multiplexing services and features using dynamic, low-latency Time Division Duplex (TDD) / Frequency Division Duplex (FDD) designs; and advanced radio technologies such as massive MIMO, robust millimeter-wave (mmWave) transmission, advanced channel decoding, and device-centric mobility. The scalability of parametric design in 5G NR (and the scaling of subcarrier spacing) can efficiently address the operation of diverse services across diverse spectrum and deployments. For example, in various outdoor and macro coverage deployments implemented with FDD / TDD below 3 GHz, subcarrier spacing can occur at 15 kHz over bandwidths (BWs) such as 5, 10, and 20 MHz. For other various outdoor and small cell coverage deployments with TDD above 3 GHz, subcarrier spacing can occur at 30 kHz over an 80 / 100 MHz BW. For various other indoor broadband implementations, by using TDD in the unlicensed portion of the 5 GHz band, the subcarrier spacing can occur at 60 kHz over a 160 MHz BW. Finally, for various deployments using mmWave components for TDD at 28 GHz, the subcarrier spacing can occur at 120 kHz over a 500 MHz BW.

[0037] 5G NR's scalable parameter design enables scalable TTIs to meet diverse latency and Quality of Service (QoS) requirements. For example, shorter TTIs can be used for low latency and high reliability, while longer TTIs can be used for higher spectral efficiency. Efficient multiplexing of long and short TTIs allows transmissions to begin at symbol boundaries. 5G NR also envisions a self-contained integrated subframe design that incorporates uplink / downlink scheduling information, data, and acknowledgments within the same subframe. Self-contained integrated subframes support communication in unlicensed or contention-based shared spectrum and support adaptive uplink / downlink configuration that can be flexibly configured on a per-cell basis to dynamically switch between uplink and downlink to meet current traffic needs.

[0038] Each frame may include multiple consecutively numbered subframes or time slots, and each subframe or time slot may have the same duration. In some examples, a frame may (e.g., in the time domain) be divided into subframes, and each subframe may be further divided into several time slots. Alternatively, each frame may include a variable number of time slots, and the number of time slots may depend on the subcarrier spacing. Each time slot may include several symbol periods (e.g., depending on the length of the cyclic prefix added before each symbol period). In some wireless communication systems 100, time slots may be further divided into multiple mini-time slots containing one or more symbols. Excluding the cyclic prefix, each symbol period may contain one or more (e.g., N) symbols. f (Number) sampling periods. The duration of a symbol period can depend on the subcarrier interval or the operating frequency band.

[0039] A subframe, time slot, mini-slot, or symbol can be the smallest scheduling unit of the wireless communication system 100 (e.g., in the time domain) and can be referred to as a transmission time interval (TTI). In some examples, the duration of the TTI (e.g., the number of symbol periods in the TTI) can be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 can be dynamically selected (e.g., in bursts of shortened TTIs (sTTIs)).

[0040] Various other aspects and features of this disclosure are further described below. It should be apparent that the teachings herein can be embodied in a variety of forms, and any specific structure, function, or both disclosed herein are merely representative and not limiting. Based on the teachings herein, those skilled in the art will appreciate that the aspects disclosed herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement an apparatus or practice a method. Furthermore, such an apparatus or practice can be implemented using other structures, functionalities, or structures and functionalities that complement or differ from one or more aspects set forth herein. For example, a method can be implemented as part of a system, device, apparatus, and / or as instructions stored on a computer-readable medium for execution on a processor or computer. Moreover, an aspect may include at least one element of the claims.

[0041] In some wireless communication systems, a User Equipment (UE) may support communication with a serving cell via multiple beamgroups. In some instances, each beamgroup may be associated with one or more Transmitter-Receiver Points (TRPs), one or more beam directions, and / or one or more other spatial beam parameters. The UE may receive downlink transmissions from multiple TRPs (e.g., via the Physical Downlink Shared Channel (PDSCH)). Additionally, the UE may decode the downlink transmission based on the beam configuration associated with each of the downlink transmissions. Furthermore, such multi-beamgroup communication may be primary cell (Pcell) communication, secondary cell (Scell) communication, or both. In some cases, one or more beams from a particular beamgroup may degrade to the point where effective communication via that beam is unlikely. Therefore, in such cases, beam fault detection (BFD), beam fault recovery (BFR), radio link monitoring (RLM), and / or radio link fault (RLF) recovery may be beneficial in assisting communication. In situations where multiple beam groups are used for communication, techniques such as those discussed herein can be used to identify communication failures (e.g., beam failures and / or RLFs) in the serving cell, and / or to recover from the communication failure based on beam failure parameters of the beam group (e.g., TRP), the beam failure parameters of the cell, or both the beam failure parameters of the beam group and the beam failure parameters of the cell.

[0042] In some scenarios, the UE can establish connections with both a Pcell and a Scell, where the Scell ​​(and in some cases, the Pcell) uses beamforming communication via two or more beamgroups (e.g., transmit-receive points (TRPs)). In some cases, different beamgroups can be associated with different control resource sets (CORESET) pool index values, and one or more component carriers (CCs) can be configured with multiple CORESET pool index values. Thus, from the UE's perspective, different TRPs are transparent, and the UE can identify the different CORESET pool index values ​​associated with the received signal.

[0043] In some scenarios, the UE may execute BFD procedures that identify one or more beams with degraded channel quality associated with a specific CORESET pool index value. In some scenarios, reference signals transmitted via each TRP (e.g., for BFD or for candidate beam detection (CBD)) may provide an indication of the corresponding CORESET pool index detectable at the UE (e.g., based on a reference signal sequence). In some scenarios, the UE may determine to declare a beam fault for one or more beams and, in response, initiate beam fault recovery (BFR). In some scenarios, a BFR MAC-CE containing information about the beamgroup and beam fault is provided, as discussed further below.

[0044] In operation, a UE located in a serving cell can operate using per-beamgroup beam fault detection and / or recovery parameters, cell-level beam fault detection and / or recovery parameters, or a combination of per-beamgroup beam fault detection and / or recovery parameters and cell-level beam fault detection and / or recovery parameters. Accordingly, in some instances, the UE can perform BFD based on per-beamgroup BFD parameters or based on cell-level BFD parameters. Similarly, in some instances, the UE can perform BFR based on per-beamgroup BFR parameters or based on cell-level BFR parameters. Therefore, in some instances, the UE can perform BFD based on per-beamgroup BFD parameters and perform BFR based on cell-level BFR parameters, or vice versa (performing BFD based on cell-level BFD parameters and performing BFR based on per-beamgroup BFR parameters). Each beamgroup and / or cell-level BFD and / or BFR parameters can be dynamically configured (e.g., by the serving cell, BS, UE, or otherwise), predefined (e.g., by the network operator, serving cell, BS, UE, standards-defined, or otherwise), or a combination of dynamic configuration and predefined. Aspects of this disclosure provide mechanisms for deploying beamgroup BFD and / or BFR parameters together with cell-level BFD, BFR, RLM, and / or RLF parameters in a serving cell. In this regard, aspects of this disclosure can define configuration / operational relationships between TRP-dependent BFD / BFR and existing cell-level BFD / BFR and RLM / RLF (including between TRP-dependent BFD / BFR and SpCell / SCell BFD / BFR, and between TRP-dependent BFD / BFR and SpCell RLM / RLF on the same SpCell).

[0045] Figure 1 A wireless communication network 100 according to some aspects of this disclosure is described. Network 100 may be a 5G network. Network 100 includes several base stations (BSs) 105 (labeled 105a, 105b, 105c, 105d, 105e, and 105f, respectively) and other network entities. BS 105 may be a station communicating with UE 115, and may also be referred to as an evolved B-node (eNB), a next-generation eNB (gNB), an access point, etc. Each BS 105 may provide communication coverage for a specific geographic area. In 3GPP, the term "cell" may refer to that specific geographic coverage area of ​​BS 105 and / or the BS subsystem serving that coverage area, depending on the context in which the term is used.

[0046] BS 105 can provide communication coverage for macrocells or small cells (such as picocells or femtocells), and / or other types of cells. Macrocells typically cover a relatively large geographic area (e.g., a radius of several kilometers) and allow unrestricted access by UEs with service subscriptions to a network provider. Small cells (such as picocells) typically cover a relatively small geographic area and allow unrestricted access by UEs with service subscriptions to a network provider. Small cells (such as femtocells) also typically cover a relatively small geographic area (e.g., a residential area) and, in addition to unrestricted access, allow restricted access by UEs associated with that femtocell (e.g., UEs in a closed subscriber group (CSG), UEs of users in that residence, etc.). A BS used for macrocells may be referred to as a macro BS. A BS used for small cells may be referred to as a small cell BS, pico BS, femtocell BS, or home BS. Figure 1 In the examples shown, BS 105d and 105e can be conventional macro BSs, while BS 105a-105c can be macro BSs with one of three-dimensional (3D), full-dimensional (FD), or massive MIMO enabled. BS 105a-105c can leverage its higher-dimensional MIMO capabilities to increase coverage and capacity using 3D beamforming in both elevation and azimuth beamforming. BS 105f can be a small cell BS, which can be a home node or a portable access point. BS 105 can support one or more (e.g., two, three, four, etc.) cells.

[0047] Network 100 can support synchronous or asynchronous operation. For synchronous operation, each BS can have similar frame timing, and transmissions from different BSs can be roughly aligned in time. For asynchronous operation, each BS can have different frame timing, and transmissions from different BSs may not be aligned in time.

[0048] Each UE 115 is distributed throughout the wireless network 100, and each UE 115 may be stationary or mobile. UE 115 may also be referred to as a terminal, mobile station, subscriber unit, station, etc. UE 115 may be a cellular phone, personal digital assistant (PDA), wireless modem, wireless communication device, handheld device, tablet computer, laptop computer, cordless phone, wireless local loop (WLL) station, etc. In one aspect, UE 115 may be a device including a Universal Integrated Circuit Card (UICC). In another aspect, UE may be a device without a UICC. In some aspects, UE 115 without a UICC may also be referred to as an IoT device or an Internet of Things (IoE) device. UE 115a-115d are examples of mobile smartphone-type devices accessing network 100. UE 115 may also be a machine specifically configured for connected communications (including Machine Type Communication (MTC), Enhanced MTC (eMTC), Narrowband IoT (NB-IoT), etc.). UE 115e-115h are examples of various machines configured for communication within access network 100. UE 115i-115k are examples of vehicles equipped with wireless communication devices configured for communication within access network 100. UE 115 can communicate with any type of BS (whether macro BS, small cell, etc.). Figure 1 In this context, the lightning bolt (e.g., a communication link) indicates radio transmissions between UE 115 and serving BS 105, desired transmissions between BSs 105, backhaul transmissions between BSs, or sidelink transmissions between UE 115, where serving BS 105 is the BS designated to serve UE 115 on the downlink (DL) and / or uplink (UL).

[0049] In operation, BS 105a-105c can use 3D beamforming and coordinated spatial technologies (such as Coordinated Multipoint (CoMP) or multi-connectivity) to serve UE 115a and 115b. Macro BS 105d can perform backhaul communication with BS 105a-105c and small cell BS 105f. Macro BS 105d can also deliver multicast services subscribed to and received by UE 115c and 115d. Such multicast services may include mobile TV or streaming video, or may include other services for providing community information (such as weather emergencies or alerts, such as Amber Alerts or Grey Alerts).

[0050] BS 105 can also communicate with the core network. The core network provides user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. At least some BS 105s (e.g., examples of gNBs or Access Node Controllers (ANCs)) can interface with the core network via backhaul links (e.g., NG-C, NG-U, etc.) and can perform radio configuration and scheduling for communication with UE 115. In various examples, BS 105s can communicate with each other directly or indirectly (e.g., via the core network) on backhaul links (e.g., X1, X2, etc.), which can be wired or wireless communication links.

[0051] Network 100 can also support mission-critical communication with highly reliable and redundant links for mission-critical devices such as UE 115e, which could be a drone. Redundant communication links with UE 115e may include links from macro BSs 105d and 105e, and links from small cell BS 105f. Other machine-type devices (such as UE 115f (e.g., a thermometer), UE 115g (e.g., a smart meter), and UE 115h (e.g., a wearable device)) can communicate directly with BSs (such as small cell BS 105f and macro BS 105e) via network 100, or be in a multi-step configuration by communicating with another user equipment that relays its information to the network (e.g., UE 115f relays temperature measurement information to smart meter UE 115g, which is then reported to the network via small cell BS 105f). Network 100 can also provide additional network efficiency through dynamic, low-latency TDD / FDD communications, such as vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), cellular V2X (C-V2X) communications between UEs 115i, 115j or 115k and other UEs 115, and / or vehicle-to-infrastructure (V2I) communications between UEs 115i, 115j or 115k and BS 105.

[0052] In some implementations, network 100 utilizes OFDM-based waveforms for communication. OFDM-based systems can divide the system BW into multiple (K) orthogonal subcarriers, which are often referred to as subcarriers, frequency modulation, frequency slots, etc. Each subcarrier can be modulated with data. In some instances, the subcarrier spacing between adjacent subcarriers can be fixed, and the total number of subcarriers (K) can depend on the system BW. The system BW can also be divided into subbands. In other instances, the subcarrier spacing and / or the duration of the time interval (TTI) can be scalable.

[0053] In some respects, BS 105 may assign or schedule (e.g., in the form of time-frequency resource blocks (RBs)) transmission resources for downlink (DL) and uplink (UL) transmissions in network 100. DL refers to the transmission direction from BS 105 to UE 115, while UL refers to the transmission direction from UE 115 to BS 105. Communication may take the form of radio frames. Radio frames may be divided into multiple subframes or time slots, for example, about 10. Each time slot may be further divided into sub-time slots. In FDD mode, simultaneous UL and DL transmissions may occur in different frequency bands. For example, each subframe includes UL subframes in the UL band and DL subframes in the DL band. In TDD mode, UL and DL transmissions occur using the same frequency band at different time periods. For example, a subset of subframes in a radio frame (e.g., DL subframes) may be used for DL ​​transmissions, and another subset of subframes in a radio frame (e.g., UL subframes) may be used for UL transmissions.

[0054] DL subframes and UL subframes can be further divided into several regions. For example, each DL or UL subframe may have a predefined region for the transmission of reference signals, control information, and data. Reference signals are predetermined signals that facilitate communication between BS 105 and UE 115. For example, reference signals may have a specific pilot pattern or structure, wherein the pilot frequencies may span the operating BW or frequency band, and each pilot frequency is positioned at a predefined time and predefined frequency. For example, BS 105 may transmit a cell-specific reference signal (CRS) and / or channel state information-reference signal (CSI-RS) to enable UE 115 to estimate the DL channel. Similarly, UE 115 may transmit a probe reference signal (SRS) to enable BS 105 to estimate the UL channel. Control information may include resource allocation and protocol control. Data may include protocol data and / or operational data. In some aspects, BS 105 and UE 115 may communicate using self-contained subframes. Self-contained subframes may include portions for DL ​​communication and portions for UL communication. Self-contained subframes can be DL-centered or UL-centered. DL-centered subframes can include a duration for DL ​​communication that is longer than the duration for UL communication. UL-centered subframes can include a duration for UL communication that is longer than the duration for DL ​​communication.

[0055] In some respects, network 100 may be an NR network deployed on licensed spectrum. BS 105 may transmit synchronization signals (e.g., including primary synchronization signal (PSS) and secondary synchronization signal (SSS)) within network 100 to facilitate synchronization. BS 105 may broadcast system information associated with network 100 (e.g., including primary information block (MIB), residual system information (RMSI), and other system information (OSI)) to facilitate initial network access. In some instances, BS 105 may broadcast PSS, SSS, and / or MIB in the form of synchronization signal block (SSB) on the physical broadcast channel (PBCH) and may broadcast RMSI and / or OSI on the physical downlink shared channel (PDSCH).

[0056] In some respects, UE 115 attempting to access network 100 can perform an initial cell search by detecting a PSS from BS 105. The PSS enables time-period synchronization and indicates a physical layer identity value. UE 115 can subsequently receive an SSS. The SSS enables radio frame synchronization and provides a cell identity value, which can be combined with a physical layer identity value to identify the cell. The PSS and SSS can be located in the center portion of the carrier or at any suitable frequency within the carrier.

[0057] After receiving the PSS and SSS, UE 115 can receive the MIB. The MIB may include system information for initial network access and scheduling information for RMSI and / or OSI. After decoding the MIB, UE 115 can receive the RMSI and / or OSI. The RMSI and / or OSI may include radio resource control (RRC) information related to the Random Access Channel (RACH) protocol, paging, control resource set (CORESET) for monitoring the Physical Downlink Control Channel (PDCCH), Physical UL Control Channel (PUCCH), Physical UL Shared Channel (PUSCH), power control, and SRS.

[0058] Physical channels can be multiplexed on a carrier using various techniques. Physical control channels and physical data channels can be multiplexed on a downlink carrier, for example, using one or more of Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), Hybrid TDM-FDM, or Space Division Multiplexing (SDM). A control region (e.g., a control resource set (CORESET)) for physical control channels can be defined by the number of symbol periods and can extend across the system bandwidth or a subset of the system bandwidth of the carrier. One or more control regions (e.g., CORESETs) can be configured for a set of UEs. For example, one or more UEs can monitor or search control regions for control information based on one or more search space sets, and each search space set can include one or more control channel candidates in one or more aggregation levels arranged in a cascaded manner. An aggregation level for control channel candidates can refer to the number of control channel resources (e.g., control channel elements (CCEs)) associated with coded information in a control information format having a given payload size. The search space set may include a common search space set configured to send control information to multiple UEs 115 and a UE-specific search space set configured to send control information to a specific UE 115.

[0059] After obtaining the MIB, RMSI, and / or OSI, UE 115 can execute a random access procedure to establish a connection with BS 105. In some examples, the random access procedure can be a four-step random access procedure. For example, UE 115 can transmit a random access preamble, and BS 105 can respond with a random access response. The random access response (RAR) may include the detected random access preamble identifier (ID) corresponding to the random access preamble, timing advance (TA) information, UL grant, temporary cell radio network temporary identifier (C-RNTI), and / or backoff indicator. Upon receiving the random access response, UE 115 can transmit a connection request to BS 105, and BS 105 can respond with a connection response. The connection response may indicate a contention resolution. In some examples, the random access preamble, RAR, connection request, and connection response may be referred to as message 1 (MSG 1), message 2 (MSG 2), message 3 (MSG 3), and message 4 (MSG 4), respectively. In some examples, the random access procedure can be a two-step random access procedure, where UE 115 can transmit the random access preamble and connection request in a single transmission, and BS 105 can respond by transmitting the random access response and connection response in a single transmission.

[0060] After the connection is established, UE 115 and BS 105 can enter the normal operation phase, during which operational data can be exchanged. For example, BS 105 can schedule UE 115 for UL and / or DL ​​communication. BS 105 can transmit UL and / or DL ​​scheduling permission to UE 115 via PDCCH. The scheduling permission can be transmitted in the form of DL control information (DCI). BS 105 can transmit DL communication signals (e.g., carrying data) to UE 115 via PDSCH based on the DL scheduling permission. UE 115 can transmit UL communication signals to BS 105 via PUSCH and / or PUCCH based on the UL scheduling permission.

[0061] In some respects, BS 105 can use Hybrid Automatic Repeat Request (HARQ) technology to communicate with UE 115 to improve communication reliability, such as to provide Ultra Reliable Low Latency Communication (URLLC) service. BS 105 can schedule UE 115 for PDSCH communication by transmitting DL permission in the PDCCH. BS 105 can transmit DL data packets to UE 115 according to the scheduling in the PDSCH. DL data packets can be transmitted in transport blocks (TBs). If UE 115 successfully receives DL data packets, UE 115 can transmit a HARQ acknowledgment (ACK) to BS 105. Conversely, if UE 115 fails to successfully receive the DL transmission, UE 115 can transmit a HARQ negative acknowledgment (NACK) to BS 105. Once a HARQ NACK is received from UE 115, BS 105 retransmits the DL data packets to UE 115. The retransmission may include the same encoded version of the DL data as the initial transmission. Alternatively, retransmissions may include an encoded version of DL data that differs from the initial transmission. UE 115 may apply soft combining to combine encoded data received from the initial transmission and retransmissions for decoding. BS 105 and UE 115 may also apply HARQ to UL communications using a mechanism substantially similar to DL HARQ.

[0062] In some aspects, network 100 may operate on a system BW or a component carrier (CC) BW. Network 100 may divide the system BW into multiple BWPs (e.g., multiple parts). BS 105 may dynamically assign UE 115 to operate on a particular BWP (e.g., a part of the system BW). The assigned BWP may be referred to as the active BWP. UE 115 may monitor the active BWP to look for signaling information from BS 105. BS 105 may schedule UE 115 to perform UL or DL ​​communication in the active BWP. In some aspects, BS 105 may assign a pair of BWPs within a CC to UE 115 for UL and DL communication. For example, the BWP pair may include one BWP for UL communication and one BWP for DL ​​communication.

[0063] In some respects, network 100 may operate on a shared channel, which may include a shared frequency band or an unlicensed frequency band. For example, network 100 may be an NR unlicensed (NR-U) network. BS 105 and UE 115 may be operated by multiple network operating entities. To avoid collisions, BS 105 and UE 115 may employ a Listen-Before-Talk (LBT) procedure to monitor transmission opportunities (TXOPs) in the shared channel. For example, a transmitting node (e.g., BS 105 or UE 115) may perform an LBT before transmitting in the channel. When the LBT passes, the transmitting node may then transmit. When the LBT fails, the transmitting node may suppress transmission in the channel. In one example, LBT may be based on energy detection. For example, when the signal energy measured from the channel is below a threshold, the LBT result is pass. Conversely, when the signal energy measured from the channel exceeds the threshold, the LBT result is fail. In another example, LBT may be based on signal detection. For example, when no channel reservation signal (e.g., a predefined preamble signal) is detected in the channel, the LBT result is pass. In some aspects, network 100 may utilize an FBE-based contention scheme to share radio channels among multiple BS 105s and / or UEs 115s using different network operating entities and / or different radio access technologies (RATs).

[0064] Figure 2A An example of a wireless communication system 200 supporting beam fault recovery techniques for serving multiple transmit-receive points (TRPs) in a cellular cell 210 (Pcell and / or Scell) is described according to various aspects of this disclosure. As discussed above, Figure 2AThe multiple TRPs described herein are examples of a single beam group. In some examples, wireless communication system 200 may implement aspects of wireless communication system 100. Wireless communication system 200 may include UE 205 and communicate with several TRPs 215, which may be examples of the corresponding devices described herein. In this example, TRP 215 may provide a multi-TRP serving cell, for example, where a first beam 220-a of a first TRP 215-a and a second beam 220-b of a second TRP 215-b provide communication with UE 205.

[0065] In some scenarios, multi-TRP transmissions can be configured based on a single downlink control information (DCI) communication. In other scenarios, multi-TRP transmissions can be configured based on multiple downlink control information (DCI) communications, wherein a first DCI (e.g., transmitted from a first TRP 215-a in PDCCH1) schedules downlink shared channel transmissions (e.g., PDSCH1 transmitted from a first TRP 215-a via a first beam 220-a), and a second DCI (e.g., transmitted from a second TRP 215-b in PDCCH2) schedules second downlink shared channel transmissions (e.g., PDSCH2 transmitted from a second TRP 215-b via a second beam 220-b). In some scenarios, the TRP 215 distinction at UE 205 can be based on the value of a CORESET pool index (e.g., CORESETPoolIndex), wherein each CORESET (e.g., up to five CORESETs) can be configured with a CORESET pool index value. In some cases, the CORESET pool index value can be 0 or 1, which groups the CORESET into two groups, which may correspond to different TRP 215s. Only some CCs can be configured to have two CORESET pool index values, while other CCs may not be configured to have two CORESET pool index values, and therefore BFD / BFR on a per TRP 215 basis can be provided to CCs configured to have two CORESET pool index values.

[0066] In some scenarios, UE 205 can be configured to provide 215 BFRs per TRP, which enables separate BFDs and separate CBDs for the beam corresponding to TRP 215 in a CC with two CORESET pool index values. Without 215 BFRs per TRP, beam failure detection and beam candidate determination may not be triggered until all beams in that CC have weakened. With 215 BFRs per TRP, a recovery procedure can be performed when a beam for a given TRP weakens, and the optimal beam corresponding to that TRP 215 can be identified without waiting for beams in other TRPs 215 to weaken as well, thereby enhancing reliability and communication efficiency. Figure 2A In this example, the serving cell 210 may be configured with two CORESET pool index values, one associated with a first TRP 215-a and the second associated with a second TRP 215-b. In this scenario, each TRP 215 may transmit one or more BFD reference signals that can be monitored by the UE 205. In this example, the UE 205 may determine that, over a time period, the first beam 220-a of the first CORESET pool index value has a channel metric below a threshold (e.g., the reference signal received power RSRP) (e.g., when the radio link quality of the reference signal associated with the CORESET pool index value in the BFD reference signals is worse than a threshold Q). out (Time). The following sections further discuss various examples of beam failure declaration, candidate beam detection, and beam recovery.

[0067] Figure 2B The example sequence 230 was explained, and its explanation system (such as...) Figure 2A Beam fault detection (BFD) and beam fault recovery (BFR) in the system described herein. Figure 2B As explained, TRP set q0 232 is providing communication. As explained, set q0 includes two TRP reference signals (RS) indicating two communication beams. For example, TRP set q0 232 is the reference signal transmitted by TRP 215-a and / or TRP 215-b and monitored and measured by UE 205 for BFD. In step 236, the level of one or more TRP resources in set 232 is measured and determined to be below the threshold Qout, resulting in an out-of-synchronization (OOS) indication. In step 238, in response to the OOS indication, a beam fault detector (BFD) timer is started and the beam fault index (BFI) count is set to 1. However, as Figure 2B As indicated in the documentation, BFD timer 234 times out before receiving another OOS indication.

[0068] In step 242, the level of one or more TRP resources in set 232 is measured and determined to be below the configurable threshold Qout, resulting in an OOS indication. As before, in step 244, BFD timer 246 is started and BFI counter is initiated. Figure 2B As explained, in step 248, one or more TRP resources in set 232 are measured again and determined to be below the threshold Qout, resulting in another OOS indication occurring within BFD timer 246. In step 250, the BFI counter is incremented until it reaches the MaxCnt (maximum count) value. In this particular example, MaxCnt is set to 2; however, MaxCnt can be configurably set to any integer that causes the TRP resources to cause an OOS indication within a set time period.

[0069] In step 250, BFR timer 252 is started when the BFI counter is at the MaxCnt value. In step 254, the reference signal received power (RSRP) corresponding to TRP RS q1 234 is measured to have a value greater than the threshold. In step 256, a report from step 254 is received and a request for TRP resources in set 234 is presented. In step 260, a random access procedure on the random access channel (RACH) can be triggered, and in step 258, a RACH request can be sent, for example, to the primary cell (PCell) receiver that made the request. The transmission of the RACH message can trigger response window 272. Within the first timing window, PDCCH 262, which stops BFR timer 264 within the timeout period of response window 272, or PDCCH 266, which stops BFR 268 after the response window times out but before BFR timer 252 times out, can be received, which will result in the adaptation of TRP resources from set q1 234. However, if step 270 is reached, the BFR times out and causes the overall recovery to fail.

[0070] Figure 3A Examples of a process flow 300 supporting beam fault recovery techniques for serving multiple beam groups in a cellular cell, according to various aspects of this disclosure, are explained. In some examples, process flow 300 may implement various aspects of wireless communication systems 100 or 200, and further explanation is provided. Figure 2BThe process flow 230 includes various aspects. Process flow 300 can be implemented by UE 310 and PCell 305, which has two values ​​in the CORESET pool index (and is served by multiple different beamgroups). In the following description of process flow 300, communication between UE 310 and PCell 305 may be transmitted in a different order than the example order shown, or operations performed by UE 310 and PCell 305 may be performed in a different order or at different times. Some operations may also be omitted from process flow 300, and others may be added to process flow 300.

[0071] In some examples, the operations described in process flow 300 may be performed by hardware (e.g., including circuit systems, processing blocks, logic components, and other components), code executed by a processor (e.g., software or firmware), or any combination thereof. Alternative examples are possible, in which some steps are performed in a different order than described or not at all. In some cases, the steps may include additional features not mentioned below, or further steps may be added.

[0072] In message 315, Pcell 305 can transmit and UE 310 can receive one or more BFD reference signals from the BFD reference signal set. In this regard, UE 310 can monitor the BFD reference signals based on beamgroup BFD parameters or cell-level BFD parameters. UE 310 can measure one or more channel metrics of the BFD reference signals as part of the BFD. Depending on various aspects, the BFD reference signals can be transmitted by different beamgroups and have multiple CORESET pool index values, and the BFD reference signals have an indication of the associated CORESET pool index value (e.g., 0 or 1 (based on a sequence of reference signals configured as CORESET pool index values)).

[0073] In step 320, UE 310 may determine that BFD has been detected (e.g., as described above in...). Figure 2B (As discussed in the text). In some cases, the detection of BFD can be based on the channel metric of the reference signal being below a threshold (e.g., Q). outIn some cases, BFD can be based on periodic CSI-RS resources configured by RRC (e.g., configured by the RRC parameter failureDetectionResources). In some cases, BFD reference signals can include up to two reference signals on a single port. In some instances, if no BFD reference signals are configured, the set of reference signals indicated by the active TCI state of the CORESET monitored by UE 310 can be used. If multiple reference signal indices exist for the active TCI state of the CORESET, the reference signal index with QCL type D is preferred. Otherwise, QCL type A, QCL type B, or QCL type C can be used. The physical layer in UE310 can be configured based on a threshold (e.g., Q... out The BFD (Browser Detection and Ranging) is set to evaluate radio link quality. In some instances, if the radio link quality of all reference signals in the BFD resource set is worse than Q... out Then UE 310 can declare a beam fault.

[0074] In step 325, UE 310 may perform candidate beam detection (CBD). In some cases, CBD may be based on periodic CSI-RS / SSBs configured by RRC (e.g., configured by the RRC parameter candidateBeamRSList). In some cases, up to 16 resources with corresponding random access preamble indices (e.g., ra-preamble-index). UE 310 may provide resources in this list that have indices equal to or greater than a threshold (e.g., Q). in The reference signal index and RSRP value of the threshold can be configurable.

[0075] In communication 330, UE 310 may initiate BFR based on beamgroup BFD parameters or cell-level BFD parameters. For example, in some instances, UE 310 may transmit a RACH request to Pcell 305. In some cases, UE 310 may initiate a random access procedure (e.g., contention-free random access) based on a random access resource (e.g., ra-preamble-index) associated with a selected reference signal index (e.g., RS index q_new) where RSRP is above a threshold.

[0076] In communication 335, Pcell 305 can transmit a BFR response based on beamgroup BFD parameters or cell-level BFD parameters, and UE 310 can receive this BFR response. In some cases, UE 310 can monitor the PDCCH in the search space set provided by RRC parameters (e.g., recoverySearchSpaceId) to detect a DCI format with a CRC scrambled by C-RNTI or MCS-C-RNTI starting from time slot n+4. If UE 310 receives the PDCCH within this window, BFR is complete. After the BFR response, UE 310 can use a QCL RS assumption with respect to the same QCL parameters as the quasi-coexistence (QCL) parameters associated with the reference signal index q_new until UE 310 receives activation for the TCI state. In some cases, after the UE 310 detects a set of symbols (e.g., 28 symbols) starting from the last symbol of the first PDCCH received with a DCI format scrambled by C-RNTI or MCS-C-RNTI, the UE 310 assumes that the same QCL parameter as the QCL parameter associated with the RS index q_new is used for PDCCH monitoring in the CORESET with index 0.

[0077] In some scenarios, a Pcell can be configured with multiple beamgroups (e.g., TRP), and the CORESET pool index can be configured with multiple values. In some scenarios, separate RACH resources can be configured for different CORESET pool index values, which allows the UE 310 to indicate a beam fault associated with a specific CORESET pool index value, which can be associated with a specific beamgroup. As discussed herein, in some scenarios, one or more Scells can be configured with multiple CORESET pool index values, and the UE can perform BFD / BFR for the Scell, referencing... Figure 3B Examples of it were discussed.

[0078] Figure 3BAnother example of a process flow 340 supporting beam fault recovery techniques for multiple beamgroups in a sub-cell, according to various aspects of this disclosure, is described. In some examples, process flow 340 may implement various aspects of wireless communication system 100 or 200. Process flow 340 may be implemented by UE 344, as well as PCell 342 and Scell ​​346, wherein Scell ​​346 may have multiple CORESET pool index values ​​(and be served by multiple different TRPs), as described herein. In the following description of process flow 340, communication between UE 344, PCell 342, and Scell ​​346 may be transmitted in a different order than the example order shown, or operations performed by UE 344, PCell 342, and Scell ​​346 may be performed in a different order or at different times. Some operations may also be omitted from process flow 340, and others may be added to process flow 340.

[0079] In some examples, the operations described in process flow 340 may be performed by hardware (e.g., including circuit systems, processing blocks, logic components, and other components), code executed by a processor (e.g., software or firmware), or any combination thereof. Alternative examples are possible, in which some steps are performed in a different order than described or not at all. In some cases, the steps may include additional features not mentioned below, or further steps may be added.

[0080] At a high level, UE 344 can monitor BFD RS from Scell ​​346, report BFD of Scell ​​346 to Pcell 342, and perform BFR for Scell ​​346 via Pcell 342 (e.g., via RACH procedure).

[0081] In communication 348, Scell ​​346 can transmit and UE 344 can receive one or more BFD reference signals from the BFD reference signal set. In this regard, UE 344 can monitor the BFD reference signals based on beamgroup BFD parameters or cell-level BFD parameters. UE 344 can measure one or more channel metrics of the BFD reference signals as part of the BFD protocol. Depending on various aspects, the BFD reference signals can be transmitted by different TRPs and have multiple CORESET pool index values, and the BFD reference signals have an indication of the associated CORESET pool index value (e.g., 0 or 1 (based on the reference signal sequence configured as CORESET pool index values)).

[0082] In step 350, UE 344 can determine that BFD was detected at Scell ​​346. In some cases, similar to the above reference... Figure 2B and3A The BFD detection discussed can be based on a channel metric of the reference signal (received at communication 348) below a threshold (e.g., Q). out In some cases, BFD can be based on periodic CSI-RS resources configured by RRC (e.g., configured by the RRC parameter failureDetectionResources). In some cases, BFD reference signals can include up to two reference signals on a single port. If no BFD reference signals are configured, the set of reference signals indicated by the active TCI state of the CORESET monitored by UE 344 can be used. If multiple reference signal indices exist for the active TCI state of the CORESET, the reference signal index with QCL type D is preferred. Otherwise, QCL type A, QCL type B, or QCL type C can be used. The physical layer in UE 344 can be configured based on a threshold (e.g., Q...). out The BFD (Browser Detection and Ranging) is set to evaluate radio link quality. If the radio link quality of all reference signals in the BFD resource set is worse than Q... out Then UE 344 can declare a beam fault.

[0083] In one example, two fault detection resource sets can be configured, each corresponding to a different CORESET pool index value. In another example, each resource within a fault detection resource used to transmit BFD reference signals can be configured with a CORESET pool index value. In some cases, if a resource is not configured with a CORESET pool index value, it is assumed that the resource is associated with a CORESET pool index value of 0. In some cases, BFD reference signal resources can be configured with two values ​​for the CORESET pool index, in which case the associated reference signals are considered for both TRPs. In some cases, when no fault detection resource is configured, the first and second resource sets are determined by the set of reference signals indicated by the active TCI state of the CORESET configured with CORESET pool index 0 or 1, respectively. In some cases, the radio link quality of all reference signals in the BFD resource associated with the CORESET pool index value is worse than a configured threshold (e.g., Q). out When this happens, a beam fault can be declared for that CORESET pool index value.

[0084] In communication 352, UE 344 can initiate BFR based on beamgroup BFD parameters or cell-level BFD parameters. For example, UE 344 can transmit a Link Recovery Request (LRR) or other BFR requests on Pcell 342. In some cases, the recovery request can be transmitted on: Pcell, primary Scell ​​(Pscell), or Scell ​​configured for a PUCCH with PUCCH BFR configured (PUCCH-Scell). LRR can indicate that UE 344 is requesting uplink resources (e.g., similar to a scheduling request (SR)) and can use PUCCH format 0 or 1. In some cases, two PUCCH resources can be configured for LRR using two corresponding scheduling request IDs (e.g., indicated by schedulingRequestID-BFR-Scell). PUCCH resources or scheduling request IDs can be associated with CORESET pool index values. If a BFD is declared for a CORESET pool index value in Scell ​​346, then in some cases, a PUCCH resource / scheduling request ID corresponding to another CORESET pool index value can be used for LRR transmission. This resource selection rule stipulates that if the Scell ​​346 and PUCCH cells have the same beam, and if all beams used for one TRP become weak, then LRR can be transmitted using the beam corresponding to the other TRP. For example, this rule can apply when a CC with PUCCH-BFR is in the same frequency band as Scell ​​346.

[0085] In other scenarios, the PUCCH resource / scheduling request ID corresponding to the same CORESET pool index value is used for LRR transmission. This choice can provide LRR transmission to the same TRP for non-ideal backhaul scenarios. For example, this rule can be followed when separate feedback is configured for different cells (ACKNACKFeedbackMode = SeparateFeedback). In other scenarios, the PUCCH resource / scheduling request ID corresponding to CORESET pool index = 0 is used for LRR transmission. For example, this rule can be followed when a CC with PUCCH-BFR is in a different frequency band than Scell ​​346. In still other scenarios, multiple PUCCH resource / scheduling request IDs can be used to transmit LRR regardless of the CORESET pool index for which BFD is advertised. This means that multiple instances of LRR transmission are provided across multiple PUCCH resources (and transmitted to two TRPs).

[0086] In communication 354, Pcell 342 may provide uplink permission to UE 344. This uplink permission may be a normal uplink permission with C-RNTI / MCS-C-RNTI that can be used as a response to LRR, which UE 344 can use to transmit a PUSCH in which BFR MAC-CE can be transmitted. Note that in some cases, UE 344 may have existing uplink permission, in which case LRR and associated uplink permission operations may be skipped.

[0087] In step 356, UE 344 may execute the CBD procedure. Before sending the MAC-CE with a beam fault recovery message, UE 344 may first identify one or more candidate beams for the faulty Scell ​​346. The CBD procedure may be performed as described above. Figure 3A and Figure 2B The discussed approach is executed in a similar manner, the difference being that this procedure is for Scell ​​346. In some cases (e.g., indicated in the RRC in candidateBeamRSSCellList-r16), up to 64 resources can be transmitted on the faulty Scell ​​346 or on another CC in the same frequency band. In some cases, each candidate beam is associated with a CORESET pool index value. In one example, two candidate beam lists, each corresponding to a CORESET pool index value, can be provided (e.g., two lists are configured for the parameter candidateBeamRSSCellList-r16). In another example, each reference signal in the candidate beam list (e.g., in candidateBeamRSSCellList-r16) can be configured with a CORESET pool index value. In some cases, if a reference signal is not configured with a CORESET pool index value, it is assumed that the reference signal is associated with a CORESET pool index value of 0. Additionally, it is permissible to configure a reference signal with two CORESET pool index values, in which case the reference signal is considered for both TRPs. In some instances, when a BFD is declared for a CORESET pool index value, candidate beams can be identified only within reference signals associated with the same CORESET pool index value.

[0088] In communication 358, UE 344 may transmit beam fault recovery messages in a BFR MAC-CE (BFRQ). Examples of BFR MAC-CEs are further discussed below. In some instances, the BFR MAC-CE may be transmitted using resources provided in the uplink grant and may be transmitted on any cell, including the faulty Scell ​​346. In some cases, UE 344 may indicate the CORESET pool index value in the Scell ​​MAC-CE for the corresponding Scell ​​346. In some cases, such indication may be provided according to the examples discussed below.

[0089] In communication 360, Pcell 342 can provide a BFR response to UE 344 based on beamgroup BFD parameters or cell-level BFD parameters. In some cases, this response can be an uplink grant to schedule a new transmission (e.g., with a switched New Data Indicator (NDI)) for the same HARQ procedure as the PUSCH carrying the BFR MAC-CE. In some cases, if a new beam corresponding to the CORESET pool index value is reported in Scell ​​346 in the BFR MAC-CE, then UE 344 can use a new beam (e.g., q) with only the same CORESET pool index value reset to Scell ​​346 28 symbols after the end of the BFR response (end of PDCCH). new The QCL assumption is as follows: Assuming that PUCCH resources are also associated with CORESET pool index values, when Scell ​​346 is a PUCCH-Scell, the spatial relationships of only PUCCH resources associated with the same CORESET pool index value are reset to the new beam in Scell ​​346. If PUCCH resources are not associated with CORESET pool index values, and if BFR MAC-CE indicates that the spatial relationships are for two CORESET pool index values ​​(e.g., two q values ​​in Scell ​​346), then... new If the BFD and candidate beams are obtained, the PUCCH beam is reset to the candidate beam corresponding to CORESET pool index = 0 (when Scell ​​is PUCCH-Scell).

[0090] Therefore, in some cases, when a secondary cell is configured for uplink control information transmission, UE344 can reset the beam for one or more PUCCH resources associated with the same value as the CORESET pool index value of the identified candidate beam. Furthermore, in some cases, when a secondary cell is configured for uplink control information transmission, UE344 can reset the beam for one or more PUCCH resources in response to the CORESET pool index value of the identified candidate beam having a first value (e.g., CORESET pool index = 0), and suppress the reset of the beam for the one or more PUCCH resources in response to the CORESET pool index value of the identified candidate beam having a second value (e.g., CORESET pool index = 1).

[0091] Figure 3C Another example process flow 370 for beam fault recovery techniques for multiple beamgroups in a sub-cell, according to various aspects of this disclosure, is described. In some examples, process flow 370 may implement various aspects of wireless communication systems 100 or 200. Process flow 370 may be implemented by UE 372, PCell 374, and Scell ​​376, wherein Scell ​​376 may have multiple CORESET pool index values ​​(and be served by multiple different TRPs), as described herein. In some aspects, PCell 372 may operate on a carrier frequency in frequency range 1 (FR1), and Scell ​​376 may operate on a carrier frequency in frequency range 2 (FR2). FR1 may refer to a sub-6 GHz frequency (e.g., between about 4 GHz and about 7 GHz), and FR2 may refer to a millimeter wave frequency (e.g., between about 24 GHz and about 52 GHz). In the following description of process flow 370, communication between UE 372, Pcell 374, and Scell ​​376 may be transmitted in a different order than the example order shown, or operations performed by UE 372, Pcell 374, and Scell ​​376 may be performed in a different order or at different times. Some operations may also be omitted from process flow 370, and others may be added to process flow 370.

[0092] In some examples, the operations described in process flow 340 may be performed by hardware (e.g., including circuit systems, processing blocks, logic components, and other components), code executed by a processor (e.g., software or firmware), or any combination thereof. Alternative examples are possible, in which some steps are performed in a different order than described or not at all. In some cases, the steps may include additional features not mentioned below, or further steps may be added.

[0093] Process flow 370 may be substantially similar to process flow 340. For example, UE 344 may monitor BFD RS 377 from Scell ​​376 and report the BFD of Scell ​​376 to Pcell 374. However, in process flow 370, UE 372 may perform RACH procedures with Scell ​​376 instead of Pcell 374 to complete the BFR for Scell ​​376.

[0094] In step 378, UE 372 can determine that BFD was detected at Scell ​​376. In some cases, similar to the above reference... Figure 2B , 3A As discussed in 3B, the detection of BFD can be based on a reference signal (e.g., as mentioned above regarding...). Figure 2B The channel metric of the communication discussed in 348, received from Scell ​​376 (e.g., BFD RS 377), is below a threshold (e.g., Q). out In some cases, BFD can be based on periodic CSI-RS resources configured by RRC (e.g., configured by the RRC parameter failureDetectionResources). In some cases, BFD reference signals can include up to two reference signals on a single port. If no BFD reference signals are configured, the set of reference signals indicated by the active TCI state of the CORESET monitored by UE 374 can be used. If multiple reference signal indices exist for the active TCI state of the CORESET, the reference signal index with QCL type D is preferred. Otherwise, QCL type A, QCL type B, or QCL type C can be used. The physical layer in UE374 can be configured based on a threshold (e.g., Q...). out The BFD (Browser Detection and Ranging) is set to evaluate radio link quality. If the radio link quality of all reference signals in the BFD resource set is worse than Q... out Then UE 374 can declare a beam fault.

[0095] In one example, two fault detection resource sets can be configured, each corresponding to a different CORESET pool index value. In another example, each resource within a fault detection resource used to transmit BFD reference signals can be configured with a CORESET pool index value. In some cases, if a resource is not configured with a CORESET pool index value, it is assumed that the resource is associated with a CORESET pool index value of 0. In some cases, BFD reference signal resources can be configured with two values ​​for the CORESET pool index, in which case the associated reference signals are considered for both TRPs. In some cases, when no fault detection resource is configured, the first and second resource sets are determined by the set of reference signals indicated by the active TCI state of the CORESET configured with CORESET pool index 0 or 1, respectively. In some cases, the radio link quality of all reference signals in the BFD resource associated with the CORESET pool index value is worse than a configured threshold (e.g., Q). out When this happens, a beam fault can be declared for that CORESET pool index value.

[0096] In communication 380, in response to the detection of BFD at Scell ​​376, UE 372 transmits an SR indication to Pcell 374 via a scheduling request (SR) (on the FR1 frequency carrier of Pcell 374). In some aspects, UE 372 may, for example, use PUCCH format 0 or PUCCH format 1 to transmit the SR on PUCCH resources. The SR indication may request Pcell 374 to provide PUSCH resources to UE 372, which UE 372 can use to transmit a BFRQ for Scell ​​376. In other words, UE 372 may determine that it wants to initiate a BFR for Scell ​​376 by transmitting the SR indication.

[0097] In some respects, UE 372 can initiate a BFR for Scell ​​376 based on beamgroup BFD parameters or cell-level BFD parameters. An SR indication can indicate that UE 344 is requesting uplink resources, where the SR indication can be transmitted using PUCCH resources. In some cases, two PUCCH resources can be configured for requesting a BFR for Scell ​​376 using two corresponding scheduling request IDs (e.g., indicated by schedulingRequestID-BFR-Scell). The PUCCH resource or scheduling request ID can be associated with a CORESET pool index value. If a BFD is declared for a CORESET pool index value in Scell ​​376, in some cases, a PUCCH resource / scheduling request ID corresponding to another CORESET pool index value can be used for LRR transmission. This resource selection rule stipulates that if Scell ​​376 and PUCCH cells use the same beam, and if all beams used for a TRP become weak, then the SR indication (for a BFR request to Scell ​​376) can use the beam corresponding to the other TRP for transmission. For example, this rule can apply when a CC with PUCCH-BFR is in the same frequency band as Scell ​​376.

[0098] In other cases, the PUCCH resource / scheduling request ID corresponding to the same CORESET pool index value is used for SR indication transmission. This choice can specify that SR indications are transmitted to the same TRP for non-ideal backhaul scenarios. For example, this rule can be followed when separate feedback is configured for different cells (ACKNACKFeedbackMode = SeparateFeedback). In other cases, the PUCCH resource / scheduling request ID corresponding to CORESET pool index = 0 is used for SR indication (BFR request for Scell ​​376) transmission. For example, this rule can be followed when a CC with PUCCH-BFR is in a different frequency band than Scell ​​376. In still other cases, multiple PUCCH resource / scheduling request IDs can be used to transmit SR indications, regardless of the CORESET pool index for which BFD was declared. This means that multiple instances of SR indication transmission are provided across multiple PUCCH resources (and transmitted to two TRPs).

[0099] In communication 382, ​​Pcell 374 may provide uplink permission to UE 372. This uplink permission may be a normal uplink permission with C-RNTI / MCS-C-RNTI that can be used as a response to an SR indication (for a BFR request to Scell ​​376), which UE 372 can use to transmit a PUSCH in which a BFR MAC-CE can be transmitted. Note that in some cases, UE 344 may have existing uplink permission, in which case LRR and associated uplink permission operations may be skipped.

[0100] In communication 384, UE 372 may transmit a beam fault report indicating BFD at Scell ​​376 in a BFR MAC-CE (BFRQ). Examples of BFR MAC-CEs are further discussed below. The BFR MAC-CE is transmitted using resources provided in the uplink grant and can be transmitted on any cell, including the faulty Scell ​​376. In some cases, UE 372 may indicate the CORESET pool index value in the Scell ​​MAC-CE for the corresponding Scell ​​376. Generally, UE 372 may indicate the beam fault and the desired or candidate beam for recovery. In some cases, such indication may be provided according to the examples discussed below.

[0101] In communication 386, Pcell 374 can provide BFR configuration to UE 372 for performing BFR for Scell ​​376. The FR configuration can indicate a new CORESET with a TCI state active for Scell ​​376 in the PUCCH TCI update. In some aspects, the BFR configuration can be based on beamgroup BFD parameters or cell-level BFD parameters. In some cases, the response can be an uplink grant to schedule a new transmission (e.g., with a switched New Data Indicator (NDI)) for the same HARQ procedure as the PUSCH carrying the BFR MAC-CE. In some cases, if a new beam corresponding to the CORESET pool index value in Scell ​​346 is reported in the BFR MAC-CE, then UE 344 can use a new beam (e.g., q) in Scell ​​346 after 28 symbols from the end of the BFR response (end of PDCCH) with only the same CORESET pool index value reset to the new beam (e.g., q) if the new beam in Scell ​​346 has only the same CORESET pool index value. newThe QCL assumption is as follows: Assuming that PUCCH resources are also associated with CORESET pool index values, when Scell346 is a PUCCH-Scell, the spatial relationships of only PUCCH resources associated with the same CORESET pool index value are reset to the new beam in Scell ​​346. If PUCCH resources are not associated with CORESET pool index values, and if BFR MAC-CE indicates that the spatial relationships of two CORESET pool index values ​​(e.g., two q values ​​in Scell ​​346) are not associated with CORESET pool index values, then... new If the BFD and candidate beams are obtained, the PUCCH beam is reset to the candidate beam corresponding to CORESET pool index = 0 (when Scell ​​is PUCCH-Scell).

[0102] Therefore, in some cases, when a secondary cell is configured for uplink control information transmission, UE344 can reset the beam for one or more PUCCH resources associated with the same value as the CORESET pool index value of the identified candidate beam. Furthermore, in some cases, when a secondary cell is configured for uplink control information transmission, UE344 can reset the beam for one or more PUCCH resources in response to the CORESET pool index value of the identified candidate beam having a first value (e.g., CORESET pool index = 0), and suppress the reset of the beam for the one or more PUCCH resources in response to the CORESET pool index value of the identified candidate beam having a second value (e.g., CORESET pool index = 1).

[0103] In step 388, Scell ​​376 can perform DL channel recovery and the DL channel is recovered.

[0104] In communication 390, Scell ​​376 may provide PDCCH DCI to UE 372 (e.g., transmitted via the FR2 frequency of Scell ​​376). PDCCH DCI may be transmitted based on UE 372's C-RNTI. PDCCH DCI may indicate resources used by UE 372 to transmit RACH requests (e.g., RACH preamble or MSG1).

[0105] In communication 392, upon receiving the PDCCH DCI, UE 372 may use the resources indicated by the PDCCH DCI received in communication 390 to transmit a RACH request.

[0106] In communication 394, upon receiving a RACH request, Scell ​​376 can respond with MSG2. In some respects, MSG2 can indicate scheduling permission for UE 372 to transmit UL communications. At this point, the Scell ​​UL channel is restored at step 396.

[0107] The BFD and BFR procedures discussed in this article can be found in Figure 1 and Figure 2A The implementation on the UE and BS in the network described herein. Subsequently, Figure 4 The example UE 400 was explained, and Figure 5 An example BS 500 based on some embodiments as discussed herein is explained.

[0108] Figure 4 This is a block diagram of an exemplary UE 400 according to some aspects of this disclosure. UE 400 may be as described above. Figure 1 , 2A The UEs 115, 205, 310, 344, and 372 discussed in 3A, 3B, and 3C. As shown, UE 400 may include a processor 402, a memory 404, a communication module 408, a BFD / BFR module 409, a transceiver 410 including a modem subsystem 412 and a radio frequency (RF) unit 414, and one or more antennas 416. These components may communicate directly or indirectly with each other, for example, via one or more buses.

[0109] Processor 402 may include a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), controller, field-programmable gate array (FPGA) device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein. Processor 402 may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0110] Memory 404 may include cache memory (e.g., the cache memory of processor 402), random access memory (RAM), magnetoresistive RAM (MRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory devices, hard disk drives, other forms of volatile and non-volatile memory, or combinations of different types of memory. In one aspect, memory 404 includes a non-transitory computer-readable medium. Memory 404 may store or have instructions 406 recorded thereon. Instructions 406 may include, when executed by processor 402, causing processor 402 to perform various aspects of this disclosure in conjunction with reference to UE 115 (e.g., ...). Figure 2A-2B Instructions 406 are the operations described in aspects of 3A-3C, 6-8, 9A-9D, 10, and 11. Instruction 406 may also be referred to as program code. Program code can be used to cause a wireless communication device to perform these operations, for example, by causing one or more processors (such as processor 402) to control or command the wireless communication device to do so. The terms "instruction" and "code" should be interpreted broadly to include any type of computer-readable statement. For example, the terms "instruction" and "code" can refer to one or more programs, routines, subroutines, functions, procedures, etc. "Instruction" and "code" can include a single computer-readable statement or many computer-readable statements.

[0111] Through transceiver 410, communication module 408 can use one or more beams from a first group to establish a connection with at least a first beam group (e.g., TRP) and use one or more beams from a second group to establish a connection with a second beam group (e.g., TRP), wherein each of the first and second beam groups is associated with a sub-cell of UE 400. Generally, through transceiver 410, communication module 408 can establish connections with multiple beam groups (e.g., mTRP).

[0112] Communication module 408 may be implemented as described herein to achieve one or more potential advantages. One implementation may allow UE 408 to provide BFD indication and candidate beams for a specific TRP in a serving cell using multiple TRPs, which can enhance the overall channel quality of network performance and allow indication of a faulty beam for a specific TRP prior to the overall failure of the serving cell. Furthermore, such an implementation may allow UE 408 to improve communication reliability, throughput, and user experience while reducing overall power consumption, among other advantages.

[0113] The communication module 408 may be implemented in hardware, code executed by a processor (e.g., software or firmware), or any combination thereof. If implemented in code executed by a processor, the functionality of the communication module 408 or its sub-components may be performed by a general-purpose processor, DSP, application-specific integrated circuit (ASIC), FPGA or other programmable logic device designed to perform the functions described in this disclosure, discrete gate or transistor logic, discrete hardware components, or any combination thereof. Specifically, the communication module 408 may be implemented on the processor 402.

[0114] BFD / BFR module 409 may be implemented via hardware, software, or a combination thereof. For example, BFD / BFR module 409 may be implemented as a processor, circuitry, and / or instructions 406 stored in memory 404 and executed by processor 402. In some instances, BFD / BFR module 409 may be integrated within modem subsystem 412 and communication module 408. For example, BFD / BFR module 409 may be implemented by a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within modem subsystem 412.

[0115] BFD / BFR module 409 can be used in various aspects of this disclosure, for example, Figure 2A-2B The BFD / BFR module 409 can be configured to perform beam fault detection (BFD) and beam fault recovery (BFR) techniques, as described herein, based on one or more beamgroup parameters and / or one or more cell-level parameters. Specifically, the BFD / BFR module 409 can determine the beam fault configuration for the serving cell. The beam fault configuration may include at least one of the following: beam fault parameters of the beamgroup or beam fault parameters of the cell. The BFD / BFR module 409 can also perform beam fault detection in the serving cell, at least in part, based on the beam fault configuration. In this regard, the BFD / BFR module 409, together with the communication module 408 and / or transceiver 410, can transmit a beam fault recovery request message indicating the faulty beam and candidate replacement beams. Additional aspects of the operation of the BFD / BFR module 409 are further discussed below.

[0116] As discussed above, a UE operating in a serving cell (PCell / SCell / SpCell) can operate with beam group-specific beam fault parameters, cell-level beam fault parameters, or a combination of beam group-specific beam fault parameters and cell-level BFR beam fault parameters, based on beam fault configurations according to various aspects of this disclosure. For example, a UE operating in a serving cell can be configured to perform beam group-specific beam fault detection (BFD), cell-level BFD, beam group-specific beam fault recovery (BFR), cell BFR, radio link monitoring (RLM), radio link fault (RLF) recovery, and / or combinations thereof. Accordingly, in some aspects, in conjunction with other components and features of the UE 400, the BFD / BFR module 409 can facilitate the execution of beam group-specific BFD, cell-level BFD, beam group-specific BFR, cell BFR, RLM, and / or RLF recovery according to this disclosure. In this regard, the BFD / BFR module 409 can determine which type(s) of BFD, BFR, and / or RLM / RLF should be performed, along with the associated parameters. Based on this determination, the BFD / BFR module 409 can cause the UE to initiate one or more of the following: group-specific BFD, cell-level BFD, beamgroup-specific BFR, cell-level BFR, RLM, and / or RLF recovery.

[0117] As shown, transceiver 410 may include modem subsystem 412 and RF unit 414. Transceiver 410 may be configured to communicate bidirectionally with other devices (such as BS 105). Modem subsystem 412 may be configured to modulate and / or encode data from memory 404 and / or communication module 408 according to modulation and coding schemes (MCS) (e.g., low-density parity-check (LDPC) coding scheme, turbo coding scheme, convolutional coding scheme, digital beamforming scheme, etc.). RF unit 414 may be configured to process (e.g., perform analog-to-digital conversion or digital-to-analog conversion, etc.) modulated / coded data (e.g., PUCCH control information, PRACH signals, PUSCH data, SR indication, BFR request, MSG1, BFR MAC-CE) transmitted from modem subsystem 412 (in outgoing transmissions) or originating from another source (such as UE 115 or BS 105). RF unit 414 may be further configured to perform analog beamforming in conjunction with digital beamforming. Although shown as being integrated together in transceiver 410, modem subsystem 412 and RF unit 414 may be separate devices coupled together at UE 115 to enable UE 115 to communicate with other devices.

[0118] RF unit 414 may provide modulated and / or processed data (e.g., data packets (or more generally, data messages containing one or more data packets and other information)) to antenna 416 for transmission to one or more other devices. Antenna 416 may further receive data messages transmitted from other devices. Antenna 416 may provide received data messages for processing and / or demodulation at transceiver 410. Transceiver 410 may provide demodulated and decoded data (e.g., SSB, RMSI, MIB, SIB, PRACH configuration, PDCCH, PDSCH, MSG2, UL approval, RRC configuration, BFD configuration, BFR configuration) to communication module 408 for processing. Antenna 416 may include multiple antennas of similar or different designs to maintain multiple transmission links. RF unit 414 may configure antenna 416.

[0119] In one aspect, UE 400 may include multiple transceivers 410 implementing different RATs (e.g., NR and LTE). In another aspect, UE 400 may include a single transceiver 410 implementing multiple RATs (e.g., NR and LTE). In yet another aspect, transceiver 410 may include various components, wherein different combinations of the components can implement different RATs.

[0120] Figure 5 This is a block diagram of an exemplary BS 500 according to some aspects of this disclosure. The BS 500 may be as described above... Figure 1 The BS 105 in Network 100 discussed above, as mentioned above. Figure 2A , 3A The Pcell / Scell ​​210, 305, 342, 346, 374, 376, and / or as described above in sections 3B and 3C. Figure 2A The TRP 215 discussed herein. As shown, the BS 500 may include a processor 502, a memory 504, a communication module 508, a BFR module 509, a transceiver 510 including a modem subsystem 512 and an RF unit 514, and one or more antennas 516. These components may communicate directly or indirectly with each other, for example, via one or more buses, and in some cases, may be operated on a single processor 502.

[0121] Processor 502 may have various features as a special-purpose processor. For example, these features may include a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein. Processor 502 may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0122] Memory 504 may include cache memory (e.g., the cache memory of processor 502), RAM, MRAM, ROM, PROM, EPROM, EEPROM, flash memory, solid-state memory devices, one or more hard disk drives, memristor-based arrays, other forms of volatile and non-volatile memory, or combinations of different types of memory. In some aspects, memory 504 may include a non-transitory computer-readable medium. Memory 504 may store instructions 506. Instructions 506 may include instructions that, when executed by processor 502, cause processor 502 to perform the operations described herein (e.g., aspects of Figures 2, 3A-3B, and 6-10). Instructions 506 may also be referred to as code, which may be broadly interpreted as including, as described above regarding... Figure 4 Any type of computer-readable statement discussed.

[0123] Communication module 508 can establish communication with a UE (such as UE 400) via a serving cell (e.g., a primary cell and / or a secondary cell), wherein communication via the serving cell uses multiple beams. For example, a first transmit / receive point of the serving cell may use one or more beams from a first group and a second transmit / receive point of the serving cell may use one or more beams from a second group; configure a first uplink resource associated with the first transmit / receive point and a second uplink resource associated with the second transmit / receive point for transmitting a recovery request message at the UE via BFR module 509, the recovery request message indicating a beam failure of the serving cell; receive the recovery request message from the UE; and determine in BFR module 509, based on the recovery request message, that the UE has declared a beam failure.

[0124] The communication module 508 or its sub-components may be implemented in hardware, code executed by a processor (e.g., software or firmware), or any combination thereof. If implemented in code executed by a processor, the functionality of the communication module 508 or its sub-components may be performed by a general-purpose processor, DSP, application-specific integrated circuit (ASIC), FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in this disclosure.

[0125] BFR module 509 is coupled to communication module 508 and / or transceiver 510 to receive a message declaring a beam fault from the UE. In some instances, BFR module 509 is configured to transmit one or more RRC messages or other communications to the UE, which provide indications of available beam fault detection and / or recovery types (e.g., varying by beamgroup or TRP, cell-level, BFR, RLF, etc.) available to the UE in the serving cell (in some instances, including explicit or implicit indications of associated parameters (e.g., resources, reference signals (BFD RS), etc.). In some instances, BFR module 509 is configured to transmit indications of one or more thresholds for the UE to utilize when determining which type(s) of BFD, BFR, and / or RLM / RLF to perform in the serving cell under various circumstances. In some instances, one or more of the thresholds are dynamically configured by BFR module 509. In some instances, the thresholds may be defined by a standard specification or otherwise predefined. Various aspects of this disclosure (e.g., Figure 2A-2B (All aspects of 3A-3C, 6-8, 9A-9D and 10-12) can be executed by BFR module 509.

[0126] As shown, transceiver 510 may include modem subsystem 512 and RF unit 514. Transceiver 510 may be configured to communicate bidirectionally with other devices, such as UE 115 and / or 400 and / or another core network element. Modem subsystem 512 may be configured to modulate and / or encode data according to MCS (e.g., LDPC decoding scheme, turbo decoding scheme, convolutional decoding scheme, digital beamforming scheme, etc.). RF unit 514 may be configured to process (e.g., perform analog-to-digital conversion or digital-to-analog conversion, etc.) modulated / encoded data (e.g., SSB, RMSI, MIB, SIB, PRACH configuration PDCCH, PDSCH, MSG2, UL permission, RRC configuration, BFD configuration, BFR configuration, RLM configuration, RLF configuration) transmitted from modem subsystem 512 (in outgoing transmissions) or originating from another source (e.g., UE 115, UE 315, or / or UE 400). RF unit 514 can be further configured to perform analog beamforming in conjunction with digital beamforming. Although shown as being integrated together in transceiver 510, modem subsystem 512 and / or RF unit 514 can be separate devices coupled together at BS 105 to enable BS 105 to communicate with other devices.

[0127] RF unit 514 may provide modulated and / or processed data (e.g., data packets (or more generally, data messages containing one or more data packets and other information)) to antenna 516 for transmission to one or more other devices. This may include, for example, information transmission for completing attachment to a network and communication with the resident UE 115 or 400 according to some aspects of this disclosure. Antenna 516 may further receive data messages transmitted from other devices and provide the received data messages for processing and / or demodulation at transceiver 510. Transceiver 510 may provide demodulated and decoded data (e.g., PUCCH control information, PRACH signals, PUSCH data, SR indication, BFR request, MSG1, BFR MAC-CE) to communication module 508 for processing. Antenna 516 may include multiple antennas of similar or different designs to maintain multiple transmission links.

[0128] In one aspect, the BS 500 may include multiple transceivers 510 implementing different RATs (e.g., NR and LTE). In another aspect, the BS 500 may include a single transceiver 510 implementing multiple RATs (e.g., NR and LTE). In yet another aspect, the transceiver 510 may include various components, wherein different combinations of the components can implement different RATs.

[0129] Figure 6 This is a flowchart illustrating a communication method 600 according to some aspects of this disclosure. The aspects of method 600 can be performed by a computing device of a wireless communication device (e.g., a processor, processing circuitry, and / or other suitable components) or other suitable means for performing the steps. For example, a wireless communication device (such as UE 115 or UE 400) can utilize one or more components (such as processor 402, memory 404, communication module 408, BFD / BFR module 409, transceiver 410, and / or one or more antennas 416) to perform aspects of method 600. Furthermore, method 600 can employ... Figure 2A-3C Mechanisms similar to those described in [the text] and Figure 6-8 The methods 600 include aspects of 9A-9D and 10-12. In some instances, aspects of method 600 may be performed between UE 115 and BS 105 in a serving cell, which may include multiple beamgroups. As explained, method 600 includes several enumeration steps, but method 600 may include additional aspects before, after, and between the enumeration steps. In some aspects, one or more of the enumerated steps may be omitted or performed in a different order.

[0130] In box 602, the UE receives from the BS a message or communication including beam fault configuration for the serving cell. In some instances, the UE determines the beam fault configuration for the serving cell based on or according to this message or communication. The serving cell may be a primary cell (PCell) and / or a secondary cell (SCell). In some instances, the UE determines the beam fault configuration for the serving cell based on an RRC message or other communication from the base station. In this regard, the RRC message or other communication from the BS may provide an indication of the available beam fault detection and / or recovery types (e.g., varying by beamgroup or TRP, cell-level, BFR, RLF, etc.) available for the UE to use in the serving cell (in some instances, including explicit or implicit indication of associated parameters (e.g., resources, reference signals, etc.)).

[0131] Beam fault configuration may include at least one of the following: beam fault parameters of a beamgroup (e.g., TRP, beam direction, component carrier, etc.) or beam fault parameters of a cell (e.g., serving cell, primary cell, secondary cell). In some instances, beamgroup-specific BFD and / or beamgroup-specific BFR may be configured simultaneously on the same serving cell having both cellular BFD and / or cellular BFR. Accordingly, in some instances, the BFD in the serving cell may be configured to have both beamgroup-specific BFD and cellular BFD. Similarly, in some instances, the BFR in the serving cell may be configured to have both beamgroup-specific BFR and cellular BFR. In some instances, the BFD in the serving cell may be configured to have only beamgroup-specific BFD or only cellular BFD, while the BFR in the serving cell may be configured to have both beamgroup-specific BFR and cellular BFR. In some instances, the BFD in the serving cell can be configured to have both beamgroup-specific BFD and cellular BFD, while the BFR in the serving cell can be configured to have only beamgroup-specific BFR or only cellular BFR. When both beamgroup-specific and cellular configurations are available in the serving cell for BFD and / or BFR, the UE can determine whether to use the beamgroup-specific configuration, the cellular configuration, or both when performing BFD and / or BFR. In this regard, the beam failure configuration can be determined considering various configuration options and / or associated rules, as discussed further below.

[0132] In block 604, the UE performs beam fault detection at least in part based on the beam fault configuration determined at 602. In some instances, the UE detects a beam fault in block 604. A beam fault may be associated with one or more beams in a beam group of the serving cell. In some instances, the beam group is associated with one or more TRPs of the serving cell. In response to the detection of a beam fault at 604, the UE may initiate recovery (e.g., BFR and / or RLF recovery). In some cases, recovery is performed at least in part based on the beam fault configuration determined at 602.

[0133] In some aspects, at 602, the UE determines that the beam fault configuration for the serving cell includes beam fault parameters for the beam group, but not beam fault parameters for the cell itself. Accordingly, the UE can perform beam fault detection at 604 based on the beam fault parameters of the beam group. In this respect, the UE can detect beam faults based on the beam fault parameters of the beam group. In some instances, the beam fault parameters of the beam group include one or more BFD parameters associated with the beam group (e.g., information about the BDF RS). In this respect, the beam group can be associated with the TRP of the serving cell. For example, the beam fault parameters of the beam group can include at least one of beam fault detection (BFD) parameters that vary depending on the transmit / receive point (TRP) or beam fault recovery (BFR) parameters that vary depending on the TRP. In some instances, the UE determines at block 602 that the beam fault configuration for serving the cell includes multiple beam fault parameters that vary from TRP to TRP and are associated with multiple transmit receive points (TRPs), and the UE performs beam fault detection at 604 by performing beam fault detection independently for each of the multiple TRPs.

[0134] In some aspects, at 602, the UE determines that the beam fault configuration for the serving cell includes beam fault parameters for the cell (e.g., serving cell, primary cell, secondary cell), but excludes beam fault parameters for the beam group. In this regard, the UE may determine at 602 that the beam fault parameters for the cell include at least one of cell-level beam fault detection (BFD) parameters or cell-level beam fault recovery (BFR) parameters. Accordingly, the UE may perform beam fault detection based on the cell's beam fault parameters at 604. In this regard, the UE may detect beam faults based on the cell's beam fault parameters.

[0135] In some aspects, at 602, the UE determines that the beam fault configuration for serving the cell includes beam fault detection parameters varying by beam group and cell-level beam fault detection parameters. In some instances, the UE determines that the beam fault parameters for the beam group include beam fault detection (BFD) parameters varying by beam group and that the beam fault parameters for the cell include cell-level BFD parameters. In some aspects, at 604, the UE performs beam fault detection by performing a first beam fault detection (BFD) based on the beam group-varying beam fault detection parameters and a second BFD based on the cell-level beam fault detection parameters. In some cases, the UE performs the first BFD based on the beam group-varying beam fault detection parameters by monitoring at least one BFD reference signal (RS) varying by transmit-receive-point (TRP). Similarly, in some cases, the UE performs the second BFD based on the cell-level beam fault detection parameters by monitoring at least one cell-level BFD RS. In some instances, the at least one TRP-dependent BFD reference signal (RS) is independent of the at least one cell-level BFD RS. In some instances, the at least one TRP-dependent BFD reference signal (RS) is based on the at least one cell-level BFD RS. For example, in some instances, each TRP-dependent BFD RS is within the set of available cell-level BFD RSs. That is, the TRP-dependent BFD RS for a cell can be a subset of the cell-level BFD RSs serving the cell or include all cell-level BFD RSs serving the cell.

[0136] In some aspects, at 602, the UE further determines that the beam fault configuration for serving the cell includes beam group-specific beam fault recovery (BFR) parameters, but not cell-level beam fault recovery (BFR) parameters. Accordingly, in some instances, the UE determines that the beam fault configuration includes beam group-specific beam fault detection (BFD) parameters, cell-level BFD parameters, and beam group-specific BFR parameters, but not cell-level BFR parameters. In some cases, in response to a beam fault detected at 604, the UE performs BFR based on the beam group-specific BFR parameters.

[0137] In some aspects, at 602, the UE further determines that the beam fault configuration for serving the cell includes cell-level beam fault recovery (BFR) parameters, but excludes beam group-specific BFR parameters. Correspondingly, in some instances, the UE determines that the beam fault configuration includes beam group-specific beam fault detection (BFD) parameters, cell-level BFD parameters, and cell-level BFR parameters, but excludes beam group-specific BFR parameters. In some cases, in response to a beam fault detected at 604, the UE performs BFR based on the cell-level BFR parameters.

[0138] In some aspects, the UE determines beam fault parameters for the beam group at 602, including beam fault detection (BFD) parameters that vary by transmit-receive point (TRP) and beam fault recovery (BFR) parameters that vary by TRP. Accordingly, in some instances, the UE determines the beam fault configuration to include at least one of TRP-specific BFD parameters, TRP-specific BFR parameters, and cell-level BFD parameters and / or cell-level BFR parameters. The UE may perform beam fault detection at 604 based on the TRP-specific BFD parameters. In some instances, the TRP-specific BFD parameters include one or more BFD parameters associated with the TRP (e.g., information about the TRP-specific BFD RS). Furthermore, in response to a BFD indicating a beam fault at 604 based on the TRP-specific BFD parameters, the UE may perform BFR procedures based on the TRP-specific BFR parameters.

[0139] In some respects, at 602, the UE determines that beam fault detection parameters varying by beamgroup include beam fault detection (BFD) parameters varying by transmit-receive point (TRP), and that cell-level beam fault detection parameters include cell-level beam fault recovery (BFR) parameters. Accordingly, in some cases, at 604, the UE performs beam fault detection based on the TRP-varying BFD parameters, and in response to the BFD indicating a beam fault, performs BFR based on the cell-level BFR parameters.

[0140] In some aspects, the UE determines at 602 that beam fault detection parameters varying by beamgroup include beam fault detection (BFD) parameters varying by transmit-receive point (TRP) and beam fault recovery (BFR) parameters varying by TRP, and that cell-level beam fault detection parameters include cell-level BFD parameters and cell-level BFR parameters. Accordingly, in some cases, the UE performs beam fault detection at 604 by performing a first BFD based on the TRP-varying BFD parameters and a second BFD based on the cell-level BFD parameters. In some instances, in response to a first BFD indicating a beam fault (based on the TRP-varying BFD parameters), the UE performs a first BFR based on the TRP-varying BFR parameters. In some instances, in response to a second BFD indicating a beam fault (based on the cell-level BFD parameters), the UE performs a second BFR based on the cell-level BFR parameters.

[0141] In some aspects, at 602, the UE determines that the beam fault configuration for serving the cell includes multiple TRP-specific beam fault parameters associated with multiple Transport Receive Points (TRPs). In some instances, the UE performs beam fault detection at 604 by performing beam fault detection (BFD) for each of the multiple TRPs. In some cases, the UE performs beam fault recovery (BFR) based on the number of BFDs indicating a beam fault. For example, in some instances, the UE may perform a TRP-specific BFR if the number of BFDs indicating a beam fault is less than (or equal to) a threshold (or otherwise reaches that threshold). In some instances, if one or more BFDs indicate a beam fault, but at least X other TRPs are active (e.g., no beam fault is detected or there is an ongoing BFR), the UE may initiate a TRP-specific BFR for the one or more BFDs that indicate a beam fault. If the number of beam fault indicators (BFDs) is greater than (or equal to) a threshold Y (or otherwise reaches the threshold), the UE may perform a cell-level beam fault response (BFR). In some instances, the UE immediately triggers the execution of a cell-level BFR in response to the number of beam faults being greater than (or equal to) the threshold (or otherwise reaching the threshold). In some cases, the threshold Y is the total number of TRPs in the serving cell. In some cases, the threshold Y is less than the total number of TRPs in the serving cell, or a percentage of the TRPs in the serving cell. In some instances, the UE's execution of a BFR includes: disabling cell-level BFR when the threshold number of active TRPs is exceeded. That is, if the beam fault detection at 604 indicates that a threshold number Z of TRPs (e.g., one or more) associated with the serving cell (or component carriers or other beamgroups of the serving cell) are active (e.g., no beam fault is detected or there is an ongoing BFR, or it starts working in the case of a successful BFR depending on the TRP), the UE will suppress the initiation of a cell-level BFR. In some instances, method 600 includes receiving from a base station of the serving cell an indication of at least one threshold for determining whether to perform a TRP-varying BFR or a cell-level BFR. These thresholds may be associated with determining when to perform (or suppress) a TRP-varying BFR and / or a cell-level BFR. In some instances, the indication of these thresholds (e.g., X, Y, and Z, or otherwise) is included in an RRC message or other communication from the base station. In this regard, the thresholds may be included in an RRC message (or other communication) from the BS that provides an indication of the available beam fault detection and / or recovery types (e.g., beamgroup or TRP-varying, cell-level, BFR, RLF, etc.) available for use by the UE in the serving cell.In some instances, thresholds may be defined by standard specifications or otherwise predefined.

[0142] In some aspects, the UE performs a cell-level beam fault recovery (BFR) in response to detecting a beam fault at 604 and terminates any active TRP-dependent BFRs. In this regard, the UE can terminate any active TRP-dependent and / or beamgroup-dependent BFRs at the time of initiation of a cell-level BFR. Furthermore, in some instances, the UE can suppress the initiation of any TRP-dependent and / or beamgroup-dependent BFRs when performing a cell-level BFR.

[0143] In some aspects, at 602, the UE determines that beam group-specific beam fault detection parameters include multiple TRP-specific beam fault parameters associated with multiple transmit-receive points (TRPs), and that cell-level beam fault detection parameters include radio link fault (RLF) parameters. Accordingly, in some cases, at 604, the UE performs beam fault detection for each of the multiple TRPs based on TRP-specific BFD parameters. Furthermore, in some instances, the UE performs recovery based on the number of BFDs indicating beam faults. For example, in some instances, if the number of BFDs indicating beam faults is less than (or equal to) a threshold (or otherwise reaches that threshold), the UE may perform a TRP-specific BFR. In some instances, if one or more BFDs indicate beam faults, but at least X other TRPs are active (e.g., no beam faults are detected or there is an ongoing BFR), the UE may initiate a TRP-specific BFR for the one or more BFDs that indicate beam faults. If the number of beam faults indicating a beam failure is greater than (or equal to) a threshold Y (or otherwise reaches that threshold), the UE may perform an RLF recovery. In some instances, the UE immediately triggers the execution of an RLF recovery in response to the number of beam faults being greater than (or equal to) the threshold (or otherwise meeting that threshold). In some cases, the threshold Y is the total number of TRPs in the serving cell. In some cases, the threshold Y is less than the total number of TRPs in the serving cell, or a percentage of the TRPs in the serving cell. In some instances, the UE's execution of recovery includes allowing an RLF recovery when the threshold number of active TRPs is exceeded. That is, if the beam fault detection at 604 indicates that a threshold number Z of TRPs (e.g., one or more) associated with the serving cell (or its component carriers or other beamgroups) are active (e.g., no beam fault is detected or there is an ongoing BFR, or a BFR that started successfully due to the TRP), the UE will suppress the initiation of an RLF recovery. In some instances, method 600 includes receiving from a base station of the serving cell an indication of at least one threshold for determining whether to perform a TRP-dependent BFR or RLF recovery. These thresholds may be associated with determining when to perform (or suppress) a TRP-dependent BFR and / or RLF recovery. In some instances, the indication of these thresholds (e.g., X, Y, and Z, or otherwise) is included in an RRC message or other communication from the base station. In this regard, the thresholds may be included in an RRC message (or other communication) from the BS that provides an indication of the available beam fault detection and / or recovery type (e.g., beamgroup or TRP-dependent, cell-level, BFR, RLF, etc.) available for use by the UE in the serving cell.In some instances, thresholds may be defined by standard specifications or otherwise predefined.

[0144] In some instances, the UE performs an RLF recovery in response to a detected beam fault at 604 and terminates any active TRP-dependent BFRs in the serving cell (e.g., SpCell). In this regard, the UE may terminate any active TRP-dependent and / or beamgroup-dependent BFRs at the time the RLF recovery is initiated. Furthermore, in some instances, the UE may suppress the initiation of any TRP-dependent and / or beamgroup-dependent BFRs at the time the RLF recovery is performed.

[0145] In some aspects, the UE performs beam fault detection (BFD) at 604 by performing beam fault detection based on beamgroup-specific parameters and radio link monitoring (RLM) based on cell-level beam fault detection parameters. In some instances, the UE performs BFD based on beamgroup-specific parameters by monitoring at least one BFD reference signal (RS) that varies from transmit-receive-point (TRP). In some instances, the UE performs RLM based on cell-level parameters by monitoring at least one RLM RS. In some instances, the at least one TRP-specific BFD reference signal (RS) is independent of the at least one RLM RS. In some cases, the at least one TRP-specific BFD RS is based on the at least one RLM RS. For example, in some instances, each TRP-specific BFD RS is within the set of available RLM RSs. That is, the TRP-specific BFD RS for a cell can be a subset of the RLM RSs serving the cell or include all RLM RSs serving the cell.

[0146] In some aspects, method 600 includes the UE triggering a radio link failure (RLM) recovery. In some instances, after triggering RLM recovery, the UE executes multiple beamfailure procedures that vary depending on the transmit / receive point (TRP). In some cases, the UE may adjust a timer (e.g., a T310 timer) associated with the RLM procedure based on the number of consecutive beamfailure-indicating BFDs that vary depending on the TRP. Adjusting the timer may include increasing or decreasing the timer by at least one of the following: a predetermined amount of time, or a percentage of the timer's duration. For example, in some instances, if the number of consecutive beamfailure-indicating BFDs that vary depending on the TRP exceeds a threshold, the UE may adjust the timer (e.g., decrease or increase the timer by x ms or a percentage of the total timer duration (e.g., 10%, 20%, 25%, 50%, or otherwise)). In some instances, the UE determines whether to adjust the timer based on the number of consecutive beamfailure-indicating BFDs that vary depending on the TRP at a single TRP. That is, the UE determines whether to adjust the timer based on the number of consecutive times a beam fault indication occurs at the same TRP (Terrestrial Point Restriction), which varies depending on the TRP. In some instances, the UE determines whether to adjust the timer based on the number of consecutive TRP-specific BFDs indicating beam faults at multiple TRPs. Specifically, the UE determines whether to adjust the timer based on the number of consecutive times a beam fault is indicated by a TRP (or any TRP in a group of TRPs). In some instances, the UE determines the amount of timer adjustment based on the number of TRPs indicating beam faults. For example, in some cases, the timer reduction is based on the number of TRPs where beam faults occur (e.g., 1 TRP = x ms or y%; 2 TRPs = 2x ms or 2y%; 3 TRPs = 3x ms or 3y%; 4 TRPs = 4x ms or 4y%). Accordingly, in some instances, the UE adjusts the timer based on the number of TRPs associated with TRP-specific BFDs indicating beam faults.

[0147] Figure 7 The explanation of recovery 700 includes beam fault detection in step 702 and recovery in step 704. For example... Figure 7As indicated, the detection of beam faults in step 702 may include beam fault detection (BFD) or radio link monitoring (RLM). The recovery in step 704 includes beam fault recovery (BFR) or radio link failure (RLF) recovery. The detection of beam faults in step 702 may include the execution of beam fault detection (BFD) at the beamgroup (e.g., TRP) or cellular level, or radio link monitoring (RLM) at the cellular level. Specifically, the BFD procedure includes monitoring a BFD reference signal (RS), which may be a beamgroup BFD RS or a cellular BFD RS. In step 704, an appropriate recovery procedure (e.g., at the beamgroup BFR, cellular BFR, or cellular RLF) is executed. In step 702, the recovery may be performed according to... Figure 6 The beam fault configuration described herein is used to perform beam group BFR individually for each beam group (e.g., TRP) in a cell.

[0148] Figure 8 An example of beam fault configuration determination according to some embodiments is described. As explained, beam fault configuration 818 is determined based on beam fault parameter set 802, which includes beam fault parameters 804 for beamgroups and beam fault parameters 806 for cells. As explained, beam fault parameters 804 for beamgroups include beamgroup BFD 808 and beamgroup BFR 810. Similarly, in this example, beam fault parameters 806 for cells include cell BFD 812 and cell BFR 814. Beam fault parameter set 820 is processed according to configuration procedure box 816, which controls beam fault configuration to perform beam fault configuration 818 according to configuration options and configuration rules discussed below.

[0149] Figure 8 The term is interpreted as the beam fault configuration from the beam fault parameter set 802 on the same cell determined in step 816 falling within one of four options, depending on whether beam group BFD 808 and cell BFD can be configured simultaneously on the same serving cell, and whether beam group BFD 812 and cell group 814 can be configured simultaneously. Figures 9A to 9D These options are explained graphically.

[0150] exist Figure 9AIn the first option 902 described herein, beamgroup BFD 808 and cell BFD 812 cannot be configured simultaneously, nor can beamgroup BFR 810 and cell BFR 814 be configured simultaneously. In the first option, beamgroup BFD 808 and beamgroup BFR 810 can be configured, or cell BFD and cell BFR can be configured. Furthermore, the configuration cannot include simultaneous configuration of beamgroup BFD 808 / beamgroup BFR 810 and cell BFD 812 / cell BFR 814.

[0151] exist Figure 9B In the second option 904 explained, beamgroup BFD 808 and cell BFD 812 can be configured simultaneously, while beamgroup BFR 810 and cell BFR 814 cannot be configured simultaneously. However, this option is less likely to occur than the others if both beamgroup 808 and cell BFD 812 will trigger the configured BFR (beamgroup BFR 810 or cell BFR 814).

[0152] exist Figure 9C In the third option 906 explained, beamgroup BFD 808 cannot be configured simultaneously with cell BFD 812, while beamgroup BFR 810 can be configured simultaneously with cell BFR 814. In this option, for example, the serving cell may be configured with only beamgroup BFD 808, which will then trigger either beamgroup BFR 810 or cell BFR 814.

[0153] exist Figure 9D In the fourth option 908 described herein, beamgroup BFD 808 can be configured simultaneously with cell BFD 812, while beamgroup BFR 810 can be configured simultaneously with cell BFR 814. In this option, for example, beamgroup BFD 808 can trigger beamgroup BFR 814, and cell BFD 812 can trigger cell BFR 814.

[0154] Figure 8 The configuration 816 explained in the text is based on Figures 9A to 9D One of the options described herein is used to configure the beam fault configuration. In step 818, a set of rules applicable to various configuration options is applied to the beam fault configuration. The results of steps 816 and 818 result in the beam fault configuration described in step 820. These considerations leading to the beam fault configuration control how beam fault detection is performed in step 604, and subsequently, recovery and operation. Therefore, instructions are executed in step 604 of the beam fault configuration, as discussed below, to influence these rules.

[0155] Figure 10An example of step 818 is explained, where the beam fault configuration reflects rules that may depend on the configuration options derived from step 816. For example... Figure 10 As explained, step 1002 involves determining the triggering rule for either the beam group BFR or the cell BFR based on a threshold number of detected beam faults. The rule reflected in step 1002 applies to third options 906 and fourth options 908, where beam group BFR 810 and cell BFR 814 can be configured simultaneously. In step 1002, the beam fault configuration can be arranged such that beam group BFD 808 can disable or trigger cell-based BFR 814 based on thresholds for the number of detected beams and the number of active beams. Therefore, in step 1002, the triggering of beam group BFR 814 or cell BFD 812 depends on the number of detected beam group faults and the number of active beam groups. Specifically, if a beam group fails based on beam group BFD 808 and at least a first number of other beam groups are active (i.e., no ongoing BFR), then the beam group BFR will be triggered for that failed beam group. However, if at least a second number of beamgroups have failed as detected by beamgroup BFD 808, the beamgroup configuration is arranged to allow triggering of cell BFR 814 in response to beamgroup BFD 808 (based on the triggering condition in step 604) or immediate triggering of cell BFR 814 in response to beamgroup BFD 808. Additionally, if at least a third number of beamgroups are active or have started working via successful beam recovery, triggering of cell BFR is not permitted, and any ongoing cell BFR should be stopped.

[0156] In the first rule implementation reflected in step 1002, the number of thresholds (first number, second number, third number) can be fixed in the specification or can be notified by the base station via signaling. In a particular example, the first number can be 1, the second number can be the number of beamgroups in the cell, and the third number can be 1. However, the specific combination of parameters can vary from application to application.

[0157] In step 1004, a configuration conforming to the second rule is implemented. The second rule applies to the third and fourth options (options 906 and 908), where both beamgroup BFR 810 and cell BFR 814 can be configured simultaneously. In step 1004, under this rule, the beam fault configuration can be arranged such that triggering cell BFR 814 can prevent triggering beamgroup BFR 810. Furthermore, if cell BFR 814 is in progress, any ongoing beamgroup BFR 810 can be terminated, and no new beamgroup BFR 810 will be triggered.

[0158] In step 1006, a third rule is incorporated, which applies when both beamgroup BFD 808 and cell BFD 812 are configurable (e.g., option 4 908). According to rule 3 in step 1006, the beam fault configuration can be arranged such that the BFD reference signals (RS) for both beamgroup BFD 808 and cell BFD 812 can be configured independently or dependently. As discussed above, the indicated BFD RS is monitored during BFD. In some beam fault configurations, the BFD RS for beamgroup BFD 808 can be configured independently of the BFD RS for cell BFD 814. Alternatively, in some beam fault configurations, the BFD RSs for group beam BFD 808 can be the same set of BFD RSs for cell BFR 814, a subset of the set of BFD RSs for cell BFR 814, or include all BFD RSs in the set of BFD RSs for cell BFR 814. For example, if the BFD RSs that differ by beam group include RS1 and RS2 for beam group 1 and beam group 2, then both RS1 and RS2 are also configured as cell BFD RSs.

[0159] As discussed above, the embodiments of this disclosure are also applicable to configurations between beamgroup BFD / BFR and cell RLM / RLF. Options similar to those indicated above can be applied during configurations where cell RLM replaces cell BFD 812 and cell RLF replaces cell BFR 814 in this discussion. However, the following additional rules may apply to cell (e.g., SpCell) RLF. Figure 11 An embodiment of step 818 is explained, in which the beam fault configuration reflects the appropriate RLF rules.

[0160] exist Figure 11In step 1102, a first RLF rule is configured. The first rule applies when beamgroup BFR 810 and cell RLF can be configured simultaneously (as with options 3 and 4 above). In step 1102, the beam fault configuration can be arranged such that beamgroup BFD 808 can disable or trigger cell RLF based on a threshold number of detected beam faults detected by beamgroup BFD 808. Specifically, if a beamgroup is detected as faulty by its beamgroup BFD 808 and at least a first number of other beamgroups are active (e.g., no ongoing beam recovery), beamgroup BFR 810 will be triggered for that faulty beamgroup. If at least a second number of beamgroups have failed, the beam fault configuration declares that either cell RLF is allowed to be triggered based on existing triggering conditions, or cell RLF is triggered immediately in response to beamgroup BFD 808. Cellular RLF is not permitted to be triggered if at least a third number of beamgroups are active or have started active via successful beam recovery, and ongoing cell RLF should be stopped (e.g., the RLF timer should not be started, and should be stopped if it has already been started for ongoing cell RLF). The thresholds (first number, second number, and third number) can be received from the base station.

[0161] In step 1104, the second RLF rule is implemented. In the second rule, the beam fault configuration can be arranged such that operation of the cell RLF disables operation of the beamgroup BFR. If, for example, a cell RRF has been triggered on a SpCell and the corresponding connection re-establishment procedure is in progress, the beamgroup BFR should be terminated, and no further beamgroup BFR should be triggered.

[0162] In step 1106, the third RLF rule is implemented. In the third rule, the beam fault configuration can be arranged such that the configuration of the beamgroup BFD RS and the cell RLM RS can be dependent. Therefore, all beam-dependent BFD RSs can be the same as the cell RLM RSs, be a subset of the cell RLM RSs, or include all cell RLM RSs. Thus, if the beamgroup BFD RSs include RS1 and RS2 for beamgroup 1 and beamgroup 2 respectively, then both RS1 and RS2 can be used as cell RLM RSs.

[0163] In step 1108, the fourth RLF rule is implemented. In the fourth rule, the beam fault configuration can be arranged such that, in the event that a cell RLF has already been triggered (i.e., the RLF timer has been started), upon detection of a beamgroup fault determined by the beamgroup BFD808, the RLF timer can be adjusted (decreased or accelerated) for a predetermined amount of time or a fraction of the total expiration time of the RLF timer.

[0164] In a first embodiment of the fourth RLF rule in step 1108, the RLF timer can be adjusted in response to the number of consecutive beamgroup BFD indicators from beamgroup BFD 808 of the same beamgroup. In another example, the RLF timer can be adjusted when several consecutive beamgroup BFD indicators across all beamgroups indicated by beamgroup BFD 808 are received. For example, the several beamgroup BFD indicators can be obtained by receiving a certain number of consecutive BFD indicators from a first TRP and another number of consecutive BFD indicators from a second TRP.

[0165] In a second embodiment of the fourth RLF rule in step 1108, the RLF timer can be adjusted by a certain amount according to each beamgroup BFD indicator determined by beamgroup BFD 808.

[0166] Figure 12 Operation 1200 of a base station (BS) according to some embodiments of this disclosure is described. In step 1202, the BS configures the UE to have parameters as discussed above suitable for determining a beam fault configuration. For example, a specific threshold as discussed above may be downloaded to the UE during one or more DCI communications with the UE. In step 1204, the BS 1204 performs a recovery function in response to a BFR or RLF from the UE derived from the beam fault configuration discussed herein.

[0167] Description of various aspects of this disclosure

[0168] Aspect 1: A wireless communication method performed by a user equipment (UE), the method comprising: receiving from a base station (BS) communication indicating a beam fault configuration for a serving cell, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell; and detecting a beam fault in the serving cell based at least in part on the beam fault configuration.

[0169] Aspect 2: The method of Aspect 1, wherein: the beam fault configuration for the serving cell includes beam fault parameters of the beam group but not beam fault parameters of the cell; and detecting the beam fault includes detecting the beam fault based on the beam fault parameters of the beam group.

[0170] Aspect 3: The method of aspect 1 or 2, wherein the beam fault parameters of the beam group include at least one of beam fault detection (BFD) parameters that vary depending on the transmit-receive point (TRP) or beam fault recovery (BFR) parameters that vary depending on the TRP.

[0171] Aspect 4: The method of any of Aspects 1-3, wherein: the beam fault configuration for the serving cell includes a plurality of beam fault parameters that vary from TRP to TRP and are associated with a plurality of transmit receive points (TRPs); and detecting the beam fault includes independently monitoring the beam for each of the plurality of TRPs.

[0172] Aspect 5: The method of Aspect 1, wherein the beam fault configuration for the serving cell includes the beam fault parameters of the cell, but does not include the beam fault parameters of the beam group.

[0173] Aspect 6: The method of aspect 5, wherein the beam fault parameters of the cell include at least one of cell-level beam fault detection (BFD) parameters or cell-level beam fault recovery (BFR) parameters.

[0174] Aspect 7: The method of Aspect 1, wherein: the beam fault configuration for the serving cell includes beam fault parameters of the beam group and beam fault parameters of the cell, wherein the beam fault parameters of the beam group include beam fault detection (BFD) parameters that vary from beam group to beam group and the beam fault parameters of the cell include cell-level BFD parameters.

[0175] Aspect 8: The method of aspect 7, wherein detecting the beam fault includes: performing a first beam fault detection (BFD) based on beam fault detection parameters that vary depending on the beam group; and performing a second BFD based on the cell-level BFD parameters.

[0176] Aspect 9: The method of aspect 7 or 8, wherein: the beam fault configuration for the serving cell includes beam group-specific beam fault recovery (BFR) parameters, but does not include cell-level beam fault recovery (BFR) parameters, the method further comprising: performing BFR based on the beam group-specific BFR parameters in response to detecting the beam fault.

[0177] Aspect 10: The method of aspect 7 or 8, wherein: the beam fault configuration for the serving cell includes cell-level beam fault recovery (BFR) parameters, but does not include beam fault recovery (BFR) parameters that vary by beam group, the method further comprising: performing BFR based on the cell-level BFR parameters in response to detecting the beam fault.

[0178] Aspect 11: The method of any of Aspects 8-10, wherein: performing the first BFD based on the beam fault detection parameters that vary due to the beam group includes monitoring at least one BFD reference signal (RS) that varies due to the transmit-receive point (TRP); and performing the second BFD based on the cell-level BFD parameters includes monitoring at least one cell-level BFD RS.

[0179] Aspect 12: The method of any of Aspects 8-11, wherein the at least one TRP-dependent BFD reference signal (RS) is independent of the at least one cell-level BFD RS.

[0180] Aspect 13: The method of any of Aspects 8-11, wherein the at least one TRP-dependent BFD reference signal (RS) is based on the at least one cell-level BFD RS.

[0181] Aspect 14: The method of aspect 1 or 7, wherein: the beam fault parameters of the beam group include beam fault detection (BFD) parameters that vary from transmit-receive point (TRP) and beam fault recovery (BFR) parameters that vary from TRP; and detecting the beam fault includes performing BFD based on the TRP-variable BFD parameters, the method further comprising: performing BFR based on the TRP-variable BFR parameters in response to the BFD indicating the beam fault.

[0182] Aspect 15: The method of aspect 1 or 7, wherein: the beam fault detection parameters that vary from beamgroup to beam group include beam fault detection (BFD) parameters that vary from transmit-receive point (TRP); the cell-level beam fault detection parameters include cell-level beam fault recovery (BFR) parameters; and detecting the beam fault includes performing BFD based on the TRP-varying BFD parameters, the method further comprising: performing BFR based on the cell-level BFR parameters in response to the BFD indicating a beam fault.

[0183] Aspect 16: The method of aspect 1 or 7, wherein: the beam fault detection parameters varying due to the beam group include beam fault detection (BFD) parameters varying due to the transmit-receive point (TRP) and beam fault recovery (BFR) parameters varying due to the TRP; the cell-level beam fault detection parameters include cell-level BFD parameters and cell-level BFR parameters; and detecting the beam fault includes: performing a first BFD based on the TRP-specific BFD parameters; and performing a second BFD based on the cell-level BFD parameters.

[0184] Aspect 17: The method of aspect 16 further includes at least one of the following: in response to a first BFD indicating a beam fault, performing a first BFR based on the TRP-varying BFR parameters; or in response to a second BFD indicating a beam fault, performing a second BFR based on the cell-level BFR parameters.

[0185] Aspect 18: A method of any of Aspects 1-17, wherein: the beam fault configuration for the serving cell includes a plurality of beam fault parameters that vary from TRP to TRP and are associated with a plurality of transmit receive points (TRPs); and detecting the beam fault includes: performing beam fault detection (BFD) for each of the plurality of TRPs; and performing beam fault recovery (BFR) based on the number of BFDs indicating the beam fault.

[0186] Aspect 19: The method of aspect 18, wherein performing the BFR includes: performing a BFR that varies depending on the TRP in response to the number being less than a threshold.

[0187] Aspect 20: The method of aspect 18, wherein performing the BFR includes: performing a cell-level BFR in response to the number being greater than a threshold.

[0188] Aspect 21: The method of aspect 20 further includes: immediately triggering the execution of the cell-level BFR in response to the number being greater than the threshold.

[0189] Aspect 22: The method of any of Aspects 18-21, wherein performing the BFR includes: disabling cell-level BFR when the threshold number of working TRPs is exceeded.

[0190] Aspect 23: The method of any of Aspects 18-22 further includes: receiving from the base station of the serving cell an indication of at least one threshold for determining whether to perform a BFR that varies due to the TRP or to perform a cell-level BFR.

[0191] Aspect 24: The method of any of Aspects 1-23, wherein the method further comprises: performing cell-level beam fault recovery (BFR) in response to detecting the beam fault; and terminating any active TRP-dependent BFR.

[0192] Aspect 25: The method of aspect 24 further includes: suppressing the initiation of any BFR that varies due to TRP when performing the cell-level BFR.

[0193] Aspect 26: The method of aspect 1 or 7, wherein: the beam fault detection parameters that vary from beamgroup to beam include multiple beam fault parameters that vary from TRP to beamgroup to beamgroup; and the cell-level beam fault detection parameters include radio link fault (RLF) parameters; detecting the beam fault includes performing beam fault detection (BFD) for each of the multiple TRPs, the method further including performing recovery based on the number of BFDs indicating beam faults.

[0194] Aspect 27: The method of aspect 26, wherein performing the recovery includes: performing a BFR that varies with TRP in response to the number (a) being less than a threshold; or performing an RLF recovery in response to the number (b) being greater than a threshold.

[0195] Aspect 28: The method of aspect 26, wherein performing the recovery includes performing RLF recovery in response to the number being greater than a threshold.

[0196] Aspect 29: The method of aspect 26 or 28, wherein performing the recovery includes: immediately performing the RLF recovery in response to the number being greater than the threshold.

[0197] Aspect 30: The method of any of Aspects 26-29, wherein performing the recovery includes: disabling RLF recovery when the threshold number of working TRPs is exceeded.

[0198] Aspect 31: The method of any of Aspects 26-30 further includes: receiving from the base station of the serving cell an indication of at least one threshold for determining whether to perform a BFR that varies with TRP or to perform an RLF recovery.

[0199] Aspect 32: The method of any of Aspects 26-31, wherein performing the recovery includes: performing RLF recovery; and terminating any active beam fault recovery (BFR) that varies with TRP.

[0200] Aspect 33: The method of any of Aspects 26-32 further includes: suppressing the initiation of any BFR that varies with TRP when performing the RLF recovery.

[0201] Aspect 34: The method of aspect 1 or 7, wherein detecting the beam fault includes: performing beam fault detection (BFD) based on beam fault detection parameters that vary depending on the beam group; and performing radio link monitoring (RLM) based on the cell-level beam fault detection parameters.

[0202] Aspect 35: The method of aspect 34, wherein: performing the BFD based on the beam fault detection parameters that vary due to the beam group includes monitoring at least one BFD reference signal (RS) that varies due to the transmit-receive point (TRP); and performing the RLM based on the cell-level beam fault detection parameters includes monitoring at least one RLM RS.

[0203] Aspect 36: The method of aspect 35, wherein the at least one BFD RS that varies due to TRP is based on the at least one RLM RS.

[0204] Aspect 37: The method of aspect 1 or 7 further includes: triggering radio link failure (RLF) recovery, the method further including: after triggering the RLF recovery, performing a plurality of transmit-receive point (TRP) different BFDs; and adjusting a timer associated with the RLF recovery based on the number of consecutive TRP-different BFDs indicating beam failure exceeding a threshold.

[0205] Aspect 38: The method of aspect 37, wherein adjusting the timer includes increasing or decreasing the timer by at least one of the following: a predetermined amount of time, or a percentage of the duration of the timer.

[0206] Aspect 39: The method of aspects 37 or 38, wherein the consecutive number of BFDs indicating the beam fault, which varies with the TRP, is based on a single TRP.

[0207] Aspect 40: The method of aspect 37 or 38, wherein the consecutive number of BFDs indicating the beam fault, which varies from TRP, is based on multiple TRPs.

[0208] Aspect 41: The method of any of Aspects 37-40, wherein adjusting the timer includes adjusting the timer based on the number of TRPs associated with the BFD, which varies with the TRP, indicating the beam failure.

[0209] Information and signals can be represented using any of a wide variety of different techniques and technologies. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.

[0210] The various illustrative blocks and modules described herein can be implemented or executed using a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors working in conjunction with a DSP core, or any other such configuration).

[0211] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. Other examples and implementations fall within the scope of this disclosure and the appended claims. For example, due to the nature of software, the above-described functions may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Features implementing the functions may also be physically located in various locations, including being distributed such that portions of the functions are implemented at different physical locations. Additionally, as used herein (including in the claims), the use of "or" in an enumeration of items (e.g., an enumeration of items accompanied by phrases such as "at least one of" or "one or more of") indicates an inclusive enumeration, such that an enumeration such as [at least one of A, B, or C] means A or B or C or AB or AC or BC or ABC (i.e., A and B and C).

[0212] As will be appreciated by those skilled in the art by this time, and depending on the specific application at hand, many modifications, substitutions, and variations can be made to the materials, apparatus, configuration, and methods of use of the devices disclosed herein without departing from the spirit and scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the specific embodiments explained and described herein (as they are merely examples), but should be fully equivalent to the appended claims and their functional equivalents.

Claims

1. A wireless communication method performed by a user equipment (UE), the method comprising: Receive communication indicating beam fault configuration, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell, wherein the at least one of the beam fault parameters of the beam group or the beam fault parameters of the cell is associated with a cell-level triggering condition or a triggering condition that varies from beam group to beam fault recovery (BFR) procedure. as well as Beam faults are detected in the serving cell based at least in part on the beam fault configuration.

2. The method of claim 1, wherein: The beam fault configuration includes beam fault parameters for the beam group, but excludes beam fault parameters for the cellular cells; and Detecting the beam fault includes detecting the beam fault based on the beam fault parameters of the beam group.

3. The method of claim 2, wherein the beam fault parameters of the beam group include at least one of beam fault detection (BFD) parameters that vary depending on the transmit / receive point (TRP) or beam fault detection (BFR) parameters that vary depending on the TRP.

4. The method of claim 2, wherein: The beam fault configuration includes multiple beam fault parameters that vary from TRP to TRP and are associated with multiple TRPs; and Detecting the beam fault involves independently monitoring the beam used for each of the plurality of TRPs.

5. The method of claim 1, wherein: The beam fault configuration includes the beam fault parameters of the cell, but not the beam fault parameters of the beam group.

6. The method of claim 5, wherein the beam fault parameters of the cell include at least one of cell-level BFD parameters or cell-level BFR parameters.

7. The method of claim 1, wherein: The beam fault configuration includes beam fault parameters for the beam group and beam fault parameters for the cell; and The beam fault parameters of the beam group include BFD parameters that vary from beam group to beam group, and the beam fault parameters of the cell include cell-level BFD parameters.

8. The method of claim 7, wherein detecting the beam fault comprises: The first BFD is performed based on the beamgroup-dependent BFD parameters; as well as The second BFD is executed based on the cell-level BFD parameters.

9. The method of claim 8, wherein the beam fault configuration includes beamgroup-specific BFR parameters but excludes cell-level BFR parameters, the method further comprising: In response to the execution of the first BFD, the BFR is executed based on the beamgroup-specific BFR parameters.

10. The method of claim 8, wherein the beam fault configuration includes cell-level BFR parameters but excludes beamgroup-specific BFR parameters, the method further comprising: In response to the execution of the second BFD, the BFR is executed based on the cell-level BFR parameters.

11. The method of claim 8, wherein: Performing the first BFD based on the beamgroup-dependent BFD parameters includes monitoring at least one TRP-dependent BFD reference signal RS; and Performing the second BFD based on the cell-level BFD parameters includes monitoring at least one cell-level BFDRS.

12. The method of claim 7, wherein: The beam fault parameters of the beam group include BFD parameters that vary depending on the TRP and BFR parameters that vary depending on the TRP; and Detecting the beam fault includes performing BFD based on the TRP-varying BFD parameters, and the method further includes: In response to the beam fault indicated by the BFD, the BFR is performed based on the BFR parameters that vary depending on the TRP.

13. The method of claim 7, wherein: The beamgroup-dependent BFD parameters include the TRP-dependent BFD parameters. The cell-level BFD parameters include the cell-level BFR parameters; and Detecting the beam fault includes performing BFD based on the TRP-varying BFD parameters, the method further comprising: In response to the BFD indicating beam fault, BFR is performed based on the cell-level BFR parameters.

14. The method of claim 7, wherein: The beamgroup-dependent BFD parameters include TRP-dependent BFD parameters and TRP-dependent BFR parameters. The beam fault parameters of the cell include cell-level BFD parameters and cell-level BFR parameters; and Detecting the beam fault includes: The first BFD is performed based on the BFD parameters that vary depending on the TRP; as well as The second BFD is executed based on the cell-level BFD parameters.

15. The method of claim 14, further comprising at least one of the following: In response to the first BFD indicating the beam fault, the first BFR is executed based on the TRP-varying BFR parameters; or In response to the beam fault indicated by the second BFD, the second BFR is performed based on the cell-level BFR parameters.

16. The method of claim 1, wherein: The beam fault configuration includes multiple beam fault parameters that vary from TRP to TRP and are associated with multiple TRPs. and Detecting the beam fault includes: Perform BFD for each of the plurality of TRPs; as well as BFR is performed based on the number of BFDs indicating the beam fault.

17. The method of claim 16, wherein performing the BFR comprises: BFRs, varying depending on the TRP, are executed in response to the number being less than a first threshold; A cellular-level BFR is performed in response to the number exceeding a second threshold; or When the threshold number of working TRPs is exceeded, the cell-level BFR is disabled.

18. The method of claim 16, further comprising: The receiver receives an indication of at least one threshold for determining whether to perform a BFR that varies depending on the TRP or to perform a cellular-level BFR.

19. The method of claim 1, wherein the method further comprises: In response to the detection of the beam fault, a cellular-level BFR is performed; as well as Terminate any active BFRs that vary depending on the TRP.

20. The method of claim 7, wherein: The beamgroup-specific BFD parameters include multiple TRP-specific beam fault parameters associated with multiple TRPs; and Detecting the beam fault includes performing BFD for each of the plurality of TRPs, the method further comprising: Recovery is performed based on the number of BFDs indicating the beam fault.

21. The method of claim 20, wherein: The cellular-level BFD parameters include Radio Link Fault (RLF) parameters; and Performing the recovery includes: BFRs, varying depending on the TRP, are executed in response to the number being less than a first threshold; In response to the number exceeding the second threshold, RLF recovery is performed based on the RLF parameters; or RLF recovery is disabled when the threshold number of working TRPs is exceeded.

22. The method of claim 20, further comprising: Receive an indication of at least one threshold for determining whether to perform a BFR that varies depending on the TRP or to perform an RLF recovery.

23. The method of claim 20, wherein performing the recovery comprises: Perform RLF recovery; as well as Terminate any active BFRs that vary depending on the TRP.

24. The method of claim 7, wherein detecting the beam fault comprises: BFD is performed based on the beamgroup-dependent BFD parameters. as well as RLM is performed based on the cell-level BFD parameters.

25. The method of claim 24, wherein: Performing the BFD based on the beamgroup-specific BFD parameters includes monitoring at least one BFD reference signal RS, which varies depending on the transmit / receive point (TRP); and Performing the RLM based on the cell-level BFD parameters includes monitoring at least one RLM RS.

26. The method of claim 7, further comprising: Triggering Radio Link Failure (RLF) recovery; After the RLF recovery is triggered, multiple BFDs, which vary depending on the Transmitter / Receiver Point (TRP), are executed. as well as The timer associated with the RLF recovery is adjusted based on the number of consecutive BFDs, which are TRP-dependent and indicate the beam fault, exceeding a threshold.

27. The method of claim 26, wherein: Adjusting the timer includes increasing or decreasing the timer by at least one of the following: a predetermined time amount, or a percentage of the timer's duration; or Adjusting the timer includes adjusting the timer based on the number of TRPs associated with the TRP-varying BFD that indicates the beam fault.

28. A user equipment (UE), comprising: Memory; A processor coupled to the memory; as well as A transceiver, coupled to the processor and configured to: Receive communication indicating a beam fault configuration, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell, wherein the at least one of the beam fault parameters of the beam group or the beam fault parameters of the cell is associated with a cell-level triggering condition or a beam group-specific triggering condition for initiating a beam fault recovery (BFR) procedure, wherein the processor is configured to: Beam faults are detected in the serving cell based at least in part on the beam fault configuration.

29. The UE of claim 28, wherein: The beam fault configuration includes beam fault parameters for the beam group, but excludes beam fault parameters for the cellular cells; and Detecting the beam fault includes detecting the beam fault based on the beam fault parameters of the beam group.

30. The UE of claim 29, wherein the beam fault parameters of the beam group include at least one of beam fault detection (BFD) parameters that vary depending on the transmit / receive point (TRP) or beam fault detection (BFR) parameters that vary depending on the TRP.

31. The UE as claimed in claim 29, wherein: The beam fault configuration includes multiple beam fault parameters that vary from TRP to TRP and are associated with multiple TRPs; and Detecting the beam fault involves independently monitoring the beam used for each of the plurality of TRPs.

32. The UE as claimed in claim 28, wherein: The beam fault configuration includes the beam fault parameters of the cell, but not the beam fault parameters of the beam group.

33. The UE of claim 32, wherein the beam fault parameters of the cell include at least one of cell-level BFD parameters or cell-level BFR parameters.

34. The UE as claimed in claim 28, wherein: The beam fault configuration includes beam fault parameters for the beam group and beam fault parameters for the cell; and The beam fault parameters of the beam group include BFD parameters that vary from beam group to beam group, and the beam fault parameters of the cell include cell-level BFD parameters.

35. The UE of claim 34, wherein detecting the beam fault comprises: The first BFD is performed based on the beamgroup-dependent BFD parameters; as well as The second BFD is executed based on the cell-level BFD parameters.

36. The UE of claim 35, wherein the beam fault configuration includes beamgroup-specific BFR parameters but excludes cell-level BFR parameters, and the transceiver is further configured to: In response to the execution of the first BFD, the BFR is executed based on the beamgroup-specific BFR parameters.

37. The UE of claim 35, wherein the beam fault configuration includes cell-level BFR parameters but excludes beamgroup-specific BFR parameters, and the transceiver is further configured to: In response to the execution of the second BFD, the BFR is executed based on the cell-level BFR parameters.

38. The UE as claimed in claim 35, wherein: Performing the first BFD based on the beamgroup-dependent BFD parameters includes monitoring at least one TRP-dependent BFD reference signal RS; and Performing the second BFD based on the cell-level BFD parameters includes monitoring at least one cell-level BFDRS.

39. The UE as claimed in claim 34, wherein: The beam fault parameters of the beam group include BFD parameters that vary depending on the TRP and BFR parameters that vary depending on the TRP; and Detecting the beam fault includes performing BFD based on the TRP-varying BFD parameters, and the transceiver is further configured to: In response to the beam fault indicated by the BFD, the BFR is performed based on the BFR parameters that vary depending on the TRP.

40. The UE of claim 34, wherein: The beamgroup-dependent BFD parameters include the TRP-dependent BFD parameters. The cell-level BFD parameters include cell-level BFR parameters; and Detecting the beam fault includes performing BFD based on the TRP-varying BFD parameters, and the transceiver is further configured to: In response to the BFD indicating beam fault, BFR is performed based on the cell-level BFR parameters.

41. The UE as claimed in claim 34, wherein: The beamgroup-dependent BFD parameters include TRP-dependent BFD parameters and TRP-dependent BFR parameters. The beam fault parameters of the cell include cell-level BFD parameters and cell-level BFR parameters; and Detecting the beam fault includes: The first BFD is performed based on the BFD parameters that vary depending on the TRP; as well as The second BFD is executed based on the cell-level BFD parameters.

42. The UE of claim 41, wherein the transceiver is further configured to perform at least one of the following: In response to the first BFD indicating the beam fault, the first BFR is executed based on the TRP-varying BFR parameters; or In response to the beam fault indicated by the second BFD, the second BFR is performed based on the cell-level BFR parameters.

43. The UE as claimed in claim 28, wherein: The beam fault configuration includes multiple beam fault parameters that vary from TRP to TRP and are associated with multiple TRPs. and Detecting the beam fault includes: Perform BFD for each of the plurality of TRPs; as well as BFR is performed based on the number of BFDs indicating the beam fault.

44. The UE of claim 43, wherein performing the BFR comprises: BFRs, varying depending on the TRP, are executed in response to the number being less than a first threshold; A cellular-level BFR is performed in response to the number exceeding a second threshold; or When the threshold number of working TRPs is exceeded, the cell-level BFR is disabled.

45. The UE of claim 43, wherein the transceiver is further configured to: The receiver receives an indication of at least one threshold for determining whether to perform a BFR that varies depending on the TRP or to perform a cellular-level BFR.

46. ​​The UE of claim 28, wherein the transceiver is further configured to: In response to the detection of the beam fault, a cellular-level BFR is performed; and Terminate any active BFRs that vary depending on the TRP.

47. The UE of claim 34, wherein: The beamgroup-specific BFD parameters include multiple TRP-specific beam fault parameters associated with multiple TRPs; and Detecting the beam fault includes performing BFD for each of the plurality of TRPs, and the transceiver is further configured to: Recovery is performed based on the number of BFDs indicating the beam fault.

48. The UE of claim 47, wherein: The cellular-level BFD parameters include Radio Link Fault (RLF) parameters; and Performing the recovery includes: BFRs, varying depending on the TRP, are executed in response to the number being less than a first threshold; In response to the number exceeding the second threshold, RLF recovery is performed based on the RLF parameters; or RLF recovery is disabled when the threshold number of working TRPs is exceeded.

49. The UE of claim 47, wherein the transceiver is further configured to: Receive an indication of at least one threshold for determining whether to perform a BFR that varies depending on the TRP or to perform an RLF recovery.

50. The UE of claim 47, wherein performing the recovery comprises: Perform RLF recovery; as well as Terminate any active BFRs that vary depending on the TRP.

51. The UE of claim 34, wherein detecting the beam fault comprises: BFD is performed based on the beamgroup-dependent BFD parameters. as well as RLM is performed based on the cell-level BFD parameters.

52. The UE as claimed in claim 51, wherein: Performing the BFD based on the beamgroup-specific BFD parameters includes monitoring at least one BFD reference signal RS, which varies depending on the transmit / receive point (TRP); and Performing the RLM based on the cell-level BFD parameters includes monitoring at least one RLM RS.

53. The UE of claim 34, wherein the transceiver is further configured to: Triggering Radio Link Failure (RLF) recovery; After triggering the RLF recovery, perform multiple BFDs that vary depending on the transmit / receive point (TRP); and The timer associated with the RLF recovery is adjusted based on the number of consecutive BFDs, which are TRP-dependent and indicate the beam fault, exceeding a threshold.

54. The UE as claimed in claim 53, wherein: Adjusting the timer includes increasing or decreasing the timer by at least one of the following: a predetermined time amount, or a percentage of the timer's duration; or Adjusting the timer includes adjusting the timer based on the number of TRPs associated with the TRP-varying BFD that indicates the beam fault.

55. A non-transient computer-readable medium having program code recorded thereon for operation on a user equipment (UE), the program code comprising: Code for enabling a UE to receive communication indicating a beam fault configuration, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell, wherein the at least one of the beam fault parameters of the beam group or the beam fault parameters of the cell is associated with a cell-level triggering condition or a triggering condition that varies from beam group to beam fault recovery (BFR) procedure. as well as Code for enabling the UE to detect beam faults in the serving cell, at least in part, based on the beam fault configuration.

56. A user equipment (UE), comprising: A means for receiving communication indicating a beam fault configuration, the beam fault configuration including at least one of beam fault parameters of a beam group or beam fault parameters of a cell, wherein the at least one of the beam fault parameters of the beam group or the beam fault parameters of the cell is associated with a cell-level triggering condition or a triggering condition that varies from beam group to beam fault recovery (BFR) procedure. as well as A means for detecting beam faults in a serving cell, at least in part based on the beam fault configuration.

Images