Transmission reception point specific beam failure indication in multi-transmission reception point scenarios

Abstract

According to one example embodiment, a method can include receiving, by a user equipment, at least one network entity failure indication configuration. The method can also include detecting, by the user equipment, that at least one first network entity satisfies at least one beam failure condition. The method can also include selecting, by the user equipment, one or more of at least one resource and at least one parameter based on the at least one received network entity failure indication configuration. The method can also include transmitting, by the user equipment, at least one indication of the at least one first network entity that satisfies the at least one beam failure condition to at least one second network entity.

Description

TECHNICAL FIELD

[0001] Some example embodiments can generally relate to mobile or wireless telecommunication systems, such as Long Term Evolution (LTE), Fifth Generation (5G) Radio Access Technologies (RATs), New Radio (NR) access technologies, and / or other communication systems. For example, certain example embodiments can relate to systems and / or methods for a user equipment to inform a network about a transmission reception point being in a beam failure condition. BACKGROUND

[0002] Examples of mobile or wireless telecommunication systems can include 5G RATs, Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), LTE- evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), LTE-A Pro, NR access technologies, and / or MulteFire Alliance. The 5G wireless system refers to the next generation (NG) of radio systems and network architecture. The 5G system is generally built on 5G NR, but 5G (or NG) networks can also be built on E-UTRA radios. NR is expected to support several service categories, such as enhanced mobile broadband (eMBB), ultra-reliable low-latency Communication (URLLC), and massive machine type communication (mMTC). NR is expected to deliver ultra- wideband, ultra-robust, low-latency connectivity to support the Internet of Things (IoT). The next generation radio access network (NG-RAN) denotes a RAN for 5G, which can provide radio access for NR, LTE, LTE-A. It should be noted that the nodes in 5G providing the radio access functionality to the user equipment (e.g., similar to Node B in UTRAN or evolved Node B (eNB) in LTE) can be referred to as next generation Node B (gNB) when built on NR radio and as next generation eNB (NG-eNB) when built on E-UTRA radio. SUMMARY BRIEF DESCRIPTION OF DRAWINGS

[0003] For proper understanding of the example embodiments, reference should be made to the drawings, wherein:

[0004] Figure 1 An example of a medium access control layer detecting beam failure is illustrated.

[0005] Figure 2 An example of two transmission reception points serving a user equipment, where one transmission reception point satisfies a beam failure condition, is illustrated.

[0006] Figure 3 An example of a signaling diagram according to certain embodiments is illustrated.

[0007] Figure 4An example of a flow diagram illustrating a method according to various embodiments is shown.

[0008] Figure 5 An example of a flow diagram illustrating a method according to some embodiments is shown.

[0009] Figure 6 An example of various network devices according to some embodiments is shown.

[0010] Figure 7 An example of a 5G network and system architecture according to certain embodiments is shown. DETAILED DESCRIPTION

[0011] It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for a user equipment to notify a network about a transmission reception point being in a beam failure condition is not intended to limit the scope of certain embodiments but to represent selected example embodiments.

[0012] Third Generation Partnership Project (3GPP) Release (Rel)-15 New Radio (NR) defines how a user equipment (UE) should use the medium access control (MAC) layer to declare a beam failure. As shown in Figure 1 The physical (PHY) layer can not take any action until a beam failure instance is detected. Once detected, the PHY layer indicates the beam failure instance to the MAC layer, which counts these instances using a counter N.

[0013] Each serving control channel needs to be in failure for a beam failure instance to be detected. An assumed physical downlink control channel (PDCCH) block error rate (BLER) can be used to determine whether a serving control channel link is in a failure condition, where the BLER is computed using measurements on a beam failure detection reference signal (BFD-RS) set. The BFD-RS set can include some synchronization signal block (SSB) and / or channel state information reference signal (CSI-RS) indexes. And as noted above, each BFD-RS resource in the BFD-RS set needs to first be in a failure condition for a beam failure instance to be indicated to the MAC layer.

[0014] A UE can be configured in a variety of ways to determine a set of BFD-RSs. For example, a network entity (NE), such as a base station (BS), transmission reception point (TRP), and / or the like, can explicitly configure a UE with at least one RS index configured for fault detection. Instead of explicit configuration, a UE can use an implicit configuration by default, where the set of BFD-RSs includes periodic CSI-RSs and / or SSBs listed in TCI-StatesPDCCH, which can be used to monitor PDCCH on at least one control resource set (CORESET). With this default configuration, a UE can expect at least one periodic CSI-RS and / or SSB to have spatial quasi-co-location (QCL) with at least one PDCCH demodulation reference signal (DMRS). Thus, a UE can determine a set of BFD-RSs (q0) for RSs indicated by an activated transmission configuration indicator (TCI) state for PDCCH.

[0015] 3GPP Release 15 also specifies beam failure recovery procedures for contention-based random access (CBRA) and contention-free random access (CFRA); however, a UE does not explicitly indicate BFR to the network with Release 15 CBRA BFR. With CFRA recovery, a physical random access channel (PRACH) preamble can be associated with downlink reference signals (DRS) provided in a list of candidate beam RSs with SSB and / or CSI-RS parameters, which can be similar to set q1 in 3GPP Technical Specification (TS) 38.213. If CFRA is configured, a UE can instead first select at least one candidate beam that exceeds a reference signal received power (RSRP) threshold, such as rsrp-ThresholdSSBBFR. If no candidate beam exceeds the RSRP threshold, a UE can instead use CBRA BFR, select an SSB by the UE, and perform a standard random access channel (RACH) procedure. Finally, if a UE is not configured with CFRA, the UE can use CBRA BFR.

