Beam indication considering beam failure recovery in new radio

Technology for a user equipment (UE) configured to perform beam failure recovery. The UE can encode a beam failure recovery (BFR) request for transmission on a physical random-access channel (PRACH) or a physical uplink control channel (PUCCH) to a next generation node B (gNB). The UE can monitor a dedicated physical downlink control channel (PDCCH) control resource set (CORESET) for a response from the gNB to the beam failure recovery request. The UE can select a default physical downlink shared channel (PDSCH) beam, wherein it is assumed, at the UE that a same quasi co-location (QCL) assumption for a PDSCH as a QCL assumption for the dedicated PDCCH CORESET; or a PDSCH demodulation reference signal (DMRS) is QCLed with a downlink (DL) reference signal (RS) of an identified candidate beam by the UE. The UE can decode a beam failure recovery request response from the gNB.

RELATED APPLICATIONS

The present application claims priority to PCT Patent Application No. PCT/CN2018/072385, filed Jan. 12, 2018, and PCT Patent Application No. PCT/CN2018/072452, filed Jan. 12, 2018, the entire applications of each of which are hereby incorporated by reference in their entireties for all purposes.

BACKGROUND

Wireless systems typically include multiple User Equipment (UE) devices communicatively coupled to one or more Base Stations (BS). The one or more BSs may be Long Term Evolved (LTE) evolved NodeBs (eNB) or New Radio (NR) next generation NodeBs (gNB) that can be communicatively coupled to one or more UEs by a Third-Generation Partnership Project (3GPP) network.

Next generation wireless communication systems are expected to be a unified network/system that is targeted to meet vastly different and sometimes conflicting performance dimensions and services. New Radio Access Technology (RAT) is expected to support a broad range of use cases including Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mMTC), Mission Critical Machine Type Communication (uMTC), and similar service types operating in frequency ranges up to 100 GHz.

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

EXAMPLE EMBODIMENTS

Mobile communication has evolved significantly from early voice systems to today's highly sophisticated integrated communication platform. The next generation wireless communication system, 5G, or new radio (NR) will provide access to information and sharing of data anywhere, and anytime by various users and applications. NR is expected to be a unified network/system that targets to meet vastly different and sometime conflicting performance dimensions and services. Such diverse multi-dimensional designs are driven by different services and applications. In general, NR will evolve based on 3GPP LTE-Advanced with additional potential new Radio Access Technologies (RATs) to enrich people lives with better, simple and seamless wireless connectivity solutions. NR will enable everything to be connected by wireless systems and deliver fast, rich contents and services.

For 5G systems, high frequency band communication has attracted significant attention from the industry, due to the fact that it can provide wider bandwidth to support future integrated communication systems. Accordingly, beamforming is a critical technology for the implementation of high frequency band systems due to the fact that the beamforming gain can compensate for severe path loss caused by atmospheric attenuation, improve the signal to noise ratio (SNR), and enlarge the coverage area. By aligning the transmission beam to the target UE, the radiated energy is focused for higher energy efficiency, and the mutual UE interference is suppressed.

FIG. 1illustrates an example of a simultaneous transmission using multiple Transmission/Reception (Tx/Rx) beams.FIG. 1further illustrates one example of simultaneous transmission using Tx and Rx beams. In the example, the UE is equipped with two or multiple antenna sub-arrays, also referred to as antenna panels. Each antenna sub-array can be used to transmit and receive a signal in a directed beam with a transmission-reception point (TRP). A TRP is synonymous with a base station (BS) or next generation node B (gNB). The use of multiple sub-arrays or panels allows simultaneous transmission and reception using multiple beams to be supported at a UE.

When there are multiple transmitting antennas, the phase between different antennas can be discontinuous. Hence, it may be difficult to employ an antenna combination based scheme. Accordingly, an antenna selection based transmission scheme can be considered for the transmission of physical uplink control channel (PUCCH). As mentioned above, the UE may be equipped with multiple panel type antennas. In this case, certain mechanisms can be defined to select the antenna panel(s) that are used to transmit the PUCCH.

Timing for PDSCH QCL Assumption Considering Beam Failure Recovery

