Method, device and computer readable medium for beam failure recovery for secondary cell

[0050]The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described only for purposes of illustration, and those skilled in the art will appreciate and implement the present disclosure without any limitation. The disclosure described herein can be implemented in a variety of ways in addition to the following description.

[0051]In the following description and claims, all techniques and scientific terms used herein have the same meaning as generally understood by those of ordinary skill in the art of the present disclosure, unless otherwise defined.

[0052]As used herein, the term "network device" or "base station" (BS) refers to a device capable of providing or hosting a cell or coverage that can communicate with a terminal device. Examples of network devices include, but are not limited to, Node B (NodeB or NB), Evolved NodeB (ENODEB or ENB), NodeB (GNB) in New Radio Access, Remote Radio Unit (RRU), Radio Head (RH), Remote Head Radios (RRH), low power nodes (such as femto nodes, pico nodes, etc.). For purposes of discussion, some embodiments will be described with reference to the examples of the network device as described hereinafter.

[0053]As used herein, the term "terminal device" refers to any device having wireless or wired communication capabilities. Examples of terminal devices include, but are not limited to, user equipment (UE), personal computer, desktop, mobile phone, cellular telephone, smart phone, personal digital assistant (PDA), portable computer, image capture device (such as digital cameras), game devices , Music storage and playback devices or Internet devices such as wireless or wired internet access and browse.

[0054]As used herein, unless the context is further clearly indicated, the singular form "one", "one", and "this" are also intended to include multiple forms. The term "including" and its variants should be interpreted as open terms, which means "including but not limited to". The term "based on" should be interpreted as "at least partially based on". The term "one embodiment" and "Embodiment" should be interpreted as "at least one embodiment". The term "another embodiment" should be interpreted as "at least one other embodiment". The term "first", "second" or the like can refer to different or the same object. Other definitions, whether explicitly or implicit, can be included below.

[0055]In some examples, the value, the process or device is called "best", "lowest", "highest", "smallest", "maximum". It will be appreciated that such a description is intended to indicate that it can be selected in many of the functions of many usage, and such selection does not require better, smaller, higher or otherwise preferred than others.

[0056]As mentioned above, a beam failure may occur when the quality of the (multiple) beam pairs of the service cell is low enough. When a beam failure occurs, a mechanism for recovery from the beam fault can be triggered. The beam failure recovery mechanism on the terminal device side typically includes the following operations: beam fault detection, new beam identity, transmission of beam failure recovery requests, and monitoring responses from network devices to beam failure recovery requests. In the 3GPP specification TS 38.214 and 38.321, the beam failure recovery (BFR) process for PCell has been specified as follows:

[0057](a) Terminal device initiates a dedicated PRACH transmission in PCELL in a non-competitive physical random access channel (CFRA) as a BFR request, and the PRACH leading index is associated with the new candidate beam index identified by the terminal device;

[0058](b) After receiving the PRACH transmission, the network device sends a BFR request response to the terminal device on a dedicated control resource set (Coreset-BFR), and the terminal device should monitor the CoreSet-BFR for the BFR request response.

[0059]In this article, the PRACH preamble is also referred to as a random access preamble.

[0060]However, this process is not suitable for beam failure for SCell. Unlike a beam failure for PCell, the Media Access Control Unit (MAC CE) can be used in beam failure to SCell, because the link on the PCell can operate when the beam fault occurs in the SCell. When the beam failure is used to use the MAC CE, if there is no physical uplink shared channel (PUSCH) resource to send the MAC CE, there may be a problem that the new beam is indicated.

[0061]Conventionally, the buffer status report (BSR) is transmitted using the remaining bit (padding bits) of PUSCH. One possible solution to the above problem is to use a Physical Upper Link Control Channel (PUCCH) resource. There is a number of symbols in the PUCCH format, and the PUCCH resource is determined by the size of the confirmation resource indicator (ARI) and the uplink control information (UCI). Therefore, there may be residual resources that are not used to send UCI on the PUCCH. For example, if the UE is included The PUCCH format 1 or PUCCH format 3 is transmitted using the PUCCH format 1 or PUCCH format 3 in the PUCCH resource of the physical resource block (PRB), and the UE will use the number of PRBs transmitted by the PUCCH. Determine the minimum number of PRBs. Therefore, it can be based on with To determine the remaining number of PRBs. The inventors of the present application have recognized that residual resources that are not used to send UCI on the PUCCH can be used to recover the beam faults for SCELL.

[0062]Embodiments of the present disclosure provide solutions for beam failure recovery. A solution for beam failure recovery according to an embodiment of the present disclosure can be adapted to occur beam failures occurred on SCELL. Further, the embodiment of the present disclosure specifies the process of using the MAC CE for beam failure recovery, and can solve the above problems and one or more other potential problems.

[0063]HereinafterFigure 1 - Figure 18 The principles and implementations of the present disclosure are described in detail.

[0064]figure 1 An example communication network 100 that can implement the embodiments of the present disclosure can be implemented. Network 100 includes a network device 110 and a terminal device 120 serving a network device 110. Network 100 can provide one or more service cells 101, 102 to serve the terminal device 120, where each serving cell corresponds to a CC. It should be understood that the number of network devices, terminal equipment, and service cells is only for illustrative purposes only, and no restrictions are made. Network 100 can include any suitable number of network devices, terminal devices, and service cells suitable for implementing embodiments of the present disclosure.

[0065]In the communication network 100, the network device 110 can transmit data and control information to the terminal device 120, and the terminal device 120 can also transmit data and control information to the network device 110. The link from the network device 110 to the terminal device 120 is referred to as a downlink (DL) or forward link, and the link from the terminal device 120 to the network device 110 is referred to as an uplink (UL) or reverse link.

