CN116887320A - Apparatus and method for beam fault detection in new air interface - Google Patents

Abstract

The present application relates generally to an apparatus and method for beam fault detection in a new air interface. An apparatus of a User Equipment (UE) is disclosed, comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface. The one or more processors are configured to: identifying signals received from the gNB via the RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after detecting the beam fault, sending a beam fault recovery request to the gNB; identifying a beam fault response signal received from the gNB; and performing beam fault detection on a beam fault recovery control resource set (CORESET-BFR) while the UE is listening for the beam fault response signal until a Physical Downlink Control Channel (PDCCH) Transmission Configuration Indicator (TCI) is reconfigured. Other embodiments may be described and claimed.

Description

Apparatus and method for beam fault detection in new air interface

The application is a divisional application of an application patent application with the application date of 2019, 3 month and 26 days, the application number of 201910232395.0 and the name of 'equipment and method for detecting beam faults in a new air interface'.

Priority claim

The present application claims the benefit of priority from PCT application serial No. PCT/CN2018/080636 entitled "candwidth PART SWITCHING DURINGBEAM FAILURE RECOVERY" filed on 3/27 of 2018 and PCT application serial No. PCT/CN2018/081938 entitled "A METHOD FOR BEAM FAILURE DETECTION IN NEW RADIO" filed on 4/4 of 2018, both of which are incorporated herein by reference in their entireties.

Technical Field

Various embodiments herein relate generally to the field of wireless communications, and more particularly, to an apparatus and method for beam fault detection in a new air interface (NR).

Background

As the demand for capacity in mobile broadband communications increases dramatically each year, wireless communication systems are improving their ability to handle mobile services. In next generation systems such as fifth generation (5G) technology, advanced communications (e.g., millimeter wave (mm-wave) communications) with potentially gigabit per second data rates are candidate technologies for increasing the overall capacity and transmission speed. Highly directional beamforming antennas are required at both the Base Station (BS) and the User Equipment (UE) to compensate for the high attenuation in the mm-wave band and to extend its transmission range.

Misalignment between the Transmit (TX) beam and the Receive (RX) beam may result in significant loss of receive power, especially for systems with narrow beams, and in beam failure. To avoid such beam faults, detection, reporting and recovery mechanisms have been employed to detect, report and recover from faults. However, if the UE is configured with a set of Reference Signals (RSs) for Beam fault Detection and declares a Beam fault event, the configuration provided by the parameters Beam-fault-Detection-RS-resource control may no longer be valid. Furthermore, if the monitored beams for beam failure detection change, those beams no longer serve the UE. Another problem is that when a bandwidth portion (BWP) in which a Beam Fault Recovery (BFR) procedure is performed is changed, the UE cannot measure the RS in the inactive BWP. Accordingly, there is a need for improved beam fault detection methods for use in NR. There is also a need for improved methods for bandwidth part switching during beam fault recovery.

Disclosure of Invention

According to an aspect of the present disclosure, there is provided an apparatus of a user equipment UE, including: a radio frequency, RF, interface; and one or more processors coupled to the RF interface and configured to: identifying signals received from a base station via the RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after the beam fault is detected, a beam fault recovery request is sent to the base station; identifying a beam fault response signal received from the base station; and continuing to monitor a control resource set for beam fault recovery, CORESET-BFR, until the physical downlink control channel, PDCCH, transmission configuration indicator, TCI, is reconfigured when the beam fault response signal is received.

According to another aspect of the present disclosure, there is provided a computer-readable storage medium having stored thereon instructions that, when executed by a processor of a user equipment, UE, cause the processor to: identifying signals received from a base station via an RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after detecting the beam fault, sending a beam fault recovery request to the base station; identifying a beam fault response signal received from the base station; and continuing to monitor a group of periodic channel state information reference signals (CSI-RS) or Synchronizing Signals (SS)/Physical Broadcast Channels (PBCH) blocks which are spatially quasi-co-located with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) and a QCL when the beam fault response signal is received.

According to another aspect of the present disclosure, there is provided an apparatus of a user equipment UE, including: a radio frequency, RF, interface; and one or more processors coupled to the RF interface and configured to: initiating a beam fault recovery BFR process; identifying signals received from a base station via the RF interface; determining a beam fault detection parameter based on the received signal; initiating beam fault detection BFD based on the beam fault detection parameters; and switching the bandwidth portion BWP from the first BWP to the second BWP, wherein the switching of BWP occurs during the BFR procedure.

According to another aspect of the present disclosure, there is provided a method for a user equipment, UE, comprising: identifying a signal received from a base station; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after the beam fault is detected, a beam fault recovery request is sent to the base station; identifying a beam fault response signal received from the base station; and continuing to monitor a control resource set for beam fault recovery, CORESET-BFR, until the physical downlink control channel, PDCCH, transmission configuration indicator, TCI, is reconfigured when the beam fault response signal is received.

According to another aspect of the present disclosure, there is provided a method of a user equipment UE, including: initiating a beam fault recovery BFR process; identifying a signal received from a base station; determining a beam fault detection parameter based on the received signal; initiating beam fault detection BFD based on the beam fault detection parameters; and switching the bandwidth portion BWP from the first BWP to the second BWP, wherein the switching of BWP occurs during the BFR procedure.

According to another aspect of the present disclosure, there is provided a readable storage medium having stored thereon a computer program comprising instructions which, when executed by a processor of a user equipment UE, cause the processor to perform the process of the method as described above.

Drawings

Features and advantages of the present disclosure will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, the features of the disclosure; and, wherein:

fig. 1 is a diagram illustrating example beam fault detection on a control resource set for beam fault recovery (CORESET-BFR) in accordance with some embodiments.

Fig. 2 depicts an example method for implementing beam fault detection in a User Equipment (UE) in accordance with some embodiments.

Fig. 3 is a diagram illustrating example beam fault detection in the case of a bandwidth part (BWP) switch, according to some embodiments.

Fig. 4 is a diagram illustrating an example of BWP handover after a UE announces a beam failure event, according to some embodiments.

Fig. 5 is a diagram illustrating an example of BWP handover after a UE receives a beam failure response, according to some embodiments.

Fig. 6 illustrates an architecture of a system of a network in accordance with some embodiments.

FIG. 7 illustrates example components of a device according to some embodiments.

Fig. 8 illustrates an example interface of baseband circuitry according to some embodiments.

Fig. 9 is an illustration of a control plane protocol stack in accordance with some embodiments.

Fig. 10 is an illustration of a user plane protocol stack in accordance with some embodiments.

Fig. 11 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended.

Detailed Description

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of the claimed embodiments. However, it will be apparent to one having ordinary skill in the art having had the benefit of the present disclosure that the various aspects of the embodiments claimed may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the embodiments of the present disclosure with unnecessary detail.

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternative embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. It will be apparent, however, to one skilled in the art that alternative embodiments may be practiced without these specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

Furthermore, various operations will be described as multiple discrete operations in turn, in a manner that is most helpful in understanding the illustrative embodiments. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrases "in various embodiments," "in some embodiments," and the like are repeated. The phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrase "a or B" means (a), (B) or (a and B).

Example embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel, concurrently or concurrently. In addition, the order of the operations may be rearranged. The process may terminate when its operations are completed, but may also have additional operations not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like. When a process corresponds to a function, its termination may correspond to the function returning to the calling function and/or the main function.

As used herein, the term "processor" refers to, be part of, or include the following circuitry: capable of sequentially and automatically performing a series of arithmetic or logical operations; digital data is recorded, stored, and/or transmitted. The term "processor" may refer to one or more application processors, one or more baseband processors, a physical Central Processing Unit (CPU), a single core processor, a dual core processor, a tri-core processor, a quad-core processor, and/or any other device capable of executing or operating on computer-executable instructions (e.g., program code, software modules, and/or functional processing). As used herein, the term "interface" refers to, is part of or includes the following circuitry: providing for the exchange of information between two or more components or devices. The term "interface" may refer to one or more hardware interfaces (e.g., a bus, input/output (I/O) interfaces, peripheral component interfaces, etc.).

Beam management

In an NR implementation, beam management may refer to a set of L1/L2 procedures for acquiring and maintaining a set of transmission/reception points (TRP) and/or User Equipment (UE) beams that can be used for Downlink (DL) and Uplink (UL) transmission/reception, which may include: beam determination, which may refer to TRP or the ability of a UE to select its own transmit (Tx)/receive (Rx) beam; beam measurement, which may refer to the ability of a transmission/reception point (TRP) or UE to measure characteristics of a received beamformed signal; beam reporting, which may refer to the ability of the UE to report information of the beamformed signals based on beam measurements; and beam scanning, which may refer to the operation of covering a spatial region with beams transmitted and/or received during a time interval in a predetermined manner.

The Tx/Rx beam correspondence at TRP holds if at least one of the following conditions is satisfied: the TRP can determine a TRP Rx beam for uplink reception based on downlink measurements of one or more Tx beams of the TRP by the UE; and the TRP can determine a TRP Tx beam for downlink transmission based on uplink measurements of the TRP on one or more Rx beams of the TRP. Tx/Rx beam correspondence at the UE holds if at least one of the following is satisfied: the UE can determine a UE Tx beam for uplink transmission based on downlink measurements of one or more Rx beams of the UE by the UE; the UE can determine a UE Rx beam for downlink reception from an indication of TRP based on uplink measurements on one or more Tx beams of the UE; and supporting capability indication of the UE beam correspondence related information to the TRP.