FIG. 2illustrates an example of an existing scheme for physical downlink shared channel (PDSCH) quasi co-located (QCL) assumption in beam failure recovery. In one example, upon receiving a next generation Node B (gNB) response for a beam failure recovery request, the UE can assume that the PDSCH demodulation reference signal (DMRS) is spatially QCLed with the downlink (DL) reference signal (RS) of the UE identified candidate beam until the reconfiguration/activation/re-indication of the transmission configuration indicator (TCI) state for PDCCH.

In one embodiment, due to latency of the downlink control information (DCI) decoding and UE beam switching, there can be examples of beam failure recovery. In one example, only after successfully decoding the DCI, the UE can be configured to determine whether there is a gNB response directed to the UE. Therefore, the UE can apply a default beam for PDSCH reception after the UE monitors the dedicated physical downlink control channel (PDCCH) control resource set (CORESET) for gNB response.FIG. 3shows an example of the scheme.

FIG. 3illustrates an example of a proposed timing for PDSCH QCL assumption based on the above described embodiments. In one embodiment, after the UE begins to monitor the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request, the UE can assume that the same QCL assumption for PDSCH is used as the QCL assumption for the dedicated PDCCH CORESET, until the indication of a reconfiguration, activation, or re-indication of a TCI state for the PDCCH.

In one embodiment, after the UE begins to monitor the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request, the UE can assume that the same QCL assumption for PDSCH is used as the QCL assumption for the dedicated PDCCH CORESET, after the UE begins to monitor the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request. In this instance, the UE can assume that the PDSCH DMRS is spatially QCLed with the DL RS of the UE identified candidate beam until an indication of the reconfiguration/activation/re-indication of the TCI state for the physical downlink control channel (PDCCH).

Alternatively, the UE can assume that the PDSCH QCL assumption is the same with the PDCCH dedicated CORESET immediately after the UE sends the beam failure recovery request, as depicted inFIG. 4.FIG. 4illustrates another example of proposed timing for the PDSCH QCL assumption.

In one embodiment, after the UE sends a beam failure recovery request over the physical random access channel (PRACH) or physical uplink control channel (PUCCH), the UE can assume the same QCL assumption for the physical downlink shared channel (PDSCH) is used as the QCL assumption for the dedicated PDCCH CORESET until an indication or determining of a reconfiguration/activation/re-indication of the TCI state for PDCCH.

In one embodiment, the UE can assume that the same QCL assumption for the PDSCH us used as the QCL assumption for the dedicated PDCCH CORESET after the UE sends a beam failure recovery request over PRACH or PUCCH. In one example, the UE can assume the PDSCH DMRS is spatially QCLed with the DL RS of the UE identified candidate beam until the reconfiguration/activation/re-indication of the TCI state for PDCCH.

Default Beam for PDSCH Considering Beam Failure Recovery

FIG. 5illustrates an example of a default beam operation considering beam failure. In one example, a scheduling offset between the PDCCH and the PDSCH is smaller than a certain threshold, k, where k is a real number. The UE can assume a default TCI state for the PDSCH reception is the TCI state used for the PDCCH QCL indication of the lowest CORESET identification (CORESET-ID) in the latest slot in which one or more CORESETs are configured for the UE. In one example, when determining the default PDSCH beam, the PDCCH CORESET can be the unicast CORESET. As such, in some embodiments, the broadcast CORESETs can be excluded.

In one embodiment, in considering the beam failure recovery operation, the UE can monitor a dedicated PDCCH CORESET for a gNB response after sending the beam failure recovery request as shown in previously discussedFIG. 2. Thus, the dedicated CORESET can be excluded when determining the default beam for PDSCH, before the gNB sends the response, or before the gNB receives the beam failure recovery request. Examples of this operation are further displayed and indicated inFIG. 6(a)andFIG. 6(b).

In an embodiment, if the scheduling offset between the PDCCH and the PDSCH is smaller than a certain threshold, that can be predetermined, before the gNB sends a response to beam failure recovery request, or before the gNB receives the beam failure recovery request, the UE can assume a default TCI state for PDSCH reception. The default TCI state can be the TCI state used for the PDCCH QCL indication of the lowest CORESET-ID in the latest slot in which one or more CORESETs are configured for the UE. The lowest CORESET-ID can be determined excluding the dedicated CORESET for the gNB response to the beam failure recovery request.

