JP7764922B2 - Terminal device, network device, and methods implemented in the terminal device and network device - Google Patents

Description

Embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to methods, devices, and computer-readable media for beam failure recovery.

Due to increased free-space propagation loss in the higher frequency bands supported by new radio access (NR), channel/signal transmission relies on highly directional links. In other words, conventional communication systems require communication based on directional beams rather than omnidirectional communication. However, directional links require fine-tuning of the transmit and receive beams, which is achieved through a series of operations known as beam management. For example, beam management typically includes operations such as beam sweeping, beam measurement, beam determination, and beam reporting. By periodically repeating these operations, the optimal transmit and receive beam pair can be updated over time.

A beam failure may occur when the quality of a beam pair of an associated control channel is sufficiently degraded (e.g., compared to an associated timer threshold or timeout). When a beam failure occurs, a mechanism for recovering from the beam failure may be activated. A beam failure recovery mechanism on the terminal device (e.g., user equipment (UE)) side typically includes operations such as detecting a beam failure, identifying a new candidate beam, transmitting a beam failure recovery request, and monitoring a response to the beam failure recovery request from a network device. For example, the terminal device monitors a beam failure detection reference signal (RS) to evaluate whether a beam failure has occurred. When a beam failure occurs, the terminal device monitors a beam-identification RS to find a new candidate beam. Once a candidate beam is identified, the terminal device transmits a beam failure recovery request containing information about the identified candidate beam to the network device. The terminal device monitors the control channel search space to detect a response to the beam failure recovery request from the network device. When the terminal device receives a beam recovery acknowledgment from the network device, it can be determined that a new beam pair has been established and the beam failure has been recovered.

In NR, a network device (e.g., a next-generation NodeB (gNB)) can provide one primary cell (PCell) and at least one secondary cell (SCell) to serve a terminal device. However, in the current 3GPP specifications, beam failure recovery procedures are only applicable to beam failures that occur in the PCell.

Generally, exemplary embodiments of the present disclosure provide methods, devices, and computer-readable media for beam failure recovery.

In a first aspect, a method is provided for implementation in a terminal device. The method includes: the network device provides at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device; and, in response to detecting a beam failure in the SCell, determining, from the PCell and the SCell, a first cell from which a beam failure recovery (BFR) request is transmitted to the network device and a second cell from which a response to the BFR request is received from the network device; transmitting the BFR request to the network device in the first cell; and monitoring a control channel search space in the second cell to receive the response to the BFR request from the network device.

In a second aspect, a terminal device is provided. The terminal device includes a processor and a memory coupled to the processor. The memory stores instructions that, when executed by the processor, cause the terminal device to perform operations. The operations include: a network device provides at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device; and, in response to detecting a beam failure in the SCell, determining, from the PCell and the SCell, a first cell from which a beam failure recovery (BFR) request is transmitted to the network device and a second cell from which a response to the BFR request is received from the network device; transmitting the BFR request to the network device in the first cell; and monitoring a control channel search space in the second cell to receive the response to the BFR request from the network device.

In a third aspect, a computer-readable medium is provided having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to perform a method according to the first aspect of the present disclosure.

In a fourth aspect, there is provided a computer program product tangibly stored on a computer-readable medium, the computer program product including instructions that, when executed by at least one processor, cause the at least one processor to perform a method according to the first aspect of the present disclosure.

Other features of the present disclosure will become more readily apparent from the following description.

These and other objects, features, and advantages of the present disclosure will become more apparent through a more detailed description of several embodiments of the present disclosure in the accompanying drawings.

1 illustrates an exemplary communications network 100 in which embodiments of the present disclosure may be implemented.

2 illustrates an exemplary scenario 201 for the network 100 shown in FIG.

2 illustrates another exemplary scenario 202 for the network 100 shown in FIG.

2B illustrates a problem that may occur in the BFR procedure in the exemplary scenario 202 shown in FIG. 2B illustrates a problem that may occur in the BFR procedure in the exemplary scenario 202 shown in FIG.

4 illustrates a flowchart of an exemplary method 400 for beam failure recovery according to some embodiments of the present disclosure.

FIG. 5 is a simplified block diagram of a device 500 suitable for practicing embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numbers represent the same or similar elements.

The principles of the present disclosure will be described with reference to several exemplary embodiments. It will be understood that these embodiments are set forth for illustrative purposes only and to aid those skilled in the art in understanding and practicing the present disclosure, without implying any limitation on the scope of the present disclosure. The disclosure described herein can be embodied in various forms other than those described below.

In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "comprises" and variations thereof are read as open terms meaning "including, but not limited to." The term "based on" is read as "based at least in part on." The terms "one embodiment" and "embodiment" are read as "at least one embodiment." The term "another embodiment" is read as "at least one other embodiment." Terms such as "first," "second," etc. can refer to different objects or the same object. Other definitions, both explicit and implicit, may be included below.

In some instances, values, procedures, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," etc. It should be understood that such descriptions are intended to indicate that a selection may be made from among many available functional options, and that such a selection is not necessarily better, smaller, higher, or more preferred than other options.