[0016] While Release 15 does not support a UE indicating a BFR to the network using CBRA BFR, Release 16 allows this indication using a MAC control element (CE) for secondary cell (SCell) BFR. In particular, Release 15 BFR is further enhanced in Release 16 by adding a failure detection for SCells. In SCell failure recovery, a UE can be configured with a scheduling request (SR) dedicated for SCell BFR. The UE can use this SR to indicate that a beam failure has occurred for an SCell and request resources for a MAC CE, thereby providing additional information about the failing SCell. A MAC CE can also be transmitted using an available uplink (UL) grant without transmitting an SR. In addition to a bitmap containing information about the failing SCell, the UE can send an SCell BFR MAC CE on an available UL grant. A new candidate index can be selected from a list for each failing SCell, each candidate index being suitable according to an RSRP threshold. The resulting list of candidate RSs is then explicitly configured.

[0017] In multi-transmission reception point (TRP) scenarios, a BFD-RS set can be configured to include resources corresponding to the TRPs serving the UE. For example, for two TRPs serving the UE, the BFD-RS can be explicitly configured with two CSI-RS indexes, each corresponding to a particular TRP. Alternatively, if the BFD-RS contains resources corresponding to only one TRP, the UE will declare a beam failure and then initiate a RACH recovery procedure despite the other TRP not satisfying the failure condition.

[0018] For beam measurement and reporting, Release 15 specifies support for both differential and non-differential reporting for non-group and group-based beam reporting. Here, a UE can be configured to report measurements corresponding to up to four reference signals (in effect, up to four beams) such as CSI-RS or SSB in a single reporting instance. Thus, measurements can be reported using N strongest CSI-RS resource indicators (CRIs) and / or SSB resource indicators, where a 6-bit length field is reserved for each indicator and N < 4. A 7-bit length field can be reserved for the largest layer 1 (L1)-RSRP, from (-140 dB mW to -44 dB mW ), and a 4-bit length field can be reserved for differential L1-RSRP reporting. When reporting on a physical uplink shared channel (PUSCH) or long physical uplink control channel (PUCCH), the L1-RSRP and / or resource indicators configured for beam management are mapped to the first CSI part.

[0019] One important topic under the NR MIMO scope of Release 17 is “Enhancements to support multi-TRP deployment” targeting both frequency range 1 (FR1) and FR2. A list of objectives related to the scope of multi-TRP operation work is described in 3GPP RP-193133, which targets include: identifying and specifying features to improve reliability and robustness of channels other than physical downlink shared channel (PDSCH) using multi-TRP and / or multi-panel, building on Rel-16 reliability features; implementing QCL / TCI related enhancements for inter-cell multi-TRP operation assuming multi-PDSCH reception based on multiple downlink control information (DCI); beam management related enhancements to provide simultaneous multi-TRP transmission and multi-panel reception.

[0020] A TRP-specific (i.e., per-TRP) beam failure recovery procedure has not yet been defined in 3GPP. While one serving TRP can not meet the beam failure condition, other TRPs can need fast beam recovery and change in response to the failed TRP, e.g., with the connected TRP, without the need for the “full” BFR procedure typically used when every serving TRP has failed (i.e., from the UE’s perspective when all TRPs have failed). To enable TRP-specific BFD, such as according to CORESET pool index, the BFD-RS set can be split into subsets, each BFD-RS subset associated with a different TRP. Thus, the UE can perform the BFD procedure separately for each subset and detect the failed TRP while the other TRPs continue to operate. Notably, 3GPP has not yet defined such TRP-specific BFD operation, but it is expected that 3GPP will eventually define and enable one.

[0021] As noted above, the current beam failure procedure is triggered when every BFD-RS resource in the BFD-RS set meets the failure condition. Thus, for a BFD-RS set containing RS resources for two serving TRPs, beam failure will be declared when both serving TRPs fail. As illustrated in Figure 2 As illustrated in FIG. 1, when only one TRP meets the failure condition, the inability to initiate the beam failure recovery procedure is a significant limitation. Recall from the foregoing discussion that enabling TRP-specific beam failure indication and recovery is of great importance for future development.

[0022] Returning to Figure 2In the scenario illustrated in FIG. 1, the UE is configured to detect that TRP-2 satisfies a failure condition while TRP-1 is not in a failure condition. Two BFD-RS subsets can be configured, where each BFD-RS subset is associated with a different TRP. It can be desirable to timely inform the network of the failure of TRP-2 so that a fast beam adjustment / recovery can be performed for the failed TRP, e.g., using the non-failed TRP. In some scenarios, depending on the cause of the failure, the failed TRP can need to be replaced by another TRP. Fast beam adjustment / recovery can be beneficial, in particular when ultra-reliable and low latency communication (URLLC) traffic is to be transmitted and / or when more than one TRP is needed to satisfy stringent URLLC latency and reliability requirements. Furthermore, recovering the failed TRP as soon as possible reduces the need for the UE to perform a full beam failure recovery procedure, as in this case it is less likely that other TRPs will fail before the first failed TRP is recovered. Any of the embodiments discussed herein can be applied to intra-cell and / or inter-cell multi-TRP. For example, TRP-1 and TRP-2 can be associated with different cells. Different cells can be identified by a physical cell identity (PCI), and TRPs can be associated with different cells through an associated CORESET, CORESETPoolIndexes, and / or reference signals indicated by the active TCI state of the PDCCH for the associated CORESET.

