CN112616159A - Method for recovering beam fault of secondary cell - Google Patents

Abstract

The apparatus detects a beam failure of a serving cell. In response, the device triggers a beam failure recovery request (BFRQ). The BFRQ remains pending until cancelled. In triggering the BFRQ, the apparatus generates a BFRQ Medium Access Control (MAC) Control Element (CE) and transmits the MAC CE of the BFR to the wireless network using resources granted under an Uplink (UL). The invention can quickly report the occurrence of the beam fault through the device, thereby realizing the beneficial effects of improving the reliability of the beam and reducing the interference time to the communication when the beam fault occurs.

Description

Method for recovering beam fault of secondary cell

Cross-referencing

The present invention is part of a non-provisional application, claiming priority from the following: us provisional application No. 62/909,833 filed on 3.10.2019 and us non-provisional patent application No. 16/999,007 filed on 20.8.2020, which are all incorporated herein by reference.

Technical Field

The present invention relates generally to mobile communications, and more particularly, to a Beam Failure Recovery (BFR) procedure involving a secondary cell (SCell) in mobile communications.

Background

Unless otherwise indicated, the approaches described in this section are not prior art to the claims set forth below and are not admitted to be prior art by inclusion in this section.

Currently, it is agreed under the third Generation Partnership Project (3 GPP) that if a User Equipment (UE) detects a beam failure of an SCell, the UE may send a Scheduling Request (SR) indication to the network in step 1 of the recovery procedure to inform the network of such beam characteristics. In step 2 of the recovery procedure, the UE transmits a Medium Access Control (MAC) Control Element (CE) carrying beam failure information such as an Identification (ID) of a serving cell having a beam failure. The MAC CE may also include new beam information if the serving cell with the beam failure has a new candidate beam different from the failed serving beam and the power level is above a Reference Signal Received Power (RSRP) threshold.

However, the format of the MAC CE for BFR (or MAC CE called BFRQ) has not been determined. Furthermore, the triggering and cancellation conditions for beam failure recovery request (BFRQ) and SR-LIKE (SR-LIKE) indications have not been well defined. In addition, when a Physical Uplink Control Channel (PUCCH) for the SR-like indication overlaps with a PUCCH for a conventional SR, a Physical Random Access Channel (PRACH), or a Physical Uplink Shared Channel (PUSCH), a priority rule has not been clearly defined.

Disclosure of Invention

The following summary is illustrative only and is not intended to be in any way limiting. That is, the following summary is provided to introduce concepts, points, benefits and advantages of the novel and non-obvious techniques described herein. Selected embodiments are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

The present invention aims to propose solutions, concepts, designs, techniques, methods and means to address the aforementioned BFR procedures related to Scell in mobile communications. Under the scheme proposed by the present invention, some MAC CE formats for BFR are introduced, conditions for triggering and cancelling BFRQ and SR-like indication are proposed, and priority rules are proposed in case PUCCH for SR-like indication overlaps PUCCH for regular SR, PRACH or PUSCH.

In an aspect, a method may include a processor of an apparatus detecting a beam failure of a serving cell. The method also includes the processor triggering a BFRQ in response to the detecting. The BFRQ remains pending until cancelled. In triggering BFRQ, the method includes the processor generating a MAC CE for a BFR and transmitting the MAC CE for the BFR to a wireless network using resources according to an Uplink (UL) grant (grant).

In another aspect, a method may include a processor of an apparatus detecting a beam failure of a secondary cell. The method also includes the processor triggering a BFRQ in response to the detecting. The BFRQ remains pending until cancelled.

The invention provides a method for recovering the beam fault, which realizes the beneficial effects of improving the reliability of the beam and reducing the interference time to communication when the beam fault occurs by rapidly reporting the occurrence of the beam fault.

It is noteworthy that although the description provided herein is in the context of networks and network topologies such as the fifth Generation (5th Generation, 5G) and New Radio (NR), the proposed concepts, schemes and any variants/derivations thereof may be implemented in, for or by any other type of Radio access technology, network and network topology, such as, but not limited to, Long Term Evolution (LTE), LTE-Advanced (LTE-Advanced Pro), Internet of Things (Internet of Things), narrowband Internet of Things (IoT), and Industrial Internet of Things (IIoT). Accordingly, the scope of the invention is not limited to the examples described herein.

Drawings

The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the invention and together with the description serve to explain the principles of the invention. It is to be understood that the figures are not necessarily to scale, some components shown may be shown to scale beyond what is shown in actual embodiments, in order to clearly illustrate the concepts of the invention.

FIG. 1 is a schematic diagram of an exemplary network environment in which various solutions and schemes are implemented in accordance with the present invention.

FIG. 2 is a schematic diagram of an example scenario according to an embodiment of the present invention.

FIG. 3 is a diagram of an example BFR process, according to an embodiment of the present invention.

FIG. 4 is a schematic diagram of an example scenario according to an embodiment of the present invention.

FIG. 5 is a schematic diagram of an example scenario according to an embodiment of the present invention.

FIG. 6 is a schematic diagram of an example scenario according to an embodiment of the present invention.

Fig. 7 is a block diagram of an example communication system according to an embodiment of the present invention.

FIG. 8 is a flow chart of an example flow according to an embodiment of the present invention.

FIG. 9 is a flow chart of an example flow according to an embodiment of the present invention.

Detailed Description

Detailed examples and embodiments of the claimed subject matter are disclosed herein. However, it is to be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matter that may be embodied in various forms. Furthermore, the present invention may be embodied in many different forms and should not be construed as being limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

SUMMARY

Embodiments according to the present invention relate to various techniques, methods, schemes and/or solutions relating to a BFR procedure of a Scell cell in mobile communication. Several possible solutions according to the invention can be implemented individually or jointly. That is, although these solutions are described separately below, two or more of these possible solutions may be implemented in one combination or another.

FIG. 1 illustrates an example network environment 100 in which various solutions and schemes are implemented in accordance with this invention. Fig. 2, 3, 4, 5, and 6 illustrate an example scenario 200, an example BFR process 300, and scenarios 200, 400, and 500, respectively, according to embodiments of the present invention. Each of scenario 200, process 300, and scenarios 300, 400, and 500 may be implemented in network environment 100. A description of various proposed schemes is provided with reference to fig. 1-6.

Referring to fig. 1, a network environment 100 may include a UE110 in wireless communication with a wireless network 120, such as a 5G NR mobile network. UE110 may wirelessly communicate with wireless network 120 via a primary cell (PCell) or a special cell (SCell) associated with a base station or network node 125 (e.g., an eNB, a gNB, or a Transmit Receive Point (TRP)) and an SCell, as well as with a base station or network node 130 (e.g., an eNB, a gNB, or a TRP). UE110 and wireless network 120 (e.g., via network node 125) may perform a BFR process for the SCell based on any of the proposed schemes according to the present invention described below.

FIG. 2 illustrates an example scenario 200 according to an embodiment of the present invention. Part (a) of fig. 2 shows an example of BFR of the SpCell. Part (B) of fig. 2 shows an example of BFR of the SCell. Referring to part (a) of fig. 2, when UE110 detects a BFR of the SpCell, UE110 may perform a Random Access Channel (RACH) procedure with wireless network 120. Referring to fig. 2 part (B), when UE110 detects a BFR of an SCell, action is taken depending on whether there are any UL resources (e.g., UL grants) available. In the event that UL resources are unavailable, UE110 may send an SR using the PUCCH to report the detected BFRs. In response, wireless network 120 may send a UL grant to UE 110. UE110 may transmit the MAC CE of the BFR to wireless network 120 if UL resources are available. In response, wireless network 120 may send a BFR response (BFRR) to UE 110. The BFRR may carry the UL grant in a hybrid automatic repeat request (HARQ) flow for new transmission, which is the same HARQ flow as the MAC CE that the UE previously used to transmit the BFR. The term "serving cell" herein refers to a PCell, a SCell, or an SCell (e.g., serving cell ═ SCell + SCell (PCell)). The term "SCell" (or "secondary cell") herein refers to one or more other serving cells other than the SCell (e.g., PCell).

