Terminal device, network device, and methods implemented in the terminal device and network device

Abstract

To provide a method, a device and a computer readable medium for beam failure recovery.SOLUTION: In example embodiments, a method implemented at a terminal device is provided. The method comprises determining, 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. 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.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] FIELD 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. [Background technology]

[0002] 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, communication based on directional beams is required, rather than omnidirectional communication as in conventional communication systems. However, directional links require fine-tuning of 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.

[0003] A beam failure may occur when the quality of a beam pair of an associated control channel is sufficiently degraded (e.g., compared with 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. When a candidate beam is identified, the terminal device sends a beam failure recovery request including 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.

[0004] 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 can only be applied to beam failures that occur on the PCell. Summary of the Invention [Problem to be solved by the invention]

[0005] Generally, exemplary embodiments of the present disclosure provide a method, device, and computer-readable medium for beam failure recovery. [Means for solving the problem]

[0006] In a first aspect, a method is provided for implementation in a terminal device, the method comprising: the network device providing at least a primary cell (PCell) and a secondary cell (SCell) for serving the terminal device, and determining, from the PCell and the SCell in response to detecting a beam failure on 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 at the first cell; and monitoring a control channel search space at the second cell to receive the response to the BFR request from the network device.

[0007] 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 on 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 at the first cell; and monitoring a control channel search space at the second cell to receive the response to the BFR request from the network device.

[0008] In a third aspect, there is provided a computer-readable medium 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.

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

[0010] Other features of the present disclosure will become readily apparent from the following description. [Brief explanation of the drawings]

[0011] The above 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.

[0012] [Figure 1] 1 illustrates an exemplary communication network 100 in which embodiments of the present disclosure may be implemented.

[0013] [Figure 2A] 2 illustrates an exemplary scenario 201 for the network 100 shown in FIG.

[0014] [Figure 2B] 2 illustrates another exemplary scenario 202 for the network 100 shown in FIG.

[0015] [Figure 3A] 2B illustrates a problem that may occur in a BFR procedure in an exemplary scenario 202 shown in FIG. [Figure 3B] 2B illustrates a problem that may occur in a BFR procedure in an exemplary scenario 202 shown in FIG.

[0016] [Figure 4] 4 shows a flowchart of an exemplary method 400 for beam failure recovery according to some embodiments of the present disclosure.

[0017] [Figure 5]5 is a simplified block diagram of a device 500 suitable for practicing embodiments of the present disclosure.

[0018] Throughout the drawings, the same or similar reference numbers represent the same or similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0019] The principles of the present disclosure will be explained with reference to some exemplary embodiments. It is understood that these embodiments are set forth for illustrative purposes only, to help those skilled in the art understand and practice the present disclosure, without implying any limitation on the scope of the present disclosure. The disclosure described herein can be implemented in various ways other than those described below.

[0020] 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 skill in the art to which this disclosure belongs.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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 occurring on the PCell.

[0025]

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

[0026] The principles and embodiments of the present disclosure will be described in detail below with reference to FIGS.

[0027] 1 illustrates an exemplary communication network 100 in which embodiments of the present disclosure may be implemented. Network 100 includes a network device 110 and a terminal device 120 served by network device 110. Network 100 may provide one or more serving cells 102 to serve 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. Network 100 may include any appropriate number of network devices, terminal devices, and / or serving cells suitable for implementing embodiments of the present disclosure.

[0028] As used herein, the term "terminal device" refers to any device having 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 a terminal device 220.

[0029] 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.

[0030] 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 on 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.

[0031] In some other scenarios, for example, the terminal device 120 may establish connections with two different network devices (not shown in FIG. 1 ), thereby utilizing 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 a Pcell of an MCG or a Primary Scell ​​(PScell) of an SCG, depending on whether the terminal device 120 is associated with an MCG or an SCG, respectively. In cases other than dual connectivity operation, the term “SpCell” may also refer to a PCell.

[0032] 1, network device 110 can communicate data and control information to terminal device 120, and terminal device 120 can also communicate data and control information to network device 110. The link from network device 110 to terminal device 120 is called downlink (DL), and the link from terminal device 120 to network device 110 is called uplink (UL).

[0033] 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), etc. 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.

[0034] 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 with 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.

[0035] 2A illustrates an example scenario 201 of the network 100 illustrated in FIG. 1. As illustrated in FIG. 2A, for example, the network device 110 of FIG. 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 on both the PCell 210 and the SCell 220.