In one embodiment, if the scheduling offset between PDCCH and PDSCH is smaller than a certain threshold before the gNB sends a response to the beam failure recovery request, or before the gNB receives the beam failure recovery request, then the UE can assume a default TCI state for PDSCH reception. The default TCI state is the TCI state used for the PDCCH QCL indication of the lowest unicast CORESET-ID (or the CORESET for unicast PDSCH) in the latest slot in which one or more unicast CORESETs (or the CORESET for unicast PDSCH), which exclude the CORESET used for the gNB response to the beam failure recovery request, are configured for the UE. In some examples, this can occur when determining the default beam for PDSCH reception. Further, the broadcast PDCCH CORESETs can be excluded, such as the CORESETs for remaining minimum system information (RMSI)/other system information (OSI)/Paging. Additionally, the dedicated CORESET for gNB response to the beam failure recovery request can be also excluded.

In one embodiment, the UE can be configured for the following CORESET monitoring operations after sending the beam failure recovery request, or after 4 slots from the slot of the beam failure recovery request transmission. In one example, the UE can monitor only the CORESET for the gNB response to the beam failure recovery request. In one example, the UE can monitor both the CORESET for the gNB response to the beam failure recovery request and the broadcast CORESETs, such as the CORESETs for RMSI/OSI/Paging. In one example, the UE can monitor all the configured CORESETs, including the CORESET for the gNB response to the beam failure recovery request, and the broadcast CORESETs, such as the CORESETs for RMSI/OSI/Paging, and the previously configured unicast PDCCH CORESET(s).

In an embodiment, the UE can be configured to monitor only the CORESET for the gNB response to beam failure recovery request after sending the beam failure recovery request, or after 4 slots from the slot of beam failure recovery request transmission. Additionally, the default beam for the PDSCH reception can be the same as the beam used for the dedicated CORESET for the gNB response. If the UE is configured to monitor both the CORESET for the gNB response and the broadcast CORESETS, the default PDSCH beam can be configured to be the same as the beam used for the CORESET which delivers the DCI. If the UE is configured to monitor all of the CORESETs, the default PDSCH beam can be configured to be the beam used for the dedicated CORESET for gNB response or the default beam is the same as the beam used for the CORESET which delivers the DCI.

In one embodiment, after the UE sends the beam failure recovery request, if the UE receives DCI on the CORESET(s), except the dedicated CORESET for the gNB response, the UE can treat the received DCI as a notification that the link has been recovered. The UE can stop re-sending the following beam failure recovery requests if the UE does not receive the gNB response within a configured time window. The UE can then perform beam reporting and the gNB can refresh the TCI table for beam indication. If the UE receives a gNB response within a configured time window, the UE can follow the gNB response for the next procedures.

In one embodiment, the number of PT-RS antenna ports can be configured per TCI state, if the TCI is not present in the PDCCH, or the scheduling offset is below a threshold with the TCI present. In accordance, the number of phase tracking reference signal (PT-RS) antenna ports should always be 1 if PT-RS is configured. Further, the number of PT-RS antenna ports can be configured to not include the DCI in the dedicated CORESET for the beam failure recovery response. Additionally, the number of PT-RS antenna ports can be fixed, e.g.1or configured by higher layer signaling, before the reconfiguration/re-indication/activation of the CORESET.

Uplink Beam Indication

For PUCCH, a list of the spatial relations between the RS and the PUCCH is configured by the radio resource control (RRC) layer. Each entry of the list can be a synchronization signal block identification (SSB ID), or channel state information reference signal (CSI-RS) resource indicator CRI or spatial relation information (SRI). One or multiple SpatialRelationInfo information element (IE) is included in the list. A medium access control (MAC) control element (MAC-CE) can be used to provide spatial relation information for a PUCCH resource to one of the entries in the list. If the list includes only one SpatialRelationInfo IE, the UE applies the configured SpatialRelationInfo, where a MAC-CE is used.

In one embodiment, the RRC signal can be used to explicitly differentiate between SRS resource sets for beam management and SRS resource set for codebook/non-codebook based UL transmission. Thus, the SRS resource set for codebook or non-codebook based UL transmissions, can be configured for a similar beam indication to be introduced. In this case, the RRC signal can be used to configure the list of spatial relation between reference RS and SRS, and MAC-CE is used to activate one spatial relation information for one SRS resource.

