Systems and methods for beam failure recovery for multi-dci mode

Abstract

Beam failure recovery (BFR) in multiple downlink control information (mDCI) mode may include receiving, by a user equipment (UE), a downlink reference signal (DL RS) set from a next-generation Node B (gNB). The DL RS set may be associated with a link between the UE and the gNB and indicate that beam failure detection (BFD) is to be performed for the link. The BFR may also include performing, by the UE, beam failure detection (BFD) for the link using the DL RS set, and performing, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam for the link by determining a beam having a reference signal received power (RSRP) greater than a reference signal received power (RSRP) threshold. The BFR may also include transmitting, by the UE, a beam failure recovery request (BFRQ) to the gNB indicating the link.

Description

TECHNICAL FIELD

[0001] The present application relates generally to wireless communication systems. BACKGROUND

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols can include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly referred to by the industry organization name Worldwide Interoperability for Microwave Access (WiMAX); and the IEEE 802.11 standard for wireless local area networks (WLANs), which is commonly referred to by the industry organization name Wi-Fi. In a 3GPP radio access network (RAN) in an LTE system, base stations can include RAN nodes such as evolved universal terrestrial radio access network (E-UTRAN) node Bs, also commonly designated as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs, and / or radio network controllers (RNCs) in the E-UTRAN, which communicate with wireless communication devices, commonly designated as user equipment (UE). In a fifth generation (5G) wireless RAN, RAN nodes can include 5G nodes, NR nodes, also referred to as next generation NodeBs or g NodeBs (gNBs).

[0003] A RAN uses a radio access technology (RAT) to communicate between RAN nodes and UEs. A RAN can include global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), universal terrestrial radio access network (UTRAN), and / or E-UTRAN, which provide access to communication services through a core network. Each RAN in a RAN operates according to a particular 3GPP RAT. For example, a GERAN implements GSM and / or EDGE RAT, a UTRAN implements universal mobile telecommunications system (UMTS) RAT or other 3GPP RAT, an E-UTRAN implements LTE RAT, and an NG-RAN implements 5G RAT. In certain deployments, an E-UTRAN can also implement 5G RAT.

[0004] The frequency bands of 5G NR can be split into two different frequency ranges. Frequency Range 1 (FR1) includes frequency bands below 6 GHz, some of which can be used by previous standards but can potentially be extended to cover a new spectrum product up to 7125 MHz. Frequency Range 2 (FR2) includes frequency bands from 24.25 to 52.6 GHz. The bands in the millimeter wave (mmWave) range of FR2 have shorter range but higher available bandwidth than the bands in FR1. The skilled person will recognize that these frequency ranges, provided by way of example, can vary over time or by region. BRIEF DESCRIPTION OF DRAWINGS

[0005] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0006] Figure 1 A system is shown in accordance with some embodiments.

[0007] Figure 2 A process is shown in accordance with some embodiments.

[0008] Figure 3 A diagram is shown in accordance with some embodiments.

[0009] Figure 4 A diagram is shown in accordance with some embodiments.

[0010] Figure 5 A system is shown in accordance with some embodiments.

[0011] Figure 6 An apparatus is shown in accordance with some embodiments.

[0012] Figure 7 An example interface is shown in accordance with some embodiments.

[0013] Figure 8 A component is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0014] In 3GPP Rel-16, operation with multiple transmission and reception points (multi-TRP) using a multi-downlink control information (mDCI) mode has been supported. Here, a UE can receive signals simultaneously from multiple TRPs, which are scheduled by multiple physical downlink control channels (PDCCHs). The PDCCHs from different TRPs can be transmitted from different control resource sets (CORESETs) with different CORESET-poolIndex values. The network can be deployed with ideal backhaul or non-ideal backhaul.

[0015] In 3GPP Rel-15 / Rel-16, beam failure recovery (BFR) operation has been supported. A UE can report beam failure for all CORESETs in a serving cell to a next generation Node B (gNB) and further report a new candidate beam to the gNB. The UE can determine an assumed block error rate (BLER) of a downlink reference signal (e.g., channel state information reference signal (CSI-RS)) that is quasi co-located (QCLed) with a CORESET to determine whether a beam for the CORESET has failed. The UE can determine a beam failure instance for the CORESET if the detected BLER is greater than a threshold. After detecting X consecutive beam failure instances for all CORESETs, the UE can declare a beam failure. The new candidate beam can be a beam with a reference signal received power (RSRP) greater than a threshold.

[0016] For the mDCI mode, a gNB can be deployed in a non-ideal backhaul mode. However, 3GPP Rel-15 / Rel-16 behavior can not recover from a beam failure between a gNB and a UE. This is because the UE only reports a beam failure and a potential new candidate beam after all CORESETs have beam failures. Thus, it can be a problem to determine how to perform beam failure recovery (BFR) between a gNB and a UE. More specifically, the problems can include how to detect a beam failure between a gNB and a UE, how to detect a new candidate beam (e.g., candidate beam detection, CBD) between a gNB and a UE, and how to report a beam failure event (beam failure recovery request, BFRQ) when declaring a beam failure. Some embodiments of the present disclosure can solve one or more such problems.

[0017] Solution - procedure

[0018] In some embodiments, a beam failure recovery (BFR) procedure can be performed for each link. Each link can be a link between a gNB and a UE. In some embodiments, a UE performs beam failure detection (BFD) and CBD simultaneously. In other embodiments, a UE first performs BFD and, after it declares a beam failure, the UE performs CBD.

[0019] Solution - beam failure detection

[0020] In some embodiments, in multi-DCI mode, a UE can detect BFD based on N (e.g., N = 2) downlink reference signal (DL RS) sets. In some embodiments, each DL RS set can correspond to CORESETs with the same CORESET-poolIndex. In some embodiments, the DL RS can be CSI-RS and / or synchronization signal block (SSB). In some embodiments, the DL RS can be configured through radio resource control (RRC) signaling. In some embodiments, if the DL RS is not configured (e.g., not configured through RRC signaling), the DL RS configured for transmission configuration indicator (TCI) state of CORESET can be used for beam failure detection. Here, for example, if there are two DL RSs configured as TCI states, the DL RS configured with QCL-typeD (e.g., spatial receiver (Rx) parameters) can be used. In some embodiments, the DL RS can be quasi co-located with the CORESET. In some embodiments, the BLER threshold and other BFD related parameters (e.g., BFD counter / timer) can be the same or different for each set.

[0021] Solution - candidate beam detection

[0022] In some embodiments, in multi-DCI mode, a UE can be configured with N (e.g., N = 2) downlink reference signal sets for candidate beam detection. In some embodiments, each DL RS set can correspond to BFR of CORESETs with the same CORESET-poolIndex. In some embodiments, the DL RS can be CSI-RS and / or SSB. In some embodiments, the DL RS can be configured through RRC signaling. Here, for example, a gNB can configure at least one DL RS for a set. In some embodiments, if the DL RS is not configured for a set, a default DL RS set can be used, e.g., SSB from the initial bandwidth part. In some embodiments, the N DL RS sets for candidate beam detection can be orthogonal. In some embodiments, the RSRP threshold can be the same or different for each set.

[0023] Solution - beam failure recovery request

[0024] In some embodiments, after the UE declares beam failure for a DL RS set of BFD, the UE can report a beam failure recovery request (BFRQ) to, for example, a gNB. In some embodiments, the BFRQ can be reported through a medium access control (MAC) control element (CE) (Option 1). In some embodiments, the BFRQ can be reported through a physical random access channel (PRACH) (Option 2). In some embodiments, the BFRQ can be reported through a physical uplink control channel (PUCCH) (Option 3). In some embodiments, for each option, after the UE receives a response from the gNB, the UE can apply a new beam to all CORESETs corresponding to the failed CORESET-poolIndex, or if no BFRQ related signal is transmitted from the PUCCH resource, the UE can apply a new beam to all PUCCH resources corresponding to the failed CORESET-poolIndex, after K (e.g., K = 28) symbols.

[0025] Solution - option 1

[0026] In some embodiments, the MAC CE can carry the BFRQ and can include one, a subset, or all of the following information: a failed serving cell index; a failed CORESET-poolIndex or a DL RS set index of BFD; a flag indicating whether a new beam is detected; a new beam index selected from the corresponding DL RS set for CBD. In some embodiments, one MAC CE can be used to indicate beam failure for one or more serving cells. In another example, one MAC CE can be used to indicate beam failure for one or more CORESET-poolIndex in one serving cell. In another example, one MAC CE can be used to indicate beam failure for one CORESET-poolIndex in one serving cell. In some embodiments, regarding the priority of MAC CE multiplexing, the priority of the MAC CE can be the same as that of the MAC CE for BFR in 3GPP Rel-16. In another example, the priority of the MAC CE can be lower or higher than that of the MAC CE for BFR in 3GPP Rel-16. In some embodiments, the MAC CE can be triggered by a dedicated scheduling request, which can be configured by higher layer signaling. In some embodiments, the response to the MAC CE can be a DCI for scheduling a new transmission with the same hybrid automatic repeat request (HARQ) process ID as the physical uplink shared channel (PUSCH) carrying the MAC CE.