[0066]Depending on the communication technology, the network 100 can be a code division multiplex (CDMA) network, time division multi-access (TDMA) network, frequency division multiple access (FDMA) network, orthogonal frequency division multiple access (OFDMA) network, single carrier frequency division Multiple Access (SC-FDMA) network or any other network. Communication discussed in network 100 can use any suitable standard, including, but not limited to, new radio access (NR), long-term evolution (LTE), LTE evolution, advanced LTE (LTE-A), broadband code division multiple access ( WCDMA), Code Division Multiple Access (CDMA), CDMA2000, and Global Mobile Communication System (GSM), etc. In addition, communication can be performed based on any generation of communication protocols to be developed or in the future. Examples of communication protocols include, but are not limited to, first generation (1 g), second generation (2G), 2.5g, 2.75g, third generation (3G), fourth generation (4G), 4.5g, fifth generation (5g) )letter of agreement. The techniques described herein can be used in wireless networks and radio technologies mentioned above and other wireless networks and radio technologies. For the sake of clarity, some aspects of this technique are described below for LTE, and LTE terminology is used in many of the descriptions below.

[0067]CAs can be supported in network 100, two or more CCs being aggregated to support wider bandwidth. In CA, network device 110 can provide a plurality of serving cells including a PCell 101 and at least one SCell 102 to the terminal device 120. The terminal device 120 can establish a radio resource control (RRC) connection with the network device 110 on the PCell 101. Once the RRC connection is established between the network device 110 and the terminal device 120 and the SCELL 102 is activated via the high layer signaling, the SCell 102 can provide additional radio resources.

[0068]It should be understood thatfigure 1 The configuration of the PCELL 101 and SCELL 102 shown is only for illustrative purposes only, without any restrictions. PCELL 101 and SCELL 102 can havefigure 1 Different configurations shown in the display.

[0069]For example, in some other scenes, the terminal device 120 can be with two groups of CCs (figure 1 Not shown) Establish a connection, and thus more radio resources can be utilized. The two groups of CCs may be defined as the CC master group and the CC assistant group, respectively. The CC master can provide a set of service cells, which are also referred to as "the main cell group (MCG)". A set of service cells can also be provided in CC auxiliary groups, also known as "secondary cell group (SCG)." For dual-connection operations, depending on the terminal device 120 is associated with MCG or associated with SCG, the term "SPCell" may refer to the MCG's PCell or SCG's primary SCell (PSCell). In other cases other than the dual connection operation, the term "spcell" can also refer to PCell. Although the PCELL is shown as an example, the embodiments of the present disclosure may also apply to two sets of dual connection configurations.

[0070]In an embodiment, the network device 110 is configured to implement a beamforming technique and transmit a signal to the terminal device 120 via a plurality of beams. The terminal device 120 is configured to receive signals transmitted by the network device 110 via a plurality of beams. There may be different beams associated with PCell 101 and SCell 102. Such asfigure 1 As shown in, the DL beams 111 and 112 are associated with SCell 102. It should be understood that SCELL 102 can have more beams associated therewith. Although not shown, the PCell 101 can also have beams associated therewith.

[0071]As mentioned above, beam failure may occur on SCELL 102. For example, network device 110 can be configured to transmit signals via beam 112, and the terminal device 120 can detect beam failures of the beam 112. Then, the beam failure recovery process can be initiated. Specifically, the terminal device 120 can identify a new beam for recovery from the beam failure. For example, the terminal device 120 can select beam 111 as a new candidate beam from the available beam on the SCEL1 102, for example, based on the quality of the available beam. In order to facilitate discussion, the new beam being identified by the terminal device 120 is called the selected beam 111 below.

[0072]Terminal device 120 can include information about the selected beam 111 in the beam failure recovery request. The terminal device 120 can then transmit the beam failure request to the network device 110 such that the network device 110 communicates with the terminal device 120 via the selected beam 111 of the SCell 120.

[0073]HereinafterFigure 2 - Figure 17 The implementation of the present disclosure is described in detail.figure 2 - Figure 6 illustrates an example method implemented at a terminal device in accordance with some embodiments of the present disclosure. It should be understood that the methods shown can include additional operations not shown and / or may omit some of the operations shown, and the scope of the present disclosure is not limited thereto.

[0074]figure 2 A flowchart illustrates an example method 200 for beam failure recovery for SCELL according to some embodiments of the present disclosure. Method 200 canfigure 1 The terminal device 120 shown is implemented. In order to discuss the purpose, reference will be referencedfigure 1 Description Method 200.

[0075]At 210, the terminal device 120 determines if there is a beam failure on the SCELL. If the terminal device 120 determines the beam failure on the SCell 102, the terminal device 120 transmits the scheduled request to the network device at the 220, such as the network device 110.

[0076]The scheduling request can be a PRACH transmission on the PCELL 101 or SCELL 102. In this case, the preamble of the PRACH can be based on CFRA or a competitive random access (CBRA). Alternatively, the scheduling request may be a scheduling request (SR) transmitted on the PCELL 101's PUCCH.

[0077]At 230, the terminal device 120 receives the response of the uplink resource assigned to the terminal device 120 on the PCell (e.g., PCell 101). This response can be transmitted on the physical downlink control channel (PDCCH) of the PCell 101, and may include a downlink control information (DCI) indicating the UL authorization on the physical uplink shared channel (PUSCH). Depending on the type of scheduling request sent at 220, the response can be scrambled by different types of radio network temporary identifiers (RNTI), such as random access RNTI (RA-RNTI) or assignment determined by the PRACH transmission timing. Community RNTI (C-RNTI) of the terminal device.

[0078]At 240, the terminal device 120 transmits a beam failure recovery request to the network device 110 using the allocated resource, which includes the beam index of the new beam selected from the available beam selected from the SCell to restore the Scell. The selected beam is in communication between terminal devices and network devices. For example, the terminal device 120 can include a beam failure recovery request in the MAC CE and transmit the MAC CE using the resources allocated by the network device 110, for example, on the PUSCH.