In an embodiment, for the SRS resource set for codebook/non-codebook based UL transmission, a list of the spatial relation between the reference RS and SRS is configured by the RRC. Each entry of the list can be a SSB ID, or CRI or SRI. Additionally, one or multiple SpatialRelationInfo IE is included in the list. The MAC-CE can be configured to provide spatial relation information for an SRS resource to one of the entries in the list. If the list includes only one SpatialRelationInfo IE, the UE can apply the configured SpatialRelationInfo and the MAC-CE can be excluded from the configuration. The RRC can be used to maintain a plurality of uplink transfer (Tx) beams, wherein the UL Tx beams can be one of multiple SSB ID, CRI or SRI. Additionally, the MAC CE can be used to select N, where N>=1 Tx beams configured by RRC. As such, the beam indication can be configured per SRS resource, per SRS resource set, or per SRS antenna port.

In one embodiment, the PUSCH beam indication is delivered over the DCI. In instances where there is a delay of DCI decoding and UE beam switching, the time offset between the DCI and the application of the new Tx beam for PUSCH should be larger than a certain threshold. The threshold is determined by the DCI decoding delay and the UE beam switching delay and can be configured according to the UE capability.FIG. 7illustrates an example of the operation through the use of a PUSCH beam indication.

In one example, if the SRI is not included in the DCI or no SRS resource for codebook based or non-codebook based transmission is configured, the PUSCH beam indication can be based on the RRC and/or the MAC CE.

In one embodiment, the UE can report the capability for the delay of the DCI decoding and the UE Tx beam switching, and indicate the capability as a threshold, k. In one example, when the gNB sends a beam indication for PUSCH over the DCI, the time offset between the DCI and application of the new Tx beam for PUSCH can be larger than or equal to the threshold k.

FIG. 8depicts functionality800of a user equipment (UE) configured to perform beam failure recovery. The UE can comprise of one or more processors configured to encode a beam failure recovery (BFR) request for transmission on a physical random-access channel (PRACH) or a physical uplink control channel (PUCCH) to a next generation node B (gNB)810. The UE can comprise of one or more processors configured to monitor a dedicated physical downlink control channel (PDCCH) control resource set (CORESET) for a response from the gNB to the beam failure recovery request820. The UE can comprise of one or more processors configured to select a default physical downlink shared channel (PDSCH) beam, wherein it is assumed a same quasi co-location (QCL) assumption for a PDSCH as a QCL assumption for the dedicated PDCCH CORESET; a PDSCH demodulation reference signal (DMRS) is QCLed with a downlink (DL) reference signal (RS) of an identified candidate beam by the UE830. The UE can comprise of one or more processors configured to decode a beam failure recovery response from the gNB840.

In one embodiment, the one or more processors are further configured to assume the same QCL assumption for the PDSCH as the QCL assumption for the dedicated PDCCH CORESET after the UE starts to monitor the dedicated PDCCH CORESET for a response from the gNB to the beam failure recovery request.

In one embodiment, the one or more processors are further configured to assume the same QCL assumption for the PDSCH as the QCL assumption for the dedicated PDCCH CORESET after the UE transmits the beam failure recovery request.

In one embodiment, the one or more processors are further configured to assume the same QCL assumption for the PDSCH until a reconfiguration, or activation, or re-indication of a transmission configuration indicator (TCI) state for the PDCCH.

In one embodiment, the one or more processors are further configured to monitor a plurality of PDCCH CORESETs after transmitting the beam failure recovery request wherein monitoring comprises monitor only the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request, wherein a default PDSCH beam is a same beam used for the dedicated PDCCH CORESET for the gNB response. The one or more processors can further be configured to monitor a plurality of PDCCH CORESETs after transmitting the beam failure recovery request wherein monitoring comprises monitor, for a remaining minimum system information (RMSI), other system information (OSI), or paging, both the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request and one or more broadcast CORESETs, wherein the default PDSCH beam is a same beam used for a CORESET that includes downlink control information (DCI). The one or more processors can further be configured to monitor a plurality of PDCCH CORESETs after transmitting the beam failure recovery request wherein monitoring comprises monitor all configured CORESETs including the dedicated PDCCH CORESET for gNB response to beam failure recovery request, one or more broadcast CORESETs, and one or more previously configured unicast PDCCH CORESETs, wherein the default PDSCH beam is a PDCCH beam used for the dedicated PDCCH CORESET for the gNB response or the default PDSCH beam is the PDCCH beam used for the PDCCH CORSET that includes the DCI.