As mentioned above, a beam failure may occur when the quality of a beam pair of an associated control channel degrades sufficiently (e.g., compared to a predetermined threshold or timeout of an associated timer). When a beam failure occurs, a mechanism for recovering from the beam failure may be activated. A beam failure recovery mechanism on the terminal device side typically includes operations such as detecting a beam failure, identifying a new candidate beam, transmitting a beam failure recovery request, and monitoring a response to the beam failure recovery request from the network device.

In NR, a network device (e.g., a next-generation NodeB (gNB)) can provide one primary cell (PCell) and at least one secondary cell (SCell) to serve a terminal device. However, in the current 3GPP specification, beam failure recovery procedures are only applicable to beam failures that occur in the PCell.

Embodiments of the present disclosure provide a solution for beam failure recovery to address one or more of the above challenges and other potential challenges. The beam failure recovery solution according to embodiments of the present disclosure can be applied to beam failures occurring in an SCell. Furthermore, embodiments of the present disclosure enable faster beam failure recovery than conventional beam failure recovery schemes.

The principles and embodiments of the present disclosure will be described in detail below with reference to Figures 1 to 5.

FIG. 1 illustrates an exemplary communication network 100 in which embodiments of the present disclosure may be implemented. The network 100 includes a network device 110 and a terminal device 120 served by the network device 110. The network 100 may provide one or more serving cells 102 to serve the terminal device 120. It should be understood that the number of network devices, terminal devices, and/or serving cells is for illustrative purposes only, without implying any limitations on the present disclosure. The network 100 may include any suitable number of network devices, terminal devices, and/or serving cells suitable for implementing embodiments of the present disclosure.

As used herein, the term "terminal device" refers to any device with wireless or wired communication capabilities. Examples of terminal devices include, but are not limited to, user equipment (UE), personal computers, desktops, mobile phones, cellular phones, smartphones, personal digital assistants (PDAs), portable computers, image capture devices such as digital cameras, gaming devices, music storage and playback devices, or Internet appliances that enable wireless or wired Internet access and browsing, etc. For purposes of discussion, some embodiments are described below with reference to a UE as an example of terminal device 220.

As used herein, the term "network device" or "base station" (BS) refers to a device that can provide or host a cell or coverage area over which terminal devices can communicate. Examples of network devices include, but are not limited to, a Node B (NodeB or NB), an Evolved Node B (eNodeB or eNB), a next-generation Node B (gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), and low-power nodes such as femto nodes and pico nodes.

For example, in some scenarios, the network 100 may support carrier aggregation (CA), in which two or more component carriers (CCs) are aggregated to support a wider bandwidth. In CA, the network device 110 may provide multiple serving cells (e.g., one serving cell per CC), including one primary cell (PCell) and at least one secondary cell (SCell), to serve the terminal device 120. The terminal device 120 may establish a Radio Resource Control (RRC) connection with the network device 110 in the PCell. Once the RRC connection between the network device 110 and the terminal device 120 is established and the SCell is activated via higher layer signaling, the SCell can provide additional radio resources.

In some other scenarios, for example, the terminal device 120 may establish connections with two different network devices (not shown in FIG. 1) and thereby utilize the radio resources of the two network devices. The two network devices may be defined as a master network device and a secondary network device, respectively. The master network device may provide a group of serving cells also referred to as a "Master Cell Group (MCG)." The secondary network device may also provide a group of serving cells also referred to as a "Secondary Cell Group (SCG)." In the case of dual connectivity operation, the term "Special Cell (SpCell)" may refer to the Pcell of the MCG or the Primary Scell (PScell) of the SCG, depending on whether the terminal device 120 is associated with the MCG or SCG, respectively. In cases other than dual connectivity operation, the term "SpCell" may also refer to the PCell.

In the communication network 100 shown in FIG. 1, the network device 110 can communicate data and control information to the terminal device 120, and the terminal device 120 can also communicate data and control information to the network device 110. The link from the network device 110 to the terminal device 120 is called the downlink (DL), and the link from the terminal device 120 to the network device 110 is called the uplink (UL).

Communications in network 100 may conform to any suitable standard, including, but not limited to, Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), GSM EDGE Radio Access Network (GERAN), and the like. Furthermore, communications may be performed in accordance with any currently known or future-developed generation of communications protocols. Examples of communications protocols include, but are not limited to, first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, and fifth-generation (5G) communications protocols.

A network device 110 (e.g., a next-generation NodeB (gNB)) may include one or more Transmission Reception Points (TRPs) or antenna panels. As used herein, the term "TRP" refers to an antenna array (having one or more antenna elements) available to a network device located in a particular geographic location. For example, a network device 110 may be connected to multiple TRPs in different geographic locations to achieve better coverage. The one or more TRPs may be included in the same serving cell or in different serving cells.

Figure 2A illustrates an exemplary scenario 201 of the network 100 shown in Figure 1. As shown in Figure 2A, for example, the network device 110 of Figure 1 may provide a PCell 210 and an SCell 220 to serve the terminal device 120. The PCell 210 and the SCell 220 may overlap each other. The network device 110 may be connected to a TRP 230 located in both the PCell 210 and the SCell 220.