[0027] Solution - option 2

[0028] In some embodiments, a UE can be configured with multiple PRACH resources, each PRACH resource associated with a DL RS for CBD. In some embodiments, the PRACH resources can be divided into N groups. For example, each group can be used for BFRQ for a CORESET-poolIndex. In some embodiments, the response to PRACH can be a PDCCH transmitted in a dedicated search space (SS) or a CORESET. In some embodiments, the dedicated SS or CORESET can be configured by higher layer signaling (e.g., RRC signaling).

[0029] Solution - option 3

[0030] In some embodiments, a UE can be configured by single-bit PUCCH resources, where each PUCCH resource is associated with a DL RS for CBD. In some embodiments, the PUCCH resources can be divided into N groups. For example, each group can be used for BFRQ for a CORESET-poolIndex.

[0031] In some embodiments, a UE can be configured by multiple-bit PUCCH resources, where each PUCCH resource is associated with a CORESET-poolIndex. In some embodiments, the PUCCH can be used to carry one, a subset, or all of the following information: a failed serving cell index; a failed CORESET-poolIndex or DL RS set index for BFD; a flag indicating whether a new beam is detected; a new beam index selected from the corresponding DL RS set for CBD. In some embodiments, the response to PUCCH can be a PDCCH transmitted in a dedicated search space (SS) or a CORESET. In some embodiments, the dedicated SS or CORESET can be configured by higher layer signaling (e.g., RRC signaling).

[0032] Solution - enabling multiple DCI Control signaling for BFR

[0033] In some embodiments, multi-DCI BFR can be enabled by explicit RRC signaling.

[0034] In some embodiments, multi-DCI BFR can be enabled by multiple DL RS sets for BFD. In some embodiments, if more than one set is configured, multi-DCI based BFR can be enabled. In some embodiments, if only one set is configured, 3GPP Rel-15 / Rel-16 based BFR can be enabled. In some embodiments, if no set is configured, BFR can be disabled.

[0035] In some embodiments, to determine whether a set is configured, the UE can detect whether a beamFailureDetectionCounter is configured. For example, if the beamFailureDetectionCounter is configured, the UE can determine that a set is configured. Otherwise, for example, if the beamFailureDetectionCounter is not configured, the UE can determine that a set is not configured.

[0036] Figure 1 A system 100 is shown in accordance with some embodiments. In the illustrated embodiment, the system 100 includes a gNB 102, a gNB 104, and a UE 106. The UE 106 and one or both of the gNB 102 and the gNB 104 can communicate with other user equipment using signals 108, signals 112, signals 116, and signals 120. For example, the gNB 102 and / or the gNB 104 are transmission and reception points (TRPs) in the system 100, and the UE 106 supports multi-TRP operation. In some embodiments, the gNB 102 transmits signals 110 in signals 108 to the UE 106, and the UE 106 transmits signals 114 in signals 112 to the gNB 102. In some embodiments, the gNB 104 transmits signals 122 in signals 120 to the UE 106, and the UE 106 transmits signals 118 in signals 116 to the gNB 104.

[0037] In 3GPP Rel-16, multi-transmission and reception point (multi-TRP) operation based on multi-downlink control information (mDCI) mode has been supported. For example, a UE 106 receives signals (e.g., signals 110 and signals 122) from multiple TRPs (e.g., gNB 102 and gNB 104) simultaneously, where the signals 110 and signals 122 are scheduled by multiple physical downlink control channels (PDCCHs). The PDCCHs from different TRPs (e.g., gNB 102, gNB 104) can be transmitted from different control resource sets (CORESETs) of each TRP with different CORESET-poolIndex values. In some embodiments, the signals 110 and / or signals 114 for communication between the UE 106 and the gNB 102 use a PDCCH from a CORESET 1 with a CORESET-poolIndex value of zero. In some embodiments, the signals 118 and / or signals 122 for communication between the UE 106 and the gNB 104 use a PDCCH from a CORESET 2 with a CORESET-poolIndex value of 1. In some embodiments, the network (e.g., gNB 102 and gNB 104) of the system 100 with mDCI mode can be deployed with ideal backhaul or non-ideal backhaul. For example, a system with ideal backhaul can have a latency of less than or about 2.5 microseconds and a throughput of up to or about 10 Gbps. A system with non-ideal backhaul can have a latency and throughput outside the range provided for ideal backhaul.

[0038] In 3GPP Rel-15 / Rel-16, beam failure recovery (BFR) operation has been supported. A UE (e.g., UE 106) can report beam (or signal) failure for all CORESETs in a serving cell and report a new candidate beam to a next generation NodeB (gNB). The UE 106 determines an assumed block error rate (BLER) of a downlink reference signal (e.g., channel state information reference signal (CSI-RS)) that is quasi co-located (QCLed) with a CORESET to determine whether a beam for the CORESET has failed. The UE 106 can consider a beam failure instance for a CORESET if a detected BLER is greater than a threshold. After detecting X consecutive beam failure instances for all CORESETs, the UE 106 can declare a beam failure. The new candidate beam can be a beam with a reference signal received power (RSRP) greater than a threshold.

[0039] In some embodiments, an alternative method is used to perform BFR operation. Here, it is not necessary to determine that beams for all CORESETs in a serving cell have failed. Instead, a beam failure instance can be determined by a UE (e.g., UE 106) by determining that beams for only a single CORESET for a gNB (e.g., gNB 102, gNB 104) have failed. Such BFR operation can allow for improved link recovery, which would be prevented if all beams for all CORESETs in a serving cell had failed.