[0036] A beam failure may occur when the network device 110 can no longer reach the terminal device 120 via a control channel (e.g., a Physical Downlink Control Channel (PDCCH)) due to incorrect beam adjustment, a blocking effect, 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 a virtual PDCCH reception transmitted via a 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 reference signal (RS). In the following description, this reference signal may also be referred to as a "beam failure detection RS" or an "RS for beam failure detection." Examples of a 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.

[0037] 2A, the PDCCH may be transmitted on 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 on the PCell 210, and may be transmitted from the TRP 230 to the terminal device 120 via another DL beam 240-2 on the SCell 220. In this case, beam failure may be detected on the PCell 210 or the SCell 220.

[0038] In some embodiments, in response to detecting a beam failure on 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.

[0039] 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 on the SCell 220, the terminal device 120 may determine from the PCell 210 and the SCell 220 a first cell from which a 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 on the determined first cell. Thereafter, the terminal device 120 may monitor the control channel search space on the second cell to receive a response to the BFR request from the network device 110.

[0040] In some embodiments, a quasi co-location (QCL) type may be configured for the RS. The quasi co-location 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}.

[0041] In some embodiments, beam failure recovery procedures may be different for different scenarios. 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 less than 6 GHz, and the second frequency range FR2 may be equal to or greater than 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 on the SCell but not on the PCell. In some embodiments, for example, in the exemplary scenario 201 shown in FIG. 2A, the PCell 210 and the SCell 220 may be configured with the same frequency range, e.g., FR2. In some embodiments, in this case, the DL beam on the PCell and the DL beam on the SCell have similar characteristics. For example, if the DL beam on the PCell is blocked, the DL beam on 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 the PCell 210 and the SCell 220 may be configured in the same frequency range, for example, FR1. In some embodiments, in this case, BFR may not be required 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-Type D, BFR may not be required for both the PCell 210 and the SCell 220.

[0042] 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, when a beam failure is detected on the SCell, another beam failure may be simultaneously detected on the PCell. In some embodiments, in this case, BFR may be required only on 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. That is, in this case, cross-carrier quasi-colocation (QCL) may be supported.

[0043] 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.

[0044] In some embodiments, 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, in the example scenario 201 shown in FIG. 2A , FR1 may be different from FR2. Furthermore, the frequency range associated with the SCell 220 may exceed the frequency range associated with the PCell 210. In some embodiments, the determined first cell from which a BFR request is transmitted to the network device 110 may be the 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 the network device 110 may be the 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 the network device 110 may be the 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).

[0045] In some embodiments, for the case of "BFR on SCell UL," transmission of a 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 the PDCCH order may be transmitted via a physical uplink control channel (PUCCH) or a 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 on the SCell 220 to the network device 110. That is, in this case, the PDCCH order can trigger 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 to which the BFR request is transmitted. For example, three bits may be used in the PDCCH order to indicate the cell index.

[0046] In some embodiments, if the PDCCH order triggers a PRACH transmission of a BFR request on SCell 220, the bit field for the random access preamble index in the PDCCH order may be fixed to 0. For example, 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.

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

[0048] 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 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, an index of the identified candidate beam may be carried in the BFR request.

[0049] In some embodiments, for the "BFR on SCell UL" case, in response to detecting beam failure on the SCell 220, the terminal device 120 may transmit a BFR request on the SCell 220 directly to the network device 110 without requesting a PDCCH order from the 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 on the SCell. Thus, in some embodiments, if the BFR timer expires, SCell failure may be reported to the network device 100 on the PCell 210 instead of initiating a CBRA procedure on the SCell 220. For example, additional status in a Channel State Information (CSI) report can be used to indicate the SCell failure. Alternatively or additionally, specific PRACH resources may be configured for reporting of SCell failure on 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 an SCell failure.

[0050] In some embodiments, for the case of "BFR on SCell UL," transmission of a BFR request may be triggered by a PDCCH order. In some embodiments, in this case, before transmitting the BFR, terminal device 120 may transmit a request for a PDCCH order on PCell 210. In response to receiving a PDCCH order from network device 110, terminal device 120 may transmit a BFR request on SCell 220 to network device 110. That is, in this case, the PDCCH order can trigger transmission of a 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.