[0079]The beam failure recovery request can include the beam index of the selected beam 111 and the SCell index of the SCELL 102. Accordingly, the structure of the MAC CE can be designed as shown in Table 1. Field "LGID" indicates that the MAC CE is used for beam failure recovery, and the field "service cell ID" indicates the SCell index with beam failure, and the field "rs ID" indicates the beam index of the new beam. Note that in the case where the scheduling request is transmitted on the SCELL 102, the SCELL index can be omitted. Although not shown, there may be reserved bits in the Mac-Ce structure to align the length of the MAC-CE information with integer bytes.

[0080]Table 1 Mac CE for BFR

[0081] LgID Service Community ID RS ID

[0082]As mentioned above, the scheduling request can be a PRACH transfer or a scheduling request on the PUCCH. HereinafterFigure 11 - Figure 13 Description This scheduling request is an embodiment of the PRACH transmission and the scheduling request is an embodiment of the scheduling request on the PUCCH.

[0083]In some embodiments, after the transmission beam failure recovery request is transmitted at 240, the terminal device 120 can monitor the beam failure recovery request response during the timing window (in this article is also referred to herein as a BFR-RA-window), in PCell 101 and SCell 102 Downlink Control Information in both PDCCH. The terminal device 120 can initiate a timer for the BFR-RA window, for example, after the transmission beam failure recovery request is transmitted at 240, and when the duration of the BFR-RA window ends, the timer expires. If the downlink control information in the PDCCH for re-scheduled the transmitted PUSCH of the beam fault recovery request included in the MAC CE is previously expired, the terminal device 120 can be to the network device 110. Resend PUSCH containing beam failure recovery requests in the Mac CE and restarts the timer for the BFR-RA window to monitor beam failure recovery request responses.

[0084]The BFR-RA window can have a predetermined duration. If the timer has expired or the BFR-RA window ends, the response to the beam failure recovery request has not been received, and the terminal device 120 can terminate the beam failure recovery process without resending the beam failure request to the network device 110. The terminal device 120 can also indicate unsuccessful beam failure recovery events to the high layer.

[0085]Alternatively, the BFR-RA window can be initiated by receiving a confirmation message from the network device 110. For example, the terminal device 120 can receive a message that explicitly confirms the reception of the PUSCH sent at 240. Thereafter, the terminal device 120 can initiate or open the BFR-RA window.

[0086]In the above embodiment, the scheduling request can be a conventional process that can be reused for other purposes, for example, a PRACH transmission and the selected PRACH preamble can be used for uplink synchronization. In some embodiments, a dedicated process such as a dedicated PRACH transmission can only be used for the purpose of beam failure, which will be related toimage 3 withFigure 4 Description.

[0087]image 3 A flowchart illustrating an example method 300 for beam failure recovery of SCELL according to some embodiments of the present disclosure. Method 300 canfigure 1 The terminal device 120 shown is implemented. In order to discuss the purpose, referencefigure 1 Description Method 300.

[0088]At 310, the terminal device 120 determines if there is a beam failure on the SCELL. If the terminal device 120 determines the beam failure on the SCELL 102, the terminal device 120 determines the PRACH preamble to be transmitted from a set of dedicated preambles at 320. The PRACH front guide index indicates the SCELL index of the SCELL 102. For example, the terminal device 120 can determine the PRACH preamble based on a predefined mapping relationship between the PRACH leading index and the network device 110. The PRACH preamble can be based on no competition.

[0089]At 330, the terminal device 120 transmits the PRACH preamble at 320 to the network device 110. For example, the terminal device 120 can transmit a dedicated PRACH transmission to the network device 110 with the PRACH before 320. The terminal device 120 can transmit a preamble on the PCELL 101 PRACH channel.

[0090]At 340, the terminal device 120 receives the downlink control information from the network device 110 on the PCell, which includes a request for the CSI report for SCELL 102. The downlink control information can be scrambled with the C-RNTI of the terminal device and received on the CoreSet-BFR, and CoreSet-BFR is a control resource set dedicated to beam failure recovery.

[0091]At 350, the terminal device 120 transmits a beam index of the beam selected from the terminal device 120 from the SCELL 102 in response to the CSI request to recover the selected beams on the SCELL 102 in the terminal device 120 and Communication between network devices 110. For example, the terminal device 120 can include the beam index of the selected beam 111 in the CSI report, and send a CSI report on the PUSCH of the PCell 101 according to the CSI request.

[0092]In such an embodiment, the SCELL index is hidden in a PRACH preamble index in the PRACH transmission, and then the beam index is explicitly included in the CSI report. Therefore, the terminal device 120 may utilize the SCELL index indicated by the PRACH preamble transmitted at 330, and the SCELL that has occurred has occurred to the network device 110, and the beam of the selected beam 111 transmitted at 350 is utilized. The index will notify the candidate beam to the network device 110.

[0093]In some embodiments, the terminal device 120 can receive a response (also referred to as a BFR response) from the network device 110 after the CSI report. The BFR responds to the link to which the SCELL based on the reported beam index is reconfigured, and can be received on the PCell 101 or on the SCELL 102.

[0094]Be relevant toimage 3 In the described embodiment, the beam failure recovery process can be used to lead by the PRACH, and the PRACH preamble is specially selected, and thus indicates index information about SCell. In this way, explicit transmission of the SCELL index can be omitted. Therefore, it is possible to reduce overhead for beam failure recovery.

[0095]Figure 4 A flowchart illustrates an example method 400 for beam failure recovery for SCELL according to some embodiments of the present disclosure. Method 400 can befigure 1 The terminal device 120 shown is implemented. In order to discuss the purpose, reference will be referencedfigure 1 Description Method 400.