[0040] Figure 2 2 shows a beam failure recovery (BFR) process 200 according to some embodiments. In the illustrated embodiment, at a UE 202 (e.g., Figure 1 UE 106 in ) and gNB 204 (e.g., Figure 1 The BFR process 200 is performed on a per-link basis between gNBs 102 and 104 in the network. It should be noted that the order of items shown in the process 200 may vary. Figure 2 Items may be combined and / or deleted where appropriate.

[0041] At item 206, the UE 202 receives control signaling for BFR from the gNB 204. In some embodiments, the control signaling is control signaling that enables multi-DCI BFR. In some embodiments, the control signaling can be explicit RRC signaling that enables multi-DCI BFR (e.g., enabling link-specific BFD and / or CBD). In some embodiments, the control signaling can be signaling of multiple downlink reference signal (DL RS) sets for BFD (or e.g., CBD) that enable multi-DCI BFR. Here, if the gNB 204 configures more than one (e.g., two or more) DL RS sets for BFD, the UE 202 determines that each link (e.g., each link associated with each DL RS set) enables multi-DCI based BFR (e.g., including BFD and / or CBD). If only one set is configured, the UE 202 determines that 3GPP Rel-15 / Rel-16 based BFR is enabled. If no set is configured, the UE 202 determines that BFR is disabled. In some embodiments, to determine whether a set (e.g., a DL RS set) is configured, the UE 202 detects whether a beamFailureDetectionCounter is configured. For example, if the beamFailureDetectionCounter is configured, the UE 202 determines that a set (e.g., a DL RS set) is configured. Otherwise, e.g., if the beamFailureDetectionCounter is not configured, the UE 202 determines that a set (e.g., a DL RS set) is not configured.

[0042] If multi-DCI BFR is configured, the process 200 continues to item 208. At item 208, the UE 202 receives DL RS for beam failure detection (BFD) and / or candidate beam detection (CBD) of one or more links between the UE 202 and the gNB 204 from the gNB 204. In some embodiments, the UE 202 receives one or more DL RS sets from the gNB 204 for each link between the UE 202 and the gNB 204, each containing one or more DL RS, where each DL RS set corresponds to a link between the UE 202 and the gNB 204, and each DL RS within each DL RS set is for a particular beam within that link. In some embodiments, the transmission at item 208 is periodically transmitted by the gNB 204 to the UE 202 and periodically received by the UE 202. The process 200 then continues to item 210, where BFD and / or CBD is performed by the UE 202 on a per-link basis according to the DL RS for the link. Thus, one or more instances of BFD and / or CBD can be performed at item 210 according to the number of links that are present.

[0043] In some embodiments, the DL RS of item 208 is used for BFD. In some embodiments, in multi-DCI mode, UE 202 detects BFD based on N (e.g., N=2) DL RS sets. For example, UE 202 determines that N DL RS sets have been configured (e.g., by gNB 204) for BFD and therefore indicates that BFD is to be performed. In some embodiments, each DL RS set may correspond to one or more CORESETs with the same CORESET-poolIndex. In some embodiments, the DL RS (e.g., the DL RS of a DL RS set) may be a CSI-RS and / or a synchronization signal block (SSB) that indicates that BFD is to be performed for the link. In some embodiments, the DL RS may be configured via radio resource control (RRC) signaling (e.g., by gNB 204). In some embodiments, if a DL RS is not configured (e.g., not configured via RRC signaling or configured as a CSI-RS or SSB), then the DL RS configured for the transmission configuration indicator (TCI) state of the CORESET (e.g., for each CORESET with the same CORESET-poolIndex) may be used for beam failure detection. Here, for example, if there are two DL RSs configured in the TCI state, then the DL RS configured with QCL-typeD (e.g., spatial receiver (Rx) parameters) may be used. In some embodiments, the DL RS may be quasi-co-located with the CORESET. In some embodiments, the BLER threshold and other BFD-related parameters (e.g., BFD counters / timers) may be the same or different for each set. In item 210, since the DL RS for the link is used for BFD, BFD is performed on the UE 202. The UE 202 may determine the BLER of the DL RS, which may be quasi-co-located (QCLed) with the CORESET, to determine whether the beam of the CORESET for the particular link has failed. If the detected BLER is greater than the threshold, UE 202 may determine a beam failure instance for the CORESET of the link.

[0044] Figure 3An example diagram 300 showing a relationship between DL RS and CORESET-poolIndex for BFD is shown, according to some embodiments. A DL RS set 302 corresponds to CORESETs for BFD and has a CORESET-poolIndex equal to zero, where the DL RS set 302 includes DL RS in CSI-RS 304 and DL RS in CSI-RS 306. A DL RS set 308 corresponds to CORESETs for BFD and has a CORESET-poolIndex equal to 1, where the DL RS set 308 includes DL RS in CSI-RS 310 and DL RS in CSI-RS 312.

[0045] Returning to Figure 2 In some embodiments, the item 208 DL RS is used for CBD. Here, in a multi-DCI mode, the UE 202 is configured with N (e.g., N = 2) DL RS sets for CBD. The UE 202 is thereby configured for CBD. In some embodiments, each DL RS set is configured for CBD (e.g., by the gNB 204). In some embodiments, for BFR, each DL RS set can correspond to one or more CORESETs with the same CORESET-poolIndex. In some embodiments, a DL RS (e.g., a DL RS of a DL RS set) can be a CSI-RS and / or SSB indicating that CBD is to be performed for the link. In some embodiments, a DL RS can be configured by RRC signaling. Here, for example, the gNB can configure at least one DL RS for a set. In some embodiments, if the UE 202 determines that no DL RS is configured for a set (or no DL RS set is configured), a default DL RS or DL RS set can be used, which may, for example, indicate that CBD is to be performed for the link. The default DL RS or DL RS set can be, for example, an SSB from an initial bandwidth part (e.g., an initial bandwidth used by the UE 202 to access the gNB 204) or an SSB from a current bandwidth part (e.g., a current bandwidth used by the UE 202 to access the gNB 204). In some embodiments, the N DL RS sets for CBD can be orthogonal. In some embodiments, for each set, the RSRP threshold is the same or different. In item 210, CBD is performed by the UE 202 because the DL RS of the link is used for CBD and the UE 202 is configured for CBD. The new candidate beam determined by the CBD can be a beam with a reference signal received power (RSRP) greater than an RSRP threshold.

[0046] Figure 4An example diagram 400 showing a relationship between DL RSs and CORSET-poolIndex for CBD is shown in accordance with some embodiments. A DL RS set 402 corresponds to CORESETs for CBD and has a CORESET-poolIndex equal to zero, where the DL RS set 402 includes DL RSs in CSI-RS 404, a DL RS set in SSB 406, and DL RSs in other formats 408. A DL RS set 410 corresponds to CORESETs for CBD and has a CORESET-poolIndex equal to 1, where the DL RS set 410 includes DL RSs in SSB 412, DL RSs in SSB 414, and DL RSs in other formats 416.

[0047] Returning to Figure 2 At item 212, the UE 202 receives DL RSs (e.g., DL RS sets; i.e., e.g., on a per-link basis) from the gNB 204. In some embodiments, the DL RS sets are for BFD. In some embodiments, the DL RS sets are for CBD. In some embodiments, the DL RS sets are for the other of BFD or CBD for each link that was not received by the UE 202 at item 208. In some embodiments, the transmission at item 212 is sent periodically by the gNB 204 to the UE 202 and received periodically by the UE 202. The description regarding item 212 is the same or substantially the same as the description of item 208, and therefore is not repeated for the sake of brevity. At item 214, BFD or CBD is performed by the UE 202 on a per-link basis in accordance with the DL RSs transmitted at item 212. Thus, one or more instances of BFD and / or CBD can be performed at item 210 in accordance with the number of links that are present. For each link, if the DL RSs of item 212 are for BFD, then BFD is performed by the UE 202 at item 214, and if the DL RSs of item 212 are for CBD, then CBD is performed by the UE 202 at item 214.

[0048] It should be noted that in some embodiments, the UE 202 performs BFD and CBD for one or more links simultaneously at item 210 and / or item 214, where item 208 and / or item 212 for the one or more links includes DL RSs for both BFD and CBD.

[0049] In some embodiments, UE 202 performs BFD and CBD in sequence. In some embodiments, BFD is at item 210, where item 208 includes DL RS for BFD. Process 200 then continues to item 216 to declare beam failure (if such failure is determined). Thereafter, process 200 continues to perform CBD, receiving DL RS for CBD after item 216 or at some other time prior to performing CBD.

[0050] At item 216, beam failure is declared using beam failure detection at item 210 or item 216.

[0051] At item 218, UE 202 transmits signaling to gNB 204. In some embodiments, after UE 202 declares beam failure for a set of DL RS for BFD, UE 202 reports a beam failure recovery request (BFRQ) in the signaling sent to gNB 204.

[0052] In some embodiments, BFRQ is reported by UE 202 through a medium access control (MAC) control element (CE) (Option 1). Here, the MAC CE carries the BFRQ and can include one, a subset, or all of the following information: a failed serving cell index; a failed CORESET-poolIndex or DL RS set index for BFD; a flag indicating whether a new beam is detected; a new beam index selected from the corresponding DL RS set for CBD. In some embodiments, one MAC CE can be used to indicate beam failure for one or more serving cells. In some embodiments, one MAC CE can be used to indicate beam failure for one or more CORESET-poolIndex in one serving cell. In some embodiments, one MAC CE can be used to indicate beam failure for 1 CORESET-poolIndex in one serving cell.

[0053] Regarding priority of MAC CE multiplexing, in some embodiments, the priority of the MAC CE is the same as the priority of the MAC CE for BFR in 3GPP Rel-16. In some embodiments, the priority of the MAC CE is lower or higher than the MAC CE for BFR in 3GPP Rel-16. In some embodiments, the MAC CE is triggered by a dedicated scheduling request, which is configured by higher layer signaling. In some embodiments, the response to the MAC CE can be a DCI for scheduling a new transmission with the same hybrid automatic repeat request (HARQ) process ID as the physical uplink shared channel (PUSCH) carrying the MAC CE.

[0054] In some embodiments, the BFRQ is reported by the UE 202 through a physical random access channel (PRACH) (Option 2). For example, the UE 202 can be configured with multiple PRACH resources, each PRACH resource being associated with a DL RS for CBD. In some embodiments, the PRACH resources can be divided into N groups. For example, each group can be used for BFRQ for a CORESET-poolIndex. In some embodiments, the PRACH resources can belong to a PRACH resource group of the same CORESET-poolIndex. In some embodiments, the response to the PRACH can be a PDCCH transmitted in a dedicated search space (SS) or a CORESET. In some embodiments, the dedicated SS or CORESET can be configured by higher layer signaling (e.g., RRC signaling).

[0055] In some embodiments, the BFRQ is reported by the UE 202 through a physical uplink control channel (PUCCH) (Option 3). For example, the UE 202 can be configured by single-bit PUCCH resources, each PUCCH resource being associated with a DL RS for CBD. In some embodiments, the PUCCH resources can be divided into N groups. For example, each group can be used for BFRQ for a CORESET-poolIndex.

[0056] In some embodiments, the UE 202 can be configured by multiple-bit PUCCH resources, each PUCCH resource being associated with a CORESET-poolIndex (e.g., same index for the same set). In some embodiments, the PUCCH can be used to carry one, a subset, or all of the following information: a failed serving cell index; a failed CORESET-poolIndex or DL RS set index for BFD; a flag indicating whether a new beam is detected; a new beam index selected from the corresponding DL RS set for CBD. In some embodiments, the response to the PUCCH can be a PDCCH transmitted in a dedicated search space (SS) or a CORESET. In some embodiments, the dedicated SS or CORESET can be configured by higher layer signaling (e.g., RRC signaling).

[0057] At item 220, UE 202 receives a response to the reported BFRQ of item 218 from gNB 204. In some embodiments, the response is an acknowledgement (e.g., “ACK”) regarding the BFRQ from gNB 204. In some embodiments, for each of options 1, 2, and 3, after UE 202 receives the response from gNB 204 at item 220, K (e.g., K=28) symbols, UE 202 may apply the new beam to all CORESETs corresponding to the failed CORESET-poolIndex, or if no BFRQ-related signal is transmitted from the PUCCH resource, UE 202 may apply the new beam to all PUCCH resources corresponding to the failed CORESET-poolIndex.

[0058] Figure 5 An exemplary architecture of a system 500 for a network according to various embodiments is shown. The following description is provided for an exemplary system 500 operating in conjunction with LTE system standards and 5G or NR system standards provided by 3GPP technical specifications. However, the exemplary embodiments are not limited in this regard and may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and the like.

[0059] like Figure 5 As shown, system 500 includes UE 502 and UE 504. In this example, UE 502 and UE 504 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronic devices, mobile phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, instrument clusters (ICs), heads-up display (HUD) devices, on-board diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), connected or “smart” appliances, MTC devices, M2M, IoT devices, etc.

