Patent Description:
New radio access system, which is also called NR system or NR network, is the next generation communication system. It has been agreed that carrier aggregation (CA) which is used in Long Term Evolution (LTE) -Advanced to increase the bandwidth will be supported in the NR system. Each aggregated carrier is referred to as a component carrier (CC). When CA is used, there are a number of serving cells, one for each CC. Generally, a primary cell (Pcell) corresponding to a primary CC and at least one secondary cell (Scell) corresponding to at least one secondary CC are provided.

A beam failure may occur when the quality of beam pair(s) of a serving cell falls low enough (for example, comparison with a threshold or time-out of an associated timer). Beam failure recovery is a mechanism for recovering beams when all or part of beams serving a terminal device has failed. In RAN2 #<NUM> meeting for the 3GPP working group, it was already agreed that the beam failure recovery is supported in the same carrier case of CA. However, there still remain questions regarding the beam failure recovery for the Scell.

<CIT> (published after the priority date of the present application) discloses methods, devices and computer readable media for beam failure recovery for a secondary cell. A method implemented in a terminal device includes: in response to a beam failure on a secondary cell (Scell), transmitting a scheduling request to a network device; receiving, from the network device and on a primary cell (Pcell), a response indicating a resource allocated to the terminal device; transmitting, to the network device and using the allocated resource, a beam failure recovery request comprising a beam index of a beam selected from available beams on the Scell by the terminal device, to recover communication between the terminal device and the network device via the selected beam on the Scell.

3GPP draft R2-<NUM> provides analyses in respect of possible solutions on how to report beam failure for an SCell.

3GPP draft R1-<NUM> provides a discussion in respect of issues relating to beam failure recovery in the context of 3GPP RAN meetings #<NUM>, #<NUM>, #<NUM> and #<NUM>.

The present invention is set out in the appended independent claims.

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

It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitations as to the scope of the disclosure.

As used herein, the term "network device" or "base station" (BS) refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a Node B (NodeB or NB), an Evolved NodeB (eNodeB or eNB), a NodeB in new radio access (gNB) a Remote Radio Unit (RRU), a radio head (RH), a remote radio head (RRH), a low power node such as a femto node, a pico node, and the like. For the purpose of discussion, in the following, some embodiments will be described with reference to gNB as examples of the network device.

As used herein, the term "terminal device" refers to any device having wireless or wired communication capabilities. Examples of the terminal device include, but not limited to, user equipment (UE), personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs), portable computers, image capture devices such as digital cameras, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like.

The term "includes" and its variants are to be read as open terms that mean "includes, but is not limited to. " The term "based on" is to be read as "based at least in part on. " The term "one embodiment" and "an embodiment" are to be read as "at least one embodiment. " The term "another embodiment" is to be read as "at least one other embodiment. " The terms "first," "second," and the like may refer to different or same objects.

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

As mentioned above, a beam failure may occur when the quality of beam pair(s) of a serving cell falls low enough. A mechanism to recover from a beam failure may be triggered when the beam failure occurs. The beam failure recovery mechanism on terminal device side usually includes the following operations: beam failure detection, identification of a new beam, transmission of a beam failure recovery request and monitoring a response to the beam failure recovery request from a network device. In 3GPP specifications TS <NUM> and <NUM>, the beam failure recovery (BFR) procedure for Pcell has been specified as follows:.

Herein, the PRACH preamble is also referred as random access preamble.

However, this procedure does not work for beam failure recovery for Scell. Different from beam failure recovery for Pcell, media access control element (MAC CE) can be used in beam failure recovery for Scell since the link on Pcell can work when the beam fails in Scell. When MAC CE is used for beam failure recovery, there may be a problem of how to indicate the new beam if there is no physical uplink shared channel (PUSCH) resource to transmit MAC CE.

Conventionally, buffer status report (BSR) is transmitted using the remaining bits (padding bits) of a PUSCH. A possible solution to the above problem is to use the physical uplink control channel (PUCCH) resources. There are several symbols for a PUCCH format and the PUCCH resources are determined by the size of uplink control information (UCI) and acknowledge resource indicator (ARI). Thus, there may be remaining resources on the PUCCH which are not used to transmit the UCI. For example, if UE transmit the UCI using PUCCH format <NUM> or PUCCH format <NUM> in a PUCCH resource that includes <MAT> physical resource blocks (PRB), the UE determines a number of PRBs <MAT> for the PUCCH transmission to be the minimum number of PRBs. Therefore, the remaining number of PRBs may be determined based on <MAT> and <MAT>. The inventors of the present application have realized that the remaining resources on the PUCCH which are not used to transmit the UCI may be used for the beam failure recovery for the Scell.

Embodiments of the present disclosure provide a solution for beam failure recovery. The solution for beam failure recovery in accordance with embodiments of the present disclosure can be adapted to the beam failure occurring on the Scell. Moreover, embodiments of the present disclosure specify the procedures for the beam failure recovery using MAC CE and can solve the above problem and one or more of other potential problems.

Principle and implementations of the present disclosure will be described in detail below with reference to <FIG>.

<FIG> shows an example communication network <NUM> in which embodiments of the present disclosure can be implemented. The network <NUM> includes a network device <NUM> and a terminal device <NUM> served by the network device <NUM>. The network <NUM> may provide one or more serving cells <NUM>, <NUM> to serve the terminal device <NUM>, with each serving cell corresponding to a CC. It is to be understood that the number of network devices, terminal devices and serving cells is only for the purpose of illustration without suggesting any limitations. The network <NUM> may include any suitable number of network devices, terminal devices and serving cells adapted for implementing embodiments of the present disclosure.