In some implementations, DL beam management may include procedures P-1, P-2, and P-3. The procedure P-1 may be used to enable the UE to measure different TRP Tx beams to support selection of TRP Tx beams/UE Rx beams. For beamforming at the TRP, process P-1 typically includes intra-TRP/inter-TRP Tx beam scanning from a set of different beams. For beamforming at the UE, procedure P-1 typically includes UE Rx beam scanning from a set of different beams.

The procedure P-2 may be used to enable the UE to make UE measurements on different TRP Tx beams, possibly changing the inter TRP/intra TRP Tx beams. Process P-2 may be a special case of process P-1, where process P-2 may be used for a potentially smaller set of beams than process P-1 for beam refinement. In case the UE uses beamforming, procedure P-3 may be used to enable the UE to measure the same TRP Tx beam to change the UE Rx beam. Procedures P-1, P-2, and P-3 may be used for aperiodic beam reporting.

The RS-based UE measurements (at least CSI-RS) for beam management consist of K beams (where K is the total number of configured beams) and the UE may report the measurements of the N selected Tx beams (where N may or may not be a fixed number). RS-based procedures for mobility purposes are not excluded. If N < K, the beam information to be reported may include the measured amounts of the N beams and information indicating the N DL Tx beams. Other information or data may be included in or with the beam information. When the UE is configured with K '>1 non-zero power (NZP) CSI-RS resources, the UE may report N' CSI-RS resource indicators (CRI).

In some NR implementations, the UE may trigger mechanisms for detecting, reporting, and recovering from beam faults, which may be referred to as a "beam fault recovery procedure," or the like. A beam failure event may occur when the quality of the beam-to-link of the associated control channel drops below a threshold, when an associated timer times out, etc. The beam restoration mechanism may be triggered when a beam failure occurs. The network may illustratively configure the UE with resources for UL transmission signals for recovery purposes. Configuration of resources is supported where a base station (e.g., TRP, gNB, etc.) is listening from all or part of the direction (e.g., random access area). UL transmissions/resources for reporting beam faults may be located in the same time instance as the Physical Random Access Channel (PRACH) or resources orthogonal to PRACH resources, or at a different (UE configurable) time instance from the PRACH. Transmission of DL signals is supported to allow the UE to listen to the beam for identifying new potential beams.

For beam failure recovery, if all serving PDCCH beams fail, a beam failure may be declared. When a beam failure is declared, a beam failure recovery request procedure may be initiated. For example, a beam fault recovery request procedure may be used to indicate a new Synchronization Signal (SS)/PBCH block or channel state information reference signal (CSI-RS) to a serving gNB (or TRP) when a beam fault is detected on the serving SS/PBCH block/CSI-RS. Beam faults may be detected by lower layers and indicated to a Medium Access Control (MAC) entity of the UE.

In some implementations, beam management may include providing or not providing beam related indications. When providing the beam-related indication, information related to a UE-side beamforming/receiving procedure for CSI-RS based measurement may be indicated to the UE through quasi-co-location (QCL). The same or different beams on the control channel may be supported, as well as corresponding data channel transmissions.

The Downlink (DL) beam indication may be based on a Transmission Configuration Indication (TCI) state. The TCI status may be indicated in a TCI list configured by Radio Resource Control (RRC) and/or Medium Access Control (MAC) Control Elements (CEs). In some implementations, the UE may configure up to M TCI states through higher layer signaling to decode PDSCH from detected PDCCH with Downlink Control Information (DCI) for the UE and a given serving cell, where M depends on UE capability. Each configured TCI state includes a Reference Signal (RS) set TCI-RS-SetConfig. Each TCI-RS-SetConfig may include parameters for configuring a quasi co-location relationship between RSs in the RS set and a demodulation reference signal (DM-RS) port group of the PDSCH. The RS set may include an associated quasi-co-location Type (QCL Type) for each DL RS configured by one or two DL RSs, and by a higher layer parameter QCL-Type. The QCL type may be different for the case of two DL RSs, whether the references are for the same DL RS or different DL RSs. The quasi-co-location Type indicated to the UE is based on the higher layer parameter QCL-Type and may take one or a combination of the following types: QCL-type a: { Doppler shift, doppler spread, average delay, delay spread }; QCL-TypeB: { Doppler shift, doppler spread }; QCL-TypeC: { average delay, doppler shift }; QCL-TypeD: { spatial Rx parameters }.

The UE may receive a selection command (e.g., in a MAC CE) that may be used to map up to 8 TCI states to the code points of the DCI field TCI states. Until the UE receives a higher layer configuration of the TCI state and before receiving the activation command, the UE may assume that the antenna ports of one DM-RS port group of the PDSCH of the serving cell are spatially quasi co-located with the SSB determined during the initial access. When the number of TCI states in the TCI states is less than or equal to 8, the DCI field TCI state directly indicates the TCI state.

The beam-fault recovery request may be communicated over a dedicated PRACH or Physical Uplink Control Channel (PUCCH) resource. For example, a UE may be configured with a set (q ₀ ) Periodic CSI-RS resource configuration index and is configured with higher layer parameters Candidate-Beam-RS-List in a set (q ₁ ) CSI-RS resource configuration index and/or SS/PBCH block index for radio link quality measurements on the serving cell. If no configuration is present, beam fault detection may be based on a CSI-RS or SSB that is spatially quasi co-located (QCLed) with a PDCCH demodulation reference signal (DMRS). For example, if the UE is not provided with the higher layer parameters Beam-Failure-Detection-RS-resource control, the UE may determine The SS/PBCH block and periodic CSI-RS configuration are configured with the same value including the higher layer parameter TCI-states PDCCH as the value of the control resource set (CORESET) the UE is configured to monitor the PDCCH.

The physical layer of the UE may be based on a set ofResource allocation is for threshold Q _out,LR To evaluate radio chainsRoad quality. Threshold value Q _out,LR Corresponding to default values for the higher layer parameters RLM-IS-OOS-threshold config and Beam-failure-cure-Beam-threshold, respectively. For the set +.>The UE may evaluate the radio link quality based only on the periodic CSI-RS resource configuration or SS/PBCH blocks co-located with the DM-RS level received by the PDCCH on which the UE listens. The UE configures Q _in,LR The threshold is applied to the periodic CSI-RS resource configuration. After scaling the SS/PBCH block transmission power with the value provided by the higher layer parameter pc_ss, the UE will Q _out,LR The threshold is at SS/PBCH blocks.

In some implementations, if the MAC entity has received a beam failure indication from a lower layer, the MAC entity may start a beam failure recovery timer (beamfailurerecovery timer) and initiate a random access procedure. If the beamfailurerecovery timer expires, the MAC entity may indicate to the upper layer that the beam-failure recovery request failed. If a downlink assignment or uplink grant is received (e.g., on a PDCCH addressed to a cell radio network temporary identifier (C-RNTI)), the MAC entity may stop and reset the beamfailurerecovery timer and consider the beam failure recovery request procedure to be successfully completed.

Beam fault detection

As described above, in legacy implementations, beam fault Detection may be based on a set of configured periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks provided by the parameter Beam-fault-Detection-RS-resource econfig. If not configured, a User Equipment (UE) may perform beam fault detection on a periodic CSI-RS or SS/PBCH block spatially quasi co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS). However, if the UE is configured with a set of RSs for Beam fault Detection and a Beam fault event is declared, the configuration provided by the parameter Beam-fault-Detection-RS-resource control may no longer be valid. According to legacy implementations, the UE will continue to perform Beam fault Detection on the original set of resources configured by the parameter Beam-Failure-Detection-RS-ResourceConfig. Therefore, such beam fault detection would be almost meaningless. According to the techniques disclosed herein, after the UE sends a beam fault recovery request, the UE may perform beam fault detection on the CORESET-BFR because the UE may typically need to monitor the set of control resources for beam fault recovery (CORESET-BFR) to obtain the gNB response.

Fig. 1 is a diagram illustrating example beam fault detection on a control resource set for beam fault recovery (CORESET-BFR) in accordance with some embodiments. As shown in fig. 1, a UE may initiate a beam fault detection procedure and may announce a beam fault event at time t 1. At time t2, the UE may send a beam fault recovery request to the gNB. At this point, the configuration provided by the parameter Beam-Failure-Detection-RS-resource control may no longer be valid because of the declared Beam Failure event. Then, the UE may need to monitor CORESET-BFR to obtain the gNB response. At time t3, the UE may receive a response to the beam failure recovery request from the gNB. In some embodiments, after receiving the gNB response to the beam fault recovery request, the UE may perform beam fault detection on the CORESET-BFR until a predefined condition is met. For example, the UE may perform beam failure detection on CORESET-BFR until the Physical Downlink Control Channel (PDCCH) Transmission Configuration Indicator (TCI) is reconfigured at time t 4. In other embodiments, after receiving the gNB response to the beam-fault-recovery request, the UE may listen to a set of periodic channel state information reference signal (CSI-RS) or Synchronization Signal (SS)/Physical Broadcast Channel (PBCH) blocks spatially quasi-co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) to detect the beam fault until a predefined condition is met. For example, the UE may listen to a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks that are spatially quasi co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) to detect a beam failure until a set of resources for beam failure detection is reconfigured.

In some embodiments, beam fault detection may not be performed while the UE is listening to CORESET-BFR.