Beam failure may occur when the network device 110 is no longer able to reach the terminal device 120 via a control channel (e.g., a Physical Downlink Control Channel (PDCCH)) due to incorrect beam adjustment, blockage effects, movement of the terminal device 120, or some other reason. For example, the terminal device 120 may detect such a situation by estimating the quality of virtual PDCCH reception transmitted via the beam used by the network device 110 to reach the terminal device 120. To perform beam failure detection, the terminal device 120 may estimate the quality of virtual PDCCH reception based on reception of a predetermined reference signal (RS). In the following description, this reference signal may also be referred to as a "beam failure detection RS" or "RS for beam failure detection." Examples of beam failure detection RS include, but are not limited to, a periodic Channel State Information Reference Signal (CSI-RS), a Synchronization Signal Block (SSB), or a combination thereof.

In the example shown in FIG. 2A, the PDCCH can be transmitted in both the PCell 210 and the SCell 220. For example, as shown in FIG. 2A, the PDCCH may be transmitted from the TRP 230 to the terminal device 120 via a DL beam 240-1 in the PCell 210, and from the TRP 230 to the terminal device 120 via another DL beam 240-2 in the SCell 220. In this case, beam failure can be detected in the PCell 210 or the SCell 220.

In some embodiments, in response to detecting a beam failure in the SCell 220, the terminal device 120 may first monitor a set of beam-specific RSs configured for the SCell to identify candidate beams for recovery from the beam failure. The terminal device 120 may include information about the candidate beams in a Beam Failure Recovery (BFR) request and transmit the BFR request including the information about the candidate beams to the network device 110 in the first cell.

In some embodiments, network device 110 provides at least PCell 210 and SCell 220 to serve terminal device 120, and in response to detecting a beam failure in SCell 220, terminal device 120 may determine from PCell 210 and SCell 220 a first cell from which a BFR request is transmitted to network device 110 and a second cell from which a response to the BFR request is received from network device 110. Terminal device 120 may transmit a BFR request to network device 110 in the determined first cell. Thereafter, terminal device 120 may monitor the control channel search space in the second cell to receive a response to the BFR request from network device 110.

In some embodiments, a quasi-colocation (QCL) type may be configured for the RS. The quasi-colocation type may be one of the following values: QCL-TypeA {Doppler shift, Doppler spread, mean delay, delay spread}, QCL-TypeB {Doppler shift, Doppler spread}, QCL-TypeC {Doppler shift, mean delay}, and QCL-TypeD {Spatial Rx parameters}.

In some embodiments, beam failure recovery procedures may differ for different scenarios. PCell 210 and SCell 220 may be associated with a first frequency range FR1 and a second frequency range FR2, respectively. For example, the first frequency range FR1 may be less than 6 GHz, and the second frequency range FR2 may be greater than or equal to 6 GHz. In some embodiments, for example, in the exemplary scenario 201 shown in FIG. 2A, the first frequency range FR1 may be the same as or different from the second frequency range FR2. In some embodiments, in this case, BFR may be required only in the SCell, but not in the PCell. In some embodiments, for example, in the exemplary scenario 201 shown in FIG. 2A, PCell 210 and SCell 220 may be configured with the same frequency range, e.g., FR2. In some embodiments, in this case, the DL beam in the PCell and the DL beam in the SCell have similar characteristics. For example, if the DL beam in the PCell is blocked, the DL beam in the SCell may also be blocked at the same time. In some embodiments, for example, in the exemplary scenario 201 shown in FIG. 2A, both PCell 210 and SCell 220 may be configured with the same frequency range, e.g., FR1. In some embodiments, in this case, BFR may not be required for both PCell 210 and SCell 220. For example, if all of the RSs configured for PCell 210 and SCell 220 are not configured with QCL-Type D, BFR may not be required for both PCell 210 and SCell 220.

2A , the PCell 210 and the SCell 220 may be configured with the same frequency range. For example, in this case, intra-band CA, in which intra-band contiguous CCs are aggregated, may be supported. In this case, when a beam failure is detected in the SCell, another beam failure may be simultaneously detected in the PCell. In this case, BFR may be required only in the PCell. Furthermore, if a beam failure detection RS is configured for the SCell 220, this beam failure detection RS may be QCL-Type D with at least one beam failure detection RS configured for the PCell 210. Alternatively or additionally, if a beam-specific RS is configured for the SCell 220, this beam-specific RS may be QCL-Type D with at least one beam-specific RS configured for the PCell 210. In other words, in this case, cross-carrier quasi-colocation (QCL) can be supported.

In some embodiments, for example, in the exemplary scenario 201 shown in FIG. 2A, the PCell 210 and the SCell 220 may be configured in the same frequency range. For example, in this case, intra-band CA, in which intra-band contiguous CCs are aggregated, may be supported. In some embodiments, in this case, the set of beam failure detection RSs may be configured only for the PCell, instead of the SCell. Correspondingly, the set of beam-specific RSs may also be configured only for the PCell, instead of the SCell.

