JP2023101012A - Terminal device, network device, and method executed in network device - Google Patents

Abstract

To provide a method for beam failure recovery, a device, and a computer-readable medium.SOLUTION: In an exemplary embodiment, a method executed in a terminal device is provided. The method includes providing at least a primary cell (PCell) and a secondary cell (SCell) for a network device to provide a service to the terminal device, and in response to detection of beam failure in the SCell, determining, from the PCell and the SCell, a first cell in which a beam failure recovery (BFR) request is transmitted to the network device and a second cell in which a response to the BFR request is received from the network device. The method further includes transmitting, by the first cell, the BFR request to the network device. The method further includes monitoring, by the second cell, a control channel search space to receive the response to the BFR request from the network device.SELECTED DRAWING: Figure 4

Description

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

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

A beam failure can occur when the quality of the associated control channel beam pair degrades sufficiently (eg, compared to the associated timer threshold or timeout). A mechanism to recover from a beam failure may be activated when a beam failure occurs. A beam failure recovery mechanism on the side of a terminal device (e.g., user equipment (UE)) typically detects beam failures, identifies new candidate beams, transmits beam failure recovery requests, and responds to beam failure recovery requests from network devices. Including actions such as monitoring. For example, a terminal device monitors a beam failure detection reference signal (RS) to assess whether a beam failure has occurred. When a beam failure occurs, the terminal device monitors beam-specific RSs to find new candidate beams. Once a candidate beam is identified, the terminal device sends a beam failure recovery request to the network device including information about the identified candidate beam. Terminal devices monitor the control channel search space to detect responses to beam failure recovery requests from network devices. When the terminal device receives the beam recovery acknowledgment from the network device, it can determine that a new beam pair has been established and the beam failure has been resolved.

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

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

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

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

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

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

Other features of the present disclosure will become readily apparent from the description that follows.

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.

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

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

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

FIG. 2B illustrates a possible problem with the BFR procedure in the exemplary scenario 202 shown in FIG. 2B. FIG. 2B illustrates a possible problem with the BFR procedure in the exemplary scenario 202 shown in FIG. 2B.

4 depicts a flowchart of an exemplary method 400 for beam failure recovery in accordance with some embodiments of the present disclosure.

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

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

The principles of the present disclosure will be explained with reference to several exemplary embodiments. It is understood that these embodiments are described for illustrative purposes only and do not imply any limitation on the scope of the disclosure, and are intended to assist those skilled in the art in understanding and practicing the present disclosure. The disclosure described herein can be embodied in various ways other than those described below.

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

As used herein, the singular forms "a," "an," and "the" unless the context clearly indicates otherwise. , is intended to include the plural. The term "including" 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" can refer to different objects or the same object. The following may contain other definitions, both explicit and implicit.

In some instances, values, procedures, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," and the like. Such statements are intended to indicate that there are many possible functional options to choose from, and that such choices need not be better, smaller, more expensive, or more preferable than other choices. It should be understood that

As discussed above, beam failure can occur when the quality of the associated control channel beam pair degrades sufficiently (eg, compared to a predetermined threshold or timeout of the associated timer). A mechanism to recover from a beam failure may be activated when a beam failure occurs. The beam failure recovery mechanism on the terminal device side typically includes operations such as detecting beam failures, identifying new candidate beams, transmitting beam failure recovery requests, and monitoring responses to beam failure recovery requests from network devices.

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

Embodiments of the present disclosure provide a solution for beam failure recovery to overcome one or more of the above problems and other potential problems. Solutions for beam failure recovery according to embodiments of the present disclosure can be applied to beam failures that occur in SCells. Further, embodiments of the present disclosure enable faster beam failure recovery than conventional beam failure recovery schemes.

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

FIG. 1 shows an exemplary communication network 100 in which embodiments of the present disclosure may be implemented. Network 100 includes network device 110 and terminal devices 120 served by network device 110 . Network 100 may provide one or more serving cells 102 to serve terminal devices 120 . It should be understood that the numbers of network devices, terminal devices and/or serving cells are for illustrative purposes only and do not imply any limitation on the present disclosure. Network 100 may include any suitable number of network devices, terminal devices and/or serving cells suitable for implementing embodiments of the present disclosure.

As used herein, the term "terminal device" refers to any device with wireless or wired communication capabilities. Examples of terminal devices include 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 devices, or Internet appliances that enable wireless or wired Internet access and browsing. For the purposes of discussion, some embodiments are described below with reference to a UE as an example of terminal device 220 .