[0023] In some cases, the network can be able to receive updated beam conditions for a TRP by configuring the UE to report beam related information using existing procedures, such as configuring RS corresponding to each TRP for beam reporting. However, such frequent reporting on beam conditions would require a relatively high reporting load when reporting resource indicators and related L1-RSRP measurements, and configuring frequent / periodic UL (PUCCH / PUSCH) resources to quickly carry such a high load. Furthermore, these resources would need to be configured such that the transmission of such a high reporting load is also sufficiently reliable, requiring a large amount of UL resources.

[0024] Certain embodiments described herein can have various benefits and / or advantages over the above-described deficiencies. For example, certain embodiments can quickly inform the network that a TRP is experiencing a beam failure in a multi-TRP system with low resource overhead, in particular when only a (reliable) 1-bit information load is used for transmission. Various embodiments can have the additional benefit of allowing the network to quickly recover the failed TRP, thereby reducing the need for the UE to perform a full / classic beam failure recovery procedure. Accordingly, certain embodiments discussed below relate to improvements in computer-related technology.

[0025] Figure 3FIGURE 1 illustrates an example of a signaling diagram depicting a UE informing a network about a NE (e.g., TRP) being in a beam failure condition. According to certain embodiments, UE 310 can be similar to UE 610, and NE 320 (e.g., TRP1) and NE 330 (e.g., TRP2) can be similar to Figure 6 The NE 620 illustrated in FIGURE 6. While some techniques described below can discuss two TRPs in example embodiments, a different number of TRPs can be used. Further, it should be noted that some techniques below can also be applied to a set of beams and / or a set of TRPs. For example, a TRP beam failure indication can be configured to indicate a set of beams that have failed, where the set of beams includes beams spanning multiple TRPs. Additionally, the methods described below can similarly be applied to a link failure scenario where a TRP experiences a radio link failure.

[0026] At 301, NE 320 can transmit to UE 310 any number of TRP failure indication configurations, which can contain a number of dedicated / shared UL resources and / or related parameters, and can be configured to allow UE 310 to indicate that a TRP is experiencing beam failure. For example, the dedicated / shared UL resources can be configured to carry any number of indications that at least one TRP satisfies a beam failure condition. These indications can include an indication / indicator of the failed TRP and / or any other information configured to identify / characterize the failed TRP. In various embodiments, the TRP indicator can be a CORESETPoolIndex, where UE 310 can assume that CORESETs configured with the same CORESETPoolIndex are associated with the same TRP. Additionally or alternatively, the TRP indicator can be associated with any number of BFD-RS indexes, which can use a mapping and / or association between at least one TRP and at least one UL resource configured to carry a TRP beam failure indication.

[0027] As an example, the TRP failure indication configurations can include a configuration of periodic PUCCH resources, such as “config-1” and “config-2,” each of which is configured to transmit one bit of information (e.g., bit “1”) indicating a failed TRP. Config-1 can help UE 310 indicate to NE 320 that NE 330 has failed, while, conversely, config-2 can help UE 310 indicate to NE 330 that NE 320 has failed. In another example, the TRP failure indication configurations can provide / configure at least one UL MAC CE to transmit a TRP beam failure indication.

[0028] At 303, the UE 310 can detect that at least one TRP, such as the NE 330, is in a beam failure condition, such as the NE 330 satisfying at least one beam failure condition threshold. The detection by the UE 310 can be based on at least one subset of BFD-RSs.

[0029] At 305, in response to the detection at 303, the UE 310 can select at least one resource and / or at least one parameter received at 301 to use in reporting the at least one failing TRP (i.e., the NE 330). In various embodiments, the UE 310 can select which resources and / or parameters to use based on which TRP(s) have failed, or conversely, which TRP(s) are not in a failure condition and have not failed. In an example with two TRPs, the UE 310 can be configured to transmit at least one information bit associated with a particular resource, such as a 1-bit length, to the NE 320 to indicate that the NE 330 is in a beam failure condition. In another example with more than two TRPs, the UE 310 can transmit at least one indicator of the failing TRP(s) with respect to the resource to the NE 320.

[0030] As an example, the UE 310 can detect that the NE 330 is in a beam failure condition and the NE 320 is not in a beam failure condition. Using the configuration received at 301, the UE 310 can use config-1 to indicate that the NE 330 has failed. Specifically, the UE 310 can use a PUCCH resource provided in config-1 to transmit an information bit of “1” to the NE 320. For example, config-1 can include a resource with PUCCH format 0 and a particular cyclic shift can be configured to indicate the information bit of “1”. Alternatively, the TRP failure indication configuration can cause the UE 310 to indicate at least one identifier of the NE 330 (e.g., CORESETPoolIndex) to the NE 320 via a UL MAC CE.

[0031] In certain embodiments, the UE 310 can select periodic and / or semi-persistent PUCCH resources to indicate the failing TRP(s), such as resources using PUCCH formats 0 and 1. For example, the UE 310 can use a mapping / association between the TRP failure indication, the PUCCH resource, and the resource / parameter configuration, which can be based on any combination of cyclic shift, time / frequency resource, and spatial relation information, to indicate the failing TRP.