With respect to beam failure detection of scells, UE110 may monitor a reference signal for a given SCell at the physical layer of the Open Systems Interconnection (OSI) model. In the event that the physical layer of UE110 detects that the RSRP of the reference signal is very low (e.g., below a threshold level), the physical layer may indicate a "beam failure instance indication" to the MAC layer of UE 110. The MAC layer may calculate the duration since the last time the beam failure instance indication was received from the physical layer. In addition, the MAC layer may increment a Beam Failure Indication (BFI) COUNTER (BFI _ COUNTER) by 1. When the BFI counter reaches a predetermined threshold, the MAC layer may consider that a beam failure of the serving cell is detected. In case the serving cell that detects the beam failure is an SCell, UE110 may trigger a BFR and perform a BFR procedure according to the present invention. In the case where the serving cell that detected the beam failure is the SpCell, UE110 may trigger the RACH procedure (e.g., by performing the legacy operations specified in release 15(Rel-15) of the 3GPP specifications). In the case where the MAC layer has not received any beam failure instance for the serving cell for a long time since the MAC layer last received the beam failure instance for the serving cell until the timer (e.g., beam failure detection timer) for the serving cell expires, the UE may consider the beam failure for the serving cell (e.g., because no consecutive beam failure instances are received from the physical layer) to have been resolved and the MAC layer may reset the BFI counter for the serving cell.

FIG. 3 illustrates an example BFR process 300 according to an embodiment of the present invention. Process 300 may be an example implementation of a BFR for an SCell shown in part (B) of fig. 2. The process 300 may include one or more operations, actions, or functions represented by one or more of block 310, block 320, block 330, block 340, block 350, block 360, block 370, and block 380. Although illustrated as discrete blocks in the process 300, the various blocks of the process 300 may be divided into more blocks, combined into fewer blocks, or portions removed, depending on the desired implementation. For simplicity and brevity, a description of process 300 is provided below in the context of network environment 100 from the perspective of UE 110. Process 300 may begin at block 310.

At block 310, process 300 may include UE110 detecting a beam failure of an SCell or SpCell (e.g., an SCell or SpCell associated with network node 130). From block 310, process 300 may proceed to block 320.

At block 320, process 300 may include UE110 triggering a BFRQ (which remains pending until cancelled) to notify wireless network 120 of the detected beam failure. From block 320, process 300 may proceed to block 330 or block 350, depending on whether certain conditions are satisfied.

At block 330, where a UL grant is available (e.g., previously configured by wireless network 120), process 300 may include UE110 generating a MAC CE of a BFR to be included in a MAC Protocol Data Unit (PDU) and transmitting the MAC PDU including the MAC CE of the BFR to wireless network 120 (e.g., via network node 125) in the UL grant (e.g., using resources configured so as to be in the UL grant). From block 330, process 300 may proceed to block 340.

At block 340, where beam information for the associated SCell (or SpCell) is already included in the MAC PDU and sent in the MAC PDU in the UL grant, process 300 may include UE110 cancelling the pending BFRQ and any SR-like indication associated with the SCell (or SpCell).

At block 350, process 300 may include UE110 immediately sending a SR-like indication to wireless network 120 for the BFRQ to be decided. Alternatively, process 300 may include UE110 sending a SR-like indication to wireless network 120 if one or more of certain conditions are met. These conditions may include, for example, but are not limited to: (1) no UL grant is available (e.g., no UL shared channel (UL-SCH) resources are available for new transmissions), (2) the latency caused by waiting for transmission on any available UL grant is too long (e.g., the UL-SCH available for new transmissions does not meet the latency requirements for SCell (or SpCell) BFRQ transmissions), and (3) the MAC CE for which the wireless network 120 does not force the UE110 to always transmit BFRs on a configured grant (e.g., the MAC entity is configured with one or more configured UL grants and the UE110 is not configured with a MAC CE that always transmits BFRs on a configured grant). Depending on whether there are any UL grants, process 300 may proceed from block 350 to block 360 or block 370. Further, the condition for the UE110 to transmit the SR-like indication may include: the UE has already scheduled the UL grant, but due to the Logical Channel Priority (LCP) procedure, the UL grant has insufficient space to include non-truncated (non-truncated) and truncated (truncated) BFR MAC CEs.

At block 360, where there is an available UL grant, process 300 may include UE110 sending a MAC CE of a BFR to wireless network 120 using the available UL grant. From block 360, process 300 may proceed to block 340.

At block 370, in the absence of an available UL grant before detecting the SR failure, the process 300 may include the UE110 triggering a contention-based random access (CBRA) process in the SpCell. The process 300 may also include the UE110 cancelling all pending SRs (in addition to the pending SR-like indication described above). From block 370, process 300 may proceed to block 380.

At block 380, process 300 may include UE110 sending message 3 to wireless network 120 at a CBRA process (Msg3), where Msg3 includes the MAC CE of the BFR. From block 380, process 300 may proceed to block 340.

As described below, various aspects presented herein may be used to implement the BFR process 300.

Under the proposed scheme according to the present invention, a PUCCH resource configured for a SCell BFR (or SpCell BFR) may be used to transmit a SR-like indication for the SCell BFR. Under the proposed scheme, PUCCH may be configured according to SR configuration dedicated to SCell BFR (or SpCell BFR). SR configurations may include, for example, but are not limited to, SR-ProhibitTimer, SR-TransMax, and SR _ COUNTER.

With the proposed scheme according to the present invention, beam failure information may be enumerated for each SCell with beam failure one by one, with respect to the format of MAC CE of BFR. Fig. 4 illustrates an example scenario 400 according to an embodiment of the present invention for the MAC CE format of a BFR. Referring to fig. 4, which illustrates a first option of an example MAC CE format, an F field may be used to indicate whether new beam information (e.g., information of one or more eligible new beams) for a serving cell identified by a serving cell ID is provided. Under the proposed scheme, MAC CE truncation of BFRs may be supported. For example, there may be two Logical Channel Identities (LCIDs) to distinguish MAC CEs of truncated BFRs from MAC CEs of non-truncated BFRs. There may be an indication in the LCID/MAC subheader/MAC payload to indicate to the network (e.g., wireless network 120) how many serving cells should be reported, based on which the network may determine whether there is truncation. Under the proposed scheme, it can be inferred from the MAC CE of truncated BFRs that some beam failure information may not be provided (e.g., due to the limitation on UL grant size). For example, the serving cell ID and the new beam information of the serving cell may not be provided at all. As another example, for a serving cell with a beam failure, a serving cell ID may be provided, but there may be no room to report new beam information (e.g., the F field is set to "1," but no new beam information is included).

Under the proposed scheme according to the present invention, regarding the MAC CE format of the BFR, two bitmaps (bitmaps) may be used to indicate the following information, respectively: (i) whether a SCell has beam failure, and (ii) whether to provide beam information for the SCell with beam failure. Fig. 5 illustrates an example scenario 500 of a MAC CE format of a BFR in accordance with an embodiment of the present invention. Referring to fig. 5, a second option of an example MAC CE format is shown, C_iThe field may be used to indicate whether a serving cell with a serving cell index (ServCellIndex) i has a beam failure, and F_iThe field may be used to indicate whether a new beam for a serving cell with ServCellIndex i is provided. Alternatively, F_iThe field may be used to indicate whether the ith serving cell with beam failure reported has new beam information. Therefore, when C_iWhen the value of (A) is 1, F_iWill be feasible (viable). Under the proposed scheme, for C_iAnd F_iThe number of bytes in may depend on the actual implementation. For example, in a Power Headroom Report (PHR) format, if the highest ServCellIndex of a serving cell in which an uplink is configured is less than 8, a one-byte bitmap is sufficient. Under the proposed scheme, truncation of MAC CE for BFR may be supported. For example, there may be two separate LCIDs to distinguish MAC CEs of truncated BFRs from MAC CEs of non-truncated BFRs. Under the proposed scheme, it may be inferred from the MAC CE of the truncated BFR that one or more pieces of information related to the detected beam failure are omitted (e.g., due to limitations of UL grant size). For example, may not be everyServing cell provides full C_iA bitmap. Alternatively, complete C may be included_iBitmap, but may not include complete F_iA bitmap. Alternatively, complete C may be included_iBitmap and F_iA bitmap in which a portion (but not all) of the new beam information is included in the same MAC PDU.