In the communication network <NUM>, the network device <NUM> can communicate data and control information to the terminal device <NUM> and the terminal device <NUM> can also communication data and control information to the network device <NUM>. A link from the network device <NUM> to the terminal device <NUM> is referred to as a downlink (DL) or a forward link, while a link from the terminal device <NUM> to the network device <NUM> is referred to as an uplink (UL) or a reverse link.

Depending on the communication technologies, the network <NUM> may be a Code Division Multiple Access (CDMA) network, a Time Division Multiple Address (TDMA) network, a Frequency Division Multiple Access (FDMA) network, an Orthogonal Frequency-Division Multiple Access (OFDMA) network, a Single Carrier-Frequency Division Multiple Access (SC-FDMA) network or any others. Communications discussed in the network <NUM> may use conform to any suitable standards including, but not limited to, New Radio Access (NR), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), cdma2000, and Global System for Mobile Communications (GSM) and the like. Furthermore, the communications may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (<NUM>), the second generation (<NUM>), <NUM>, <NUM>, the third generation (<NUM>), the fourth generation (<NUM>), <NUM>, the fifth generation (<NUM>) communication protocols. For clarity, certain aspects of the techniques are described below for LTE, and LTE terminology is used in much of the description below.

CA can be supported in the network <NUM>, in which two or more CCs are aggregated in order to support a broader bandwidth. In CA, the network device <NUM> may provide to the terminal device <NUM> a plurality of serving cells including one Pcell <NUM> and at least one SCell <NUM>. The terminal device <NUM> can establish Radio Resource Control (RRC) connection with the network device <NUM> on the Pcell <NUM>. The Scell <NUM> can provide additional radio resources once the RRC connection between the network device <NUM> and the terminal device <NUM> is established and the Scell <NUM> is activated via higher layer signaling.

It is to be understood that the configuration of Pcell <NUM> and Scell <NUM> shown in <FIG> is only for the purpose of illustration without suggesting any limitations. Pcell <NUM> and Scell <NUM> may be in other configuration than that shown in <FIG>.

In some other scenarios, for example, the terminal device <NUM> may establish connections with two groups of CCs (not shown in <FIG>) and thus can utilize more radio resources. The two groups of CCs may be respectively defined as a master group of CCs and a secondary group of CCs. The master group of CCs may provide a group of serving cells, which are also referred to as "Master Cell Group (MCG)". The secondary group of CCs may also provide a group of serving cells, which are also referred to as "Secondary Cell Group (SCG)". For dual connectivity operation, a term "Special Cell (SpCell)" may refer to the Pcell of the MCG or the primary Scell (PScell) of the SCG depending on if the terminal device <NUM> is associated to the MCG or the SCG, respectively. In other cases than the dual connectivity operation, the term "SpCell" may also refer to the Pcell. Although Pcell is illustrated as examples, embodiments of the present disclosure may be also applicable to both groups of dual connectivity configuration.

In embodiments, the network device <NUM> is configured to implement beamforming technique and transmit signals to the terminal device <NUM> via a plurality of beams. The terminal device <NUM> is configured to receive the signals transmitted by the network device <NUM> via the plurality of beams. There may be different beams associated with the Pcell <NUM> and the Scell <NUM>. As shown in <FIG>, DL beams <NUM> and <NUM> are associated with the Scell <NUM>. It is to be understood that the Scell <NUM> may have more beams associated therewith. Although not shown, the Pcell <NUM> may also have beams associated therewith.

As mentioned above, a beam failure may occur on the Scell <NUM>. For example, the network device <NUM> may be configured to transmit a signal via the beam <NUM> and the terminal device <NUM> may detect a beam failure of the beam <NUM>. Then, a beam failure recovery procedure may be initiated. Specifically, the terminal device <NUM> may identify a new beam for recovery from the beam failure. For example, the terminal device <NUM> may select a beam <NUM> from available beams on the Scell <NUM> as a new candidate beam, for example, based on the qualities of the available beams. For ease of discussion, the new beam identified by the terminal device <NUM> is hereinafter referred to as the selected beam <NUM>.

The terminal device <NUM> may include information on the selected beam <NUM> in a beam failure recovery request. The terminal device <NUM> may then transmit the beam failure recovery request to the network device <NUM>, such that the network device <NUM> communicates with the terminal device <NUM> via the selected beam <NUM> of the Scell <NUM>.

Implementations of the present disclosure will be described in detail below with reference to <FIG>. <FIG> illustrate example methods according to some embodiments of the present disclosure implemented at a terminal device. It is to be understood that the methods shown may include additional acts not shown and/or may omit some shown acts, and the scope of the present disclosure is not limited in this regard.

<FIG> illustrates a flowchart of an example method <NUM> for beam failure recovery for a Scell in accordance with the invention. The method <NUM> can be implemented at the terminal device <NUM> shown in <FIG>. For the purpose of discussion, the method <NUM> will be described with reference to <FIG>.

At <NUM>, the terminal device <NUM> determines whether there is a beam failure on a Scell. If the terminal device <NUM> determines a beam failure on the Scell <NUM>, the terminal device <NUM> at <NUM> transmits a scheduling request to a network device, for example, the network device <NUM>.

The scheduling request may be a PRACH transmission on PRACH channel of the Pcell <NUM> or the Scell <NUM>. In such cases, the preamble of PRACH transmission may be based on CFRA or contention-based random access (CBRA). Alternatively, the scheduling request is a scheduling request (SR) transmitted on the PUCCH of the Pcell <NUM>.

