WO2020014833A1

WO2020014833A1 - Beam failure recovery

Info

Publication number: WO2020014833A1
Application number: PCT/CN2018/095827
Authority: WO
Inventors: Yukai GAO; Gang Wang
Original assignee: Nec Corporation
Priority date: 2018-07-16
Filing date: 2018-07-16
Publication date: 2020-01-23
Also published as: JP2023101012A; JP7513157B2; JP7283531B2; JP2022500886A

Abstract

Embodiments of the present disclosure provide method, device and computer readable medium for beam failure recovery. In example embodiments, a method implemented at a terminal device is provided. The method comprises, in response to a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device and a beam failure being detected in the SCell, determining, from the PCell and the SCell, a first cell in which a beam failure recovery (BFR) request is to be transmitted to the network device and a second cell in which a response to the BFR request is to be received from the network device. The method further comprises transmitting, in the first cell, the BFR request to the network device. In addition, the method further comprises monitoring a control channel search space in the second cell to receive the response to the BFR request from the network device.

Description

BEAM FAILURE RECOVERY

TECHNICAL FIELD

Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to method, device and computer readable medium for beam failure recovery.

BACKGROUND

Due to increased free space path loss in higher frequency band supported in new radio access (NR) , channel/signal transmission relies on highly directional links. In other words, directional beam based communication is needed rather than the omni-directional communication in traditional communication systems. Directional links, however, require fine alignment of the transmitter and receiver beams, achieved through a set of operations knowns as beam management. For example, the beam management may generally include operations like beam sweeping, beam measurement, beam determination and beam reporting. These operations can be periodically repeated to update the optimal transmitter and receiver beam pair over time.

A beam failure may occur when the quality of beam pair (s) of an associated control channel falls low enough (for example, comparison with a threshold or time-out of an associated timer) . A mechanism to recover from a beam failure may be triggered when the beam failure occurs. The beam failure recovery mechanism on terminal device (such as, user equipment (UE) ) side usually includes the following operations: beam failure detection, identification of a new candidate beam, transmission of a beam failure recovery request and monitoring a response for the beam failure recovery request from a network device. For example, the terminal device may monitor a beam failure detection reference signal (RS) to assess if a beam failure occurs. Once the beam failure occurs, the terminal device may monitor beam identification RSs to find a new candidate beam. Once the candidate beam is identified, the terminal device may send a beam failure recovery request carrying information on the identified candidate beam to the network device. The terminal device may monitor a control channel search space to detect a response for the beam failure recovery request from the network device. Once the terminal device receives the beam recovery acknowledgement from the network device, the new beam pair can be considered to be established and the beam failure can be considered to be recovered.

In NR, a network device (such as, a next generation NodeB (gNB) ) may provide one primary cell (PCell) and at least one secondary cell (SCell) to serve a terminal device. However, in current 3GPP specifications, the beam failure recovery procedure may be only adapted to a beam failure occurs in the PCell.

SUMMARY

In general, example embodiments of the present disclosure provide method, device and computer readable medium for beam failure recovery.

In a first aspect, there is provided a method implemented at a terminal device. The method comprises: in response to a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device and a beam failure being detected in the SCell, determining, from the PCell and the SCell, a first cell in which a beam failure recovery (BFR) request is to be transmitted to the network device and a second cell in which a response to the BFR request is to be received from the network device; transmitting, in the first cell, the BFR request to the network device; 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, there is provided a terminal device. The terminal device comprises 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 actions. The actions comprise: in response to a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device and a beam failure being detected in the SCell, determining, from the PCell and the SCell, a first cell in which a beam failure recovery (BFR) request is to be transmitted to the network device and a second cell in which a response to the BFR request is to be received from the network device; transmitting, in the first cell, the BFR request to the network device; 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, there is provided a computer readable medium having instructions stored thereon. The instructions, when executed on at least one processor, cause the at least one processor to carry out the method according to the first aspect of the present disclosure.

In a fourth aspect, there is provided a computer program product that is tangibly stored on a computer readable storage medium. The computer program product includes instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to the first aspect of the present disclosure.

Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Through the more detailed description of some embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