[0060] In some embodiments, the UE 502 and / or the UE 504 can be IoT UEs, which can include a network access layer designed for low-power IoT applications that utilize short-lived UE connections. An IoT UE can utilize technologies such as M2M or MTC for exchanging data with an MTC server or device via a PLMN, ProSe or D2D communication, sensor network, or IoT network. The M2M or MTC data exchange can be a machine-initiated data exchange. IoT networks describe interconnecting IoT UEs, which can include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The IoT UEs can execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.

[0061] The UE 502 and the UE 504 can be configured to connect with, e.g., communicatively couple with, an access node or radio access node (shown as (R)AN 516). In embodiments, the (R)AN 516 can be an NG RAN or a SG RAN, an E-UTRAN, or a legacy RAN such as a UTRAN or GERAN. As used herein, the term “NG RAN” or like terms can refer to (R)AN 516 that operates in an NR or SG system, and the term “E-UTRAN” or like terms can refer to (R)AN 516 that operates in an LTE or 4G system. The UE 502 and the UE 504 utilize connections (or channels) (shown as connection 506 and connection 508, respectively), each of which comprises a physical communications interface or layer (discussed in further detail below).

[0062] In this example, the connection 506 and the connection 508 are air interfaces that implement a cellular-based communication protocol and can be consistent with GSM, CDMA, PTT, POC, UMTS, 3GPP LTE, SG, NR, and / or any other communication protocol discussed herein. In embodiments, the UE 502 and the UE 504 can also directly exchange communication data via a ProSe interface 510. The ProSe interface 510 can alternatively be referred to as a sidelink (SL) interface 110 and can comprise one or more logical channels, including but not limited to a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

[0063] The UE 504 is shown to be configured to access an AP 512 (also referred to as “WLAN node,” “WLAN,” “WLAN terminal,” “WT,” etc.) via connection 514. The connection 514 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 512 would comprise a wireless fidelity Router. In this example, the AP 512 can be connected to the Internet without being connected to the core network (described in further detail below) of the wireless system. In various embodiments, the UEs 504, the (R)AN 516, and the AP 512 can be configured to utilize LWA operation and / or LWIP operation. The LWA operation can involve UEs 504 in RRC CONNECTED, configured by the RAN node 518 or RAN node 520 to utilize radio resources of LTE and WLAN. The LWIP operation can involve UEs 504 using WLAN radio resources (e.g., the connection 514) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) sent over the connection 514. IPsec tunneling can include encapsulating the entire original IP packet and adding a new packet header, protecting the original header of the IP packet.

[0064] The (R)AN 516 can include one or more AN nodes, such as RAN nodes 518 and 520, implementing connectivity between the 5GC 502 and UEs 504. As used herein, the term “access node,” “access point,” or the like can describe equipment, which provides the radio

[0065] In some implementations, all or part of the RAN node 518 or RAN node 520 can be implemented as one or more software entities running on a server computer, e.g., as part of a virtual network, which can be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In these implementations, the CRAN or vBBUP can enable a RAN function split, such as a PDCP split wherein RRC and PDCP layers are operated by the CRAN / vBBUP and other L2 protocol entities are operated by individual RAN nodes (e.g., RAN node 518 or RAN node 520); a MAC / PHY split wherein RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP and the PHY layer is operated by individual RAN nodes (e.g., RAN node 518 or RAN node 520); or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers, and upper part of the PHY layer are operated by the CRAN / vBBUP and a lower part of the PHY layer is operated by individual RAN nodes. This virtualization framework allows the idle processor cores of the RAN node 518 or RAN node 520 to perform other virtualized applications. In some implementations, individual RAN nodes can represent individual gNBs connected to a gNB-CU (not shown) via separate F1 interfaces Figure 5 (not shown). In these implementations, the gNB-DUs can include one or more remote radio heads or RFEMs and the gNB-CU can be operated by a server (not shown) located in the (R)AN 516 or by a server pool in a similar manner as the CRAN / vBBUP. Additionally, or alternatively, one or more of RAN nodes 518 or RAN nodes 520 can be a next generation eNB (ng-eNB), which is a RAN node providing E-UTRA user plane and control plane protocol terminations towards the UEs 502 and 504, and connected via an NG interface (discussed below) to a SGC. In V2X scenarios, one or more of RAN nodes 518 or RAN nodes 520 can be a RSU or function as a RSU.

[0066] The term“roadside unit” or“RSU” can refer to any transportation infrastructure entity used for V2X communications. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE can be referred to as a“UE-type RSU,” an RSU implemented in or by an eNB can be referred to as an“eNB-type RSU,” an RSU implemented in or by a gNB can be referred to as a“gNB-type RSU,” and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside, which provides connectivity support to passing vehicle UEs (vUEs). The RSU can also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can operate on 5.9 GHz direct short-range communications (DSRC) band to provide extremely low latency communications required for high-speed events such as crash avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can operate on cellular V2X frequency bands to provide the low latency communications mentioned earlier as well as other cellular communications services. Additionally or alternatively, the RSU can operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the computing device and radio frequency circuitry of the RSU can be encased in a weatherproof package suitable for outdoor installation and can include a network interface controller to provide wired connectivity (e.g., Ethernet) to a traffic signal controller and / or backhaul network.

[0067] The RAN nodes 518 and / or the RAN nodes 520 can terminate the air interface protocol and can be the first point of contact for the UEs 502 and 504. In some embodiments, the RAN nodes 518 and / or 520 can perform various

[0068] In embodiments, the UEs 502 and 504 can be configured to communicate using OFDM communication signals with each other or with the RAN nodes 518 and / or 520 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communications) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise orthogonal

[0069] In some implementations, a downlink resource grid can be used for downlink transmissions from the RAN node 518 and / or the RAN node 520 to the UE 502 and / or the UE 504, while uplink transmissions can utilize a similar approach. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. For an OFDM system, such a time-frequency plane representation is a common practice. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain is reflected in the number of subframes

[0070] According to various embodiments, the UEs 502 and 504 and the RAN nodes 518 and / or 520 transmit (and receive) data using licensed medium (also referred to as“licensed spectrum” and / or“licensed bands”) and unlicensed shared medium (also referred to as“unlicensed spectrum” and / or“unlicensed bands”). The licensed spectrum can include channels that operate in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum can include the 5 GHz band.

[0071] To operate in the unlicensed spectrum, the UEs 502 and 504 and the RAN nodes 518 or 520 can operate using LAA, eLAA, and / or feLAA mechanisms. In these implementations, the UEs 502 and 504 and the RAN nodes 518 or 520 can perform one or more known clear channel assessment (CCA) mechanisms to contend for access to the unlicensed spectrum. The CCA mechanisms can include listening before talking, or LBT. The LBT procedures can include the CCA evaluation during the CCA observation time.

[0072] LBT is a mechanism by which equipment (e.g., UEs 502 and 504, RAN node 518 or 520, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a specific channel in the medium is sensed to be unoccupied). The medium sensing operation can include CCA, which utilizes at least ED to determine the presence or absence of other signals on a channel in order to determine if a channel is clear or busy. This LBT mechanism allows cellular / LAA networks to coexist with incumbent systems in the unlicensed spectrum, as well as with other LAA networks. The ED can include sensing RF energy levels on the intended transmission band for a period of time and comparing the sensed RF energy levels to a predefined or configured threshold.

[0073] In general, incumbent systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., mobile station (MS), such as UE 502, AP 512, etc.) intends to transmit, the WLAN node can first perform CCA before transmission. Additionally, in cases where more than one WLAN node senses the channel to be idle and transmits at the same time, a backoff mechanism is used to avoid collisions. The backoff mechanism can be a counter that is randomly introduced within the CWS, which is increased exponentially upon a collision and reset to a minimum value upon a successful transmission. The LBT mechanism designed for LAA is somewhat similar to the CSMA / CA of WLANs. In some implementations, the LBT procedure for a DL or UL transmission burst (including PDSCH or PUSCH transmissions) can have a variable length LAA contention window between X and Y ECCA slots, where X and Y are the minimum and maximum values of the CWS for LAA. In one example, the minimum CWS for LAA transmissions can be 9 microseconds (ps); however, the size of the CWS and the MCOT (e.g., transmission burst) can be based on government regulatory requirements.