[0051] In some embodiments, for the case of "BFR on SCell UL and PCell DL," in response to detecting beam failure on the SCell 220, the terminal device 120 may transmit a BFR request on the SCell 220 directly to the network device 110 without requesting a PDCCH order from the 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 on the SCell. Thus, in some embodiments, if the BFR timer expires, SCell failure may be reported to the network device 100 on the PCell 210 instead of initiating a CBRA procedure on the SCell 220. For example, additional status in a channel state information (CSI) report can be used to indicate the SCell failure. Alternatively or additionally, specific PRACH resources may be configured for reporting of SCell failure on 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 an SCell failure.

[0052] In some embodiments, for the case of "BFR on SCell UL and PCell DL," BFR based on CFRA may be supported on SCell 220. In some embodiments, in this case, terminal device 120 may monitor the control channel search space on 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 on SCell 220. In some embodiments, the PRACH resource may be QCL'd with an identified candidate beam on SCell 220. In some embodiments, if QCL-Type D is not configured for any RS on PCell 210, "BFR on SCell UL and PCell DL" is not available.

[0053] In some embodiments, for the case of "BFR on SCell UL and PCell DL," the terminal device 120 may monitor the PCell 210 for a response to the BFR request while the BFR request is transmitted via the PRACH on the SCell 220. In some embodiments, a 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 on 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 on the SCell 220 is slot #n, the slot for receiving the response to the BFR request on the PCell 210 may be slot #(n'+k). Here, slot #n' is the nearest slot on the PCell 210 that overlaps with slot #n on the SCell 220, and the time interval k may be determined based on the SCS associated with the PCell 210 or the SCell 220.

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

[0055] 2B illustrates another exemplary scenario 202 of the network 100 illustrated in FIG. 1. As illustrated 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 on the PCell 210 and the SCell 220, respectively.

[0056] 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 a virtual PDCCH reception transmitted via a beam that the network device 110 uses 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.

[0057] In the example shown in FIG. 2B , the PDCCH can be transmitted on 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 on the PCell 210 or the SCell 220. For example, in response to detecting beam failure on 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. Thereafter, the terminal device 120 may monitor the control channel search space to receive a response to the BFR request.

[0058] 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 arise.

[0059] 3A and 3B illustrate problems 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 on the PCell 210 and the SCell 220, respectively, are distant from each other. A 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 the current 3GPP specification, a 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 cannot receive the BFR request. Furthermore, in the current 3GPP specification, a 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 receive the response to the BFR request. That is, in the current 3GPP specifications, BFR on PCell UL and PCell DL cannot be supported.

[0060] The embodiments of the present disclosure can solve the problems shown in FIGS. 3A and 3B.

[0061] In some embodiments, the network device 110 provides at least a PCell 210 and an SCell 220 to serve the terminal device 120, and in response to detecting a beam failure on 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 on the determined first cell. Thereafter, the terminal device 120 may monitor the control channel search space on the second cell to receive a response to the BFR request from the network device 110.

[0062] 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”).

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

[0064] In some embodiments, when a BFR request is transmitted on the PCell 210, the UL beam for transmission of the BFR request may reuse a beam on the PCell 210. For example, the QCL parameters for transmission of 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 nearest slot for the PCell 210, or any one of the beam failure detection RS or beam failure detection RS with the lowest identifier on the PCell 210, or some other RS ​​or TCI state on the PCell 210. For example, the terminal device 120 may determine the UL beam for transmission of the BFR request based on the set of beam failure detection resources configured for the PCell.

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

[0066] In some embodiments, a first set of PRACH resources, sequences, or preambles may be configured for transmission of a BFR request on the PCell 210, and a second set of PRACH resources, sequences, or preambles may be used to indicate identified different candidate beams on the PCell 210. In some embodiments, transmission of a BFR request on the 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 on the SCell 220 is transmitted on the PCell 210, a timing advance value on 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 (because a timing advance value was applied to the PRACH transmission of the BFR request), the PRACH transmission may be considered as a BFR for a beam failure on the SCell 220. In some embodiments, when a BFR request for a beam failure on the PCell 210 is transmitted on the PCell 210, there may not be a timing advance value available on the PCell 210. For example, if there is a time difference in the BFR request received at the 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 on the PCell 210.