Fig. 1 shows an example communication network 100 in which embodiments of the present disclosure can be implemented;

Fig. 2A shows an example scenario 201 of the network 100 as shown in Fig. 1;

Fig. 2B shows another example scenario 202 of the network 100 as shown in Fig. 1;

Figs. 3A and 3B show a problem that may occur in the BFR procedure in the example scenario 202 as shown in Fig. 2B;

Fig. 4 shows a flowchart of an example method 400 for beam failure recovery in accordance with some embodiments of the present disclosure; and

Fig. 5 is a simplified block diagram of a device 500 that is suitable for implementing embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitations as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills 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 “includes” and its variants are to be read as open terms that mean “includes, but is not limited to. ” The term “based on” is to be read as “at least in part based on. ” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment. ” The term “another embodiment” is to be read as “at least one other embodiment. ” The terms “first, ” “second, ” and the like may refer to different or same objects. Other definitions, explicit and implicit, may be included below.

In some examples, values, procedures, or apparatus are referred to as “best, ” “lowest, ” “highest, ” “minimum, ” “maximum, ” or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

As described above, a beam failure may occur when the quality of beam pair (s) of an associated control channel falls low enough (for example, comparison with a predetermined threshold or time-out of an associated timer) . A mechanism to recover from a beam failure may be triggered when the beam failure occurs. The beam failure recovery mechanism on terminal device side usually includes the following operations: beam failure detection, identification of a new candidate beam, transmission of a beam failure recovery request and monitoring a response for the beam failure recovery request from a network device.

Embodiments of the present disclosure provide a solution for beam failure recovery, so as to solve the problem above and one or more of other potential problems. The solution for beam failure recovery in accordance with embodiments of the present disclosure can be adapted to the beam failure occurs in the SCell. Moreover, embodiments of the present disclosure enable faster beam failure recovery than the traditional beam recovery schemes.

Principle and implementations of the present disclosure will be described in detail below with reference to Figs. 1-5.

Fig. 1 shows an example communication network 100 in which embodiments of the present disclosure can 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 is to be understood that the number of network devices, terminal devices and/or serving cells is only for the purpose of illustration without suggesting any limitations to the present disclosure. The network 100 may include any suitable number of network devices, terminal devices and/or serving cells adapted for implementing implementations of the present disclosure.

As used herein, the term “terminal device” refers to any device having wireless or wired communication capabilities. Examples of the terminal device include, but not limited to, user equipment (UE) , personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs) , portable computers, image capture devices such as digital cameras, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like. For the purpose of discussion, in the following, some embodiments will be described with reference to UE as an example of the terminal device 220.

As used herein, the term “network device” or “base station” (BS) refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a Node B (NodeB or NB) , an Evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNB) , a Remote Radio Unit (RRU) , a radio head (RH) , a remote radio head (RRH) , a low power node such as a femto node, a pico node, and the like.

For example, in some scenarios, carrier aggregation (CA) can be supported in the network 100, in which two or more component carriers (CCs) are aggregated in order to support a broader bandwidth. In CA, the network device 110 may provide a plurality of serving cells (for example, one for each of the CCs) including one primary cell (PCell) and at least one Secondary Cell (SCell) to serve the terminal device 120. The terminal device 120 can establish Radio Resource Control (RRC) connection with the network device 110 in the PCell. The SCell can provide additional radio resources 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.

In some other scenarios, for example, the terminal device 120 may establish connections with two different network devices (not shown in Fig. 1) and thus can utilize radio resources of the two network devices. The two network devices may be respectively defined as a master network device and a secondary network device. The master network device may provide a group of serving cells, which are also referred to as “Master Cell Group (MCG) ” . The secondary network device may also provide a group of serving cells, which are also referred to as “Secondary Cell Group (SCG) ” . For Dual Connectivity operation, a term “Special Cell (SpCell) ” may refer to the Pcell of the MCG or the primary Scell (PScell) of the SCG depending on if the terminal device 120 is associated to the MCG or the SCG, respectively. In other cases than the Dual Connectivity operation, the term “SpCell” may also refer to the PCell.