In one embodiment, the one or more processors are further configured to decode the DCI received on the PDCCH CORESET after the UE transmits the beam failure recovery request; determine that a link has been recovered based on the decoded DCI; cease re-sending a beam failure recovery request; and perform beam reporting to enable the gNB to refresh a transmission configuration indicator (TCI) table for beam indication.

In one embodiment, the one or more processors are further configured to monitor a plurality of PDCCH CORESETs; and determine a lowest CORESET identification (ID) by excluding a dedicated PDCCH CORESET used for sending the response to the BFR from the gNB to the UE from the plurality of PDCCH CORESETs.

FIG. 9illustrates architecture of a system900of a network in accordance with some embodiments. The system900is shown to include a user equipment (UE)901and a UE902. The UEs901and902are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

The UEs901and902may be configured to connect, e.g., communicatively couple, with a radio access network (RAN)910—the RAN910may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a Ne8Gen RAN (NG RAN), or some other type of RAN. The UEs901and902utilize connections903and904, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections903and904are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.

In this embodiment, the UEs901and902may further directly exchange communication data via a ProSe interface905. The ProSe interface905may alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

The UE902is shown to be configured to access an access point (AP)906via connection907. The connection907can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP906would comprise a wireless fidelity (WiFi®) router. In this example, the AP906is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).

The RAN910can include one or more access nodes that enable the connections903and904. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNB), RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The RAN910may include one or more RAN nodes for providing macrocells, e.g., macro RAN node911, and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low power (LP) RAN node912.

Any of the RAN nodes911and912can terminate the air interface protocol and can be the first point of contact for the UEs901and902. In some embodiments, any of the RAN nodes911and912can fulfill various logical functions for the RAN910including, 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, and mobility management.

The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs901and902. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs901and902about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE102within a cell) may be performed at any of the RAN nodes911and912based on channel quality information fed back from any of the UEs901and902. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs901and902.

The RAN910is shown to be communicatively coupled to a core network (CN)920—via an S1 interface913. In embodiments, the CN920may be an evolved packet core (EPC) network, a Next Gen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface913is split into two parts: the S1-U interface914, which carries traffic data between the RAN nodes911and912and the serving gateway (S-GW)922, and the S1-mobility management entity (MME) interface915, which is a signaling interface between the RAN nodes911and912and MMEs921.

In this embodiment, the CN920comprises the MMEs921, the S-GW922, the Packet Data Network (PDN) Gateway (P-GW)923, and a home subscriber server (HSS)924. The MMEs921may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs921may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS924may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The CN920may comprise one or several HSSs924, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS924can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

The S-GW922may terminate the S1 interface913towards the RAN910, and routes data packets between the RAN910and the CN920. In addition, the S-GW922may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

The P-GW923may terminate an SGi interface toward a PDN. The P-GW923may route data packets between the EPC network923and external networks such as a network including the application server930(alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface925. Generally, the application server930may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW923is shown to be communicatively coupled to an application server930via an IP communications interface925. The application server930can 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 UEs901and902via the CN920.

The P-GW923may further be a node for policy enforcement and charging data collection. Policy and Charging Enforcement Function (PCRF)926is the policy and charging control element of the CN920. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF926may be communicatively coupled to the application server930via the P-GW923. The application server930may signal the PCRF926to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF926may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server930.

FIG. 10illustrates example components of a device1000in accordance with some embodiments. In some embodiments, the device1000may include application circuitry1002, baseband circuitry1004, Radio Frequency (RF) circuitry1006, front-end module (FEM) circuitry1008, one or more antennas1010, and power management circuitry (PMC)1012coupled together at least as shown. The components of the illustrated device1000may be included in a UE or a RAN node. In some embodiments, the device1000may include less elements (e.g., a RAN node may not utilize application circuitry1002, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device1000may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

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

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

In some embodiments, the baseband circuitry1004may include one or more audio digital signal processor(s) (DSP)1004F. The audio DSP(s)1004F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry1004and the application circuitry1002may be implemented together such as, for example, on a system on a chip (SOC).

RF circuitry1006may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry1006may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry1006may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry1008and provide baseband signals to the baseband circuitry1004. RF circuitry1006may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry1004and provide RF output signals to the FEM circuitry1008for transmission.

In some embodiments, the mixer circuitry1006aof the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry1006dto generate RF output signals for the FEM circuitry1008. The baseband signals may be provided by the baseband circuitry1004and may be filtered by filter circuitry1006c.

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

The synthesizer circuitry1006dmay be configured to synthesize an output frequency for use by the mixer circuitry1006aof the RF circuitry1006based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry1006dmay be a fractional N/N+1 synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a necessity. Divider control input may be provided by either the baseband circuitry1004or the applications processor1002depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor1002.

FEM circuitry1008may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas1010, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry1006for further processing. FEM circuitry1008may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry1006for transmission by one or more of the one or more antennas1010. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry1006, solely in the FEM1008, or in both the RF circuitry1006and the FEM1008.

In some embodiments, the FEM circuitry1008may include a TX/RX switch to switch between transmit mode 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 to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry1006). The transmit signal path of the FEM circuitry1008may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry1006), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas1010).