[0096]At 410, the terminal device 120 determines if there is a beam failure on the SCELL. If the terminal device 120 determines the beam failure on the SCELL 102, the terminal device 120 determines at 420 to determine the PRACH preamble to be transmitted. The PRACH leading index indicates the beam index of the beam selected from the available beams selected from the SCELL 102 from the terminal device 120. For example, the terminal device 120 can determine the PRACH preamble to be transmitted based on a PRACH preamble dedicated to beam failure to restore multiple beams associated with multiple beams of SCELL 102.

[0097]At 430, the terminal device 120 transmits a PRACH preamble to the network device on SCell 102 to recover communication between terminal device 120 and network device 110 via SCELL 102. For example, the terminal device 120 can utilize a PRACH-defined patroking index at 410 to initiate a dedicated PRACH transmission to the network device on SCELL 102.

[0098]In such an embodiment, since the PRACH preamble is transmitted on the SCELL 102, the terminal device 120 may not need to send with information about the SCELL index. Since the beam index is guided by the PRACH front conducting, the terminal device 120 may not explicitly send information about the beam index. Therefore, the PRACH preamble is transmitted on the SCELL by using a dedicated PRACH process, and the terminal device 120 may notify the network device 110 only in one message.

[0099]Be relevant toFigure 4 In the described embodiment, the beam failure recovery process can utilize the PRACH transmission on the SCELL, and the PRACH preamble is specially selected, indicating information about the candidate beam. In this way, explicit transmission of the SCELL index and beam index can be omitted. Therefore, it is possible to further reduce overhead for beam failure recovery.

[0100]As mentioned above, there may be the following scenario: No PUSCH can be used for the transmission of Mac CE, so beam failure recovery requests cannot be transmitted. When the PUCCH is transmitted, the residual resource of the PUCCH can be used for beam failure recovery requests.

[0101]After receiving the data from the network device 110 on the physical downlink shared channel (PDSCH) of the PCELL 101, the terminal device 120 can transmit an uplink such as a hybrid automatic retransmission request (HARQ) ACK / NACK to the network device 110. Control Information (UCI). The PUCCH resource configured for the terminal device 120 and the PUCCH resource configured may be greater than the PUCCH resources required by UCI. Therefore, the terminal device 120 can transmit a beam failure recovery request using the remaining resources of the PUCCH, i.e., fill the beam failure request into the PUCCH.

[0102]Figure 5 A flowchart illustrates an example method 500 for beam failure recovery of SCELL according to some embodiments of the present disclosure. Method 500 canfigure 1 The terminal device 120 shown is implemented. In order to discuss the purpose, referencefigure 1 withFigure 6A-Figure 6B Description method 500.

[0103]At 510, the terminal device 120 determines if there is a beam failure on the SCELL. If the terminal device 120 determines the beam failure on the SCELL 102, the terminal device 120 determines that the resource of the PCell's uplink control channel is based on the resource of the PCell's uplink control channel and the uplink control information to be transmitted on the uplink control channel. Uplink control channel. The terminal device 120 can determine the PUCCH that the PCell 101 will be used.

[0104]ReferFigure 6A withFigure 6B It is a schematic diagram illustrating the filling of beam fault requests in the PUCCH, in accordance with some embodiments of the present disclosure. Figures 601 and 602 show long PUCCH (L-PUCCH) 610 and short PUCCH (S-PUCCH) 620. As an example, the terminal device 120 can determine the use of L-PUCCH 610 to fill the beam failure recovery request. For example, the first portion 611 of the L-PUCCH610 can be used to transmit UCI, and the second portion of the L-PUCCH 610 can be used to send beam failure recovery requests.

[0105]In some embodiments, the terminal device 120 can determine the PUCCH to be used based on the remaining resource block. The terminal device 120 can first determine the first number of physical resource blocks (PRBs) assigned to the uplink control channel. For example, the terminal device 120 can determine the number of PRBs allocated to the L-PUCCH 610 as The terminal device 120 can then determine the second number of PRBs to be used by UCI. For example, the terminal device 120 can determine the number of PRBs to be used in UCI based on the information included in the UCI. That is, the number of PRBs corresponding to the first portion 611 is Then, the third number M of the PRB that can be used to send beam fault recovery requests can be determined by the following formula.r:

[0106]

[0107]MrIndicates the number of PRBs corresponding to the second portion 612. If MrIt is determined to be equal to or greater than the number of thresholds, and the terminal device 120 can determine the L-PUCCH 610 as a channel for transmitting beam failure recovery requests. The number of thresholds can be predetermined based on the size of the beam failure recovery request.

[0108]It should be understood that other information such as CSI reports can also be sent in the uplink control channel. In this case, the PRB occupied by other information should be included in the determined Considerations. Figure 602 shows S-PUCCH 602 and its first portion 621 and the second portion 622. Terminal device 120 can determine whether to transmit beam failure recovery requests with a second portion 622 to transmit beam failure recovery requests in a similar manner described in L-PUCCH 610.

[0109]Still referring toFigure 5 At 530, the terminal device 120 transmits beam failure recovery requests along with the uplink control information on the uplink control channel. Terminal device 120 can transmit beam failure requests in the second portion 612 or 622 and transmit UCI to network device 110 in the first portion 611 or 621. The beam failure recovery request includes the SCELL index of the SCELL 102 and the beam index of the beam selected from the available beams selected from the SCELL 102. Send beam failure recovery requests to restore communication between terminal device 120 and network device 110 via the selected beam 111 on the SCELL 102.

[0110]In some embodiments, after transmitting a beam failure recovery request on the uplink control channel, the terminal device 120 can initiate a timer for monitoring the response to beam failure recovery requests, i.e., open the BFR-RA window. If the timer has expired or the BFR-RA window ends, the response to the beam fault request has not been received, and the terminal device 120 can resend the beam failure recovery request to the network device 110.

[0111]In some embodiments, the terminal device 120 can receive a new data transmission from the network device 110, which is associated with the same HARQ ID as the ACK / NACK sent at 530. In this case, the beam failure recovery request can be considered to be received by the network device 110. Therefore, the terminal device 120 can end the BFR-RA window to produce a reduced BFR-RA window.