In the communication network 100 as 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 communication data and control information to the network device 110. A link from the network device 110 to the terminal device 120 is referred to as a downlink (DL) , while a link from the terminal device 120 to the network device 110 is referred to as an uplink (UL) .

The communications in the network 100 may conform to any suitable standards 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) , Machine Type Communication (MTC) and the like. Furthermore, the communications may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols.

The network device 110 (such as, a next generation NodeB (gNB) ) may be equipped with one or more Transmission and Reception Point (TRP) or antenna panel. As used herein, the term “TRP” refers to an antenna array (with one or more antenna elements) available to the network device located at a specific geographical location. For example, the network device 110 may be coupled with multiple TRPs in different geographical locations to achieve better coverage. The one or more TRPs may be included in a same serving cell or different serving cells.

Fig. 2A shows an example scenario 201 of the network 100 as shown in Fig. 1. As shown in Fig. 2A, for example, the network device 110 in Fig. 1 may provide a PCell 210 and a SCell 220 to serve the terminal device 120. The PCell 210 and the SCell 220 may be overlapped with each other. The network device 110 may be coupled with a TRP 230, which is located in both of the PCell 210 and the SCell 220.

A beam failure may occur if the network device 110 is no longer able to reach the terminal device 120 via a control channel (such as, Physical Downlink Control Channel (PDCCH) ) due to incorrect adjustment of the beams, blockage effect, movement of the terminal device 120, or some other reasons. For example, the terminal device 120 may detect this situation by estimating the quality of a hypothetical PDCCH reception transmitted over a beam the network device 110 would use to reach the terminal device 120. To perform beam failure detection, the terminal device 120 may estimate the quality of a hypothetical PDCCH reception based on reception of a certain reference signal (RS) . In the following text, this reference signal may also be referred to as “beam failure detection RS” or “RS for beam failure detection” . Examples of the beam failure detection RS may include but not limited to periodic Channel State Information-Reference Signal (CSI-RS) , synchronization signal block (SSB) , or a combination thereof.

In the example as shown in Fig. 2A, PDCCHs may be transmitted in both of the PCell 210 and the SCell 220. For example, as shown in Fig. 2A, PDCCHs may be transmitted from the TRP 230 to the terminal device 120 via a DL beam 240-1 in the PCell 210 and transmitted from the TRP 230 to the terminal device 120 via another DL beam 240-2 in the SCell 220. In this event, a 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 identification RSs configured for the SCell to identify a candidate beam for recovery from the beam failure. The terminal device 120 may include information on the candidate beam in a beam failure recovery (BFR) request, and transmit the BFR request including the information on the candidate beam to the network device 110 in the first cell.

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

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

In some embodiments, for different scenarios, the beam failure recovery procedures may be different. The PCell 210 and the 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 below 6GHz, and the second frequency range FR2 may be above 6GHz. In some embodiments, for example in the example scenario 201 as shown in Fig. 2A, FR1 may be the same as or different from FR2. In some embodiments, in this case, BFR may be needed only in the SCell but not in the PCell. In some embodiments, for example in the example scenario 201 as shown in Fig. 2A, the PCell 210 and the SCell 220 may be configured in a same frequency range, for example FR2. In some embodiments, in this case, the DL beams in the PCell and those in the SCell may have similar characteristics. For example, if the DL beams in the PCell are blocked, the DL beams in the SCell may also be blocked as the same time. In some embodiments, for example in the example scenario 201 as shown in Fig. 2A, both the PCell 210 and the SCell 220 may be configured in a same frequency range, for example FR1. In some embodiments, in this case, there may be no need of BFR for both the PCell 210 and the SCell 220. For example, if all of the RSs configured for the PCell 210 and the SCell 220 are not configured with QCL-TypeD, there may be no need of BFR for both the PCell 210 and the SCell 220.