As used herein, the term “network device” or “base station” (BS) refers to a device capable of providing or hosting a cell or coverage with which terminal devices can communicate. Examples of network devices include Node B (NodeB or NB), Evolved NodeB (eNodeB or eNB), Next Generation NodeB (gNB), Remote Radio Unit (RRU), Radio Head (RH), Remote These include, but are not limited to, radio heads (RRHs) and low power nodes such as femto nodes and pico nodes.

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

In some other scenarios, for example, terminal device 120 may establish connections with two different network devices (not shown in FIG. 1), thereby using radio resources of the two network devices. can be used. Two network devices may be defined as a master network device and a secondary network device, respectively. A master network device may serve a group of serving cells, also called a “Master Cell Group (MCG)”. A secondary network device may also serve a group of serving cells, also called a "Secondary Cell Group (SCG)." For dual connectivity operation, the term “special cell (SpCell)” refers to the MCG Pcell or the SCG primary Scell (PScell), depending on whether the terminal device 120 is associated with the MCG or SCG, respectively. good too. Outside of dual connectivity operation, the term "SpCell" may also refer to PCell.

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

Communications in network 100 may conform to any suitable standard, where standards include 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) : GSM EDGE Radio Access Network), etc. Further, communication may be performed according to any generation of communication protocols now known or developed in the future. Examples of communication protocols include first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation ( 5G) communication protocols, but are not limited to these.

A network device 110 (eg, next generation NodeB (gNB)) may comprise 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 network devices located at a particular geographic location. For example, network device 110 may be connected with multiple TRPs in different geographical locations to achieve better coverage. One or more TRPs may be included in the same serving cell or in different serving cells.

FIG. 2A shows an exemplary scenario 201 for network 100 shown in FIG. As shown in FIG. 2A, for example, network device 110 of FIG. 1 may provide PCell 210 and SCell 220 to provide services to terminal device 120 . PCell 210 and SCell 220 may overlap each other. Network device 110 may be connected with TRP 230 located on both PCell 210 and SCell 220 .

Due to beam inaccuracy, occlusion effects, movement of terminal device 120, or some other reason, network device 110 may cause network device 110 to overwrite a control channel (eg, Physical Downlink Control Channel (PDCCH)). A beam failure may occur when the terminal device 120 is no longer reachable by For example, terminal device 120 may detect such a situation by estimating the quality of the virtual PDCCH reception transmitted over the beam that network device 110 uses to reach terminal device 120 . To perform beam failure detection, terminal device 120 may estimate the quality of virtual PDCCH reception based on reception of a given reference signal (RS). In the following description, this reference signal may be called "beam failure detection RS" or "beam failure detection RS". Examples of beam failure detection RS include periodic Channel State Information-Reference Signal (CSI-RS), Synchronization Signal Block (SSB), or a combination thereof, It is not limited to these.

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

In some embodiments, in response to detection of a beam failure at SCell 220, terminal device 120 is first configured for the SCell to identify candidate beams for beam failure recovery. A set of beam-specific RSs may be monitored. 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 network device 110 in the first cell.

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

In some embodiments, a quasi co-location (QCL) type may be configured for the RS. The pseudo-colocation types are QCL-Type A {Doppler shift, Doppler spread, mean delay, delay spread}, QCL-Type B {Doppler shift, Doppler spread}, QCL-Type C {Doppler shift, mean delay}, and QCL-Type D {Spatial Rx parameter}.

In some embodiments, beam failure recovery procedures may be different for different scenarios. PCell 210 and SCell 220 may be associated with a first frequency range FR1 and a second frequency range FR2, respectively. For example, the first frequency range FR1 may be below 6 GHz and the second frequency range FR2 may be above 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 only be required on the SCell, but not on the PCell. In some embodiments, eg, in exemplary scenario 201 shown in FIG. 2A, PCell 210 and SCell 220 may be configured in the same frequency range, eg, FR2. In some embodiments, in this case the DL beam on the PCell and the DL beam on the SCell have similar properties. 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 exemplary scenario 201 shown in FIG. 2A, both PCell 210 and SCell 220 may be configured in the same frequency range, eg, FR1. In some embodiments, this case may not require BFR for both PCell 210 and SCell 220 . For example, if all of the RSs configured for PCell 210 and SCell 220 are not configured with QCL-Type D, then both PCell 210 and SCell 220 may not require BFR.