[0112]Be relevant toFigure 5 In the described embodiment, the beam failure recovery process can utilize the remaining resources of the PUCCH that will be wasted. In this way, the transmission of beam fault requests may not require special resources. Therefore, the overhead of beam failure recovery can be further reduced while increasing the efficiency of beam failure recovery.

[0113]Figure 7 - Figure 11 The example method implemented at the network device is illustrated in accordance with some embodiments of the present disclosure. It should be understood that the methods shown can include additional operations not shown and / or may omit some of the operations shown, and the scope of the present disclosure is not limited thereto.

[0114]Figure 7 A flowchart illustrates an example method 700 for beam failure recovery for SCELL according to some embodiments of the present disclosure. Method 700 canfigure 1 The network device 110 shown in the present is implemented. In order to discuss the purpose, reference will be referencedfigure 1 Description method 700.

[0115]At 710, the network device 110 receives a scheduling request from a terminal device (eg, terminal device 120). Dependfigure 2 The scheduled request may be a PRACH transmission received on the PCell 101 or SCell 102. Alternatively, the scheduling request may be a scheduling request received on the PCCH of the PCEL1 101.

[0116]At 720, the network device 110 transmits a response to the terminal device on the primary cell (e.g., PCell 101), which is assigned to the resource of the terminal device 120. This response can include a downlink control information indicating UL authorization. Depending on the type of scheduling request sent at 220, the downlink control information is scrambled by different types of RNTI, and different types of RNTI, such as RA-RNTI determined by the PRACH transmission timing, or allocated to the terminal device C- RNTI and the like. HereinafterFigure 11 - Figure 13 Describe an embodiment in which different types of responses are transmitted.

[0117]At 730, the network device 110 receives a beam failure recovery request from the terminal device 120 using the allocated resource, including the beam index of the beam selected by the terminal device 120 from the beam selected from the SCell to via Scell ​​102. The selected beam 111 is in communication with the terminal device 120. For example, the SCell index and beam index can be included in the MAC CE received using the assigned resource (e.g., PUSCH).

[0118]After receiving a beam failure request, network device 110 can communicate with the terminal device 120 with the selected beam 111 instead of the previous beam 112 to SCell 102.

[0119]In some embodiments, network device 110 can transmit a further response to the beam failure recovery request on the SCELL 102. For example, network device 110 can transmit a response via the selected beam 111.

[0120]Figure 8 A flowchart illustrates an example method 800 for beam failure recovery for SCELL according to some embodiments of the present disclosure. Method 800 canfigure 1 The network device 110 shown in the present is implemented. In order to discuss the purpose, referencefigure 1 Description Method 800.

[0121]At 810, the network device 110 receives the PRACH preamble from the dedicated PRACH transmission of the terminal device (e.g., terminal device 120) on the PCell. The PRACH leading index indicates the SCell index of the SCell (eg, SCell 102) serving the terminal device 120.

[0122]At 820, the network device 110 determines the SCELL 102 from the PRACH preamble. For example, network device 110 can determine SCELL 102 based on a predefined mapping relationship between the PRACH preamble between providing at least one SCELL of the terminal device 120 by the network device 110.

[0123]At 830, the network device 110 transmits a downlink control information to the terminal device 120 on the PCell serving the terminal device 120, which includes a request for the CSI report for SCELL 102. The downlink control information can be scrambled with the CRNTI corresponding to the terminal device.

[0124]At 840, the network device 110 receives the beam index of the beam selected from the terminal device 120 from the available beams from the SCELL 102 from the terminal device 120. The beam index of the selected beam 111 can be included in the CSI report, the CSI report being received on the PUSCH of the PCell 101.

[0125]In such an embodiment, the SCell index of the SCELL that has occurred on it has been implicitly included in the PRACH preamble. Therefore, after receiving the beam index of the selected beam 111, the network device 110 can communicate with the terminal device 120 on the SCell 102 determined at 820 at the selected beam 111.

[0126]Figure 9 A flowchart illustrating an example method 900 for beam failure recovery for SCELL according to some embodiments of the present disclosure. Method 900 canfigure 1 The network device 110 shown in the present is implemented. In order to discuss the purpose, referencefigure 1 Description method 900.

[0127]At 910, the network device 110 receives a dedicated PRACH transmission from the terminal device on the SCell serving the terminal device. For example, network device 110 can receive a PRACH preamble on the SCell 102 serving the terminal device 120. The PRACH leading index indicates the beam index of the beam selected from the available beams from the terminal device 120 from the SCELL.

[0128]At 920, the network device 110 determines the beam index from the PRACH preamble received at 910. For example, network device 110 can determine beam index based on a predefined mapping relationship between the PRACH preamble between multiple beams associated with SCELL 102.

[0129]In such an embodiment, since the PRACH preamble is received on the SCell 102, the network device 110 can determine a beam failure on the SCELL without a dedicated information regarding the SCELL index. After determining the candidate beam (e.g., the selected beam 111) selected by the terminal device 120, the network device can communicate with the terminal device 120 via the selected beam 111 on the SCell 102. In some embodiments, network device 110 can transmit beam failure resume responses to terminal device 120 via the selected beam 111.

[0130]DependFigure 5 The described beam fault recovery request can be filled in the PCELL's PUCCH.Figure 10 A flowchart illustrating an example method 1000 for beam failure recovery of SCELL according to some embodiments of the present disclosure. Method 1000 canfigure 1 The network device 110 shown in the present is implemented. In order to discuss the purpose, referencefigure 1 withFigure 6A-Figure 6B Description method 1000.

[0131]At 1010, the network device 110 receives a beam failure recovery request with the uplink control information on the uplink control channel of the PCell serving the terminal device. For example, network device 110 can receive from terminal device 120Figure 6A The L-PUCCH 610 shown in. UCI can be included in the first portion 611, and beam failure recovery requests can be included in the second portion 612. The UCI can be associated with the data transmitted to the terminal device 120. For example, UCI can include HARQ ACK / NACK information.