[0032] Using the identified resources and / or parameters from 305, at 307, the UE 310 can transmit at least one indication to the NE 320 indicating at least one failed TRP and / or a failure situation. In some embodiments, the UE 310 can also transmit the at least one indication via explicit uplink control information (UCI). In an example embodiment, in a case where the UE 310 is served by two TRPs, two configurations of a dedicated periodic PUCCH resource of format 0 can be configured, where a first configuration can allow transmission to the NE 320, and a second configuration can allow transmission to the NE 330. Additionally, the at least one TRP failure indication can be signaled via PUCCH format 0, for example with a single information bit, similar to a positive SR. As a result, in response to the UE 310 detecting a TRP failure, the UE 310 can use the configuration of the periodic PUCCH resource associated with the NE 320 to transmit the TRP failure indication to the NE 320.

[0033] In some embodiments, the UE 310 can use a PUCCH format with a bitmap to indicate the failed RS associated with the failed TRP in an ascending or descending order of CORESET index and / or CORESETPoolIndex. For example, in a case where the UE 310 is configured with 4 BFD-RS, the UE 310 can transmit explicit information of the failed TRP / failed PDCCH beam combination, allowing the network to identify the TRP failure using the bitmap information.

[0034] In various embodiments, a PUSCH resource, such as a configured grant resource, can be configured to carry the TRP failure indication. For example, various parameters / configurations of the configured grant resource, such as DMRS, can carry the TRP failure indication. Additionally or alternatively, the UE 310 can include the TRP failure indication in the form of UCI on the PUSCH, with or without uplink shared (transport) channel (UL-SCH) data. The UE 310 can use various associations between the PUSCH resource and the serving TRP(s) to select a suitable resource to transmit the TRP failure indication. For example, for two TRPs, two configured grant PUSCH configurations can carry the indication, where each configuration can correspond to a transmission towards a different TRP, for example by explicitly associating each configured grant PUSCH configuration with a particular TRP. To avoid confusion in a case where the configured grant occasion is only used for data transmission, each configuration can be configured with two DMRS, where the first DMRS is used for the TRP failure indication, and the second DMRS is only used for data transmission. Thus, when a TRP fails, the UE 310 can inform the network by using the configured grant configuration to send the DMRS(s) indicating the beam failure to the non-failed TRP, such as the NE 320.

[0035] In some embodiments, the UE 310 can be configured with any combination of UL RS, such as sounding reference signals (SRS), resources, and related parameters, to transmit a TRP failure indication. For example, in the case of two TRPs, two SRS resources can be used, each SRS configured to carry a TRP failure indication. When a TRP fails, the UE 310 can transmit at least one SRS towards the non-failed TRP (i.e., the NE 320), informing the network that the NE 330 has failed. In addition, the UE 310 can use at least one UL MAC CE to signal the TRP failure indication, where the UE 310 can request an UL grant via dedicated and / or shared SR resources to transmit the MAC CE indicating the TRP failure indication, such as if UL (PUSCH) resources are not available.

[0036] In certain embodiments, the UE 310 can be configured with any number of aperiodic / semi-persistent beam reporting configurations that can be activated when the UE 310 transmits the TRP failure indication(s). For example, the UL indication(s) can indicate to the network, such as the NE 320, that a failure has been detected on the NE 330, and in response, the UE 310 can receive a trigger to start beam reporting according to the configured UL resources. After a new PDCCH beam is configured for the UE 310, the TCI state of the PDCCH is activated, the UE 310 can stop reporting and / or the reporting resources can be deactivated. Additionally or alternatively, the UE 310 can stop reporting if the UE 310 does not receive a new TCI state for the failed PDCCH after N reporting periods, and / or can stop monitoring the PDCCH on the CORESET(s) of the NE 330. In one example embodiment, the UE 310 can stop monitoring the PDCCH on the failed CORESET or the CORESETs of the failed TRP if the network has triggered the beam reporting and cancelled the reporting. In one example embodiment, the NE 320 can configure the UE 310 to provide beam reporting (such as CSI-ReportConfig) of a specific set of reference signals (such as in CSI-ResourceConfig). The resource configuration and reporting can be specific to and conditioned on the indicated TRP.

[0037] Figure 4 FIGURE 1 illustrates an example of a method performed by a UE to notify a network about a NE (e.g., TRP) being in a beam failure condition. According to certain embodiments, the UE can similarly to Figure 6The UE 610 is illustrated in the figure. While some of the techniques described below can be discussed with two TRPs in the example embodiment, any number of TRPs can be used. Furthermore, it should be noted that some of the following techniques can also be applied to a set of beams and / or a set of TRPs. For example, a TRP beam failure indication can be configured to indicate a set of beams that has failed, wherein the set of beams includes beams spanning multiple TRPs. Additionally, the methods described below can be similarly applied to link failure scenarios where the TRP has experienced a radio link failure.

[0038] At 401, the UE can access information such as... Figure 6 The first NE / TRP, such as NE 620, receives any number of TRP fault indication configurations, which may include several dedicated / shared UL resources and / or related parameters, and may be configured to allow the UE to indicate that the NE is experiencing a beam fault. For example, dedicated / shared UL resources may be configured to carry any number of indications regarding at least one NE satisfying a beam fault condition. These indications may include indications / indicators of the faulty NE, and / or any other information configured to identify / characterize the faulty NE. In various embodiments, the TRP indicator may be a CORESETPoolIndex, where the UE may assume that CORESETs configured with the same CORESETPoolIndex are associated with the same NE / TRP. Additionally or alternatively, the TRP indicator may be associated with any number of BFD-RS indices, which may use mappings and / or associations between at least one NE and at least one UL resource configured to carry TRP beam fault indications.