At <NUM>, the terminal device <NUM> receives from the network device <NUM> and on a Pcell (e.g. the Pcell <NUM>), a response indicating a uplink resource allocated to the terminal device <NUM>. The response may be transmitted on physical downlink control channel (PDCCH) of the Pcell <NUM> and comprises downlink control information (DCI) indicating a UL grant on physical uplink shared channel (PUSCH). Depending on the type of the scheduling request transmitted at <NUM>, the response may be scrambled by different types of Radio Network Temporary Identifier (RNTI), such as random access-RNTI (RA-RNTI) determined by the PRACH transmission occasion or cell-RNTI (C-RNTI) allocated to terminal device.

At <NUM>, the terminal device <NUM> transmits, to the network device <NUM> and using the allocated resource, a beam failure recovery request comprising a beam index of a new beam selected from available beams on the Scell by the terminal device, to recover communication between the terminal device and the network device via the selected beam on the Scell. The terminal device <NUM> includes the beam failure recovery request in MAC CE and transmits the MAC CE using the resource allocated by the network device <NUM>, e.g. on the PUSCH.

The beam failure recovery request comprises the beam index of the selected beam <NUM> and may comprise the Scell index of the Scell <NUM>. Accordingly, the structure of MAC CE can be designed as in show in Table <NUM>. The field "LGID" indicates that the MAC CE is for beam failure recovery, the field "Serving Cell ID" indicates the Scell index with beam failure, and the field "RS ID" indicates the beam index of the new beam. It is to be noted that in the case where the scheduling request is transmitted on the Scell <NUM>, the Scell index may be omitted. Although not shown, there may be reserved bits in the MAC-CE structure to align the length of MAC-CE information to an integer number of bytes.

As mentioned above, the scheduling request is either a PRACH transmission or scheduling request on PUCCH. The embodiments where the scheduling request is a PRACH transmission and the embodiments where the scheduling request on PUCCH is a scheduling request will be described below with respect to <FIG>.

In some embodiments, after transmitting the beam failure recovery request at <NUM>, the terminal device <NUM> may monitor downlink control information in both PDCCH of the Pcell <NUM> and the Scell <NUM> during a timing window (also referred to as BFR-RA-window herein) for beam failure recovery request response. The terminal device <NUM> initiates a timer for the BFR-RA-window, for example, several slots after transmitting the beam failure recovery request at <NUM>, and the timer expires when the duration of BFR-RA-window ends. If a downlink control information in PDCCH for rescheduling the transmitted PUSCH which contains the beam failure recovery request in MAC CE is received from the network before the timer expires, then the terminal device <NUM> may retransmit the PUSCH containing the beam failure recovery request in MAC CE to the network device <NUM>, and restart the timer for the BFR-RA-window to monitor beam failure recovery request response.

The BFR-RA-window may have a predetermined duration. If the timer has expired or the BFR-RA-window ends, but no response to the beam failure recovery request has been received, then the terminal device <NUM> may terminate the beam failure recovery procedure, without retransmitting the beam failure request to the network device <NUM>. The terminal device <NUM> may further indicate to the higher layer an unsuccessful beam failure recovery event.

Alternatively, the BFR-RA-window may be initiated by receiving an acknowledge message from the network device <NUM>. For example, the terminal device <NUM> may receive a message which explicitly acknowledges the reception of the PUSCH transmitted at <NUM>. After that, the terminal device <NUM> may initiate or start the BFR-RA-window.

In the embodiments described above, the scheduling request procedure may be a normal procedure which can be reused for other purpose, e.g., the PRACH transmission and the selected PRACH preamble can be used for uplink synchronization. In some embodiments, a dedicated procedure, such as a dedicated PRACH transmission, may be used only for the purpose of beam failure recovery, which will be described below with respect to <FIG> and <FIG>.

<FIG> illustrates a flowchart of an example method <NUM> for beam failure recovery for a Scell in accordance with some embodiments of the present disclosure. The method <NUM> can be implemented at the terminal device <NUM> shown in <FIG>. For the purpose of discussion, the method <NUM> will be described with reference to <FIG>.

At <NUM>, the terminal device <NUM> determines whether there is a beam failure on a Scell. If the terminal device <NUM> determines a beam failure on the Scell <NUM>, the terminal device <NUM> at <NUM> determines a PRACH preamble to be transmitted, from a set of dedicated preambles. The PRACH preamble index indicates a Scell index of the Scell <NUM>. For example, the terminal device <NUM> may determine the PRACH preamble based on a predefined mapping relation between the PRACH preamble indices and the at least one Scell provided by the network device <NUM>. The PRACH preambles can be contention free based.

At <NUM>, the terminal device <NUM> transmits the PRACH preamble determined at <NUM> to a network device <NUM>. For example, the terminal device <NUM> may initiate a dedicated PRACH transmission to the network device <NUM> with the PRACH preamble determined at <NUM>. The terminal device <NUM> may transmit the preamble on PRACH channel of the Pcell <NUM>.

At <NUM>, the terminal device <NUM> receives, from the network device <NUM> and on a Pcell, downlink control information including a request for CSI reporting for the Scell <NUM>. The downlink control information may be scrambled with the C-RNTI of the terminal device and received on a CORESET-BFR which is a control resource set used dedicatedly for beam failure recovery.

At <NUM>, the terminal device <NUM> transmits, to the network device <NUM> and in response to the CSI request, a beam index of a beam selected from available beams on the Scell <NUM> by the terminal device <NUM>, to recover communication between the terminal device <NUM> and the network device <NUM> via the selected beam on the Scell <NUM>. For example, the terminal device <NUM> may include the beam index of the selected beam <NUM> in a CSI report and transmit the CSI report on the PUSCH of the Pcell <NUM> according to the CSI request.

