Transmitting / receiving point-specific beam failure indication in multi-transmitting / receiving point scenarios

Abstract

To provide a system and method for notifying a network that a transmission reception point is in a beam failure condition in a next generation radio access network.SOLUTION: A method includes the steps of: receiving, by user equipment, a network entity failure indication configuration; detecting, by the user equipment, that a network entity satisfies a beam-failure condition; selecting, by the user equipment, a resource based on the received network entity failure indication configuration, the resource being configured to carry an indication that the detected network entity satisfies the beam failure condition; and transmitting, by the user equipment, the indication of the network entity that satisfies the beam-failure condition. The network entity failure indication configuration includes at least two sets of periodic physical uplink control channel resources configured to transmit the indication of the detected network entity.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] Some exemplary embodiments may relate generally to mobile or wireless telecommunications systems, such as Long Term Evolution (LTE), fifth generation (5G) radio access technology (RAT), new radio (NR) access technology, and / or other communication systems. For example, some exemplary embodiments may relate to systems and / or methods for user equipment to notify a network that a transmission / reception point is in a beam failure condition. [Background technology]

[0002] Examples of mobile or wireless telecommunications systems may include 5G RAT, Universal Mobile Telecommunications System (UMTS) Terrestial Radio Access Network (UTRAN), LTE Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), LTE-A Pro, NR access technology, and / or MultiFire Alliance. 5G wireless systems refer to next-generation (NG) radio systems and network architectures. 5G systems are typically built on 5G NR, but 5G (or NG) networks may also be built on E-UTRA radio. NR is expected to be able to support 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 extreme broadband, ultra-robust, low-latency connectivity, and large-scale networking to support the Internet of Things (IoT). The Next Generation Radio Access Network (NG-RAN) represents the RAN for 5G that can provide radio access for NR, LTE, and LTE-A. Note that the node in 5G that provides radio access functionality to user equipment (e.g., similar to a Node B in UTRAN or an evolved Node B (eNB) in LTE) may be called a Next Generation Node B (gNB) when built on NR radios, and a Next Generation eNB (NG-eNB) when built on E-UTRA radios.

[0003] For a proper understanding of the exemplary embodiments, reference is made to the accompanying drawings. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 shows an example of a medium access control layer for detecting beam failure. [Figure 2] FIG. 2 shows an example of two transmission / reception points serving a user equipment, where one transmission / reception point satisfies a beam obstruction condition. [Figure 3] FIG. 3 illustrates an example signaling diagram according to some embodiments. [Figure 4] FIG. 4 illustrates an example flow diagram of a method according to various embodiments. [Figure 5] FIG. 5 illustrates an example flow diagram of a method according to some embodiments. [Figure 6] FIG. 6 illustrates examples of various network devices according to some embodiments. [Figure 7] FIG. 7 illustrates an example of a 5G network and system architecture, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the Figures herein, could 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 user equipment to notify a network that a transmission / reception point is in a beam failure condition is not intended to limit the scope of some embodiments, but instead represents selected example embodiments.

[0006] The Third Generation Partnership Project (3GPP) Release (Rel)-15 New Radio (NR) defined how a user equipment (UE) should declare beam failure using the Medium Access Control (MAC) layer. As shown in Figure 1, the physical (PHY) layer may not take any action until a beam failure instance is detected. Once detected, the PHY layer indicates a beam failure instance to the MAC layer, which tallies these instances using a counter N.

[0007] Each serving control channel must be in a failed state for a beam failure instance to be detected. The virtual physical downlink control channel (PDCCH) block error rate (BLER) can be used to determine whether the serving control channel link is in a failed state, where the BLER is calculated using measurements of a beam failure detection reference signal (BFD-RS) set. The BFD-RS set may include several synchronization signal blocks (SSBs) and / or channel state information reference signal (CSI-RS) indices. And, as described above, each BFD-RS resource in the BFD-RS set must first be in a failed state for a beam failure instance to be indicated to the MAC layer.

[0008] A UE can be configured in various ways to determine its BFD-RS set. For example, a network entity (NE), such as a base station (BS) or a transmission / reception point (TRP), can explicitly configure the UE with at least one RS index configured for failure detection. Instead of explicit configuration, the UE may use implicit configuration by default, in which the BFD-RS set includes periodic CSI-RSs and / or SSBs listed in the TCI-StatesPDCCH that can be used to monitor the PDCCH on at least one control resource set (CORESET). In this default configuration, the UE can expect that at least one periodic CSI-RS and / or SSB has quasi-colocation (QCL) with at least one PDCCH demodulation reference signal (DMRS). Thus, the UE can determine the set of BFD-RSs (q0) to use for the RS indicated by the activated Transmission Configuration Indicator (TCI) state for the PDCCH.