Under the proposed scheme according to the present invention, regarding the MAC CE format for BFR, a failed serving cell with new beam information and a failed serving cell without new beam information may be indicated with a separate LCID or flag (flag) in a header or payload, respectively. Fig. 6 illustrates an example scenario 600 in accordance with an embodiment of the present invention for the MAC CE format of a BFR. Referring to fig. 6, a third option of an example MAC CE format is shown. Specifically, part (a) of fig. 6 shows an example format indicating a serving cell without new beam information, and part (B) of fig. 6 shows an example format indicating a serving cell with new beam information. Referring to fig. 6, the R field may be a reserved bit set to 0. When used as a flag, the value of the R field may be set to 0 or 1. When set to 1, the MAC CE may indicate the failed serving cell and the eligible new beam information. When set to 0, the MAC CE may indicate a failed serving cell without any qualified new beam information. Referring to FIG. 6, C may be utilized_iA field to indicate whether a serving cell with ServCellIndex i has a beam failure. In case of indicating the MAC CE as including new beam information, C may be in the MAC CE format_iThe fields are followed by providing new beam information in an order, where the order corresponds to having a corresponding C_iSet to the serving cell of 1. Under the proposed scheme, truncation of MAC CE for BFR may be supported. For example, there may be two separate LCIDs to distinguish MAC CEs of truncated BFRs from MAC CEs of non-truncated BFRs. Under the proposed scheme, some non-provided beam failure information (e.g., due to restrictions on UL grant size) may be inferred from the MAC CE of truncated BFRs. For example, a complete C may not be provided for each serving cell_iA bitmap. Alternatively, complete C may be included_iBit map, and newA portion (but not all) of the beam information is included in the same MAC PDU.

Under the proposed scheme according to the present invention, a fourth option of the example MAC CE format may include a MAC CE format of a short BFR. Under the proposed scheme, the short format may enable the UE110 to report limited information with only a few bytes due to the MAC PDU size limitation. The term "short" in this context may refer to a situation where one serving cell (and no more) fails. The term "short truncation" herein may refer to a situation where more than one serving cell of UE110 fails but only one serving cell is reported. Under the proposed scheme, the UE110 may include beam failure information of only one serving cell in the MAC CE of the BFR. Under the first approach, UE110 may always report only the serving cell ID even if there is a qualified new beam that may be reported for the serving cell. A bit flag may be included in the payload to indicate whether there is new beam information that is not reported. Under a second approach, in the first subformat (subformat 1), UE110 may report only the serving cell ID if the serving cell has no eligible new beams to report. Alternatively, in the second subformat (subformat 2), in case the serving cell has a qualified new beam to report, the UE110 may report the serving cell ID as well as the new beam information. To distinguish between these two subformats, a number of options may be considered, including: (a) using a separate LCID, (b) using a flag in the payload, (c) using one bit to indicate in the MAC subheader (e.g., R/F/LCID/F format), and (d) using an L value to indicate the size (e.g., subformat 1 in the case of two bytes; subformat 2 in the case of three bytes). The short format may include the number of failed scells or the number of failed scells that have not yet been reported.

Under the proposed scheme, a bitmap may be included to indicate a failed SCell (without any other information). The number of bytes of the bitmap may depend on the highest ID of the activated SCell, and thus the size of the bitmap is known by the network (e.g., wireless network 120). In the case where the MAC PDU is of sufficient size to include the entire bitmap plus one extra byte, the MAC CE may include one byte of the MAC subheader (e.g., R/LCID) plus the bitmap. Otherwise, the MAC CE may include a two-byte MAC subheader (e.g., R/R/LCID/L) and a partial bitmap. Separate LCIDs may be used to distinguish between the two short formats. The LCID field is a field in the MAC subheader indicating the purpose of a MAC CE or MAC Service Data Unit (SDU) payload. Thus, the LCID field may be used to indicate that the MAC CE is a BFR's MAC CE.

With the proposed scheme according to the present invention, regarding the indication of SpCell BFR, the MAC CE of BFR may be designed to support the indication of SpCell BFR. For example, in the case where UE110 triggers CBRA due to SpCell BFR, and in the case where there is an SCell failure during a RACH procedure, UE110 may use the MAC CE of the BFR to indicate both SCell BFR and SpCell BFR. Similarly, in the case where the SCell BFR triggers CBRA, and in the case where a beam failure is detected in the SpCell during a RACH procedure, UE110 may indicate the SpCell BFR using the MAC CE of the BFR. Under the proposed scheme, in the MAC CE of BFR, UE110 may indicate a beam failure of SpCell by indicating a serving cell index of SpCell (e.g., cell ID ═ 00000), or UE110 may set a bitmap of ID 0 to 1 to inform wireless network 120 of SpCell beam failure (e.g., C of cell ID 0 is not set up)_iSet to R, reserved bit).

Under the proposed scheme according to the present invention, one of a plurality of options may be employed with respect to the priority of the BFR MAC CE. For example, under the first option (option 1), the priority of the MAC CE of the BFR may be placed under a cell radio network temporary identifier (C-RNTI) MAC CE or data from an uplink common control channel (UL-CCCH) and above a configuration grant confirmation MAC CE. Under the second option (option 2), the priority of the MAC CE of the BFR may be placed below the configuration permission confirmation MAC CE and above the MAC CE of the Buffer Status Report (BSR), but in addition to the BSR for padding. Under a third option (option 3), the MAC CE of a BFR may be prioritized at the same level as C-RNTI MAC CE or data from the UL-CCCH. Notably, since the MAC CEs of BFRs may have several formats (e.g., distinguished by LCID, truncated and non-truncated, or short and long formats), the MAC CEs of different formats of BFRs may have the same priority or different priorities.

Under the proposed scheme according to the present invention, wireless network 120 may configure UE110 with configuration permission (e.g., type 1 or type 2) with a MAC CE dedicated to transmit BFRs, with respect to dedicated resources for BFRQ transmission. Under the proposed scheme, wireless network 120 may configure a resource pool dedicated to BFRQ transmission via a two-step RACH. For example, message A (MsgA) in the two-step RACH may include MAC CEs for C-RNTI MAC CE and BFRs.

Under the proposed scheme according to the present invention, regarding the triggering of BFRQ, when a beam failure of an SCell is detected, the BFRQ of a given SCell with beam failure may be triggered. Furthermore, once the BFRQ of a given SCell triggers, the triggered BFRQ may remain pending (pending) until cancelled. According to the proposed scheme, one of a plurality of options can be employed with respect to cancelling the pending BFRQ. For example, under the first option (option 1), the pending BFRQ may be cancelled when beam information of all serving cells having beam failure associated with the pending BFRQ is included in a MAC PDU already transmitted to the network (e.g., wireless network 120). In the second option (option 2), the pending BFRQ may be cancelled if: (1) beam information for all serving cells with beam failure associated with the BFRQ to be decided is sent in the MAC PDU; (2) UE110 receives a HARQ Acknowledgement (ACK) from wireless network 120 or receives a new UL grant in the same HARQ process of the same serving cell as the previously transmitted MAC PDU including the MAC CE of the BFR. For example, after transmission of a MAC PDU of a MAC CE including a BFR associated with the BFRQ to be decided, the BFRQ to be decided may still be decided (i.e., not cancelled), but may be suspended (suspended). A new timer may be introduced. A new timer may be started when the MAC CE of the BFR is transmitted. During the timer run, UE110 may not send more MAC CEs for BFRs associated with the same serving cell with the beam failure. If UE110 receives a HARQ ACK or a new UL grant from wireless network 120 on the same HARQ flow of the same serving cell before the timer expires, the timer may be stopped and the pending BFRQ may be cancelled, wherein the beam failure information for the associated SCell with beam failure of the pending BFRQ is included in the MAC PDU. Conversely, if a HARQ ACK or a new UL grant is not received by UE110 on the same HARQ flow of the same serving cell before the timer expires, UE110 may continue with the BFRQ to be decided (e.g., by continuing to transmit the MAC CE of the BFR). In another example, the pending BFRQ may be cancelled or a new timer started after the transmission of the MAC PDU of the MAC CE including the BFR associated with the pending BFRQ. If there is no NAC response at the timer expiration (e.g., a HARQ ACK or UL grant is received on the same HARQ flow), UE110 may re-trigger the BFRQ of the serving cell for which beam failure information is sent without a response from the network.