In some embodiments, PCell 210 and SCell 220 may be associated with a first frequency range FR1 and a second frequency range FR2, respectively. For example, in the exemplary scenario 201 shown in FIG. 2A, FR1 may be different from FR2. Furthermore, the frequency range associated with SCell 220 may exceed the frequency range associated with PCell 210. In some embodiments, the determined first cell from which a BFR request is transmitted to network device 110 may be SCell 220 (e.g., in this case, also referred to as "BFR on SCell UL" in the following text). Alternatively, in some embodiments, the determined first cell from which a BFR request is transmitted to network device 110 may be PCell 210 (e.g., in this case, also referred to as "BFR on PCell UL" in the following text). In some other embodiments, the determined second cell from which a response to the BFR request is received from network device 110 may be PCell 210 (e.g., in this case, also referred to as "BFR on PCell DL" in the following text). Alternatively, in some other embodiments, the determined second cell from which a response to the BFR request is received from network device 110 may be SCell 220 (e.g., in this case, also referred to as "BFR on SCell DL" in the following text). In some embodiments, the determined first cell from which the BFR request is transmitted to network device 110 is SCell 220, and the determined second cell from which a response to the BFR request is received from network device 110 may be PCell 210 (e.g., in this case, also referred to as "BFR on SCell UL and PCell DL" in the following text).

In some embodiments, for the case of "BFR on SCell UL," transmission of the BFR request may be triggered by a PDCCH order. In some embodiments, in this case, before transmitting the BFR, the terminal device 120 may transmit a request for a PDCCH order on the PCell 210. In some embodiments, the request for a PDCCH order may be transmitted via the Physical Uplink Control Channel (PUCCH) or the Physical Random Access Channel (PRACH) in the PCell 210. For example, the request for a PDCCH order may be transmitted on the PCell 210 using at least one of a specific sequence, a specific time resource, a specific frequency resource, and a specific cyclic shift of the PUCCH or PRACH sequence. For example, the index of the identified candidate beam may not be carried in the request. In response to receiving a PDCCH order from the network device 110, the terminal device may transmit a BFR request to the network device 110 on the SCell 220. That is, in this case, the PDCCH order can trigger the transmission of BFR across carriers. In some embodiments, for example, a field occupying some reserved bits in the PDCCH order can be used to indicate the index of the cell to which the BFR request is transmitted. For example, three bits may be used in the PDCCH order to indicate the cell index.

In some embodiments, if the PDCCH order triggers a PRACH transmission of a BFR request in SCell 220, the random access preamble index bit field in the PDCCH order may be fixed to 0. For example, the 6 bits for the random access preamble index may be fixed to 0. In some embodiments, the SS/PBCH index field and/or the PRACH mask index field may be reserved.

In some embodiments, if a PDCCH order triggers a PRACH transmission of a BFR request in SCell 220, terminal device 120 may ignore the random access preamble index bit field in the PDCCH order. In some embodiments, the random access preamble index for the PRACH transmission of a BFR request in SCell 220 may be based on the index of the identified candidate beam in SCell 220.

In some embodiments, for the "BFR on SCell UL" case, transmission of the BFR request may be triggered by a PDCCH order. In some embodiments, in this case, before transmitting the BFR, the terminal device 120 may transmit a request for a PDCCH order on the SCell 220. In response to receiving the PDCCH order from the network device 110, the terminal device may transmit a BFR request to the network device 110 on the SCell 220. In some embodiments, in this case, the DL beam for the PDCCH order transmission may be the identified candidate beam. For example, the index of the identified candidate beam may be carried in the BFR request.

In some embodiments, for the "BFR on SCell UL" case, in response to detecting beam failure in SCell 220, terminal device 120 may transmit a BFR request in SCell 220 directly to network device 110 without requesting a PDCCH order from network device 110. In some embodiments, the BFR request may be transmitted over a Physical Random Access Channel (PRACH) to initiate a Contention Free Based Random Access (CFRA) procedure for BFR. Contention Based Random Access (CBRA) may not be supported in SCell. Thus, in some embodiments, if the BFR timer expires, SCell failure may be reported to network device 100 over PCell 210 rather than initiating a CBRA procedure in SCell 220. For example, additional status in a Channel State Information (CSI) report may be used to indicate SCell failure. Alternatively or additionally, specific PRACH resources may be configured for reporting SCell failures in the PCell. Furthermore, it may not be necessary to use one of the set of candidate beams (corresponding to the set of beam-specific RSs) configured for the PCell to report SCell failures.

In some embodiments, for the "BFR on SCell UL" case, the transmission of the BFR request may be triggered by a PDCCH order. In some embodiments, in this case, before transmitting the BFR, the terminal device 120 may transmit a request for a PDCCH order on the PCell 210. In response to receiving a PDCCH order from the network device 110, the terminal device may transmit a BFR request on the SCell 220 to the network device 110. That is, in this case, the PDCCH order can trigger the transmission of the BFR across carriers. In some embodiments, for example, a field occupying some reserved bits in the PDCCH order can be used to indicate the index of the cell for which the BFR request is triggered.

In some embodiments, for the "BFR on SCell UL and PCell DL" case, in response to detecting beam failure in SCell 220, terminal device 120 may transmit a BFR request in SCell 220 directly to network device 110 without requesting a PDCCH order from network device 110. In some embodiments, the BFR request may be transmitted over a physical random access channel (PRACH) to initiate a non-contention-based random access (CFRA) procedure for BFR. Contention-based random access (CBRA) may not be supported in SCell. Thus, in some embodiments, if the BFR timer expires, SCell failure may be reported to network device 100 in PCell 210 rather than initiating a CBRA procedure in SCell 220. For example, additional status in a channel state information (CSI) report may be used to indicate SCell failure. Alternatively or additionally, specific PRACH resources may be configured for reporting SCell failures in the PCell. Furthermore, it may not be necessary to use one of the set of candidate beams (corresponding to the set of beam-specific RSs) configured for the PCell to report SCell failures.