[0039] As an example, a TRP fault indication configuration may include the configuration of periodic PUCCH resources, such as "config-1" and "config-2", each of which is configured to transmit a bit of information (e.g., bit "1") indicating a faulty TRP. Config-1 can help the UE indicate to the first NE that the second NE has failed, while conversely, config-2 can help the UE indicate to the second NE that the first NE has failed. In another example, the TRP fault indication configuration may provide / configure at least one ULMACCE to transmit a TRP beam fault indication.

[0040] At 403, the UE can detect things such as Figure 6At least one second NE / TRP, such as NE 620, in the multi-TRP is in a beam failure condition, such as the failed NE satisfies at least one beam failure condition threshold. The UE’s detection can be based on at least one subset of BFD-RSs. In another example, the failure detection in the multi-TRP can be based on one set of BFD-RSs, where the failure can be detected on a portion / subset of the BFD-RS resources in the set.

[0041] At 405, in response to the detection at 403, the UE can select at least one resource and / or at least one parameter received at 401 to use in reporting the at least one second NE / TRP (i.e., NE 330). In various embodiments, the UE can select which resources and / or parameters to use based on which TRP(s) have failed, or conversely, which TRP(s) are not in a failure condition and have not failed. In an example with two TRPs, the UE can be configured to transmit at least one information bit (e.g., 1 bit length) associated with a particular resource to the first NE to indicate that the second NE is in a beam failure condition. In another example with more than two TRPs, the UE can transmit at least one indicator of the second TRP with respect to the resource to the first NE.

[0042] As an example, the UE can detect that the second NE is in a beam failure condition and the first NE is not in a beam failure condition. Using the configuration received at 401, the UE can use config-1 to indicate the second NE. Specifically, the UE can use the PUCCH resource provided in config-1 to transmit an information bit of “1” to the first NE. For example, config-1 can include a resource with PUCCH format 0 and a particular cyclic shift can be configured to indicate the information bit of “1”. Alternatively, the TRP failure indication configuration can cause the UE to indicate at least one identifier (e.g., CORESETPoolIndex) of the second NE to the first NE via a UL MAC CE.

[0043] In certain embodiments, the UE can select periodic and / or semi-persistent PUCCH resources to indicate the failed TRP, such as using resources of PUCCH formats 0 and 1. For example, the UE can use the mapping / association between the TRP failure indication, PUCCH resource, and resource / parameter configuration, which can be based on any combination of cyclic shift, time / frequency resource, and spatial relation information, to indicate the failed TRP.

[0044] Using the resources and / or parameters identified from 405, at 407, the UE can transmit at least one indication to the first NE indicating at least one second NE and / or a failure situation. In some embodiments, the UE can also transmit the at least one indication via explicit uplink control information (UCI). In example embodiments, in the case that the UE is served by two TRPs, two configurations of a dedicated periodic PUCCH resource of format 0 can be configured, where the first configuration can allow transmission to one NE and the second configuration can allow transmission to the other NE. Additionally, the at least one TRP failure indication can be signaled via PUCCH format 0, e.g., with a single information bit, similar to a positive SR. As a result, in response to the UE detecting a TRP failure, the UE can use the configuration of the periodic PUCCH resource associated with the second NE to transmit the TRP failure indication to the first NE.

[0045] In some embodiments, the failure detection and / or indication can be based on a set of BFD-RS resources associated with a particular TRP or can be determined based on the active TCI state of CORESETs of a CORESET Pool Index. In some embodiments, the UE can provide an indication of a set of BFD-RS resources that failed. This indication can indicate to the network that a particular TRP / network element is in a failure condition. As an example, the UE can have been configured with sets of beam failure detection resources q0_0 and q0_1 that can be associated with TRP-1 and TRP-2, respectively. When the UE has determined that a beam failure occurred on at least one of the resource sets, it can indicate the failed resource set(s). The resource sets used for beam failure detection can have explicit identifiers or the failure indication for a resource set can be associated with a recovery signaling configuration (e.g., an uplink signal or channel specific to the resource set).

[0046] In some embodiments, the UE can use a PUCCH format with a bitmap that indicates the failed RS associated with a failed TRP in ascending or descending order of CORESET index and / or CORESETPoolIndex. For example, in the case that the UE is configured with 4 BFD-RS, the UE can transmit explicit information of the failed TRP / failed PDCCH beam combination, allowing the network to use the bitmap information to identify the TRP failure.

[0047] In various embodiments, a PUSCH resource, such as a configured grant resource, can be configured to carry the TRP failure indication. For example, various parameters / configurations of the configured grant resource, such as DMRS, can carry the TRP failure indication. Additionally or alternatively, the UE can include the TRP failure indication in the form of UCI on the PUSCH - with or without uplink shared (transport) channel (UL-SCH) data. The UE can use various associations between the PUSCH resource and the serving TRP(s) to select the appropriate resource to transmit the TRP failure indication. For example, for two TRPs, two configured grant PUSCH configurations can carry the indication, where each configuration can correspond to a transmission towards a different TRP, e.g., by explicitly associating each configured grant PUSCH configuration with a particular TRP. To avoid confusion in cases where the configured grant occasion is used only for data transmission, each configuration can be configured with two DMRS, where the first DMRS is used for the TRP failure indication, and the second DMRS is used only for data transmission. Thus, when a TRP fails, the UE can inform the network by transmitting the DMRS(s) indicating the beam failure to the other NE / TRP using the configuration of the configured grant(s).