In such embodiments, the Scell index is implicitly indicated by the PRACH preamble index in a PRACH transmission and then the beam index is explicitly included in the CSI report. Therefore, the terminal device <NUM> may notify the network device <NUM> of the Scell on which a beam failure has occurred with the Scell index indicated by the PRACH preamble transmitted at <NUM>, and notify the network device <NUM> of the candidate beam with the beam index of the selected beam <NUM> transmitted at <NUM>.

In some embodiments, the terminal device <NUM> may receive from the network device <NUM> a response to the beam failure recovery request (also referred to as BFR response) after the CSI report. The BFR response is for link reconfiguration of Scell based on the reported beam index, and may be received either on the Pcell <NUM> or on the Scell <NUM>.

In the embodiments described with respect to <FIG>, the beam failure recovery procedure may utilize a PRACH preamble which is deliberately selected and thus indicates index information on the Scell. In this way, the explicit transmission of the Scell index may be omitted. Thus, the overhead for the beam failure recovery can be reduced.

At <NUM>, the terminal device <NUM> determines whether there is a beam failure on a Scell. If the terminal device <NUM> determines a beam failure on the Scell <NUM>, the terminal device <NUM> at <NUM> determines a PRACH preamble to be transmitted. The PRACH preamble index indicates a beam index of a beam selected from available beams on the Scell <NUM> by the terminal device <NUM>. For example, the terminal device <NUM> may determine the PRACH preamble to be transmitted based on a predefined mapping relation between the PRACH preambles dedicated for beam failure recovery purpose and a plurality of beams associate with the Scell <NUM>.

At <NUM>, the terminal device <NUM> transmits the PRACH preamble to a network device and on the Scell <NUM>, to recover communication between the terminal device <NUM> and the network device <NUM> via the selected beam <NUM> on the Scell <NUM>. For example, the terminal device <NUM> may initiate a dedicated PRACH transmission on the Scell <NUM> to a network device with PRACH preamble index determined at <NUM>.

In such embodiments, since the PRACH preamble is transmitted on the Scell <NUM>, the terminal device <NUM> may not need to transmit with the information on the Scell index. Since the beam index is implicitly indicated by the PRACH preamble, the terminal device <NUM> also may not explicitly transmit the information on the beam index. Therefore, by transmitting the PRACH preamble on the Scell through a dedicated PRACH procedure, the terminal device <NUM> may notify the network device <NUM> of the beam failure recovery in only one message.

In the embodiments described with respect to <FIG>, the beam failure recovery procedure may utilize a PRACH transmission on the Scell and the PRACH preamble is deliberately selected and thus indicates information on the candidate beam. In this way, the explicit transmission of the Scell index and the beam index may be omitted. Thus, the overhead for the beam failure recovery can be further reduced.

As mentioned above, there may be situation where no PUSCH is available for the transmission of MAC CE and thus the beam failure recovery request cannot be transmitted. When PUCCH transmission is available, the remaining resources of a PUCCH may be used for beam failure recovery request.

Upon receiving data from the network device <NUM> and on a physical downlink shared channel (PDSCH) of the Pcell <NUM>, the terminal device <NUM> may transmit to the network device <NUM> uplink control information (UCI), such as hybrid automatic repeat request (HARQ) ACK/NACK. The PUCCH resources configured for the terminal device <NUM> to transmit the UCI may be more than that required by the UCI. Therefore, the remaining resources of the PUCCH may be utilized by the terminal device <NUM> to transmit the beam failure recovery request, i.e. to pad the beam failure recovery request in PUCCH.

<FIG> illustrates a flowchart of an example method <NUM> for beam failure recovery for a Scell in accordance with some embodiments of the present disclosure. The method <NUM> can be implemented at the terminal device <NUM> shown in <FIG>. For the purpose of discussion, the method <NUM> will be described with reference to <FIG> and <FIG>.

At <NUM>, the terminal device <NUM> determines whether there is a beam failure on a Scell. If the terminal device <NUM> determines a beam failure on the Scell <NUM>, the terminal device <NUM> at <NUM> determines an uplink control channel of a Pcell to be used, based on resources of the uplink control channel and uplink control information to be transmitted on the uplink control channel. The terminal deice <NUM> may determine a PUCCH of the Pcell <NUM> to be used.

Refer to <FIG>, which are schematic diagrams illustrating padding beam failure request in a PUCCH according to some embodiments of the present disclosure. Diagrams <NUM> and <NUM> show a long-PUCCH (L-PUCCH) <NUM> and a short-PUCCH (S-PUCCH) <NUM>. As an example, the terminal device <NUM> may determine to use the L-PUCCH <NUM> to pad the beam failure recovery request. For example, a first potion <NUM> of the L-PUCCH <NUM> may be used to transmit the UCI and a second portion of the L-PUCCH <NUM> may be used to transmit the beam failure recovery request.

In some embodiments, the terminal device <NUM> may determine the PUCCH to be used based on the remaining resource blocks. The terminal device <NUM> may first determine a first number of physical resource blocks (PRBs) that are allocated to the uplink control channel. For example, the terminal device <NUM> may determine the number of PRBs allocated to the L-PUCCH <NUM> to be <MAT>. The terminal device <NUM> may then determine a second number of PRBs to be used by the UCI. For example, the terminal device <NUM> may determine, based on information included in the UCI, the number of PRBs to be used by the UCI as <MAT>. That is, the number of PRBs corresponding to the first portion <NUM> is <MAT>. Then, a third number Mr of PRBs that can be used to transmit the beam failure recovery request is determined by the following equation: <MAT>.