In some embodiments, the PMC1012may manage power provided to the baseband circuitry1004. In particular, the PMC1012may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC1012may often be included when the device1000is capable of being powered by a battery, for example, when the device is included in a UE. The PMC1012may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

WhileFIG. 10shows the PMC1012coupled only with the baseband circuitry1004. However, in other embodiments, the PMC1012may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry1602, RF circuitry1006, or FEM1008.

In some embodiments, the PMC1012may control, or otherwise be part of, various power saving mechanisms of the device1000. For example, if the device1000is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device1000may power down for brief intervals of time and thus save power.

FIG. 11illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry1004ofFIG. 10may comprise processors1004A-1004E and a memory1004G utilized by said processors. Each of the processors1004A-1004E may include a memory interface,1104A-1104E, respectively, to send/receive data to/from the memory1004G.

The baseband circuitry1004may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface1112(e.g., an interface to send/receive data to/from memory external to the baseband circuitry1004), an application circuitry interface1114(e.g., an interface to send/receive data to/from the application circuitry1002ofFIG. 10), an RF circuitry interface1116(e.g., an interface to send/receive data to/from RF circuitry1006ofFIG. 10), a wireless hardware connectivity interface1118(e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface1110(e.g., an interface to send/receive power or control signals to/from the PMC1012.

FIG. 12also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen can be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to a user. The non-volatile memory port can also be used to expand the memory capabilities of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

EXAMPLES

The following examples pertain to specific technology embodiments and point out specific features, elements, or actions that can be used or otherwise combined in achieving such embodiments.

Example 1 includes an apparatus of a user equipment (UE) configured to perform beam failure recovery, the apparatus comprising: one or more processors configured to: encode a beam failure recovery (BFR) request for transmission on a physical random-access channel (PRACH) or a physical uplink control channel (PUCCH) to a next generation node B (gNB); monitor a dedicated physical downlink control channel (PDCCH) control resource set (CORESET) for a response from the gNB to the beam failure recovery request; select a default physical downlink shared channel (PDSCH) beam, wherein it is assumed, at the UE that: a same quasi co-location (QCL) assumption for a PDSCH as a QCL assumption for the dedicated PDCCH CORESET; or a PDSCH demodulation reference signal (DMRS) is QCLed with a downlink (DL) reference signal (RS) of an identified candidate beam by the UE; and decode a beam failure recovery request response from the gNB; and a memory interface configured to receive from a memory the QCL assumption.

Example 2 includes the apparatus of example 1, wherein the one or more processors are further configured to assume the same QCL assumption for the PDSCH as the QCL assumption for the dedicated PDCCH CORESET after the UE starts to monitor the dedicated PDCCH CORESET for a response from the gNB to the beam failure recovery request.

Example 3 includes the apparatus of example 1, wherein the one or more processors are further configured to assume the same QCL assumption for the PDSCH as the QCL assumption for the dedicated PDCCH CORESET after the UE transmits the beam failure recovery request.

Example 4 includes the apparatus of example 1, wherein the one or more processors are further configured to assume the same QCL assumption for the PDSCH until a reconfiguration, or activation, or re-indication of a transmission configuration indicator (TCI) state for the PDCCH.

Example 5 includes the apparatus of example 1, wherein the one or more processors are further configured to monitor a plurality of PDCCH CORESETs after transmitting the beam failure recovery request wherein monitoring comprises: monitor only the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request, wherein a default PDSCH beam is a same beam used for the dedicated PDCCH CORESET for the gNB response; monitor, for a remaining minimum system information (RMSI), other system information (OSI), or paging, both the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request and one or more broadcast CORESETs, wherein the default PDSCH beam is a same beam used for a CORESET that includes downlink control information (DCI); monitor all configured CORESETs including the dedicated PDCCH CORESET for gNB response to beam failure recovery request, one or more broadcast CORESETs, and one or more previously configured unicast PDCCH CORESETs, wherein the default PDSCH beam is a PDCCH beam used for the dedicated PDCCH CORESET for the gNB response or the default PDSCH beam is the PDCCH beam used for the PDCCH CORSET that includes the DCI.

Example 6 includes the apparatus of example 5, wherein the one or more processors are further configured to: decode the DCI received on the PDCCH CORESET after the UE transmits the beam failure recovery request; determine that a link has been recovered based on the decoded DCI; cease re-sending a beam failure recovery request; and perform beam reporting to enable the gNB to refresh a transmission configuration indicator (TCI) table for beam indication.

Example 7 includes the apparatus of example 1, wherein the one or more processors are further configured to: monitor a plurality of PDCCH CORESETs; and determine a lowest CORESET identification (ID) by excluding a dedicated PDCCH CORESET used for sending the response to the BFR from the gNB to the UE from the plurality of PDCCH CORESETs.

Example 8 includes an apparatus of a next generation node B (gNB) configured to send a physical downlink control channel (PDCCH) control resource set (CORESET), the apparatus comprising: one or more processors configured to: select a default physical downlink shared channel (PDSCH) beam, prior to receiving a beam failure recovery (BFR) request from a user equipment (UE) or sending a response to the BFR request to the UE, when a scheduling offset between a physical downlink control channel (PDCCH) and a PDSCH is smaller than a selected threshold, k, wherein k is a real number; a memory interface configured to send k to a memory.

Example 9 includes the apparatus of example 8, wherein the one or more processors are further configured to select the default PDSCH beam by excluding: a broadcast PDCCH CORESET, including a CORESET for remaining minimum system information (RMSI), or other system information (OSI), or paging.

Example 10 includes the apparatus of example 8, wherein the one or more processors are further configured to select the default PDSCH beam by excluding: a dedicated PDCCH CORESET used for sending the response to the BFR from the gNB to the UE.

Example 11 includes at least one machine readable storage medium having instructions embodied thereon for a user equipment (UE) configured to perform beam failure recovery, the instructions thereon when executed by one or more processors at the UE perform the following: encode a beam failure recovery (BFR) request for transmission on a physical random-access channel (PRACH) or a physical uplink control channel (PUCCH) to a next generation node B (gNB); monitor a dedicated physical downlink control channel (PDCCH) control resource set (CORESET) for a response from the gNB to the beam failure recovery request; select a default physical downlink shared channel (PDSCH) beam, wherein it is assumed, at the UE that: a same quasi co-location (QCL) assumption for a PDSCH as a QCL assumption for the dedicated PDCCH CORESET; or a PDSCH demodulation reference signal (DMRS) is QCLed with a downlink (DL) reference signal (RS) of an identified candidate beam by the UE; and decode a beam failure recovery request response from the gNB.

Example 12 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: assume the same QCL assumption for the PDSCH as the QCL assumption for the dedicated PDCCH CORESET after the UE starts to monitor the dedicated PDCCH CORESET for a response from the gNB to the beam failure recovery request.

Example 13 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: assume the same QCL assumption for the PDSCH as the QCL assumption for the dedicated PDCCH CORESET after the UE transmits the beam failure recovery request.

Example 14 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: assume the same QCL assumption for the PDSCH until a reconfiguration, or activation, or re-indication of a transmission configuration indicator (TCI) state for the PDCCH.

Example 15 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: monitor a plurality of PDCCH CORESETs after transmitting the beam failure recovery request wherein monitoring comprises: monitor only the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request, wherein a default PDSCH beam is a same beam used for the dedicated PDCCH CORESET for the gNB response; monitor, for a remaining minimum system information (RMSI), other system information (OSI), or paging, both the dedicated PDCCH CORESET for the gNB response to the beam failure recovery request and one or more broadcast CORESETs, wherein the default PDSCH beam is a same beam used for a CORESET that includes downlink control information (DCI); monitor all configured CORESETs including the dedicated PDCCH CORESET for gNB response to beam failure recovery request, one or more broadcast CORESETs, and one or more previously configured unicast PDCCH CORESETs, wherein the default PDSCH beam is a PDCCH beam used for the dedicated PDCCH CORESET for the gNB response or the default PDSCH beam is the PDCCH beam used for the PDCCH CORSET that includes the DCI.

Example 16 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: decode the DCI received on the PDCCH CORESET after the UE transmits the beam failure recovery request; determine that a link has been recovered based on the decoded DCI; cease re-sending a beam failure recovery request; and perform beam reporting to enable the gNB to refresh a transmission configuration indicator (TCI) table for beam indication.

Example 17 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: monitor a plurality of PDCCH CORESETs; and determine a lowest CORESET identification (ID) by excluding a dedicated PDCCH CORESET used for sending the response to the BFR from the gNB to the UE from the plurality of PDCCH CORESETs.

Example 18 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: select the default PDSCH beam when a scheduling offset between the PDCCH and the PDSCH is smaller than a selected threshold, k, wherein k is a real number before the gNB sends response to beam failure recovery request or before the gNB receives the beam failure recovery request.

Example 19 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: select the default PDSCH beam by excluding: a broadcast PDCCH CORESET, including a CORESET for remaining minimum system information (RMSI), or other system information (OSI), or paging.

Example 20 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: select the default PDSCH beam by excluding: a dedicated PDCCH CORESET (CORESET-BFR) for gNB response to the beam failure recovery request.

Example 21 includes the at least one machine readable storage medium in example 11, further comprising instructions, that when executed by one or more processors at the UE, perform the following: monitor the PDCCH CORESET(s) after transmitting the beam failure recovery request wherein monitoring comprises: monitor only the dedicated PDCCH CORESET (CORESET-BFR) for the gNB response to the beam failure recovery request, wherein a default PDSCH beam is a same beam used for the dedicated PDCCH CORESET (CORESET-BFR) for the gNB response; monitor both the dedicated PDCCH COREST (CORESET-BFR) for the gNB response to the beam failure recovery request and one or more broadcast CORESET(s), including one or more CORESET(s) for a remaining minimum system information (RMSI), other system information (OSI), or paging, wherein the default PDSCH beam is a same beam used for a CORESET that includes downlink control information (DCI); monitor all configured CORESETS including the dedicated PDCCH CORESET (CORESET-BFR) for gNB response to beam failure recovery request, one or more broadcast CORESETs, and one or more previously configured unicast PDCCH CORESETs, wherein the default PDSCH beam is a PDCCH beam used for the dedicated PDCCH CORESET for the gNB response or the default PDSCH beam is the PDCCH beam used for the PDCCH CORSET that includes the DCI.

Example 22 includes the at least one machine readable storage medium in example 21, further comprising instructions, that when executed by one or more processors at the UE, perform the following: decode the DCI received on the PDCCH CORESET after the UE transmits the beam failure recovery request; determine that a link has been recovered based on the decoded DCI; cease re-sending a beam failure recovery request; and perform beam reporting to enable the gNB to refresh a transmission configuration indicator (TCI) table for beam indication.

Example 23 includes at least one machine readable storage medium having instructions embodied thereon for a next generation node B (gNB) configured to send a physical downlink control channel (PDCCH) control resource set (CORESET), the instructions thereon when executed by one or more processors at the gNB perform the following: select a default physical downlink shared channel (PDSCH) beam, prior to receiving a beam failure recovery (BFR) request from a user equipment (UE) or sending a response to the BFR request to the UE, when a scheduling offset between a physical downlink control channel (PDCCH) and a PDSCH is smaller than a selected threshold, k, wherein k is a real number.

Example 24 includes at least one machine readable storage medium in example 23, further comprising instructions, that when executed by one or more processors at the gNB, perform the following: select the default PDSCH beam by excluding: a broadcast PDCCH CORESET, including a CORESET for remaining minimum system information (RMSI), or other system information (OSI), or paging.

Example 25 includes at least one machine readable storage medium in example 23, further comprising instructions, that when executed by one or more processors at the gNB, perform the following: select the default PDSCH beam by excluding: a dedicated PDCCH CORESET used for sending the response to the BFR from the gNB to the UE.