In some embodiments, for example in the example scenario 201 as shown in Fig. 2A, the PCelt 210 and the SCell 220 may be configured in a same frequency range. For example, intra-band CA may be supported in this case, in which intra-band contiguous CCs are aggregated. In some embodiments, in this case, if a beam failure is detected in the SCell, another beam failure may also be detected in the PCell at the same time. In some embodiments, in this case, the BFR may only be needed in the PCell. Further, if a beam failure detection RS is configured for the SCell 220, this beam failure detection RS may be QCLed in QCL-TypeD with at least one beam failure detection RS configured for the PCell 210. Alternatively, or in addition, if a beam identification RS is configured for the SCell 220, this beam identification RS may be QCLed in QCL-TypeD with at least one beam identification RS configured for the PCell 210. That is, cross-carrier quasi co-location (QCL) may be supported in this case.

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

In some embodiments, the PCell 210 and the SCell 220 may be associated with the first frequency range FR 1 and the second frequency range FR2 respectively. For example, in the example scenario 201 as shown in Fig. 2A, FR1 may be different from FR2. Moreover, the frequency range associated with the SCell 220 may exceed that associated with the PCell 210. In some embodiments, the determined first cell in which the BFR request is to be transmitted to the network device 110 may be the SCell 220 (for example, this case is also referred to as “BFR on SCell UL” in the following text) . Alternatively, in some embodiments, the determined first cell in which the BFR request is to be transmitted to the network device 110 may be the PCell 210 (for example, this case is also referred to as “BFR on PCell UL” in the following text) . In some other embodiments, the determined second cell in which the response to the BFR request is to be received from the network device 110 may be the PCell 210 (for example, this case is also referred to as “BFR on PCell DL” in the following text) . Alternatively, in some other embodiments, the determined second cell in which the response to the BFR request is to be received from the network device 110 may be the SCell 220 (for example, this case is also referred to as “BFR on SCell DL” in the following text) . In some embodiments, the determined first cell in which the BFR request is to be transmitted to the network device 110 may be the SCell 220, while the determined second cell in which the response to the BFR request is to be received from the network device 110 may be the PCell 210 (for example, this case is also referred to as “BFR on SCell UL and PCell DL” in the following text) .

In some embodiments, regarding the case “BFR on SCell UL” , the transmission of the BFR request may be triggered by a PDCCH order. In some embodiments, in this case, prior to transmitting the BFR, the terminal device 120 may transmit a request for the PDCCH order in the PCell 210. In some embodiments, the request for the PDCCH order may be transmitted over Physical Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) in the Pcell 210. For example, the request for the PDCCH order may be transmitted with at least one of the following: a specific sequence, a specific time resource, a specific frequency resource, and a specific cyclic shift of a sequence of PUCCH or PRACH in the Pcell 210. For example, the index of the identified candidate beam may not be needed to be carried in the request. In response to receiving the PDCCH order from the network device 110, the terminal device may transmit the BFR request to the network device 110 in the SCell 220. 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 an index of the cell in which the BFR request is to be transmitted. For example, 3 bits may be used in the PDCCH order to indicate the index of the cell.

In some embodiments, if the PDCCH order is to trigger PRACH transmission of the BFR request in the SCell 220, the bit field of Random Access Preamble index in the PDCCH order may be fixed to be 0. For example, the 6 bits for the Random Access Preamble index may be fixed to be 0. In some embodiments, the field of SS/PBCH index and/or the field of PRACH Mask index may be reserved.

In some embodiments, if the PDCCH order is to trigger PRACH transmission of the BFR request in the SCell 220, the terminal device 120 may ignore the bit field of Random Access Preamble index in the PDCCH order.In some embodiments, the Random Access Preamble index for the PRACH transmission of the BFR request in the SCell 220 may be based on the index of the identified candidate beams in the Scell 220.

In some embodiments, regarding the case “BFR on SCell UL” , the transmission of the BFR request may be triggered by a PDCCH order. In some embodiments, in this case, prior to transmitting the BFR, the terminal device 120 may transmit a request for the PDCCH order in the SCell 220. In response to receiving the PDCCH order from the network device 110, the terminal device may transmit the BFR request to the network device 110 in the SCell 220. In some embodiments, in this case, the DL beam for 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, regarding the case “BFR on SCell UL” , in response to detecting a beam failure in SCell 220, the terminal device 120 may transmit the BFR request to the network device 110 in the SCell 220 directly, without requesting a PDCCH order from the network device 110. In some embodiments, the BFR request may be transmitted over 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 the SCell. Therefore, in some embodiments, in case that a BFR timer expires, a SCell failure may be reported to the network device 100 in the PCell 210, rather than initiating a CBRA procedure in the SCell 220. For example, an additional state in the Channel State Information (CSI) report can be used to indicate the SCell failure. Alternatively, or in addition, a specific PRACH resource may be configured for the report of the SCell failure in the PCell. Moreover, there may be no need to use one of the set of candidate beams (corresponding to the set of beam identification RSs) configured for the PCell to report the SCell failure.