Mr represents the number of PRBs corresponding to the second portion <NUM>. If Mr is determined to be equal to or greater than a threshold number, the terminal device <NUM> may determine the L-PUCCH <NUM> as a channel to transmit the beam failure recovery request. The threshold number may be predetermined based on the size of the beam failure recovery request.

It is to be understood that other information such as CSI report may also be transmitted in the uplink control channel. In this event, the PRBs occupied by the other information should be considered into the determined <MAT>. Diagram <NUM> shows a S-PUCCH <NUM> along with its first portion <NUM> and second portion <NUM>. The terminal device <NUM> may determine to use the second portion <NUM> to transmit the beam failure recovery request in a similar manner described with respect to the L-PUCCH <NUM>.

Still referring to <FIG>, at <NUM>, the terminal device <NUM> transmits, to a network device and on the uplink control channel, a beam failure recovery request along with the uplink control information. The terminal device <NUM> may transmit, to the network device <NUM>, the beam failure recovery request in the second portion <NUM> or <NUM> and the UCI in the first portion <NUM> or <NUM>. The beam failure recovery request comprises a Scell index of the Scell <NUM> and a beam index of a beam selected from available beams on the Scell <NUM> by the terminal device <NUM>. The beam failure recovery request is transmitted to recover communication between the terminal device <NUM> and the network device <NUM> via the selected beam <NUM> on the Scell <NUM>.

In some embodiments, after transmitting the beam failure recovery request on the uplink control channel, the terminal device <NUM> may initiate a timer for monitoring a response to the beam failure recovery request, i.e., start a BFR-RA-window. If the timer has expired or the BFR-RA-window ends but no response to the beam failure request has been received, the terminal device <NUM> may retransmit the beam failure recovery request to the network device <NUM>.

In some embodiments, the terminal device <NUM> may receive from the network device <NUM> a new data transmission associated with the same HARQ ID as the ACK/NACK transmitted at <NUM>. In this case, the beam failure recovery request may be considered to have been received by the network device <NUM>. Thus, the terminal device <NUM> may end up the BFR-RA-window, resulting in a reduced BFR-RA-window.

In the embodiments described with respect to <FIG>, the beam failure recovery procedure may utilize the remaining resources of a PUCCH which otherwise would be wasted. In this way, the transmission of the beam failure request may not require dedicated resources. Thus, the overhead for the beam failure recovery can be further reduced while improving the efficiency of the beam failure recovery.

<FIG> illustrate example methods for according to some embodiments of the present disclosure implemented at a network device. It is to be understood that the methods shown may include additional acts not shown and/or may omit some shown acts, and the scope of the present disclosure is not limited in this regard.

<FIG> illustrates a flowchart of an example method <NUM> for beam failure recovery for a Scell in accordance with some embodiments of the present disclosure. The method <NUM> can be implemented at the network device <NUM> shown in <FIG>. For the purpose of discussion, the method <NUM> will be described with reference to <FIG>.

At <NUM>, the network device <NUM> receives a scheduling request from a terminal device, e.g. the terminal device <NUM>. As described with respect to <FIG>, the scheduling request may be a PRACH transmission received on the Pcell <NUM> or Scell <NUM>. Alternatively, the scheduling request may be a scheduling request received on a PUCCH of the Pcell <NUM>.

At <NUM>, the network device <NUM> transmits, to the terminal device and on a primary cell (e.g. the Pcell <NUM>), a response indicating a resource allocated to the terminal device <NUM>. The response may comprise downlink control information indicating a UL grant. Depending on the type of the scheduling request transmitted at <NUM>, the downlink control information may be scrambled by different types of RNTI, such as RA-RNTI determined by a PRACH transmission occasion or C-RNTI allocated to the terminal device. The embodiments where different types of response are transmitted will be described below with respect to <FIG>.

At <NUM>, the network device <NUM> receive, from the terminal device <NUM> and using the allocated resource, a beam failure recovery request comprising a beam index of a beam selected from available beams on a Scell by the terminal device <NUM>, to communicate with the terminal device <NUM> via the selected beam <NUM> on the Scell <NUM>. For example, the Scell index and the beam index may be included in MAC CE received using the allocated resources, e.g. PUSCH.

After receiving the beam failure recovery request, the network device <NUM> may use the selected beam <NUM> rather than the previous beam <NUM> to communicate with the terminal device <NUM> on the Scell <NUM>.

In some embodiments, the network device <NUM> may transmit, to the terminal device <NUM>, a further response to the beam failure recovery request on the Scell <NUM>. For example, the network device <NUM> may transmit the response via the selected beam <NUM>.

At <NUM>, the network device <NUM> receives a PRACH preamble in a dedicated PRACH transmission on Pcell from a terminal device, for example the terminal device <NUM>. The PRACH preamble index indicates a Scell index of a Scell (e.g. Scell <NUM>) serving the terminal device <NUM>.

At <NUM>, the network device <NUM> determines the Scell <NUM> from the PRACH preamble. For example, the network device <NUM> may determine the Scell <NUM> based on a predefined mapping relation between the PRACH preambles and the at least one Scell provided by the network device <NUM> to the terminal device <NUM>.

At <NUM>, the network device <NUM> transmits, to the terminal device <NUM> and on a Pcell serving the terminal device <NUM>, downlink control information including a request for CSI reporting for the Scell <NUM>. The downlink control information may be scrambled with C-RNTI corresponding to the terminal device.

At <NUM>, the network device <NUM> receives, from the terminal device <NUM>, a beam index of a beam selected from available beams on the Scell <NUM> by the terminal device <NUM>. The beam index of the selected beam <NUM> may be included in a CSI report which is received on the PUSCH of the Pcell <NUM>.