In some embodiments, when performing beam fault detection, if a beam fault instance is detected, the UE may need to send an indication to the Medium Access Control (MAC) layer. If the counter for the beam fault instance reaches a threshold, a beam fault recovery request may be triggered. However, if the monitored resources (or beams, or CORESET) for beam fault detection change, or the number of monitored resources (or beams, or CORESET) for beam fault detection changes, the beam associated with the resource on which the monitored beam fault detection is being performed no longer serves the UE. For example, the original transmit (Tx) beams that are listening may be a and B, and the gNB may configure the UE to switch to listening Tx beam C. In some embodiments, the UE may send an indication to the MAC layer to reset the beam fault detection counter. The bfi_counter and the beamfailuredetection timer may be reset if the MAC layer in the UE receives an indication to reset the beam failure detection COUNTER from the Physical (PHY) layer.

Fig. 2 depicts an example method 200 for implementing beam fault detection in a User Equipment (UE) in accordance with some embodiments. As shown in fig. 2, method 200 may include: the signal received from the gNB is identified at 202. In an example, the signal may be received via, for example, an RF interface. The method 200 may further include: beam fault detection parameters are determined at 204 based on the received signals. In some embodiments, the beam fault detection parameters may include a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection. In some embodiments, the UE may be configured based on the beam fault detection parameters.

The method 200 may further include: a set of resources associated with the beam fault detection parameters are monitored at 206 to detect a beam fault. If the UE announces a beam fault event, the method 200 may include: a beam fault recovery request is sent to the gNB at 208. The UE may then identify a beam fault response signal received from the gNB. In some embodiments, the method 200 may further comprise: after receiving the beam fault response signal and while the UE is listening to a beam fault recovery control resource set (CORESET) (CORESET-BFR), beam fault detection is performed on CORESET-BFR until a Physical Downlink Control Channel (PDCCH) Transmission Configuration Indicator (TCI) is reconfigured. In other embodiments, the method 200 may further include: a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks spatially quasi co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) are monitored to detect a beam failure before a beam failure response signal is received and until a set of resources for beam failure detection are reconfigured. In other embodiments, the method 200 may further include: beam fault detection may not be performed while the UE is listening to CORESET-BFR.

At 210, the method 200 may further include: determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and transmitting an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER based on the determined change. In an example, if the monitored resources associated with the beam fault detection parameters change, or the number of the monitored resources associated with the beam fault detection parameters change, the beam fault detection counter may be reset. In another example, if the monitored CORESET changes, or the number of monitored CORESETs changes, the beam fault detection counter may be reset.

bWP switching during beam fault detection

As described above, beam fault detection may be based on Physical Downlink Control Channel (PDCCH) detection in the active bandwidth part (BWP). After a certain number (N) of consecutive beam fault instances are detected, a beam fault event will be declared. However, if BWP changes before N consecutive beam failure instances are detected, the UE may need to decide whether to reset the beam failure detection counter because the UE cannot measure Reference Signals (RSs) in the inactive BWP. Fig. 3 is a diagram illustrating example beam fault detection under bandwidth part (BWP) handoff in accordance with some embodiments. In these embodiments, it may be assumed that N is greater than 4.

As shown in fig. 3, the UE may operate in a bandwidth part (BWP) (e.g., bwp#1). At time t1, the UE may detect a third beam failure instance in bwp#1. Then, at time t2, the UE may detect another beam failure instance, i.e. a fourth beam failure instance. Since the total number of detected beam fault instances is less than N, the UE will not announce a beam fault event. However, at time t3, the UE may switch to another BWP, e.g., bwp#2. Since the count in the beam fault detection counter was previously for BWP #1, the UE may need to decide whether to reset the beam fault detection counter. In some embodiments, the beam fault detection counter may be reset if the UE switches to another BWP. In this case, the physical layer may transmit an indication regarding BWP handover to an upper layer (i.e., MAC layer) so that the MAC layer may reset the counter for beam fault detection. As a result, the beam fault detection counter may be reset and the UE may detect the first and second beam fault instances in bwp#2 as shown at times t4 and t5, respectively.

In other embodiments, if the reference signal for beam fault detection in the new BWP (e.g., bwp#2) and the beam fault detection reference signal for the old BWP (e.g., bwp#1) are spatially one-to-one or many-to-one or one-to-many common bit (QCL), the MAC layer in the UE may continue to use the counter for beam fault detection. For example, if the CORSET in the old BWP and the new BWP share the same Transmission Configuration Indication (TCI) in one Component Carrier (CC), the MAC layer in the UE may continue to use the counter for beam fault detection.

Which CORESETs in the new and old BWP are QCL, which may be configured or predefined by higher layers via Radio Resource Control (RRC) signaling. For example, CORESET having the same ID in both old and new BWP may be QCL.

bWP handoff after a UE declares a beam failure event

In some cases, it may be that a BWP handover occurs after the UE announces a beam failure event. Fig. 4 is a diagram illustrating an example of BWP handover after a UE declares a beam failure event, according to some embodiments.

As shown in fig. 4, the UE may operate in a bandwidth part (BWP) (e.g., bwp#1). At time t1, the UE may detect the N-1 th beam failure instance in bwp#1. Then, at time t2, the UE may detect another beam failure instance, i.e., the nth beam failure instance. Since the total number of detected beam fault instances reaches the threshold N, the UE may announce a beam fault event. Thereafter, the UE will transmit a beam failure recovery request in BWP #1 at time t 4. However, at time t3 before time t4, the UE may switch to another BWP, e.g., bwp#2. Since the announcement of the beam fault event was previously for BWP #1, the UE may need to decide whether or not to send a beam fault recovery request. In some embodiments, if the UE switches to another BWP, the UE may restart the beam fault detection procedure in the new BWP (e.g., BWP # 2) after the BWP switch. In other embodiments, if the reference signal sets for beam fault detection in two BWP are spatially one-to-one QCL, the UE may transmit a beam fault recovery request in a new BWP (e.g., BWP # 2) after BWP handover. The PHY layer may provide the { SSBRI/CRI index, L1-RSRP } measured from the new BWP to the MAC for new beam identification.

bWP handoff after receiving beam failure response by UE

In some cases, it may be that BWP handover occurs after the UE receives the beam failure response. Fig. 5 is a diagram illustrating an example of BWP handover after a UE receives a beam failure response, according to some embodiments.

As shown in fig. 5, the UE may operate in a bandwidth part (BWP) (e.g., bwp#1). The UE may detect a beam failure in BWP #1 and announce a beam failure event accordingly. Then, at time t1, the UE may transmit a Beam Fault Recovery (BFR) request in bwp#1. At time t2, the UE may receive a Response to the BFR request from the gNB in a dedicated Beam-failure-Recovery-Response-core configured control resource set for Beam failure Recovery (core-BFR) of the higher layer parameters. Thereafter, the UE may only listen to CORESET-BFR from time t4 until the other CORESETs are reconfigured. However, at time t3 before time t4, the UE may switch to another BWP, e.g., bwp#2. Thus, the UE may need to decide which CORESET-BFRs should be listened to. In some embodiments, the UE may assume that this new CORESET-BFR in bwp#2 is QCL spatially with the beam identified during beam failure recovery. Thus, the UE may only listen to CORESET-BFR in the new BWP (e.g., bwp#2) after the BWP handover. In other embodiments, if there is no spatial QCL between the corets in the two BWP (e.g., bwp#1 and bwp#2), the UE may listen for all CORESETs in the new BWP (e.g., bwp#2), which CORESET-BFR may not be included. Thus, the beam fault recovery process can be considered to restart. Alternatively, the UE may restart the beam failure recovery procedure after BWP handover, regardless of whether CORESET in both BWPs is QCL or not.

In some embodiments, the UE may expect not to switch to another BWP after receiving the beam fault response in CORESET-BFR before reconfiguring CORESET.

CORESET-BFR configuration

The spatial QCL between CORESETs in different BWP may help determine whether the UE should restart the BFR procedure. In one embodiment, one CORESET in one BWP may be configured via Radio Resource Control (RRC) signaling to be spatially QCL with CORESET in another configured BWP. In another embodiment, such cross BWP QCL signaling for CORESET via higher layers is only for CORESET-BFR.

Further, after the UE sends the Beam fault Recovery request, the UE may listen to the dedicated CORESET to obtain the gNB Response to the Beam fault Recovery request, which is configured by the parameter Beam-fault-Recovery-Response-CORESET. The dedicated CORESET may be configured in BWP in consideration of a plurality of BWP operations, otherwise if BWP handover occurs, the UE cannot receive the gNB response. In an embodiment, a dedicated CORESET for the gNB response to the beam fault recovery request may be configured in BWP. If a dedicated CORESET for BFR is not configured for BWP, the UE may not perform beam fault detection or beam fault recovery when switching to the BWP. Alternatively, when the UE expects to listen for the gNB response after transmitting the Beam-failure-recovery request within a window configured by higher layer parameters Beam-failure-request-window, the UE may not expect DCI indicating BWP handover or perform autonomous timer-based BWP handover.

After the UE receives the beam fault recovery response in CORESET-BFR, it may begin listening only to the CORESET until RRC reconfiguration or beam indication is received through the MAC Control Element (CE) of the other CORESET. Thus, during this period, when the scheduling offset is below the threshold, the UE may assume that PDSCH and CORESET-BFR are QCL spatially.

Fig. 6 illustrates an architecture of a system 600 of a network in accordance with some embodiments. System 600 is shown to include a User Equipment (UE) 601 and a UE 602. UEs 601 and 602 are shown as smart phones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a Personal Data Assistant (PDA), pager, laptop computer, desktop computer, wireless handheld device, or any computing device that includes a wireless communication interface.

In some embodiments, either of UEs 601 and 602 may include an internet of things (IoT) UE, which may include a network access layer designed for low power IoT applications that utilize short term UE connections. IoT UEs may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with MTC servers or devices via Public Land Mobile Network (PLMN), proximity services (ProSe), or device-to-device (D2D) communications, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. IoT networks describe interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connectivity. The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

UEs 601 and 602 may be configured to connect (e.g., communicatively couple) with a Radio Access Network (RAN) 610—ran 610 may be, for example, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), a NextGen RAN (NG RAN), or other type of RAN. UEs 601 and 602 utilize connections 603 and 604, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connections 603 and 604 are shown as air interfaces for implementing communicative coupling, and may conform to cellular communication protocols, such as global system for mobile communications (GSM) protocols, code Division Multiple Access (CDMA) network protocols, push-to-talk (PTT) protocols, PTT Over Cellular (POC) protocols, universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, fifth generation (5G) protocols, new air interface (NR) protocols, and so forth.

In this embodiment, the UEs 601 and 602 may also exchange communication data directly via the ProSe interface 605. ProSe interface 605 may alternatively be referred to as a side link interface, which includes one or more logical channels including, but not limited to, a physical side link control channel (PSCCH), a physical side link shared channel (PSSCH), a physical side link discovery channel (PSDCH), and a physical side link broadcast channel (PSBCH).

UE 602 is shown configured to access an Access Point (AP) 606 via connection 607. Connection 607 may comprise a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, where AP 606 would include wireless fidelityAnd a router. In this example, the AP 606 is shown connected to the internet and not to the core network of the wireless system (described in further detail below).

RAN 610 may include one or more access nodes that enable connections 603 and 604. These Access Nodes (ANs) may be referred to as Base Stations (BS), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., cell). RAN 610 may include one or more RAN nodes (e.g., macro RAN node 611) for providing macro cells and one or more RAN nodes (e.g., low Power (LP) RAN node 612) for providing femto cells or pico cells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth than macro cells).

Either of the RAN nodes 611 and 612 may terminate the air interface protocol and may be the first point of contact for the UEs 601 and 602. In some embodiments, either of RAN nodes 611 and 612 may perform various logical functions of RAN 610, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling, as well as mobility management.

According to some embodiments, UEs 601 and 602 may be configured to: according to various communication techniques, such as, but not limited to, orthogonal Frequency Division Multiple Access (OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or side-chain communications), orthogonal Frequency Division Multiplexing (OFDM) communication signals are used to communicate with each other or with any of RAN nodes 611 and 612 over a multicarrier communication channel, although the scope of the embodiments is not limited in this respect.

In some embodiments, the downlink resource grid may be used for downlink transmissions from either of the RAN nodes 611 and 612 to the UEs 601 and 602, while the uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resource in each time slot in the downlink. This time-frequency plane representation is a common practice for OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in the radio frame. The smallest time-frequency unit in a resource grid is called a resource element. Each resource grid includes a plurality of resource blocks that describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

A Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to UEs 601 and 602. The Physical Downlink Control Channel (PDCCH) may carry information on a transport format and resource allocation related to the PDSCH channel, etc. It may also inform UEs 601 and 602 of transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (assignment of control channel resource blocks and shared channel resource blocks to UEs 601 and 602 within a cell) may be performed at either one of RAN nodes 611 and 612 based on channel quality information fed back from either one of UEs 601 and 602. The downlink resource assignment information may be transmitted on a PDCCH for (e.g., assigned to) each of the UEs 601 and 602.

The PDCCH may use Control Channel Elements (CCEs) to convey control information. The PDCCH complex-valued symbols may first be organized into four tuples before being mapped to resource elements, and then may be arranged using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine groups of four physical resource elements referred to as Resource Element Groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of Downlink Control Information (DCI) and channel conditions. Four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation level, l=1, 2, 4, or 8) may be defined in LTE.