With the proposed scheme for triggering class SR indication according to the present invention, when a BFRQ triggers, the UE110 may trigger class SR indication for the SCell BFR if one or more of a number of conditions have been met. Such conditions may include, for example, but are not limited to: (1) no UL-SCH resources available for new transmissions; (2) the MAC entity is configured with a configuration UL grant, and UE110 is configured to always transmit the MAC CE of the BFR with the configuration grant, and (3) the UL-SCH resources available for new transmission do not meet the requirements of SCell BFRQ transmission. The configuration UL grant may be a generally configured grant for transmitting data or, alternatively, a configuration grant dedicated to BFRQ transmission. The requirement for SCell BFR transmission may be one or more of: (1) the latency requirement, which may be defined as the PUSCH duration of the UL grant, the duration of the period from the receipt of the PDCCH indicating the PUSCH to the start of the PUSCH or the duration of the period from the receipt of the PDCCH indicating the PUSCH to the end of the PUSCH, (2) serving cell restrictions, including the wireless network 120 configuring the UE110 to send BFRQs on selected serving cells without beam failure, and (3) remaining UL grant size restrictions, may be defined as the number of bits or bytes that the UE includes the minimum set of beam failure information due to Logical Channel Priority (LCP) procedures. Another alternative may be that in case the BFRQ has triggered, then the UE110 may immediately trigger a class SR indication for the BFRQ to be decided. The purpose is to ensure that the wireless network 120 can be informed of SCell failure as soon as possible.

Under the proposed scheme for cancelling SR-like indications according to the present invention, different scells may trigger separate BFRQ and separate SR-like indications. When the class SR indication is triggered, it remains pending until cancelled. Under the proposed scheme, in case of transmitting a MAC PDU including BFRQ information of a corresponding SCell, the SR-like indication may be cancelled. Those SR-like indications to be decided whose BFRQ information is not included in the transmitted MAC PDU may remain to be decided. Under the proposed scheme, UE110 may or may not trigger CBRA for SpCell in case the transmission of the SR configuration for SCell BFR reaches the maximum number of PUCCH transmissions configured for the applied SR configuration. In the case where UE110 triggers CBRA for SpCell, UE110 may also perform one of the following: (1) cancel all pending SRs, (2) cancel all pending SRs for regular SRs, but not for SCell BFR, (3) cancel pending SR whose SR configuration suffers SR failure, and (4) continue to send SR for SR configurations of SCell BFR that exceed the sending limit. In the case that UE110 does not trigger CBRA for SpCell, UE110 may also perform one of the following: (1) cancel a pending SR whose SR configuration suffers from SR failure, and (2) not cancel the pending SR-like indication and continue to perform the corresponding SR transmission. Under the proposed scheme, the UE110 may trigger CBRA for the SpCell in case SR transmission for normal SR has reached the maximum number of PUCCH transmissions. Further, the UE110 may cancel either all pending SRs including the pending SR for the SCell BFR or all pending SRs except the pending SR for the SCell BFR. In case all beam failure information associated with all serving cells with beam failure has been sent with a UL grant that is not provided by a Random Access Response (RAR), the MAC entity may stop the ongoing RACH procedure for the SCell BFR.

With the proposed scheme according to the present invention, regarding the handling of pending SRs when there is no dedicated SR configuration for BFRs, the wireless network 120 may avoid handling pending SRs in case the MAC entity has no valid PUCCH resource configuration for pending SR-like indication. For example, SCell BFRs indicated by the class SR may not be supported without configuring PUCCH dedicated to SCell BFRs. Further, in the case where wireless network 120 determines that the SCell BFR function is supported, the PUCCH resource for BFR may be a mandatory field (regulatory field). Under the proposed scheme, an alternative approach may be that the UE110 transmits the SR on regular SR resources. For example, in a case where UE110 is configured with any SR configuration for data, UE110 may transmit an SR with such SR configuration. In the event that any SR configuration associated with high priority data is configured for UE110, UE110 may utilize such SR configuration to transmit the SR. For example, the SR configuration may be configured for UE110 to request resources for two purposes: for UL data transmission (conventional SR procedure) and for BFRQ transmission.

Under the proposed scheme, another alternative may be that UE110 triggers the RACH. For example, UE110 may trigger the RACH even if there is an SR configuration configured for a regular SR. Alternatively, the UE110 may trigger the RACH only when there is no SR configuration configured for a regular SR. Still alternatively, the UE110 may trigger the RACH only when there is no high priority SR configuration configured for a regular SR. In the presence of a high priority SR configuration configured for a regular SR, UE110 may request UL resources using the regular SR. Under the proposed scheme, in case of triggering RACH, UE110 may or may not cancel SR regardless of whether UE110 cancels SR for BFR SCell. Under the proposed scheme, for triggering RACH, UE110 may trigger CBRA for SpCell. Alternatively, the UE110 may trigger contention-free random access (CFRA) to the SCell, where CFRA resources are configured and dedicated for SCell BFR reporting. Still alternatively, UE110 may trigger CBRA for SpCell without configuring CFRA resources dedicated to SCell BFRs.

With the proposed scheme according to the present invention, the UE110 may be allowed to transmit PUCCH even though PUCCH overlaps with a measurement gap, with respect to priority of SR transmission of SCell BFR. For example, in cases where piggybacking is not possible, in some cases the PUCCH may be prioritized over UL-SCH transmission. For example, in a case where an UL-SCH resource is not used to transmit ultra-reliable low-latency communication (URLLC) traffic, the PUCCH may be prioritized over the UL-SCH in a case where the UL-SCH resource does not carry data with high priority (e.g., traffic-based quality of service (QoS) requirements or logical channel priority). Further, a relatively high priority may be assigned to the class SR indication. The UL-SCH may be transmitted in case it has a higher priority than the SR-like indication. Otherwise, PUCCH may be transmitted.

Under the proposed scheme according to the present invention, with respect to the handling of multiple SR-like indications of SCell BFRs, there may be one or more SR configurations configured for each MAC entity that are dedicated to SCell BFRs. Under the proposed scheme, SCell BFRQs of different serving cells may trigger separate SR-like indications based on one SR indication (one-SR-indication-per-SCell) per SCell. Under the proposed scheme, the SR-like indication of different serving cells may use separate SR configurations or share the same SR configuration for SCell BFR. That is, each SR is configured for each serving cell, each PUCCH cell group, or each cell group (each MAC entity). In case more than one individual (indicative) SR-like indication triggers an indication from the MAC entity to the physical layer to signal an SR on the same active PUCCH resource, then the SR COUNTER (SR _ COUNTER) of the relevant SR configuration can only be incremented once.

Under the proposed scheme according to the present invention, there may be various options when the PUCCH of the class SR indication for BFR overlaps with the PUCCH for the normal SR, regarding the priority when the overlap occurs between the PUCCHs. Under a first option (option 1), for class SR indication, it may depend on the implementation of the UE for the class SR indication. Under the second option (option 2), the SR-like indication can always take precedence over the regular SR. Under a third option (option 3), the priority indicated by the class SR may be compared with the priority of the traffic. For example, in case a normal SR is not triggered by URLLC traffic or traffic with a sufficiently high priority (e.g. based on QoS requirements of the traffic or logical channel priority), then the priority indicated by the SR-like indication may be compared to the priority of such traffic. Alternatively, a relatively high priority may be assigned to the class SR indication, and in case that the normal SR is not triggered by a Logical Channel (LCH) or traffic with a higher priority than the class SR indication, then the class SR indication for the BFR may be sent; otherwise, PUCCH for normal SR may be transmitted. Under the proposed scheme, when PUCCHs for multiple SR-like indications for BFRs overlap, one of the following two options may be taken. Under the first option (option 1), depending on the embodiment of which UE selects which to send. In the second option (option 2), the UE110 may select the PUCCH with the SR-like indication of (i) minimum PUCCH duration, (ii) minimum periodicity, (iii) minimum latency until PUCCH transmission begins, or (iv) minimum latency until PUCCH transmission ends.