[0132]At 1020, the network device 110 obtains the SCell index serving the SCell index serving the terminal device from the beam failure recovery request and the beam index of the beam selected from the terminal device from the available beams of the SCell. The network device 110 can obtain the SCell index of the SCELL 102 and the beam index of the selected beam 111. Therefore, network device 110 can determine that beam failure has occurred on SCell 102, and the terminal device 120 has selected a new beam. Then, the network device 110 can communicate with the terminal device 120 via the selected beam 111 on the SCELL 102.

[0133]As mentioned above, the scheduling request can be the PRACH preamble on the PCell or SCell, or may be a scheduling request on the PUCCH.Figure 11 - Figure 13 The process illustrating a process for beam failure for SCELL according to some embodiments of the present disclosure. Associated withFigure 11 - Figure 13 The process described can be consideredfigure 2 withFigure 7 Realization of the method described.

[0134]Figure 11 The flow diagram illustrating a process 1100 for beam failure recovery of SCELL according to some embodiments of the present disclosure. In order to discuss the purpose, referencefigure 1 Description Process 1100. Process 1100 can involvefigure 1 Network device 110 and terminal device 120.

[0135]After detecting the beam failure on the SCEL1 102, the selected beam 111 is identified, the terminal device can initiate a beam failure recovery process. In this implementation, the beam failure recovery process can be a normal random access process. The terminal device 120 transmits 1105 random access forwarding to the network device 110 on the PCell 101.

[0136]After receiving the random access preamble, the network device 110 transmits 1110 random access response (RAR) to the terminal device 120 on the PCell 101. RAR can use RA-RNTI to scramble and include downlink control information having UL authoritions to allocate uplink resources for terminal device 120.

[0137]After receiving the RAR, the terminal device 120 transmits 1115MAC CE to the network device 110 using the allocated resource (e.g., on the PUSCH). The MAC CE may include the SCell index of the SCELL 102 and the beam index of the selected beam 111. If the MAC CE is successfully received, the network device 110 sends a 1120 beam failure recovery request response to the terminal device 120.

[0138]Figure 12 It is a flowchart illustrating a process 1200 for beam failure recovery of SCELL, in accordance with some embodiments of the present disclosure. In order to discuss the purpose, referencefigure 1 Description Process 1200. Process 1200 can involvefigure 1 Network device 110 and terminal device 120.

[0139]After detecting the beam failure on the SCEL1 102, the selected beam 111 is identified, the terminal device can initiate a beam failure recovery process. In this implementation, the beam failure recovery process can be a normal random access process. The terminal device 120 transmits 1205 random access forwarding to the network device 110 on the SCELL 102.

[0140]After receiving the random access preamble, the network device 110 transmits 1210 random access response (RAR) to the terminal device 120 on the PCell 101. RAR can use RA-RNTI to scramble and include downlink control information having UL authoritions to allocate uplink resources for terminal device 120.

[0141]After receiving the RAR, the terminal device 120 transmits 1215MAC CE to the network device 110 using the allocated resource (eg, on the PUSCH). In this case, the MAC CE may include the beam index of the selected beam 111, and may omit the SCell index of the Scell ​​102. If the MAC CE is successfully received, the network device 110 transmits a 1220 beam failure recovery request response to the terminal device 120.

[0142]Figure 13 It is a flowchart illustrating a process 1300 for beam failure recovery of SCELL, in accordance with some embodiments of the present disclosure. In order to discuss the purpose, reference will be referencedfigure 1 Description Process 1300. Process 1300 can involvefigure 1 Network device 110 and terminal device 120.

[0143]After detecting the beam failure on the SCEL1 102, the selected beam 111 is identified, the terminal device can initiate a beam failure recovery process. In this implementation, the terminal device 120 can initiate an explicit process for trigger UL authorization to send beam failure recovery requests. The terminal device 120 transmits a 1305 scheduling request (SR) to the network device 110 on the uplink control channel of the PCell 101. The terminal device 120 can transmit SR on the PCCH of the PCell 101.

[0144]After receiving the SR, the network device 110 transmits 1310 to the response to the SR on the PCELL 101. The response to the SR can be scrambled by the C-RNTI assigned to the terminal device, and includes downlink control information having UL authorization to allocate uplink resources for terminal device 120.

[0145]After receiving the response to the SR, the terminal device 120 transmits 1315MAC CE to the network device 110 using the allocated resource (eg, on the PUSCH). The MAC CE may include the SCell index of the SCELL 102 and the beam index of the selected beam 111. If the MAC CE is successfully received, the network device 110 sends a 1320 beam failure recovery request response to the terminal device 120.

[0146]Figure 14 A schematic diagram 1400 illustrating a BFR-RA window for beam failure recovery in accordance with some embodiments of the present disclosure. In some embodiments, after the MAC CE is transmitted 1415 to the network device 110, the terminal device 120 can activate 1420 to monitor the response (also referred to as a BFR response) to beam fault recovery requests. That is, the terminal device 120 can turn on the BFR-RA window 1405. It should be understood that the action of sending 1415MAC CE can refer to it is related toFigure 11 1115 shown inFigure 12 1215 shown inFigure 13 The action described in 1315 shown in.

[0147]In some embodiments, the terminal device 120 can receive a 1425BFR response on SCell 102 (or on the PCell), which means that the beam fault is successfully recovered. The terminal device 120 can terminate the beam fault recovery process and can end the BFR-RA window 1405.

[0148]In some embodiments, the terminal device 120 can receive 1430 from the network device 110 about the downlink control information of the re-scheduled PUSCH (ie, the re-schedule of beam failure recovery request). Then, the terminal device 120 can resend the beam fault recovery request in the 1435MAC CE on the PUSCH to the network device 110. After retransmission, the terminal device 120 can initiate a 1440 timer. Therefore, the new BFR-RA window 1410 can be turned on. Note that as the new BFR-RA window 1410 is on, the BFR-RA window 1405 can be discarded.