Some embodiments may use the concept as an extension of the above concepts for resource allocation for control channel information. For example, some embodiments may utilize an Enhanced Physical Downlink Control Channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more Enhanced Control Channel Elements (ECCEs). Similar to above, each ECCE may correspond to nine groups of four physical resource elements referred to as Enhanced Resource Element Groups (EREGs). In some cases, ECCEs may have other amounts of EREGs.

RAN 610 is shown communicatively coupled to a Core Network (CN) 620 via an S1 interface 613. In an embodiment, CN620 may be an Evolved Packet Core (EPC) network, a next generation packet core (NPC) network, or some other type of CN. In this embodiment, the S1 interface 613 is divided into two parts: an S1-U interface 614 carrying traffic data between RAN nodes 611 and 612 and a serving gateway (S-GW) 622; and an S1 Mobility Management Entity (MME) interface 615, which is a signaling interface between RAN nodes 611 and 612 and MME 621.

In this embodiment, CN620 includes MME 621, S-GW 622, packet Data Network (PDN) gateway (P-GW) 623, and Home Subscriber Server (HSS) 624.MME 621 may be similar in function to the control plane of a legacy serving General Packet Radio Service (GPRS) support node (SGSN). MME 621 may manage mobility aspects in the access such as gateway selection and tracking area list management. HSS 624 may include a database for network users including subscription-related information for supporting network entity handling communication sessions. CN620 may include one or more HSS 624 depending on the number of mobile subscribers, the capacity of the device, the organization of the network, etc. For example, HSS 624 may provide support for routing/roaming, authentication, authorization, naming/addressing solutions, location dependencies, and the like.

S-GW 622 may terminate S1 interface 613 to RAN 610 and route data packets between RAN 610 and CN 620. Further, S-GW 622 may be a local mobility anchor for inter-RAN node handover and may also provide anchoring for inter-3 GPP mobility. Other responsibilities may include legal interception, billing, and some policy enforcement.

The P-GW 623 may terminate an SGi interface to the PDN. The P-GW 623 may route data packets between the EPC network 623 and external networks (e.g., networks including an application server 630 (alternatively referred to as an Application Function (AF)) via an Internet Protocol (IP) interface 625. The application server 630 may be an element that provides applications (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.) using IP bearer resources to the core network. In this embodiment, P-GW 623 is shown communicatively coupled to application server 630 via IP communication interface 625. The application server 630 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 601 and 602 via the CN 620.

The P-GW 623 may also be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF) 626 is a policy and charging control element of CN 620. In a non-roaming scenario, there may be a single PCRF associated with an internet protocol connectivity access network (IP-CAN) session of the UE in a Home Public Land Mobile Network (HPLMN). In a roaming scenario where traffic is off-home, there may be two PCRFs associated with the IP-CAN session of the UE: a home PCRF (H-PCRF) within the HPLMN and a visited PCRF (V-PCRF) in a Visited Public Land Mobile Network (VPLMN). PCRF 626 may be communicatively coupled to application server 630 via P-GW 623. Application server 630 may signal PCRF 626 to indicate the new service flow and select the appropriate quality of service (QoS) and charging parameters. PCRF 626 may provide the rules to a Policy and Charging Enforcement Function (PCEF) (not shown) with an appropriate Traffic Flow Template (TFT) and QoS Class Identifier (QCI), which begins QoS and charging specified by application server 630.

Fig. 7 illustrates example components of a device 700 according to some embodiments. In some embodiments, the device 700 may include an application circuit 702, a baseband circuit 704, a Radio Frequency (RF) circuit 706, a Front End Module (FEM) circuit 708, one or more antennas 710, and a Power Management Circuit (PMC) 712, coupled together at least as shown. The components of the apparatus 700 shown may be included in a UE or RAN node. In some embodiments, the device 700 may include fewer elements (e.g., the RAN node may not utilize the application circuitry 702, but instead include a processor/controller to process IP data received from the EPC). In some embodiments, device 700 may include additional elements, such as memory/storage, displays, cameras, sensors, or input/output (I/O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., for a cloud RAN (C-RAN) implementation, the circuitry may be included in more than one device separately).

The application circuitry 702 may include one or more application processors. For example, application circuitry 702 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Processors may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled with or may include memory/storage and may be configured to: instructions stored in the memory/storage are executed to enable various applications or operating systems to run on device 700. In some embodiments, the processor of application circuit 702 may process IP data packets received from the EPC.