In such embodiments, the Scell index of the Scell on which a beam failure has occurred is implicitly included in the PRACH preamble. Thus, after receiving the beam index of the selected beam <NUM>, the network device <NUM> may use the selected beam <NUM> to communicate with the terminal device <NUM> on the Scell <NUM> determined at <NUM>.

At <NUM>, the network device <NUM> receives a dedicated PRACH transmission from a terminal device and on a Scell serving the terminal device. For example, the network device <NUM> may receive the PRACH preamble on the Scell <NUM> serving the terminal device <NUM>. The PRACH preamble index indicates a beam index of a beam selected from available beams on the Scell by the terminal device <NUM>.

At <NUM>, the network device <NUM> determines the beam index from the PRACH preamble received at <NUM>. For example, the network device <NUM> may determine the beam index based on a predefined mapping relation between the PRACH preambles and a plurality of beams associate with the Scell <NUM>.

In such embodiments since the PRACH preamble is received on the Scell <NUM>, the network device <NUM> may determine that a beam failure has occurred on this Scell without dedicated information on the Scell index. After determining the candidate beam (e.g. the selected beam <NUM>) selected by the terminal device <NUM>, the network device may communicate with the terminal device <NUM> via the selected beam <NUM> on the Scell <NUM>. In some embodiments, the network device <NUM> may transmit a beam failure recovery response to the terminal device <NUM> via the selected beam <NUM>.

As described with respect to <FIG>, the beam failure recovery request may be padded in a PUCCH of a Pcell. <FIG> illustrates a flowchart of an example method <NUM> for beam failure recovery for a Scell in accordance with some embodiments of the present disclosure. The method <NUM> can be implemented at the network device <NUM> shown in <FIG>. For the purpose of discussion, the method <NUM> will be described with reference to <FIG> and <FIG>.

At <NUM>, the network device <NUM> receives, from a terminal device and on an uplink control channel of a Pcell serving the terminal device, a beam failure recovery request along with uplink control information. For example, the network device <NUM> may receive the L-PUCCH <NUM> shown in <FIG> from the terminal device <NUM>. The UCI may be included in the first portion <NUM> and the beam failure recovery request may be included in the second portion <NUM>. The UCI may be associated with data previously transmitted to the terminal device <NUM>. For example, the UCI may include HARQ ACK/NACK information.

At <NUM>, the network device <NUM> obtains, from the beam failure recovery request, a Scell index of a Scell serving the terminal device and a beam index of a beam selected from available beams on the Scell by the terminal device. The network device <NUM> may obtain the Scell index of the Scell <NUM> and the beam index of the selected beam <NUM>. Thus, the network device <NUM> may determine that a beam failure has occurred on the Scell <NUM> and a new beam has been selected by the terminal deivce <NUM>. Then, the network device <NUM> may communicate with the terminal device <NUM> via the selected beam <NUM> on the Scell <NUM>.

As mentioned above, the scheduling request may be a PRACH preamble on the Pcell or Scell, or it may be a scheduling request on PUCCH. <FIG> are flowcharts illustrating processes for beam failure recovery for a Scell according to some embodiments of the present disclosure. The processes described with respect to <FIG> may be considered as implementations of the methods descried with respect to <FIG> and <FIG>.

<FIG> is a flowchart illustrating process <NUM> for beam failure recovery for a Scell according to some embodiments of the present disclosure. For the purpose of discussion, the process <NUM> will be described with reference to <FIG>. The process <NUM> may involve the network device <NUM> and the terminal device <NUM> in <FIG>.

After detecting a beam failure on the Scell <NUM> and identifying the selected beam <NUM>, the terminal device may initiate a beam failure recovery procedure. In this implementation, the beam failure recovery procedure may be a normal random access procedure. The terminal device <NUM> transmits <NUM> a random access preamble on the Pcell <NUM> to the network device <NUM>.

Once receiving the random access preamble, the network device <NUM> transmits <NUM> a random access response (RAR) to the terminal device <NUM> on the Pcell <NUM>. The RAR may be scrambled with RA-RNTI and include downlink control information with UL grant to allocate uplink resources for the terminal device <NUM>.

After receiving the RAR, the terminal device <NUM> transmits <NUM> MAC CE to the network device <NUM> and using the allocated resources (e.g. on PUSCH). The MAC CE may include the Scell index of the Scell <NUM> and the beam index of the selected beam <NUM>. If the MAC CE is successfully received, the network device <NUM> transmits <NUM> a beam failure recovery request response to the terminal device <NUM>.

After detecting a beam failure on the Scell <NUM> and identifying the selected beam <NUM>, the terminal device may initiate a beam failure recovery procedure. In this implementation, the beam failure recovery procedure may be a normal random access procedure. The terminal device <NUM> transmits <NUM> a random access preamble on the Scell <NUM> to the network device <NUM>.

After receiving the RAR, the terminal device <NUM> transmits <NUM> MAC CE to the network device <NUM> and using the allocated resources (e.g. on PUSCH). In this case, the MAC CE may include the beam index of the selected beam <NUM> and the Scell index of the Scell <NUM> may be omitted. If the MAC CE is successfully received, the network device <NUM> transmits <NUM> a beam failure recovery request response to the terminal device <NUM>.

After detecting a beam failure on the Scell <NUM> and identifying the selected beam <NUM>, the terminal device may initiate a beam failure recovery procedure. In this implementation, the terminal device <NUM> may initiate an explicit procedure for triggering a UL grant to transmit the beam failure recovery request. The terminal device <NUM> transmits <NUM>, to the network device <NUM>, a scheduling request (SR) on an uplink control channel of the Pcell <NUM>. The terminal device <NUM> may transmit the SR on the PUCCH of the Pcell <NUM>.

