M-trp beam failure indication

Abstract

A method for user equipment detecting a beam failure on at least one transmission / reception point, TRP, the UE configured to communicate with a plurality of TRPs; based on the detection, encoding beam failure indication data to a beam failure recovery, BFR, medium access control, MAC, control element, CE, wherein the beam failure indication data indicates the beam failure on the at least one TRP; and transmitting the BFR MAC CE to a network element of a wireless communication network.

Description

Technical Field

[0001] This invention relates to communications. Background Technology

[0002] Modern wireless networks are capable of utilizing multiple transmit / receive point (M-TRP) schemes. With the increase in such capabilities, there is a need for solutions to enhance the overall effectiveness of these capabilities. For example, providing solutions related to addressing problems caused by beam failures in M-TRP scenarios could be beneficial. Summary of the Invention

[0003] According to one aspect, the subject matter of the independent claims is provided. Several embodiments are defined in the dependent claims.

[0004] According to one aspect, an apparatus is provided, comprising at least one processor and at least one memory, including program code, wherein the at least one memory and the computer program code are configured, together with the at least one processor, to cause the apparatus to perform operations including: detecting a beam fault on at least one transmit / receive point (TRP), the apparatus being configured to communicate with a plurality of TRPs; based on the detection, encoding beam fault indication data into a beam fault recovery (BFR), a medium access control (MAC), and a control unit (CE), wherein the beam fault indication data indicates a beam fault on at least one TRP; and transmitting the BFR, MAC, and CE to network elements of a wireless communication network.

[0005] According to one aspect, an apparatus is provided, comprising at least one processor and at least one memory, including program code, wherein the at least one memory and the computer program code are configured together with the at least one processor to cause the apparatus to perform operations including: configuring a user equipment (UE) of a wireless communication network to monitor beam faults on at least one of a plurality of transmit / receive points (TRPs), the UE being configured to communicate with the plurality of TRPs, wherein the configuration causes the UE to encode beam fault indication data into a beam fault recovery (BFR), a medium access control (MAC), and a control unit (CE) based on the detection of a beam fault, and to transmit the BFR, MAC, and CE to the wireless network, the beam fault indication data indicating a beam fault on at least one TRP.

[0006] Embodiments that are not within the scope of the claims should be interpreted as examples that help to understand this disclosure.

[0007] One or more examples of embodiments are illustrated in more detail in the following drawings and description. Other features will be apparent from the specification, drawings, and claims. Attached Figure Description

[0008] Some embodiments will now be described with reference to the accompanying drawings, wherein...

[0009] Figure 1A The illustration shows an example of a wireless communication system to which the embodiments can be applied;

[0010] Figure 1B The illustration shows an example of a wireless communication system to which the embodiments can be applied;

[0011] Figure 2 and Figure 3 The diagram illustrates flowcharts according to some embodiments;

[0012] Figure 4A and Figure 4B The diagram illustrates the MAC CE data structure;

[0013] Figure 5 The diagram illustrates a signal diagram according to one embodiment;

[0014] Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 6E , Figure 6F and Figure 6H Some embodiments are illustrated; and

[0015] Figure 7 and Figure 8 An apparatus according to some embodiments is illustrated. Detailed Implementation

[0016] The following embodiments are examples. Although the specification may refer to "a," "an," or "some" embodiments (one or more) in several places, this does not necessarily mean that each such reference refers to the same embodiment(s), or that the feature applies only to a single embodiment. Individual features of different embodiments may also be combined to provide other embodiments. Furthermore, the words "comprising" and "including" should be understood not to limit the described embodiments to consisting only of those features already mentioned, and such embodiments may also contain features / structures not specifically mentioned.

[0017] In the following description, radio access architectures based on LTE Advanced (LTE-A) or New Radio (NR, 5G) will be used as examples of access architectures to which these embodiments can be applied to describe different exemplary embodiments; however, the embodiments are not limited to such architectures. Those skilled in the art will recognize that these embodiments can also be applied to other types of communication networks with suitable means by appropriately adapting parameters and processes. Some examples of other options for suitable systems are Universal Mobile Telecommunications System (UMTS) radio access networks (UTRAN or E-UTRAN), LTE (same as E-UTRA), wireless local area networks (WLAN or WiFi), and global interoperability for microwave access (WiMAX). Personal Communication Services (PCS) Wideband Code Division Multiple Access (WCDMA), systems using Ultra Wideband (UWB) technology, sensor networks, Mobile Ad Hoc Networks (MANET), and Internet Protocol Multimedia Subsystem (IMS), or any combination thereof.

[0018] Figure 1A An example of a simplified system architecture is depicted, showing only some components and functional entities, all of which are logical units, and their implementation may differ from that shown. Figure 1A The connections shown are logical connections; the actual physical connections may differ. It will be apparent to those skilled in the art that the system typically includes, in addition to... Figure 1A Other functions and structures besides those shown.

[0019] However, the embodiments are not limited to the system given as an example, but those skilled in the art can apply the solution to other communication systems with the necessary properties.

[0020] Figure 1A The example shows a portion of an exemplary radio access network. Figure 1A Terminal devices or user equipment 100 and 102 are shown, configured to wirelessly connect to an access node (e.g., (e / g)NodeB) 104 providing the cell on one or more communication channels within the cell. (e / g)NodeB refers to an eNodeB or gNodeB as defined in the 3GPP specification. The physical link from the user equipment to the (e / g)NodeB is called an uplink or reverse link, and the physical link from the (e / g)NodeB to the user equipment is called a downlink or forward link. It should be understood that the (e / g)NodeB or their functionality can be implemented using any node, host, server, or access point suitable for this purpose.

[0021] A communication system typically includes more than one (e / g)NodeB, in which case the (e / g)NodeBs may also be configured to communicate with each other via wired or wireless links designed for this purpose. These links can be used not only for signaling purposes but also to route data from one (e / g)NodeB to another. An (e / g)NodeB is a computing device configured to control the radio resources of the communication system to which it is coupled. A NodeB may also be referred to as a base station, access point, access node, or any other type of interface device, including relay stations capable of operating in a wireless environment. An (e / g)NodeB includes or is coupled to a transceiver. From the transceiver of the (e / g)NodeB, a connection is provided to an antenna element that establishes a bidirectional radio link to the user equipment. The antenna element may include multiple antennas or antenna elements. The (e / g)NodeB is further connected to the core network 110 (CN or Next Generation Core NGC). Depending on the system, the corresponding part on the CN side can be a Serving Gateway (S-GW, which routes and forwards user data packets), a Packet Data Network Gateway (P-GW) used to provide user equipment (UE) connectivity to external packet data networks, or a Mobility Management Entity (MME), etc.

[0022] The user equipment (also known as UE, user gear, user terminal, terminal equipment, etc.) illustrates a type of device to which resources on the air interface are allocated and assigned, and thus any features of the user equipment described herein can be implemented using corresponding devices such as relay nodes. An example of such a relay node is a Layer 3 relay (self-backhaul relay) toward a base station.

[0023] User equipment typically refers to portable computing devices that include wireless mobile communication devices operating with or without a Subscriber Identity Module (SIM), including but not limited to the following types of devices: mobile stations (mobile phones), smartphones, personal digital assistants (PDAs), handheld devices, devices using wireless modems (such as alarm or measuring devices), laptops and / or touchscreen computers, tablet computers, game consoles, laptops, and multimedia devices. It should be understood that user equipment can also be a virtually exclusive uplink-only device, an example of which is a camera or camcorder that loads images or video clips onto a network. User equipment can also be a device capable of operating in an Internet of Things (IoT) network, where objects are provided with the ability to transmit data over the network without requiring human-to-human or human-to-computer interaction. User equipment can also utilize the cloud. In some applications, user equipment may include small portable devices with radio components (such as watches, headphones, or glasses), and computation is performed in the cloud. User equipment (or, in some embodiments, a Layer 3 relay node) is configured to perform one or more user equipment functionalities. User equipment can also be referred to as subscriber unit, mobile station, remote terminal, access terminal, user terminal, or user equipment (UE), to name just a few.

[0024] The various techniques described in this paper can also be applied to cyber-physical systems (CPS) (systems that control collaborative computing elements of physical entities). CPS can enable the implementation and development of a large number of interconnected ICT devices (sensors, actuators, processors, and microcontrollers, etc.) embedded in physical objects in different locations. Mobile cyber-physical systems are a subclass of cyber-physical systems in which the physical systems discussed have inherent mobility. Examples of mobile physical systems include mobile robots and electronic devices transported by humans or animals.

[0025] Furthermore, although these devices are depicted as a single entity, different units, processors, and / or memory units can be implemented (in... Figure 1A (Not all of them are shown in the image).

[0026] 5G supports the use of multiple-input multiple-output (MIMO) antennas, far more base stations or nodes than LTE (the so-called small cell concept), including macro sites cooperating with smaller base stations, and employs a variety of radio technologies depending on service requirements, use cases, and / or available spectrum. 5G mobile communications support a wide range of use cases and related applications, including video streaming, augmented reality, data sharing in different ways, and various forms of machine-type applications (such as (massive) machine-type communications (mMTC), including vehicle safety, different sensors, and real-time control). 5G is expected to have multiple radio interfaces: sub-6 GHz, cmWave, and mmWave, and will also be able to integrate with existing legacy radio access technologies (such as LTE). At least in the early stages, integration with LTE can be implemented as a single system where macro coverage is provided by LTE, and 5G radio interface access comes from small cells aggregated to LTE. In other words, 5G plans to simultaneously support inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as sub-6 GHz-cmWave and sub-6 GHz-cmWave-mmWave). One of the concepts being considered for use in 5G networks is network slicing, in which multiple independent and dedicated virtual sub-networks (network instances) can be created within the same infrastructure to run services with different requirements for latency, reliability, throughput, and mobility.