Baseband circuitry 704 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 704 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of the RF circuitry 706 and to generate baseband signals for the transmit signal path of the RF circuitry 706. Baseband circuitry 704 may interface with application circuitry 702 for generating and processing baseband signals and controlling the operation of RF circuitry 706. For example, in some embodiments, the baseband circuitry 704 may include a third generation (3G) baseband processor 704A, a fourth generation (4G) baseband processor 704B, a fifth generation (5G) baseband processor 704C, or other baseband processor 704D for other existing, developing, or future developed generations (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 704 (e.g., one or more of the baseband processors 704A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 706. In other embodiments, some or all of the functionality of baseband processors 704A-D may be included in modules stored in memory 704G and executed via Central Processing Unit (CPU) 704E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 704 may include Fast Fourier Transform (FFT), precoding, or constellation mapping/demapping functions. In some embodiments, the encoding/decoding circuitry of baseband circuitry 704 may include convolution, tail-biting convolution, turbo, viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of the modem and encoder/decoder functions are not limited to these examples and may include other suitable functions in other embodiments.

In some embodiments, the baseband circuitry 704 may include one or more audio Digital Signal Processors (DSPs) 704F. The audio DSP 704F may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the constituent components of baseband circuitry 704 and application circuitry 702 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, baseband circuitry 704 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 704 may support communication with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other Wireless Metropolitan Area Network (WMAN), wireless Local Area Network (WLAN), wireless Personal Area Network (WPAN). Embodiments in which the baseband circuitry 704 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

The RF circuitry 706 may enable communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 706 may include switches, filters, amplifiers, and the like to facilitate communication with a wireless network. The RF circuitry 706 may include a receive signal path, which may include circuitry for down-converting RF signals received from the FEM circuitry 708 and providing baseband signals to the baseband circuitry 704. RF circuitry 706 may also include transmit signal paths, which may include circuitry for up-converting baseband signals provided by baseband circuitry 704 and providing RF output signals to FEM circuitry 708 for transmission.

In some embodiments, the receive signal path of the RF circuit 706 may include a mixer circuit 706a, an amplifier circuit 706b, and a filter circuit 706c. In some embodiments, the transmit signal path of the RF circuit 706 may include a filter circuit 706c and a mixer circuit 706a. The RF circuit 706 may also include a synthesizer circuit 706d for synthesizing frequencies used by the mixer circuit 706a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 706a of the receive signal path may be configured to: the RF signal received from FEM circuitry 708 is down-converted based on the synthesized frequency provided by synthesizer circuitry 706 d. The amplifier circuit 706b may be configured to amplify the down-converted signal, and the filter circuit 706c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to: unwanted signals are removed from the down-converted signals to generate output baseband signals. The output baseband signal may be provided to baseband circuitry 704 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, although this is not a requirement. In some embodiments, the mixer circuit 706a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuit 706a of the transmit signal path may be configured to: the input baseband signal is up-converted based on the synthesized frequency provided by synthesizer circuit 706d to generate an RF output signal for FEM circuit 708. The baseband signal may be provided by baseband circuitry 704 and may be filtered by filter circuitry 706 c.

In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., hartley image rejection). In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuitry 706 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 704 may include a digital baseband interface to communicate with the RF circuitry 706.

In some dual mode embodiments, separate radio IC circuits may be provided for processing the signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, synthesizer circuit 706d may be a fractional-N synthesizer or a fractional-N/n+1 synthesizer, although the scope of embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, the synthesizer circuit 706d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

The synthesizer circuit 706d may be configured to: the output frequency is synthesized based on the frequency input and the divider control input for use by the mixer circuit 706a of the RF circuit 706. In some embodiments, the synthesizer circuit 706d may be a fractional N/n+1 synthesizer.

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), although this is not a requirement. The divider control input may be provided by the baseband circuitry 704 or the application processor 702, depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the application processor 702.

The synthesizer circuit 706d of the RF circuit 706 may include a divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a Dual Mode Divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to: the input signal is divided by N or n+1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D flip-flop. In these embodiments, the delay elements may be configured to decompose the VCO period into Nd equal phase packets, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, the synthesizer circuit 706d may be configured to generate the carrier frequency as the output frequency, while in other embodiments the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with the quadrature generator and divider circuit to generate a plurality of signals at the carrier frequency that have a plurality of different phases relative to one another. In some embodiments, the output frequency may be an LO frequency (fLO). In some embodiments, the RF circuit 706 may include an IQ/polar converter.

FEM circuitry 708 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 710, amplify the received signals, and provide an amplified version of the received signals to RF circuitry 706 for further processing. FEM circuitry 708 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by RF circuitry 706 for transmission by one or more of antennas 710. In various embodiments, amplification by either the transmit signal path or the receive signal path may be accomplished in the RF circuit 706 alone, the FEM 708 alone, or both the RF circuit 706 and FEM 708.

In some embodiments, FEM circuitry 708 may include a TX/RX switch to switch between transmit and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA for amplifying the received RF signal and providing the amplified received RF signal as an output (e.g., to the RF circuitry 706). The transmit signal path of FEM circuitry 708 may include: a Power Amplifier (PA) for amplifying an input RF signal (e.g., provided by RF circuit 706); and one or more filters for generating RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 710).

In some embodiments, PMC 712 may manage the power provided to baseband circuitry 704. In particular, the PMC 712 may control power supply selection, voltage scaling, battery charging, or DC-DC conversion. The PMC 712 may generally be included when the device 700 is capable of being powered by a battery, such as when the device is included in a UE. The PMC 712 may improve power conversion efficiency while providing desired implementation size and heat dissipation characteristics.

Although fig. 7 shows PMC 712 coupled only with baseband circuitry 704, in other embodiments PMC 712 may additionally or alternatively be coupled with other components and perform similar power management operations for other components, such as, but not limited to, application circuitry 702, RF circuitry 706, or FEM 708.

In some embodiments, PMC 712 may control, or be part of, various power saving mechanisms of device 700. For example, if the device 700 is in an RRC Connected state (where it is still Connected to the RAN node because it is expected to receive traffic soon after), it may enter a state called discontinuous reception mode (DRX) after an inactivity period. During this state, the device 700 may be powered down for a brief interval, thereby conserving power.

If there is no data traffic activity for an extended period of time, the device 700 may transition to an rrc_idle state (where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc.). The device 700 enters a very low power state and it performs paging where it wakes up again periodically to listen to the network and then powers down again. The device 700 may not receive data in this state and in order to receive data it must transition back to the RRC Connected state.

The additional power saving mode may allow the device to be unavailable to the network for a period longer than the paging interval (ranging from a few seconds to a few hours). During this time, the device is completely unreachable to the network and may be completely powered down. Any data transmitted during this time will create a large delay and this delay is assumed to be acceptable.

The processor of the application circuit 702 and the processor of the baseband circuit 704 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of baseband circuitry 704 may be used (alone or in combination) to perform layer 3, layer 2, or layer 1 functions, while the processor of application circuitry 704 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., transmission Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include a Radio Resource Control (RRC) layer, which will be described in further detail below. As mentioned herein, layer 2 may include a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, and a Packet Data Convergence Protocol (PDCP) layer, which will be described in further detail below. As mentioned herein, layer 1 may include a Physical (PHY) layer of a UE/RAN node, as will be described in further detail below.

Fig. 8 illustrates an example interface of baseband circuitry according to some embodiments. As discussed above, the baseband circuitry 704 of fig. 7 may include processors 704A-704E and memory 704G used by the processors. Each of the processors 704A-704E may include a memory interface 804A-804E, respectively, to send and receive data to and from the memory 704G.

The baseband circuitry 704 may also include one or more interfaces for communicatively coupling to other circuits/devices, such as a memory interface 812 (e.g., an interface for transmitting/receiving data to/from memory external to the baseband circuitry 704), an application circuitry interface 814 (e.g., an interface for transmitting/receiving data to/from the application circuitry 702 of fig. 7), an RF circuitry interface 816 (e.g., an interface for transmitting/receiving data to/from the RF circuitry 706 of fig. 7), a wireless hardware connection interface 818 (e.g., an interface for transmitting/receiving data to/from a Near Field Communication (NFC) component),Components (e.g.)>An interface for components and other communication components to send/receive data) and a power management interface 820 (e.g., an interface for sending/receiving power or control signals to/from the PMC 712).

Fig. 9 is an illustration of a control plane protocol stack in accordance with some embodiments. In this embodiment, control plane 900 is shown as a communication protocol stack between UE 601 (or alternatively, UE 602), RAN node 611 (or alternatively, RAN node 612), and MME 621.

The PHY layer 901 may transmit or receive information used by the MAC layer 902 over one or more air interfaces. PHY layer 901 may also perform link adaptation or Adaptive Modulation and Coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers such as RRC layer 905. PHY layer 901 may still further perform error detection for the transport channel, forward Error Correction (FEC) encoding/decoding for the transport channel, modulation/demodulation for the physical channel, interleaving, rate matching, mapping to the physical channel, and multiple-input multiple-output (MIMO) antenna processing.

The MAC layer 902 may perform mapping between logical channels and transport channels, multiplexing MAC Service Data Units (SDUs) from one or more logical channels to Transport Blocks (TBs) for delivery to a PHY via a transport channel, demultiplexing MAC SDUs from Transport Blocks (TBs) delivered from a PHY via a transport channel to one or more logical channels, multiplexing MAC SDUs to TBs, reporting scheduling information, error correction by hybrid automatic repeat request (HARQ), and logical channel prioritization.

The RLC layer 903 may operate in a variety of modes of operation, including: transparent Mode (TM), unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer 903 may perform transmission of upper layer Protocol Data Units (PDUs), error correction by automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. The RLC layer 903 may also perform re-segmentation of RLC data PDUs for AM data transfer, re-ordering RLC data PDUs for UM and AM data transfer, detecting duplicate data for UM and AM data transfer, discarding RLC SDUs for UM and AM data transfer, detecting protocol errors for AM data transfer, and performing RLC re-establishment.

The PDCP layer 904 may perform header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform sequential delivery of upper layer PDUs when reconstructing lower layers, eliminate duplication of lower layer SDUs when reconstructing lower layers for radio bearers mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, control timer-based data discard, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