Once receiving the SR, the network device <NUM> transmits <NUM>, to the terminal device <NUM> on the Pcell <NUM>, a response to the SR. The response to the SR may be scrambled with C-RNTI allocated to the terminal device and include downlink control information with UL grant to allocate uplink resources for the terminal device <NUM>.

After receiving the response to the SR, the terminal device <NUM> transmits <NUM> MAC CE to the network device <NUM> and using the allocated resources (e.g. on PUSCH). The MAC CE may include the Scell index of the Scell <NUM> and the beam index of the selected beam <NUM>. If the MAC CE is successfully received, the network device <NUM> transmits <NUM> a beam failure recovery request response to the terminal device <NUM>.

<FIG> is a schematic diagram <NUM> illustrating a BFR-RA window for beam failure recovery according to some embodiments of the present disclosure. In some embodiments, after transmitting <NUM> the MAC CE on the Pcell <NUM> to the network device <NUM>, the terminal device <NUM> may initiate <NUM> a timer for monitoring a response to the beam failure recovery request (also referred to as BFR response). That is, the terminal device <NUM> may start the BFR-RA-window <NUM>. It is to be understood that the action of transmitting <NUM> the MAC CE may refer to the actions described above with respect to <NUM> shown in <FIG>, <NUM> shown in <FIG>and <NUM> shown in <FIG>.

In some embodiments, the terminal device <NUM> may receive <NUM> the BFR response on the Scell <NUM> (or on the Pcell), which implies the beam failure is successfully recovered. The terminal device <NUM> may terminate the beam failure recovery procedure and may end up the BFR-RA-window <NUM>.

In some embodiments, the terminal device <NUM> may receive <NUM> from the network device <NUM> downlink control information on rescheduling PUSCH containing the MAC CE, i.e. reschedule of the beam failure recovery request. Then, the terminal device <NUM> may retransmit <NUM> the beam failure recovery request in the MAC CE on PUSCH to the network device <NUM>. Following the retransmission, the terminal device <NUM> may initiate <NUM> the timer. Thus, a new BFR-RA-window <NUM> may be started. Note that with the starting of the new BFR-RA-window <NUM>, the BFR-RA-window <NUM> may be discarded.

If the BFR-RA-window <NUM> or <NUM> (depending on which one is valid) has expired or ends, but no BFR response has been received, then the terminal device <NUM> may terminate the beam failure recovery procedure without retransmitting the beam failure recovery request. The terminal device <NUM> may further indicate to higher layer of an unsuccessful beam failure recovery.

In such cases, there is no need to retransmit the beam failure recovery request for the following reasons. The network device <NUM> may has received the beam failure recovery request but does not respond to it. The network device <NUM> may have responded on the Scell but the selected beam <NUM> is not good enough such that the terminal device <NUM> cannot receive the BFR response. There also may be another situation where the MAC CE including the beam failure recovery request is not received by the network device <NUM>.

As mentioned above, the scheduling request may be transmitted with a dedicated PRACH preamble. <FIG> are flowcharts illustrating processes for beam failure recovery for a Scell according to some embodiments of the present disclosure.

<FIG> is a flowchart illustrating process <NUM> for beam failure recovery for a Scell according to some embodiments of the present disclosure. For the purpose of discussion, the process <NUM> will be described with reference to <FIG>. The process <NUM> may involve the network device <NUM> and the terminal device <NUM> in <FIG>. The process <NUM> may refer to an implementation of the methods described with respect to <FIG> and <FIG>.

After detecting a beam failure on the Scell <NUM> and identifying the selected beam <NUM>, the terminal device may initiate a beam failure recovery procedure. In this implementation, the beam failure recovery procedure may be a dedicated random access procedure. The terminal device <NUM> transmits <NUM> a random access preamble on the Pcell <NUM> to the network device <NUM>. The random access preamble index indicates a Scell index of the Scell <NUM>. For example, the random access preamble may be determined by the terminal device <NUM> based on a predefined mapping relation between the random access preambles and the at least one Scell provided by the network device <NUM>.

Once receiving the random access preamble, the network device <NUM> transmits <NUM> a response to the terminal device <NUM> on the Pcell <NUM>. Unlike the normal RAR, this response may be scrambled with C-RNTI on a dedicated coreset, and may include downlink control information with request for CSI report for the Scell <NUM>. For example, this response may include CSI request for the Scell <NUM>.

After receiving the response, the terminal device <NUM> transmits <NUM> a CSI report to the network device <NUM> and using the allocated resources on PUSCH depending on the CSI request. The CSI report may include the beam index of the selected beam <NUM>. Note that the Scell index of the Scell <NUM> may be optional, since the index on the Scell has been indicated by the random access preamble.

In some embodiments, if the CSI report is successfully received, the network device <NUM> transmits <NUM> a beam failure recovery response to the terminal device <NUM>.

After detecting a beam failure on the Scell <NUM> and identifying the selected beam <NUM>, the terminal device may initiate a beam failure recovery procedure. In this implementation, the beam failure recovery procedure may be another dedicated random access procedure. The terminal device <NUM> transmits <NUM> a random access preamble on the Scell <NUM> to the network device <NUM>.

This random access preamble indicates a beam index of a beam selected from available beams on the Scell <NUM> by the terminal device <NUM>. For example, random access preamble indicates the beam index of the selected beam <NUM>. The random access preamble may be determined by the terminal device <NUM> based on a predefined mapping relation between the random access preambles and a plurality of beams associate with the Scell <NUM>.