[0027] The current architecture in LTE networks is entirely distributed across radios and typically entirely centralized in the core network. Low-latency applications and services in 5G require content to be closer to the radio, leading to local burst and multi-access edge computing (MEC). 5G enables analytics and knowledge generation to occur at the data source. This approach requires leveraging resources such as laptops, smartphones, tablets, and sensors that may not have continuous network connectivity. MEC provides a distributed computing environment for application and service hosting. It also enables content to be stored and processed closer to cellular users to accelerate response times. Edge computing encompasses a wide range of technologies such as wireless sensor networks, mobile data acquisition, mobile signature analytics, collaborative distributed peer-to-peer self-organizing networks and processing, and can also be categorized as local cloud / fog computing and grid / grid computing, dew computing, mobile edge computing, micro-cloud, distributed data storage and retrieval, autonomous self-healing networks, remote cloud services, augmented and virtual reality, data caching, the Internet of Things (massive connectivity and / or latency critical), and critical communications (autonomous vehicles, traffic safety, real-time analytics, time-critical control, healthcare applications).

[0028] The communication system is also capable of communicating with other networks such as the public switched telephone network or the Internet 112, or utilizing services provided by them. The communication network can also support the use of cloud services; for example, at least a portion of the core network operation can be performed as a cloud service (this is in...). Figure 1A (Described as "Cloud" 114). The communication system may also include a central control entity, which provides facilities for different operators' networks to cooperate, for example, in spectrum sharing.

[0029] By leveraging Network Functions Virtualization (NVF) and Software-Defined Networking (SDN), edge cloud can be introduced into the Radio Access Network (RAN). Using edge cloud can mean that access node operations are at least partially operationally coupled to servers, hosts, or nodes at remote radio heads or base stations, including radio components. Node operations may also be distributed across multiple servers, nodes, or hosts. The application of the cloudRAN architecture enables real-time RAN functions to be executed on the RAN side (in the distributed unit DU104), while non-real-time functions can be executed centrally (in the centralized unit CU 108).

[0030] It should also be understood that the functional distribution between core network operations and base station operations may differ from LTE, or even not exist at all. Other technological advancements that may be used include big data and all-IP, which could change how networks are built and managed. 5G (or New Radio, NR) networks are being designed to support multi-tiered architectures, where MEC servers can be placed between the core and base stations or Node Bs (gNBs). It should be understood that MEC can also be applied to 4G networks.

[0031] 5G can also leverage satellite communications to enhance or supplement the coverage of 5G services, for example, by providing backhaul. Possible use cases include providing service continuity for machine-to-machine (M2M) or Internet of Things (IoT) devices or vehicular passengers, or ensuring the availability of critical communications and future rail, maritime, and / or air communications. Satellite communications can utilize geostationary orbit (GEO) satellite systems, as well as low Earth orbit (LEO) satellite systems, particularly mega-constellations (systems deploying hundreds of (nano) satellites). Each satellite 106 in a mega-constellation can cover several satellite-enabled network entities that create a ground cell. Ground cells can be created via ground relay nodes 104 or gNBs located on the ground or in satellites.

[0032] It will be apparent to those skilled in the art that the depicted system is merely an example of a portion of a radio access system, and in practice, the system may include multiple (e / g) NodeBs, user equipment may access multiple radio cells, and the system may also include other devices such as physical layer relay nodes or other network elements. At least one (e / g) NodeB may be a home (e / g) nodeB. Furthermore, multiple different types of radio cells and multiple radio cells may be available within the geographical area of ​​the radio communication system. Radio cells may be macrocells (or umbrella cells), which are large areas, typically tens of kilometers in diameter, or smaller cells such as microcells, femtocells, or picocells. Figure 1A The (e / g)NodeB can provide any type of these cells. Cellular radio systems can be implemented as multi-layer networks comprising several types of cells. Typically, in a multi-layer network, one access node provides one or more types of cells, thus requiring multiple (e / g)NodeBs to provide this type of network structure.

[0033] To meet the need for improved deployment and performance of communication systems, the concept of "plug-and-play" (e / g) NodeBs has been introduced. Typically, networks capable of using "plug-and-play" (e / g) NodeBs include, in addition to home (e / g) NodeBs (H(e / g) NodeBs), home NodeB gateways or HNB-GWs. Figure 1A (Not shown in the image). HNB gateways (HNB-GWs), typically installed within a carrier network, aggregate traffic from a large number of HNBs back to the core network. The networks discussed in this article may refer to, for example, cellular networks such as 5G.

[0034] The UE may be able to perform beam fault recovery (BFR) using either contention-free random access (CFRA) or contention-based random access (CBRA). In CFRA BFR, a dedicated random access (RA) preamble resource can be provided to the UE, which can be associated with a specific downlink (DL) reference signal (RS) (i.e., a new candidate beam). Therefore, CFRA BFR can indicate to the network that a beam fault has been declared, the UE has initiated recovery, and a new candidate beam has been selected. Alternatively, a secondary cell (SCell) BFR can be used, allowing the UE to transmit a Medium Access Control (MAC) CE in the event of a SCell beam fault. This CE can indicate to the network the index of the faulty SCell and further indication of whether a suitable candidate beam has been detected (e.g., the quality and / or received signal strength of the candidate beam exceeds a threshold level), as well as the index of the candidate beam RS in the candidate beam RS list. The transmission of the MAC CE can precede the transmission of the dedicated SR signal, which indicates the beam fault event on the SCell; however, the MAC CE can also be multiplexed to any UL license.

[0035] It should be noted that when referring to BFR MAC CE, it can refer to BFR MAC CE, truncated BFR MAC CE, or MAC CE used for beam fault recovery. If truncated BFR MAC CE is explicitly referenced, the reference may apply to truncated BFR MAC CE, but not necessarily to BFR MAC CE. Figure 4A Examples of BFRs with a single octet bitmap and truncated BFR MAC CEs are shown, while Figure 4B Examples of BFRs with four octet bitmaps and truncated BFR MAC CEs are shown. These diagrams are used as examples to describe some features and data structures of BFR MAC CEs used in the context of this application. Generally, the following MAC CE can be used to indicate a SpCell fault. Those skilled in the art will understand that SpCell can refer to the primary cell of a primary cell group or the primary / secondary cell of a secondary cell group. It should also be noted that PCell can refer to the SpCell of the primary cell group, and PSCell can refer to the SpCell of the secondary cell group.

[0036] The BFR MAC CE can be identified by a MAC subheader with a Logical Channel ID (LCID) / eLCID. The BFR MAC CE may have a variable size. It may include a bitmap and beam fault recovery information in ascending order based on the ServCellIndex, i.e., an eight-bit byte containing a Candidate Beam Availability Indicator (AC) for the SCells indicated in the bitmap.

[0037] For BFR MAC CE, a single octet bitmap can be used when the highest ServCellIndex of the SCell of the MAC entity that detects a beam fault is less than 8; otherwise, four octets can be used.

[0038] For truncated BFR MAC CE, a single octet bitmap (see...) Figure 4A (Example) can be used in the following cases; otherwise, four octets can be used (see example). Figure 4B Example):

[0039] - The highest ServCellIndex of the SCell of the MAC entity configured with beam fault detection is less than 8; or

[0040] - A beam fault was detected in the SpCell, and the SpCell will be indicated in the truncated BFR MAC CE. As a result of Logical Channel Priority (LCP), the uplink shared channel (UL-SCH) resources available for transmission cannot accommodate the truncated BFR MAC CE with four octet bitmaps and their subheadings.

[0041] refer to Figure 4A and 4B Fields in BFR MAC CE can be defined as follows:

[0042] -SP: This field indicates beam fault detection for the SpCell of this MAC entity. The SP field can be set to 1 to indicate that a beam fault in the SpCell is detected only if a BFR MAC CE or a truncated BFR MAC CE is to be included in the MAC PDU as part of the random access procedure; otherwise, it is set to 0.

[0043] -Ci(BFR MAC CE): This field indicates the detection of a beam fault and the presence of an octet containing the AC field of the SCell with ServCellIndex i. A Ci field set to 1 indicates that a beam fault has been detected and that an octet containing the AC field exists for the cell with ServCellIndex i. A Ci field set to 0 indicates that a beam fault has not been detected and that an octet containing the AC field does not exist for the cell with ServCellIndex i. The octets containing the AC field exist in ascending order based on ServCellIndex;

[0044] -Ci (Truncation BFR MAC CE): This field indicates beam fault detection for the SCell with ServCellIndex i. A Ci field set to 1 indicates that a beam fault was detected and that an octet containing the AC field of the SCell with ServCellIndex i may be present. A Ci field set to 0 indicates that a beam fault was not detected and that an octet containing the AC field does not exist for the SCell with ServCellIndex i. Octets containing the AC field, if present, are included in ascending order based on ServCellIndex. The number of included octets containing the AC field is maximized without exceeding the available license size.