[0074] The LAA mechanism builds on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is known as a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, resulting in a maximum aggregated bandwidth of 100 MHz. In FDD systems, the number of aggregated carriers can be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, individual CCs can have a different bandwidth from other CCs. In TDD systems, the number of CCs and the bandwidth of each CC is generally the same for DL and UL.

[0075] A CA also contains individual serving cells to provide individual CCs. The coverage range of a serving cell can differ, for example, because CCs on different frequency bands will experience different pathloss. A primary service cell or PCell can provide a PCC for both UL and DL, and can handle RRC and NAS related activities. Other serving cells are referred to as SCells, and each can provide individual SCCs for both UL and DL. SCCs can be added and removed as required, while changing the PCC can require the UE 502 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells can operate in unlicensed spectrum (referred to as“LAA SCells”), and are assisted by a PCell operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE can receive UL grants on configured LAA SCells with different PUSCH starting positions within the same subframe.

[0076] The PDSCH carries user data and higher-layer signaling to the UEs 502 and 504. Among other information, the PDCCH carries information about the transport format and resource allocations related to the PDSCH channel. It can also convey information about the transport format, resource allocation, and HARQ information related to the uplink shared channel to the UEs 502 and 504. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UEs 504 within a cell) can be performed at any of the RAN nodes 518 or 520 based on channel quality information fed back from any of the UEs 502 and 504. The downlink resource assignment information can be sent to a UE 504 on the PDCCH prior to the allocated traffic channel resources.

[0077] The PDCCH uses CCEs to carry control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruplets, which can then be permuted using a sub-block interleaver to spread out the probability of large peaks for a given antenna port. One or more of these CCEs can be used to transmit each PDCCH, where the number of CCEs used can be based on the size of the DCI and the channel conditions. One or more CCEs can be grouped to form a REG. Four consecutive REGs can form a PDCCH. The PDCCH carries DCI that can include information about uplink resources allocated to the UE, downlink resources, power control, and / or access control.

[0078] Some embodiments can use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments can utilize an EPDCCH for control information transmission using PDSCH resources. The EPDCCH can be transmitted using one or more ECCEs. Similar to above, each ECCE can correspond to nine sets of four physical resource elements known as an EREGs. In some cases, an ECCE can have other numbers of EREGs.

[0079] The RAN nodes 518 or the RAN nodes 520 can be configured to communicate with one another via interface 522. In embodiments where the system 500 is an LTE system (e.g., when CN 530 is an EPC), the interface 522 can be an X2 interface. The X2 interface can be defined between two or more RAN nodes (e.g., two or more eNBs, etc.) connected to the EPC, and / or between two eNBs connected to the EPC. In some implementations, the X2 interface can include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U can provide flow control mechanisms for user data packets transferred over the X2 interface, and can be used to communicate information about the delivery of user data between eNBs. For example, the X2-U can provide specific sequence number information for user data transmitted from a MeNB to an SeNB; information about successful in-sequence delivery of PDCP PDUs to a UE 502 from the SeNB for user data; information for PDCP PDUs that were not delivered to the UE 502; information for a current minimum desired buffer size at the SeNB for transmitting user data to the UE; etc. The X2-C can provide intra-LTE access mobility functionality, including context transfer from source to target eNBs, user plane transport control, etc.; load management functionality; and inter-cell interference coordination functionality.

[0080] In implementations where the system 500 is an SG or NR system (e.g., when the CN 530 is an SGC), the interface 522 can be an Xn interface. The Xn interface is defined between two or more RAN nodes (e.g., two or more gNBs, etc.) connected to a SGC, between a RAN node 518 (e.g., gNB) and an eNB connected to a SGC, and / or between two eNBs connected to a 5GC (e.g., the CN 530). In some implementations, the Xn interface can include an Xn-User plane (Xn-U) interface and an Xn-Control plane (Xn-C) interface. The Xn-U can provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and traffic control functionality. The Xn-C can provide management and error handling functionality, functionality to manage the Xn-C interface; mobility support for UE 502 in a connected mode (e.g., CM-CONNECTED) including functionality to manage the connected mode mobility of a UE from one or more RAN nodes 518 or RAN nodes 520 to another. The mobility support can include context transfer from an old (source) serving RAN node 518 to new (target) serving RAN node 520 and control of user plane tunnels between the old (source) serving RAN node 518 to new (target) serving RAN node 520. The protocol stack of the Xn-U can include a transport network layer built on Internet Protocol (IP) transport layer and a GTP-U layer on top of the UDP and / or IP layers to carry user plane PDUs. The Xn-C protocol stack can include an application layer signaling protocol (called Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. The SCTP can be on top of the IP layer, and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver the signaling PDUs. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack can be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0081] The (R)AN 516 is shown to be communicatively coupled to a core network— in this embodiment, to a CN 530. The CN 530 can include one or more network elements 532 that are configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UEs 502 and 504) who are connected to the CN 530 via the (R)AN 516. The components of the CN 530 can be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV can be used to virtualize any or all of the above-described network functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instantiation of the CN 530 can be referred to as a network slice, and a logical instantiation of a portion of the CN 530 can be referred to as a network sub-slice. NFV architectures and infrastructures can be used to virtualize one or more network functions on industry-standard server hardware, storage hardware, or switches comprising a combination of these (alternatively, performed by specialized hardware).

[0082] Generally, the application server 534 can be an element of a network infrastructure that provides content or services via a web interface to one or more UEs 502, 504. For example, the application server 534 can facilitate access to internet access services for UEs 502, 504 or provide access to content or services

[0083] In embodiments, the CN 530 can be an SGC, and the (R)AN 116 can connect with the CN 530 via an NG interface 524. In embodiments, the NG interface 524 can split into two parts: an NG user plane (NG-U) interface 526, which carries traffic data between the RAN node 518 or 520 and a UPF; and an SI control plane (NG-C) interface 528, which is a signaling interface between the RAN node 518 or 520 and an AMF.

[0084] In embodiments, the CN 530 can be an SG CN, while in other embodiments, the CN 530 can be an EPC. Where the CN 530 is an EPC, the (R)AN 116 can interface with the CN 530 via an S1 interface 524. In embodiments, the S1 interface 524 can be split into two parts: the S1 user plane (S1-U) interface 526, which carries traffic data between the RAN node 518 or RAN node 520 and the S-GW; and the S1-MME interface 528, which is a signaling interface between the RAN node 518 or RAN node 520 and the MME.

[0085] Figure 6 Exemplary components of the device 600 are illustrated. In some embodiments, the device 600 can include application circuitry 602, baseband circuitry 604, Radio Frequency (RF) circuitry (shown as RF circuitry 620), front-end module (FEM) circuitry (shown as FEM circuitry 630), one or more antennas 632, and power management circuitry (PMC) (shown as PMC 634) coupled together as shown in the figure. The components of the illustrated device 600 can be included in a UE or a RAN node. In some embodiments, the device 600 can include fewer elements (for example, a RAN node can not utilize application circuitry 602, and instead include a processor / controller to process IP data received from an EPC). In some embodiments, the device 600 can include additional elements such as memory / storage, displays, cameras, sensors, or input / output (I / O) interfaces.

[0086] The application circuitry 602 can include one or more application processors. For example, the application circuitry 602 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The one or more processors of the application circuitry 602 can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors can be coupled with or include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 600. In some embodiments, the processors of application circuitry 602 can process IP data packets received from an EPC.

[0087] The baseband circuitry 604 can include circuitry such as one or more single-core or multi-core processors. The baseband circuitry 604 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 620 and to generate baseband signals for a transmit signal path of the RF circuitry 620. The baseband circuitry 604 can interface with the application circuitry 602 for generation and processing of the baseband signals and for control of the RF circuitry 620. For example, in some embodiments, the baseband circuitry 604 can comprise a third generation (3G) baseband processor (3G baseband processor 606), a fourth generation (4G) baseband processor (4G baseband processor 608), a fifth generation (5G) baseband processor (5G baseband processor 610), or other baseband processor(s) 612 (e.g., second generation (2G), sixth generation (6G), etc.) of other existing, emerging, or future development generations. The baseband circuitry 604, for example one or more of the baseband processors, can handle various radio control functions

[0088] In some embodiments, the baseband circuitry 604 can include a digital signal processor (DSP), such as one or more audio DSP(s) 616. The one or more audio DSP(s) 616 can include elements for compression / decompression and echo cancellation, and in other embodiments can include other suitable processing elements. In some embodiments, components of the baseband circuitry can be combined on a single chip, in a single chipset, or as separate components on the same board. In some embodiments, some or all of the constituent components of the baseband circuitry 604 and the application circuitry 602 can be implemented together, such as on a system on a chip (SOC).