In some embodiments, for the case of "BFR on SCell UL and PCell DL," BFR based on CFRA may be supported in SCell 220. In some embodiments, in this case, terminal device 120 may monitor the control channel search space in PCell 210 to receive a response to the BFR request from network device 110. For example, the BFR request may be transmitted via a PRACH resource in SCell 220. In some embodiments, the PRACH resource may be QCL'd with an identified candidate beam in SCell 220. In some embodiments, if QCL-Type D is not configured for any RS in PCell 210, "BFR on SCell UL and PCell DL" is not available.

In some embodiments, for the "BFR on SCell UL and PCell DL" case, the terminal device 120 may monitor the PCell 210 for a response to the BFR request while the BFR request is being transmitted via the PRACH in the SCell 220. In some embodiments, the subcarrier spacing (SCS) associated with the PCell may be different from the SCS associated with the SCell. In some embodiments, in this case, the time interval for monitoring the response in the PCell may be determined based on the SCS associated with the PCell 210 or the SCell 220. For example, assuming that the slot for transmitting the BFR request in the SCell 220 is slot #n, the slot for receiving a response to the BFR request in the PCell 210 may be slot #(n'+k). Here, slot #n' is the closest slot in PCell 210 that overlaps with slot #n in SCell 220, and time interval k can be determined based on the SCS associated with PCell 210 or SCell 220.

In some embodiments, when a BFR request is transmitted on the SCell 220 (e.g., to initiate a CFRA-based BFR) and the BFR timer for the CFRA-based BFR expires, a CBRA-based BFR may be triggered. For example, a CBRA-based BFR may be triggered only by a PDCCH order. In some embodiments, in this case, in response to receiving a PDCCH order to trigger a CBRA-based BFR, the terminal device 120 may transmit a BFR request via the PRACH to initiate a CBRA-based BFR. In some embodiments, the terminal device 120 may monitor the PCell 210 for a response to the BFR request.

FIG. 2B illustrates another exemplary scenario 202 of the network 100 shown in FIG. 1. As shown in FIG. 2B, for example, the network device 110 of FIG. 1 may provide a PCell 210 and an SCell 220 to serve the terminal device 120. For example, the PCell 210 and the SCell 220 may not overlap each other. The network device 110 may be connected to two TRPs 230-1 and 230-2 located in the PCell 210 and the SCell 220, respectively.

Beam failure may occur when the network device 110 is no longer able to reach the terminal device 120 via a control channel (e.g., a PDCCH) due to incorrect beam adjustment, blockage effects, movement of the terminal device 120, or some other reason. For example, the terminal device 120 may detect such a situation by estimating the quality of the virtual PDCCH reception transmitted via the beam used by the network device 110 to reach the terminal device 120. To perform beam failure detection, the terminal device 120 may estimate the quality of the virtual PDCCH reception based on reception of a predetermined beam failure detection RS.

2B, the PDCCH can be transmitted in both the PCell 210 and the SCell 220. For example, as shown in FIG. 2B, the PDCCH may be transmitted from the TRP 230-1 to the terminal device 120 via a DL beam 240-1 in the PCell 210, and from the TRP 230-2 to the terminal device 120 via another DL beam 240-2 in the SCell 220. In this case, beam failure can be detected in the PCell 210 or the SCell 220. For example, in response to detecting beam failure in the SCell 220, the terminal device 120 may first monitor a set of beam-specific RSs configured for the SCell to identify candidate beams for recovery from the beam failure. The terminal device 120 may transmit a BFR request including information about the candidate beams to the network device 110 to initiate a random access procedure for BFR. The terminal device 120 may then monitor the control channel search space to receive a response to the BFR request.

In the exemplary scenario 202 shown in FIG. 2B, assuming that a BFR request is transmitted from the terminal device 120 to the network device 110 on the PCell 210 and a response to the BFR request is transmitted from the network device 110 to the terminal device 120 on the PCell 210 (i.e., "BFR on PCell UL and PCell DL"), some problems may occur.

3A and 3B illustrate a problem that may occur in the BFR procedure in the exemplary scenario 202 shown in FIG. 2B. As shown in FIG. 3A, TRPs 230-1 and 230-2, located in PCell 210 and SCell 220, respectively, are distant from each other. A DL beam 240-2 from TRP 230-2 may be detected as having failed, and a candidate beam 310 may be identified for recovery from the beam failure. Under current 3GPP specifications, a BFR request may be transmitted from terminal device 120 to network device 110 in the direction of candidate beam 320. In this case, as shown in FIG. 3A, TRP 230-1 in PCell 210 cannot receive the BFR request. Furthermore, under current 3GPP specifications, a response to the BFR request may be transmitted from network device 110 to terminal device 120 in the direction of candidate beam 320. In this case, as shown in FIG. 3B, terminal device 120 cannot receive the response to the BFR request. That is, the current 3GPP specifications do not support BFR on PCell UL and PCell DL.