[0149]If the BFR-RA window 1405 or 1410 (depending on which valid) has expired or end, the BFR response has not been received, and the terminal device 120 can terminate the beam failure recovery process without resending the beam failure recovery request. Terminal device 120 can also indicate unsuccessful beam failures to the high layer.

[0150]In this case, due to the following reasons, it is not necessary to resend beam failure recovery requests. Network device 110 may have received beam failure requests, but there is no response to this. Network device 110 may have responded on SCELL, but the selected beam 111 is not good enough, so that the terminal device 120 cannot receive the BFR response. There may be another case in which the network device 110 does not receive a MAC CE including beam failure recovery request.

[0151]As mentioned above, the scheduling request can be transmitted using a dedicated PRACH preamble.Figure 15 - Figure 16 The process illustrating a process for beam failure for SCELL according to some embodiments of the present disclosure.

[0152]Figure 15 It is a flowchart illustrating a process 1500 for beam failure recovery of SCELL according to some embodiments of the present disclosure. In order to discuss the purpose, referencefigure 1 Description Process 1500. Process 1500 can involvefigure 1 Network device 110 and terminal device 120. Process 1500 can refer to itimage 3 withFigure 8 Realization of the method described.

[0153]After detecting the beam failure on the SCEL1 102, the selected beam 111 is identified, the terminal device can initiate a beam failure recovery process. In this implementation, the beam failure recovery process can be a dedicated random access process. The terminal device 120 sends 1505 random access forwarding to the network device 110 on the PCell 101. The random access leader index indicates the SCell index of the Scell ​​102. For example, the random access preamble can be determined by the terminal device 120 based on a predefined mapping relationship between at least one SCELL provided by the network device 110 based on the random access preamble.

[0154]After receiving the random access forward, network device 110 transmits a response 1510 to the terminal device 120 on the PCell 101. Unlike normal RAR, the response can be scrambled by C-RNTI on a dedicated Coreset, and may include a downlink control information having a request for a CSI report for SCELL 102. For example, the response can include a CSI request for SCELL 102.

[0155]After receiving the response, the terminal device 120 transmits a 1515csi report to the network device 110 using the allocated resource on the PUSCH requests depending on the CSI request. The CSI report may include the beam index of the selected beam 111. Note that since the index of SCell has been indicated by a random access preamble, the SCell index of SCELL 102 can be optional.

[0156]In some embodiments, if the CSI report is successfully received, the network device 110 sends a 1520 beam failure response to the terminal device 120.

[0157]Figure 16 It is a flowchart illustrating a process 1600 for beam failure recovery of SCELL, in accordance with some embodiments of the present disclosure. In order to discuss the purpose, referencefigure 1 Description Process 1600. Process 1600 can involvefigure 1 Network device 110 and terminal device 120. Process 1600 can refer to itFigure 4 withFigure 9 Realization of the method described.

[0158]After detecting the beam failure on the SCEL1 102, the selected beam 111 is identified, the terminal device can initiate a beam failure recovery process. In this implementation, the beam failure recovery process can be another dedicated random access process. The terminal device 120 transmits 1605 random access forward guides to network device 110 on SCell 102.

[0159]The random access preamble indicates the beam index of the beam selected from the available beams of the terminal device 120 from the SCELL 102. For example, a random access front guide indicates the beam index of the selected beam 111. The random access preamble is determined by the terminal device 120 based on a predefined mapping relationship between the random access preamble and the multiple beam associated with SCell 102.

[0160]After receiving the random access preamble, the network device 110 determines the SCell that has occurred has occurred and the candidate beam selected by the terminal device 120. The network device 110 sends a 1610BFR response to the terminal device 120. In such an embodiment, only two messages between the network device 110 and the terminal device 120 are required during beam failure recovery. It can improve the efficiency of beam failure recovery.

[0161]Figure 17 It is a schematic diagram 1700 for a process 1700 for beam failure, in accordance with some embodiments of the present disclosure. In order to discuss the purpose, referencefigure 1 withFigure 6A Description Process 1700. Process 1700 can involvefigure 1 Network device 110 and terminal device 120. Process 1700 can refer toFigure 5 withFigure 10 Realization of the method described.

[0162]The network device 110 transmits 1705 downlink control information to the terminal device 120, and transmits 1715 data on the PDSCH of the PCell 101. At some time, beam failure 1710 may occur on SCELL 102. After detecting the beam failure 1710 on the SCEL1 102, the terminal device needs to transmit to the network device 110 to transmit the SCell index including the SCELL 102 and the beam failure recovery request within the beam index of the selected beam 111. At the same time, the terminal device 120 also needs to transmit UCI to network device 110. As described above, the terminal device 120 can connect beam fault recovery requests along with UCI in a PUCCH assigned to transmit UCI (such as long pucch "l-pucch" or short pUCCH "S-PUCCH", such asFigure 6A withFigure 6B Down shown). The UCI may include a HARQ ACK / NACK associated with data transmitted at 1715. Then, the terminal device 120 transmits a 1720 beam failure recovery request together with the UCI on the PCEL1 PUCCH.

[0163]In some embodiments, after transmitting 1720PUCCH, the terminal device 120 can initiate 1725 for monitoring the response (also referred to as BFR response) on beam failure recovery requests. That is, the terminal device 120 can turn on the BFR-RA window 1701.

[0164]In some embodiments, the terminal device 120 can receive a 1735BFR response on SCell 102 (or on the PCell), which means that the beam fault is successfully recovered. The terminal device 120 can terminate the beam fault recovery process and can end the BFR-RA window 1701.