[0048] In some embodiments, the UE can be configured with any combination of UL RS, such as sounding reference signals (SRS), resources, and related parameters, to transmit the TRP failure indication. For example, in the case of two TRPs, two SRS resources can be used, each SRS configured to carry the TRP failure indication. When a TRP fails, the UE 310 can transmit at least one SRS to the non-failed TRP informing the network that an NE has failed and which one. Further, the UE can use at least one UL MAC CE to signal the TRP failure indication, where the UE can request an UL grant via a dedicated / or shared SR resource to transmit the MAC CE indicating the TRP failure indication, such as if UL PUSCH resources are not available.

[0049] In some embodiments, the UE can be configured with any number of aperiodic / semi-persistent beam reporting configurations that can be activated when the UE transmits (multiple) TRP fault indications. For example, (multiple) UL indications can indicate to the network (such as a non-faulty NE) that a fault has been detected on the NE, and in response, the UE can receive a trigger to start beam reporting based on the configured UL resources. After configuring a new PDCCH beam for the UE, the TCI state of the PDCCH is activated, and the UE can stop reporting and / or the reporting resources can be deactivated. Additionally or alternatively, if the UE does not receive a new TCI state for the faulty PDCCH after N reporting periods, the UE can stop reporting, and / or can stop monitoring the PDCCH on the CORESET of the faulty NE. In one example embodiment, the non-faulty NE can configure the UE to provide beam reporting (such as CSI-ReportConfig) for a specific set of reference signals (such as in CSI-ResourceConfig). Resource configuration and reporting can be specific to and conditional on the indicated TRP.

[0050] Figure 5 The illustration shows an example of a method performed by a UE to notify another NE (e.g., a TRP) that it is in a beam failure condition. According to some embodiments, the NE may be similar to... Figure 6 The NE 620 is illustrated in the figure. Although an example is described below, it should be understood that other arrangements / numbers of NEs / TRPs can be used. Furthermore, it should be noted that some of the following techniques can also be applied to a set of beams and / or a set of TRPs. For example, a TRP beam failure indicator can be configured to indicate a set of beams that has failed, where the set of beams includes beams spanning multiple TRPs. Additionally, the methods described below can be similarly applied to link failure situations where the TRP has experienced a radio link failure.

[0051] At position 501, the NE can send a signal to the UE (such as...). Figure 6The UE 610) transmits any number of TRP failure indication configurations, which can contain several dedicated / shared UL resources and / or related parameters, and can be configured to allow the UE to indicate that a TRP is experiencing beam failure. For example, the dedicated / shared UL resources can be configured to carry any number of indications that at least one TRP satisfies a beam failure condition. These indications can include an indication / indicator of the failing TRP, and / or any other information configured to identify / characterize the failing TRP. In various embodiments, the TRP indicator can be a CORESETPoolIndex, where the UE can assume that CORESETs configured with the same CORESETPoolIndex are associated with the same TRP. Additionally or alternatively, the TRP indicator can be associated with any number of BFD-RS indexes, which can use a mapping and / or association between at least one TRP and at least one UL resource configured to carry a TRP beam failure indication.

[0052] As an example, the TRP failure indication configurations can include a configuration of periodic PUCCH resources, such as “config-1” and “config-2,” each of which is configured to transmit one bit of information (e.g., bit “1”) indicating a failing TRP. Config-1 can help the UE indicate to the first NE that the second NE has failed, while, conversely, config-2 can help the UE indicate to the second NE that the first NE has failed. In another example, the TRP failure indication configurations can provide at least one UL MAC CE to transmit a TRP beam failure indication. At 503, the NE can receive an indication of at least one failing TRP from the UE using at least one resource / parameter selected by the UE from 501.

[0053] Figure 6 An example of a system is illustrated in accordance with certain example embodiments. In one example embodiment, the system can include a plurality of devices, such as, for example, the UE 610 and / or the NE 620.

[0054] The UE 610 can include one or more of a mobile device, such as a mobile phone, a smart phone, a personal digital assistant (PDA), a tablet, or a portable media player, a digital camera, a pocket video camera, a video game console, a navigation unit such as a Global Positioning System (GPS) device, a desktop or laptop computer, a single-point device such as a sensor or a smart meter, or any combination thereof.

[0055] The NE 620 can be a TRP, a base station such as an evolved Node B (eNB) or a next generation Node B (gNB), a next generation radio access network (NGRAN), a serving gateway, a server, and / or any other access node or combination thereof.

[0056] One or more of these devices can include at least one processor, indicated respectively as 611 and 621. At least one memory can be provided in one or more of the devices, indicated as 612 and 622. The memory can be fixed or removable. The memory can include computer program instructions or computer code contained therein. The processors 611 and 621 and memories 612 and 622, or a subset thereof, can be configured to provide the components corresponding to various blocks of Figures 3-5 Although not shown, the devices can also include positioning hardware, such as a global positioning system (GPS) or microelectromechanical system (MEMS) hardware, which can be used to determine a location of the device. Other sensors such as barometers, compasses, and the like are also permitted and can be included to determine location, altitude, orientation, and the like.

[0057] As shown in Figure 6 Transceivers 613 and 623 can be provided, and one or more of the devices can also include at least one antenna, illustrated respectively as 614 and 624. The devices can have many antennas, such as an array of antennas configured for multiple-input multiple-output (MIMO) communication, or multiple antennas for multiple radio access technologies. Other configurations of these devices can be provided, for example.