In some embodiments, regarding the case “BFR on SCell UL” , the transmission of the BFR request may be triggered by a PDCCH order. In some embodiments, in this case, prior to transmitting the BFR, the terminal device 120 may transmit a request for the PDCCH order in the PCell 210. In response to receiving the PDCCH order from the network device 110, the terminal device may transmit the BFR request to the network device 110 in the SCell 220. 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 an index of the cell in which the BFR request is triggered.

In some embodiments, regarding the case “BFR on SCell UL and PCell DL” , in response to detecting a beam failure in SCell 220, the terminal device 120 may transmit the BFR request to the network device 110 in the SCell 220 directly, without requesting a PDCCH order from the network device 110. In some embodiments, the BFR request may be transmitted over 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 the SCell. Therefore, in some embodiments, in case that a BFR timer expires, a SCell failure may be reported to the network device 100 in the PCell 210, rather than initiating a CBRA procedure in the SCell 220. For example, an additional state in the Channel State Information (CSI) report can be used to indicate the SCell failure. Alternatively, or in addition, a specific PRACH resource may be configured for the report of the SCell failure in the PCell. Moreover, there may be no need to use one of the set of candidate beams (corresponding to the set of beam identification RSs) configured for the PCell to report the SCell failure.

In some embodiments, regarding the case “BFR on SCell UL and PCell DL” , the CFRA based BFR may be supported in the SCell 220. In some embodiments, in this case, the terminal device 120 may monitor a control channel search space in the PCell 210 to receive the response to the BFR request from the network device 110. For example, the BFR request may be transmitted over a PRACH resource in the SCell 220. In some embodiments, the PRACH resource may be QCLed with the identified candidate beam in the SCell 220. In some embodiments, in case that there is no QCL-TypeD configured for any of the RSs in the PCell 210, the case “BFR on SCell UL and PCell DL” may not be available.

In some embodiments, regarding the case “BFR on SCell UL and PCell DL” , the terminal device 120 may monitor the response to the BFR request in the PCell 210, while the BFR request is transmitted over PRACH in the SCell 220. In some cases, subcarrier spacing (SCS) associated with the PCell may be different from that associated with the SCell. In some embodiments, in this case, a 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, suppose that the slot for transmission of the BFR request in the SCell 220 is slot #n, the slot for receiving the response to the BFR request in the PCell 210 may be slot # (n’+k) , where slot #n’may be the latest slot in the PCell 210 overlapping with slot #n in the SCell 220, and the time interval k can be determined based on the SCS associated with the PCell 210 or the SCell 220.

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

Fig. 2B shows another example scenario 202 of the network 100 as shown in Fig. 1. As shown in Fig. 2B, for example, the network device 110 in Fig. 1 may provide a PCell 210 and a SCell 220 to serve the terminal device 120. For example, the PCell 210 and the SCell 220 may not be overlapped with each other. The network device 110 may be coupled with two TRPs 230-1 and 230-2, which are located in the PCell 210 and the SCell 220 respectively.

A beam failure may occur if the network device 110 is no longer able to reach the terminal device 120 via a control channel (such as, PDCCH) due to incorrect adjustment of the beams, blockage effect, movement of the terminal device 120, or some other reasons. For example, the terminal device 120 may detect this situation by estimating the quality of a hypothetical PDCCH reception transmitted over a beam the network device 110 would use to reach the terminal device 120. To perform beam failure detection, the terminal device 120 may estimate the quality of a hypothetical PDCCH reception based on reception of a certain beam failure detection RS.

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