[0045] -AC: This field indicates the presence of the candidate RS ID field in this octet. The AC field is set to 1 if at least one of the following is available: the inter-SSB synchronization reference received power (SS-RSRP) in candidateBeamRSSCellList is higher than the synchronization block (SSB) of rsrp-ThresholdBFR; or the inter-CSI-RS CSI-RS RP in candidateBeamRSSCellList is higher than the channel state information (CSI) of rsrp-ThresholdBFR. Otherwise, it is set to 0. If the AC field is set to 1, the candidate RS ID field exists. If the AC field is set to 0, R bits exist.

[0046] - Candidate RS ID: This field is set to the index of the SSB in candidateBeamRSSCellList whose SS-RSRP is higher than rsrp-ThresholdBFR, or to the index of the CSI-RS in candidateBeamRSSCellList whose CSI-RSRP is higher than rsrp-ThresholdBFR. This field is 6 bits long.

[0047] -R: Reserve bits, set to 0.

[0048] However, it should be noted that when BFR is indicated on the SpCell, the AC, R, and candidate RS ID bytes (i.e., the AC, R, and candidate RS ID fields) are currently not present. That is, no such information is encoded into the SpCell's BFR MAC CE.

[0049] The network described (e.g.) Figure 1AIt can also support the use of multiple transmit points (TRPs) (i.e., multiple transmit / receive points (M-TRPs)). M-TRPs can support, for example, up to two (2) TRPs, but the number of TRPs is not limited to two. Therefore, for example, UEs 100 and 102 can receive data via multiple TRPs. Different TRPs can be controlled, for example, by network node 104. Examples of such systems are shown in... Figure 1B As shown in the figure, this diagram can be understood as depicting the relationship between... Figure 1A The same system, but with higher accuracy compared to the M-TRP scenario. M-TRP operation can be implemented in this way, that is, using the CORESETPoolIndex parameter [0..1] to associate the CORESET with a specific TRP, instead of explicitly indicating the TRP identifier (ID). CORESETs within the Physical Downlink Control Channel (PDCCH)-config with the same poolIndex can be assumed by the UE to be configured to be provided from the same TRP. Reference Figure 1B The diagram illustrates TRPs with CORESETPoolIndex 0 and 1, where a TRP with CORESETPoolIndex 0 provides three beams (RS#1, RS#2, and RS#3), while a TRP with CORESETPoolIndex 1 provides two beams (RS#4 and RS#5). M-TRPs can also be configured for inter-cell scenarios, where a TRP (sometimes called an inter-cell M-TRP) can be associated with different cells. In an inter-cell M-TRP, a UE can be provided with a configuration where the CORESET of the CORESETPoolIndex / TRP is provided by multiple cells (e.g., two). In some examples, a UE can be explicitly configured with more than one (e.g., two) different CORESETPoolIndex values ​​associated with a CORESET or CORESETpoolIndex other than the current serving cell (e.g., associating the CORESET / PoolIndex with a Physical Cell Identifier (PCI)). In some examples, a UE may determine that it is configured for inter-cell (M-TRP) communication when associated with a downlink reference signal indicated by the active TCI state of the CORESET's PDCCH / PDSCH or a quasi-cooperative positioning (QCL) signal (the source of which is associated with a PCI outside the current serving cell). These should be understood as illustrative examples.

[0050] However, despite the introduction of M-TRP operation and the existence of techniques for BFR indication, there has been no progress in improving the availability of M-TRP for beam fault detection and / or BFR regarding M-TRP. For example, if one of the beams (i.e., having RS#1, RS#2, RS#3, RS#4, or RS#5) fails, there is a lack of an effective and reliable concept for indicating it to the network. For instance, if UE 100 (e.g., configured for PDCCH reception and / or configured for beam fault detection) is served via beams RS#1 and RS#4, and RS#1 fails, UE 100 can determine that it has experienced a fault on a subset of beams. This can be referred to as a partial beam fault. It is possible to recover from such partial beam faults by utilizing the RS#2 or RS#3 beam. However, there is no known process for this, and typically, all beams configured for fault detection must be in a fault condition for the recovery process to be initiated. When all beams (i.e., all beam fault detection reference signals (BFD-RS) or all reference signals in the fault detection set (i.e., set q0) are in a fault condition, it can be called a beam fault, or in some cases a complete fault or a complete beam fault.

[0051] In another example, if the UE is configured to monitor beam faults on one or more beam fault detection resource sets (e.g., BFD-RS sets #0 and #1), and all RSs in all sets are in a fault condition, the UE can determine that a full beam fault has occurred / detected. In another example, if the UE experiences a fault on set #0, it can determine that there is a partial fault or a complete failure on set #0. In some cases, if a fault is detected on set #1, the UE can declare a partial fault. In some cases, if a fault is detected on set #0 (but not on set #1), the UE can declare a partial fault, but if a fault is detected only on set #1, the UE may not declare a partial fault. Furthermore, a beam fault can occur if both RS #1 and RS #4 are faulty. Recovery via RS #2 / 3 and RS #5 is also possible. Again, the procedures for this aspect have not been described. Therefore, a solution is provided for M-TRP beam fault indication, or for fault indication when a subset of fault detection reference signals is determined to be in a fault condition (e.g., based on a hypothetical PDCCH BLER), or for fault indication when at least one of the beams (e.g., PDCCH beams or beam fault detection reference signals) associated with (multiple) CORESETs of a specific CORESETPoolIndex is faulty or has already failed. This solution allows the use of unused, reinterpreted, or specifically defined BFR MAC CE fields of the SpCell to encode indications of beam faults on at least one of multiple TRPs. It should be noted that, in general, the described method can be used with any MAC CE, MAC CE for beam fault recovery, PUCCH or PUSCH signaling for fault recovery or fault indication. This improves communication efficiency and helps the UE recover more effectively from beam fault situations. For example, instead of simply indicating that the entire cell has failed, the UE can indicate that one or more TRPs used by the UE have failed on currently unused resources. These TRPs can be provided via one or more cells. Therefore, the accuracy of indication and thus the efficiency of recovery can be improved from known solutions that do not fundamentally address M-TRP beam fault indication and recovery. It should also be noted that any method described herein can also be used for fault recovery of one or more SCells (according to the embodiments described herein). In some examples, faults can be indicated for both the SpCell and one or more Scells(one or more), or simply, any method described herein can be used for fault indication and / or to provide additional information about the fault (e.g., the TRP of the fault, candidate beam information, complete / partial fault). Any embodiment described herein can describe a method for: indicating a fault, recovering from a fault, or both.

[0052] Figure 2 A flowchart according to one embodiment is illustrated. (Reference) Figure 2 A method for a UE in a wireless communication network is provided, the method comprising: detecting a beam fault on at least one TRP, the UE being configured to communicate with a plurality of TRPs (block 202); encoding beam fault indication data into a BFR MAC CE based on the detection, wherein the beam fault indication data indicates a beam fault on at least one TRP (block 204); and transmitting the BFR MAC CE to network elements of the wireless communication network (block 206).

[0053] Figure 3 A flowchart according to one embodiment is illustrated. (Reference) Figure 3 A method for a network element in a wireless communication network is provided, the method comprising: configuring a UE of the wireless communication network to monitor beam faults on at least one of a plurality of TRPs, the UE being configured to communicate with the plurality of TRPs, wherein the configuration causes the UE to transmit beam fault indication data indicating beam faults on at least one TRP (or a set of fault detection resources) to a BFR MAC CE based on the detection of beam faults, and transmitting the BFR MAC CE (block 302) to a wireless network (e.g., to the network element configuring the UE or some other network element).

[0054] For example, Figure 2 and Figure 3 The described method can be applied to Figure 1A and 1B In (multiple) systems. Regarding Figure 2 and Figure 3 The UE discussed can be, for example, UE 100 or UE 102, or some other similar network device. For example, see reference... Figure 2 and Figure 3The network element discussed can refer to network node 104. For example, a TRP can be controlled and / or utilized by network node 104 to enable M-TRP communication to UE 100 or UE 102. The proposed solution enables the UE to indicate beam faults in M-TRP scenarios, such that, for example, a BFR MAC CE indicates one or more specific TRPs that have failed. In some examples, a BFR MAC CE can be used to indicate that a specific set of fault detection resources (BFD-RS) that can be associated with one or more TRPs has failed. For example, if the UE uses two TRPs, and one of the TRPs is associated with a beam fault (e.g., a beam fault provided by the TRP and used by the UE), then a BFR MAC CE can indicate that specific failed TRP. Therefore, a BFR can be easily triggered, such as configuring another beam of the same TRP for the UE. It should be noted that in such cases, the UE may not completely lose communication with the network, because, for example, the other TRP of the two TRPs may still be operational as needed (i.e., not associated with a beam fault). Therefore, the BFR MAC CE can be sent via another TRP, or it is possible for the UE to perform a random access procedure, such as CBRA, and send the BFR MAC CE during the random access procedure. The proposed solution can also be used to indicate that all TRPs (e.g., in the case of using two TRPs) are associated with beam failure, i.e., all TRPs have failed. In all cases, it is possible for the UE to indicate a candidate beam (e.g., indicating the RS index) to the network (e.g., network element) in the BFR MAC CE, so that BFR can be performed even in the case of all TRP failures.

[0055] In this regard, it should be noted that the proposed solution is not limited to any specific method for determining TRP-related faults. As an example of a fault detection strategy that could be considered for determining beam faults in an M-TRP scenario, the UE could be configured by the network with a TRP-specific set of q0 (i.e., fault detection resources; for example, q0_#0 could be equal to the RS of a certain TRP (e.g., having...). Figure 1B In CORESETPoolIndex 0), and q0_#1 can be equal to the RS of some other TRP (e.g., having Figure 1BThe fault detection resources (e.g., resource sets) for a CORESETPoolIndex (1) and / or a single q0 can be used, but the indication can be determined based on a subset of RSs in the set. Furthermore, there can be two fault detection procedures at the MAC layer, one for each CORESETPoolIndex if two CORESETPoolIndex exist. The number of procedures can also be larger if the number is greater, allowing monitoring for faults in each TRP. In some examples, the fault detection resources (e.g., resource sets) for a TRP or CORESETPoolIndex can be determined based on RSs indicated by the active TCI state of the PDCCH (i.e., PDCCH beam) of the corresponding CORESET associated with a particular CORESETPoolIndex. Each CORESETPoolIndex or the fault detection resource set across CORESETPoolIndex can include one or more RSs.

[0056] After (or in response to) the UE having determined a TRP-specific fault at the MAC layer, for example, based on the set of q0_TRP0 and q0_TRP1, or having determined a (partial) beam fault based on any TRP / CORESETPoolIndex-specific fault detection mechanism, the UE may trigger a TRP fault indication, as referenced above. Figure 2 As explained, triggering a TRP fault indication may include, for example... Figure 2 Steps 204 and 206, or any embodiments thereof. Regarding step 206, the transmission of the BFR MAC CE (sometimes simply referred to herein as MAC CE) may be performed as part of the CBRA. That is, for example, the BFR MAC CE may be sent in Msg3 of the CBRA, or in MsgA of the 2-step RACH. Alternatively, the UE may multiplex the BFR MAC CE to a UL grant. The UL grant may refer to an available UL grant or a UL grant obtained via a functional TRP. For example, if one of the TRPs fails, another UL grant may be obtained via the remaining TRPs. In some examples, the UE may determine to select a random access resource on the failed TRP. In some examples, the UE may be provided with, for example, an association between a CBRA resource and / or an SSB and a specific TRP, and this association may be used in the random access resource selection. As an example, the UE may select any random access resource to provide the BFR MAC CE, or it may select a random access resource associated with the failed TRP.

[0057] In one embodiment, in the event of a partial beam failure, the UE transmits a BFR MAC CE on a UL-granted or available UL resource (e.g., an uplink shared channel (UL-SCH) resource). However, if the UL grant / resource is unavailable, the UE may trigger a scheduling request (SR) procedure. This allows the UE to obtain resources for transmitting the BFR MAC CE if no UL grant(s) are available. In one embodiment, the UE uses a BFR SR resource associated with the SCell BFR to request UL resources for transmitting the BFR MAC CE. The BFR MAC CE may include beam failure indication data indicating a partial beam failure. For example, in a full beam failure, the UE may initiate a random access procedure. It is also possible to utilize a random access procedure in the event of a partial failure. In some cases, utilizing existing UL grants or requesting resources, such as through an SR procedure, may be advantageous.

[0058] In one embodiment, the UE is configured to perform an operation including: triggering the transmission of a BFR MAC CE (e.g., using a CBRA procedure or a scheduling request procedure) if a beam fault is detected on all TRPs of a plurality of TRPs, if a beam fault is detected on a default TRP (e.g., CORESETPoolIndex equals 0), or if a beam fault is detected on a TRP that is configured (i.e., the network may also configure it such that CORESETPoolIndex equals 0 or 1) for which the UE monitors for beam faults; for example, the BFR MAC CE can be sent using UL grants as described above, and if unavailable, a CBRA procedure can be triggered to send the BFR MAC CE. In one example, if a UL grant is sent on an uplink resource associated with a non-faulty TRP, the UE can use the available UL grant to send the MAC CE (or PUSCH signaling for BFR).

[0059] It should be noted that in the case of partial failures, sending a BFR MAC CE during the CBRA procedure can also be used. For example, the UE can select resources from the failed TRP, thereby indicating new candidates via the CBRA procedure.

[0060] In one embodiment, the UE is configured to perform an operation including: triggering a CBRA procedure if a beam fault is detected on all TRPs of a plurality of TRPs, if a beam fault is detected on a default TRP, or if a beam fault is detected on a TRP configured for beam fault monitoring by the UE. In a further embodiment, the UE may send a BFR MAC CE without triggering a CBRA procedure.

[0061] Figure 5 The diagram illustrates a signal pattern according to one embodiment. (Reference) Figure 5 In block 502, network node 104 can configure UE 100 for M-TRP beam fault indication. This configuration may be similar to that discussed in reference block 302. That is, the network can instruct UE 100 how UE 100 should monitor beam faults and how to indicate beam faults if such faults are detected. As described above, this configuration may include, for example, configuring the UE to indicate full beam faults (i.e., beam faults detected on all TRPs) and partial beam faults (i.e., beam faults detected on one of the TRPs). For example, the network configuration may further include indication of which TRPs(s) the UE should monitor for partial faults. For example, the network can configure UE 100 to monitor a default TRP (sometimes called the primary TRP) and / or indicate partial faults with respect to the default TRP. The default TRP may refer to a CORESETPoolIndex configuration, where a specific value such as "0" is used for the CORESET if no CORESETPoolIndex is provided for the corresponding CORESET. Alternatively, this type of value can also be configured or agreed to be "1". Therefore, for example, the network can configure UE 100 to indicate a partial fault when CORESETPoolIndex = 0. Alternatively, the network can configure UE 100 to monitor non-default TRPs and / or indicate partial faults with respect to non-default TRPs. Therefore, for example, the network can configure UE 100 to indicate a partial fault when CORESETPoolIndex = 1.

[0062] Based on the configuration received from network node 104 or some other network element, UE 100 can perform M-TRP beam fault detection, monitoring, and / or indication. In block 504, UE 100 can detect beam faults (e.g., complete or partial faults). Based on the detection in block 504, as shown in block 506, UE 100 can carry coded beam fault indication data to the BFR MAC CE.

[0063] In box 508, a BFR MAC CE can be sent from the UE to the network. Figure 5 In this process, the BFR MAC CE is sent to network node 104. As described above, the transmission can be performed as part of a random access procedure (e.g., in Msg3 of CBRA) or using available or obtainable UL authorization.

[0064] For example, if a full beam failure is detected in block 504, then in block 506, UE 100 can encode the BFR MACCE to indicate a full beam failure. Similarly, if a partial beam failure is detected in block 504, then in block 506, UE 100 can encode the BFR MACCE to indicate a partial beam failure. In such cases, the BFR MAC CE can indicate, for example, the CORESETPoolIndex (e.g., 0 or 1) of the TRP associated with the beam failure. Alternatively, for example, if the network has already configured UE 100 to indicate a partial failure at a certain CORESETPoolIndex (e.g., 0 or 1), the BFR MAC CE can simply indicate a partial failure, and the network can determine which TRP the beam failure involves based on the previously made configuration.

[0065] The above briefly illustrates how the network can configure UE 100 to encode beam fault indication data into BFR MACCE. For example, refer to... Figure 4A and Figure 4B The beam fault indication data can be encoded into one or more of the following fields of the BFR MAC CE: AC, R, and candidate RS ID or R bit. As mentioned above, the BFR MAC CE can refer to an untruncated BFR MAC CE or a truncated BFR MAC CE. How the different(multiple) fields are encoded will be explained later. Figures 6A to 6HThe discussion will proceed in further detail with the help of some examples shown. The existence of the SpCell field depends on partial beam fault detection (BFD) configured for the UE. For example, if partial BFD is not configured, the field is not encoded, while if partial BFD is configured, the field is encoded. In another example, the SpCell field is encoded when the UE has been configured with multiple TRPs or inter-cell M-TRPs. In yet another example, the field is encoded when the UE is configured with more than one or two different CORESETPoolIndex values. In yet another example, the field is encoded when the UE is configured to perform fault detection based on a subset of TRP, CORESETPoolIndex, or BFD-RS (where more than one set of fault detection resources may exist). However, in one embodiment, the BFR MAC CE used to carry beam fault indication data is a BFR MAC CE configured to indicate a SpCell fault. Previously, these fields (i.e., AC, R, and candidate RS ID or R bits) had not been used. Therefore, the proposed solution extends the availability of BFRMAC CE for SpCell fault indication by utilizing unused fields(s) to append indications of beam faults for each or multiple TRPs. It should also be noted that while this solution enables the use of BFR MACCE for SpCell fault indication of TRP-related beam faults, BFR MAC CE can also be used for its original purpose of indicating SpCell faults. This can be achieved, for example, by encoding specified data into the SP field of the BFR MAC CE (see, for example, the SP field of the BFR MAC CE). Figure 4A ).

[0066] In any embodiment, the SpCell's BFR MAC CE bit field may point to a fault detection resource set, rather than referencing a CORESETPoolIndex value or TRP ID. For example, in a case where the UE is configured to perform fault detection based on BFD-RS set #0 and BFD-RS set #1, this field may indicate the set of faults. For instance, in the fault set, all RSs need to be in a fault condition to declare a beam fault (or L1 to indicate beam fault instance indication to higher layers such as MAC). The BFD-RS sets may be associated with TRP / CORESETPoolIndex (e.g., 0 and 1). In some examples, although only one CORESETPoolIndex is configured, the UE may be configured with multiple fault detection sets. As an example, the UE may be configured to perform fault detection on BFD-RSs that are assumed to be monitored from the same TRP (i.e., the CORESET is configured with the same CORESETPoolIndex).

[0067] Therefore, the network can configure UE 100 in at least two different ways. In one embodiment, the network configures UE 100 to encode beam fault indication data into the BFR MAC CE by configuring UE 100 to indicate beam faults associated with multiple TRPs (and therefore multiple CORESETPoolIndex, since each TRP may correspond to a certain CORESETPoolIndex) and / or at least one TRP. Thus, the network can configure UE 100 to perform full beam fault indication and / or partial beam fault indication.

[0068] In one embodiment, the UE is configured by higher-layer parameters (e.g., PDCCH-Config) for indicating full and / or partial beam failure. For example, PDCCH-Config may include two or more distinct values ​​for CORESETPoolIndex in ControlResourceSet. Configuration can be performed by the network.

[0069] Similarly, as briefly discussed above, network-based configuration can refer to... Figure 1A or Figure 1B The configuration of the cellular network. This configuration can be implemented by one or more network elements, such as network node 104.

[0070] As described above, each TRP can be associated with a CORESETPoolIndex value, or more specifically, from the UE's perspective, it is assumed that CORESETs configured with the same PoolIndex share the same or similar attributes, for example, sent from the same TRP. However, this does not necessarily mean that the network must instruct the UE to a specific CORESETPoolIndex value or a specific TRP for monitoring. Instead, the network can instruct the UE to share specific attributes with certain sets of control resources having the same CORESETPoolIndex, and the UE can determine that an M-TRP is configured when more than one or at least two different CORESETPoolIndex values ​​are configured.

[0071] According to one embodiment, if the UE has configured more than one CORESETPoolindex value and detects a beam fault (BFR), the UE encodes beam fault indication data into a BFR MAC CE. In an alternative example, the UE encodes the indication data when it has configured more than one fault detection resource set (e.g., two). These fault detection resource sets may be associated with a TRP / CORESETPoolIndex of one cell (intra-cell multiple TRPs) or multiple cells (e.g., inter-cell multiple TRPs). Multiple fault detection resource sets may also be configured for fault detection of a single TRP / CORESETPoolIndex. Therefore, if the UE has been configured by the network with two or more CORESETPoolindex values ​​(or fault detection resource sets), the UE may encode the data into a BFR MAC CE, as shown, for example, by referring to... Figure 2 As explained, these two CORESETPoolindex values ​​should be distinct. On the other hand, if the network configures a CORESETPoolindex value for the UE (i.e., no more than one CORESETPoolIndex value or no more than one fault detection resource set), the UE can encode the BFR MAC CE such that it indicates a cell-level fault (i.e., all beams associated with said one CORESETPoolIndex or fault detection resource set have failed), and can not encode the beam fault indication data field at all (e.g., the UE uses the indication in the bitmap to indicate only that SpCell has failed, without any candidate information).

[0072] In one embodiment, if the UE is configured with more than one CORESETPoolIndex value, and at least one CORESET or at least one CORESETPoolIndex is associated with a PDCCH reception from a non-serving cell, the UE encodes beam fault indication data into BFR MAC CE. This may imply that the proposed solution can be used in inter-cell scenarios.

[0073] Figure 6A An embodiment is illustrated. (Reference) Figure 6A The AC 602, R 604, and candidate RS ID 606 fields are shown as illustrative examples. These fields may be similar to those in the reference above. Figure 4A and Figure 4BThe fields described are those included in BFR MAC CE. Note that the proposed solution does not necessarily require specific fields 602-606, and similar solutions can be implemented using (multiple) general bits and (multiple) bytes. Therefore, in the following text, field 602 is referred to as the second information element, field 604 as the first information element, and field 606 as the third information element. Figure 6B , Figure 6C , Figure 6D , Figure 6E , Figure 6F and Figure 6H The illustrations present several example embodiments of different ways of encoding beam fault indication data into a BFR MAC CE or similar entity. In these different example embodiments, note that the SP field of the BFR MAC CE can still be used to indicate a cell-level fault (e.g., a current SpCell fault) or a fault specific to the SpCell for a given TRP / CORESETPoolIndex / fault detection resource set. In the case of a SCell fault in a multi-TRP as described in the different example embodiments, the UE can indicate the SCell index of the fault and encode additional indication data as described herein.

[0074] According to one embodiment, reference Figure 6B The beam failure indication data includes a first information element 604 indicating whether the beam failure is complete or partial. For example, this indication can be implemented using a single bit (e.g., 0 for a complete beam failure or 1 for a partial beam failure). Therefore, for example, if the UE detects a complete failure, field 604 may not be set (and thus may be equal to 0), and the network can therefore assume that a complete failure has occurred. Figure 6B As shown, fields 602 and 606 may not be encoded. However, in some embodiments, they may be used, and some examples are given below. According to one embodiment, network node 104 configures the UE to indicate whether a complete or partial beam failure has occurred. As described above, this indication can be performed by using the first information element 604 to indicate a complete or partial beam failure.

[0075] In one embodiment, the UE is configured (e.g., by network node 104) to monitor beam faults in a specific TRP among a plurality of TRPs, and wherein a first information element 604 indicates a complete beam fault or a beam failure in that specific TRP. Thus, for example, the network can configure the UE to monitor beam faults associated with a certain CORESETPoolIndex, and the UE can report partial faults associated with that CORESETPoolIndex. Faults can be declared based on the BFD-RS associated with the CORESET of the CORESETPoolIndex.

[0076] In one embodiment, the specific TRP is configured to the UE by the wireless communication network. For example, the network may select the UE to monitor a default or non-default TRP (e.g., the BFD-RS associated with a CORESET of CORESETPoolIndex 0 or 1).

[0077] In one embodiment, the specific TRP is the default TRP even if the network does not explicitly configure the UE to monitor it. Therefore, in this embodiment, partial faults may always be associated with the TRP where CORESETPoolIndex=0, or in other words, the UE considers partial fault detection based on the RS indicated by the active Transport Configuration Indicator (TCI) state (one or more) where CORESETPoolIndex=0.

[0078] In one embodiment, the UE is configured to report only partial faults on the CORESET associated with a CORESETPoolIndex equal to 0 or 1. Therefore, in this embodiment, the UE does not indicate partial faults on both CORESETPoolIndexes.

[0079] According to one embodiment, reference Figure 6C In the case of partial beam failure, the beam failure indication data includes a second information element 602 (i.e., in addition to the first information element 604 indicating the partial failure) indicating the index value of the TRP / CORESETPoolIndex associated with the partial beam failure. For example, this index value could be a CORESETPoolIndex. If there are two TRPs that detect partial failures (i.e., 0 for one CORESETPoolIndex and 1 for the other), the CORESETPoolIndex value can be indicated, for example, with one bit. If there are more CORESETPoolIndexes (and therefore more TRPs), more than one bit can be used. Indicating the CORESETPoolIndex can be beneficial because the network may not necessarily know which CORESETPoolIndex the partial beam failure is associated with. For example, the UE could therefore indicate a partial beam failure on a CORESETPoolIndex equal to 0 or 1.

[0080] In one embodiment, the second information element 602 indicates the presence of a third information element 606 in the BFR MAC CE. Therefore, the second information element does not necessarily indicate the CORESETPoolIndex value. In this embodiment, the third information element 606 may further indicate the index of the candidate beam for the CORESETPoolIndex of the fault that the UE has detected. Based on this information, the network may also be implicitly indicated regarding the TRP of the fault. For example, the network may determine the association between the candidate beam identifier and the TRP of the fault based on stored information.

[0081] In one embodiment, reference Figure 6C In the event of a partial beam failure, the beam failure indication data includes a second information element 602 indicating the presence of candidate beams exceeding a predetermined threshold. The predetermined threshold may be, for example, a reference signal received power (RSRP) threshold or a signal-to-interference-noise ratio (SINR) threshold. For example, the threshold may be configured by the network. For example, the indication may be 0 or 1 (i.e., a one-bit indication). As discussed in previous embodiments, the third information element 606 can therefore indicate one or more candidate beam identifiers of the CORESETPoolIndex associated with the partial beam failure.

[0082] According to one embodiment, reference Figure 6E If the second information element 602 indicates (e.g., bit 0) that no candidate beam exceeds a predetermined threshold, the beam fault indication data also includes a third information element 606, which indicates the index of the TRP (or CORESETPoolIndex) associated with the partial beam fault. Therefore, for example, if the AC field is set to zero (i.e., no candidate is associated with the faulty TRP and has a quality higher than the threshold), the UE can encode at least one bit field to indicate that the faulty TRP (e.g., the first or last, or any bit in the third information element 606) can be set to the value of the faulty TRP / CORESETPoolIndex.

[0083] Therefore, in Figure 6D In this context, at least one candidate beam exists, and this can be indicated to the network by the UE by setting field 602 to 1 and indicating one or more candidates in field 606. However, if there are no candidates, field 602 can be set to 0, and in this case, field 606 can be used to indicate the TRP / CORESETPoolIndex associated with a partial beam failure. For example, one bit of field 606 can be used. Generally, the third information element can include multiple bits that can be used for indication purposes. For example, fields 602-606 can be equal to one byte.

[0084] In one embodiment, if the UE knows the association between the SSB and the TRP / CORESETPoolIndex, the UE selects the CBRA resource corresponding to the faulty TRP / CORESETPoolIndex and sends a BFRMAC CE in Msg3 or MsgA of a 2-step RACH. The network can determine that the selected SSB is an implicit candidate for the TRP / CORESETPoolIndex. In such cases, it may not be necessary to send an indication of the faulty TRP / CORESETPoolIndex, as it can be implicitly indicated to the network.

[0085] In another embodiment, if the UE knows the association of an SSB with a TRP / CORESETPoolIndex, the UE selects a CBRA resource on a non-faulty (or functional) TRP / CORESETPoolIndex and indicates any SSB of the faulty TRP / CORESETPoolIndex in the third information element 606. This can also be understood by the network as an implicit indication of a faulty TRP / CORESETPoolIndex. If the network provides the UE with an SSB association (or a CSI-RE associated with a DL-RS) to a TRP, a candidate RS ID can be implicitly indicated. The UE can select any SSB for indication purposes. For example, if the UE has been provided with an association of a random access resource / DL-RS corresponding to a RACH resource with a specific TRP / CORESETPoolIndex, it can determine to select a new candidate beam from the faulty TRP based on the association. For example, the selected SSB may exceed a threshold that it would be selected by the UE.

[0086] In one embodiment, reference Figure 6D The third information element 606 may not be encoded, and after successful delivery of BFRMAC CE, the network does not require the UE to monitor the CORESET associated with the faulty TRP / CORESETPoolIndex until reconfiguration is made using the new TCI state.

[0087] Alternatively, when the UE indicates a partial fault, it can indicate the TRP / CORESETPoolIndex / fault detection resource set for its declared fault (e.g., in field 606). Additionally, this field (i.e., field 606) can indicate candidate RSs for the TRP / CORESETPoolIndex for the fault.

[0088] In one embodiment, in any of the methods described herein, the UE uses one or more of the following to indicate a candidate RS (i.e., a new candidate beam, for example, in field 606): a downlink RS, an SSB (or CSI-RS) index, a TRP / CORESETPoolIndex-specific RS index, a DL RS listed in the candidate RS list, or a candidate listed in the TRP-specific candidate RS list.

[0089] In one embodiment, reference Figure 6F and Figure 6H The second information element 602 (e.g., one bit) is used to indicate a complete or partial beam failure (0 / 1) on a given TRP / CORESETPoolIndex. In such cases, the first information element 604 (e.g., one bit) can be used to indicate the faulty TRP / CORESETPoolIndex / fault detection resource set, or whether there are candidate beams exceeding a threshold available to the UE. Figure 6F In the example, the second information element is used to indicate the TRP / CORESETPoolIndex / fault detection resource set. It is further possible to indicate (multiple) candidates in the third information element 606 (e.g., 6 bits), such as... Figure 6H As shown. For example, the UE may be configured with a list of candidate RSs, or an SSB or a CSI-RS associated with a TRP / CORESETPoolIndex / fault detection resource set. Therefore, the network can determine partial beam faults (i.e., which TRP / CORESETPoolIndex / fault detection resource set has failed) based on the association of the indicated candidate RSs. Alternatively, if the second information element 602 is set to zero to indicate no candidates, at least one bit in the third information element 606 may encode the faulty CORESETPoolIndex / fault detection resource set (i.e., the TRP indicating the fault).

[0090] Note that, at this point, when indicating a partial SpCell fault (complete or partial beam failure), the UE can ignore pending SCell fault indications. That is, the UE is not required to report a faulty SCcell, and can report the SCcell fault in a subsequent MAC CE.

[0091] Furthermore, as discussed above, in some examples, the UE can know or determine the association between the SSB or CSI-RS and the TRP / CORESETPoolIndex / fault detection resource set. This association can be obtained from the network, for example, via Radio Resource Control (RRC) signaling and / or MAC CE. For instance, this RRC signaling can be specific RRC signaling. For example, if there are 4 SSBs in a cell, SSB indices #0 and #1 can be associated with TRP0 / recovery resources where CORESETPoolIndex equals 0, and SSB indices #2 and #3 can be associated with TRP1 / recovery resources where CORESETPoolIndex equals 1, respectively. In some examples, the SSB may belong to another cell (i.e., not the serving cell), therefore the proposed solution can also be applied to inter-cell M-TRPs.

[0092] For the network side, refer to Figure 5 and Figures 6A to 6H Network node 104 can obtain BFR MAC CE with certain specific beam fault indication data from UE 100. In one example, based on the first information element 604 in the beam fault indication data, network node 104 can determine whether the UE is experiencing a partial or complete beam fault.

[0093] In another example, if the first information element 604 indicates a partial beam failure, network node 104 can determine the TRP / CORESETPoolIndex associated with the beam failure based on the second information element 602 and / or the third information element 606 included in the beam failure indication data. Based on this information, BFR can be continued or initiated by network node 104.

[0094] Some example implementations are listed below.

[0095] In one embodiment, when the UE has determined a TRP-specific fault at the MAC layer, for example based on the set of q0_TRP0 and q0_TRP1, or has determined a partial beam fault based on any TRP / CORESETPoolIndex-specific fault detection mechanism, the UE can trigger a TRP fault indication using, for example, a random access procedure. During the random access procedure, a CBRA can be performed using the BFR MAC CE specified for the SpCell fault to recover from the beam fault.

[0096] In one embodiment, if multiple TRPs / (multiple) CORESETPoolIndex or partial beam fault detection are configured for the UE, or if the UE is configured by a higher-layer parameter PDCCH-Config containing two different values ​​of CORESETPoolIndex in ControlResourceSet, then additional bytes are present / encoded for additional BFR information for SpCell (i.e., bytes containing SpCell AC, R, and candidate RS ID fields, or at least one byte carrying partial / multiple TRP-specific fault recovery information).

[0097] In one embodiment, when the UE is configured with more than one CORESETspoulindex value (the UE is configured with multiple TRPs such that at least two CORESETs on the active DL BWP have different CORESETPoolIndex values), the UE encodes the field according to an embodiment of the invention. In other words, when the UE is configured with one CORESETPoolIndex, or when it is not configured with more than one CORESETPoolIndex, it encodes (truncated) BFR MAC CE as described in Section 2.

[0098] In one embodiment, a partial fault may always be associated with the TRP of CORESETPoolIndex'0, or in other words, the UE considers partial fault detection based on the RS indicated by the (multiple) active TCI states of CORESETPoolIndex'0. As a related example embodiment, the UE is configured to report only partial faults on the CORESET associated with CORESETPoolIndex'1' or '0'.

[0099] In one embodiment, when the UE reports a CORESETPoolIndex-specific SpCell fault using a (truncated) BFR MAC CE, the UE may encode the MAC CE as follows (with additional bytes carrying SpCell-specific information):

[0100] ●Option 1

[0101] The SP field indicates a fault on the current SpCell.

[0102] The ○R field (used to indicate partial TRP failure) indicates a partial failure (the configured CORESETPoolindex has experienced a TRP failure).

[0103] ■Whether the UE reports a TRP fault with a PoolIindex value of 0 or 1 (the fault is declared based on the BFD-RS associated with the CORESET PoolIndex) can be configured by the network.

[0104] ■ The R field is set to "0", which indicates that no partial fault was detected, and the network assumes that a complete fault (beam failure on all RSs) has occurred.

[0105] In one embodiment, for partial or TRP failures, only a single TRP may be monitored, and when a complete failure is detected, the UE does not set the R field.

[0106] In one embodiment, the TRP for partial fault monitoring is not the default TRP (CORESETPoolIndex0), meaning the UE can be configured to report only partial faults on TRPs with a CORESETPoolIndex value of '1'.

[0107] ●Option 2

[0108] In one embodiment, the UE is configured to report a fault on a CORESET associated with CORESET poolindex '1' or '0', meaning the UE monitors a partial fault in a TRP or it monitors a complete fault. When the UE reports a fault in a specific SpCell of CORESETPoolIndex using (truncated) BFR MAC CE, the UE encodes the MAC CE as follows:

[0109] ■ The SP field indicates a fault on the SpCell.

[0110] The R field indicates a complete or partial failure, where a partial failure refers to a TRP failure (the RS associated with the CORESET under the same CORESETPoolIndex has failed).

[0111] ■AC Field Options

[0112] ● The AC field, based on the R field, indicates whether a fault has occurred if the CORESETPoolIndex value is "0" or "1".

[0113] In one embodiment, if the UE knows the association between the SSB and the TRP, the UE selects the CBRA resource corresponding to the faulty TRP, and the network interprets the selected SSB as an implicit candidate for the TRP.

[0114] In another embodiment, if the UE knows the SSB association, the UE selects the CBRA resource on the non-faulty TRP and indicates any SSB of the faulty TRP in the candidate field. If the network provides an SSB index association with the TRP, indicating the candidate RS ID, the UE can select any SSB, or any SSB above a threshold of the faulty TRP.

[0115] In another embodiment, the candidate RS ID field may not be encoded, and after successful delivery of MAC CE, the UE does not need to monitor the CORESET associated with the faulty poolIndex until it is reconfigured with a new TCI state.

[0116] In one embodiment, if the UE indicates whether to report a CORESETPoolindex failure based on the RS associated with the Poolindex value 0 or 1, this can be configured by the network.

[0117] In one embodiment, the UE indicates the TRP / CORESETPoolIndex that failed after its indicated partial failure. Additionally, a candidate RS can be indicated for a given TRP / CORESETPoolIndex.

[0118] In one embodiment, when the UE indicates a partial beam fault (e.g., using the R field), the candidate RS field implicitly indicates the faulty TRP / CORESETPoolIndex. When the AC field is set to zero (i.e., there are no candidates associated with the faulty TRP and whose quality is above a threshold), the UE encodes at least one bit field to indicate the faulty TRP (e.g., the first or last, or any bit in the candidate RS field, is set to the value of the faulty TRP / CORESETPoolIndex).

[0119] ●Option 3

[0120] ○ In one embodiment, the additional byte encoding of the SpCell fault is as follows:

[0121] ■BIT1: Indicates partial or complete fault

[0122] ■BIT2: If BIT1 indicates a partial fault, BIT2 indicates the fault TRP, i.e., the CORESETPoolIndex where the fault occurred.

[0123] ■ Or BIT2: If BIT1 indicates a partial fault, then BIT2 indicates whether there are candidates for the fault's TRP that are above a threshold.

[0124] ■BIT3-BIT8: Indicates candidate RS indexes. The Ue can be configured with a list of candidate RSs, or an SSB associated with a TRP. The network determines partial beam failures (which TRP is faulty) based on the association of candidate RSs.

[0125] ■ Alternative, BIT3-BIT8: If the AC field is set to zero to indicate that there are no candidates, then the TRP ID (CORESETPoolIndex) of at least one bit in the candidate RS field is encoded as faulty.

[0126] In one embodiment, when a partial SpCell fault is indicated, the UE can ignore the pending Scell ​​fault indication, that is, it does not need to report the faulty SCell, and can report the SCell fault in a subsequent MAC CE.

[0127] In one embodiment, the UE can be assigned to an SSB associated with a TRP for partial / TRP-specific fault recovery in a specific RRC configuration:

[0128] ● In one embodiment, if there are 4 SSBs in the cell, SSB indices #0 and #1 can be associated with TRP0 / recovery resources for CORESETPoolIndex #0, and #2 and #3 can be associated with TRP1 / recovery resources for CORESETPoolIndex #1, respectively.

[0129] ●SSB can also belong to another cell, i.e., a non-serving cell, such as an inter-cell MTRP.

[0130] In one embodiment, the method described herein is applied when the UE is configured with more than one CORESETPoolIndex value and at least one CORESET in the CORESETPoolIndex is associated with a PDCCH reception from a non-serving cell (inter-cell MTRP).

[0131] In one embodiment, when the UE declares a partial beam fault, it triggers the SpCell's BFR and attempts to map the (truncated) BFR MAC CE to the UL grant, if available; otherwise, the UE triggers a scheduling request procedure. In one option, the UE may use the BFR SR resource associated with the SCell BFR to request UL resources to send a BFR MAC CE with partial beam fault information.

[0132] Figure 7 and Figure 8Devices 700 and 800 are provided, including a control circuitry system (CTRL) 710 and 810 such as at least one processor and at least one memory 730 and 830, including computer program code (software) 732 and 832, wherein the at least one memory and the computer program code (software) 732 and 832 are configured together with at least one processor to cause the respective device 700 and 800 to execute Figures 1 to 1990. Figure 6H Any of the embodiments or their operations.

[0133] refer to Figure 7 and Figure 8 The memories 730 and 830 can be implemented using any suitable data storage technology, such as semiconductor-based storage devices, flash memory, magnetic storage devices and systems, optical storage devices and systems, fixed memory, and removable memory. The memories 730 and 830 may include databases 734 and 834 for storing data. For example, the configuration of M-TRP and M-TRP beam fault indication can be stored in the database. For example, network node 104 can configure UE 100 to use a certain beam fault indication. For example, this configuration can be stored by UE 100 in the database and used accordingly before reconfiguration (e.g., a new Transmit Configuration Indicator (TCI) state set by the network).

[0134] Devices 700 and 800 may also include radio interfaces (TRX) 720 and 820, which include hardware and / or software for establishing communication connections according to one or more communication protocols. For example, the TRX may provide the device with communication capabilities to access a radio access network. The TRX may include standard, well-known components such as amplifiers, filters, frequency converters, (de)modulators, encoder / decoder circuitry, and one or more antennas. For example, the TRX may provide access to F1 and / or Xn interfaces, and / or provide UL / DL communication capabilities. For example, BFR MAC CE may be transmitted via the TRX.

[0135] Devices 700 and 800 may include user interfaces 740 and 840, which may include, for example, at least one keyboard, microphone, touch display, monitor, speaker, etc. Users of devices 700 and 800 can use user interfaces 740 and 840 to control the corresponding devices.

[0136] In one embodiment, the device 700 may be in or included in a UE, such as a UE performing the methods described above (e.g., see [link to UE]). Figure 2 For example, device 700 may be included in UE 100 or UE 102.

[0137] In one embodiment, the device 800 may be in or included in a network element, such as a network element that performs the methods described above (e.g., see...). Figure 3 For example, device 800 may be included in network node 104.

[0138] According to one embodiment, reference Figure 7 The control circuit system 710 includes a detection circuit system 712, which is configured to perform at least the following: Figure 2 The operation described in block 202; the encoding circuit system 714, configured to perform at least the operation regarding Figure 2 The operation described in block 204; and the transmitting circuit system 716, which is configured to perform at least the operation of the transmission circuit system 716. Figure 2 The operation described in box 206.

[0139] According to one embodiment, reference Figure 8 The control circuit system 810 includes a configuration circuit system 812, which is configured to perform at least the following: Figure 3 The operation is described in block 302. Additionally, the control circuitry 810 may also include a receiving circuitry system 814, which is configured to receive BFR MAC CE from at least one or more UEs.

[0140] In one embodiment, at least some of the functionalities of device 800 can be shared between two physically separate devices, forming an operational entity. Therefore, device 800 can be viewed as depicting an operational entity comprising one or more physically separate devices for performing at least some of the described processes. Thus, device 800 utilizing such a shared architecture can include a remote control unit (RCU), such as a host computer or server computer, operatively coupled (e.g., via a wireless or wired network) to one or more remote radio headends (RRHs), such as one or more TRPs located in a base station or network node 104. In one embodiment, at least some of the processes in the described process can be performed by the RCU. In one embodiment, the performance of at least some of the processes in the described process can be shared between the RRH and the RCU. For example, CU / DU splitting can utilize such a shared architecture.

[0141] In one embodiment, the RCU can generate a virtual network through which it communicates with the RRH. Generally, virtual networking can involve the process of combining hardware and software network resources and network functions into a single software-based management entity (virtual network). Network virtualization can involve platform virtualization, often combined with resource virtualization. Network virtualization can be categorized as an external virtual network that combines many networks or portions of networks into a server computer or host computer (i.e., into the RCU). External network virtualization aims to optimize network sharing. Another type is an internal virtual network, which provides network-like functionality to software containers on a single system.

[0142] In one embodiment, the virtual network can provide flexible operational distribution between the RRH and RCU. In effect, any digital signal processing task can be performed in either the RRH or the RCU, and the boundary for transferring responsibility between the RRH and RCU can be selected depending on the implementation.

[0143] According to one aspect, a system comprising a plurality of devices 700 and one or more devices 800 is provided.

[0144] As used herein, the term “circuit system” refers to all of the following: (a) purely hardware circuit implementations, such as those implemented only in analog and / or digital circuit systems; and (b) combinations of circuitry and software (and / or firmware), such as (if applicable): (i) combinations of processors (one or more) or (ii) a portion of processors (one or more) / software, including digital signal processors (one or more), software, and memory (one or more), which work together to enable a device to perform various functions; and (c) circuitry, such as microprocessors (one or more) or portions thereof, which require software or firmware for operation, even if such software or firmware does not physically exist. The definition of “circuit system” applies to all uses of the term in this application. As another example, as used herein, the term “circuit system” will also cover implementations of only one or more processors or portions thereof and their accompanying software and / or firmware. For example, if applicable to a particular element, the term “circuit system” will also cover baseband integrated circuits or application processor integrated circuits for mobile phones, or similar integrated circuits in servers, cellular network devices, or other network devices.

[0145] In one embodiment, referring to Figures 1 to... Figure 6HAt least some of the processes described can be performed by means including corresponding apparatus for performing at least some of the processes described. Some example apparatuses for performing these processes may include at least one of the following: a detector, a processor (including dual-core and multi-core processors), a digital signal processor, a controller, a receiver, a transmitter, an encoder, a decoder, a memory, RAM, ROM, software, firmware, a display, a user interface, a display circuit system, a user interface circuit system, user interface software, display software, a circuit, an antenna, an antenna circuit system, and a circuit system. In one embodiment, at least one processor, memory, and computer program code form a processor apparatus or include one or more portions of computer program code for performing according to Figures 1 to 1. Figure 6H One or more operations or operations thereof in any of the embodiments.

[0146] According to yet another embodiment, the apparatus for performing the embodiment includes a circuit system comprising at least one processor and at least one memory, including computer program code. When activated, the circuit system causes the apparatus to perform at least some of the functionalities, or operations, of any of the embodiments according to Figures 1 to 6H.

[0147] The techniques and methods described herein can be implemented by various means. For example, these techniques can be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. For hardware implementations, the apparatus(s) of the embodiments can be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or combinations thereof. For firmware or software, the implementation can be executed by a module (e.g., processes, functions, etc.) of at least one chipset performing the functions described herein. Software code can be stored in memory cells and executed by a processor. The memory cells can be implemented within or outside the processor. In the latter case, as is known in the art, it can be communicatively coupled to the processor via various means. Furthermore, the components of the systems described herein can be rearranged and / or supplemented by additional components to facilitate implementation of the various aspects described herein, and they are not limited to the precise configurations presented in the given figures as will be understood by those skilled in the art.

[0148] The described embodiments can also be performed as a computer process defined by a computer program or parts thereof. (Referring to Figures 1 to...) Figure 6HEmbodiments of the described methods can be performed by executing at least a portion of a computer program including corresponding instructions. The computer program may be in source code form, object code form, or some intermediate form, and it may be stored in a carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer or processor-readable computer program distribution medium. The computer program medium may be, for example, but not limited to, recording media, computer memory, read-only memory, electrical carrier signals, telecommunication signals, and software distribution packages. For example, the computer program medium may be a non-transitory medium. The software coding for performing the embodiments shown and described is entirely within the capabilities of those skilled in the art. In one embodiment, the computer-readable medium includes the computer program.

[0149] Although the invention has been described above with reference to examples in conjunction with the accompanying drawings, it is apparent that the invention is not limited thereto, but can be modified in various ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly, and they are intended to illustrate rather than limit the embodiments. It will be apparent to those skilled in the art that the concept of the invention can be implemented in various ways as technology advances. Furthermore, it will be understood by those skilled in the art that the described embodiments may, but do not necessarily, be combined with other embodiments in various ways.

Claims

1. An apparatus for communication, comprising at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to perform operations comprising: detecting a beam failure on at least one transmission / reception point, TRP, the apparatus being configured to communicate with a plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value, and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP; Based on the detecting, encoding beam failure indication data into a beam failure recovery (BFR) medium access control (MAC) control element (CE), wherein the beam failure indication data indicates the beam failure on the at least one TRP, wherein the beam failure indication data comprises: an information element indicating that the beam failure is a partial failure or another information element indicating a failed set of BFD-RSs; and sending the BFR MAC CE to a network element of a wireless communication network.

2. The apparatus of claim 1, wherein the BFR MAC CE is a BFR MAC CE, or a truncated BFR MAC CE.

3. The apparatus of claim 1, wherein the BFR MAC CE is a CE configured to indicate a beam failure of a primary cell of a master cell group or a primary secondary cell of a secondary cell group.

4. The apparatus of claim 1, wherein the BFR MAC CE is sent in a contention-based random access, CBRA, procedure.

5. The apparatus of claim 4, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising: triggering the CBRA procedure if the beam failure is detected on all of the plurality of TRPs, if the beam failure is detected on a default TRP, or if the beam failure is detected on a TRP configured to be monitored by the apparatus for beam failure; otherwise, not triggering the CBRA procedure to send the BFR MAC CE.

6. The apparatus of claim 1, wherein the BFR MAC CE is multiplexed to an available uplink grant, or to an uplink grant obtained via a functioning or non-failed TRP.

7. The apparatus of claim 1, wherein the apparatus is configured to monitor for a beam failure of a particular TRP of the plurality of TRPs.

8. The apparatus of claim 7, wherein the particular TRP is configured to the apparatus by the wireless communication network.

9. The apparatus of claim 7, wherein the particular TRP is a default TRP.

10. The apparatus of claim 1, wherein in the case of partial beam failure, the beam failure indication data comprises: an information element indicating an index value of a TRP associated with the partial beam failure.

11. The apparatus of claim 1, wherein in the case of partial beam failure, the beam failure indication data comprises: an information element indicating whether there are candidate beams that exceed a predetermined threshold.

12. The apparatus of claim 11, wherein if the information element indicates that no candidate beam exceeds the predetermined threshold, the beam failure indication data further comprises: an information element indicating an index of a TRP associated with the partial beam failure.

13. The apparatus of any of the preceding claims 1 to 12, wherein the beam failure indication data further comprises: an information element indicating candidate beams detected by the apparatus.

14. An apparatus for communication, comprising at least one processor and at least one memory including computer program code, where the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform operations comprising: configuring a user equipment, UE, of a wireless communication network to monitor beam failure on at least one of a plurality of transmission / reception points, TRPs, the UE being configured to communicate with the plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP, wherein the configuring causes the UE to encode beam failure indication data into a beam failure recovery, BFR, medium access control, MAC, control element, CE, and transmit the BFR MAC CE to the wireless network based on detecting a beam failure, the beam failure indication data indicating a beam failure on at least one TRP; obtaining the BFR MAC CE including beam failure indication data from the UE, wherein the beam failure indication data includes: an information element indicating that the beam failure is a partial failure or another information element indicating a failed set of BFD-RSs; and determining, based on the beam failure indication data, whether the UE experienced a partial beam failure and which set of BFD-RSs has failed.

15. The apparatus of claim 14, wherein the BFR MAC CE is a CE configured by the apparatus for indicating a failure of a primary cell of a primary cell group or a primary secondary cell of a secondary cell group.

16. The apparatus of claim 14, wherein the BFR MAC CE is configured to be transmitted in a contention-based random access, CBRA, procedure.

17. A method for communication performed by a user equipment, UE, of a wireless communication network, the method comprising: detecting a beam failure on at least one transmission / reception point, TRP, the UE being configured to communicate with a plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP; based on the detecting, encoding beam failure indication data into a beam failure recovery, BFR, medium access control, MAC, control element, CE, wherein the beam failure indication data indicates the beam failure on the at least one TRP, wherein the beam failure indication data comprises: an information element indicating that the beam failure is a partial failure or another information element indicating a set of beam failure detection, BFD, reference signals, BFD-RSs, that have failed; and sending the BFR MAC CE to a network element of the wireless communication network.

18. A method for communication performed by a network element of a wireless communication network, the method comprising: configuring a user equipment, UE, of the wireless communication network to monitor for a beam failure on at least one of a plurality of transmission / reception points, TRPs, the UE being configured to communicate with the plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP, wherein the configuring causes the UE to, based on detecting a beam failure, encode beam failure indication data into a beam failure recovery, BFR, medium access control, MAC, control element, CE, and send the BFR MAC CE to the wireless communication network, the beam failure indication data indicating the beam failure on at least one TRP; obtaining the BFR MAC CE including beam failure indication data from the UE, wherein the beam failure indication data comprises: an information element indicating that the beam failure is a partial failure or another information element indicating a set of BFD-RSs that have failed; and based on the beam failure indication data, determining whether the UE experienced a partial beam failure and which set of BFD-RSs has failed.

19. A computer program product embodied on a computer readable medium and comprising computer program code readable by a computer, wherein the computer program code configures the computer to perform a computer process comprising: detecting, by a user equipment, UE, of a wireless communication network, a beam failure on at least one transmission / reception point, TRP, the UE being configured to communicate with a plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP; Based on the detecting, encoding beam failure indication data into a beam failure recovery (BFR) medium access control (MAC) control element (CE), wherein the beam failure indication data indicates the beam failure on the at least one TRP, wherein the beam failure indication data comprises: an information element indicating that the beam failure is a partial failure or another information element indicating a set of BFD-RSs that have failed; and sending the BFR MAC CE to a network element of the wireless communication network.

20. A computer program product, embodied on a computer readable medium and comprising computer program code readable by a computer, wherein the computer program code configures the computer to perform a computer process comprising: configuring a user equipment, UE, of a wireless communication network to monitor for a beam failure on at least one of a plurality of transmission / reception points, TRPs, the UE configured to communicate with the plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value, and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP, wherein the configuring causes the UE to, based on detecting a beam failure, encode beam failure indication data into a beam failure recovery, BFR, medium access control, MAC, control element, CE, and transmit the BFR MAC CE to the wireless communication network, the beam failure indication data indicating a beam failure on at least one TRP; obtaining, from the UE, the BFR MAC CE comprising beam failure indication data, wherein the beam failure indication data comprises: an information element indicating that the beam failure is a partial failure or another information element indicating a set of BFD-RSs that failed; and and determining, based on the beam failure indication data, whether the UE experienced a partial beam failure and which set of BFD-RSs has failed.

21. An apparatus for communication, comprising means for performing operations comprising: detecting a beam failure on at least one transmission / reception point, TRP, the apparatus configured to communicate with a plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value, and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP; Based on the detecting, encoding beam failure indication data into a beam failure recovery (BFR) medium access control (MAC) control element (CE), wherein the beam failure indication data indicates the beam failure on the at least one TRP, wherein the beam failure indication data comprises: an information element indicating that the beam failure is a partial failure or another information element indicating a set of BFD-RSs that failed; and and transmitting the BFR MAC CE to a network element of a wireless communication network.

22. An apparatus for communication, comprising means for performing operations comprising: A user equipment, UE, configured for a wireless communication network to monitor for a beam failure on at least one of a plurality of transmission / reception points, TRPs, the UE configured to communicate with the plurality of TRPs, wherein each of the plurality of TRPs is associated with a CORESETPoolIndex value, and each CORESETPoolIndex value is associated with at least one set of beam failure detection reference signals, BFD-RSs, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one set of BFD-RSs associated with the TRP, wherein the configuration causes the UE to, based on detecting a beam failure, encode beam failure indication data indicating the beam failure on at least one TRP to a beam failure recovery, BFR, medium access control, MAC, control element, CE, and transmit the BFR MAC CE to the wireless communication network; obtaining, from the UE, the BFR MAC CE including beam failure indication data, wherein the beam failure indication data includes: an information element indicating that the beam failure is a partial failure or another information element indicating a failed set of BFD-RSs; and and determining, based on the beam failure indication data, whether the UE experienced a partial beam failure and which set of BFD-RSs has failed.

Images