Patent Description:
Modern wireless networks are capable of utilizing Multi-Transmission/Reception Point (M-TRP) schema. As such capabilities are increasing, there is a demand for providing solutions that enhance overall effectiveness of such capabilities. For example, it may be beneficial to provide solutions that relate to solving problems caused by beam failures in M-TRP scenario. Document <CIT> describes some aspects of beam failure detection and recovery.

According to an aspect, there is provided the subject matter of the independent claims. Some embodiments are defined in the dependent claims.

In the following some embodiments will be described with reference to the attached drawings, in which.

The following embodiments are examples.

In the following, different exemplifying embodiments will be described using, as an example of an access architecture to which the embodiments may be applied, a radio access architecture based on long term evolution advanced (LTE Advanced, LTE-A) or new radio (NR, <NUM>), without restricting the embodiments to such an architecture, however. A person skilled in the art will realize that the embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN or E-UTRAN), long term evolution (LTE, the same as E-UTRA), wireless local area network (WLAN or WiFi), worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet Protocol multimedia subsystems (IMS) or any combination thereof.

<FIG> shows terminal devices or user devices <NUM> and <NUM> configured to be in a wireless connection on one or more communication channels in a cell with an access node (such as (e/g)NodeB) <NUM> providing the cell. (e/g)NodeB refers to an eNodeB or a gNodeB, as defined in 3GPP specifications. The physical link from a user device to a (e/g)NodeB is called uplink or reverse link and the physical link from the (e/g)NodeB to the user device is called downlink or forward link. It should be appreciated that (e/g)NodeBs or their functionalities may be implemented by using any node, host, server or access point etc. entity suitable for such a usage.

A communications system typically comprises more than one (e/g)NodeB in which case the (e/g)NodeBs may also be configured to communicate with one another over links, wired or wireless, designed for the purpose. These links may be used not only for signalling purposes but also for routing data from one (e/g)NodeB to another. The (e/g)NodeB is a computing device configured to control the radio resources of communication system it is coupled to. The NodeB may also be referred to as a base station, an access point, an access node, or any other type of interfacing device including a relay station capable of operating in a wireless environment. The (e/g)NodeB includes or is coupled to transceivers. From the transceivers of the (e/g)NodeB, a connection is provided to an antenna unit that establishes bi-directional radio links to user devices. The antenna unit may comprise a plurality of antennas or antenna elements. The (e/g)NodeB is further connected to core network <NUM> (CN or next generation core NGC). Depending on the system, the counterpart on the CN side can be a serving gateway (S-GW, routing and forwarding user data packets), packet data network gateway (P-GW), for providing connectivity of user devices (UEs) to external packet data networks, or mobility management entity (MME), etc..

<NUM> enables using multiple input - multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and employing a variety of radio technologies depending on service needs, use cases and/or spectrum available. <NUM> mobile communications supports a wide range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications (such as (massive) machine-type communications (mMTC), including vehicular safety, different sensors and real-time control). <NUM> is expected to have multiple radio interfaces, namely below <NUM>, cmWave and mmWave, and also being capable of being integrated with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and <NUM> radio interface access comes from small cells by aggregation to the LTE. In other words, <NUM> is planned to support both inter-RAT operability (such as LTE-<NUM>) and inter-RI operability (inter-radio interface operability, such as below <NUM> - cmWave, below <NUM> - cmWave - mmWave). One of the concepts considered to be used in <NUM> networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

The current architecture in LTE networks is fully distributed in the radio and typically fully centralized in the core network. The low-latency applications and services in <NUM> require to bring the content close to the radio which leads to local break out and multi-access edge computing (MEC).

It should also be understood that the distribution of functions between core network operations and base station operations may differ from that of the LTE or even be non-existent. <NUM> (or new radio, NR) networks are being designed to support multiple hierarchies, where MEC servers can be placed between the core and the base station or node B (gNB).

Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (IoT) devices or for passengers on board of vehicles, or ensuring service availability for critical communications, and future railway, maritime, and/or aeronautical communications. Satellite communication may utilize geostationary earth orbit (GEO) satellite systems, but also low earth orbit (LEO) satellite systems, in particular mega-constellations (systems in which hundreds of (nano)satellites are deployed).

The network discussed herein may refer to, for example, cellular network such as <NUM> and the like.

UE may be capable of performing Beam Failure Recovery (BFR) either using Contention Free Random Access (CFRA) or Contention Based Random Access (CBRA). In CFRA BFR, the UE may be provided with dedicated Random Access (RA) preamble resources that may correspond to a specific downlink (DL) Reference Signal (RS) (i.e. a new candidate beam). CFRA BFR may therefore indicate network that a beam failure has been declared, UE has initiated recovery, and selected a new candidate beam. Further, Secondary Cell (SCell) BFR may be used so that in case of an SCell beam failure, UE may transmit a Medium Access Control (MAC) Control Element (CE) that may indicate network the failed SCell index and a further indication if a suitable candidate beam has been detected (e.g. the quality and/or received signal strength of the candidate beam exceeds a threshold level), and an index of the candidate beam RS in the candidate beam RS list. Transmission of MAC CE may be preceded by a transmission of dedicated SR signal that may indicate, on the SCell, beam failure event, but the MAC CE may also be multiplexed to any UL grant.

It is noted that when reference is made to BFR MAC CE it may refer to BFR MAC CE or to truncated BFR MAC CE or a MAC CE used for beam failure recovery. If reference is made explicitly to truncated BFR MAC CE, the reference may be applicable to truncated BFR MAC CE, but not necessarily to BFR MAC CE. <FIG> shows an example of a BFR and truncated BFR MAC CE with single octet bitmap and <FIG> shows an example of a BFR and truncated BFR MAC CE with four octets bitmap. These Figures are used as examples to describe some of the features and data structure of the BFR MAC CEs utilized in the context of this application. In general, the below described MAC CEs may be used to indicate SpCell failure. Skilled person understands that SpCell may refer to a primary cell of a master cell group or a primary secondary cell of a secondary cell group. It is further noted that PCell may refer to SpCell of a master cell group and PSCell may refer to SpCell of a secondary cell group.