[0089] In some embodiments, the baseband circuitry 604 can provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 604 can support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 604 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0090] RF circuitry 620 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 620 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 620 can include a receive signal path, which can include circuitry to down-convert RF signals received from the FEM circuitry 630 and provide baseband signals to the baseband circuitry 604. RF circuitry 620 can also include a transmit signal path, which can include circuitry to up-convert baseband signals provided by the baseband circuitry 604 and provide RF output signals to the FEM circuitry 630 for transmission.

[0091] In some embodiments, the receive signal path of the RF circuitry 620 can include mixer circuitry 622, amplifier circuitry 624 and filter circuitry 626. In some embodiments, the transmit signal path of the RF circuitry 620 can include filter circuitry 626 and mixer circuitry 622. RF circuitry 620 can also include synthesizer circuitry 628 for synthesizing a frequency for use by the mixer circuitry 622 of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 622 of the receive signal path can be configured to down-convert RF signals received from the FEM circuitry 630 based on the synthesized frequency provided by synthesizer circuitry 628. The amplifier circuitry 624 can be configured to amplify the down-converted signals, and the filter circuitry 626 can be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to the baseband circuitry 604 for further processing. In some embodiments, the output baseband signals can be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 622 of the receive signal path can include passive mixers, although the scope of the embodiments is not limited in this respect.

[0092] In some embodiments, the mixer circuitry 622 of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 628 to generate RF output signals for the FEM circuitry 630. The baseband signals can be provided by the baseband circuitry 604 and can be filtered by filter circuitry 626.

[0093] In some embodiments, the mixer circuitry 622 of the receive signal path and the mixer circuitry 622 of the transmit signal path can include two or more mixers and can be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 622 of the receive signal path and the mixer circuitry 622 of the transmit signal path can include two or more mixers and can be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 622 of the receive signal path and the mixer circuitry 622 can be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 622 of the receive signal path and the mixer circuitry 622 of the transmit signal path can be configured for superheterodye operation.

[0094] In some embodiments, the output baseband signals and the input baseband signals can be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signals and the input baseband signals can be digital baseband signals. In these alternative embodiments, the RF circuitry 620 can include analog-to-digital converter (ADC) circuitry and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 604 can include a digital baseband interface to communicate with the RF circuitry 620.

[0095] In some dual-mode embodiments, separate radio ICs can be provided for processing signals for the

[0096] In some embodiments, the synthesizer circuitry 628 can be a fractional-N synthesizer or a fractional N / N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 628 can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer that includes a phase-locked loop with a frequency divider.

[0097] The synthesizer circuitry 628 can be configured to synthesize an output frequency for use by the mixer circuitry 622 of the RF circuitry 620 based on a frequency input and a divider control input. In some embodiments, synthesizer circuitry 628 can be a fractional N / N+1 synthesizer.

[0098] In some embodiments, the frequency input can be provided by a voltage controlled oscillator (VCO), although this is not a requirement. The divider control input can be provided by the baseband circuitry 604 or the application circuitry 602, such as an application processor, based on the desired output frequency. In some embodiments, the divider control input can be determined from a look-up table based on a channel indicated by the application circuitry 602.

[0099] Synthesizer circuitry 628 of the RF circuitry 620 can include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider can be a dual modulus divider (DMD) and the phase accumulator can be a digital phase accumulator (DPA). In some embodiments, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements can be configured to break a VCO period up into Nd equal phase segments. In this way, the DLL provides negative feedback to help assure that the total delay through the delay line is one VCO cycle.

[0100] In some embodiments, synthesizer circuitry 628 can be configured to generate a carrier frequency as an output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency), and used in conjunction with quadrature generator and divider circuitry, to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency can be a LO frequency (fLO). In some embodiments, the RF circuitry 620 can include an IQ / polar converter.

[0101] FEM circuitry 630 can include a receive signal path, which can include circuitry configured to operate on RF signals received from one or more antennas 632, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 620 for further processing. FEM circuitry 630 can also include a transmit signal path, which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 620 for transmission by one or more of the one or more antennas 632. In various embodiments, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry 620, solely in the FEM circuitry 630, or in both the RF circuitry 620 and the FEM circuitry 630.

[0102] In some embodiments, the FEM circuitry 630 can include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 630 can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 630 can include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (for example, to the RF circuitry 620). The transmit signal path of the FEM circuitry 630 can include a power amplifier (PA) to amplify input RF signals (for example, provided by the RF circuitry 620), and one or more filters to generate RF signals for subsequent transmission (for example, by one or more of the one or more antennas 632).

[0103] In some embodiments, the PMC 634 can manage power provided to the baseband circuitry 604. In particular, the PMC 634 can control power-source selection, voltage scaling, battery-charging, or DC-to-DC conversion. The PMC 634 can typically be included on the device 600 when the device 600 is capable of being powered by a battery, for example when the device 600 is included in a UE. The PMC 634 can increase the power conversion efficiency in providing the desired implementation size and heat dissipation characteristics.

[0104] Figure 6 The PMC 634 is shown to be coupled to only the baseband circuitry 604. However, in other embodiments, the PMC 634 can be coupled to and perform similar power management operations for other components such as, but not limited to, the application circuitry 602, the RF circuitry 620, or the FEM circuitry 630.

[0105] In some embodiments, the PMC 634 can control, or otherwise be part of, various power saving mechanisms of the device 600. For example, if the device 600 is in an RRC_Connected state, where it is still connected to a RAN node as it expects to receive traffic shortly, then it can enter a state known as Discontinuous Reception, DRX, after a period of inactivity. During this state, the device 600 can power down for brief intervals of time and thus save power. The device 600 wakes up periodically to monitor for traffic. In some embodiments, the actual time for monitoring traffic can be a short burst.

[0106] If there is no data traffic activity for an extended period of time, then the device 600 can transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 600 in this state wakes up periodically to listen to the network for paging notifications. If there is no paging message, then the device 600 goes back to sleep. The actual time for listening can be short bursts. In some embodiments, the actual time for listening can be in a few seconds. In some embodiments, if there is no user data traffic for an extended period of time, then the device 600 can transition off to a RRC_Inactive state, where it disconnects from the network but still stores configuration information for a cell. Like state RRC_Idle, the device 600 periodically wakes up to listen to the network for paging notifications. In some embodiments, the actual time for listening can be in a few seconds. In some embodiments, the device 600 in the RRC_Inactive state can transition back to RRC_Connected state quickly when user traffic becomes available.

[0107] An additional power saving mode can leave a device unable to use the network for longer than the paging interval (ranging from a few seconds to several hours). During this time, the device is completely unable to connect to the network and can be completely powered off. Any data sent during this time incurs a large delay and assumes that the delay is acceptable.

[0108] The processors of application circuitry 602 and baseband circuitry 604 can be used to execute instructions fetched from one or more memory units 616. The memory units 616 can be internal to, or external to, the processors. The various layers of the protocol stack can be implemented as one or more of these instructions. For example, layer 3, layer 2, or layer 1 functions can be executed by the processors of baseband circuitry 604, either alone or in combination, while layer 4 functions can be performed using data (e.g., packet data) received from these layers by the processors of application circuitry 602. As referred to herein, layer 3 can include a radio resource control (RRC) layer, described in further detail below. As referred to herein, layer 2 can include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, layer 1 can include a physical (PHY) layer of a UE / RAN node, described in further detail below.

[0109] Figure 7 An exemplary interface 700 of baseband circuitry, in accordance with some embodiments, is shown. As described above, Figure 6 The baseband circuitry 604 of FIG. 6 can include a 3G baseband processor 606, a 4G baseband processor 608, a 5G baseband processor 610, other baseband processor(s) 612, a CPU 614, and memory 618 used by the processors. As illustrated, each of the processors can include a respective memory interface 702 to send receive data to / from the memory 618.