[0058] The transceivers 613 and 623 can be transmitters, receivers, or both a transmitter and a receiver, or a unit or device configured for both transmission and reception.

[0059] The processors 611 and 621 can be embodied by any computational or data processing device, such as a central processing unit (CPU), an application-specific integrated circuit (ASIC), or similar device. The processors can be implemented as a single controller, or a plurality of controllers or processors.

[0060] The memories 612 and 622 can independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory can be used. The memory can be combined on a single integrated circuit as the processor, or separate from the processor(s). Furthermore, the computer program instructions stored in the memory and which can be processed by the processor can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language. The memory can be removable or non-removable.

[0061] The memory and computer program instructions can be configured, with the processor for the particular device, to cause a hardware apparatus, such as a user equipment, to perform any of the processes described below (see, for example, Figures 3-5). Thus, in certain embodiments, a non-transitory computer-readable medium can be encoded with computer instructions, when executed in hardware, perform a process, such as one of the processes described herein. Alternatively, certain embodiments can be performed entirely in hardware.

[0062] In certain embodiments, an apparatus can include circuitry configured to perform any of the processes or functions illustrated in Figures 3-5 In certain embodiments, an apparatus can include circuitry configured to perform any of the processes or functions illustrated in

[0063] Figure 7 An example of a 5G network and system architecture is illustrated in accordance with certain embodiments. Shown are a number of network functions, which can be implemented as software operating as part of a network device or a dedicated hardware, as a network device itself or a dedicated hardware, or as a virtual function operating as a network device or a dedicated hardware. Figure 7 The UEs and NEs illustrated in FIG. 6 can be similar to the UEs 610 and NEs 620, respectively. User plane functions (UPFs) can provide services such as intra-RAT and inter-RAT mobility, routing and forwarding of packets, inspection of data packets, user plane quality of service (QoS) handling, buffering of downlink packets, and / or triggering of downlink data notifications. Application functions (AFs) can interface primarily with the core network to facilitate application usage of traffic routing and interact with the policy framework.

[0064] The features, structures, or characteristics of the example embodiments described throughout this specification can be combined in any suitable manner in one or more example embodiments. For example, use of the phrases “various embodiments,” “certain embodiments,” “some embodiments,” or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the example embodiments can be included in at least one example embodiment. Thus, appearances of the phrases “in various embodiments,” “in certain embodiments,” “in some embodiments,” or other similar language throughout this specification do not necessarily all refer to the same group of example embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more example embodiments.

[0065] Additionally, different functions or processes discussed above can be performed in different orders and / or concurrently with each other. Furthermore, if desired, one or more of the described functions or processes can be optional or can be combined. As such, the foregoing description should be considered as merely illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.

[0066] Those of ordinary skill in the art will readily understand that the example embodiments discussed above can be practiced with different ordered processes and / or different configurations of hardware elements than those disclosed. Accordingly, although some embodiments have been described based upon these example embodiments, it would be clear to those of ordinary skill in the art that certain modifications, changes, and substitutions are expressly contemplated, while remaining within the spirit and scope of the example embodiments.

[0067] Partial Glossary

[0068] 3GPP Third Generation Partnership Project

[0069] 5G Fifth Generation

[0070] 5GC Fifth Generation Core

[0071] 5GS Fifth Generation System

[0072] AMF Access and Mobility Management Function

[0073] ASIC Application-Specific Integrated Circuit

[0074] BFD-RS Beam Failure Detection Reference Signal

[0075] BLER Block Error Rate

[0076] BS Base Station

[0077] CBRA Contention-Based Random Access

[0078] CBSD citizens broadband radio service device

[0079] CE control element

[0080] CFRA contention free random access

[0081] CG configured grant

[0082] CN core network

[0083] CORESET control resource set

[0084] CPU central processing unit

[0085] CSI channel state information

[0086] CSI-RS channel state information reference signal

[0087] CRI channel state information reference signal resource indicator

[0088] DBmW decibel-milliwatt

[0089] DCI downlink control information

[0090] DL downlink

[0091] DMRS demodulation reference signal

[0092] DRS downlink reference signal

[0093] eMBB enhanced mobile broadband

[0094] eMTC enhanced machine type communications

[0095] eNB evolved node B

[0096] eOLLA enhanced outer loop link adaptation

[0097] EPS evolved packet system

[0098] FDD frequency division duplex

[0099] FR frequency range

[0100] gNB next generation node B

[0101] GPS global positioning system

[0102] HDD hard disk drive

[0103] IEEE institute of electrical and electronics engineers

[0104] L1 layer 1

[0105] L2 Layer 2

[0106] LTE Long Term Evolution

[0107] LTE-A Long Term Evolution Advanced

[0108] MAC Medium Access Control

[0109] MBS Multicast and Broadcast System

[0110] MCS Modulation Coding Scheme

[0111] MEMS Micro-Electro-Mechanical System

[0112] MIMO Multiple Input Multiple Output

[0113] MME Mobility Management Entity

[0114] mMTC Massive Machine Type Communication

[0115] MPDCCH Machine Type Communication Physical Downlink Control Channel

[0116] MTC Machine Type Communication

[0117] NAS Non Access Stratum

[0118] NE Network Entity

[0119] NG Next Generation

[0120] NG-eNB Next Generation Evolved Node B