[0009] 3GPP Rel-15 also specified beam failure recovery procedures for condition-based random access (CBRA) and contention-free random access (CFRA). However, the UE does not explicitly indicate BFR to the network with Rel-15 CBRA BFR. In CFRA recovery, the physical random access channel (PRACH) preamble may be associated with a downlink reference signal (DRS) provided in a candidate beam RS list with SSB and / or CSI-RS parameters, which may be similar to set q1 in 3GPP Technical Specification (TS) 38.213. If CFRA is configured, the UE may 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, the UE may use CBRA BFR instead, and the UE selects SSB and performs a standard random access channel (RACH) procedure. Finally, if the UE is not configured with CFRA, the UE may use CBRA BFR.

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

[0011] In a multiple transmit / receive point (TRP) scenario, the BFD-RS set may be configured to include resources corresponding to the TRPs serving the UE. For example, with two TRPs serving the UE, the BFD-RS may be explicitly configured with two CSI-RS indices, each corresponding to a specific TRP. Alternatively, if the BFD-RS includes resources corresponding to only one TRP, the UE will declare a beam failure and then initiate a RACH recovery procedure despite another TRP not meeting the failure condition.

[0012] For beam measurements and reporting, Rel-15 specified support for differential and non-differential based reporting for both non-group and group-based beam reporting. Here, a UE may be configured to report measurements corresponding to up to four reference signals (practically up to four beams), such as CSI-RS or SSB, in a single reporting instance. Thus, measurements may be reported using the N strongest CSI-RS resource indicators (CRIs) and / or SSB resource indicators, with a 6-bit long field reserved for each indicator, where N is less than or equal to 4. The 7-bit long field is used to report the strongest CSI-RS and / or SSB resource indicators (CRIs), with a 6-bit long field reserved for each indicator, where N is less than or equal to 4. mW ~-44dB mW ) may be reserved for maximum Layer 1 (L1)-RSRP, and a 4-bit long field may be reserved for differential L1-RSRP reporting. L1-RSRP and / or resource indicators configured for beam management are mapped to the first CSI section when reported on the physical uplink shared channel (PUSCH) or long physical uplink control channel (PUCCH).

[0013] A key topic under the Rel-17 NR MIMO scope is "Enhancements on the support for multi-TRP deployment," targeting Frequency Range (FR) 1 and FR 2. The list of objectives for the multi-TRP operation scope of work is described in 3GPP RP-193133, and includes identifying and specifying features to improve reliability and robustness for channels other than the physical downlink shared channel (PDScH) using multiple TRPs and / or multiple panels, using Rel-16 reliability features as a baseline; QCL / TCI-related enhancements to enable inter-cell multi-TRP operation, assuming multiple downlink control information (DCI)-based multi-PDSCH reception; and beam management-related enhancements to provide multi-panel reception and simultaneous multi-TRP transmission.