The primary services and functions of the RRC layer 905 may include broadcasting of system information (e.g., included in a Master Information Block (MIB) or a System Information Block (SIB) related to a non-access stratum (NAS)), broadcasting of system information related to an Access Stratum (AS), paging, establishment, maintenance and release of RRC connections between a UE and an E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions (including key management), radio Access Technology (RAT) mobility and measurement configuration of UE measurement reporting. The MIB and SIB may include one or more Information Elements (IEs), each of which may include a separate data field or data structure.

The UE 601 and the RAN node 611 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack, including a PHY layer 901, a MAC layer 902, an RLC layer 903, a PDCP layer 904, and an RRC layer 905.

The non-access stratum (NAS) protocol 906 forms the highest layer of the control plane between the UE 601 and the MME 621. NAS protocol 906 supports mobility and session management procedures of UE 601 to establish and maintain IP connectivity between UE 601 and P-GW 623.

The S1 application protocol (S1-AP) layer 915 may support the functions of the S1 interface and include basic procedures (EPs). The EP is an interworking unit between the RAN node 611 and the CN 620. The S1-AP layer service may include two groups: UE-associated services and non-UE-associated services. These services perform the following functions including, but not limited to: E-UTRAN radio access bearer (E-RAB) management, UE capability indication, mobility, NAS signaling, RAN Information Management (RIM), and configuration delivery.

A Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as SCTP/IP layer) 914 may ensure reliable transfer of signaling messages between the RAN node 611 and the MME 621 based in part on the IP protocols supported by the IP layer 913. The L2 layer 912 and the L1 layer 911 may refer to communication links (e.g., wired or wireless) used by the RAN node and MME to exchange information.

RAN node 611 and MME 621 may exchange control plane data via a protocol stack using an S1-MME interface, including an L1 layer 911, an L2 layer 912, an IP layer 913, an SCTP layer 914, and an S1-AP 915 layer.

Fig. 10 is an illustration of a user plane protocol stack in accordance with some embodiments. In this embodiment, user plane 1000 is shown as a communication protocol stack between UE601 (or alternatively, UE 602), RAN node 611 (or alternatively, RAN node 612), S-GW 622, and P-GW 623. The user plane 1000 may utilize at least some of the same protocol layers as the control plane 900. For example, the UE601 and the RAN node 611 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange user plane data via a protocol stack, including a PHY layer 901, a MAC layer 902, an RLC layer 903, a PDCP layer 904.

A General Packet Radio Service (GPRS) tunneling protocol for the user plane (GTP-U) layer 1004 may be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the user data transmitted may be packets in any of IPv4, IPv6, or PPP formats. The UDP and IP security (UDP/IP) layer 1003 may provide a checksum for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication of selected data streams. RAN node 611 and S-GW 622 may utilize an S1-U interface to exchange user plane data via a protocol stack, including L1 layer 911, L2 layer 912, UDP/IP layer 1003, and GTP-U layer 1004. The S-GW 622 and the P-GW623 may utilize an S5/S8a interface to exchange user plane data via a protocol stack, including an L1 layer 911, an L2 layer 912, a UDP/IP layer 1003, and a GTP-U layer 1004. As discussed above with respect to fig. 9, the NAS protocol supports mobility and session management procedures for the UE601 to establish and maintain an IP connection between the UE601 and the P-GW 623.

Fig. 11 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments. In particular, FIG. 11 shows a graphical representation of a hardware resource 1100, including one or more processors (or processor cores) 1110, one or more memory/storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via a bus 1140. For embodiments that utilize node virtualization (e.g., NFV), hypervisor 1102 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize hardware resources 1100.

The processor 1110 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), such as a baseband processor, an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1112 and processor 1114.

Memory/storage 1120 may include main memory, disk memory, or any suitable combination thereof. Memory/storage 1120 may include, but is not limited to, any type of volatile or non-volatile memory such as Dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), erasable Programmable Read Only Memory (EPROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, solid state storage, and the like.

Communication resources 1130 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 1104 or one or more databases 1106 via network 1108. For example, the communication resources 1130 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, and so forth,Components (e.g.)>)、/>Components and other communication components.

The instructions 1150 may include software, programs, applications, applets, apps, or other executable code for causing at least any one of the processors 1110 to perform any one or more of the methods discussed herein. The instructions 1150 may reside, completely or partially, within at least one of the processor 1110 (e.g., within a cache of the processor), the memory/storage 1120, or any suitable combination thereof. Further, any portion of the instructions 1150 may be transferred from any combination of the peripheral 1104 or database 1106 to the hardware resource 1100. Thus, the memory of processor 1110, memory/storage 1120, peripherals 1104, and database 1106 are examples of computer-readable and machine-readable media.

Example

The following examples pertain to particular technical embodiments and specify particular features or elements that may be used or combined in implementing these embodiments.

Example 1 may be an apparatus of a User Equipment (UE), comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: identifying signals received from a gNB via the RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after detecting a beam fault, sending a beam fault recovery request to the gNB; identifying a beam fault response signal received from the gNB; and performing beam fault detection on a beam fault recovery control resource set (CORESET-BFR) when the UE is listening for the CORESET, until a Physical Downlink Control Channel (PDCCH) Transmission Configuration Indicator (TCI) is reconfigured.

Example 2 may include the subject matter of example 1 or any other example herein, wherein the beam fault detection parameters comprise a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection, and wherein the one or more processors are further configured to: the UE is configured based on the beam fault detection parameters.

Example 3 may include the subject matter of example 1 or any other example herein, wherein the one or more processors are further configured to: and when the UE is monitoring the CORESET-BFR, beam fault detection is not performed.

Example 4 may include the subject matter of examples 1-3 or any other example herein, wherein the one or more processors are further configured to: determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and transmitting an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER and reset the beam fault detection timer beamfailure detection timer based on the determined change.

Example 5 may be an apparatus of a User Equipment (UE), comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: identifying signals received from the gNB via the RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after detecting a beam fault, sending a beam fault recovery request to the gNB; identifying a beam fault response signal received from the gNB; and listening to a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks spatially quasi co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) before receiving the beam failure response signal and until a set of resources for beam failure detection is reconfigured, to detect a beam failure.

Example 6 may include the subject matter of example 5 or any other example herein, wherein the beam fault detection parameters comprise a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection, and wherein the one or more processors are further configured to: the UE is configured based on the beam fault detection parameters.

Example 7 may include the subject matter of examples 5-6 or any other example herein, wherein the one or more processors are further configured to: determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and transmitting an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER and reset the beam fault detection timer beamfailure detection timer based on the determined change.

Example 8 may be an apparatus of a User Equipment (UE), comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: initiating a Beam Fault Recovery (BFR) procedure; identifying signals received from a gNB via the RF interface; determining a beam fault detection parameter based on the received signal; initiating Beam Fault Detection (BFD) based on the beam fault detection parameters; and switching a bandwidth part (BWP) from the first BWP to the second BWP, wherein the switching of BWP occurs during the BFR procedure.

Example 9 may include the subject matter of example 8 or any other example herein, wherein the one or more processors are further configured to: when BWP is switched during BFD, a counter for BFD is reset.

Example 10 may include the subject matter of example 8 or any other example herein, wherein the one or more processors are further configured to: when BWP is switched during BFD, the counter for BFD is allowed to continue counting.

Example 11 may include the subject matter of example 10 or any other example herein, wherein the one or more processors are further configured to: based on determining that a set of control resources (CORESET) for the first BWP and the second BWP are spatially quasi co-located (QCL) with each other, the counter for BFD is allowed to continue counting when switching BWP during BFD.

Example 12 may include the subject matter of example 8 or any other example herein, wherein the one or more processors are further configured to: when a BWP handover occurs after the UE declares a beam failure event, BFD is restarted for the second BWP after the BWP handover.

Example 13 may include the subject matter of example 8 or any other example herein, wherein the one or more processors are further configured to: when a BWP handover occurs after a UE declares a beam failure event, if a BFD Reference Signal (RS) set of the first BWP and the second BWP is spatially one-to-one quasi co-located (QCL), a BFR request is transmitted in the second BWP after the BWP handover.

Example 14 may include the subject matter of example 8 or any other example herein, wherein the one or more processors are further configured to: transmitting a BFR request after determining a beam fault event; receiving a BFR response based on the BFR request; and listening for a set of control resources (CORESET) in the second BWP before receiving a reconfiguration or beam indication of CORESET when a BWP switch occurs after receiving the BFR response.

Example 15 may include the subject matter of example 14 or any other example herein, wherein the CORESET is configured by higher layer signaling.

Example 16 may include the subject matter of example 14 or any other example herein, wherein the one or more processors are further configured to: after BWP switching, listening for all CORESET in the second BWP.

Example 17 may include the subject matter of example 16 or any other example herein, wherein the one or more processors are further configured to: when CORESETs in the first BWP and the second BWP are spatially quasi co-located (QCL), listening for all CORESETs in the second BWP.

Example 18 may include the subject matter of example 14 or any other example herein, wherein the UE is not expected to switch to another BWP after receiving a BFR response in a beam failure recovery CORESET (CORESET-BFR) prior to reconfiguring the CORESET.

Example 19 may include the subject matter of example 8 or any other example herein, wherein one control resource set (CORESET) in the first BWP is configured to be spatially QCL with CORESET in the second BWP through Radio Resource Control (RRC) signaling.