Embodiments of the present disclosure can solve the problems shown in Figures 3A and 3B.

In some embodiments, the network device 110 provides at least the PCell 210 and the SCell 220 to serve the terminal device 120, and in response to detecting a beam failure in the SCell 220, the terminal device 120 may determine, from the PCell 210 and the SCell 220, a first cell from which a beam failure recovery (BFR) request is transmitted to the network device 110 and a second cell from which a response to the BFR request is received from the network device 110. The terminal device 120 may transmit the BFR request to the network device 110 in the determined first cell. The terminal device 120 may then monitor the control channel search space in the second cell to receive a response to the BFR request from the network device 110.

In some embodiments, for example, in the exemplary scenario 202 shown in FIG. 2B, the determined first cell from which a BFR request is transmitted to the network device 110 may be the PCell 210, and the determined second cell from which a response to the BFR request is received from the network device 110 may also be the PCell 210 (i.e., "BFR on PCell UL and PCell DL").

In some embodiments, for a beam failure in SCell 220, there may be only one PRACH resource configured in PCell 210 for transmitting a BFR request or beam failure report. In this case, the identified new candidate beam does not need to be associated with a PRACH resource. For example, PCell 210 may configure new SCell measurements in response to receiving a BFR request or beam failure report.

In some embodiments, when a BFR request is transmitted in PCell 210, the UL beam for transmitting the BFR request may reuse a beam in PCell 210. For example, the QCL parameter for transmitting the BFR request (i.e., PRACH transmission) may not be determined based on an identified new candidate beam, but may be determined based on the TCI (Transmission Configuration Indicator) state of the core set (CORESET) with the lowest identifier configured in the most recent slot for PCell 210, or any one of the beam failure detection RS or beam failure detection RS with the lowest identifier in PCell 210, or some other RS or TCI state in PCell 210. For example, the terminal device 120 may determine the UL beam for transmitting the BFR request based on the set of beam failure detection resources configured for the PCell.

In some embodiments, one PRACH resource for transmission of a BFR request may correspond to one beam in PCell 210 and another beam in SCell 220. Beam obstruction occurring in PCell 210 or SCell 220 may be indicated by different cyclic shift (CS) values or different cover codes used for PRACH transmission.

In some embodiments, a first set of PRACH resources, sequences, or preambles may be configured for transmission of a BFR request in PCell 210, and a second set of PRACH resources, sequences, or preambles may be used to indicate identified different candidate beams in PCell 210. In some embodiments, transmission of a BFR request in SCell 220 may also be based on at least one of the first set of PRACH resources, sequences, or preambles. In some embodiments, when a BFR request for a beam failure in SCell 220 is transmitted in PCell 210, a timing advance value in PCell 210 may be applied to the PRACH transmission of the BFR request. For example, if there is no time difference in the BFR request received at network device 110 (because a timing advance value was applied to the PRACH transmission of the BFR request), the PRACH transmission may be considered a BFR for a beam failure in SCell 220. In some embodiments, when a BFR request for a beam failure in PCell 210 is transmitted in PCell 210, there may not be a timing advance value available in PCell 210. For example, if there is a time difference in the BFR request received at network device 110 (because no timing advance value applies to the PRACH transmission of the BFR request), the PRACH transmission may be considered a BFR for a beam failure in PCell 210.

In some embodiments, when a response to a BFR request is received at PCell 210, the DL beam for transmission of the response may reuse a beam in PCell 210. For example, the QCL parameter for the control resource set configured for BFR ("CORESET-BFR") may not be determined based on an identified new candidate beam, but may be determined based on, for example, the TCI state of the CORESET with the lowest identifier configured in the most recent slot for PCell 210, or any one of the beam failure detection RS or beam failure detection RS with the lowest identifier in PCell 210, or some other RS or TCI state in PCell 210. For example, the terminal device 120 may determine the DL beam for detection of the response based on the set of beam failure detection resources configured for PCell 210. For example, the response to the BFR request may be a random access response (RAR) received at PCell 210. The RAR received by PCell 210 may indicate recovery from beam failure in SCell 220.

In some embodiments, when a response to a BFR request for an SCell is received at PCell 210, the response may be free of a timing adjustment command. In some embodiments, the response to the BFR request may be transmitted over a PDCCH. In some embodiments, the PDCCH may be a compact PDCCH. For example, no scheduling information may be present on the PDCCH. As another example, the response may be free of a timing adjustment command. In some embodiments, the response to the BFR request may be DCI format 0_0 and/or DCI format 1_0. In some embodiments, the response to the BFR request may be transmitted over a PDCCH with a CSI request and/or a PDCCH order.

In some embodiments, if a BFR request is transmitted on PCell 210 and a response to the BFR request is received on SCell 220, the QCL parameters for CORESET-BFR may be determined based on the identified new candidate beam. However, in some embodiments, if SCell 220 is not configured with CORESET-BFR, BFR may not be required in SCell 220.