Under the proposed scheme according to the present invention, there may be a plurality of options when the PUCCH indicated by the SR-like of BFR overlaps with PRACH resources, regarding the priority when the overlap occurs between PUCCH and RACH. Under the first option (option 1), depending on which embodiment the UE sends. Under the second option (option 2), detailed rules may be specified. For example, in case RACH is not used for SCell BFR, PCell BFR, handover, or for high priority data, PUCCH for SCell BFR may take precedence; otherwise, the RACH may take precedence. That is, in the case where the PUCCH of the SCell BFR is skipped, the MAC layer may update the COUNTER (e.g., minus 1) for each SR skip since SR transmission is not performed (e.g., in the case where the physical layer determines to skip the PUCCH of the SCell BFR, the physical layer may indicate to the MAC layer a notification of SR COUNTER suspension (SR _ COUNTER _ SUSPEND).

Under the proposed scheme, when the PRACH for SCell BFR overlaps with the PUCCH for regular SR, it depends on which UE implementation to send. Alternatively, detailed rules may be specified. For example, PRACH for SCell BFR may be specified to always take precedence. Alternatively, the UE110 may determine the priority based on the highest priority traffic that triggered the SR transmission (e.g., the priority may be based on logical channel priority, latency requirements, or other QoS requirements). Under the proposed scheme, when the PRACH for SCell BFR overlaps with the PUCCH for SCell BFR, it depends on which UE implementation to transmit. Alternatively, detailed rules may be specified. For example, PRACH may be prioritized or PUCCH may be prioritized.

Under the proposed scheme according to the present invention, with respect to priority when a RACH process is triggered during an ongoing RACH process, UE110 may continue the ongoing RACH for SpCell BFR when the RACH is triggered by SCell BFR and in case there is already an ongoing RACH process for SpCell BFR. When the RACH is triggered by the SCell BFR and in case there is already an ongoing RACH procedure for the SCell BFR, the UE110 may continue the ongoing RACH. When the RACH is triggered by the SCell BFR and in case there is already an ongoing RACH process that is not for the SCell BFR nor the SpCell BFR, the UE110 may stop the ongoing RACH and proceed with the RACH for the SCell BFR. Alternatively, in case the ongoing RACH is for handover, high priority data or SR failure, the UE110 may continue the ongoing RACH procedure. When a RACH process for SpCell BFR is triggered, UE110 may continue the ongoing RACH for SCell BFR, with the ongoing RACH triggered by SCell BFR already present. Alternatively, UE110 may stop the ongoing RACH for SCell BFR and may start the RACH for SpCell BFR. Still alternatively, the UE110 may determine a progress of the ongoing RACH for the SCell BFR. In the event that UE110 does not receive a RAR for the ongoing RACH of SCell BFR, UE110 may stop the ongoing RACH and may start the RACH for the SpCell BFR. Otherwise, UE110 may continue with the ongoing RACH. Still alternatively, UE110 may determine whether UE110 has a dedicated PRACH for SCell BFR and/or SpCell BFR. When a RACH procedure other than BFR is triggered, UE110 may continue the ongoing RACH for SCell BFR, with the ongoing RACH triggered by SCell BFR already present. Alternatively, in case the ongoing RACH is for handover, high priority data or SR failure, the UE110 may stop the ongoing RACH for the SCell BFR and start a new RACH procedure.

In view of the above, some of the points (highlight) of the various proposed solutions according to the invention are summarized below.

In some embodiments, when UE110 detects a beam failure of an SCell, UE110 may trigger a BFRQ, which may remain pending until cancelled. In triggering BFRQ, UE110 may generate a MAC CE of BFRs included in MAC PDUs to transmit to wireless network 120 in UL grants. UE110 may trigger a SR-like indication to wireless network 120 to request UL resources for MAC CE transmission for BFRs when certain conditions are met. After transmitting the beam failure information for the SCell that detected the beam failure, UE110 may cancel the pending BFRQ and SR-like indication for the SCell.

In some embodiments, UE110 may trigger a class SR indication for the SCell BFR if one or more of the following conditions are met: (1) no UL-SCH resources are available for new transmissions; (2) the MAC entity is configured with a configured UL grant and the UE110 is not configured with a MAC CE for BFRs that is always sent with the configured grant, and (3) the UL-SCH resources available for new transmission do not meet the requirements of SCell BFRQ transmission.

In some embodiments, the configuration UL grant may be a general configuration grant for transmitting data or may be a configuration grant dedicated for BFRQ transmission. Thus, wireless network 120 may configure UE110 to always transmit a BFR's MAC CE with a general configuration grant or a configuration grant that is transmitted for the BFR's MAC CE.

In some embodiments, the requirements for triggering the class SR indication may include one or more of: (1) latency requirements, which may be defined as a PUSCH duration for a UL grant, a duration of a period from receiving a PDCCH indicating the PUSCH to starting the PUSCH or receiving a PDCCH indicating the PUSCH to ending the PUSCH, (2) serving cell restriction, which may include wireless network 120 configuring UE110 to send BFRQ in a selected serving cell without beam failure, and (3) remaining UL grant size, which refers to whether UE110 may include a minimum set of beam failure information in the remaining UL grant size due to Logical Channel Priority (LCP) procedures.

In some embodiments, where a BFRQ has been triggered as described above, the UE110 may immediately trigger a SR-like indication for the BFRQ to be decided.

In some embodiments, the UE110 may trigger CBRA for SpCell in case the MAC entity has no valid PUCCH resource configuration for the SR-like indication to decide.

In some embodiments, the class SR indication may not be triggered in the event wireless network 120 does not configure UE110 with an SR configuration dedicated to BFRs.

In some embodiments, in case the MAC entity has no valid PUCCH resource configuration for the pending SR-like indication, the UE110 may send the SR in the SR configuration for data arrival if the SR configuration for data arrival is configured.

In some embodiments, there may be multiple SR configurations dedicated to the class SR indication of the SCell BFR configured for each MAC entity. For example, SR configurations dedicated to class SR indications may not be used to request uplink resources for UL data transmission. For another example, the SR configuration dedicated to the class SR indication may also be used by UE110 to request uplink resources for UL data transmission.

In some embodiments, the SR-like indication may be on a per SCell basis. Thus, SCell BFRQs for different serving cells may trigger different/separate SR-like indications, respectively.

In some embodiments, the SR-like indications for different serving cells may use separate SR configurations or may share the same SR configuration for SCell BFRs. That is, the SR configuration may be per serving cell, per PUCCH cell group, and/or per cell group (e.g., per MAC entity).

In some embodiments, in case more than one separate SR-like indication triggers an instruction from the MAC entity to the physical layer to signal an SR on the same active PUCCH resource, the SR COUNTER (SR _ COUNTER) for the relevant SR configuration may be incremented only once.

In some embodiments, UE110 may trigger CBRA for SpCell and cancel all pending SRs, in case the transmission of the SR-like indication for SCell BFR has reached the maximum number of PUCCH transmissions for which the applied SR configuration is configured.

In some embodiments, in case SR transmission for regular SR (for data arrival) reaches the maximum number of PUCCH transmissions, UE110 may trigger CBRA for SpCell and cancel all pending SRs except pending SR-like indication for SCell BFR.

In some embodiments, the priority of the MAC CE of the BFR may be lower than the priority of the configuration permission acknowledgement MAC CE and higher than the priority of the MAC CE of the BSR for non-padding use.

In some embodiments, the MAC CE of the BFR may have a short format, which may include beam failure information for one serving cell. Alternatively or additionally, the MAC CE of the BFR may have a short format, which may include one or more bitmaps (bitmaps) indicating the IDs of the SCell(s) with beam failure.

In some embodiments, the MAC CE of the BFR may have two formats. The first format may include only those serving cells that do not have new beam information (e.g., no candidate beams above the RSRP threshold). The second format may include only those serving cells with beam failure and new beam information.

In some embodiments, the MAC CE of the BFR may include a truncated (truncated) format to include a portion of the beam information from all failed scells. Thus, the UE110 may select a format in case there is not enough space in the available UL grant to send beam information in the entity.

Illustrative embodiments

FIG. 7 illustrates an example system 700 having at least one example apparatus 710 and an example apparatus 720, according to an embodiment of the invention. Each of the apparatus 710 and the apparatus 720 may perform various functions to implement the schemes, techniques, procedures, and methods described herein relating to BFR procedures for scells in mobile communications, including the various proposed designs, concepts, schemes, systems, and methods described above, and the procedures described below. For example, the apparatus 710 may be an exemplary embodiment of the UE110 and the apparatus 720 may be an exemplary embodiment of the network node 125.

Each of the devices 710 and 720 may be part of an electronic device, may be a network device or UE (e.g., UE 110), such as a portable or mobile device, a wearable device, a wireless communication device or a computing device, or the like. For example, each of the apparatus 710 and the apparatus 720 may be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing device such as a tablet, laptop, notebook, or the like. Each of the devices 710 and 720 may also be part of a machine type device, and may be an IoT device such as a fixed or static device, a home device, a wired communication device, or a computing device. For example, each of the device 710 and the device 720 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. When implemented in or as a network device, the apparatus 710 and/or the apparatus 720 may be implemented in a network node (e.g., the network node 125), for example in an eNB in an LTE, LTE-Advanced, or LTE-Advanced Pro network, or in a gNB or TRP in a 5G network, NR network, or IoT network.

In some embodiments, each of the devices 710 and 720 may be implemented in the form of one or more Integrated Circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more reduced-Instruction-Set Computing (RISC) processors, or one or more Complex-Instruction-Set Computing (CISC) processors. In the various embodiments described above, each of the devices 710 and 720 includes at least some of those components shown in fig. 7, e.g., the processor 712 and the processor 722, respectively. Each of the apparatus 710 and the apparatus 720 may further comprise one or more other components (e.g., an internal power supply, a display device, and/or a user interface device) unrelated to the proposed solution of the present invention, and for brevity and simplicity these components of the apparatus 710 and the apparatus 720 are neither shown in fig. 7 nor described in fig. 7.

In an aspect, each of processor 712 and processor 722 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. That is, even though the singular term "processor" is used herein to refer to the processor 712 and the processor 722, each of the processor 712 and the processor 722 may include multiple processors in some embodiments and a single processor in other embodiments in accordance with the present invention. In another aspect, each of the processors 712 and 722 may be implemented in hardware (and, optionally, firmware) with electronic components that may include, but are not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and/or one or more varactors configured and arranged in accordance with the present invention to achieve particular objectives. In other words, at least in some implementations, each of the processor 712 and the processor 722 may act as a dedicated machine specifically designed, configured and arranged to perform specific tasks including tasks related to a BFR process for a Scell in mobile communications in accordance with various embodiments of the present invention.

In some embodiments, the apparatus 710 may further include a transceiver 716 coupled to the processor 712. The transceiver 716 is capable of wirelessly transmitting and receiving data. The apparatus 720 may also include a transceiver 726 coupled to the processor 722. The transceiver 726 is capable of wirelessly transmitting and receiving data.

In some embodiments, the apparatus 710 may further include a memory 714, the memory 714 being coupled to the processor 712 and capable of being accessed by the processor 712 and storing data therein. In some embodiments, the device 720 may further include a memory 724, the memory 724 being coupled to the processor 722 and being accessible by the processor 722 and storing data therein. Each of memory 714 and memory 724 may include one type of Random Access Memory (RAM), for example, dynamic RAM (dram), static RAM (sram), thyristor RAM (T-RAM), and/or zero capacitor (Z-RAM) memory. Alternatively or additionally, each of memory 714 and memory 724 may include one type of read-only memory (ROM), such as mask ROM, programmable ROM (prom), erasable programmable ROM (eprom), and/or electrically erasable programmable ROM (eeprom). Alternatively or additionally, each of memory 714 and memory 724 may include a type of non-volatile random access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric ram (feram), magnetoresistive ram (mram), and/or phase change memory.

Each of the devices 710 and 720 may be communication entities capable of communicating with each other using various proposed schemes in accordance with the present invention. For purposes of illustration and not limitation, the following provides a description of the capabilities of the apparatus 720 as a base station of a serving cell of a wireless network (e.g., a 5G/NR mobile network), the apparatus 710 as a UE. It is noted that although the example embodiments described below are provided in the context of a UE, they may equally be implemented in and performed by a base station. Thus, although the following description of example embodiments relates to the apparatus 710 being a UE (e.g., UE 110), it is also applicable to the apparatus 720 being a network node (e.g., network node 125) or base station, e.g., gNB, TRP or eNodeB, in a wireless network (e.g., wireless network 120) such as a 5G NR mobile network.

Under the proposed scheme with respect to BFR procedures for scells in mobile communication in accordance with the present invention, processor 712 of apparatus 710 may detect, via transceiver 716, a beam failure of a serving cell (e.g., an SCell or SpCell associated with network node 130). Further, processor 712 may trigger a BFRQ via transceiver 716 in response to the detection. The BFRQ may remain pending until cancelled. In triggering BFRQ, processor 712 may generate a MAC CE for the BFR and then transmit the MAC CE for the BFR to a wireless network (e.g., via wireless network 120 as device 720 of network node 125) using resources pursuant to the UL grant.

In some embodiments, in generating a MAC CE for a BFR, processor 712 may generate a MAC CE with an associated LCID indicating that the MAC CE is associated with a beam failure of a detected serving cell.

In some embodiments, in generating the MAC CE of the BFR, processor 712 may generate a truncated BFR MAC CE that omits one or more pieces of information related to the beam failure.

In some embodiments, in generating the MAC CE for the BFR, processor 712 may generate the MAC CE for the non-truncated BFR including the first bitmap and the second bitmap. In this case, the first bitmap (e.g., C)_iBitmap) may indicate beam failure detection of one or more of the plurality of serving cells, and a second bitmap (e.g., F)_iBitmap) may indicate whether new beam information for one or more eligible new beams is provided for one or more of the plurality of serving cells or whether new beam information for one or more eligible new beams is provided for one or more of the plurality of serving cells that have beam failure.