Example 20 may include the subject matter of example 8 or any other example herein, wherein one beam failure recovery control resource set (CORESET-BFR) is configured for each BWP.

Example 21 may include the subject matter of example 20 or any other example herein, wherein the one or more processors are further configured to: when CORESET-BFR is not configured, BFD is not performed and BFR requests are sent.

Example 22 may include the subject matter of example 8 or any other example herein, wherein the one or more processors are not expected to instruct BWP handover or to instruct performing autonomous timer-based BWP handover Downlink Control Information (DCI) messages when the BFR response is to be listened to after the BFR request is expected to be sent within a window of a higher layer parameter Beam-failure-recovery-request-window configuration.

Example 23 may be an apparatus of a gNB, comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: determining beam fault detection parameters of a User Equipment (UE); identifying a signal based on the determined beam fault detection parameter; and transmitting the identified signal to the UE.

Example 24 may include the subject matter of example 23 or any other example herein, wherein the beam-failure detection parameters further comprise a set of periodic CSI-RS resources or SS/PBCH blocks for beam-failure detection.

Example 25 may include the subject matter of example 23 or any other example herein, wherein the Beam fault Detection parameters further comprise a Beam-fault-Detection-RS-resource econfig element.

Example 26 may include the subject matter of example 23 or any other example herein, wherein the one or more processors are further configured to: a failure recovery request received from the UE is identified.

Example 27 may include the subject matter of example 26 or any other example herein, wherein the one or more processors are further configured to: and sending a response to the beam fault recovery request.

Example 28 may be a method performed at a User Equipment (UE), comprising: identifying signals received from the gNB via the RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after detecting a beam fault, sending a beam fault recovery request to the gNB; identifying a beam fault response signal received from the gNB; and performing beam fault detection on a beam fault recovery control resource set (CORESET-BFR) when the UE is listening for the CORESET, until a Physical Downlink Control Channel (PDCCH) Transmission Configuration Indicator (TCI) is reconfigured.

Example 29 may include the subject matter of example 28 or any other example herein, wherein the beam fault detection parameters include a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection, and wherein the method further comprises: the UE is configured based on the beam fault detection parameters.

Example 30 may include the subject matter of example 28 or any other example herein, further comprising: and when the UE is monitoring the CORESET-BFR, beam fault detection is not performed.

Example 31 may include the subject matter of examples 28-30 or any other example herein, further comprising: determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and transmitting an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER and reset the beam fault detection timer beamfailure detection timer based on the determined change.

Example 32 may be a method performed at a User Equipment (UE), comprising: identifying signals received from the gNB via the RF interface; determining a beam fault detection parameter based on the received signal; monitoring a set of resources associated with the beam fault detection parameters to detect a beam fault; after detecting a beam fault, sending a beam fault recovery request to the gNB; identifying a beam fault response signal received from the gNB; and listening to a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks spatially quasi co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) before receiving the beam failure response signal and until a set of resources for beam failure detection is reconfigured, to detect a beam failure.

Example 33 may include the subject matter of example 32 or any other example herein, wherein the beam fault detection parameters include a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection, and wherein the method further comprises: the UE is configured based on the beam fault detection parameters.

Example 34 may include the subject matter of examples 32-33 or any other example herein, further comprising: determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and transmitting an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER and reset the beam fault detection timer beamfailure detection timer based on the determined change.

Example 35 may be a method performed at a User Equipment (UE), comprising: initiating a Beam Fault Recovery (BFR) procedure; identifying signals received from the gNB via the RF interface; determining a beam fault detection parameter based on the received signal; initiating Beam Fault Detection (BFD) based on the beam fault detection parameters; and switching a bandwidth part (BWP) from the first BWP to the second BWP, wherein the switching of BWP occurs during the BFR procedure.

Example 36 may include the subject matter of example 35 or any other example herein, further comprising: when BWP is switched during BFD, a counter for BFD is reset.

Example 37 may include the subject matter of example 35 or any other example herein, further comprising: when BWP is switched during BFD, the counter for BFD is allowed to continue counting.

Example 38 may include the subject matter of example 37 or any other example herein, further comprising: based on determining that a set of control resources (CORESET) for the first BWP and the second BWP are spatially quasi co-located (QCL) with each other, the counter for BFD is allowed to continue counting when switching BWP during BFD.

Example 39 may include the subject matter of example 35 or any other example herein, further comprising: when a BWP handover occurs after the UE declares a beam failure event, BFD is restarted for the second BWP after the BWP handover.

Example 40 may include the subject matter of example 35 or any other example herein, further comprising: when a BWP handover occurs after a UE declares a beam failure event, if a BFD Reference Signal (RS) set of the first BWP and the second BWP is spatially one-to-one quasi co-located (QCL), a BFR request is transmitted in the second BWP after the BWP handover.

Example 41 may include the subject matter of example 35 or any other example herein, further comprising: transmitting a BFR request after determining a beam fault event; receiving a BFR response based on the BFR request; and listening for a set of control resources (CORESET) in the second BWP before receiving a reconfiguration or beam indication of CORESET when a BWP switch occurs after receiving the BFR response.

Example 42 may include the subject matter of example 41 or any other example herein, wherein the CORESET is configured by higher layer signaling.

Example 43 may include the subject matter of example 41 or any other example herein, further comprising: after BWP switching, listening for all CORESET in the second BWP.

Example 44 may include the subject matter of 43 or any other example herein, further comprising: when CORESETs in the first BWP and the second BWP are spatially quasi co-located (QCL), listening for all CORESETs in the second BWP.

Example 45 may include the subject matter of example 41 or any other example herein, wherein, prior to reconfiguring the CORESET, the UE is not expected to switch to another BWP after receiving a BFR response in a beam failure recovery CORESET (CORESET-BFR).

Example 46 may include the subject matter of example 35 or any other example herein, wherein one control resource set (CORESET) in the first BWP is configured to be spatially QCL with CORESET in the second BWP through Radio Resource Control (RRC) signaling.

Example 47 may include the subject matter of example 35 or any other example herein, wherein one beam failure recovery control resource set (CORESET-BFR) is configured for each BWP.

Example 48 may include the subject matter of example 47 or any other example herein, further comprising: when CORESET-BFR is not configured, BFD is not performed and BFR requests are sent.

Example 49 may include the subject matter of example 35 or any other example herein, wherein the UE is not expected to indicate a BWP handover or to indicate performing an autonomous timer-based BWP handover Downlink Control Information (DCI) message when listening for a BFR response after sending the BFR request within a window of a higher layer parameter Beam-failure-recovery-request-window configuration.

Example 50 may be a method performed at a gNB, comprising: determining beam fault detection parameters of a User Equipment (UE); identifying a signal based on the determined beam fault detection parameter; and transmitting the identified signal to the UE.

Example 51 may include the subject matter of example 50 or any other example herein, wherein the beam-failure detection parameters further comprise a set of periodic CSI-RS resources or SS/PBCH blocks for beam-failure detection.

Example 52 may include the subject matter of example 50 or any other example herein, wherein the Beam fault Detection parameter further comprises a Beam-fault-Detection-RS-resource econfig element.

Example 53 may include the subject matter of example 50 or any other example herein, further comprising: a failure recovery request received from the UE is identified.

Example 54 may include the subject matter of example 53 or any other example herein, further comprising: and sending a response to the beam fault recovery request.

Example 55 may be a computer-readable storage medium having instructions stored thereon that, when executed by a processor, cause the processor to perform the method of any of examples 28-54.

Example 56 may be an apparatus of a User Equipment (UE), comprising: means for identifying signals received from the gNB via the RF interface; means for determining beam fault detection parameters based on the received signals; means for listening to a set of resources associated with the beam fault detection parameter to detect a beam fault; means for sending a beam fault recovery request to the gNB upon detection of a beam fault; means for identifying a beam fault response signal received from the gNB; and means for performing beam fault detection on a beam fault recovery control resource set (CORESET-BFR) when the UE is listening for the CORESET, until a Physical Downlink Control Channel (PDCCH) Transmission Configuration Indicator (TCI) is reconfigured.

Example 57 may include the subject matter of example 56 or any other example herein, wherein the beam fault detection parameters include a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection, and wherein the apparatus further comprises: the apparatus includes means for configuring the UE based on the beam fault detection parameters.

Example 58 may include the subject matter of example 56 or any other example herein, further comprising: the apparatus may include means for not performing beam fault detection while the UE is listening to the CORESET-BFR.

Example 59 may include the subject matter of examples 56-58 or any other example herein, further comprising: means for determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and means for sending an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER and reset the beam fault detection timer beamfailure detection timer based on the determined change.

Example 60 may be an apparatus of a User Equipment (UE), comprising: means for identifying signals received from the gNB via the RF interface; means for determining beam fault detection parameters based on the received signals; means for listening to a set of resources associated with the beam fault detection parameter to detect a beam fault; means for sending a beam fault recovery request to the gNB upon detection of a beam fault; means for identifying a beam fault response signal received from the gNB; and means for listening to a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks spatially quasi co-located (QCL) with a Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) before receiving the beam failure response signal and until a set of resources for beam failure detection are reconfigured, to detect a beam failure.