Suppose that in the example scenario 202 as shown in Fig. 2B, the BFR request is to be transmitted from the terminal device 120 to the network device 110 in the PCell 210, while the response to the BFR request is to be transmitted from the network device 110 to the terminal device 120 in the PCell 210 (that is, “BFR on PCell UL and PCell DL” ) , some problems may occur.

Figs. 3A and 3B show a problem that may occur in the BFR procedure in the example scenario 202 as shown in Fig. 2B. As shown in Fig. 3A, the TRPs 230-1 and 230-2, which are located in the PCell 210 and the SCell 220 respectively, may be remote from each other. The DL beam 240-2 from the TRP 230-2 may be detected to be failed, and a candidate beam 310 may be identified for recovery from the beam failure. In current 3GPP specifications, the BFR request may be transmitted from the terminal device 120 to the network device 110 in the direction of the candidate beam 320. In this case, as shown in Fig. 3A, the TRP 230-1 in the PCell 210 in the PCell 210 cannot receive the BFR request. Moreover, in current 3GPP specifications, the response to the BFR request may be transmitted from the network device 110 to the terminal device 120 in the direction of the candidate beam 320. In this case, as shown in Fig. 3B, the terminal device 120 cannot receiving the response to the BFR request. That is, in current 3GPP specifications, BFR on PCell UL and PCell DL cannot be supported.

Embodiments of the present disclosure can solve the problem as shown in Figs. 3A and 3B.

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

In some embodiments, for example in the example scenario 202 as shown in Fig. 2B, the determined first cell in which the BFR request is to be transmitted to the network device 110 may be the PCell 210, while the determined second cell in which the response to the BFR request is to be received from the network device 110 may also be the PCell 210 (that is, “BFR on PCell UL and PCell DL” ) .

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

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

In some embodiments, one PRACH resource for transmission of the BFR request may correspond to one beam in the PCell 210 and another beam in the SCell 220. A beam failure occurs in the PCell 210 or the SCell 220 may be indicated by different cycle shift (CS) value or different cover code used for PRACH transmission.

In some embodiments, a first set of PRACH resources, sequences or preambles may be configured for transmission of the BFR request in the PCell 210, and a second set of PRACH resources, sequences or preambles may be used to indicate different identified candidate beams in the PCell 210. In some embodiments, the transmission of the BFR request in the SCell 220 may be also based on at least one of the first set of PRACH PRACH resources, sequences or preambles. In some embodiments, if the BFR request for a beam failure in the SCell 220 is transmitted in the PCell 210, a timing advance value in the 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 the network device 110 (since the timing advance value is applied to the PRACH transmission of the BFR request) , the PRACH transmission may be regarded as BFR for the beam failure in the SCell 220. In some embodiments, if the BFR request for a beam failure in the PCell 210 is transmitted in the PCell 210, there may be no timing advance value available in the PCell 210. For example, if there is time difference in the BFR request received at the network device 110 (since no timing advance value is applied to the PRACH transmission of the BFR request) , the PRACH transmission may be regarded as BFR for the beam failure in the PCell 210.

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

In some embodiments, if the response to the BFR request for Scell is to be received in the PCell 210, there may be no timing adjustment command in the response. In some embodiments, the response to the BFR request may be transmitted via a PDCCH. In some embodiments, the PDCCH may be a compact PDCCH. For example, there may be no scheduling information in the PDCCH. As another example, there may be no timing adjustment command in the response. In some embodiments, the response to the BFR request may be in one of the following formats: DCI format 0_0 and/or DCI format 1_0. In some embodiments, the response to the BFR request may be transmitted via the PDCCH with aCSI request and/or a PDCCH order.

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

In some embodiments, a first set of BFR parameters (such as an BFR counter, an BFR time or the like) in the PCell 210 may be used for the beam failure in the PCell 210. In some embodiments, if the BFR request for a beam failure in the SCell 220 to be transmitted in the PCell 210, a second set of BFR parameters (such as an BFR counter, an BFR time or the like) in the PCell 210 may be used for the beam failure in the SCell 220. For example, the first set of BFR parameters may be different from the second set of BFR parameters. In some embodiments, the BFR in the SCell 220 may reuse the preamble resources used for the BFR in the PCell 210, but the BFR counter or timer for the BFR in the SCell 220 and that for the BFR in the PCell 210 may be separated from each other.