In some embodiments, for example, in exemplary scenario 201 shown in FIG. 2A, PCell 210 and SCell 220 may be configured in the same frequency range. For example, in this case intra-band CA where intra-band consecutive CCs are aggregated may be supported. In some embodiments, in this case, when a beam obstruction is detected on the SCell, another beam obstruction may be detected on the PCell at the same time. In some embodiments, in this case BFR may only be required on the PCell. Further, if a beam failure detection RS is configured for the SCell 220, this beam failure detection RS may be QCL-ized with at least one beam failure detection RS configured for the PCell 210 and QCL-Type D. Alternatively or additionally, if a beam-specific RS is configured for SCell 220, this beam-specific RS may be QCL-ized with QCL-TypeD with at least one beam-specific RS configured for PCell 210. . That is, in this case, cross-carrier pseudo collocation (QCL) can be supported.

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

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

In some embodiments, for the "BFR on SCell UL" case, transmission of BFR requests may be triggered by PDCCH order. In some embodiments, in this case, terminal device 120 may transmit a request for PDCCH order on PCell 210 before transmitting the BFR. In some embodiments, requests for PDCCH orders may be transmitted over a physical uplink control channel (PUCCH) or a physical random access channel (PRACH) within PCell 210 . For example, a request for a PDCCH order may be transmitted on the PCell 210 using at least one of a specific sequence, specific time resources, specific frequency resources, and specific cyclic shifts of the PUCCH or PRACH sequences. For example, the index of the identified candidate beam may not be carried in the request. In response to receiving a PDCCH order from network device 110 , the terminal device may transmit a BFR request to network device 110 on SCell 220 . That is, in this case the PDCCH order can trigger the transmission of BFR across carriers. In some embodiments, for example, a field occupying some reserved bits in the PDCCH order can be used to indicate the index of the cell in which the BFR request is transmitted. For example, 3 bits in PDCCH order may be used to indicate the cell index.

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

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

In some embodiments, for the "BFR on SCell UL" case, transmission of BFR requests may be triggered by PDCCH orders. In some embodiments, in this case, terminal device 120 may transmit a request for PDCCH order on SCell 220 before transmitting the BFR. In response to receiving a PDCCH order from network device 110 , the terminal device may transmit a BFR request to network device 110 on 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, for the “BFR on SCell UL” case, in response to detecting a beam failure on SCell 220 , terminal device 120 may request a PDCCH order on SCell 220 without requesting a PDCCH order from network device 110 . The BFR request may be transmitted directly to network device 110 . In some embodiments, the BFR request specifies the Physical Random Access Channel (PRACH) to initiate Contention Free Based Random Access (CFRA) procedures for BFR. may be transmitted via Contention Based Random Access (CBRA) may not be supported in SCells. Thus, in some embodiments, rather than initiating a CBRA procedure on SCell 220, a SCell failure may be reported to network device 100 on PCell 210 when the BFR timer expires. For example, additional states in channel state information (CSI) reports can be used to indicate SCell failures. Alternatively or additionally, a specific PRACH resource may be configured for SCell failure reporting 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 SCell failures.

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

In some embodiments, for the "BFR on SCell UL and PCell DL" case, in response to detecting a beam failure on SCell 220, terminal device 120 may request a PDCCH order from network device 110 without , SCell 220 may transmit the BFR request directly to network device 110 . In some embodiments, a 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 SCells. Thus, in some embodiments, rather than initiating a CBRA procedure on SCell 220, a SCell failure may be reported to network device 100 on PCell 210 when the BFR timer expires. For example, additional states in channel state information (CSI) reports can be used to indicate SCell failures. Alternatively or additionally, a specific PRACH resource may be configured for SCell failure reporting 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 SCell failures.

In some embodiments, CFRA-based BFR may be supported in SCell 220 for the “BFR on SCell UL and PCell DL” case. 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, a BFR request may be transmitted over PRACH resources on SCell 220 . In some embodiments, PRACH resources may be QCLed with identified candidate beams in SCell 220 . In some embodiments, “BFR on SCell UL and PCell DL” is not available if QCL-TypeD is not configured for any RS in PCell 210 .

In some embodiments, for the “BFR on SCell UL and PCell DL” case, terminal device 120 monitors responses to BFR requests on PCell 210 while the BFR requests are transmitted over PRACH on SCell 220. good too. In some embodiments, the subcarrier spacing (SCS) associated with the PCell may differ 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 PCell 210 or SCell 220 . For example, assuming slot #n is the slot for transmission of the BFR request in SCell 220, slot #(n'+k) may be the slot for receiving the response to the BFR request in PCell 210. Here, slot #n' is the nearest slot in PCell 210 that overlaps slot #n in SCell 220, and time interval k can be determined based on the SCS associated with PCell 210 or SCell 220.

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

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