In some embodiments, in generating the MAC CE of the BFR, processor 712 may generate a short BFR MAC CE having information of those serving cells that experienced the beam failure, but no other information about the serving cells that experienced the beam failure.

In some embodiments, in generating the MAC CE for the BFR, processor 712 may generate the MAC CE for the long BFR with information of the serving cell in which the beam failure was detected and other information about the serving cell suffering from the beam failure.

In some embodiments, the serving cell may include a SpCell. In this case, in generating the MAC CE of the BFR, the processor 712 may generate the MAC CE including the BFR indicated (serving cell index of the SpCell).

In some embodiments, the MAC CE of a BFR may be lower priority than C-RNTI MAC CE or data from the UL-CCCH, and may be higher priority than the configuration grant acknowledgement MAC CE.

In some embodiments, the MAC CE of the BFR may have a lower priority than the configuration permission acknowledgement MAC CE and a higher priority than the BSR for non-padding purposes.

In some implementations, the processor 712 may perform additional operations. For example, the processor 712 may cancel the BFRQ in response to the beam information of the serving cell being included in a MAC PDU already transmitted to the wireless network. In cancelling BFRQ, processor 712 may stop sending more BFRs' MAC CEs to the wireless network.

In some implementations, the processor 712 may perform additional operations. For example, the processor 712 may trigger a SR-like indication via the transceiver 716 to notify the wireless network of a beam failure of the serving cell in response to the detection. In the trigger class SR indication, the processor 712 may send an SR for BFR to the wireless network.

In some embodiments, the serving cell may comprise an SCell. In this case, in triggering the class SR indication, the processor 712 may trigger the class SR indication in response to one or more of the plurality of conditions having been satisfied. The plurality of conditions may include: (a) no UL-SCH resources are available for new transmission, (b) the MAC entity is configured with one or more UL grants and the apparatus is configured to transmit a class SR indication (even if the configured UL grant is available), and (c) there is insufficient space to include non-truncated BFR MAC CEs or truncated BFR MAC CEs due to the LCP process, even if there are UL grants available.

In some implementations, the processor 712 may perform additional operations. For example, the processor 712 may cancel the SR-like indication in response to BFR information for the serving cell being included in a MAC PDU already transmitted to the wireless network. In cancelling the SR-like indication, the processor 712 may stop sending SRs for BFRs to the wireless network.

Under another proposed scheme according to the present invention with respect to a BFR procedure of an SCell in mobile communication, processor 712 of apparatus 710 may detect a beam failure of the SCell via transceiver 716. Additionally, processor 712 may trigger a BFRQ in response to the detection. The BFRQ may remain pending until cancelled.