[0110] The baseband circuitry 604 can also include one or more interfaces to communicate with other circuitries / devices, such as a memory interface 704 (e.g., an interface to send / receive data to / from memory external to the baseband circuitry 604); an application circuitry interface 706 (e.g., an interface to send / receive data to / from Figure 6 application circuitry 602 of FIG. 6); an RF circuitry interface 708 (e.g., an interface to send / receive data to / from RF circuitry 620); a wireless hardware connectivity interface 710 (e.g., an interface to send / receive data to / from Near Field Communication (NFC) components, Bluetooth® Figure 6 components, and other communication components (e.g., USB); components, and other communication components (e.g., USB); components, and other communication components (e.g., USB); components, and other communication components (e.g., USB); and a power management interface 712 (e.g., an interface to send / receive power or control signals to / from the PMC 634).

[0111] Figure 8 is a block diagram illustrating a component 800 that can read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and that can perform any one or more of the methodologies discussed herein, according to some example embodiments. Specifically, Figure 8 A diagrammatic representation of the hardware resources 802 is shown, including one or more processors 812 (or processor cores), one or more memory / storage devices 818, and one or more communication resources 820, each of which can be communicatively coupled via a bus 822. For embodiments wherein node virtualization (e.g., NFV) is utilized, a hypervisor 804 can be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 802.

[0112] The processors 812 (e.g., a central processing unit (CPU), a reduced instruction set computer (RISC) processor, a complex instruction set computer (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) can include, for example, a processor 814 and a processor 816.

[0113] The memory / storage devices 818 can include main memory, disk storage, or any suitable combination thereof. The memory / storage devices 818 can include, but are not limited to, any type of volatile or nonvolatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state memory, etc.

[0114] The communication resources 820 can include interconnection or network components such as a modem, a network interface card (e.g., Ethernet), a Bluetooth®, Bluetooth® Low Energy), and other communication components.

[0115] ​The instructions 824 can include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors 812 to perform any one or more of the methodologies discussed herein. The instructions 824 can reside completely, though not necessarily entirely, within at least one of the processors 812 (e.g., within the processor’s cache memory), the memory / storage devices 818, or any suitable combination thereof. Furthermore, any portion of the instructions 824 can be transferred between any combination of the hardware resources 802 and the databases 808 over the communications network 820. Accordingly, the memory of processors 812, the memory / storage devices 818, the peripherals 806, and the databases 808 are examples of computer-readable and machine-readable media.

[0116] For one or more embodiments, at least one of the components illustrated in one or more of the preceding figures can be configured to perform one or more operations, techniques, processes, and / or methods described in the following example section. For example, the baseband circuitry described above in connection with one or more of the preceding figures can be configured to operate according to one or more of the following examples. In another example, circuitry associated with a UE, base station, network element, etc. described above in connection with one or more of the preceding figures can be configured to operate according to one or more of the examples illustrated in the following example section.

[0117] Embodiments

[0118] The following embodiments relate to additional embodiments.

[0119] Example 1 includes a non-transitory computer-readable storage medium for a user equipment (UE) to perform beam failure recovery (BFR) in a multiple downlink control information (mDCI) mode. The computer-readable storage medium includes instructions that, when executed by a computer, cause the computer to: receive, by the UE from a next generation NodeB (gNB), a set of downlink reference signals (DL RSs) associated with a link between the UE and the gNB and indicating that beam failure detection (BFD) is to be performed for the link, the set of DL RSs being periodically received by the UE from the gNB. The instructions also cause the computer to perform, by the UE, beam failure detection (BFD) for the link using the set of DL RSs, the BFD determining a beam failure of the link by determining that a block error rate (BLER) of the link is greater than a BLER threshold. The instructions also control the computer to perform, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam of the link by determining a beam having a reference signal received power (RSRP) that is greater than an RSRP threshold. The instructions also control the computer to transmit, by the UE to the gNB, a beam failure recovery request (BFRQ) indicating the beam failure of the link.

[0120] Example 2 includes the non-transitory computer-readable storage medium of Example 1, wherein the DL RS set corresponds to one or more CORESETs with a same CORESET-poolIndex value.

[0121] Example 3 includes the non-transitory computer-readable storage medium of Example 1, wherein the DL RS set includes a DL RS that is a channel state information reference signal (CSI-RS) or a synchronization signal block (SSB) indicating that BFD is to be performed for the link.

[0122] Example 4 includes the non-transitory computer-readable storage medium of Example 3, wherein the DL RS is configured by radio resource control (RRC) signaling.

[0123] Example 5 includes the non-transitory computer-readable storage medium of Example 1, wherein the computer-readable storage medium includes instructions that cause the computer to: receive, by the UE from the gNB, an additional DL RS set, the additional DL RS set being associated with the link and configuring the UE for the CBD, the additional DL RS set being periodically received by the UE from the gNB.

[0124] Example 6 includes the non-transitory computer-readable storage medium of Example 5, wherein the additional DL RS set corresponds to one or more CORESETs with a same CORESET-poolIndex.

[0125] Example 7 includes the non-transitory computer-readable storage medium of Example 5, wherein the additional DL RS set includes a DL RS that is a channel state information reference signal (CSI-RS) or a synchronization signal block (SSB) indicating that CBD is to be performed for the link.

[0126] Example 8 includes the non-transitory computer-readable storage medium of Example 7, wherein the computer-readable storage medium includes instructions that cause the computer to: determine, by the UE, that the DL RS of the additional DL RS set is not configured by a gNB, and use, by the UE, a default DL RS, wherein the default DL RS is a SSB from an initial bandwidth part or a current bandwidth part and indicates CBD for the link.

[0127] Example 9 includes the non-transitory computer-readable storage medium of Example 1, wherein the BFRQ is via a medium access control control element (MAC CE) transmission, the MAC CE including a failing CORESET-poolIndex or a DL RS set index corresponding to the link.

[0128] Example 10 includes the non-transitory computer-readable storage medium of Example 1, wherein the BFRQ is transmitted using a physical random access channel (PRACH) transmission, wherein the UE is configured with PRACH resources associated with the DL RS of the CBD for the link, the PRACH resources belonging to a resource group for a same CORESET-poolIndex.

[0129] Example 11 includes the non-transitory computer-readable storage medium of Example 1, wherein the BFRQ is transmitted using a multi-bit PUCCH resource, wherein each of the PUCCH resources is associated with the same CORESET-poolIndex, and wherein each PUCCH resource includes a failing CORESET-poolIndex or a DL RS set index corresponding to the link.

[0130] Example 12 includes the non-transitory computer-readable storage medium of Example 1, wherein the computer-readable storage medium includes instructions that cause the computer to receive, by the UE from the gNB, a response regarding the BFRQ, and apply, by the UE, the candidate beam to one or more CORESETs corresponding to a failing CORESET-poolIndex or a DL RS set index corresponding to the link.

[0131] Example 13 includes the non-transitory computer-readable storage medium of Example 1, wherein the BFD and the CBD are performed sequentially.

[0132] Example 14 includes the non-transitory computer-readable storage medium of Example 1, wherein the BFD and the CBD are performed simultaneously.

[0133] Example 15 includes the non-transitory computer-readable storage medium of Example 1, wherein the computer-readable storage medium includes instructions that cause the computer to receive, at the UE from the gNB, control signaling enabling multi-DCI BFR.

[0134] Example 16 includes the non-transitory computer-readable storage medium of Example 15, wherein the control signaling is RRC signaling.

[0135] Example 17 includes the non-transitory computer-readable storage medium of Example 15, wherein the control signaling includes a plurality of DL RS sets configured for BFR, and wherein the computer-readable storage medium includes instructions that cause the computer to determine that multi-DCI BFR is enabled due to the presence of the plurality of DL RS sets configured for BFR.

[0136] Example 18 includes a method for beam failure recovery (BFR) in a multiple downlink control information (mDCI) mode. The method includes receiving, by a UE from a next generation NodeB (gNB), a set of downlink reference signals (DL RSs) associated with a link between the UE and the gNB and indicating that beam failure detection (BFD) is to be performed for the link, the set of DL RSs being periodically received by the UE from the gNB. The method further includes performing, by the UE, beam failure detection (BFD) for the link using the set of DL RSs, the BFD determining a beam failure of the link by determining a block error rate (BLER) of the link is greater than a BLER threshold. The method further includes performing, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam of the link by determining a beam having a reference signal received power (RSRP) greater than an RSRP threshold. The method further includes transmitting, by the UE to the gNB, a beam failure recovery request (BFRQ) indicating the beam failure of the link.

[0137] Example 19 includes an apparatus for a user equipment (UE) to perform beam failure recovery (BFR) in a multiple downlink control information (mDCI) mode. The apparatus includes a processor and a memory storing instructions that, when executed by the processor, configure the apparatus to receive, by a UE from a next generation NodeB (gNB), a set of downlink reference signals (DL RSs) associated with a link between the UE and the gNB and indicating that beam failure detection (BFD) is to be performed for the link, the set of DL RSs being periodically received by the UE from the gNB. The instructions further configure the apparatus to perform, by the UE, beam failure detection (BFD) for the link using the set of DL RSs, the BFD determining a beam failure of the link by determining a block error rate (BLER) of the link is greater than a BLER threshold. The instructions further configure the apparatus to perform, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam of the link by determining a beam having a reference signal received power (RSRP) greater than an RSRP threshold. The instructions further configure the apparatus to transmit, by the UE to the gNB, a beam failure recovery request (BFRQ) indicating the beam failure of the link.

[0138] Example 20 includes the apparatus of Example 19, wherein the set of DL RSs corresponds to one or more CORESETs having a same CORESET-poolIndex value.

[0139] Example 21 can include an apparatus comprising means for performing one or more elements of a method described in or related to any of the above examples or any other method, technique, or process described herein.

[0140] Example 22 can include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of the above examples. Example 23 can include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of the above examples.

[0141] Example 23 can include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of the above examples.

[0142] Example 24 can include a method, technique, or process as described in or related to any of the above examples or portions or parts thereof.

[0143] Example 25 can include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions to cause the one or more processors to perform a method, technique, or process as described in or related to any of the above examples, or portions thereof, when executed by the one or more processors.

[0144] Example 26 can include a signal as described in or related to any of the above examples or portions or parts thereof.

[0145] Example 27 can include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of the above examples or portions or parts thereof, or otherwise described in the present disclosure.

[0146] Example 28 can include a signal encoded with data as described in or related to any of the above examples or portions or parts thereof, or otherwise described in the present disclosure.

[0147] Example 29 can include a signal encoded with a datagram, packet, frame, segment, PDU, or message as described in or related to any of the above examples or portions or parts thereof, or otherwise described in the present disclosure.

[0148] Example 30 can include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform a method, technique, or process as described in or related to any of the above examples, or portions thereof.

[0149] Example 31 can include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of the above examples or portions thereof.

[0150] Example 32 can include a signal in a wireless network as shown and described herein.

[0151] Example 33 can include a method of communicating in a wireless network as shown and described herein.

[0152] Example 34 can include a system for providing wireless communication as shown and described herein.

[0153] Example 35 can include an apparatus for providing wireless communication as shown and described herein.

[0154] Any of the above examples can be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides functionality and / or technical advantages, but that does not mean that every implementation necessarily makes use of each one of the advantages described. It is possible for an implementation to result in advantages other than those specifically identified herein. Variations on these implementations can become apparent to those of ordinary skill in the art once the above teachings are considered. Numerous implementations can be practiced without resorting to the details of the above description. The scope of the following claims is to be accorded the broadest fair interpretation so as to encompass all implementations with equivalents.

[0155] Implementations of the systems and methods described herein can include various operations, which can be embodied in machine-executable instructions that are executed by a computer system. The computer system can include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system can include hardware components that include specific logic for performing the operations, or can include a combination of hardware, software, and / or firmware.

[0156] It will be recognized that the systems described herein include descriptions of specific implementations. These implementations can be combined, partially combined, separated into multiple systems, or otherwise divided or combined in other ways. Further, it is contemplated that parameters, attributes, aspects, etc. of one implementation can be used in another implementation. For clarity, these parameters, attributes, aspects, etc. are only described in one or more implementations, and it will be recognized that these parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another implementation unless specifically stated otherwise.

[0157] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly stated to users.

[0158] Although the foregoing has been described in considerable detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the invention. It should be noted that there are many alternative ways of implementing both the processes and the apparatus described herein. The embodiments of the present invention are therefore to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A non-transitory computer-readable storage medium for performing beam failure recovery (BFR) in a multiple downlink control information (mDCI) mode by a user equipment (UE), the computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to: receiving, by the UE from a next generation Node B (gNB), a downlink reference signal (DL RS) set associated with a link between the UE and the gNB and indicating that beam failure detection (BFD) is to be performed for the link, the DL RS set being periodically received by the UE from the gNB; performing, by the UE, beam failure detection (BFD) for the link using the DL RS set, wherein the BFD determines a beam failure of the link by determining that a block error rate (BLER) of the link is greater than a BLER threshold; performing, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam for the link by determining a beam having a reference signal received power (RSRP) greater than a RSRP threshold; as well as A medium access control element (MAC CE) is transmitted by the UE to the gNB, the MAC CE including a beam failure recovery request (BFRQ) indicating the link, the MAC CE including one or more of the following: a failed serving cell index, a failed CORESET-poolIndex or DL ​​RS set index of the BFD, a flag indicating whether a new beam is detected, and a new beam index selected from a corresponding DL RS set for CBD. 2 . The non-transitory computer-readable storage medium of claim 1 , wherein the DL RS set corresponds to one or more CORESETs having the same CORESET-poolIndex value.

3. The non-transitory computer-readable storage medium of claim 1, wherein the DL RS set comprises a DL RS that is a channel state information reference signal (CSI-RS) or a synchronization signal block (SSB) indicating that BFD is to be performed for the link. 4 . The non-transitory computer-readable storage medium of claim 3 , wherein the DLRS is configured through Radio Resource Control (RRC) signaling.

5. The non-transitory computer-readable storage medium of claim 1 , wherein the computer-readable storage medium stores instructions that cause the computer to: An additional DL RS set is received by the UE from the gNB, the additional DL RS set is associated with the link and the UE is configured for the CBD, and the additional DL RS set is periodically received by the UE from the gNB. 6 . The non-transitory computer-readable storage medium of claim 5 , wherein the additional DL RS set corresponds to one or more CORESETs having the same CORESET-poolIndex. 7 . The non-transitory computer-readable storage medium of claim 5 , wherein the additional DL RS set includes a DL RS that is a CSI-RS or an SSB indicating that CBD is to be performed for the link.

8. The non-transitory computer-readable storage medium of claim 7, wherein the computer-readable storage medium stores instructions that cause the computer to: Determining, by the UE, that the DL RS of the additional DL RS set is not configured by the gNB; and A default DL RS is used by the UE, wherein the default DL RS is an SSB from an initial bandwidth part or a current bandwidth part and indicates a CBD for the link.

9. The non-transitory computer-readable storage medium of claim 1 , wherein the BFRQ is transmitted using a physical random access channel (PRACH), wherein the UE is configured with a PRACH resource associated with a DL RS for the CBD of the link, the PRACH resource belonging to a resource group for the same CORESET-poolIndex.

10. The non-transitory computer-readable storage medium of claim 1 , wherein the BFRQ is transmitted using a multi-bit PUCCH resource, wherein each of the PUCCH resources is associated with the same CORESET-poolIndex, and wherein each PUCCH resource includes a failed CORESET-poolIndex or a DLRS set index corresponding to the link.

11. The non-transitory computer-readable storage medium of claim 1 , wherein the computer-readable storage medium stores instructions that cause the computer to: receiving, by the UE, a response from the gNB regarding the BFRQ; and The UE applies the candidate beams to one or more CORESETs corresponding to the failed CORESET-poolIndex or the DLRS set index corresponding to the link. 12 . The non-transitory computer-readable storage medium of claim 1 , wherein the BFD and the CBD are performed sequentially. 13 . The non-transitory computer-readable storage medium of claim 1 , wherein the BFD and the CBD are performed concurrently.

14. The non-transitory computer-readable storage medium of claim 1 , wherein the computer-readable storage medium stores instructions that cause the computer to: Control signaling for enabling multi-DCI BFR is received at the UE from the gNB.

15. The non-transitory computer-readable storage medium of claim 14, wherein the control signaling is RRC signaling.

16. The non-transitory computer-readable storage medium of claim 14, wherein the control signaling includes a plurality of DL RS sets configured for BFR, and wherein the computer-readable storage medium stores instructions that cause the computer to: It is determined that multi-DC IBFR is enabled due to the presence of the multiple DL RS sets configured for BFR.

17. A method for beam failure recovery (BFR) in multiple downlink control information (mDCI) mode, the method comprising: receiving, by a UE from a next generation Node B (gNB), a downlink reference signal (DLRS) set associated with a link between the UE and the gNB and indicating that beam failure detection (BFD) is to be performed for the link, the DL RS set being periodically received by the UE from the gNB; performing, by the UE, beam failure detection (BFD) for the link using the DL RS set, wherein the BFD determines a beam failure of the link by determining that a block error rate (BLER) of the link is greater than a BLER threshold; performing, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam for the link by determining a beam having a reference signal received power (RSRP) greater than a RSRP threshold; as well as A medium access control element (MAC CE) is transmitted by the UE to the gNB, the MAC CE including a beam failure recovery request (BFRQ) indicating the link, the MAC CE including one or more of the following: a failed serving cell index, a failed CORESET-poolIndex or DL ​​RS set index of the BFD, a flag indicating whether a new beam is detected, and a new beam index selected from a corresponding DL RS set for CBD.

18. An apparatus for a user equipment (UE) to perform beam failure recovery (BFR) in a multiple downlink control information (mDCI) mode, the apparatus comprising: processor; and a memory storing instructions that, when executed by the processor, configure the apparatus to: receiving, by the UE from a next generation Node B (gNB), a downlink reference signal (DL RS) set associated with a link between the UE and the gNB and indicating that beam failure detection (BFD) is to be performed for the link, the DL RS set being periodically received by the UE from the gNB; performing, by the UE, beam failure detection (BFD) for the link using the DL RS set, wherein the BFD determines a beam failure of the link by determining that a block error rate (BLER) of the link is greater than a BLER threshold; performing, by the UE, candidate beam detection (CBD) for the link, the CBD determining a candidate beam for the link by determining a beam having a reference signal received power (RSRP) greater than a RSRP threshold; as well as A medium access control element (MAC CE) is transmitted by the UE to the gNB, the MAC CE including a beam failure recovery request (BFRQ) indicating the link, the MAC CE including one or more of the following: a failed serving cell index, a failed CORESET-poolIndex or DL ​​RS set index of the BFD, a flag indicating whether a new beam is detected, and a new beam index selected from a corresponding DL RS set for CBD.

19. The apparatus of claim 18, wherein the DL RS set corresponds to one or more CORESETs having the same CORESET-poolIndex value.

Images