In some embodiments, as described above, to perform beam failure detection, the terminal device 120 may estimate the quality of a hypothetical PDCCH reception based on reception of a certain reference signal (RS) . For example, the RS may be a CSI-RS. The reception power of the CSI-RS in the SCell 220 can be determined based on a SSB defined in the SCell 220. However, in some case, there may be no SSB 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 SSB in the PCell 210.

Fig. 4 illustrates a flowchart of an example method 400 for beam failure recovery in accordance with some embodiments of the present disclosure. The method 400 can be implemented at the terminal device 120 shown in Figs. 1, 2A and/or 2B. It is to be understood that the method 400 may include additional acts not shown and/or may omit some shown acts, and the scope of the present disclosure is not limited in this regard.

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

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

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

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

In some embodiments, the second cell is the SCell, and the PDCCH order is received from the network device in one of the PCell and the SCell.

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

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

In some embodiments, the first cell is the SCell and the second cell is the PCeI1. The terminal device may transmit the BFR request by: determining, based on the candidate beam, a QCL parameter associated with Physical Random Access Channel (PRACH) for transmission of the BFR request; and transmitting the BFR request over PRACH based on the QCL parameter.

It can be seen that, embodiments of the present disclosure provide a solution for beam failure recovery. The solution for beam failure recovery in accordance with embodiments of the present disclosure can be adapted to the beam failure occurs in the SCell. Moreover, embodiments of the present disclosure enable faster beam failure recovery than the traditional beam recovery schemes.

Fig. 5 is a simplified block diagram of a device 500 that is suitable for implementing embodiments of the present disclosure. The device 500 can be considered as a further example implementation of the network device 110 or the terminal device 120 as shown in Fig. 1. Accordingly, the device 500 can be implemented at or as at least a part of the network device 110 or the terminal device 120.

As shown, the device 500 includes a processor 510, a memory 520 coupled to the processor 510, a suitable transmitter (TX) and receiver (RX) 540 coupled to the processor 510, and a communication interface coupled to the TX/RX 540. The memory 510 stores at least a part of a program 530. The TX/RX 540 is for bidirectional communications. The TX/RX 540 has at least one antenna to facilitate communication, though in practice an Access Node rnentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2 interface for bidirectional communications between eNBs, S1 interface for communication between a Mobility Management Entity (MME) /Serving Gateway (S-GW) and the eNB, Un interface for communication between the eNB and a relay node (RN) , or Uu interface for communication between the eNB and a terminal device.

The program 530 is assumed to include program instructions that, when executed by the associated processor 510, enable the device 500 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to Figs. 1 to 4. The embodiments herein may be implemented by computer software executable by the processor 510 of the device 500, or 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, a combination of the processor 510 and memory 520 may form processing means 550 adapted to implement various embodiments of the present disclosure.

The memory 520 may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 520 is shown in the device 500, there may be several physically distinct memory modules in the device 500. The processor 510 may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 500 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

Generally, 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 which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also 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, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above with reference to Fig. 4. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

The above program code may be embodied on a machine readable medium, which may be any tangible medium that may contain, or store 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. A machine readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having 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) , an 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.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be 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 sub-combination.

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

Claims

A method implemented at a terminal device, comprising:

in response to a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device and a beam failure being detected in the SCell, determining, from the PCell and the SCell, a first cell in which a beam failure recovery (BFR) request is to be transmitted to the network device and a second cell in which a response to the BFR request is to be received from the network device;

transmitting, in the first cell, the BFR request to the network device; and

monitoring a control channel search space in the second cell to receive the response to the BFR request from the network device.
The method of Claim 1, wherein a frequency corresponding to the SCell exceeds that correspond to the PCell.
The method of Claim 1, wherein the first cell is the SCell and the second cell is one of the PCell and the SCell, and wherein transmitting the BFR request comprises:

transmitting a request for a Physical Downlink Control Channel (PDCCH) order in the PCell; and