Once receiving the random access preamble, the network device <NUM> determines the Scell on which a beam failure has occurred and the candidate beam selected by the terminal device <NUM>. The network device <NUM> transmits <NUM> a BFR response to the terminal device <NUM>. In such embodiments, only two messages between the network device <NUM> and the terminal device <NUM> are required in the beam failure recovery procedure. which can improve the efficiency of beam failure recovery.

<FIG> is a schematic diagram <NUM> illustrating a process <NUM> for beam failure recovery according to some embodiments of the present disclosure. For the purpose of discussion, the process <NUM> will be described with reference to <FIG> and <FIG>. The process <NUM> may involve the network device <NUM> and the terminal device <NUM> in <FIG>. The process <NUM> may refer to an implementation of the methods described with respect to <FIG> and <FIG>.

The network device <NUM> transmits <NUM> downlink control information to the terminal device <NUM> and transmits <NUM> data on a PDSCH of the Pcell <NUM>. At certain time, a beam failure <NUM> may occur on the Scell <NUM>. After detecting the beam failure <NUM> on the Scell <NUM> and identifying the selected beam <NUM>, the terminal device need to transmit a beam failure recovery request including the Scell index of the Scell <NUM> and the beam index of the selected beam <NUM> to the network device <NUM>. Meanwhile, the terminal device <NUM> also needs to transmit UCI to the network device <NUM>. As described above, the terminal device <NUM> may include the beam failure recovery request along with the UCI in the PUCCH (such as the long PUCCH "L-PUCCH" or short PUCCH "S-PUCCH" as shown in <FIG>) allocated to transmitted the UCI. The UCI may include HARQ ACK/NACK related to the data transmitted at <NUM>. Then, the terminal device <NUM> transmits <NUM> the beam failure recovery request along with the UCI on the PUCCH of the Pcell <NUM>.

In some embodiments, after transmitting <NUM> the PUCCH, the terminal device <NUM> may initiate <NUM> a timer for monitoring a response to the beam failure recovery request (also referred to as BFR response). That is, the terminal device <NUM> may start the BFR-RA-window <NUM>.

If the BFR-RA-window <NUM> has expired or ends, but no BFR response has been received, then the terminal device <NUM> may retransmit the beam failure recovery request to the network device <NUM>. Unlike the implementations described above with respect to <FIG>, retransmission of the beam failure recovery request is required when the BFR-RA-window has expired.

In some embodiments, the terminal device <NUM> may receive <NUM> new data from the network device <NUM>. The new data may be associated with the same HARQ ID as the HARQ ACK/NACK transmitted at <NUM>. In this event, the beam failure recovery request may be considered to have been successfully received by the network device <NUM>. Thus, the terminal device <NUM> may terminate the BFR-RA-window <NUM>, resulting in a reduced BFR-RA-window <NUM>.

<FIG> is a simplified block diagram of a device <NUM> that is suitable for implementing embodiments of the present disclosure. The device <NUM> can be considered as a further example implementation of a network device <NUM> or a terminal device <NUM> as shown in <FIG>. Accordingly, the device <NUM> can be implemented at or as at least a part of the network device <NUM> or the terminal device <NUM>.

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

The program <NUM> is assumed to include program instructions that, when executed by the associated processor <NUM>, enable the device <NUM> to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to <FIG> and <FIG>. The embodiments herein may be implemented by computer software executable by the processor <NUM> of the device <NUM>, or by hardware, or by a combination of software and hardware. The processor <NUM> may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor <NUM> and memory <NUM> may form processing means <NUM> adapted to implement various embodiments of the present disclosure.

The memory <NUM> may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory <NUM> is shown in the device <NUM>, there may be several physically distinct memory modules in the device <NUM>. The processor <NUM> may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.

While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above with reference to any of <FIG> and <FIG>. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

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

Claim 1:
A method implemented in a terminal device (<NUM>), comprising:
in response to a beam failure on a secondary cell, Scell, transmitting a scheduling request to a network device (<NUM>);
receiving, from the network device (<NUM>) and on a primary cell, Pcell, a response indicating a resource allocated to the terminal device (<NUM>);
transmitting, to the network device (<NUM>) and using the allocated resource, a beam failure recovery request comprising a beam index of a beam selected from available beams on the Scell by the terminal device (<NUM>), to recover communication between the terminal device (<NUM>) and the network device (<NUM>) via the selected beam on the Scell, wherein:
transmitting the scheduling request comprises transmitting a random access preamble on the Pcell, receiving the response comprises receiving downlink control information with an uplink grant, and transmitting the beam failure recovery request comprises transmitting reference signal, RS, ID corresponding to the beam index, and a Scell index of the Scell, in media access control, MAC, control element, CE; or
transmitting the scheduling request comprises transmitting a random access preamble on the Scell, receiving the response comprises receiving downlink control information with an uplink grant, and transmitting the beam failure recovery request comprises transmitting reference signal, RS, ID corresponding to the beam index, in media access control, MAC, control element, CE; or
transmitting the scheduling request comprises transmitting the scheduling request on an uplink control channel of the Pcell, receiving the response comprises receiving downlink control information with an uplink grant, and transmitting the beam failure recovery request comprises transmitting reference signal, RS, ID corresponding to the beam index, and a Scell index of the Scell, in media access control, MAC, control element, CE; and
in response to receiving from the network device (<NUM>) downlink control information on reschedule of the beam failure recovery request, retransmitting the beam failure recovery request to the network device (<NUM>); and
initiating a timer for monitoring a response to the beam failure recovery request.