[0014] TRP-specific (i.e., per-TRP) beam failure recovery procedures are still undefined in 3GPP. One serving TRP may not meet the beam failure condition, while other TRPs may need to rapidly recover and change beams in response to the failed TRP, e.g., with a connected TRP, without requiring the "full" BFR procedure typically used when each serving TRP fails (i.e., when all TRPs fail from the UE's perspective). To enable TRP-specific BFD, the BFD-RS set may be divided into subsets, with each BFD-RS subset associated with a different TRP, e.g., according to a CORESET pool index. Thus, the UE can perform BFD procedures separately for each subset and detect the failed TRP while the other TRPs continue to operate. Note that while 3GPP has not yet defined such TRP-specific BFD operation, it is expected that 3GPP will eventually define and enable it.

[0015] As mentioned above, the current beam failure procedure is triggered when each BFD-RS resource in a BFD-RS set meets a failure condition. Therefore, for a BFD-RS set containing RS resources for two serving TRPs, beam failure is declared when both serving TRPs fail. As shown in Figure 2, the inability to initiate beam failure recovery procedures when only one TRP meets a failure condition is a significant limitation. Returning to the previous discussion, enabling TRP-specific beam failure indication and recovery is of significant interest for future development.

[0016] Returning to the scenario shown in FIG. 2, the UE is configured to detect that TRP-2 meets a failure condition and that TRP-1 does not. Two BFD-RS subsets can be configured, with each BFD-RS subset associated with a different TRP. The network may need to be notified quickly about the failure of TRP-2 so that rapid beam adjustment / recovery for the failed TRP can be performed, for example, using a non-failed TRP. In some scenarios, depending on the reason for the failure, the failed TRP may need to be replaced by another TRP. Rapid beam adjustment / recovery may be beneficial, especially when ultra-reliable and low-latency communication (URLLC) traffic is to be carried and / or when multiple TRPs are required to meet stringent URLLC latency and reliability requirements. Furthermore, recovering the failed TRP as quickly as possible reduces the need for the UE to perform a comprehensive beam failure recovery procedure, since in this case, other TRPs are unlikely to fail before recovering the first failed TRP. Any of the embodiments discussed herein may apply to intra-cell and / or inter-cell multi-TRPs. For example, TRP-1 and TRP-2 may be associated with different cells. Different cells may be identified by physical cell identity (PCI), and TRPs may be associated with different cells through reference signal association indicated by CORESET, CORESETPoolindexes, and / or active TCI status for the PDCCH for the associated CORESET.

[0017] In some situations, the network may be able to use existing procedures to receive updated beam conditions for TRPs by configuring the UE to report beam-related information, such as configuring the RS corresponding to each TRP for beam reporting. However, such frequent reporting of beam conditions requires a relatively high reporting load when resource indicators and associated L1-RSRP measurements are reported, as well as configuring frequent / periodic UL (PUCCH / PUSCH) resources to carry this high load quickly. Furthermore, these resources need to be configured so that transmission of such a high reporting load is also sufficiently reliable, requiring a significant amount of UL resources.

[0018] Some embodiments described herein may have various benefits and / or advantages for overcoming the above-mentioned drawbacks. For example, some embodiments may quickly notify the network that a TRP is experiencing a beam failure in a multi-TRP system with low resource overhead, especially when transmitted using only a (reliable) 1-bit information load. Various embodiments may have the additional benefit of enabling the network to quickly recover a failed TRP, thereby reducing the need for a UE to perform a full / classical beam failure recovery procedure. Accordingly, certain embodiments discussed below are directed to improvements in computer-related technology.

[0019] FIG. 3 illustrates an example signaling diagram showing a UE notifying the network that an NE (e.g., a TRP) is in a beam failure state. According to some embodiments, the UE 310 may be similar to the UE 610, and the NE 320 (e.g., TRP1) and the NE 330 (e.g., TRP2) may both be similar to the NE 620 shown in FIG. 6. While some techniques described below may be discussed for two TRPs in exemplary embodiments, a different number of TRPs may be used. Furthermore, it should be noted that some of the techniques below may also be applied to a group of beams and / or a group of TRPs. For example, a TRP beam failure indication may be configured to indicate a group of failed beams, where the beam group includes beams across multiple TRPs. Additionally, the methods described below may be similarly applied to link failure situations in which a TRP is experiencing a radio link failure.

[0020] In 301, the NE 320 may transmit any number of TRP failure indication configurations to the UE 310, which may include several dedicated / shared UL resources and / or related parameters and may be configured to enable the UE 310 to indicate that a TRP is experiencing a beam failure. For example, the dedicated / shared UL resources may be configured to carry any number of indications that at least one TRP meets a beam failure condition. These indications may 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 may be a CORESETPoolIndex, and the UE 310 may assume that CORESETs configured with the same CORESETPoolIndex are associated with the same TRP. Additionally or alternatively, the TRP indicator may be associated with any number of BFD-RS indices and may use a mapping and / or association between at least one TRP and at least one UL resource configured to carry the TRP beam failure indication.

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

[0022] At 303, the UE 310 may detect that at least one TRP, such as the NE 330, is in a beam failure state, such as the NE 330 meeting at least one beam failure condition threshold. The detection by the UE 310 may be based on at least one BFD-RS subset.

[0023] At 305, in response to the detection at 303, the UE 310 may select at least one resource and / or at least one parameter received at 301 for use in reporting at least one failed TRP (i.e., to the NE 330). In various embodiments, the UE 310 may select which resource and / or parameter to use based on which TRP has failed or, conversely, which TRP is not in a failed state and is not failed. In an example with two TRPs, the UE 310 may be configured to transmit at least one information bit, such as a one-bit length, associated with a particular resource to the NE 320 indicating that the NE 330 is in a beam failure state. In another example with more than two TRPs, the UE 310 may transmit at least one indicator of a failed TRP on a resource to the NE 320.

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

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

[0026] Using the identified resources and / or parameters from 305, the UE 310 may transmit at least one indication to the NE 320 at 307 indicating at least one failed TRP and / or failure condition. In some embodiments, the UE 310 may also transmit the at least one indication via explicit uplink control information (UCI). In an exemplary embodiment, the UE 310 may be served by two TRPs and configured with two configurations of dedicated periodic PUCCH resources of format 0, a first configuration may enable transmission to the NE 320 and a second configuration may enable transmission to the NE 330. Additionally, at least one TRP failure indication may be transmitted via PUCCH format 0, e.g., by signaling 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 may transmit a TRP failure indication to the NE 320 using the configuration of periodic PUCCH resources associated with the NE 320.

[0027] In some embodiments, the UE 310 may use a PUCCH format with a bitmap indicating the failed RSs associated with the failed TRPs in ascending or descending order of CORESET Index and / or CORESETPoolIndex. For example, if the UE 310 is configured with four BFD-RSs, the UE 310 may transmit explicit information of the failed TRP / failed PDCCH beam combination, allowing the network to identify the TRP failure using the bitmap information.

[0028] In various embodiments, PUSCH resources, such as configured grant resources, may be configured to carry a TRP failure indication. For example, various parameters / configurations, such as the DMRS of the configured grant resources, may carry the TRP failure indication. Additionally or alternatively, the UE 310 may include a TRP failure indication in the form of UCI on the PUSCH with or without uplink shared (transport) channel (UL-SCH) data. The UE 310 may select a suitable resource for transmitting the TRP failure indication using various associations between PUSCH resources and the serving TRP. For example, for two TRPs, two configured grant PUSCH configurations may carry the indication, and each configuration may correspond to a transmission directed to a different TRP, e.g., by explicitly associating each configured grant PUSCH configuration with a specific TRP. To avoid confusion where a configured grant opportunity is used only for data transmission, each configuration may be configured with two DMRSs, with a first DMRS used for the TRP failure indication and a second DMRS used only for data transmission. Thus, when a TRP fails, the UE 310 can notify the network by sending a DMRS indicating the beam failure to a non-failing TRP, such as the NE 320, using the configured grant configuration.

[0029] In some embodiments, the UE 310 may be configured with any combination of UL RSs, such as sounding reference signals (SRSs), resources, and associated parameters for transmitting a TRP failure indication. For example, in the case of two TRPs, two SRS resources may be used, with each SRS configured to carry a TRP failure indication. When a TRP fails, the UE 310 may transmit at least one SRS toward the non-failed TRP (i.e., the NE 320) to notify the network that the NE 330 has failed. Furthermore, the UE 310 may use at least one UL MAC CE to signal the TRP failure indication, and the UE 310 may request an UL grant over dedicated and / or shared SR resources to transmit a MAC CE indicating the TRP failure indication, such as when UL (PUSCH) resources are unavailable.

[0030] In some embodiments, the UE 310 may be configured with any number of aperiodic / semi-persistent beam reporting configurations that may be activated when the UE 310 transmits a TRP failure indication. For example, the UL indication may indicate to a network, such as the NE 320, that a failure has been detected on the NE 330, and in response, the UE 310 may receive a trigger to initiate beam reporting according to the configured UL resources. After a new PDCCH beam is configured for the UE 310, thereby activating the TCI state for the PDCCH, the UE 310 may suspend reporting and / or the reporting resources may be deactivated. Additionally or alternatively, if the UE 310 does not receive a new TCI state for the failed PDCCH after N reporting periods, the UE 310 may suspend reporting and / or suspend monitoring the PDCCH on the CORESET of the NE 330. In an exemplary embodiment, if the network triggers a beam report and cancels the report, the UE 310 may cease monitoring the PDCCH for the failed CORESET or CORESETs of the failed TRP. In an exemplary embodiment, the NE 320 may configure the UE 310 to provide a beam report, such as a CSI-ReportConfig, for a particular set of reference signals, such as in a CSI-ResourceConfig. The resource configuration and reporting may be specific to and conditioned on the indicated TRP.

[0031] FIG. 4 illustrates an example of a method performed by a UE to notify the network that an NE (e.g., a TRP) is in a beam failure state. The UE may be similar to the UE 610 illustrated in FIG. 6 according to some embodiments. While some techniques described below may discuss two TRPs in an exemplary embodiment, any number of TRPs may be used. Furthermore, it should be noted that some of the techniques below may also apply to a group of beams and / or a group of TRPs. For example, a TRP beam failure indication may be configured to indicate a group of failed beams, where a beam group includes beams across multiple TRPs. Additionally, the methods described below may similarly apply to link failure situations in which a TRP is experiencing a radio link failure.

[0032] In 401, the UE may receive any number of TRP failure indication configurations from a first NE / TRP, such as NE 620 of FIG. 6, which may include several dedicated / shared UL resources and / or related parameters, configured to enable the UE to indicate that the NE is experiencing a beam failure. For example, the dedicated / shared UL resources may be configured to carry any number of indications that at least one NE meets a beam failure condition. These indications may include an indication / indicator of the failed NE and / or any other information configured to identify / characterize the failed NE. In various embodiments, the TRP indicator may be a CORESETPoolIndex, and 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 a mapping and / or association between at least one NE and at least one UL resource configured to carry the TRP beam failure indication.

[0033] As an example, the TRP failure indication configuration may include periodic PUCCH resource configurations such as "config-1" and "config-2," each configured to transmit one bit of information (e.g., bit "1") indicating a failed TRP. Config-1 may assist the UE in indicating to a first NE that a second NE has failed, and conversely, config-2 may assist the UE in indicating to a second NE that a first NE has failed. In another example, the TRP failure indication configuration may provide / configure at least one UL MAC CE to transmit a TRP beam failure indication.

[0034] At 403, the UE may detect that at least one second NE / TRP, such as NE 620 of FIG. 6, is in a beam failure state, such as a failed NE satisfying at least one beam failure state threshold. The detection by the UE may be based on at least one BFD-RS subset. In another example, failure detection in a multi-TRP may be based on one set of BFD-RSs, and failure may be detected on a portion / subset of the BFD-RS resources in the set.

[0035] At 405, in response to the detection at 403, the UE may select at least one resource and / or at least one parameter received at 401 for use in reporting at least one second NE / TRP (i.e., NE 330). In various embodiments, the UE may select which resource and / or parameter to use based on which TRPs have failed or, conversely, which TRPs are not in a failed state and are not failed. In an example with two TRPs, the UE may be configured to transmit at least one information bit associated with a particular resource, such as a one-bit length, to the first NE indicating that the second NE is in a beam failure state. In another example with more than two TRPs, the UE may transmit at least one indicator of the second TRP on a resource to the first NE.

[0036] As an example, the UE may detect that the second NE is in a beam failure state and that the first NE is not in a beam failure state. Using the configuration received in 401, the UE may use config-1 to indicate the second NE. Specifically, the UE may transmit an information bit "1" to the first NE using a PUCCH resource provided in config-1. For example, config-1 may include a resource having PUCCH format 0, and a specific cyclic shift may be configured to indicate the information bit "1". Alternatively, the TRP failure indication configuration may cause the UE to indicate at least one indicator of the second NE (e.g., CORESETPoolIndex) to the first NE via the UL MAC CE.

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

[0038] Using the resources and / or parameters identified from 405, the UE may transmit at least one indication indicating a failure condition to at least one second NE and / or the first NE at 407. In some embodiments, the UE may also transmit the at least one indication via explicit uplink control information (UCI). In an exemplary embodiment, the UE may be served by two TRPs and configured with two configurations of dedicated periodic PUCCH resources of format 0, where a first configuration may enable transmission to one NE and a second configuration may enable transmission to the other NE. Additionally, at least one TRP failure indication may be transmitted via PUCCH format 0, e.g., by signaling with a single information bit, similar to a positive SR. As a result, in response to the UE detecting a TRP failure, the UE may transmit a TRP failure indication to the first NE using the configuration of periodic PUCCH resources associated with the second NE.

[0039] In some embodiments, failure detection and / or indication may be based on the BFD-RS resource set associated with a particular TRP or may be determined based on the active TCI status for the CORESETS of CORESETPoolIndex. In some embodiments, the UE may provide an indication of the failed BFD-RS resource set. This indication may indicate to the network that a particular TRP / network element is in a failure state. As an example, the UE may be configured with beam failure detection resource sets q0_0 and q0_1, which may be associated with TRP-1 and TRP-2, respectively. If the UE determines that a beam failure has occurred in at least one of the resource sets, the UE may indicate one or more failed resource sets. The resource sets for beam failure detection may have an explicit indicator, or the failure indication for the resource set may be associated with a recovery signaling configuration (e.g., a resource set-specific uplink signal or channel).

[0040] In some embodiments, the UE may use a PUCCH format with a bitmap indicating the failed RSs associated with the failed TRPs in ascending or descending order of CORESET index and / or CORESETPoolIndex. For example, if the UE is configured with four BFD-RSs, the UE may transmit explicit information of the failed TRP / failed PDCCH beam combination, allowing the network to identify TRP failures using the bitmap information.

[0041] In various embodiments, PUSCH resources, such as configured grant resources, may be configured to carry a TRP failure indication. For example, various parameters / configurations, such as DMRS of the configured grant resources, may carry the TRP failure indication. Additionally or alternatively, the UE may include a TRP failure indication in the form of UCI on the PUSCH with or without uplink shared (transport) channel (UL-SCH) data. The UE may select a suitable resource for transmitting the TRP failure indication using various associations between PUSCH resources and the serving TRP. For example, for two TRPs, two configured grant PUSCH configurations may carry the indication, and each configuration may correspond to a transmission directed to a different TRP, e.g., by explicitly associating each configured grant PUSCH configuration with a specific TRP. To avoid confusion where a configured grant opportunity is used only for data transmission, each configuration may be configured with two DMRSs, with the first DMRS used for the TRP failure indication and the second DMRS used only for data transmission. Therefore, when a TRP fails, the UE can notify the network by sending a DMRS indicating the beam failure to another NE / TRP using the configured grant configuration.

[0042] In some embodiments, the UE may be configured with any combination of UL RSs, such as sounding reference signals (SRSs), resources, and associated parameters for transmitting a TRP failure indication. For example, in the case of two TRPs, two SRS resources may be used, with each SRS configured to carry a TRP failure indication. When a TRP fails, the UE 310 may transmit at least one SRS toward the non-failed TRPs to inform the network that the NE has failed. Furthermore, the UE may use at least one UL MAC CE to signal the TRP failure indication, and the UE may request an UL grant via dedicated and / or shared SR resources to transmit a MAC CE indicating the TRP failure indication, such as when an UL PUSCH resource is unavailable.

[0043] In some embodiments, a UE may be configured with any number of aperiodic / semi-persistent beam reporting configurations that may be activated when the UE transmits a TRP failure indication. For example, the UL indication may indicate to the network, such as a non-failed NE, that a failure has been detected on the NE, and in response, the UE may receive a trigger to initiate beam reporting according to the configured UL resources. After a new PDCCH beam is configured for the UE, thereby activating the TCI state for the PDCCH, the UE may suspend reporting and / or the reporting resources may be deactivated. Additionally or alternatively, if the UE does not receive a new TCI state for the failed PDCCH after N reporting periods, the UE may suspend reporting and / or discontinue monitoring the PDCCH on the CORESET of the failed NE. In an exemplary embodiment, the non-failed NE may configure the UE to provide beam reporting, such as in a CSI-ReportConfig, for a specific set of reference signals, such as in a CSI-ResourceConfig. The resource configuration and reporting may be specific to and conditioned on the indicated TRP.

[0044] FIG. 5 illustrates an example of a method performed by an NE that has been notified by a UE that another NE (e.g., a TRP) is in a beam failure state. The NE may be similar to NE 620, as shown in FIG. 6, according to some embodiments. While an example is described below, it will be understood that other arrangements / numbers of NEs / TRPs may be used. Furthermore, it should be noted that some of the techniques below may also be applied to groups of beams and / or groups of TRPs. For example, a TRP beam failure indication may be configured to indicate a group of failed beams, where a beam group includes beams across multiple TRPs. Additionally, the methods described below may be similarly applied to link failure situations in which a TRP is experiencing a radio link failure.

[0045] In 501, the NE may transmit any number of TRP failure indication configurations to a UE, such as UE 610 of FIG. 6, which may include several dedicated / shared UL resources and / or related parameters and may be configured to enable the UE to indicate that a TRP is experiencing a beam failure. For example, the dedicated / shared UL resources may be configured to carry any number of indications that at least one TRP satisfies a beam failure condition. These indications may 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 may be a CORESETPoolIndex, and the UE may assume that CORESETs configured with the same CORESETPoolIndex are associated with the same TRP. Additionally or alternatively, the TRP indicator may be associated with any number of BFD-RS indices, which may use a mapping and / or association between at least one TRP and at least one UL resource configured to carry the TRP beam failure indication.

[0046] As an example, the TRP failure indication configuration may include periodic PUCCH resource configurations such as "config-1" and "config-2," each configured to transmit one bit of information (e.g., bit "1") indicating a failed TRP. Config-1 may assist the UE in indicating to a first NE that a second NE has failed, and conversely, config-2 may assist the UE in indicating to a second NE that a first NE has failed. In another example, the TRP failure indication configuration may provide at least one UL MAC CE for transmitting a TRP beam failure indication. At 503, the NE may receive at least one indication of a failed TRP from the UE using at least one resource / parameter from 501 selected by the UE.

[0047] 6 illustrates an example of a system according to some exemplary embodiments. In one exemplary embodiment, the system may include multiple devices, such as, for example, a UE 610 and / or a NE 620.

[0048] The UE 610 may include one or more of the following mobile devices, such as a mobile phone, a smartphone, a personal digital assistant (PDA), a tablet, 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 location device such as a sensor or smart meter, or any combination thereof.

[0049] The NE620 may be one or more of 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 (NG RAN), a serving gateway, a server, and / or any other access node, or a combination thereof.

[0050] One or more of these devices may include at least one processor, shown as 611 and 621, respectively. At least one memory may be provided in one or more of the devices, shown as 612 and 622. The memory may be fixed or removable. The memory may include computer program instructions or computer code contained therein. The processors 611 and 621 and the memories 612 and 622, or a subset thereof, may be configured to provide means corresponding to the various blocks in FIGS. 3-5. Although not shown, the device may also include positioning hardware, such as a global positioning system (GPS) or microelectromechanical systems (MEMS) hardware, that may be used to determine the device's location. Other sensors, such as a barometer, compass, etc., are permitted and may be included to determine position, elevation, orientation, etc.

[0051] 6, transceivers 613 and 623 may be provided, and one or more devices may also include at least one antenna, shown as 614 and 624, respectively. A device may have many antennas, such as an array of antennas configured for multiple-input multiple-output (MIMO) communications, or multiple antennas for multiple radio access technologies. For example, other configurations of these devices may be provided.

[0052] The transceivers 613 and 623 may be units or devices that may be configured for a transmitter, a receiver, or both a transmitter and a receiver, or both transmitting and receiving.

[0053] Processors 611 and 621 may be embodied by any computational or data processing device, such as a central processing unit (CPU), an application specific integrated circuit (ASIC), or equivalent device. The processors may be implemented as a single controller or multiple controllers or processors.

[0054] Memories 612 and 622 may 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 may be used. The memory may be combined on a single integrated circuit as the processor, or may be separate from one or more processors. Furthermore, the computer program instructions that may be stored in the memory and processed by the processor may be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language. The memory may be removable or non-removable.

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

[0056] In some embodiments, a device may include circuitry configured to perform any of the processes or functions illustrated in FIGS. 3-5. For example, the circuitry may be a dedicated hardware circuit implementation, such as analog and / or digital circuitry. In another example, the circuitry may be a combination of hardware circuitry and software, such as a combination of analog and / or digital hardware circuitry and software or firmware, and / or software (including digital signal processors) that cooperate to cause the device to perform various processes or functions, software, and any portion of a hardware processor having at least one memory. In yet another example, the circuitry may be a hardware circuit and / or processor, such as a microprocessor or portion of a microprocessor, that includes software, such as firmware, for operation. Software in the circuitry may be absent if not necessary for the operation of the hardware.

[0057] FIG. 7 illustrates an example of a 5G network and system architecture according to an embodiment. Several network functions are illustrated, which may be implemented as software running as part of a network device or dedicated hardware, as the network device itself or dedicated hardware, or as virtual functions running as a network device or dedicated hardware. The UE and NE illustrated in FIG. 7 may be similar to UE 610 and NE 620, respectively. The user plane function (UPF) may provide services such as intra-RAT and inter-RAT mobility, data packet routing and forwarding, packet inspection, user plane quality of service (QoS) processing, downlink packet buffering, and / or downlink data notification triggering. The application function (AF) primarily interfaces with the core network to facilitate application use of traffic routing and may interact with the policy framework.

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

[0059] Moreover, where appropriate, different functions or procedures described above may be performed in different orders and / or concurrently with one another. Moreover, one or more of the described functions or procedures may be optional or combined, if desired. Therefore, the foregoing description should be considered illustrative of the principles and teachings of some exemplary embodiments, and not limiting thereof.

[0060] Those skilled in the art will readily appreciate that the exemplary embodiments described above may be implemented in a different order and / or with hardware elements in different configurations than those disclosed. Thus, while several embodiments have been described based on these exemplary embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent while remaining within the spirit and scope of the exemplary embodiments. (Part of the glossary) 3GPP Third Generation Partnership Project 5G Fifth Generation 5GC Fifth Generation Core 5GS Fifth Generation System AMF Access and Mobility Management Function ASIC Application Specific Integrated Circuit BFD-RS Beam Failure Detection Reference Signal BLER Block Error Rate BS Base Station CBRA Contention-Based Random Access CBSD Citizens Broadband Radio Service Device CE Control Element CFRA Contention-Free Random Access CG Configured Grant CN Core Network CORESET Control Resource Set CPU Central Processing Unit CSI Channel State Information CSI-RS Channel State Information Reference Signal CRI Channel State Information Reference Signal Resource Indicator dBmW Decibel-milliwatts DCI Downlink Control Information DL Downlink DMRS Demodulation Reference Signal DRS Downlink Reference Signal eMBB Enhanced Mobile Broadband eMTC Enhanced Machine Type Communication eNB Evolved Node B eOLLA Enhanced Outer Loop Link Adaptation EPS Evolved Packet System FDD Frequency Division Duplex FR Frequency Range gNB Next Generation Node B GPS Global Positioning System HDD Hard Disk Drive IEEE Institute of Electrical and Electronics Engineers L1 Layer 1 L2 Layer 2 LTE Long-Term Evolution LTE-A Long-Term Evolution Advanced MAC Medium Access Control MBS Multicast and Broadcast Systems MCS Modulation and Coding Scheme MEMS Micro Electrical Mechanical System MIMO Multiple Input Multiple Output MME Mobility Management Entity mMTC Massive Machine Type Communication MPDCCH Machine Type Communication Physical Downlink Control Channel MTC Machine Type Communication NAS Non-Access Stratum NE Network Entity NG Next Generation NG-eNB Next Generation Evolved Node B NG-RAN Next Generation Radio Access Network NR New Radio NR-U New Radio Unlicensed PBC Physical Broadcast Channel PDA Personal Digital Assistance PDCCH Physical Downlink Control Channel PDSCH Physical Downlink Shared Channel PDU Protocol Data Unit PHY Physical PRACH Physical Random Access Channel PRB Physical Resource Block PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel QCL Quasi Co-location QoS Quality of Service RACH Random Access Channel RAM Random Access Memory RAN Radio Access Network RAT Radio Access Technology RE Resource Element RLC Radio Link Control RRC Radio Resource Control RS Reference Signal RSRP Reference Signal Received Power SMF Session Management Function SR Scheduling Request SRB Signaling Radio Bearer SSB Synchronization Signal Block TB Transport Block TCI Transmission Configuration Indicator TDD Time Division Duplex TR Technical Report TRP Transmission Reception Point TS Technical Specification Tx Transmission UCI Uplink Control INFORMATION UE User Equipment UL Uplink UMTS Universal Mobile Telecommunications System UPF User Plane Function URLLC Ultra-Reliable and Low-Latency Communication UTRAN Universal Mobile Telecommunications System Terrestrial Radio Access Network WLAN Wireless Local Area Network

Claims

1. receiving, by a user equipment, at least one network entity failure indication configuration; detecting, by the user equipment, that at least one first network entity satisfies at least one beam failure condition; selecting, by the user equipment, at least one resource based on the received at least one network entity failure indication configuration, wherein the at least one resource configures transmission of at least one indication that the detected at least one first network entity satisfies the at least one beam failure condition; transmitting, by the user equipment, the at least one indication of the at least one first network entity satisfying the at least one beam failure condition; Equipped with 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 indication of the detected at least one first network entity; method.

2. 2. The method of claim 1, wherein the step of transmitting the at least one indication is a step of transmitting the at least one indication to at least one second network entity, the at least one second network entity being in a non-fault state.

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

4. 2. The method of claim 1, wherein the detection that a network entity is in a beam failure condition is performed based on a subset of at least one beam failure detection reference signal associated with the network entity.

5. The method of claim 1, wherein at least one network entity failure indication is transmitted via at least one uplink reference signal.

6. 10. The method of claim 1, wherein the at least one indication comprises at least one medium access control control element transmitted over at least one physical uplink shared channel.

7. 2. The method of claim 1, wherein the user equipment is configured with at least one aperiodic or semi-persistent beam reporting configuration that is activated in response to the user equipment detecting the at least one first network entity that has failed or the user equipment transmitting a corresponding network entity failure indication.

8. sending, by the network entity, at least one network entity failure indication configuration; receiving, by the network entity, at least one indication that at least one first network entity satisfies at least one beam failure condition; Equipped with 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 indication of the at least one first network entity having failed; At least one resource is selected based on the at least one network entity failure indication configuration, and the at least one resource configures transmission of at least one indication that the detected at least one first network entity satisfies the at least one beam failure condition. method.

9. 9. The method of claim 8, wherein the network entity is in a non-fault state.

10. 10. The method of claim 8, wherein each of the at least one network entity fault indication configurations is associated with at least one network entity.

11. at least one processor; at least one memory containing computer program code; An apparatus comprising: The at least one memory and the computer program code, together with the at least one processor, perform at least: receiving at least one network entity failure indication configuration; detecting that at least one first network entity satisfies at least one beam failure condition; selecting at least one resource based on the at least one received network entity failure indication configuration, the at least one resource configuring transmission of at least one indication that the detected at least one first network entity satisfies the at least one beam failure condition; transmitting the at least one indication of the at least one first network entity satisfying the at least one beam failure condition; and causing the device to execute 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 indication of the detected at least one first network entity; Device.

12. 12. The apparatus of claim 11, wherein the at least one indication is sent to at least one second network entity, and the at least one second network entity is in a non-fault state.

13. 12. The apparatus of claim 11, wherein each of the at least one network entity fault indication configurations is associated with at least one network entity.

14. 12. The apparatus of claim 11, wherein the at least one indication comprises at least one medium access control control element transmitted over at least one physical uplink shared channel.

Images