If network device 110 becomes unable to reach terminal device 120 via a control channel (eg, PDCCH) due to beam inaccuracy, occlusion effects, movement of terminal device 120, or some other reason, Beam obstruction may occur. For example, terminal device 120 may detect such a situation by estimating the quality of the virtual PDCCH reception transmitted over the beam that network device 110 uses to reach terminal device 120 . To perform beam failure detection, terminal device 120 may estimate the quality of virtual PDCCH reception based on reception of a given beam failure detection RS.

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

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

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

Embodiments of the present disclosure can solve problems such as those shown in FIGS. 3A and 3B.

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

In some embodiments, for example, in exemplary scenario 202 shown in FIG. The determined second cell received may also be PCell 210 (ie, "BFR on PCell UL and PCell DL").

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

In some embodiments, if a BFR request is transmitted on the PCell 210, the UL beam for transmission of the BFR request may reuse the beam on the PCell 210. For example, the QCL parameters for BFR request transmission (i.e., PRACH transmission) are determined based on the identified new candidate beam, but the lowest identifier configured in the immediate slot for PCell 210. TCI (Transmission Configuration Indicator) state of the core set (CORESET), or any one of the beam failure detection RS or the beam failure detection RS with the lowest identifier in the PCell 210, or some other in the PCell 210 It may be determined based on RS or TCI status. For example, 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.

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

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

In some embodiments, if a response to a BFR request is received at PCell 210 , the DL beam for transmission of the response may reuse the beam at PCell 210 . For example, the QCL parameters for the control resource set configured for BFR (“CORESET-BFR”) are not determined based on the identified new candidate beams, for example, the most recent slot for PCell 210 or any one of the beam failure detection RS or the beam failure detection RS with the lowest identifier in the PCell 210 or some other RS in the PCell 210 Or it may be determined based on the TCI status. For example, terminal device 120 may determine the DL beam for response detection based on the 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 at PCell 210 . The RAR received on PCell 210 may indicate recovery from beam failure on SCell 220 .

In some embodiments, when a response to a BFR request for a SCell is received at PCell 210, there may be no timing adjustment commands in the response. In some embodiments, responses to BFR requests may be transmitted over the PDCCH. In some embodiments, the PDCCH may be a compact PDCCH. For example, PDCCH may not have scheduling information. As another example, there may be no timing adjustment commands 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, responses to BFR requests may be transmitted via PDCCH with CSI requests and/or PDCCH orders.

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

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

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

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

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

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

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

In some embodiments, the first cell is a SCell and the second cell is either a PCell or SCell. A 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 on the SCell to the network device.

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

In some embodiments, the first cell is the PCell, the terminal device determines the first resource for transmission of the BFR request based on a set of beam failure detection resources configured for the PCell; The BFR request may be transmitted by transmitting the BFR request to the network device over 1 resource.

In some embodiments, the second cell is a PCell, the terminal device determines a quasi-collocation (QCL) parameter associated with the control channel search space based on the candidate beams, and determines the control channel based on the QCL parameter. Monitoring the search space monitors the control channel search space.

In some embodiments, the first cell is the SCell and the second cell is the PCell. The terminal device determines QCL parameters associated with a physical random access channel (PRACH) for transmission of the BFR request based on the candidate beams, and transmits the BFR request over the PRACH based on the QCL parameters, A BFR request may be transmitted.

It can be seen that embodiments of the present disclosure provide a solution for beam failure recovery. Solutions for beam failure recovery according to embodiments of the present disclosure can be applied to beam failures that occur in SCells. Moreover, embodiments of the present disclosure enabled faster beam failure recovery than conventional beam failure recovery schemes.

FIG. 5 is a simplified block diagram of a device 500 suitable for implementing embodiments of the present disclosure. Device 500 may be considered a further exemplary embodiment of network device 110 or terminal device 120 shown in FIG. Accordingly, device 500 may be implemented in or as at least part of network device 110 or terminal device 120 .

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

Program 530 is a program that, when executed by associated processor 510, enables device 500 to operate in accordance with embodiments of the present disclosure, as described herein with reference to FIGS. It is assumed to contain instructions. Embodiments herein may be implemented by computer software executable by processor 510 of device 500, by hardware, or by a combination of software and hardware. Processor 510 may be configured to implement various embodiments of the present disclosure. Further, the combination of processor 510 and memory 520 may form processing means 550 suitable for implementing various embodiments of the present disclosure.