Example 61 may include the subject matter of example 60 or any other example herein, wherein the beam fault detection parameters include a set of periodic channel state information reference signals (CSI-RS) or Synchronization Signals (SS)/Physical Broadcast Channel (PBCH) blocks for beam fault detection, and wherein the apparatus further comprises: the apparatus includes means for configuring the UE based on the beam fault detection parameters.

Example 62 may include the subject matter of 60-61 or any other example herein, further comprising: means for determining a change in the monitored resource, beam, or control resource set (CORESET), or a change in the number of monitored resources, beams, or CORESETs; and means for sending an indication to the MAC layer to reset the beam fault detection COUNTER BFI-COUNTER and reset the beam fault detection timer beamfailure detection timer based on the determined change.

Example 63 may be an apparatus of a User Equipment (UE), comprising: means for initiating a Beam Fault Recovery (BFR) procedure; means for identifying signals received from a gNB via the RF interface; means for determining beam fault detection parameters based on the received signals; means for initiating Beam Fault Detection (BFD) based on the beam fault detection parameters; and means for switching a bandwidth part (BWP) from the first BWP to the second BWP, wherein the switching of BWP occurs during the BFR procedure.

Example 64 may include the subject matter of example 63 or any other example herein, further comprising: the method further includes resetting a counter for BFD when BWP is switched during BFD.

Example 65 may include the subject matter of example 63 or any other example herein, further comprising: the apparatus further includes means for allowing the counter for BFD to continue counting when the BWP is switched during BFD.

Example 66 may include the subject matter of example 65 or any other example herein, further comprising: and means for allowing a counter for BFD to continue counting when switching BWP during BFD based on determining that a set of control resources (CORESET) for the first BWP and the second BWP are spatially quasi co-located (QCL) with each other.

Example 67 may include the subject matter of example 63 or any other example herein, further comprising: when a BWP handover occurs after the UE declares a beam failure event, restarting BFD for the second BWP after the BWP handover.

Example 68 may include the subject matter of example 63 or any other example herein, further comprising: when a BWP handoff occurs after a UE declares a beam failure event, if BFD Reference Signal (RS) sets of the first BWP and the second BWP are spatially one-to-one quasi co-located (QCL), transmitting a BFR request in the second BWP after the BWP handoff.

Example 69 may include the subject matter of example 63 or any other example herein, further comprising: means for sending a BFR request after determining a beam failure event; means for receiving a BFR response based on the BFR request; and means for listening to a control resource set (CORESET) in the second BWP before receiving a reconfiguration or beam indication of CORESET when a BWP switch occurs after receiving the BFR response.

Example 70 may include the subject matter of example 69 or any other example herein, wherein the CORESET is configured by higher layer signaling.

Example 71 may include the subject matter of example 69 or any other example herein, further comprising: and means for listening to all CORESET in the second BWP after the BWP switch.

Example 72 may include the subject matter of 71 or any other example herein, further comprising: and means for listening to all CORESETs in the second BWP when CORESETs in the first BWP and the second BWP are spatially quasi co-located (QCL).

Example 73 may include the subject matter of example 69 or any other example herein, wherein, prior to reconfiguring the CORESET, the UE is not expected to switch to another BWP after receiving a BFR response in a beam failure recovery CORESET (CORESET-BFR).

Example 74 may include the subject matter of example 63 or any other example herein, wherein one control resource set (CORESET) in the first BWP is configured to be spatially QCL with CORESET in the second BWP through Radio Resource Control (RRC) signaling.

Example 75 may include the subject matter of example 63 or any other example herein, wherein one set of beam fault recovery control resources (CORESET-BFR) is configured for each BWP.

Example 76 may include the subject matter of example 75 or any other example herein, further comprising: the method also includes not performing BFD and sending BFR requests when CORESET-BFR is not configured.

Example 77 may include the subject matter of example 63 or any other example herein, wherein the UE is not expected to indicate a BWP handover or to indicate performing an autonomous timer-based BWP handover Downlink Control Information (DCI) message when listening for a BFR response after sending the BFR request within a window of a higher layer parameter Beam-failure-recovery-request-window configuration.

Example 78 may be an apparatus of a gNB, comprising: means for determining beam fault detection parameters of a User Equipment (UE); means for identifying a signal based on the determined beam fault detection parameter; and means for transmitting the identified signal to the UE.

Example 79 may include the subject matter of example 78 or any other example herein, wherein the beam-failure detection parameters further comprise a set of periodic CSI-RS resources or SS/PBCH blocks for beam-failure detection.

Example 80 may include the subject matter of example 78 or any other example herein, wherein the Beam fault Detection parameter further comprises a Beam-fault-Detection-RS-resource econfig element.

Example 81 may include the subject matter of example 78 or any other example herein, further comprising: the apparatus includes means for identifying a failure recovery request received from the UE.

Example 82 may include the subject matter of example 81 or any other example herein, further comprising: and sending a response to the beam fault recovery request.

As used herein, the term "circuitry" may refer to, be part of, or include: an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some aspects, the circuitry may be implemented in or the functionality associated with one or more software or firmware modules. In some aspects, the circuitry may comprise logic that operates at least in part in hardware.

The various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact disk read only memories (CD-ROMs), hard drives, transitory or non-transitory computer-readable storage media, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. The circuitry may include hardware, firmware, program code, executable code, computer instructions, and/or software. The non-transitory computer readable storage medium may be a computer readable storage medium that does not include a signal. In the case of program code execution on programmable computers, the computing device can include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and nonvolatile memory and/or storage elements may be Random Access Memory (RAM), erasable programmable read-only memory (EPROM), flash drive, optical drive, magnetic hard drive, solid state drive, or other media for storing electronic data. The node and wireless device may also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or a timer module (i.e., timer). One or more programs that may implement or utilize the various techniques described herein may use Application Programming Interfaces (APIs), reusable controls, and the like. These programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

It should be appreciated that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors (e.g., logic chips, transistors, or other discrete components). A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by various types of processors. Identified modules may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. However, the executables of an identified module may not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices. The modules may be active or passive, including agents operable to perform desired functions.

Reference throughout this specification to "an example" or "exemplary" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present technology. Thus, the appearances of the phrase "in an example" or the word "exemplary" in various places throughout this specification are not necessarily all referring to the same embodiment.

As used herein, a plurality of items, structural elements, constituent elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, any individual member of such list should not be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and examples of the present technology may be referred to herein along with alternatives to the various components thereof. It should be understood that these embodiments, examples, and alternatives are not to be construed as actually equivalent to each other, but rather as separate and autonomous representations of the present technology.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of arrangements, distances, network examples, etc., to provide a thorough understanding of embodiments of the present technology. One skilled in the relevant art will recognize, however, that the technology may be practiced without one or more of the specific details, or with other methods, components, arrangements, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the technology.

While the foregoing examples illustrate the principles of the technology in one or more particular applications, it will be apparent to those skilled in the art that various modifications in form, use, and detail of implementation can be made without undue burden of the inventive concepts and without departing from the principles and concepts of the technology. Accordingly, it is not intended that the technology be limited, except as by the claims set forth below.

Claims (10)

1. A baseband processor of a user equipment, UE, comprising:

one or more processors configured to execute instructions stored in memory to cause the UE to:

monitoring a set of channel state information reference signal (CSI-RS) resources or Synchronization Signal (SS)/Physical Broadcast Channel (PBCH) block resources to detect beam faults;

transmitting a beam fault recovery request to a base station in response to detecting the beam fault;

receiving a beam fault recovery response from the base station; and

after receiving the beam fault recovery response, continuing to monitor a beam fault recovery control resource set CORESET, i.e., CORESET-BFR, until the physical downlink control channel PDCCH transmission configuration indicator TCI is reconfigured.

2. The baseband processor of claim 1, wherein the one or more processors further cause the UE to:

signals are received from the base station to configure the set of CSI-RS resources.

3. The baseband processor of claim 1, wherein the one or more processors further cause the UE to:

and when the UE is monitoring the CORESET-BFR, beam fault detection is not performed.

4. The baseband processor of any of claims 1-3, wherein the one or more processors are further to cause the UE to:

determining changes in the monitored resource, beam or control resource set CORESET; and

in response to determining the change in the resource, beam or CORESET being listened to, the COUNTER BFI-COUNTER for beam failure detection is reset.

5. The baseband processor as recited in claim 4, wherein said one or more processors further cause said UE to:

the beam fault timer is reset in response to determining the change in the resource, beam or CORESET being listened to.

6. A method performed by a user equipment, UE, comprising:

monitoring a set of channel state information reference signal (CSI-RS) resources to detect beam faults;

Transmitting a beam fault recovery request to a base station in response to detecting the beam fault;

receiving a beam fault recovery response from the base station; and

after receiving the beam fault recovery response, continuing to monitor a beam fault recovery control resource set CORESET, i.e., CORESET-BFR, until the physical downlink control channel PDCCH transmission configuration indicator TCI is reconfigured.

7. The method of claim 6, further comprising:

signals are received from the base station to configure the set of CSI-RS resources.

8. The method of claim 6, further comprising:

and when the UE is monitoring the CORESET-BFR, beam fault detection is not performed.

9. The method of any of claims 6-8, further comprising:

determining changes in the monitored resource, beam or control resource set CORESET; and

in response to determining the change in the resource, beam or CORESET being listened to, the COUNTER BFI-COUNTER for beam failure detection is reset.

10. The method of claim 9, further comprising:

the beam fault timer is reset in response to determining the change in the resource, beam or CORESET being listened to.