In some embodiments, processor 712 may perform certain operations in triggering a BFRQ. For example, processor 712 may generate a MAC CE for the BFR. Further, the processor 712 may transmit the MAC CE of the BFR to the wireless network using the resource according to the UL grant.

In some embodiments, at least one SR configuration dedicated to SCell BFRs may be configured for each MAC entity.

In some embodiments, in detecting a beam failure of an SCell, the processor 712 may detect a beam failure of multiple serving cells. Further, in triggering BFRQ, the processor 712 may trigger a respective one of the plurality of class SR indications for a corresponding one of the plurality of serving cells.

In some embodiments, multiple class SR indications may share the same SR configuration for SCell BFRs.

Alternatively, each of the plurality of SR configurations may be for a respective one of a plurality of class SR indications. In this case, each of the plurality of SR configurations may be for a corresponding serving cell, a corresponding PUCCH cell group, a corresponding cell group, or a corresponding MAC entity.

In some implementations, the processor 712 may perform additional operations. For example, the processor 712 may cancel the BFRQ in response to the beam information of the SCell being included in a MAC PDU already transmitted to the wireless network. In cancelling BFRQ, processor 712 may stop sending MAC CEs of any other instance BFRs to the wireless network.

FIG. 8 is an exemplary flow 800 described in accordance with an embodiment of the invention. The flow 800 represents an aspect that embodies the various proposed aspects, concepts, schemes, systems and methods described above. More specifically, the flow 800 represents an aspect of the concept and scheme proposed in accordance with the present invention regarding a BFR procedure for an SCell in mobile communication. Flow 800 may include one or more operations, actions, or functions illustrated by blocks 810, 820 and sub-blocks 822 and 824. Although the various blocks shown are discrete, the various blocks in the flow 800 may be split into more blocks, combined into fewer blocks, or some blocks removed, depending on the desired implementation. Further, the blocks or sub-blocks of the process 800 may be performed in the order shown in FIG. 8 or may be performed in other orders. Further, blocks or sub-blocks of the process 800 may be repeated or iteratively performed. The flow 800 may be implemented by or in the devices 710 and 720 and any variations thereof. For purposes of illustration only and not to limit scope, flow 800 is described below in the context of apparatus 710 as a UE (e.g., UE 110) and apparatus 720 as a network node (e.g., network node 125) in a wireless network (e.g., wireless network 120), such as a 5G/NR mobile network. The flow 800 may begin at block 810.

At block 810, flow 800 may include processor 712 of apparatus 710 detecting, via transceiver 716, a beam failure of a serving cell (e.g., an SCell or SpCell associated with network node 130). Flow 800 may proceed from block 810 to block 820.

At block 820, flow 800 may include processor 712 triggering a BFRQ via transceiver 716 in response to the detection. The BFRQ remains pending until cancelled. In triggering BFRQ, process 800 may include processor 712 performing the operations represented by sub-blocks 822 and 824.

At sub-block 822, flow 800 may include processor 712 generating a MAC CE for the BFR. Flow 800 may proceed from sub-block 822 to sub-block 824.

At sub-block 824, flow 800 may include processor 712 transmitting the MAC CE of the BFR to a wireless network (e.g., via wireless network 120 as device 720 of network node 125) using resources pursuant to the UL grant.

In some embodiments, in generating a MAC CE for a BFR, flow 800 may include processor 712 generating a MAC CE with an associated LCID indicating that the MAC CE is associated with a beam failure of a detected serving cell.

In some embodiments, in generating the MAC CE of the BFR, flow 800 may include processor 712 generating a truncated BFR MAC CE that omits one or more pieces of information related to the beam failure.

In some embodiments, in generating a MAC CE for a BFR, flow 800 may include processor 712 generating a MAC CE for a non-truncated BFR including a first bitmap and a second bitmap. In this case, the first bitmap (e.g., C)_iMay indicate beam failure detection of one or more of the plurality of serving cells, and a second bitmap (e.g., F)_iA bitmap of (a) may indicate: (a) whether to provide new beam information for the one or more eligible new beams for one or more of the plurality of serving cells, or (b) whether to provide new beam information for the one or more eligible new beams for one or more of the plurality of serving cells having the beam failure.

In some embodiments, in generating a MAC CE for a BFR, flow 800 may include processor 712 generating a MAC CE for a short BFR that includes information of a serving cell detected to have a beam failure, but does not have other information related to the serving cell that suffered the beam failure.

In some embodiments, in generating the MAC CE for the BFR, flow 800 may include processor 712 generating the MAC CE for the long BFR including information of the serving cell detected to have the beam failure, and other information related to the serving cell suffering from the beam failure.

In some embodiments, the serving cell may include a SpCell. In this case, in generating the MAC CE for the BFR, flow 800 may include processor 712 may generate the MAC CE including the BFR indicated (serving cell index of the SpCell).

In some embodiments, the MAC CE of a BFR may be lower priority than C-RNTI MAC CE or data from the UL-CCCH, and may be higher priority than the configuration grant acknowledgement MAC CE.

In some embodiments, the MAC CE of the BFR may have a lower priority than the configuration permission acknowledgement MAC CE and a higher priority than the BSR for non-padding purposes.

In some implementations, the flow 800 may include the processor 712 performing additional operations. For example, flow 800 may include processor 712 cancelling the BFRQ in response to the beam information of the serving cell being included in a MAC PDU already transmitted to the wireless network. In cancelling BFRQ, flow 800 may include processor 712 may stop sending MAC CEs of any other instance BFRs to the wireless network.

In some implementations, the flow 800 may include the processor 712 performing additional operations. For example, flow 800 may include processor 712 triggering, via transceiver 716, a SR-like indication to notify a wireless network of a beam failure of a serving cell in response to the detecting. In triggering class SR indication, flow 800 may include processor 712 transmitting an SR for a BFR to a wireless network.

In some embodiments, the serving cell may comprise an SCell. In this case, in triggering the class SR indication, the flow 800 may include the processor 712 triggering the class SR indication in response to one or more of the plurality of conditions having been satisfied. The plurality of conditions may include: (a) no UL-SCH resources are available for new transmissions, (b) the MAC entity is configured with one or more UL grants and the apparatus is configured to transmit a class SR indication, and (c) there are uplink grants for new transmissions, but due to the LCP procedure there are not enough uplink grants to carry truncated or non-truncated BFR MAC CEs.

In some implementations, the flow 800 may include the processor 712 performing additional operations. For example, flow 800 may include processor 712 canceling the SR-like indication in response to BFR information of the serving cell being included in a MAC PDU already transmitted to the wireless network. In cancelling the SR-like indication, flow 800 may include processor 712 ceasing to send the SR for the BFR to the wireless network.

FIG. 9 is an exemplary flowchart 900 described in accordance with an embodiment of the present invention. Flow 900 represents an implementation of one aspect of the various proposed aspects, concepts, schemes, systems and methods described above. More specifically, the flow 900 represents an aspect of the concept and scheme proposed in accordance with the present invention regarding a BFR procedure for an SCell in mobile communication. The flow 900 may include one or more operations, actions, or functions illustrated by the blocks 910, 920. Although the various blocks shown are discrete, the various blocks in flow 900 may be split into more blocks, combined into fewer blocks, or portions thereof, depending on the desired implementation. Further, the blocks or sub-blocks of the flow 900 may be performed in the order shown in FIG. 9 or may be performed in other orders. Further, blocks or sub-blocks of the process 900 may be repeated or iteratively performed. The flow 900 may be implemented by or in the devices 710 and 720 and any variations thereof. For purposes of illustration only and not to limit scope, flow 900 is described below in the context of apparatus 710 as a UE (e.g., UE 110) and apparatus 720 as a network node (e.g., network node 125) in a wireless network (e.g., wireless network 120), such as a 5G/NR mobile network. The flow 900 may begin at block 910.

At block 910, flow 900 may include processor 712 of apparatus 710 detecting, via transceiver 716, a beam failure of the SCell. Flow 900 may proceed from block 910 to block 920.

At block 920, flow 900 may include processor 712 triggering a BFRQ in response to the detection. The BFRQ remains pending until cancelled.