The BFR MAC CEs may be identified by a MAC subheader with Logical Channel ID (LCID)/eLCID. BFR MAC CE may have a variable size. It may include a bitmap and in ascending order based on the ServCellIndex, beam failure recovery information i.e. octets containing candidate beam availability indication (AC) for SCells indicated in the bitmap.

For BFR MAC CE, a single octet bitmap may be used when the highest ServCellIndex of this MAC entity's SCell for which beam failure is detected is less than <NUM>, otherwise four octets may be used.

For Truncated BFR MAC CE, a single octet bitmap (see example of <FIG>) may be used for the following cases, otherwise four octets (see example of <FIG>) may be used:.

The fields in the BFR MAC CEs may be defined as follows with reference to <FIG>:.

However, it is noted that presently the AC, R, Candidate RS ID byte (i.e. AC, R, and Candidate RS ID fields) are not present when indicating BFR on SpCell. there is no such information encoded into the BFR MAC CE for SpCell.

The described network (e.g. <FIG>) may further support utilizing multiple transmission points (TRPs) (i.e. Multi-Transmission/Reception Point (M-TRP)). M-TRP may support, for example, up to two (<NUM>) TRPs, but the number of TRPs may not be limited to two. Thus, for example, the UE <NUM>, <NUM> may receive data via a plurality of TRPs. The different TRPs could be controlled, for example, by the network node <NUM>. Example of such as system is given in <FIG> which may be understood to depict the same system as <FIG>, but with greater accuracy with respect to the M-TRP scenario. The M-TRP operation may be implemented in such a manner that instead of explicitly indicating the TRP identifier (ID), the CORESETs may be associated to specific TRPs using a CORESETPoolIndex parameter [<NUM>. CORESETs within a Physical Downlink Control Channel (PDCCH)-config that have the same poolIndex may be assumed by the UE to be configured to be provided from the same TRP. Referring to <FIG>, TRPs with CORESETPoolIndex <NUM> and <NUM> are shown, wherein the TRP having CORESETPoolIndex <NUM> provides three beams (RS#<NUM>, RS#<NUM>, and RS#<NUM>) and the TRP having CORESETPoolIndex <NUM> provides two beams (RS#<NUM>, and RS#<NUM>). M-TRP may also be configured for inter-cell scenario i.e. the TRPs (sometimes referred to as inter-cell M-TRP) may be associated with different cells. In inter-cell M-TRP UE may be provided a configuration where the CORESETs of CORESETPoolIndex/TRP are provided by multiple cells (e.g. two). In some examples, UE may be explicitly configured with CORESETs with more than one (e.g. two) distinct CORESETPoolIndex values that CORESETs or the CORESETpoolIndex is associated with another cell than the current serving cell (e.g. associating a CORESET/Poolindex with a Physical Cell Identity (PCI)). In some examples, UE may determine that it is configured with inter-cell (M-TRP) communication when the downlink reference signal indicated by an activated TCI State for PDCCH/PDSCH for a CORESET is associated or the quasi co-location (QCL) (source of the signal is associated with a PCI other than the current serving cell. These should be understood as illustrative examples.

However, although M-TRP operation has been introduced and techniques for BFR indication exist, there has been no developments in increasing the usability M-TRP with respect to beam failure detection and/or BFR with respect to M-TRP. For example, if one of the beams (i.e. having RS#<NUM>, RS#<NUM>, RS#<NUM>, RS#<NUM>, or RS#<NUM>) fails, an efficient and reliable concept of how it is indicated to the network is missing. For example, if UE <NUM> (e.g. configured for PDCCH reception and/or configured for beam failure detection) is served via beams RS#<NUM> and RS#<NUM> and RS#<NUM> fails, the UE <NUM> may determine that is has experienced failure on subset of beams. This may be referred to as partial beam failure. It may be possible to recover from such partial beam failure by utilizing beams RS#<NUM> or RS#<NUM>. However, there is no known process for this and typically all the beams configured for failure detection have to be in failure condition for the recovery process to be initiated. When all beams (i.e. all the Beam Failure Detection Reference Signal (BFD-RS) or all the reference signals in the failure detection set, i.e. in the set q0) are in failure condition it may be referred to as beam failure or in some cases full failure or full beam failure.

In another example, if UE is configured to monitor beam failure on one or more beam failure detection resource sets (e.g. BFD-RS set#<NUM> and set#<NUM>) and all the RS in all the sets are in failure condition, UE may determine that full beam failure has occurred/detected. In another example, if UE experiences failure on set#<NUM> it may determine a partial failure or a failure on set#<NUM>. In some cases, if a failure is detected on set#<NUM> UE may declare partial failure. In some cases, if a failure is detected on set#<NUM> (but not on#<NUM>) UE may declare partial failure but if the failure is detected only on set#<NUM> UE may not declare partial failure. Further, beam failure may happen if both RS#<NUM> and RS#<NUM> fail. It may also be possible to recover from this via RS#<NUM>/<NUM> and RS#<NUM>. Again, no process for this has yet been described. Hence, there is provided a solution for M-TRP beam failure indication or for a failure indication where a subset of failure detection reference signals are determined to be in failure condition (e.g. based on hypothetical PDCCH BEER) or for failure where at least one of the beams (e.g. PDCCH beams, or beam failure detection reference signals) associated with a CORESET(s) of a specific CORESETPoolIndex are in failure or have failed. The solution enables the use of unused, or re-interpret specific or define specific, BFR MAC CE fields for SpCell for encoding indication about beam failure on at least one TRP amongst a plurality of TRPs. It should be noted that, in general, the described methods may be used for any MAC CE, MAC CE for beam failure recovery, PUCCH or PUSCH signaling used for failure recovery or indication of a failure. This may improve communication efficiency, and help the UE to recover more efficiently from a beam failure situation. For example, instead of indicating only that the whole cell has failed, the UE may indicate on the presently unused resources that one or many of TRPs, utilized by the UE, have failed. These TRPs may be provided via one or more cells. Hence, the accuracy of the indication and therefore the efficiency of the recovery may be enhanced from the known solutions which do not address M-TRP beam failure indication and recovery at all. It should be further noted that any method herein may also be used for failure recovery (according to the embodiments herein) for one or more SCell(s). In some examples, the failure may be indicated for both SpCell and one or more SCells or simply any method herein can be used for failure indication and/or providing additional information on the failure (e.g. failed TRP, candidate beam information, full/partial failure). Any of the embodiments herein may describe a method for: indicating the failure, recovering from the failure, or both.

<FIG> illustrates a flow diagram according to an embodiment. Referring to <FIG>, a method for a UE of a wireless communication network is provided, the method comprising: detecting a beam failure on at least one TRP, the UE being configured to communicate with a plurality of TRPs (block <NUM>); based on the detecting, encoding a beam failure indication data to a BFR MAC CE, wherein the beam failure indication data indicates the beam failure on the at least one TRP (block <NUM>); and transmitting the BFR MAC CE to a network element of the wireless communication network (block <NUM>).

<FIG> illustrates a flow diagram according to an embodiment. Referring to <FIG>, a method for a network element of a wireless communication network is provided, the method comprising: configuring a UE of the wireless communication network to monitor beam failure on at least one of a plurality of TRPs, the UE being configured to communicate with the plurality of TRPs, wherein the configuring causes the UE to encode, based on detecting a beam failure, beam failure indication data indicating a beam failure on at least one TRP (or a failure detection resource set) to a BFR MAC CE, and to transmit the BFR MAC CE to the wireless network (e.g. to the network element that configures the UE or to some other network element) (block <NUM>).

The described methods of <FIG> may be applicable in the system(s) of <FIG>, for example. The UE discussed with respect to <FIG> may be, for example, UE <NUM>, or UE <NUM>, or some other similar network device. The network element discussed with respect to <FIG> may refer to network node <NUM>, for example. TRPs may, for example, be controlled and/or utilized by the network node <NUM> to realize the M-TRP communication to the UE <NUM> or UE <NUM>. The proposed solution enables the UE to indicate, in M-TRP scenario, beam failure so that, for example, the BFR MAC CE indicates the specific TRP or TRPs that has/have failed. In some examples the BFR MAC CE may be used to indicated that specific set of failure detection resources (BFD-RS), that may be associated with one or more TRPs, have failed. For example, if two TRPs are utilized by the UE, and one the TRPs is associated with beam failure (e.g. beam provided by the TRP and used by the UE fails), the BFR MAC CE may indicate that particular failed TRP. Hence, BFR can be readily triggered so that, for example, another beam of the same TRP is configured for the UE. It is noted that in such case, the UE may not totally loose communication to the network as, for example, another one of the two TRPs may still work as needed (i.e. is not associated with a beam failure). Hence, the BFR MAC CE may be transmitted via the other TRP or it is possible to perform random access procedure, such as CBRA, by the UE and to transmit the BFR MAC CE in the random access procedure. It is also possible to utilize the proposed solution to indicate that all TRPs (e.g. in the case that two TRPs are used) are associated with a beam failure, i.e. all TRPs have failed. In all cases it may be possible to indicate candidate beams (e.g. indicate RS index) by the UE to network (e.g. network element) in the BFR MAC CE so that the BFR can be performed also in the case that all TRPs fail.

At this point it is noted that the proposed solution is not limited to any specific method for determining a TRP associated failure. As an example of failure detection strategies that may take into account determining a beam failure in M-TRP scenario, UE may be configured, by the network, with a TRP specific set of q0 (i.e. failure detection resources; e.g. q0_#<NUM> may equal to RSs of a certain TRP (e.g. having CORESETPoolIndex <NUM> in <FIG>) and q0 #<NUM> may equal to RSs of a certain other TRP (e.g. having CORESETPoolIndex <NUM> in <FIG>)) and/or single q0 but indication may be determined based on the subset of RS in the set. In addition, there may be two failure detection procedures at MAC layer, one for each CORESETPoolIndex if two CORESETPoolIndex exists. If the number is higher, the number of procedures may also be higher, i.e. each TRP may be monitored for failure. In some examples the failure detection resources (e.g. a resource set) for a TRP or a CORESETPoolIndex may be determined based on the RS indicated by the activated TCI States for PDCCH (i.e. PDCCH beams) for a respective CORESET that is associated with a specific CORESETPoolIndex. Failure detection resource set, per CORESETPoolIndex or across CORESETPoolindexes may include one or more RS. After (or in response to) UE has determined a TRP specific failure at MAC layer, e.g. based on the set of q0_TRP0 and q0_TRP1 or has determined (partial) beam failure based on any TRP/CORESETPoolIndex specific failure detection mechanism, UE may trigger the TRP failure indication as explained above with respect to <FIG>. The triggering the TRP failure indication may comprise, for example, steps <NUM> and <NUM> of <FIG> or any embodiments thereof. Regarding step <NUM>, the transmission of the BFR MAC CE (sometimes referred to simply as MAC CE herein) may be performed as a part of CBRA. That is, the BFR MAC CE may be transmitted in Msg3 of the CBRA, or in MsgA in <NUM>-step RACH, for example. Alternatively, the UE may multiplex the BFR MAC CE to an UL grant. The UL grant may refer to available UL grant or to an UL grant obtained via functional TRP. For example, if one of the TRPs fail, a further UL grant may be obtained via the remaining TRP, for example. In some examples, UE may determine to select the random access resources on the failed TRP. In some examples, an association of e.g. CBRA resources and/or SSBs with a specific TRP may be provided for UE and may be used in random access resource selection. As an example UE may select any random access resources for providing the BFR MAC CE or it may select the random access resources associated with the failed TRP.

In one embodiment, in case of a partial beam failure, the UE transmits the BFR MAC CE on an UL grant or available UL resources (e.g., uplink shared channel (UL-SCH) resources). However, if UL grant/resources is not available, the UE may trigger Scheduling Request (SR) procedure. This way the UE may obtain resources for transmitting the BFR MAC CE if no UL grant(s) are available. In an embodiment, the UE uses the BFR SR resource associated with SCell BFR for requesting UL resources to transmit the BFR MAC CE. The BFR MAC CE may include the beam failure indication data indicating partial beam failure. For example, in full beam failure the UE may initiate the random access procedure. It is also possible to utilize the random access procedure in partial failure. In some cases it may be beneficial to utilize either existing UL grant or request resources, for example, with SR procedure.

In an embodiment, the UE is configured to perform operations comprising: triggering the transmission of BFR MAC CE (e.g. using CBRA procedure or a scheduling request procedure) if the beam failure is detected on all of the plurality of TRPs, if the beam failure is detected on a default TRP (e.g. CORESETPoolIndex equals <NUM>), or if the beam failure is detected on a TRP configured (i.e. the network may configure this too be, for example, CORESETPoolIndex equals <NUM> or <NUM>) to be monitored, by the UE, for a beam failure. ; BFR MAC CE may be transmitted, for example, using the UL grant as explained above, if not available, the CBRA process may be triggered to transmit the BFR MAC CE. e In one example, UE may use available UL grant to transmit the MAC CE (or PUSCH signaling for BFR) if the UL grant is transmitted on uplink resources associated with non-failed TRP.

It is noted that transmitting the BFR MAC CE in CBRA procedure may also be used in case of partial failure. For example, the UE may select resources from failed TRP, and thus indicate a new candidate via the CBRA procedure.

In an embodiment, the UE is configured to perform operations comprising: triggering the CBRA process 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 UE, for a beam failure. In a further embodiment, the UE may not trigger the CBRA process to transmit the BFR MAC CE.

<FIG> illustrates a signal diagram according to an embodiment. Referring to <FIG>, in block <NUM>, the network node <NUM> may configure UE <NUM> for M-TRP beam failure indication. This configuration may be similar as discussed with reference block <NUM>. That is, the network may indicate to the UE <NUM> how the UE <NUM> should monitor beam failure and how beam failure should be indicated if such failure is detected. As discussed above, the configuration may comprise, for example, configuring the UE to indicate full beam failure (i.e. beam failure is detected on all the TRPs) and partial beam failure (i.e. beam failure is detected on one of the TRPs). The network configuration may, for example, further comprise indication of what or which TRP(s) the UE should monitor for partial failure. For example, the network may configure the UE <NUM> to monitor default TRP (sometimes referred to as primary TRP), and/or to indicate partial failure with respect to the default TRP. Default TRP may refer to a CORESETPoolIndex configuration where in case a CORESETPoolIndex is not provided for a respective CORESET, a specific value such as '<NUM>' is used for that CORESET. Alternatively, such value may also be configured or agreed to be '<NUM>'. So, for example, the network may configure the UE <NUM> to indicate partial failure on CORESETPoolIndex=<NUM>. It may alternatively be possible that the network configures the UE <NUM> to monitor non-default TRP and/or to indicate partial failure with respect to the non-default TRP. So, for example, the network may configure the UE <NUM> to indicate partial failure on CORESETPoolIndex=<NUM>.

Based on the configuration received from the network node <NUM> or some other network element, the UE <NUM> may perform the M-TRP beam failure detection, monitoring and/or indication. In block <NUM>, the UE <NUM> may detect beam failure (e.g. either full or partial failure). Based on the detection of block <NUM>, the UE <NUM> may carry the encoding beam failure indication data to BFR MAC CE as shown in block <NUM>.

In block <NUM>, the BFR MAC CE may be transmitted from the UE to the network. In <FIG>, the BFR MAC CE is transmitted to the network node <NUM>. The transmission may be performed as a part of random access procedure (e.g. in Msg3 of CBRA) or using available or obtainable UL grant as was discussed above.

For example, if full beam failure is detected in block <NUM>, in block <NUM> the UE <NUM> may encode the BFR MAC CE so that it indicates full beam failure. For example, if partial beam failure is detected in block <NUM>, in block <NUM> the UE <NUM> may encode the BFR MAC CE so that it indicates the partial beam failure. In such case, the BFR MAC CE may indicate, for example, CORESETPoolIndex of the TRP associated with the beam failure (e.g. <NUM> or <NUM>). Or, for example, if the network has configured the UE <NUM> to indicate partial failure on a certain CORESETPoolIndex (e.g. <NUM> or <NUM>), the BFR MAC CE may simply indicate partial failure, and the network may determine to which TRP the beam failure relates to based on the previously made configuration.

It was briefly addressed above that the network may configure the UE <NUM> for encoding the beam failure indication data into the BFR MAC CE. For example, with reference to <FIG>, this beam failure indication data may be encoded into one or more of the following fields of the BFR MAC CE: AC, R, and Candidate RS ID or R bits. As noted above, the BFR MAC CE may refer to non-truncated BFR MAC CE or to truncated BFR MAC CE. How the different field(s) are encoded is discussed in further detail with the help of some examples shown in <FIG> later. The presence of the fields for SpCell dependent on the partial beam failure detection (BFD) being configured for the UE. , if the partial BFD has not been configured, the fields are not encoded, while if the partial BFD is configured, the fields are encoded. In another example, when UE has been configured with multi-TRP or inter-cell M-TRP the fields for SpCell are encoded. In another example, when UE configured with, more than one distinct or with two distinct values of CORESETPoolIndexes, the field(s) are encoded. In yet another example when UE configured to perform failure detection on TRP basis, on CORESETPoolIndex basis or sub-set of BFD-RS (where there may be more than one set of failure detection resources) the fields are encoded. However, in an embodiment, the BFR MAC CE that is used to carry the beam failure indication data is a BFR MAC CE configured for indicating a failure of SpCell. Previously, said fields (i.e. AC, R, and Candidate RS ID or R bits) have been unused. The proposed solution therefore extends the usability of the BFR MAC CE for SpCell failure indication by utilizing the unused field(s) for indicating additionally beam failure per TRP or TRPs. It is also noted that although the present solution enables the use of the BFR MAC CE for SpCell failure indication for TRP related beam failure, the BFR MAC CE may also be used for the original purpose of indicating SpCell failure. For example, this can be made by encoding specified data into SP field of the BFR MAC CE (see e.g. <FIG>).

In any of the embodiments, the BFR MAC CE bit fields for SpCell, instead of referring to CORESETPoolIndex value or a TRP ID, the field or field(s) may point to a failure detection resource set. As an example, in case UE is configured to perform failure detection based on set #<NUM> of BFD-RS and set # <NUM> of BFD-RS, the field may indicate the failed set. As an example, in the failed set, all the RS need to be in failure condition to declare beam failure (or L1 to indicate beam failure instance indication to higher layer such as MAC). The BFD-RS sets may be associated respectively with TRP/CORESETPoolIndex (e.g. <NUM> and <NUM>). In some examples, UE may be configured with multiple failure detection sets although only one CORESETPoolIndex is configured. As an example UE may be configured to perform failure detection on the BFD-RS that are assumed to be monitored from the same TRP (i.e. CORESETs are configured with same CORESETPoolIndex).

So, the network may configure the UE <NUM> at least with two different ways. In one embodiment, the network configures the UE <NUM> for encoding the beam failure indication data into the BFR MAC CE by configuring the UE <NUM> to indicate beam failure related to multiple TRPs (and hence multiple CORESETPoolIndexes as each TRP may correspond to a certain CORESETPoolIndex) and/or at least one TRP. So, the network may configure the UE <NUM> to perform full and/or partial beam failure indication.

In an embodiment, the UE is configured by a higher layer parameter (e.g. PDCCH-Config) for full and/or partial beam failure indication. For example, the PDCCH-Config may comprise two or more different values of CORESETPoolIndex in ControlResourceSet. Configuring may be performed by the network.

As also briefly discussed above, the configuring by the network may refer to configuring by the cellular network of <FIG>. Such configuration may be implemented by one or more network elements, such as the network node <NUM>.

As addressed above, each TRP may be associated with a certain CORESETPoolIndex value or more specifically the CORESET configured with same PoolIndex are assumed from UE perspective to share same or similar properties e.g. transmitted from the same TRP. However, this does not mean necessarily that the network has to indicate a certain CORESETPoolIndex value or certain TRP to the UE to monitor. Instead the network may indicate to the UE that certain control resource sets that have the same CORESETPoolIndex share specific properties and UE may determine that M-TRP is configured when there are more than one or at least two distinct values of CORESETPoolIndexes configured. According to an embodiment, the UE encodes the beam failure indication data to the BFR MAC CE if it has been configured with more than one CORESETPoolindex values and BFR is detected. In an alternative example, UE encodes the indication data when it has been configured with more than one failure detection resource sets (e.g. two). These failure detection resource sets may be associated with TRPs/CORESETPoolIndexes of a cell (intra-cell multi-TRP) or multiple cells (e.g. inter-cell multi-TRP). Multiple failure detection resource sets may also be configured for single TRP/CORESETPoolIndex failure detection. So, if the UE has been configured by the network with two or more CORESETPoolindex values (or failure detection resource sets), the UE may encode said data into the BFR MAC CE as explained e.g. with respect to <FIG>. The two CORESETPoolindex values should be different to each other. If on the other hand, the network configures the UE with one CORESETPoolindex value (i.e. not more than one CORESETPoolindex value or not more than one failure detection resource set), the UE may encode the BFR MAC CE so that it indicates a cell level failure (i.e. all beams associated with said one CORESETPoolIndex or a failure detection resource set fail) and the beam failure indication data fields may not be encoded at all (e.g. UE indicates only that SpCell has failed using the indication in the bitmap without any candidate information.

In one embodiment, the UE encodes the beam failure indication data to the BFR MAC CE if the UE is configured with more than one CORESETPoolIndex values and at least one of the CORESET or at least one of the CORESETPoolIndex is associated with PDCCH reception from a non-serving cell. This may mean that the proposed solution may be utilized in inter-cell scenario.

<FIG> illustrates an embodiment. Referring to <FIG>, AC <NUM>, R <NUM>, and candidate RS ID <NUM> fields are shown as illustrative examples. These fields may be similar as described above with reference to <FIG>, i.e. fields comprised in the BFR MAC CE. It is noted that the proposed solution does not necessarily require the specific fields <NUM>-<NUM>, and that similar solution may be realized with generic bit, bits, byte, and/or bytes. Hence, hereinafter field <NUM> is referred to as a second information element, field <NUM> is referred to as a first information element and field <NUM> is referred to as third information element. <FIG>, <FIG>, <FIG>, and <FIG> illustrate some example embodiments of different ways to encode the beam failure indication data into the BFR MAC CE or similar entity. In the different example embodiments, it is noted that SP field of the BFR MAC CE may still be used to indicate failure on the cell level (e.g. current SpCell failure) or that there has been a TRP/CORESETPoolIndex/failure detection resource set specific failure for SpCell. In case of SCell failure in multi-TRP as described in the different example embodiments, UE may indicate the failed SCell index and encode additional indication data as described herein.

According to an embodiment, with reference to <FIG>, the beam failure indication data comprises a first information element <NUM> indicating whether the beam failure is full or partial. For example, the indication may be realized with one bit (e.g. <NUM> for full beam failure or <NUM> for partial beam failure). So, for example, if full failure is detected by the UE, said field <NUM> may not be set (thus may equal to <NUM>), and thus the network may assume that full failure has occurred. As shown in <FIG>, fields <NUM> and <NUM> may not be encoded. However, in some embodiments they may be used of which some examples are given below. According to an embodiment, the network node <NUM> configures the UE to indicate whether full or partial beam failure has occurred. The indication may be performed by indicating the full or partial beam failure with the first information element <NUM> as explained above.

In an embodiment, the UE is configured (e.g. by the network node <NUM>) to monitor beam failure of a specific TRP amongst the plurality of TRP, and wherein the first information element <NUM> indicates either full beam failure or beam failure of the specific TRP. So, for example, network may configure the UE to monitor beam failure related to a certain CORESETPoolIndex, and UE may report partial failure related to that CORESETPoolIndex. Failure may be declared based on BFD-RS associated with the CORESETS of the CORESETPoolIndex.

In an embodiment, said specific TRP is configured by the wireless communication network to the UE. the network may select the UE to monitor default or non-default TRP (e.g. BFD-RS associated with CORESETs of CORESETPoolIndex <NUM> or <NUM>).

In an embodiment, said specific TRP is default TRP even if the network does not explicitly configure the UE to monitor default TRP. Hence, in this embodiment, the partial failure may be always the TRP associated with CORESETPoolIndex = <NUM> or in other words, UE considers the partial failure detection based on the RS indicated by the active Transmission Configuration Indicator (TCI) State(s) for CORESETPoolindex = <NUM>.

In an embodiment, the UE is configured to report partial failure only on the CORESETs associated with CORESETPoolIndex equaling <NUM> or <NUM>. Hence, in this embodiment, the UE does not indicate partial failure on both CORESETPoolIndexes.

According to an embodiment, with reference to <FIG>, in case of a partial beam failure, the beam failure indication data comprises a second information element <NUM> (i.e. in addition to the first information element <NUM> indicating partial failure) indicating an index value of a TRP/CORESETPoolIndex associated with the partial beam failure. This index value may be the CORESETPoolIndex, for example. The CORESETPoolIndex value may be indicated, for example, with a bit if there are two TRPs that monitored for partial failure (i.e. <NUM> for one CORESETPoolIndex and <NUM> for another CORESETPoolIndex). If there are more CORESETPoolIndexes (and hence more TRPs), more than one bit may be used. It may be beneficial to indicate the CORESETPoolIndex as the network may not necessarily know to which CORESETPoolIndex the partial beam failure is related to. For example, the UE may thus indicate partial beam failure on CORESETPoolIndex equalling <NUM> or <NUM>. In an embodiment, the second information element <NUM> indicates presence of a third information element <NUM> in the BFR MAC CE. Hence, the second information element does not necessarily indicate the CORESETPoolIndex value. In this embodiment, the third information element <NUM> may further indicate an index of a candidate beam for the failed CORESETPoolIndex that has been detected by the UE. Based on this information, the network may implicitly be indicated about the failed TRP also. The network may determine association between the candidate beam identifier and the failed TRP based on stored information, for example.

In an embodiment, with reference to <FIG>, in case of a partial beam failure, the beam failure indication data comprises a second information element <NUM> indicating whether there is a candidate beam exceeding a predetermined threshold. Predetermined threshold may be for example Reference Signal Receive Power (RSRP) threshold or Signal-to-interference-plus-noise ratio (SINR) threshold. Threshold may be configured by network, for example. This indication may be either <NUM> or <NUM>, for example (i.e. one bit indication). As discussed in the previous embodiment, the third information element <NUM> may thus indicate one or more candidate beam identifiers for CORESETPoolIndex that is associated with the partial beam failure.

According to an embodiment, with reference to <FIG>, if the second information element <NUM> indicates (e.g. bit is <NUM>) no candidate beam exceeding the predetermined threshold, the beam failure indication data further comprises a third information element <NUM> indicating an index of a TRP (or CORESETPoolIndex) associated with the partial beam failure. So, for example, in case the AC field is set to zero (i.e. no candidates that are associated with failed TRP, and with quality above the threshold) UE may encode at least one bitfield to indicate the failed TRP (e.g. first or last or any bit in the third information element <NUM>) may be set to the value of failed TRP/CORESETPoolIndex.

So, in <FIG> there was at least one candidate beam and this may be indicated, by the UE to the network, by setting field <NUM> to <NUM> and indicating the one or more candidates in field <NUM>. However, field <NUM> may be set to <NUM> if there are no candidates, and in this case field <NUM> may be used to indicate the TRP/CORESETPoolIndex that is associated with the partial beam failure. For example, one bit of the field <NUM> may be used. In general, the third information element may comprise a plurality of bits that can be used for indication purposes. For example, fields <NUM>-<NUM> may equal to one byte.

In an embodiment, if the SSB association to TRP/CORESETPoolIndex is known by the UE, UE selects CBRA resources corresponding to the failed TRP/CORESETPoolIndex and transmits the BFR MAC CE in Msg3 or in MsgA of <NUM>-step RACH. The network may determine that the selected SSB is an implicit candidate for the TRP/CORESETPoolIndex. In such case there may be no need to transmit indication about the failed TRP/CORESETPoolIndex as it may be implicitly indicated to the network. In another embodiment, if the SSB association to TRP/CORESETPoolIndex is known by the UE, UE selects the CBRA resources on the non-failed (or functional) TRP/CORESETPoolIndex and indicates in the third information element <NUM> any SSB of the failed TRP/CORESETPoolIndex. This may also be understood, by the network, as an implicit indication about the failed TRP/CORESETPoolIndex. Candidate RS ID may be indicated implicitly if SSB association (or CSI-RE of DL-RS association) to a TRP is provided by the network to the UE. UE may select any SSB for the indication purpose. For example, if UE has been provided with association of random access resource/DL-RS that correspond to the RACH resource with a specific TRP/CORESETPoolIndex it may determine to select new candidate beam from the failed TRP based on said association. For example, the selected SSB may exceed a thre shold value for it to be selected by the UE.

In an embodiment, with reference to <FIG>, the third information element <NUM> may not be encoded, and after successful delivery of the BFR MAC CE, UE is not required, by the network, to monitor CORESETs associated with the failed TRP/CORESETPoolIndex until reconfigured with new TCI states.

Alternatively, the UE may indicate the TRP/CORESETPoolIndex/failure detection resource set (e.g. in field <NUM>) for which the failure was declared when it indicates the partial failure. Additionally, the field (i.e. field <NUM>) may indicate a candidate RS for the failed TRP/CORESETPoolIndex.

In an embodiment, in any of the methods herein, UE indicates candidate RS (i.e. new candidate beam e.g. in field <NUM>) with one or more of the following: Downlink RS, an SSB (or CSI-RS) index, TRP/CORESETPoolIndex specific RS index, an DL RS listed in a candidate RS list, a candidate listed in TRP specific candidate RS list.

In an embodiment, with reference to <FIG> and <FIG>, a second information element <NUM> (e.g. one bit) is used to indicate full or partial beam failure (<NUM>/<NUM>) on a given TRP/CORESETPoolIndex. In such case, a first information element <NUM> (e.g. one bit) may be used to indicate failed TRP/CORESETPoolIndex/failure detection resource set or whether or not there is a candidate beam exceeding a threshold available for the UE. In the example of <FIG>, second information element is used to indicate the TRP/CORESETPoolIndex/failure detection resource set. It is further possible to indicate candidate(s) in the third information element <NUM> (e.g. <NUM> bits) as shown in <FIG>. For example, the UE may be configured with candidate RS list or the SSBs or CSI-RS are associated with a TRP/CORESETPoolIndex/failure detection resource set. The network may thus determine the partial beam failure (i.e. which TRP/CORESETPoolIndex/failure detection resource set has failed) based on the association of the indicated candidate RS. Alternatively, if the second information element <NUM> is set to zero to indicate no candidate, at least one of the bits in the third information element <NUM> may encode the failed CORESETPoolIndex/failure detection resource set (i.e. indicate the failed TRP).

It is noted at this point that the UE may ignore the pending SCell failure indication when indicating partial SpCell failure (either full or partial beam failure). That is, UE may not be required to report SCells that are in failure and may report the Scell failure in subsequent MAC CE.

Furthermore, above it was discussed that in some examples the UE may know or determine the SSB or CSI-RS to TRP/CORESETPoolIndex/failure detection resource set association. This association may be obtained from the network, for example, via Radio Resource Control (RRC) signaling and/or MAC CE. This RRC signaling may be specific RRC signaling, for example. For example, if there are <NUM> SSBs in a cell, SSB indexes #<NUM> and #<NUM> may be indicated to be associated with TRP0/recovery resources for CORESETPoolIndex equaling <NUM>, and SSB indexes #<NUM> #<NUM> respectively for TRP1/recovery resource for CORESETPoolIndex equaling <NUM>. In some examples it is possible that the SSBs belong to another cell (i.e. not serving cell), and thus the proposed solution may be applicable also for inter-cell M-TRP. For the network side, with reference to <FIG> and <FIG>, the network node <NUM> may obtain the BFR MAC CE from the UE <NUM> with certain specific beam failure indication data. In one example, based on the first information element <NUM> in the beam failure indication data, the network node <NUM> may determine whether the UE has experienced partial or full beam failure.

In another example, if the first information element <NUM> indicates partial beam failure, the network node <NUM> may determine, based on a second information element <NUM> and/or a third information element <NUM> comprised in the beam failure indication data, a TRP/CORESETPoolIndex associated with the beam failure. Based on this information, the BFR may be continued or initiated by the network node <NUM>.

The following list some example embodiments.

In an embodiment, when UE has determined a TRP specific failure at MAC layer, e.g. based on the set of q0_TRP0 and q0_TRP1 or has determined partial beam failure based on any TRP/CORESETPoolIndex specific failure detection mechanism, UE may trigger the TRP failure indication using, e.g., Random Access procedure in which the CBRA can be performed to recover from beam failure using the BFR MAC CE specified for SpCell failure.

In an embodiment, if multiple TRPs/CORESETPoolIndex(es) or partial beam failure detection is configured for the UE or, if a UE is configured by higher layer parameter PDCCH-Config that contains two different values of CORESETPoolIndex in ControlResourceSet, the additional byte for additional BFR information (i.e. the byte containing the SpCell AC, R and Candidate RS ID fields is present, or at least one byte carrying partial/multiTRP specific failure recovery information) for SpCell is present/encoded.

In an embodiment, UE encodes the fields according to the embodiments of this invention when it has been configured with more than one CORESETPoolindex values (UE is configured with multi-TRP so that at least <NUM> CORESETs on the active DL BWP have different CORESETPoolIndex values). in other words, when UE is configured with one CORESETPoolIndex, or is not configured with more than one CORESETPoolIndex, it encodes the (Truncated) BFR MAC CE as in section <NUM>.

In an embodiment, the partial failure may be always the TRP associated with CORESETPoolIndex '<NUM>' or in other words, UE considers the partial failure detection based on the RS indicated by the active TCI State(s) for CORESETPoolindex '<NUM>'. As related example embodiment, UE is configured to report partial failure only on the CORESETs associated with CORESETPoolindex '<NUM>' or '<NUM>'.

In an embodiment, when the UE reports the CORESETPoolIndex specific SpCell failure using a (Truncated) BFR MAC CE, UE could encode the MAC CE as follows (the additional byte is present carrying the SpCell specific information:.

In an embodiment, UE may ignore the pending SCell failure indication when indicating partial SpCell failure i.e. it is not required to report SCells that are in failure and may report the Scell failure in sub sequent MAC CE.

In an embodiment, UE may be given the SSB association to a TRP for partial/TRP specific failure recovery in a specific RRC configuration:.

In an embodiment, the methods described herein are applied when UE is configured with more than CORESETPoolIndex values and at least one of the CORESETS in a CORESETPoolIndex is associated with PDCCH reception from a non-serving cell (inter-cell MTRP).

In an embodiment, when the UE declares partial beam failure, it triggers BFR for SpCell and attempts to map the (Truncated) BFR MAC CE on an UL grant, if available; otherwise the UE triggers Scheduling Request procedure. In one option the UE can use the BFR SR resource associated with SCell BFR for requesting UL resources to transmit the BFR MAC CE with partial beam failure information.

<FIG> and <FIG> provide apparatuses <NUM>, <NUM> comprising a control circuitry (CTRL) <NUM>, <NUM>, such as at least one processor, and at least one memory <NUM>, <NUM> including a computer program code (software) <NUM>, <NUM>, wherein the at least one memory and the computer program code (software) <NUM>, <NUM>, are configured, with the at least one processor, to cause the respective apparatus <NUM>, <NUM> to carry out any one of the embodiments of <FIG>, or operations thereof.

Referring to <FIG> and <FIG>, the memory <NUM>, <NUM>, may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory <NUM>, <NUM> may comprise a database <NUM>, <NUM> for storing data. For example, the configuration of the M-TRP and M-TRP beam failure indication may be stored to the database. For example, the network node <NUM> may configure the UE <NUM> to use a certain beam failure indication. This configuration may be stored, for example, by the UE <NUM> to the database and used accordingly before reconfiguration (e.g. new Transmission Configuration Indicator (TCI) states set by the network).

The apparatus <NUM>, <NUM> may further comprise radio interface (TRX) <NUM>, <NUM> comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to access the radio access network, for example. The TRX may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de)modulator, and encoder/decoder circuitries and one or more antennas. TRX may provide access to F1 and/or Xn interface, for example, and/or provide UL/DL communication capability. For example, the BFR MAC CE may be transmitted via the TRX.

The apparatus <NUM>, <NUM> may comprise user interface <NUM>, <NUM> comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface <NUM>, <NUM> may be used to control the respective apparatus by a user of the apparatus <NUM>, <NUM>.

In an embodiment, the apparatus <NUM> may be or be comprised in a UE, e.g. the UE performing the method described above (e.g. see <FIG>). For example, the apparatus <NUM> may be or be comprised in the UE <NUM> or UE <NUM>.

In an embodiment, the apparatus <NUM> may be or be comprised in a network element, e.g. the network element performing the method described above (e.g. see <FIG>). For example, the apparatus <NUM> may be or be comprised in the network node <NUM>.

According to an embodiment, with reference to <FIG>, the control circuitry <NUM> comprises a detecting circuitry <NUM> configured at least to perform operations described with respect to block <NUM> of <FIG>; an encoding circuitry <NUM> configured at least to perform operations described with respect to block <NUM> of <FIG>; and a transmitting circuitry <NUM> configured at least to perform operations described with respect to block <NUM> of <FIG>.

According to an embodiment, with reference to <FIG>, the control circuitry <NUM> comprises a configuring circuitry <NUM> configured at least to perform operations described with respect to block <NUM> of <FIG>. Additionally, the control circuitry <NUM> may further comprise a receiving circuitry <NUM> configured at least to receive the BFR MAC CE from the UE or UEs.

In an embodiment, at least some of the functionalities of the apparatus <NUM> may be shared between two physically separate devices, forming one operational entity. Therefore, the apparatus <NUM> may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes. Thus, the apparatus <NUM> utilizing such shared architecture, may comprise a remote control unit (RCU), such as a host computer or a server computer, operatively coupled (e.g. via a wireless or wired network) to a remote radio head(s) (RRH), such as a TRP or TRPs, located in a base station or network node <NUM>, for example. In an embodiment, at least some of the described processes may be performed by the RCU. In an embodiment, the execution of at least some of the described processes may be shared among the RRH and the RCU. For example, CU/DU split may utilize such shared architecture.

In an embodiment, the RCU may generate a virtual network through which the RCU communicates with the RRH. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization may involve platform virtualization, often combined with resource virtualization. Network virtualization may be categorized as external virtual networking which combines many networks, or parts of networks, into the server computer or the host computer (i.e. to the RCU). External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to the software containers on a single system.

In an embodiment, the virtual network may provide flexible distribution of operations between the RRH and the RCU. In practice, any digital signal processing task may be performed in either the RRH or the RCU and the boundary where the responsibility is shifted between the RRH and the RCU may be selected according to implementation.

According to an aspect there is provided a system comprising a plurality of apparatuses <NUM> and one or more apparatuses <NUM>.

As used in this application, the term 'circuitry' refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and soft-ware (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present.

In an embodiment, at least some of the processes described in connection with <FIG> may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of <FIG> or operations thereof.

According to yet another embodiment, the apparatus carrying out the embodiments comprises a circuitry including at least one processor and at least one memory including computer program code. When activated, the circuitry causes the apparatus to perform at least some of the functionalities according to any one of the embodiments of <FIG>, or operations thereof. The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within 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, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with <FIG> may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium, for example. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art. In an embodiment, a computer-readable medium comprises said computer program.

Claim 1:
An apparatus of a wireless communication network, the apparatus comprising means for performing:
detecting (<NUM>) a beam failure on one transmission/reception point, TRP, the apparatus being configured to communicate with a plurality of TRPs of a cell, wherein each TRP of the plurality of TRPs is associated with a CORESETPoolIndex value, and each CORESETPoolIndex value is associated with at least one beam failure detection reference signal, BFD-RS, set, and wherein a beam failure on a TRP is determined based on a failure condition of the at least one BFD-RS set associated to the TRP;
based on the detecting, encoding (<NUM>) a beam failure indication data to a beam failure recovery, BFR, media access control, MAC, control element, CE, wherein the beam failure indication data indicates the beam failure on one TRP of the plurality of TRPs, wherein the beam failure indication data comprises an information element indicating that the beam failure is partial in which beam failure is detected on one TRP of the plurality of TRPs and another information element indicating an index value of a TRP associated with the partial beam failure; and
transmitting (<NUM>) the BFR MAC CE to a network element of the wireless communication network.