[0121] NG-RAN Next Generation Radio Access Network

[0122] NR New Radio

[0123] NR-U License-Exempt New Radio

[0124] PBC Physical Broadcast Channel

[0125] PDA Personal Digital Assistant

[0126] PDCCH Physical Downlink Control Channel

[0127] PDSCH Physical Downlink Shared Channel

[0128] PDU Protocol Data Unit

[0129] PHY Physical

[0130] PRACH Physical Random Access Channel

[0131] PRB Physical Resource Block

[0132] PUCCH physical uplink control channel

[0133] PUSCH physical uplink shared channel

[0134] QCL quasi co-location

[0135] QoS quality of service

[0136] RACH random access channel

[0137] RAM random access memory

[0138] RAN radio access network

[0139] RAT radio access technology

[0140] RE resource element

[0141] RLC radio link control

[0142] RRC radio resource control

[0143] RS reference signal

[0144] RSRP reference signal received power

[0145] SMF session management function

[0146] SR scheduling request

[0147] SRB signaling radio bearer

[0148] SSB synchronization signal block

[0149] TB transport block

[0150] TCI transmission configuration indicator

[0151] TDD time division duplex

[0152] TR technical report

[0153] TRP transmission reception point

[0154] TS technical specification

[0155] Tx transmission

[0156] UCI uplink control information

[0157] UE user equipment

[0158] UL uplink

[0159] UMTS universal mobile telecommunications system

[0160] UPF user plane function

[0161] URLLC ultra-reliable and low latency communications

[0162] UTRAN universal mobile telecommunications system terrestrial radio access network

[0163] WLAN wireless local area network

Claims

1. A method for communication, comprising: receiving (301, 401), by a user equipment (310) from a second network entity (320), at least one network entity failure indication configuration, wherein the at least one network entity failure indication configuration comprises at least one resource and / or at least one parameter; detecting (303, 403), by the user equipment, that at least one first network entity (330) satisfies at least one beam failure condition; selecting (305, 405), by the user equipment, one or more of the at least one resource and the at least one parameter based on the received at least one network entity failure indication configuration, the one or more of the at least one resource and the at least one parameter configuring transmission of at least one network entity failure indication of the detected at least one first network entity satisfying the at least one beam failure condition; and transmitting (307, 407), by the user equipment to the second network entity, the at least one network entity failure indication of the at least one first network entity satisfying the at least one beam failure condition, wherein the second network entity is in a non-failure condition.

2. The method of claim 1, wherein each of the at least one network entity failure indication configuration is associated with at least one network entity.

3. The method of claim 1, wherein the at least one network entity failure indication configuration comprises at least one uplink medium access control control element indicating at least one CORESETPoolIndex associated with the detected at least one first network entity.

4. The method of claim 1, wherein the at least one network entity failure indication configuration comprises at least two sets of periodic physical uplink control channel resources configured to transmit at least one network entity failure indication of the detected at least one first network entity.

5. The method of claim 1, wherein the detection that at least one first network entity satisfies at least one beam failure condition is based on at least one beam failure detection reference signal. at least one medium access control control element transmitted via at least one physical uplink shared channel.

6. The method of claim 1, wherein the at least one network entity failure indication comprises:

7. The method of claim 1, wherein the one or more of at least one resource and at least one parameter are associated with at least one network entity.

8. A method for communication, comprising: transmitting (301, 401), by a second network entity (320) to a user equipment (310), at least one network entity failure indication configuration, wherein the at least one network entity failure indication configuration comprises at least one resource and / or at least one parameter; and ​ receiving (307, 503), from a user equipment, at least one network entity failure indication that at least one first network entity satisfies at least one beam failure condition, wherein the second network entity is in a non-failure condition.

9. The method of claim 8, wherein the at least one network entity failure indication configuration comprises at least one uplink medium access control control element indicating at least one CORESETPoolIndex associated with the at least one failing network entity.

10. The method of claim 8, wherein the at least one network entity failure indication configuration comprises at least two sets of periodic physical uplink control channel resources configured to transmit at least one network entity failure indication of the at least one failing network entity.

11. The method of claim 8, wherein the at least one network entity failure indication comprises: at least one medium access control control element received via at least one physical uplink shared channel.

12. A user equipment (310) 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 user equipment at least to perform: receiving (301, 401), from a second network entity, at least one network entity failure indication configuration, wherein the at least one network entity failure indication configuration comprises at least one resource and / or at least one parameter; detecting (303, 403) that at least one first network entity satisfies at least one beam failure condition; selecting (305, 405), based on the received at least one network entity failure indication configuration, one or more of the at least one resource and the at least one parameter, the one or more of the at least one resource and the at least one parameter configuring transmission of at least one network entity failure indication that the detected at least one first network entity satisfies the at least one beam failure condition; and transmitting (307, 407), to the second network entity, the at least one network entity failure indication of the at least one first network entity that satisfies the at least one beam failure condition, wherein the second network entity is in a non-failure condition.

13. A second network entity (320) 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 second network entity at least to perform: transmitting (301, 501), to a user equipment, at least one network entity failure indication configuration; wherein the at least one network entity failure indication configuration comprises at least one resource and / or at least one parameter, wherein the at least one network entity failure indication configuration comprises at least one resource and / or at least one parameter; and receiving (307, 503), from the user equipment, at least one network entity failure indication that at least one first network entity fulfills at least one beam failure condition, wherein the second network entity is in a non-failure condition.

Images