In some embodiments, in triggering BFRQ, flow 900 may include processor 712 performing certain operations. For example, flow 900 may include processor 712 generating a MAC CE for the BFR. Further, flow 900 may include processor 712 transmitting the MAC CE of the BFR to the wireless network using resources pursuant to the UL grant.

In some embodiments, at least one SR configuration dedicated to SCell BFRs may be configured for each MAC entity.

In some embodiments, in detecting a beam failure of an SCell, flow 900 may include processor 712 detecting a beam failure of multiple serving cells. Further, in triggering BFRQ, flow 900 may include processor 712 triggering a respective one of the plurality of class SR indications for a corresponding one of the plurality of serving cells.

In some embodiments, multiple class SR indications may share the same SR configuration for SCell BFRs.

Alternatively, each of the plurality of SR configurations may be for a respective one of a plurality of class SR indications. In this case, each of the plurality of SR configurations may be for a corresponding serving cell, a corresponding PUCCH cell group, a corresponding cell group, or a corresponding MAC entity.

In some embodiments, flow 900 may include processor 712 performing additional operations. For example, flow 900 may include processor 712 cancelling BFRQ in response to the beam information for the SCell being included in a MAC PDU already transmitted to the wireless network. In cancelling BFRQ, flow 900 may include processor 712 ceasing to send MAC CEs of any other instance BFRs to the wireless network.

Additional description

The subject matter described herein sometimes illustrates different components included within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

Furthermore, with respect to substantially any plural and/or singular terms used herein, those having skill in the art may translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural reciprocity may be explicitly set forth herein.

Furthermore, those of skill in the art will understand that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) generally mean "open" terms, e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an," e.g., "a and/or" an "should be interpreted to mean" at least one "or" one or more, "which likewise applies to the use of definite articles used to introduce a claim recitation. Furthermore, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations. Further, where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). Where a convention analogous to "A, B or at least one of C, etc." is used, in the sense one having skill in the art would understand the convention, it is generally intended that such a construction be interpreted (e.g., "a system having at least one of A, B or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative items, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the items, either of the items, or both items. For example, the phrase "a or B" will be understood to include the possibility of "a" or "B" or "a and B".

From the foregoing, it will be appreciated that various embodiments of the invention have been described herein for purposes of illustration, and that various modifications may be made without deviating from the scope and spirit of the invention. Accordingly, the various embodiments disclosed herein are not meant to be limiting, with the true scope and spirit being determined by the following claims.

Claims (20)

1. A method for beam fault recovery of a secondary cell comprises the following steps:

the device detects a beam failure of a serving cell; and

a beam failure recovery request is triggered in response to the detection,

wherein the beam failure recovery request remains pending until cancelled, and

wherein the step of triggering the beam failure recovery request comprises:

generating a medium access control element for beam failure recovery, and

and transmitting the beam failure recovered medium access control element to the wireless network by using the resource according to the uplink grant.

2. The method of claim 1, wherein the step of generating the medium access control element for beam failure recovery comprises generating a medium access control element with an associated logical channel identifier, wherein the associated logical channel identifier indicates that the medium access control element is related to the detected beam failure of the serving cell.

3. The method of claim 1, wherein the step of generating the beam failure recovery medium access control element comprises generating a truncated beam failure recovery medium access control element that omits one or more pieces of information related to the beam failure.

4. The method of claim 1, wherein the step of generating the beam failure recovered medium access control element comprises generating a non-truncated beam failure recovered medium access control element comprising a first bitmap and a second bitmap, wherein the first bitmap indicates beam failure detection of one or more serving cells of the plurality of serving cells, and the second bitmap indicates whether to provide new beam information of one or more qualified new beams for the one or more serving cells of the plurality of serving cells or whether to provide new beam information of one or more qualified new beams for the one or more serving cells of the plurality of serving cells with a beam failure.

5. The method of claim 1, wherein the step of generating the beam failure recovery medium access control element comprises generating a short beam failure recovery medium access control element having information of the serving cell suffering from the beam failure but no other information related to the serving cell suffering from the beam failure.

6. The method of claim 1, wherein the step of generating the beam failure recovery medium access control element comprises generating a long beam failure recovery medium access control element having information of the serving cell suffering from beam failure and other information related to the serving cell suffering from beam failure.

7. The method of claim 1, wherein the serving cell comprises a special cell, and wherein the step of generating the beam failure resilient medium access control element comprises generating the beam failure resilient medium access control element comprising an indication of a serving cell index of the special cell.

8. The method of claim 1, wherein the medium access control element for beam failure recovery has a lower priority than the medium access control element for cell radio network temporary identifier or data from the uplink common control channel and a higher priority than the configuration grant confirmation medium access control element.

9. The method of claim 1, wherein the priority of the MAC element for beam failure recovery is lower than that of the MAC element for configuration admission acknowledgement and higher than that of the MAC element not used for the buffer status report for padding.

10. The method of beam failure recovery for a secondary cell of claim 1, further comprising:

canceling the beam failure recovery request in response to the beam information of the serving cell being included in a medium access control protocol data unit that has been transmitted to the wireless network,

wherein the step of canceling the beam failure recovery request comprises ceasing transmission of any other beam failure recovery medium access control elements to the wireless network.

11. The method of beam failure recovery for a secondary cell of claim 1, further comprising:

triggering a generic scheduling request indication to notify the wireless network of the beam failure of the serving cell in response to the detecting step,

wherein the step of triggering the class of scheduling request indication comprises sending a scheduling request for beam failure recovery to the wireless network.

12. The method of claim 11, wherein the serving cell comprises a secondary cell, wherein the step of triggering the type of scheduling request indication comprises triggering the type of scheduling request indication in response to one or more of a plurality of conditions being met, wherein the plurality of conditions comprise:

no uplink shared channel resources are available for new transmissions,

the medium access control entity is configured with one or more uplink grants, the apparatus is configured to send the scheduling request indication of the type, and

uplink shared channel resources are available for new transmissions, but due to the lack of sufficient uplink grants for the logical channel priority procedure, truncated beam failure recovery or non-truncated beam failure recovery medium access control elements cannot be included in the uplink grant or grants.

13. The method of beam failure recovery for a secondary cell of claim 11, further comprising:

canceling the class scheduling request indication in response to the beam failure recovery information for the serving cell being included in a medium access control protocol data unit that has been transmitted to the wireless network,

wherein the step of the class of scheduling request indication comprises stopping transmission of scheduling requests for beam failure recovery to the wireless network.

14. A method for beam fault recovery of a secondary cell comprises the following steps:

the device detects a beam fault of the secondary cell; and

a beam failure recovery request is triggered in response to the detection,

wherein the beam failure recovery request remains pending until cancelled.

15. The method of claim 14, wherein the step of triggering the beam failure recovery request comprises:

generating a medium access control element for beam failure recovery, and

and transmitting the beam failure recovered medium access control element to the wireless network by using the resource according to the uplink grant.

16. The method of claim 15, wherein at least one scheduling request configuration dedicated to beam failure recovery of the secondary cell is configured for each medium access control entity.

17. The method of claim 15, wherein the step of detecting the beam failure of the secondary cell comprises detecting beam failures of a plurality of serving cells, and wherein the step of triggering the beam failure recovery request comprises triggering a corresponding one of a plurality of class scheduling request indications for a corresponding one of the plurality of serving cells.

18. The method of claim 17, wherein the plurality of class scheduling requests indicate sharing the same scheduling request configuration for beam failure recovery of the secondary cell.

19. The method of beam failure recovery of a secondary cell of claim 17, wherein each of a plurality of scheduling request configurations is used for a corresponding class scheduling request indication of the plurality of class scheduling request indications, and wherein each of the plurality of scheduling request configurations is used for a corresponding serving cell, a corresponding group of physical uplink control channel cells, a corresponding group of cells, or a corresponding medium access control entity.

20. The method of beam failure recovery for a secondary cell of claim 15, further comprising:

canceling the beam failure recovery request in response to the beam information of the serving cell being included in a medium access control protocol data unit that has been transmitted to the wireless network,

wherein the step of canceling the beam failure recovery request comprises ceasing transmission of any other beam failure recovery medium access control elements to the wireless network.

Images