Memory 520 may be of any type suitable for local technology networks, non-limiting examples include non-transitory computer readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, It may be implemented using any suitable data storage technology such as optical memory devices and systems, fixed memory devices and removable memory. Although only one memory 520 is shown in device 500, device 500 may have multiple memory modules that are physically separate. Processor 510 may be of any type suitable for local technology networks, non-limiting examples include general purpose computers, special purpose computers, microprocessors, DSPs (Digital Signal Processors), and based on multi-core processor architectures. It may include one or more of the processors. Device 500 may have multiple processors, such as application specific integrated circuit chips that are temporally dependent on a clock that synchronizes the main processor.

In general, various embodiments of the present disclosure may be implemented in hardware or dedicated circuitry, 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. Although various aspects of the embodiments of the present disclosure are illustrated and described using block diagrams, flowcharts, or some other pictorial representations, these blocks, devices, systems, techniques, or techniques described herein. It is understood that the methods may be implemented in hardware, software, firmware, dedicated circuitry or logic, general purpose hardware or controllers or other computing devices, or some combination thereof, as non-limiting examples. want to be

The present disclosure further provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. A computer program product comprises computer-executable instructions, such as those contained in a program module, executed on a device on a real or virtual processor of interest to perform the process or method described above with reference to FIG. including. 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 split between program modules described in various embodiments. Machine-executable instructions for program modules may be executed within local or distributed devices. In a distributed device, program modules may be located in both local and remote storage media.

Program code to implement 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, special purpose computer, or other programmable data processing apparatus such that when the program code is executed by the processor or controller, the flowcharts and/or block diagrams are represented. The functions/operations specified in are realized. The program code may run entirely on a machine, part thereof may run on a machine, it may run as a stand-alone software package, part may run on a machine and part may run on the remote machine, or may run entirely on the remote machine or server.

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

Further, although acts have been depicted in a particular order, this does not mean that such acts are performed in the specific order shown, or in any sequential order, or any other order depicted to achieve desirable results. It should not be understood as requiring that an action be performed. Multitasking and parallel processing may be advantageous in certain situations. Similarly, although the above description contains details of certain specific embodiments, these should not be construed as limiting the scope of the disclosure, as features unique to the specific embodiments may be included. should be construed as an explanation of 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 can also be implemented in multiple embodiments separately or in any suitable subcombination.

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

Claims (12)

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 on the SCell;
transmitting information for beam failure recovery (BFR) indicating candidate beams and indices of the SCells to the network device; transmitting information for the BFR without requesting scheduling; or sending a request requesting scheduling of transmission of information for BFR, wherein the beam impairment of the SCell is indicated in a channel state information (CSI) report status;
monitoring a physical downlink control channel (PDCCH) on the SCell to receive a response to information for the BFR from the network device;
How to prepare. the request is sent prior to the sending of information for the BFR;
The method of claim 1. further comprising sending to the network device the request sent on a particular cyclic shift;
The method of claim 1. Sending the request includes:
determining a first resource for transmission of the request based on a set of beam failure detection resources configured for the PCell;
sending the request to the network device over the first resource;
including,
The method of claim 1. Sending information for the BFR includes:
identifying the candidate beam;
including information about the candidate beams in information for the BFR;
transmitting information for the BFR to the network device;
including,
The method of claim 1. Monitoring the PDCCH includes:
determining quasi-colocation (QCL) parameters associated with the PDCCH based on the candidate beams;
monitoring the PDCCH based on the QCL parameters;
including,
6. The method of claim 5. a terminal device,
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 on the SCell;
transmitting information for beam failure recovery (BFR) indicating candidate beams and indices of the SCells to the network device; transmitting information for the BFR without requesting scheduling; or sending a request requesting scheduling of transmission of information for BFR, wherein the beam impairment of the SCell is indicated in a channel state information (CSI) report status;
monitoring a physical downlink control channel (PDCCH) on the SCell to receive a response to information for the BFR from the network device;
comprising a processor for performing an operation comprising
terminal device. the request is sent prior to the sending of information for the BFR;
The terminal device according to claim 7. further comprising sending to the network device the request sent on a particular cyclic shift;
The terminal device according to claim 7. Sending the request includes:
determining a first resource for transmission of the request based on a set of beam failure detection resources configured for the PCell;
sending the request to the network device over the first resource;
including,
The terminal device according to claim 7. Sending information for the BFR includes:
identifying the candidate beam;
including information about the candidate beams in information for the BFR;
transmitting information for the BFR to the network device;
including,
The terminal device according to claim 7. Monitoring the PDCCH includes:
determining quasi-colocation (QCL) parameters associated with the PDCCH based on the candidate beams;
monitoring the PDCCH based on the QCL parameters;
including,
The terminal device according to claim 11.

Images