In some embodiments, a first set of BFR parameters (e.g., BFR counter, BFR time, etc.) in PCell 210 may be used for beam failure in PCell 210. In some embodiments, if a BFR request for beam failure in SCell 220 is transmitted in PCell 210, a second set of BFR parameters (e.g., BFR counter, BFR time, etc.) in PCell 210 may be used for beam failure in SCell 220. For example, the first set of BFR parameters may be different from the second set of BFR parameters. In some embodiments, BFR in SCell 220 may reuse preamble resources used for BFR in PCell 210, but the BFR counter or timer for BFR in SCell 220 and the counter or timer for BFR in PCell 210 may be separate from each other.

In some embodiments, as described above, to perform beam failure detection, the terminal device 120 may estimate the quality of virtual PDCCH reception based on reception of a predetermined reference signal (RS). For example, the RS may be a CSI-RS. The reception power of the CSI-RS in the SCell 220 may be determined based on an SSB defined in the SCell 220. However, in some embodiments, an SSB may not be defined in the SCell 220. In some embodiments, in this case, the power of the CSI-RS in the SCell 220 may be determined based on the power of the SSB in the PCell 210.

FIG. 4 illustrates a flowchart of an exemplary method 400 for beam failure recovery according to some embodiments of the present disclosure. Method 400 may be implemented in the terminal device 120 illustrated in FIGS. 1, 2A, and/or 2B. It should be understood that method 400 may include additional operations not illustrated and/or omit some illustrated operations, and the scope of the present disclosure is not limited in this respect.

In block 410, the network device provides at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device, and in response to detecting a beam failure in the SCell, the terminal device determines, from the PCell and the SCell, a first cell from which a beam failure recovery (BFR) request is transmitted to the network device and a second cell from which a response to the BFR request is received from the network device.

In block 420, the terminal device transmits a BFR request to the network device in the first cell.

In block 430, the terminal device monitors the control channel search space in the second cell to receive a response to the BFR request from the network device.

In some embodiments, the first cell is an SCell, and the second cell is either a PCell or an SCell. The terminal device may transmit a BFR request by transmitting a request for a PDCCH order on the PCell and, in response to receiving the PDCCH order from the network device, transmitting a BFR request to the network device on the SCell.

In some embodiments, the second cell is an SCell, and the PDCCH order is received from the network device in either the PCell or the SCell.

In some embodiments, the first cell is a PCell, and the terminal device may transmit the BFR request by determining a first resource for transmitting the BFR request based on a set of beam failure detection resources configured for the PCell, and transmitting the BFR request to the network device via the first resource.

In some embodiments, the second cell is a PCell, and the terminal device monitors the control channel search space by determining a quasi-co-location (QCL) parameter associated with the control channel search space based on the candidate beam, and monitoring the control channel search space based on the QCL parameter.

In some embodiments, the first cell is an SCell and the second cell is a PCell. The terminal device may transmit the BFR request by determining, based on the candidate beam, a QCL parameter associated with a physical random access channel (PRACH) for transmitting the BFR request, and transmitting the BFR request via the PRACH based on the QCL parameter.

It can be seen that embodiments of the present disclosure provide a solution for beam failure recovery. The beam failure recovery solution according to embodiments of the present disclosure can be applied to beam failures occurring in an SCell. Furthermore, embodiments of the present disclosure enable faster beam failure recovery than conventional beam failure recovery schemes.

Figure 5 is a simplified block diagram of a device 500 suitable for implementing embodiments of the present disclosure. Device 500 can be considered a further exemplary embodiment of network device 110 or terminal device 120 shown in Figure 1. Thus, device 500 can be implemented in or as at least a portion of network device 110 or terminal device 120.

As shown, device 500 includes a processor 510, a memory 520 connected to processor 510, a suitable transmitter (TX) and receiver (RX) 540 connected to processor 510, and a communications interface connected to TX/RX 540. Memory 510 stores at least a portion of a program 530. TX/RX 540 is for bidirectional communication. TX/RX 540 has at least one antenna to facilitate communication, although in practice there may be multiple access nodes referred to herein. The communications interface may represent any interface required for communication with other network elements, such as an X2 interface for bidirectional communication between eNBs, an S1 interface for communication between a Mobility Management Entity (MME)/Serving Gateway (S-GW) and eNBs, a Un interface for communication between eNBs and relay nodes (RNs), or a Uu interface for communication between eNBs and terminal devices.

The program 530 is assumed to include program instructions that, when executed by an associated processor 510, enable the device 500 to operate in accordance with embodiments of the present disclosure, as described herein with reference to Figures 1-4. The embodiments herein may be implemented by computer software executable by the processor 510 of the device 500, by hardware, or by a combination of software and hardware. The processor 510 may be configured to implement various embodiments of the present disclosure. Furthermore, the combination of the processor 510 and the memory 520 may form a processing means 550 suitable for implementing various embodiments of the present disclosure.

Memory 520 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, including, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory devices, and removable memory. While only one memory 520 is shown in device 500, device 500 may have multiple physically separate memory modules. Processor 510 may be of any type suitable for a local technology network and may include, by way of non-limiting example, one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a DSP (Digital Signal Processor), and a processor based on a multi-core processor architecture. Device 500 may have multiple processors, such as application-specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

In general, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. While various aspects of embodiments of the present disclosure have been illustrated and described using block diagrams, flowcharts, or some other graphical representations, it should be understood that these blocks, apparatus, systems, techniques, or methods described herein may be implemented in, by way of non-limiting example, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or some combination thereof.