in response to receiving the PDCCH order from the network device, transmitting the BFR request to the network device in the SCell.
The method of Claim 3, wherein the second cell is the SCell, and the PDCCH order is received from the network device in one of the PCell and the SCell.
The method of Claim 1, wherein the first cell is the PCell, and wherein transmitting the BFR request comprises:

determining, based on a set of beam failure detection resources configured for the PCell, a first resource for transmission of the BFR request; and

transmitting the BFR request to the network device over the first resource.
The method of Claim 5, wherein the second cell is the PCell, and wherein monitoring the control channel search space comprises:

determining, based on the set of beam failure detection resources configured for the PCell, a second resource for monitoring the control channel search space in the PCell; and

monitoring the control channel search space over the second resource.
The method of Claim 1, wherein transmitting the BFR request comprises:

identifying a candidate beam for recovery from the beam failure in the SCell;

including information on the candidate beam in the BFR request; and

transmitting, in the first cell, the BFR request to the network device.
The method of Claim 7, where the second cell is the SCell, and wherein monitoring the control channel search space comprises:

determining, based on the candidate beam, a quasi-co-location (QCL) parameter associated with the control channel search space; and

monitoring the control channel search space based on the QCL parameter.
The method of Claim 7, wherein the first cell is the SCell and the second cell is the PCell, and wherein transmitting the BFR request comprises:

determining, based on the candidate beam, a QCL parameter associated with Physical Random Access Channel (PRACH) for transmission of the BFR request; and

transmitting the BFR request over PRACH based on the QCL parameter.
A terminal device comprising:

a processor; and

a memory coupled to the processor and storing instructions thereon, the instructions, when executed by the processor, causing the terminal device to perform actions comprising:

in response to a network device providing at least a primary cell (PCell) and a secondary cell (SCell) to serve the terminal device and a beam failure being detected in the SCell, determining, from the PCell and the SCell, a first cell in which a beam failure recovery (BFR) request is to be transmitted to the network device and a second cell in which a response to the BFR request is to be received from the network device;

transmitting, in the first cell, the BFR request to the network device; and

monitoring a control channel search space in the second cell to receive the response to the BFR request from the network device.
The terminal device of Claim 10, wherein a frequency corresponding to the SCell exceeds that correspond to the PCell.
The terminal device of Claim 10, wherein the first cell is the SCell and the second cell is one of the PCell and the SCell, and wherein transmitting the BFR request comprises:

transmitting a request for a Physical Downlink Control Channel (PDCCH) order in the PCell; and

in response to receiving the PDCCH order from the network device, transmitting the BFR request to the network device in the SCell.
The terminal device of Claim 12, wherein the second cell is the SCell, and the PDCCH order is received from the network device in one of the PCell and the SCell.
The terminal device of Claim 10, wherein the first cell is the PCell, and wherein transmitting the BFR request comprises:

determining, based on a set of beam failure detection resources configured for the PCell, a first resource for transmission of the BFR request; and

transmitting the BFR request to the network device over the first resource.
The terminal device of Claim 14, wherein the second cell is the PCell, and wherein monitoring the control channel search space comprises:

determining, based on the set of beam failure detection resources configured for the PCell, a second resource for monitoring the control channel search space in the PCell; and

monitoring the control channel search space over the second resource.
The terminal device of Claim 10, wherein transmitting the BFR request comprises:

identifying a candidate beam for recovery from the beam failure in the SCell;

including information on the candidate beam in the BFR request; and

transmitting, in the first cell, the BFR request to the network device.
The terminal device of Claim 16, where the second cell is the SCell, and wherein monitoring the control channel search space comprises:

determining, based on the candidate beam, a quasi-co-location (QCL) parameter associated with the control channel search space; and

monitoring the control channel search space based on the QCL parameter.
The terminal device of Claim 16, wherein the first cell is the SCell and the second cell is the PCell, and wherein transmitting the BFR request comprises:

determining, based on the candidate beam, a QCL parameter associated with Physical Random Access Channel (PRACH) for transmission of the BFR request; and

transmitting the BFR request over PRACH based on the QCL parameter.
A computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to carry out the method according to any of claims 1 to 9.