[0067] In some embodiments, when a response to a BFR request is received on the PCell 210, the DL beam for transmission of the response may reuse a beam on the PCell 210. For example, the QCL parameters 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 nearest slot for the PCell 210, or any one of the beam failure detection RS or beam failure detection RS with the lowest identifier on the PCell 210, or some other RS ​​or TCI state on the PCell 210. For example, the terminal device 120 may determine a DL beam for detection of the response based on a set of beam failure detection resources configured for the PCell. For example, the response to the BFR request may be a random access response (RAR) received on the PCell 210. The RAR received on the PCell 210 may indicate recovery from beam failure on the SCell 220.

[0068] In some embodiments, when a response to a BFR request for an SCell is received on the PCell 210, there may be no timing adjustment command present in the response. 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, there may be no scheduling information present in the PDCCH. As another example, there may be no timing adjustment command present in the response. 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.

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

[0070] In some embodiments, a first set of BFR parameters (e.g., BFR counter, BFR time, etc.) in the PCell 210 may be used for beam failure on the PCell 210. In some embodiments, if a BFR request for beam failure on the SCell 220 is transmitted on the PCell 210, a second set of BFR parameters (e.g., BFR counter, BFR time, etc.) in the PCell 210 may be used for beam failure on 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 on the SCell 220 may reuse preamble resources used for BFR on the PCell 210, but the BFR counter or timer for BFR on the SCell 220 and the counter or timer for BFR on the PCell 210 may be separate from each other.

[0071] In some embodiments, to perform beam failure detection as described above, 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 received power of the CSI-RS on SCell 220 may be determined based on an SSB defined on SCell 220. However, in some embodiments, no SSB may be defined on SCell 220. In this case, in some embodiments, the power of the CSI-RS on SCell 220 may be determined based on the power of the SSB on PCell 210.

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

[0073] 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 on 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.

[0074] In block 420, the terminal device transmits a BFR request to the network device on the first cell.

[0075] At 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.

[0076] In some embodiments, the first cell is an SCell and the second cell is one of a PCell and 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 the BFR request to the network device on the SCell.

[0077] In some embodiments, the second cell is a SCell and the PDCCH order is received from the network device on either a PCell or an SCell.

[0078] 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.

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

[0080] 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 beams, QCL parameters associated with a physical random access channel (PRACH) for transmission of the BFR request, and transmitting the BFR request via the PRACH based on the QCL parameters.

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

[0082] 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 FIG. 1. Thus, device 500 can be implemented in or as at least a portion of network device 110 or terminal device 120.

[0083] As shown, device 500 includes a processor 510, a memory 520 coupled to processor 510, a suitable transmitter (TX) and receiver (RX) 540 coupled to processor 510, and a communication interface coupled 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 communication 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, an Un interface for communication between eNBs and relay nodes (RNs), or a Uu interface for communication between eNBs and terminal devices.

[0084] 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.

[0085] 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 digital signal processor (DSP), 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.

[0086] 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 the 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.

[0087] 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 local or distributed devices. In a distributed device, the program modules may be located in both local and remote storage media.

[0088] Program code for carrying out the 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, a special-purpose computer, or other programmable data processing apparatus, so that when the program code is executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are realized. The program code may be executed entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine, or entirely on a remote machine or server.

[0089] The program code may be embodied on a machine-readable medium, which may be any tangible medium that can 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. The machine-readable medium includes, but is 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 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.

[0090] 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.

[0091] Although the present disclosure has been described in language 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 disclosed as example forms of implementing the claims.

Claims

1. 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.

2. 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 .

3. the request is transmitted prior to the transmission of the information for the BFR. The terminal device according to claim 1 .

4. 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 .

5. 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 .

6. 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 .

7. 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 .

8. 1. A network device, comprising: The radio access point / radio ... Network devices.

9. 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 .

10. the request is transmitted prior to the transmission of the information for the BFR. The network device of claim 8 .

11. means for receiving from the terminal device the request transmitted at a particular cyclic shift; The network device of claim 8 .

12. 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.

13. 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.

14. the request is transmitted prior to the transmission of the information for the BFR. The method of claim 12.

15. transmitting the request to the network device, the request being transmitted in a particular cyclic shift. The method of claim 12.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. the request is transmitted prior to the transmission of the information for the BFR.

20. The method of claim 19.

22. receiving the request from the terminal device, the request being transmitted at a particular cyclic shift; 20. The method of claim 19.

Images