The present disclosure further provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions that execute on a target real or virtual processor device, such as those included in program modules, to perform the processes or methods described above with reference to FIG. 4. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or divided among the program modules described in various embodiments. The machine-executable instructions for the program modules may be executed in a local device or a distributed device. In a distributed device, the program modules may be located in both local and remote storage media.

Program code for executing the methods of the present disclosure may be written in any combination of one or more programming languages. Such program code is provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, so that, when executed by the processor or controller, the functions/operations specified in the flowcharts and/or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

The program code may be embodied on a machine-readable medium, which may be any tangible medium capable of containing or storing a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include an electrical connection of one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Furthermore, although acts are depicted in a particular order, this should not be understood as requiring such acts to be performed in the particular order or sequential order depicted, or that all of the depicted acts be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Similarly, while the above description includes details of several specific embodiments, these should not be construed as limiting the scope of the disclosure, but rather as descriptions of features specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the present disclosure has been described in terms specific to structural features and/or methodological acts, it should be understood that the present disclosure, as defined by the appended claims, is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are described as example forms of implementing the claims.

Claims (22)

A terminal device,
A terminal device, comprising: a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device; and means for transmitting information for beam failure recovery (BFR) to the network device, indicating a candidate beam and an index of the SCell, in response to detection of a beam failure in the SCell; the terminal device transmitting the information for BFR without requesting scheduling or after a request requesting scheduling of transmission of the information for the BFR is transmitted; and the beam failure of the SCell is indicated by the state of a channel state information (CSI) report. means for monitoring a physical downlink control channel (PDCCH) to receive a response to the BFR information from the network device;
Further provided with
The terminal device according to claim 1 . the request is transmitted prior to the transmission of the information for the BFR.
The terminal device according to claim 1 . means for transmitting the request to the network device, the request being transmitted in a particular cyclic shift;
The terminal device according to claim 1 . The means for sending the request includes:
means for determining a first resource for transmission of the request based on a set of beam failure detection resources configured for the PCell;
means for sending the request to the network device via the first resource;
Including,
The terminal device according to claim 4 . The means for transmitting information for BFR includes:
means for identifying the candidate beams;
means for including information about the candidate beams in information for the beam frequency reset;
means for transmitting information for the BFR to the network device;
Including,
The terminal device according to claim 1 . The means for monitoring the PDCCH includes:
means for determining a quasi-co-location (QCL) parameter associated with the PDCCH based on the candidate beam;
means for monitoring the PDCCH based on the QCL parameter;
Including,
The terminal device according to claim 2 . 1. A network device, comprising:
The radio access point/radio ...
Network devices. means for transmitting a physical downlink control channel (PDCCH) to the terminal device in response to the information for the BFR;
Further provided with
The network device of claim 8 . the request is transmitted prior to the transmission of the information for the BFR.
The network device of claim 8 . means for receiving from the terminal device the request transmitted at a particular cyclic shift;
The network device of claim 8 . 1. A method implemented in a terminal device, comprising:
a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device, and in response to detecting a beam failure in the SCell, transmitting information for beam failure recovery (BFR) to the network device, the information indicating a candidate beam and an index of the SCell, wherein the information for the BFR is transmitted without requesting scheduling or a request requesting scheduling of transmission of the information for the BFR is transmitted, and the beam failure of the SCell is indicated by a state of a channel state information (CSI) report.
method. monitoring a physical downlink control channel (PDCCH) to receive a response to the BFR information from the network device;
Further provided with
The method of claim 12. the request is transmitted prior to the transmission of the information for the BFR.
The method of claim 12. transmitting the request to the network device, the request being transmitted in a particular cyclic shift.
The method of claim 12. Sending the request comprises:
determining a first resource for transmission of the request based on a set of beam failure detection resources configured for the PCell; and
sending the request to the network device via the first resource;
Including,
16. The method of claim 15. Transmitting information for the BFR includes:
identifying the candidate beams;
including information about the candidate beams in information for the beam frequency reset;
transmitting information for the BFR to the network device;
Including,
The method of claim 12. Monitoring the PDCCH includes:
determining a quasi-co-location (QCL) parameter associated with the PDCCH based on the candidate beam;
monitoring the PDCCH based on the QCL parameter;
Including,
The method of claim 13. A method implemented in a network device, comprising:
providing at least a primary cell (PCell) and a secondary cell (SCell) to serve a terminal device, and receiving, in response to beam failure being detected in the SCell by the terminal device, information for beam failure recovery (BFR) indicating a candidate beam and an index of the SCell from the terminal device, wherein the information for the BFR is transmitted without requesting scheduling or a request requesting scheduling of transmission of information for the BFR is transmitted, and the beam failure of the SCell is indicated by a state of a channel state information (CSI) report.
method. transmitting a physical downlink control channel (PDCCH) to the terminal device to respond with information for the BFR;
Further provided with
20. The method of claim 19. the request is transmitted prior to the transmission of the information for the BFR.
20. The method of claim 19. receiving the request from the terminal device, the request being transmitted at a particular cyclic shift;
20. The method of claim 19.