[0165]If the BFR-RA window 1701 has expired or end, the BFR response has not been received, and the terminal device 120 can send beam failure recovery requests to the network device 110. AbroadFigure 14 The implementation described is different. When the BFR-RA window has expired, a re-transfer of beam failure recovery requests is required.

[0166]In some embodiments, the terminal device 120 can receive 1730 new data from the network device 110. The new data can be associated with the same HARQ ID as the HARQ ACK / NACK sent at 1720. In this case, the beam failure recovery request can be considered successfully received by the network device 110. Therefore, the terminal device 120 can terminate the BFR-RA window 1701 to produce a reduced BFR-RA window 1730.

[0167]Figure 18 It is a simplified block diagram of the device 1800 suitable for implementing the embodiment of the present disclosure. Device 1800 can be considered asfigure 1 Another example of the network device 110 or terminal device 120 shown in the mesh is implemented. Therefore, device 1800 can be implemented at network device 110 or terminal device 120 or as part of network device 110 or terminal device 120.

[0168]As shown, device 1800 includes a processor 1810 coupled to memory 1820 of processor 1810, coupled to a suitable transmitter (TX) and receiver (RX) 1840 coupled to the processor 1810, and coupled to TX / RX 1840 Communication Interface. The memory 1810 stores at least a portion of the program 1830. TX / RX 1840 is used for two-way communication. TX / RX 1840 has at least one antenna to facilitate communication, but the access node mentioned in this application may have several antennas in practice in practice. The communication interface can represent any interface required to communicate with other network components, such as a two-way communication between the eNB, for the mobility management entity (MME) / service gateway (S-GW) and the eNB The S1 interface of the communication, the UN interface for the communication between the eNB and the relay node (RN) or the UU interface for communication between the eNB and the terminal device.

[0169]It is assumed that the program 1830 includes a program instruction that allows the device 1800 to operate according to the embodiment of the present disclosure, as in the present disclosureFigures 2 to 5 withFigure 7 to 10 The discussion is discussed. Embodiments of this paper may be implemented by computer software executed by processor 1810 of device 1800, or by hardware, or a combination of software and hardware. Processor 1810 can be configured to implement various embodiments of the present disclosure. Further, the combination of processor 1810 and memory 1810 can form a processing member 1850 adapted to implement various embodiments of the present disclosure.

[0170]Memory 1810 can be any type suitable for a local technical network, and any suitable data storage technique can be used, as a non-limiting example, such as a non-temporary computer readable storage medium, a semiconductor-based memory device, magnetic memory device And systems, optical memory devices and systems, fixed memory, and removable memory. Although only one memory 1810 is shown in device 1800, there may be several physically different memory modules in device 1800. Processor 1810 can be any type suitable for the local technology network, and as a non-limiting example, can include a general purpose computer, a dedicated computer, a microprocessor, a digital signal processor (DSP), and a processor based on multi-core processor architecture. One or more. The device 1800 can have a plurality of processors, such as a dedicated integrated circuit chip that is from the clock synchronized with the main processor in time.

[0171]Typically, various embodiments of the present disclosure can be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be performed by a controller, microprocessor or other computing device. Although various aspects of the embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts or use some other graphical representations, it will be appreciated that as non-limiting examples, the frames, devices, systems, systems, techniques, or techniques described herein Methods can be implemented in hardware, software, firmware, dedicated circuitry, or logic, universal hardware or controller or other computing devices or some combination thereof.

[0172]The present disclosure also provides at least one computer program product stored on a non-transitory computer readable storage medium. The computer program product includes a computer executable instruction, such as those included in the program module, which execute instructions executed in the devices on the target real or virtual processor to perform the above reference.Figure 2- Figure 5 withFigure 7 - Figure 10Any one of the processes or methods described. Typically, the program module includes routines, programs, libraries, objects, classes, components, data structures, and the like to perform specific tasks or implement specific abstract data types. In various embodiments, the function of the program module can be combined or segmented between the program module as desired. Machine executable instructions for program modules can be performed in a local device or distributed device. In a distributed device, the program module can be located in the local and remote storage media.

[0173]The program code for performing the method of the present disclosure can be written in any combination of one or more programming languages. These program code can be supplied to a processor or controller of a general purpose computer, a dedicated computer, or another programmable data processing device such that the program code is specified in the flowchart and / or block diagram when executed by the processor or controller. Functions / operations are implemented. The program code can be executed completely on the computer, and the part is executed on the computer, as a stand-alone package is executed, and the part is performed on the computer and is executed on a remote computer, or execute on a remote computer or server.

[0174]The above program code can be embodied on the machine readable medium, which may be any tangible medium that can include or store the programs used or combined with the device or device therebetween. The machine readable medium can be a machine readable signal medium or a machine readable storage medium. Machine readable media can include, but are not limited to, electrical, magnetic, light, electromagnetic, infrared or semiconductor systems, devices or devices, or any suitable combination of the foregoing. More specific examples of machine readable storage media will include electrical connection, portable computer floppy disk, hard disk, random access memory (RAM), read-only memory (ROM), wiped read-only memory (EPROM or flash), fiber, portable optical disk read only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above.

[0175]Moreover, despite the operation in a specific order, this should not be understood as required to perform such operations in a particular order shown or in a continuous order, or perform all illustrated operations to achieve desired results. In some scenarios, multitasking and parallel processing may be advantageous. Also, although several specific implementation details are included in the discussion above, these should not be construed as limiting the scope of the present disclosure, and should be construed as a description that may be specific to the particular embodiments. Some features described in the context of separate embodiments may also be implemented in a single embodiment. In contrast, various features described in the context of a single embodiment may also be implemented in a plurality of embodiments or in any suitable sub-combination, respectively.

[0176]Although the present disclosure has been described in terms of structural features and / or method actions, it is understood that the disclosure of the appended claims is not necessarily limited to the specific features or operations described above. Instead, the above specific features and operations are disclosed as an example form of implementing the claims.