CN116896796A - Apparatus and method for beam fault recovery - Google Patents

Abstract

The present disclosure relates to an apparatus and method for beam fault recovery. An apparatus for a User Equipment (UE) includes processing circuitry configured to: encoding a beam fault indication for transmission to a first Access Node (AN) associated with a first frequency band, wherein the beam fault indication indicates a beam fault in a second frequency band; and decoding a Beam Fault Recovery (BFR) configuration message received from the first AN, wherein the BFR configuration message includes BFR configuration information received by the first AN from a second AN associated with the second frequency band.

Description

Apparatus and method for beam fault recovery

Priority statement

The present application is based on U.S. patent application Ser. No. 63/326,143, filed on 3/2022, and claims priority from that application, which is incorporated herein by reference in its entirety.

Technical Field

Embodiments of the present disclosure relate generally to wireless communications, and in particular, to an apparatus and method for Beam Fault Recovery (BFR).

Background

In current third generation partnership project (3 GPP) mobile communication technologies, such as Long Term Evolution (LTE) and New Radio (NR), the BFR procedure or mechanism for side information assisted cellular communication systems is important.

Disclosure of Invention

An aspect of the present disclosure provides an apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to: encoding a beam fault indication for transmission to a first Access Node (AN) associated with a first frequency band, wherein the beam fault indication indicates a beam fault in a second frequency band; and decoding a Beam Fault Recovery (BFR) configuration message received from the first AN, wherein the BFR configuration message includes BFR configuration information received by the first AN from a second AN associated with the second frequency band.

AN aspect of the present disclosure provides AN apparatus for a first Access Node (AN) associated with a first frequency band, wherein the apparatus comprises processing circuitry configured to: decoding an indication received from a User Equipment (UE) regarding beam faults in a second frequency band; encoding a beam fault message for transmission to a second AN associated with the second frequency band, wherein the beam fault message indicates a beam fault in the second frequency band; and encoding a Beam Fault Recovery (BFR) configuration message for transmission to the UE, wherein the BFR configuration message includes BFR configuration information received from the second AN.

AN aspect of the present disclosure provides AN apparatus for a second Access Node (AN) associated with a second frequency band, wherein the apparatus comprises processing circuitry configured to: decoding a beam fault message received from a first AN associated with a first frequency band, wherein the beam fault message indicates that a User Equipment (UE) has detected a beam fault in the second frequency band; and encoding Beam Fault Recovery (BFR) configuration information for transmission to the first AN.

An aspect of the present disclosure provides an apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to: a Beam Fault Recovery (BFR) request is encoded for transmission to a first Access Node (AN) associated with a first frequency band, wherein the BFR request indicates a beam fault in a second frequency band and a new best beam for the second frequency band, and the BFR request is further forwarded by the first AN to a second AN associated with the second frequency band.

An aspect of the present disclosure provides an apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to: after detecting a beam fault in a frequency band, determining a new best beam for the frequency band based on periodic beam measurements in the frequency band; and encoding a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam for transmission in a Random Access Channel (RACH) resource corresponding to the new best beam to AN Access Node (AN) associated with the frequency band.

Drawings

Embodiments of the present disclosure will now be described, by way of example and not limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

Fig. 1 illustrates an example architecture of a system according to some embodiments of the present disclosure.

Fig. 2 illustrates an example architecture of a system including a 5GC according to some embodiments of the present disclosure.

Fig. 3 illustrates a network according to some embodiments of the present disclosure.

Figure 4 shows the BFR process in NR.

Fig. 5 illustrates an example of a set of narrow beams in a higher frequency band covering the same spatial region as a wide beam in a lower frequency band, according to some embodiments of the present disclosure.

Fig. 6 illustrates a signaling flow diagram for Random Access (RA) for beam fault recovery using an initial access procedure, according to some embodiments of the present disclosure.

Fig. 7 illustrates an example medium access control element (MAC-CE) for notifying beam faults, according to some embodiments of the present disclosure.

Fig. 8 illustrates an example Information Element (IE) for transmitting a BFR configuration to a User Equipment (UE) in accordance with some embodiments of the present disclosure.

Fig. 9 illustrates an example MAC-CE for a User Equipment (UE) to transmit BFR configuration in accordance with some embodiments of the present disclosure.

Fig. 10 illustrates a signaling flow diagram for beam fault recovery in a secondary frequency band using a secondary frequency band to report an optimal beam in accordance with some embodiments of the present disclosure.

Fig. 11 illustrates an example MAC-CE for informing of a new best beam for a assisted band, according to some embodiments of the present disclosure.

Fig. 12 illustrates a signaling flow diagram for beam fault recovery in an assisted frequency band in the presence of periodic beam measurements in the assisted frequency band, according to some embodiments of the present disclosure.

Fig. 13 illustrates a signaling flow diagram of an RA for beam fault recovery in a assisted frequency band with both periodic beam measurements and periodic RACH resource allocation in the assisted frequency band, according to some embodiments of the present disclosure.

Fig. 14 illustrates a flow chart of a method for beam fault recovery according to some embodiments of the present disclosure.

Fig. 15 illustrates a flow chart of a method for beam fault recovery according to some embodiments of the present disclosure.

Fig. 16 illustrates a flow chart of a method for beam fault recovery according to some embodiments of the present disclosure.

Fig. 17 illustrates a flow chart of a method for beam fault recovery according to some embodiments of the present disclosure.

Fig. 18 illustrates a flow chart of a method for beam fault recovery according to some embodiments of the present disclosure.

Fig. 19 illustrates an example of an infrastructure device, according to some embodiments of the present disclosure.

Fig. 20 schematically illustrates a wireless network in accordance with various embodiments.

Fig. 21 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methods discussed herein, according to some example embodiments.

Detailed Description

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. However, it will be apparent to those skilled in the art that many alternative embodiments may be implemented using portions 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 may be 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 an embodiment," "in one embodiment," and "in some embodiments" are repeated herein. These phrases generally do not refer to the same embodiment; however, they may also refer to the same embodiments. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrases "A or B" and "A/B" mean "(A), (B), or (A and B)".

Fig. 1 illustrates an example architecture of a system 100 according to some embodiments of the disclosure. The following description is provided for an example system 100 that operates in conjunction with a Long Term Evolution (LTE) system standard and a 5G or New Radio (NR) system standard provided by a 3GPP Technical Specification (TS). However, the example embodiments are not limited in this respect and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, institute of Electrical and Electronics Engineers (IEEE) 802.16 protocols (e.g., wireless Metropolitan Area Network (MAN), worldwide Interoperability for Microwave Access (WiMAX), etc.), and so forth.

As shown in fig. 1, the system 100 may include a UE 101a and a UE 101b (collectively referred to as UE(s) 101 "). As used herein, the term "user equipment" or "UE" may refer to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio, reconfigurable mobile, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface. In this example, the UE 101 is shown as a smart phone (e.g., a handheld touch screen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronics devices, cellular phones, smart phones, feature phones, tablet computers, wearable computer devices, personal Digital Assistants (PDAs), pagers, wireless handheld devices, desktop computers, notebook computers, in-Vehicle Infotainment Systems (IVIs), in-vehicle entertainment (ICE) devices, dashboards (Instrument Cluster, ICs), heads-up display (HUD) devices, in-vehicle diagnostic (OBD) devices, dashboard mobile Devices (DME), mobile Data Terminals (MDT), electronic Engine Management Systems (EEMS), electronic/Engine Control Units (ECU), electronic/Engine Control Modules (ECM), embedded systems, microcontrollers, control modules, engine Management Systems (EMS), or "smart" devices, machine-type communication (MTC) devices, machine-to-machine (M2M), internet of things (IoT) devices, and/or the like.

In some embodiments, any of the UEs 101 may include an 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 M2M or MTC to exchange data with MTC servers or devices via PLMNs, proximity-based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks. The data exchange of M2M or MTC 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 connections. The IoT UE may execute a background application (e.g., keep-alive message, status update, etc.) to facilitate connection of the IoT network.

UE 101 may be configured to connect (e.g., communicatively couple) with RAN 110. In an embodiment, RAN 110 may be a Next Generation (NG) RAN or a 5G RAN, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN) or a legacy RAN, such as a UTRAN (UMTS terrestrial radio access network) or a GERAN (GSM (global system for Mobile communications or group Sp service Mobile) EDGE (GSM evolution) radio access network). As used herein, the term "NG RAN" or the like may refer to RAN 110 operating in NR or 5G system 100, and the term "E-UTRAN" or the like may refer to RAN 110 operating in LTE or 4G system 100. The UE 101 utilizes connections (or channels) 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" may refer to any tangible or intangible transmission medium for transmitting data or a data stream. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term indicating a path or medium through which data is transmitted. In addition, the term "link" may refer to a connection between two devices for the purpose of transmitting and receiving information via a Radio Access Technology (RAT).

In this example, connections 103 and 104 are shown as air interfaces to enable communicative coupling, and may be consistent with cellular communication protocols, such as global system for mobile communications (GSM) protocols, code Division Multiple Access (CDMA) network protocols, push-to-talk (PTT) protocols, push-to-cellular PTT (POC) protocols, universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, fifth generation (5G) protocols, new Radio (NR) protocols, and/or any other communication protocols discussed herein. In an embodiment, the UE 101 may exchange communication data directly via the ProSe interface 105. ProSe interface 105 may alternatively be referred to as a Sidelink (SL) interface 105 and may include 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).

The UE 101b is shown configured to access an Access Point (AP) 106 (also referred to as a "WLAN node 106", "WLAN terminal 106", or "WT 106", etc.) via a connection 107. Connection 107 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 106 would comprise a wireless fidelity (WiFi) router. In this example, the AP 106 is shown connected to the internet and not to the core network of the wireless system (described in further detail below). In various embodiments, the UE 101b, RAN 110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operation and/or WLAN LTE/WLAN radio level integration (LWIP) operation with IPsec tunneling. The LWA operation may involve the UE 101b in rrc_connected being configured by the RAN node 111 to utilize radio resources of LTE and WLAN. LWIP operations may involve the UE 101b using WLAN radio resources (e.g., connection 107) to authenticate and encrypt packets (e.g., internet Protocol (IP) packets) sent over connection 107 via an internet protocol security (IPsec) protocol tunnel. IPsec tunnels may include encapsulating the entire original IP packet and adding a new packet header, protecting the original header of the IP packet.

RAN 110 may include one or more RAN nodes 111a and 111b (collectively referred to as RAN node(s) 111 ") that enable connections 103 and 104. As used herein, the terms "Access Node (AN)", "access point", "RAN node", and the like may describe devices that provide radio baseband functionality for data and/or voice connections between a network and one or more users. These access nodes may be referred to as Base Stations (BS), next generation node BS (gNB), RAN nodes, evolved nodebs (enbs), nodebs, roadside units (RSUs), transmission reception points (TRxP or TRP), and the like, and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., cell). As used herein, the term "NG RAN node" or the like may refer to a RAN node 111 (e.g., a gNB) operating in an NR or 5G system 100, and the term "E-UTRAN node" or the like may refer to a RAN node 111 (e.g., an eNB) operating in an LTE or 4G system 100. According to various embodiments, RAN node 111 may be implemented as one or more dedicated physical devices such as a macrocell base station and/or a Low Power (LP) base station for providing a femtocell, picocell, or other similar cell with smaller coverage area, smaller user capacity, or higher bandwidth than the macrocell.

In some embodiments, all or part of RAN node 111 may be implemented as part of a virtual network as one or more software entities running on a server computer, which may be referred to as a Cloud Radio Access Network (CRAN) and/or virtual baseband unit pool (vBBUP). In these embodiments, CRAN or vBBUP may implement RAN functional partitioning, such as: PDCP partitioning, wherein RRC and PDCP layers are operated by CRAN/vbup, while other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC/PHY partitioning, where RRC, PDCP, RLC and MAC layers are operated by CRAN/vbup and PHY layers are operated by individual RAN nodes 111; or "lower PHY" split, where RRC, PDCP, RLC, MAC layers and upper portions of the PHY layers are operated by CRAN/vBBUP and lower portions of the PHY layers are operated by individual RAN nodes 111. The virtualization framework allows freeing up the processor cores of RAN node 111 to execute other virtualized applications. In some implementations, individual RAN node 111 may represent an individual gNB-DU connected to the gNB-CU via an individual F1 interface (not shown in fig. 1). In these implementations, the gNB-DU may include one or more remote radio heads or Radio Front End Modules (RFEM), and the gNB-CU may be operated by a server (not shown) located in RAN 110 or by a server pool in a similar manner as CRAN/vbBup. Additionally or alternatively, one or more RAN nodes 111 may be a next generation eNB (NG-eNB), which is a RAN node providing E-UTRA user plane and control plane protocol termination to the UE 101, and which is connected to the 5GC via an NG interface.

In a V2X scenario, one or more RAN nodes 111 may be or act as an RSU. The term "roadside unit" or "RSU" may refer to any transport infrastructure entity for V2X communication. The RSUs may be implemented in or by suitable RAN nodes or fixed (or relatively stationary) UEs, wherein RSUs implemented in or by UEs may be referred to as "UE-type RSUs", RSUs implemented in or by enbs may be referred to as "eNB-type RSUs", RSUs implemented in or by gnbs may be referred to as "gNB-type RSUs", etc. In one example, an RSU is a computing device coupled with a radio frequency circuit located at the roadside that provides connectivity support for a passing vehicle UE 101 (vUE 101). The RSU may also include internal data storage circuitry for storing junction map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate over the 5.9GHz Direct Short Range Communication (DSRC) band to provide very low latency communications required for high speed events, such as avoiding collisions, traffic warnings, and the like. Additionally or alternatively, the RSU may operate on the cellular V2X frequency band to provide the low-latency communications described above, as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a WiFi hotspot (2.4 GHz band) and/or provide connectivity to one or more cellular networks to provide uplink and downlink communications. The computing device(s) and some or all of the radio frequency circuitry of the RSU may be enclosed in a weather-proof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired (e.g., ethernet) connection with the traffic signal controller and/or the backhaul network.

Any RAN node 111 may terminate the air interface protocol and may be the first point of contact for the UE 101. In some embodiments, any RAN node 111 may satisfy various logical functions of RAN 110 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, and mobility management.

In embodiments, UE 101 may be configured to communicate with each other or any RAN node 111 over a multicarrier communication channel using Orthogonal Frequency Division Multiplexing (OFDM) communication signals in accordance with 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-link communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may comprise a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any RAN node 111 to the UE 101, while uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource of 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 the resource grid is denoted as 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 be currently allocated. There are several different physical downlink channels transmitted using such resource blocks.

According to various embodiments, UE 101 and RAN node 111 transmit (e.g., send and receive) data over a licensed medium (also referred to as "licensed spectrum" and/or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum and/or" unlicensed band "). The licensed spectrum may include channels operating in a frequency range of about 400MHz to about 3.8GHz, while the unlicensed spectrum may include the 5GHz band.

To operate in unlicensed spectrum, the UE 101 and RAN node 111 may operate using Licensed Assisted Access (LAA), enhanced LAA (eLAA), and/or other eLAA (feLAA) mechanisms. In these implementations, the UE 101 and RAN node 111 may perform one or more known media sensing operations and/or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied prior to transmission in the unlicensed spectrum. The medium/carrier sensing operation may be performed according to a Listen Before Talk (LBT) protocol.

LBT is a mechanism in which a device (e.g., UE 101, RAN node 111,112, etc.) senses a medium (e.g., channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include a Clear Channel Assessment (CCA) that utilizes at least Energy Detection (ED) to determine whether other signals are present on the channel to determine whether the channel is occupied or clear. The LBT mechanism allows the cellular/LAA network to coexist with incumbent systems in the unlicensed spectrum and with other LAA networks. ED may include sensing Radio Frequency (RF) energy over an expected transmission band for a period of time and comparing the sensed RF energy to a predetermined or configured threshold.

In general, incumbent systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLAN employs a contention-based channel access mechanism called carrier sense multiple access with collision avoidance (CSMA/CA). Here, when a WLAN node (e.g., a Mobile Station (MS) such as UE 101, AP 106) intends to transmit, the WLAN node may first perform CCA before transmitting. In addition, a back-off mechanism is used to avoid collisions in the case where more than one WLAN node senses the channel as idle and transmits simultaneously. The backoff mechanism may be a counter that is randomly drawn within the Contention Window Size (CWS), which increases exponentially when collisions occur and is reset to a minimum when the transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA/CA for WLAN. In some implementations, the LBT procedure for DL or UL transmission bursts comprising PDSCH or PUSCH transmissions, respectively, may have LAA contention window of variable length between X and Y extended CCA (ECCA) slots, where X and Y are minimum and maximum values of CWS for the LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μs); however, the size of the CWS and the Maximum Channel Occupancy Time (MCOT) (e.g., transmission burst) may be based on government regulatory requirements.

LAA mechanisms are established based on Carrier Aggregation (CA) technology of LTE-Advanced (LTE-Advanced) systems. In CA, each aggregated carrier is referred to as a Component Carrier (CC). CCs may have bandwidths of 1.4, 3, 5, 10, 15, or 20MHz, and may aggregate up to five CCs, thus the maximum aggregate bandwidth is 100MHz. In a Frequency Division Duplex (FDD) system, the number of aggregated carriers may be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, individual CCs may have different bandwidths than other CCs. In a Time Division Duplex (TDD) system, the number of CCs and the bandwidth of each CC are typically the same for DL and UL.

The CA also includes a separate serving cell to provide a separate CC. The coverage of the serving cell may be different, for example, because CCs on different frequency bands will experience different path losses. A primary serving cell or primary cell (PCell) may provide a primary CC (PCC) for both UL and DL, and may handle Radio Resource Control (RRC) and non-access stratum (NAS) related activities. Other serving cells are referred to as secondary cells (scells), and each SCell may provide a separate secondary CC (SCC) for both UL and DL. SCCs may be added and removed as needed, while changing PCC may require UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all scells may operate in unlicensed spectrum (referred to as "LAA scells"), and the LAA scells are assisted by PCell operating in licensed spectrum. When the UE is configured with more than one LAA SCell, the UE may receive a UL grant on the configured LAA SCell indicating a different Physical Uplink Shared Channel (PUSCH) starting location within the same subframe.

A Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to the UE 101. 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 the UE 101 about transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (allocation of control and shared channel resource blocks to UEs 101b within a cell) may be performed at any RAN node 111 based on channel quality information fed back from any UE 101. The downlink resource allocation information may be transmitted on a PDCCH for (e.g., allocated to) each UE 101.

The PDCCH may use a Control Channel Element (CCE) to convey control information. The PDCCH complex-valued symbols may first be organized into quadruples before being mapped to resource elements, which may then be permuted 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 sets of four physical resource elements called 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 may be defined in LTE (e.g., aggregation level, l=1, 2, 4, or 8).

Some embodiments may use a concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may use 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 the above, each ECCE may correspond to nine sets of four physical resource elements referred to as Enhanced Resource Element Groups (EREGs). In some cases, ECCEs may have other amounts of EREGs.

RAN nodes 111 may be configured to communicate with each other via interface 112. In embodiments where the system 100 is an LTE system, the interface 112 may be an X2 interface 112. The X2 interface may be defined between two or more RAN nodes 111 (e.g., two or more enbs, etc.) connected to EPC 120 and/or two enbs connected to EPC 120. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface and may be used to communicate information about user data transfer between enbs. For example, X2-U may provide specific sequence number information for user data transmitted from a master eNB (MeNB) to a secondary eNB (SeNB); information about successful sequential transmission of PDCP PDUs from the SeNB to the UE 101 for user data; information of PDCP PDUs not delivered to the UE 101; information about a current minimum required buffer size at the SeNB for data sent to the UE user; etc. X2-C may provide LTE access mobility functions including context transfer from source eNB to target eNB, user plane transfer control, etc.; a load management function; inter-cell interference coordination function.

In embodiments where system 100 is a 5G or NR system, interface 112 may be an Xn interface 112. An Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gnbs, etc.) connected to the 5gc 120, between a RAN node 111 (e.g., a gNB) connected to the 5gc 120 and an eNB, and/or between two enbs connected to the 5gc 120. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U may provide for the unsecured transport of user plane PDUs and support/provide data forwarding and flow control functions. Xn-C may provide: management and error handling functions; managing the function of the Xn-C interface; mobility support for UEs 101 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality to manage UE mobility for CONNECTED modes between one or more RAN nodes 111. Mobility support may include context transfer from an old (source) serving RAN node 111 to a new (target) serving RAN node 111; and control of user plane tunnels between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of an Xn-U may include a transport network layer built on top of an Internet Protocol (IP) transport layer, and a GTP-U layer above the UDP and/or IP layer(s) for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol, referred to as the Xn application protocol (Xn-AP), and a transport network layer built on SCTP. SCTP may be located above the IP layer and may provide for the vouching transfer of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack and/or the Xn-C protocol stack may be the same as or similar to the user plane(s) and/or control plane protocol stack(s) shown and described herein.

RAN 110 is shown communicatively coupled to a core network, in this embodiment Core Network (CN) 120.CN 120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UE 101) connected to CN 120 through RAN 110. The term "network element" may describe a physical or virtualized device for providing wired or wireless communication network services. The term "network element" may be considered synonymous with and/or referred to as: networked computers, network hardware, network devices, routers, switches, hubs, bridges, radio network controllers, radio access network devices, gateways, servers, virtualized Network Functions (VNFs), network Function Virtualization Infrastructure (NFVI), and/or the like. The components of the CN 120 may be implemented in one physical node or in a separate physical node, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, network Function Virtualization (NFV) may be used to virtualize any or all of the above-described network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. The logical instantiation of the CN 120 may be referred to as a network slice, and the logical instantiation of a portion of the CN 120 may be referred to as a network sub-slice. NFV architecture and infrastructure can be used to virtualize one or more network functions or be executed by dedicated hardware onto physical resources including industry standard server hardware, storage hardware, or a combination of switches. In other words, NFV systems may be used to perform virtual or reconfigurable implementations of one or more EPC components/functions.

In general, the application server 130 may be an element that provides an application that uses IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). The application server 130 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 UE 101 via the EPC 120.

In an embodiment, CN 120 may be 5GC (referred to as "5GC 120" or the like), and RAN 110 may be connected with CN 120 via NG interface 113. In an embodiment, NG interface 113 may be split into two parts: a NG user plane (NG-U) interface 114 that carries traffic data between RAN node 111 and User Plane Functions (UPFs); and an S1 control plane (NG-C) interface 115, which is a signaling interface between RAN node 111 and the AMF.

In an embodiment, the CN 120 may be a 5G CN (referred to as "5gc 120" or the like), while in other embodiments, the CN 120 may be an Evolved Packet Core (EPC). In the case where CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 may connect with CN 120 via S1 interface 113. In an embodiment, the S1 interface 13 may be divided into two parts: an S1 user plane (S1-U) interface 114 that carries traffic data between RAN node 111 and a serving gateway (S-GW); and an S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN node 111 and the MME.

Fig. 2 illustrates an example architecture of a system 200 including a 5gc 220, according to some embodiments of the present disclosure.

The system 200 is shown as comprising: UE 201, which may be the same as or similar to UE 101 previously discussed; (R) AN 210, which may be the same as or similar to RAN 110 discussed previously, and may include RAN node 111 discussed previously; and a Data Network (DN) 203, which may be, for example, an operator service, internet access, or a third party service; and a 5G core network (5 GC or CN) 220.

The 5gc 220 may include an authentication server function (AUSF) 222; an access and mobility management function (AMF) 221; session Management Function (SMF) 224; network Exposure Function (NEF) 223; policy Control Function (PCF) 226; a Network Function (NF) repository function (NRF) 225; unified Data Management (UDM) 227; an Application Function (AF) 228; a User Plane Function (UPF) 202; and a Network Slice Selection Function (NSSF) 229.

The UPF 202 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session interconnect point to DN 203, and a branching point to support multi-homed PDU sessions. The UPF 202 may also perform packet routing and forwarding, packet inspection, policy rules for user plane parts, lawful interception packets (UP sets), traffic usage reporting, qoS processing (e.g., packet filtering, gating, UL/DL rate enforcement) for the user plane, uplink traffic verification (e.g., SDF to QoS traffic mapping), transmission level packet marking in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 202 may include an uplink classifier for supporting routing traffic flows to the data network. DN 203 may represent various network operator services, internet access, or third party services. DN 203 can include or be similar to application server 130 discussed previously. The UPF 202 can interact with the SMF 224 via an N4 reference point between the SMF 224 and the UPF 202.

The AUSF 222 may store data for authentication of the UE 201 and process authentication related functions. The AUSF 222 may facilitate a common authentication framework for various access types. The AUSF 222 may communicate with the AMF 221 via an N12 reference point between the AMF 221 and the AUSF 222; and may communicate with UDM 227 via an N13 reference point between UDM 227 and AUSF 222. In addition, AUSF 222 may expose a Nausf service-based interface.

The AMF 221 may be responsible for registration management (e.g., for registering the UE 201, etc.), connection management, reachability management, mobility management, and lawful interception of AMF related events, as well as access authentication and authorization. AMF 221 may be the termination point of the N11 reference point between AMF 221 and SMF 224. The AMF 221 may provide for the transmission of Session Management (SM) messages between the UE 201 and the SMF 224 and act as a transparent proxy for routing SM messages. The AMF 221 may also provide for transmission of Short Message Service (SMS) messages between the UE 201 and an SMS function (SMSF) (not shown in fig. 2). The AMF 221 may act as a secure anchor function (SEA), which may include interactions with the AUSF 222 and the UE 201, receiving an intermediate key established as a result of the UE 201 authentication procedure. In the case of using USIM-based authentication, the AMF 221 may acquire security material from the AUSF 222. The AMF 221 may also include a Security Context Management (SCM) function that receives its keys from the SEA for deriving access network specific keys. Furthermore, AMF 221 may be AN end point of the RAN CP interface, which may include or be AN N2 reference point between (R) AN 211 and AMF 221; the AMF 221 may be the termination point of NAS (N1) signaling and perform NAS ciphering and integrity protection.

The AMF 221 may also support NAS signaling with the UE 201 through an N3 interworking function (IWF) interface. The N3IWF may be used to provide access to untrusted entities. The N3IWF may be AN end point for the N2 interface between the (R) AN 210 and the AMF 221 of the control plane and may be AN end point for the N3 reference point between the (R) AN 210 and the UPF 202 of the user plane. In this way, AMF 221 may process N2 signaling from SMF 224 and AMF 221 for PDU sessions and QoS, encapsulate/decapsulate packets for IPSec and N3 tunneling, label the N3 user plane packets in the uplink, and perform QoS corresponding to the N3 packet labels, taking into account the QoS requirements associated with such labels received over N2. The N3IWF may also relay uplink and downlink control plane NAS signaling between the UE 201 and the AMF 221 via the N1 reference point between the UE 201 and the AMF 221, and relay uplink and downlink user plane packets between the UE 201 and the UPF 202. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 201. AMFs 221 may expose interfaces based on Namf services and may be the termination point of the N14 reference point between two AMFs 221 and the N17 reference point between AMFs 221 and a 5G device identification register (5G-EIR) (not shown in FIG. 2).

UE 201 may need to register with AMF 221 to receive network services. Registration Management (RM) is used to register or de-register UE 201 with a network (e.g., AMF 221) and establish a UE context in the network (e.g., AMF 221). UE 201 may operate in a RM registration state or a RM deregistration state. In the RM deregistration state, the UE 201 is not registered with the network, and the UE context in the AMF 221 does not hold valid location or routing information of the UE 201, so the AMF 221 cannot reach the UE 201. In the RM registration state, the UE 201 registers with the network, and the UE context in the AMF 221 may hold valid location or routing information of the UE 201 so that the UE 201 may be reached by the AMF 221. In the RM registration state, UE 201 may perform a mobility registration update procedure, perform a periodic registration update procedure triggered by expiration of a periodic update timer (e.g., informing the network that UE 201 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

AMF 221 may store one or more RM contexts for UE 201, where each RM context is associated with a particular access to the network. The RM context may be a data structure, database object, etc., that indicates or stores the registration status and periodic update timer, etc., for each access type. The AMF 221 may also store a 5GC MM context, which may be the same as or similar to the (E) MM context previously discussed. In various embodiments, AMF 221 may store CE mode B restriction parameters for UE 201 in an associated MM context or RM context. The AMF 221 may also derive the value from the usage setting parameters of the UE that have been stored in the UE context (and/or MM/RM context) when needed.

Connection Management (CM) may be used to establish and release signaling connections between UE 201 and AMF 221 over the N1 interface. The signaling connection is used to enable NAS signaling exchange between UE 201 and CN 120 and includes AN signaling connection (e.g., RRC connection or UE-N3IWF connection for non-3 GPP) between the UE and AN Access Network (AN) and AN N2 connection for UE 201 between the AN (e.g., RAN 210) and AMF 221. The UE 201 may operate in one of two CM states: CM IDLE (CM-IDLE) mode or CM CONNECTED (CM-CONNECTED) mode. When the UE 201 is operating in CM-IDLE state/mode, the UE 201 may not have a NAS signaling connection established with the AMF 221 over the N1 interface and there may be (R) AN 210 signaling connections (e.g., N2 and/or N3 connections) for the UE 201. When the UE 201 is operating in CM-CONNECTED state/mode, the UE 201 may have a NAS signaling connection established with the AMF 221 over the N1 interface and there may be (R) AN 210 signaling connections (e.g., N2 and/or N3 connections) for the UE 201. Establishing AN N2 connection between the (R) AN 210 and the AMF 221 may cause the UE 201 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and when N2 signaling between the (R) AN 210 and the AMF 221 is released, the UE 201 may transition from the CM-CONNECTED mode to the CM-IDLE mode.

The SMF 224 may be responsible for: session Management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address allocation and management (including optional authorization); selecting and controlling the UP function; configuring traffic steering at the UPF to route traffic to the correct destination; terminating the interface to the policy control function; control policy enforcement and a portion of QoS; lawful interception (for SM events and interfaces to LI systems); terminating the NAS message of the SM section; downlink data notification; the initiator of the AN specific SM information is sent to the AN through the AMF by N2; the SSC pattern of the session is determined. SM may refer to the management of PDU sessions, which may refer to PDU connectivity services that provide or enable PDU exchanges between the UE 201 and a Data Network (DN) 203 identified by a Data Network Name (DNN). The PDU session may be established at the request of UE 201, modified at the request of UE 201 and 5gc 220, and released using NAS SM signaling exchanged on the N1 reference point between UE 201 and SMF 224 at the request of UE 201 and 5gc 220. Based on the request from the application server, the 5gc 220 can trigger a specific application in the UE 201. In response to receiving the trigger message, the UE 201 may communicate the trigger message (or related portions/information of the trigger message) to one or more identified applications in the UE 201. The identified application(s) in the UE 201 may establish a PDU session to a particular DNN. The SMF 224 may check whether the UE 201 request meets user subscription information associated with the UE 201. In this regard, the SMF 224 may retrieve and/or request update notifications from the UDM 227 regarding SMF 224-level subscription data.

The SMF 224 may include the following roaming functions: processing a local implementation to apply a QoS SLA (VPLMN); a billing data collection and billing interface (VPLMN); lawful interception (in the interface of the VPLMN and LI system of SM events); interactions with external DNs are supported to transport signaling of PDU session authorization/authentication through the external DNs. An N16 reference point between two SMFs 224 may be included in the system 200 that may be between another SMF 224 in the visited network and an SMF 224 in the home network in the roaming scenario. In addition, the SMF 224 may expose an interface based on the Nsmf service.

NEF 223 may provide means for securely exposing services and capabilities provided by 3GPP network functions for third parties, internal exposure/re-exposure, application functions (e.g., AF 228), edge computing or fog computing systems, and the like. In such embodiments, NEF 223 may authenticate, authorize, and/or limit AF. NEF 223 may also convert information exchanged with AF 228 and information exchanged with internal network functions. For example, the NEF 223 may convert between an AF service identifier and internal 5GC information. NEF 223 can also receive information from other Network Functions (NF) based on their exposed capabilities. This information may be stored as structured data in the NEF 223 or stored in the data storage NF using a standardized interface. The stored information may then be re-exposed to other NFs and AFs by NEF 223 and/or used for other purposes, such as analysis. In addition, NEF 223 may expose an interface based on Nnef services.

The NRF 225 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of the discovered NF instances to the NF instances. NRF 225 also maintains information of available NF instances and services supported thereby. As used herein, the term "instantiation" and the like may refer to the creation of an instance, and "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. In addition, NRF 225 may expose an interface based on Nnrf services.

PCF 226 may provide policy rules to control plane function(s) to implement them and may also support a unified policy framework to manage network behavior. PCF 226 may also implement a Front End (FE) to access subscription information related to policy decisions in the UDR of UDM 227. PCF 226 may communicate with AMF 221 via an N15 reference point between PCF 226 and AMF 221, which may include PCF 226 in the visited network and AMF 221 in a roaming scenario. PCF 226 may communicate with AF 228 via an N5 reference point between PCF 226 and AF 228; and communicates with SMF 224 via an N7 reference point between PCF 226 and SMF 224. System 200 and/or CN 120 may also include an N24 reference point between PCF 226 (in the home network) and PCF 226 in the visited network. In addition, PCF 226 may expose an interface based on the Npcf service.

The UDM 227 may process subscription related information to support the processing of communication sessions by network entities and may store subscription data for the UE 201. For example, subscription data may be transferred between UDM 227 and AMF 221 via an N8 reference point (not shown in fig. 2) between UDM 227 and AMF 221. UDM 227 may include two parts: the FE and unified data store (UDR) are applied (FE and UDR are not shown in fig. 2). UDR may store subscription data and policy data for UDM 227 and PCF 226, and/or structured data and application data for exposure (including Packet Flow Description (PFD) for application detection, application request information for multiple UEs 201) for NEF 223. UDR 221 may expose an interface based on the Nudr service to allow UDM 227, PCF 226, and NEF 223 to access a particular set of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of related data changes in the UDR. The UDM may include a UDM FE that is responsible for the handling of credentials, location management, subscription management, etc. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing; user identification processing; access authorization; registration/mobility management; and subscription management. UDR may interact with SMF 224 via an N10 reference point between UDM 227 and SMF 224. The UDM 227 may also support SMS management, where SMS-FEs implement similar application logic as previously described. In addition, UDM 227 may expose a Nudm service based interface.

The AF 228 may provide application impact on traffic routing, access Network Capability Exposure (NCE), and interact with policy frameworks for policy control. NCE may be a mechanism that allows 5gc 220 and AF 228 to provide information to each other via NEF 223, which may be used for edge computing implementations. In such an implementation, network operators and third party services may be hosted close to the UE 201 access point to enable efficient service delivery with reduced end-to-end delay and load on the transport network. For edge computing implementations, the 5GC may select the UPF 202 close to the UE 201 and perform traffic steering from the UPF 202 to the DN 203 via the N6 interface. This may be based on the UE subscription data, the UE location and the information provided by AF 228. In this way, AF 228 may affect UPF (re) selection and traffic routing. Based on the operator deployment, the network operator may allow the AF 228 to interact directly with the associated NF when the AF 228 is considered a trusted entity. In addition, AF 228 may expose an interface based on Naf services.

NSSF 229 may select a set of network slice instances to serve UE 201. NSSF 229 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and a mapping to subscribed single NSSAI (S-NSSAI), if desired. NSSF 229 may also determine a list of candidate AMFs 221 or a set of AMFs for serving UE 201 based on a suitable configuration and possibly by querying NRF 225. Selection of a set of network slice instances for UE 201 may be triggered by AMF 221 (which registers UE 201 by interacting with NSSF 229), which may result in a change of AMF 221. NSSF 229 may interact with AMF 221 via an N22 reference point between AMF 221 and NSSF 229; and may communicate with another NSSF 229 in the visited network via an N31 reference point (not shown in fig. 2). In addition, NSSF 229 may expose an interface based on the Nnssf service.

As previously described, the 5gc 220 may include SMSF, which may be responsible for SMS subscription checking and authentication, and relay SM messages from other entities to the UE 201/relay SM messages from the UE 201 to other entities, which may be, for example, SMS-GMSC/IWMSC/SMS routers. SMS may also interact with AMF 221 and UDM 227 for notification procedures that UE 201 is available for SMS delivery (e.g., setting a UE unreachable flag and notifying UDM 227 when UE 201 is available for SMS).

The 5GC 220 may also include other elements not shown in FIG. 2, such as a data storage system/architecture, a 5G device identity register (5G-EIR), a Secure Edge Protection Proxy (SEPP), and the like. The data storage system may include a structured data storage network function (SDSF), an unstructured data storage network function (UDSF), and so forth. Any NF may store unstructured data into or retrieve unstructured data (e.g., UE context) from the UDSF via an N18 reference point (not shown in fig. 2) between any NF and the UDSF. Individual NFs may share a UDSF for storing their respective unstructured data, or individual NFs may each have their own UDSF located at or near the individual NFs. In addition, the UDSF may expose an interface based on Nudsf services (not shown in fig. 2). The 5G-EIR may be NF, which checks the status of a permanent device identifier (PEI) to determine if a particular device/entity is blacklisted from the network; the SEPP may be a non-transparent proxy that performs topology hiding, message filtering, and policing over the inter-PLMN control plane interface.

In addition, there may be more reference points and/or service-based interfaces between NF services in the NF; however, these interfaces and reference points are omitted from fig. 2 for clarity. In one example, the 5gc 220 may include an Nx interface, which is an inter-CN interface between the MME and the AMF 221 to enable interworking between the EPC and the 5gc 220. Other example interfaces/references these points may include an N5G-EIR service-based interface exposed by a 5G-EIR, an N27 reference point between an NRF in the visited network and an NRF in the home network; and an N31 reference point between the NSSF in the visited network and the NSSF in the home network.

Fig. 3 shows a diagram of a network 300 according to various embodiments of the present disclosure. The network 300 may operate in a manner consistent with the 3GPP technical specifications of LTE or 5G/NR systems. However, the example embodiments are not limited in this respect and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems and the like.

The network 300 may include a UE 302 that may include any mobile or non-mobile computing device designed to communicate with a RAN 304 via an over-the-air connection. The UE 302 may be, but is not limited to, a smart phone, tablet, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, instrument cluster, heads-up display device, on-vehicle diagnostic device, dashboard mobile device, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networking appliance, machine-type communication device, M2M or D2D device, internet of things device, etc.

In some embodiments, the network 300 may include multiple UEs directly coupled to each other through a side link interface. The UE may be an M2M/D2D device that communicates using a physical side link channel (e.g., without limitation, a physical side link broadcast channel (PSBCH), a physical side link discovery channel (PSDCH), a physical side link shared channel (PSSCH), a physical side link control channel (PSCCH), a physical side link fundamental channel (PSFCH), etc.).

In some embodiments, UE 302 may also communicate with AP 306 over an air connection. AP 306 may manage WLAN connections that may be used to offload some/all network traffic from RAN 304. The connection between the UE 302 and the AP 306 may be consistent with any IEEE 802.11 protocol, where the AP 306 may be wireless fidelity @, for example) And a router. In some embodiments, UE 302, RAN 304, and AP 306 may utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA)/lightweight IP (LWIP)). Cellular WLAN aggregation may involve the UE 302 configured by the RAN 304 utilizing both cellular radio resources and WLAN resources.

RAN 304 may include one or more access nodes, such as AN 308.AN 308 may terminate the air interface protocol of UE 302 by providing access layer protocols including RRC, packet Data Convergence Protocol (PDCP), radio Link Control (RLC), medium Access Control (MAC), and L1 protocols. In this way, the AN 308 may enable data/voice connectivity between the CN 320 and the UE 302. In some embodiments, the AN 308 may be implemented in a separate device or as one or more software entities running on a server computer, as part of a virtual network, which may be referred to as a CRAN or virtual baseband unit pool, for example. The AN 308 may be referred to as a Base Station (BS), a gNB, a RAN node, AN evolved node B (eNB), a next generation eNB (ng-eNB), a node B (NodeB), a roadside unit (RSU), a TRxP, a TRP, and the like. The AN 308 may be a macrocell base station or a low power base station for providing a microcell, picocell, or other similar cell having a smaller coverage area, smaller user capacity, or higher bandwidth than the macrocell.

In embodiments where the RAN 304 includes multiple ANs, they may be coupled to each other through AN X2 interface (in the case where the RAN 304 is AN LTE RAN) or AN Xn interface (in the case where the RAN 304 is a 5G RAN). The X2/Xn interface, which in some embodiments may be separated into a control plane interface/user plane interface, may allow the AN to communicate information related to handoff, data/context transfer, mobility, load management, interference coordination, etc.

The AN of RAN 304 may separately manage one or more cells, groups of cells, component carriers, etc. to provide AN air interface for network access to UE 302. The UE 302 may be connected simultaneously with multiple cells provided by the same or different ANs of the RAN 304. For example, the UE 302 and the RAN 304 may use carrier aggregation to allow the UE 302 to connect with multiple component carriers, each component carrier corresponding to a primary cell (Pcell) or a secondary cell (Scell). In a dual connectivity scenario, the first AN may be a primary node providing a primary cell group (MCG) and the second AN may be a secondary node providing a Secondary Cell Group (SCG). The first/second AN may be any combination of eNB, gNB, ng-enbs, etc.

RAN 304 may provide the air interface over licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node may use License Assisted Access (LAA), enhanced LAA (eLAA), and/or further enhanced LAA (feLAA) mechanisms based on Carrier Aggregation (CA) technology with PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform media/carrier sensing operations based on, for example, a Listen Before Talk (LBT) protocol.

In a vehicle-to-everything (V2X) scenario, the UE 302 or AN 308 may be or act as a roadside unit (RSU), which may refer to any transport infrastructure entity for V2X communications. The RSU may be implemented in or by a suitable AN or stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; RSUs implemented in or by next generation nodebs (gnbs) may be referred to as "gNB-type RSUs"; etc. In one example, the RSU is a computing device coupled with a radio frequency circuit located at the roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, such as collision avoidance, traffic alerts, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weather-proof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.

In some embodiments, RAN 304 may be an LTE RAN 310 including an evolved node B (eNB), e.g., eNB 312.LTE RAN 310 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo code for data, TBCC for control, etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH demodulation is performed depending on PDSCH/PDCCH demodulation reference signals (DMRS); and relying on CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate over the sub-6 GHz band.

In some embodiments, RAN 304 may be a Next Generation (NG) -RAN 314 with a gNB (e.g., gNB 316) or gn-eNB (e.g., NG-eNB 318). The gNB 316 may connect with 5G enabled UEs using a 5G NR interface. The gNB 316 may connect with the 5G core through a NG interface, which may include an N2 interface or an N3 interface. The Ng-eNB 318 may also connect with the 5G core over the Ng interface, but may connect with the UE over the LTE air interface. The gNB 316 and the ng-eNB 318 may be connected to each other via an Xn interface.

In some embodiments, the NG interface may be divided into two parts, a NG user plane (NG-U) interface that carries traffic data between nodes of NG-RAN 314 and UPF 348, and a NG control plane (NG-C) interface that is a signaling interface (e.g., an N2 interface) between NG-RAN 314 and nodes of access and mobility management function (AMF) 344.

NG-RAN 314 may provide a 5G-NR air interface with the following characteristics: a variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; polarity, repetition, simplex, and Reed-Muller (Reed-Muller) codes for control, and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use CRS but may use PBCH DMRS for PBCH demodulation; phase tracking of PDSCH using PTRS; and performing time tracking using the tracking reference signal. The 5G-NR air interface may operate on an FR1 band including a sub-6 GHz band or an FR2 band including 24.25GHz to 52.6GHz bands. The 5G-NR air interface may comprise an SSB, which is an area of the downlink resource grid comprising PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may use BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, UE 302 may be configured with multiple BWP's, where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 302, the SCS of the transmission is also changed. Another use case of BWP relates to power saving. In particular, the UE 302 may be configured with multiple BWPs having different numbers of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWP containing a smaller number of PRBs may be used for data transmission with smaller traffic load while allowing power saving at UE 302 and in some cases the gcb 316. BWP comprising a large number of PRBs may be used for scenes with higher traffic loads.

RAN 304 is communicatively coupled to CN 320, which includes network elements, to provide various functions to support data and telecommunications services to clients/subscribers (e.g., users of UE 302). The components of CN 320 may be implemented in one physical node or in a different physical node. In some embodiments, NFV may be used to virtualize any or all of the functionality provided by the network elements of CN 320 onto physical computing/storage resources in servers, switches, and the like. The logical instance of CN 320 may be referred to as a network slice, and the logical instantiation of a portion of CN 320 may be referred to as a network sub-slice.

In some embodiments, CN 320 may be an LTE CN 322, which may also be referred to as an Evolved Packet Core (EPC). LTE CN 322 may include a Mobility Management Entity (MME) 324, a Serving Gateway (SGW) 326, a Serving GPRS Support Node (SGSN) 328, a Home Subscriber Server (HSS) 330, a Proxy Gateway (PGW) 332, and a policy control and charging rules function (PCRF) 334, which are coupled to each other through an interface (or "reference point") as shown. The function of the elements of LTE CN 322 may be briefly described as follows.

The MME 324 may implement mobility management functions to track the current location of the UE 302 to facilitate policing, bearer activation/deactivation, handover, gateway selection, authentication, etc.

SGW 326 may terminate the S1 interface towards the RAN and route data packets between the RAN and LTE CN 322. SGW 326 may be a local mobility anchor for inter-RAN node handover and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

SGSN 328 can track the location of UE 302 and perform security functions and access control. In addition, SGSN 328 may perform EPC inter-node signaling for mobility between different RAT networks; MME 324 specified PDN and S-GW selection; MME selection for handover, etc. The S3 reference point between MME 324 and SGSN 328 may enable user and bearer information exchange for inter-3 GPP network mobility in the idle/active state.

HSS 330 may include a database for network users that includes subscription-related information that supports network entity handling communication sessions. HSS 330 may provide support for routing/roaming, authentication, permissions, naming/addressing resolution, location dependencies, and the like. The S6a reference point between the HSS 330 and the MME 324 may enable the transmission of subscription and authentication data to authenticate/grant the user access to the LTE CN 320.

PGW 332 may terminate an SGi interface towards a Data Network (DN) 336 that may include an application/content server 338. PGW 332 may route data packets between LTE CN 322 and data network 336. PGW 332 may be coupled to SGW 326 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 332 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. In addition, the SGi reference point between PGW 332 and data network 336 may be, for example, an operator external public, private PDN, or an operator internal packet data network for providing IMS services. PGW 332 may be coupled with PCRF 334 via a Gx reference point.

PCRF 334 is the policy and charging control element of LTE CN 322. PCRF 334 may be communicatively coupled to application/content server 338 to determine appropriate QoS and charging parameters for the service flows. PCRF 332 may provide the associated rules to the PCEF with the appropriate TFT and QCI (via the Gx reference point).

In some embodiments, CN 320 may be a 5G core network (5 GC) 340. The 5gc 340 may include an authentication server function (AUSF) 342, an access and mobility management function (AMF) 344, a Session Management Function (SMF) 346, a User Plane Function (UPF) 348, a Network Slice Selection Function (NSSF) 350, a network open function (NEF) 352, an NF storage function (NRF) 354, a Policy Control Function (PCF) 356, a Unified Data Management (UDM) 358, and an Application Function (AF) 360, which are coupled to each other through an interface (or "reference point") as shown. The function of the elements of the 5gc 340 may be briefly described as follows.

The AUSF 342 may store data for authentication of the UE 302 and process authentication related functions. The AUSF 342 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5gc 340 through reference points as shown, the AUSF 342 may also present an interface based on the Nausf service.

The AMF 344 may allow other functions of the 5gc 340 to communicate with the UE 302 and RAN 304 and subscribe to notifications about mobility events of the UE 302. The AMF 344 may be responsible for registration management (e.g., registering the UE 302), connection management, reachability management, mobility management, lawful intercept AMF related events, and access authentication and permissions. The AMF 344 may provide for the transmission of Session Management (SM) messages between the UE 302 and the SMF346 and act as a transparent proxy for routing SM messages. The AMF 344 may also provide for transmission of SMS messages between the UE 302 and the SMSF. The AMF 344 may interact with the AUSF 342 and the UE 302 to perform various security anchoring and context management functions. Furthermore, the AMF 344 may be an end point of the RAN CP interface, which may include or be an N2 reference point between the RAN 304 and the AMF 344; the AMF 344 may act as an endpoint for NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF 344 may also support NAS signaling with the UE 302 over the N3 IWF interface.

The SMF 346 may be responsible for SM (e.g., session establishment, tunnel management between UPF 348 and AN 308); UE IP address allocation and management (including optional permissions); selection and control of the UP function; configuring flow control at the UPF 348 to route traffic to the appropriate destination; termination of the interface to the policy control function; control policy enforcement, charging, and a portion of QoS; legal interception (for SM events and interfaces to LI systems); terminating the SM portion of the NAS message; downlink data notification; initiating AN-specific SM information (sent over N2 to AN 308 through AMF 344); and determining the SSC mode of the session. SM may refer to the management of PDU sessions, and PDU sessions or "sessions" may refer to PDU connectivity services that provide or enable PDU exchanges between UE 302 and data network 336.

UPF 348 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with data network 336, and a branching point to support multi-homing PDU sessions. UPF 348 may also perform packet routing and forwarding, perform packet inspection, perform policy rules user plane part, lawful interception packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport layer packet tagging in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 348 may include an uplink classifier to support routing traffic flows to the data network.

NSSF 350 may select a set of network slice instances to serve UE 302. The NSSF 350 may also determine the allowed Network Slice Selection Assistance Information (NSSAI) and the mapping to subscribed individual NSSAIs (S-NSSAIs), if desired. NSSF 350 may also determine the set of AMFs to use for serving UE 302, or a list of candidate AMFs, based on a suitable configuration and possibly by querying NRF 354. The selection of a set of network slice instances for UE 302 may be triggered by AMF 344 (with which UE 302 registers by interacting with NSSF 350), which may result in a change in AMF. NSSF 350 may interact with AMF 344 via an N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). In addition, NSSF 350 may expose an interface based on the Nnssf service.

The NEF 352 may securely disclose services and capabilities provided by 3GPP network functions for third parties, internal disclosure/rediscovery, AF (e.g., AF 360), edge computing or fog computing systems, and the like. In these embodiments, NEF 352 can authenticate, permit, or throttle AFs. The NEF 352 may also translate information exchanged with the AF 360 and information exchanged with internal network functions. For example, the NEF 352 may translate between AF service identifiers and internal 5GC information. The NEF 352 may also receive information from other NFs based on their public capabilities. This information may be stored as structured data at the NEF 352 or at the data store NF using a standardized interface. The NEF 352 may then re-disclose the stored information to other NFs and AFs, or for other purposes such as analysis. In addition, NEF 352 may expose an interface based on Nnef services.

NRF 354 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of the discovered NF instances to the NF instances. NRF 354 also maintains information of available NF instances and services supported by them. As used herein, the terms "instantiate," "instance," and the like may refer to creating an instance, "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. Further, NRF 354 may expose an interface based on the Nnrf service.

PCF 356 may provide policy rules to control plane functions to enforce them and may also support a unified policy framework to manage network behavior. PCF 356 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 358. In addition to communicating with functions through reference points as shown, PCF 356 also presents an interface based on the Npcf service.

The UDM 358 may process subscription related information to support network entities in handling communication sessions and may store subscription data for the UE 302. For example, subscription data may be communicated via an N8 reference point between the UDM 358 and the AMF 344. UDM 358 may include two parts: application front-end and UDR. The UDR may store policy data and subscription data for UDM 358 and PCF 356, and/or structured data and application data for the disclosure for NEF 352 (including PFD for application detection, application request information for multiple UEs 302). UDR 221 may expose an interface based on the Nudr service to allow UDM 358, PCF 356, and NEF 352 to access specific sets of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of related data changes in the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, etc. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access permissions, registration/mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, the UDM 358 may also present an interface based on Nudm services.

AF 360 may provide application impact on traffic routing, provide access to the NEF, and interact with the policy framework for policy control.

In some embodiments, the 5gc 340 may enable edge computation by selecting an operator/third party service that is geographically close to the point where the UE 302 attaches to the network. This may reduce latency and load on the network. To provide edge computing implementations, the 5gc 340 may select a UPF 348 close to the UE 302 and perform traffic steering from the UPF 348 to the data network 336 over the N6 interface. This may be based on UE subscription data, UE location, and information provided by AF 360. In this way, AF 360 may affect UPF (re) selection and traffic routing. Based on the carrier deployment, the network operator may allow AF 360 to interact directly with the associated NF when AF 360 is considered a trusted entity. In addition, AF 360 may expose an interface based on Naf services.

The data network 336 may represent various network operator services, internet access, or third party services that may be provided by one or more servers, including, for example, an application/content server 338.

In NR, beam management is a set of layer 1 (physical layer, L1)/layer 2 (data link layer, L2) procedures for acquiring and maintaining a set of Transmission Reception Points (TRP) and/or UE beams available for Downlink (DL) and Uplink (UL) transmission/reception. Beam management includes the following functions:

-beam determination: selection of own transmit (Tx)/receive (Rx) beam for TRP or UE

Beam measurement: measuring characteristics of received beamformed signals for TRP or UE

Beam reporting: information for UE reporting beam formed signals based on beam measurements

-beam scanning: operation of covering a spatial region, transmitting and/or receiving beams in a predetermined manner during a time interval

Beam management allows UEs to switch between beams as radio conditions change over time. Beam failure events that occur when there is a change in radio conditions may quickly render established beam pairs unreliable before conventional beam management can make beam adjustments. There may be alternate candidate beam pairs to reliably restore the link between the UE and BS. The mechanism of finding alternate beam pairs and re-establishing links is called a Beam Fault Recovery (BFR) process. At a high level, the BFR procedure includes beam failure detection, candidate beam pair identification, BFR request transmission, and BFR restoration response.

In the beam fault detection phase, the UE detects a beam fault event occurrence based on measurement of a beam fault detection reference signal, e.g., a channel state information reference signal (CSI-RS) or a Synchronization Signal Block (SSB). These reference signals are spatially quasi co-located (qciled) with the Physical Downlink Control Channel (PDCCH). When the quality of the monitored reference signal is below a configured threshold, the PHY layer generates and passes a Beam Fault Instance (BFI) to the MAC layer. The beam failure instance means that all serving beams in a set of beams configured for beam failure detection fail (e.g., a hypothetical PDCCH block error rate (BLER) determined based on measurements of SS or CSI-RS is above a threshold). The set of beams for beam failure detection of the serving cell is configured via an RRC message. For UEs, only periodic CSI-RS or SSB (spatially quasi co-located with PDCCH demodulation reference signals (DMRS)) is used for beam-failure detection. When the number of BFIs exceeds a configured value before a configured timer (beam failure detection timer) expires, the UE will declare that a beam failure is detected.

Upon detection of a beam failure, the UE will initiate the BFR procedure. As a first step in the BFR procedure, the UE attempts to find a new beam pair that may restore the link. The BS (e.g., next generation NodeB or "gNB") may use beamfailurereconveryconfig (beam failure recovery configuration) to provide a set of beam measurement resources for the UE to identify a new beam pair. Candidatebeam rslist (candidate beam reference signal list) provides a set of up to 16 SSB and/or CSI-RS beams. The UE measures Reference Signal Received Power (RSRP) of a reference signal corresponding to the candidate beam. If the RSRP of the candidate beam exceeds the configured threshold, the candidate beam is selected for BFR. Once the candidate beam is selected for BFR, the UE needs to send a BFR request (BFRQ) to the BS. For special cells (SpCell, spCell refers to primary cell (PCell) for primary cell group (MCG) and primary secondary cell (PSCell) for Secondary Cell Group (SCG), otherwise (e.g., in case of Dual Connectivity (DC) unconfiguration) the term SpCell refers to PCell), the MAC entity of the UE initiates a random access procedure on SpCell for beam recovery, RRC may configure all parameters based on BeamFailureRecoveryConfig IE. The transmission of BeamFailureRecoveryConfig is optional, e.g., the gNB may or may not provide parameters for the RA procedure. If the gNB has provided dedicated RA resources for some of the beams, these beams are prioritized by the UE, e.g., the UE selects the appropriate beam to perform BFR (Candida beamRSList in BeamFailureRecoveryConfig IE includes a PHY resource list associated with the candidate beam to reestablish the connection). The UE may also start the beamFailureRecoveryTimer if the beamFailureRecoveryTimer is configured. The UE selects a contention-free (if specifically signaled) Physical Random Access Channel (PRACH) occasion and/or preamble corresponding to the new candidate beam of the SpCell and transmits the preamble. The UE then starts a BFR-response window (BFR response window, which is a nomenclature used herein for ra-response window-see 3GPP TS 38.321V16.7.0 (2021-12) (third generation partnership project; technical specification group radio access network; NR; medium Access Control (MAC) protocol specification (release 16)) configured in beamfailurerecoveryconfigug, starting at the first PDCCH occasion after ending the preamble transmission for a fixed duration of X symbols. BFR-response window is a Random Access Response (RAR) response window configured by the gNB for BFR. While bfr-response window is running, the UE monitors PDCCH of SpCell for a response to BFRQ identified by a cell radio network temporary identifier (C-RNTI). If the UE receives a PDCCH transmission addressed to the C-RNTI from the SpCell, the UE considers that the BFR procedure was successfully completed and the beamFailureRecoveryTimer stopped. If bfr-response window expires, the UE performs again: 1) selecting PRACH occasions and/or preambles, 2) transmitting preambles and 3) monitoring PDCCH. If BFR-response window expires and the UE has sent the PRACH preamble for a configured number of times, the BFR procedure is deemed unsuccessful and the UE may trigger a radio link failure. If the beamefailureRecoveryTimer expires and the BFR procedure is not successfully completed, the UE stops using the contention-free random access resources configured for BFR. For the P (S) Cell, the BFR procedure ends with a successful Random Access Channel (RACH).

For BFR in the SCell, the UE sends a BFR MAC control element (MAC-CE) if UL shared channel (UL-SCH) resources are available (e.g., if the UE already has UL grant on the serving cell). Otherwise, the UE triggers a Scheduling Request (SR) PUCCH for BFR of the SCell. If the SR PUCCH is triggered, the network may provide grants on the P (S) Cell, but this depends on the network implementation. The BFR MAC-CE may contain a plurality of failed scells. For each SCell, SCell BFR MAC-CE indicates the following information: information about the failed SCell index; an indication as to whether a new candidate beam RS is detected; and a new candidate beam RS index (if available).

For scells, the BFR ends with a New Data Indicator (NDI) handoff for UL hybrid automatic repeat request (HARQ) processes carrying BFR MAC-CE by the network.

Figure 4 shows the BFR process in NR. The signaling flow for the BFR procedure in NR is shown in fig. 4. The left diagram in fig. 4 shows the BFR procedure for PCell, and the right diagram in fig. 4 shows the BFR procedure for SCell.

In previous systems for LTE and NR, a similar scenario was solved by carrier aggregation, where a UE may be served by both a PCell and one or more scells. More specifically, when there is a beam failure in the SCell, assistance from the PCell is used to recover a new best beam for the SCell. However, in these previous systems, the BFR procedure or mechanism is not optimized for side information assisted communication systems in which the BS may be turned on-demand. Furthermore, for some BFR mechanisms in NR, periodic beam measurements can create a significant amount of overhead.

In view of the above, a procedure is proposed for providing BFR in a side information assisted cellular communication system, wherein side information is extracted by measurements in a first frequency band (frequency band 1) and used to establish a communication link in a second frequency band (frequency band 2). In other words, the proposed procedure is directed to a BFR procedure for a cellular communication link in a frequency band that utilizes assistance information from an auxiliary frequency band. The proposed BFR procedure provides an efficient method for performing BFR for normally closed BSs, wherein the efficiency comes in part from the assistance information provided by the assistance frequency band. More specifically, with the help of the auxiliary band or first band (band 1), a BFR procedure is proposed for the auxiliary band or second band (band 2) to take into account both periodic and dynamic beam measurements. This provides dynamic beam measurements with the help of links already established in the first frequency band, which reduces the overhead compared to periodic beam measurements.

One example of an exemplary band combination is a first band in NR frequency range 2 (24.25 GHz to 71 GHz) and a second band in the sub-terahertz or terahertz (THz) domain. One example of a target system is a low-band assisted terahertz cellular communication system. In this example, the first frequency band may be in NR frequency range 1 (450 MHz to 6 GHz) or NR frequency range 2, and the second frequency band may be in the frequency range of 100-300 GHz. From now on, NR frequency range 1 and NR frequency range 2 will be denoted FR1 and FR2, respectively. The first frequency band and the second frequency band may be assigned with a frequency band ID. The band ID may be defined to represent one of the operating bands in FR1 (n 1-n 99) or FR2 (n 257-n 261) or future high frequency bands (e.g., sub-terahertz bands). A table may be defined to map the operating band to integer values that may be used as band IDs.

It is assumed that transceivers operating in two frequency bands are collocated for the situation under consideration. The first frequency band follows a conventional protocol/procedure similar to the one used in NR to establish the link. Then, when favorable channel conditions exist, a system operating in the first frequency band keeps measuring channel conditions for opportunistic transmissions in the second frequency band. The second band transceiver may remain off until favorable channel conditions are detected to save power. Once favorable channel conditions are detected, the communication link in the first frequency band facilitates communication in the second frequency band by helping to quickly establish a link for data transmission while the channel is still in good condition. Further, the first frequency band may assist the second frequency band in other cases of beam fault recovery, control channel information transmission, and the like.

If the second frequency band is in the high frequency range (e.g., over 100 GHz), then both the BS and the UE may use beamforming to mitigate the higher path loss incurred. Generally, larger antenna arrays are used to combat harsh propagation conditions in higher carrier frequencies. The relative antenna aperture size of an antenna implemented in a higher carrier frequency is typically smaller. This allows for a denser antenna array to be packaged and for a narrower beam with higher antenna directivity gain to be utilized. Thus, in higher carrier frequencies, both the BS and the UE may need to scan through many beams to provide wide angle coverage. Although the transceiver can scan through all beams, it takes a long time to determine a pair of beams for the BS and the UE in case a large number of beams are used on both Tx and Rx sides. Some assistance from the first frequency band may significantly reduce this overhead.

Fig. 5 illustrates an example of a set of narrow beams in a higher frequency band covering the same spatial region as a wide beam in a lower frequency band, according to some embodiments of the present disclosure. In the example shown in fig. 5, the first frequency band is in a lower frequency range than the second frequency band. As shown in fig. 5, a set of narrow beams of the second frequency band (in this case, higher frequencies) cover the same spatial region as the wide beams of the first frequency band (in this case, lower frequencies).

As shown in fig. 5, the preferred first band beam generally indicates the range of candidate second band beams that overlap the first band beam in angular coverage. Therefore, the chance of finding the optimal second band beam pair by simply scanning the overlapping second band beams is very high.

In some embodiments of the present disclosure, the BFR procedure for the second frequency band is provided for the case where the UE is unaware of the new best beam. That is, these BFR procedures are designed for systems in which no periodic beam measurements (via beam scanning) are configured in the second frequency band. Further, it is assumed that the second frequency band RACH resources are not periodically allocated because the second frequency band BS may be turned off when not serving any UE to save energy. In an example, when a beam failure is detected, a procedure similar to the initial access is initiated, as shown in the signaling flow diagram in fig. 6.

Fig. 6 illustrates a signaling flow diagram of an RA for beam fault recovery using an initial access procedure, according to some embodiments of the present disclosure. As shown in fig. 6, in step 1, the UE notifies the first frequency band BS of beam failure in the second frequency band. The beam fault indication may be considered a beam fault recovery request. In an example, step 1 may be performed using MAC-CE or Uplink Control Information (UCI).

In one example, an example MAC-CE for beam failure is shown in fig. 7 and described in detail below.

Fig. 7 illustrates an example MAC-CE for notifying beam faults, according to some embodiments of the present disclosure. A new Logical Channel ID (LCID) (e.g., bfr) may be defined to indicate that the MAC-CE is to be used to notify of a beam failure event in the second frequency band. The field "BB" in fig. 7 indicates whether the MAC-CE has information for a new best beam index. A value of '0' indicates that the best beam index is not included, and a value of '1' indicates that the best beam index is included after the field "band Id". The field "band Id" indicates the identity of the second band. For example, if the second frequency band is one of the NR FR2 operating bands (n 257-n 261) defined in Table 5.2-1 in 3GPP TS 38.101-2V15.16.0 (2021-12) (third Generation partnership project; technical Specification group radio networking; NR; user Equipment (UE) radio transmission and reception; part 2: range 2 independent release (release 15)), the "band Id" may be mapped to one of these operating bands by defining a mapping table. The field "best beam index" indicates an index of the best beam among the beams measured by the UE. The field "R" represents a reserved bit and is available for future expansion.

In another example, a new UCI type may be defined to indicate beam failure. The new UCI may contain the band ID of the second band experiencing the beam failure. Optionally, the new UCI may also include a beam index of the new best beam for beam fault recovery.

With continued reference to fig. 6, the first and second frequency band BSs exchange information about beam faults and BFR configurations in steps 2 and 3, respectively. The first band BS forwards the BFR configuration to the UE in step 4. The BFR configuration may include scheduling resources for reference signal (SSB/CSI-RS) transmission for best beam detection and resources for best beam indication to the second band BS. The BFR configuration may be transmitted to the UE using dedicated Radio Resource Control (RRC) signaling, MAC-CE, downlink Control Information (DCI), or a combination thereof.

In one example, an example RRC Information Element (IE) for transmitting this information (i.e., BFR configuration) is shown in fig. 8 and described in detail below.

Fig. 8 illustrates an example IE for transmitting BFR configuration to a UE in accordance with some embodiments of the present disclosure. Parameters of the IE are explained in table 1 as follows. When the field is set to "PRACH" (i.e., the field "BFR-Method" indicates that the BFR request is to be sent by the UE using PRACH), the IE also includes a specific dedicated PRACH preamble for each reference signal beam. From the PRACH preamble detected at the second frequency band BS, the new best beam selected by the UE can be inferred.

Table 1: BFR configuration parameters for a second frequency band

/>

In another example, an example MAC-CE for BFR configuration is shown in fig. 9 and described in detail below.

Fig. 9 illustrates an example MAC-CE for transmitting BFR configurations to a UE in accordance with some embodiments of the present disclosure. The field "BID" in fig. 9 refers to the frequency band being assisted (e.g., the second frequency band). For example, the field "BID" may represent one of the operating bands in FR1 (n 1-n 99) or FR2 (n 257-n 261). A table may be defined to map the operating frequency bands to integer values that may be used as BID. The description of the other fields is self-explanatory and matches the fields described in table 1 for BFR-Config-SideInfoAssisted IE.

With continued reference to fig. 6, in step 5, an on-demand SSB/CSI-RS may be transmitted so that the UE may determine a new best beam. In step 6, the UE transmits a PRACH preamble from which the second band BS may determine a new best beam. The PDCCH in response to the PRACH preamble may be transmitted from the first frequency band BS or the second frequency band BS as shown in the right and left diagrams of fig. 6, respectively. In the latter case, the second band BS transmits a PDCCH co-located with a new best beam quasi-station (QCLed). Proper reception of the PDCCH addressed to the C-RNTI of the UE indicates successful recovery from the beam failure. In the former case, the second band BS requests the first band BS to transmit PDCCH to the UE. In this case, a different Radio Network Temporary Identifier (RNTI) may be defined and used to scramble the PDCCH to let the UE know that this PDCCH is responsive to PRACH transmissions in the second frequency band. In order for the UE to be able to recognize this RNTI, the UE must be configured with an RNTI within the message in step 4 of fig. 6 (i.e. BFR configuration), e.g. indicated by the field "BFR-Band2-RNTI" as shown in table 1. In addition, a new field may be defined to indicate whether the PDCCH in response to the beam fault recovery request is transmitted from the first frequency Band or the second frequency Band, for example, using the field "bfr-PDCCH-Band" as shown in table 1.

In another example, an alternative approach for beam fault recovery in the second frequency band may be used in cases where the UE is unaware of the new best beam. The signaling flow of this method is shown in fig. 10 and described in detail below.

Fig. 10 illustrates a signaling flow diagram for reporting an optimal beam for beam fault recovery in a second frequency band using a first frequency band in accordance with some embodiments of the present disclosure. As can be seen from fig. 10, there is no PRACH preamble transmission in step 6. Instead, the best beam for the second frequency band is reported to the first frequency band BS, which in turn informs the second frequency band BS. Thereafter, the second band BS transmits the PDCCH, and the beam fault recovery procedure is successful after receiving the PDCCH. The optimal beam reporting to the first band BS may be accomplished through UCI or MAC-CE. UCI repetition or retransmission may be utilized to improve reliability, as UCI may not be as reliable as MAC-CE.

In one example, an example MAC-CE for indicating the best beam to the first frequency band BS in step 6 is shown in fig. 11 and described in detail below.

Fig. 11 illustrates an example MAC-CE for informing of a new best beam for a second frequency band, according to some embodiments of the present disclosure. A new LCID may be defined to indicate that the MAC-CE is to inform the first band BS of the new best beam for the second band. The field "band Id" indicates the identity of the second band. The field "best beam index" indicates the index of the new best beam determined by the UE. The field "R" represents a reserved bit and is available for future expansion.

In another example, a new UCI type may be defined to indicate the new best beam information in step 6 of fig. 11. UCI should contain a single bit to indicate whether a new best beam index is included. In addition, UCI should contain a band ID of the second band experiencing beam failure and a new best beam index.

It will be appreciated that other steps of the alternative method shown in fig. 10 are similar to those of the method shown in fig. 6, and that the relevant content is not described in detail herein.

In some embodiments of the present disclosure, the BFR procedure for the second frequency band may be used in cases where there is periodic beam measurement (e.g., by beam scanning reference signals) in the second frequency band configured by the second frequency band BS at the UE. The signaling flow of this method is shown in fig. 12.

Fig. 12 illustrates a signaling flow diagram for beam fault recovery in a second frequency band in the presence of periodic beam measurements in the second frequency band, according to some embodiments of the present disclosure. As shown in fig. 12, in step 1, periodic beam measurements are made in a second frequency band. Thus, as soon as the UE detects a beam failure, it is able to determine a new best beam for the second frequency band. The UE reports the beam failure and the new best beam for the second frequency band to the first frequency band BS, which in turn informs the second frequency band BS. Thereafter, the UE starts monitoring the PDCCH on the new best beam. In the example in the left diagram of fig. 12, the second band BS transmits the PDCCH with its C-RNTI to the UE, and the beam failure recovery procedure is successful after receiving the PDCCH. It is to be understood that the contents shown in fig. 12 regarding monitoring of the PDCCH are similar to those of the method shown in fig. 6 or 10, and the related contents are not described herein again. The beam failure and the optimal beam indication in step 2 may be performed with the example MAC-CE or UCI described with respect to fig. 6, and will not be described again here. For the case of MAC-CE, the field "BB" in fig. 7 will be set to 1, indicating that there is new best beam information in the MAC-CE.

In some embodiments of the present disclosure, the random access procedure for beam fault recovery in the second frequency band may be used in cases where there is both periodic beam measurement and periodic RACH resource allocation in the second frequency band.

Fig. 13 illustrates a signaling flow diagram of an RA for beam fault recovery in a second frequency band with both periodic beam measurements and periodic RACH resource allocation in the second frequency band, according to some embodiments of the present disclosure. In this case, the UE may directly inform the second band BS of the beam failure. Note that the UE still needs assistance from the first frequency band to establish an initial link with the second frequency band BS. The periodic RACH resource allocation is configured after the UE establishes a link with the second frequency band BS. This is shown in the left-hand diagram of fig. 13. RACH resources are divided into RACH occasions and different RACH occasions can be mapped to different beams from periodic beam measurements. The signaling flow for the BFR procedure in this method is shown in the right diagram of fig. 13. As shown in fig. 13, after detecting the beam failure and the UE selects a new best beam, the UE transmits a PRACH preamble in the second frequency band. The second band BS responds with a PDCCH transmission that addresses the UE with its C-RNTI. BFR is considered successful when the UE receives the PDCCH.

Fig. 14 illustrates a flowchart of a method 1400 for beam fault recovery according to some embodiments of the present disclosure. In some embodiments, the method 1400 may be performed at a UE. Method 1400 may include steps 1410 and 1420.

At 1410, a beam fault indication is encoded for transmission to a first AN associated with a first frequency band, wherein the beam fault indication indicates a beam fault in a second frequency band.

In some embodiments of the present disclosure, the beam fault indication is encoded using a medium access control element (MAC-CE), wherein the MAC-CE includes one or more of: a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify of beam faults in the second frequency band; and a band ID indicating an identity of the second band.

In some embodiments of the present disclosure, the beam fault indication is encoded using Uplink Control Information (UCI) including a band ID indicating an identity of the second frequency band.

In some embodiments of the present disclosure, the MAC-CE or UCI further includes a beam index indicating an index of a new best beam for the second frequency band.

At 1420, a Beam Fault Recovery (BFR) configuration message received from the first AN is decoded, wherein the BFR configuration message includes BFR configuration information received by the first AN from a second AN associated with the second frequency band.

In some embodiments of the present disclosure, the BFR configuration message is received from the first AN via one or more of: dedicated Radio Resource Control (RRC) signaling, medium access control elements (MAC-CEs), downlink Control Information (DCI), or a combination of the above.

In some embodiments of the present disclosure, the BFR configuration message includes one or more of the following: a band ID indicating an identity of the second band; information related to one or more candidate beams in the second frequency band and corresponding reference signals; and a BFR method indicating whether information regarding a new best beam for the second frequency band is to be encoded by the UE using a Physical Random Access Channel (PRACH) preamble.

It will be appreciated that the content of the BFR configuration message may refer to the content of the BFR configuration parameters for the second frequency band described in table 1 above, and the relevant content is not described herein.

In some embodiments of the present disclosure, the method 1400 may further include determining a new best beam for the second frequency band from among the candidate beams based on a measurement of Reference Signal Received Power (RSRP) of one or more reference signals received from the second AN corresponding to the one or more candidate beams indicated in the BFR configuration message. In some embodiments of the present disclosure, the reference signals include one or more channel state information reference signal (CSI-RS) signals or Synchronization Signal Block (SSB) signals.

In some embodiments of the present disclosure, the method 1400 may further include selecting a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam for transmission to the second AN. In this case, each reference signal (SSB/CSI-RS) beam is assigned a specific dedicated PRACH preamble so that the second AN can use the preamble transmission to infer the new best beam that the UE has selected.

In some embodiments of the present disclosure, the method 1400 may further include encoding a beam indication message for transmission to the first AN, wherein the beam indication message indicates a new best beam and is further forwarded by the first AN to the second AN.

In some embodiments of the present disclosure, the beam indication message is encoded using a medium access control element (MAC-CE), wherein the MAC-CE includes one or more of: a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify the first AN of a new best beam for the second frequency band; and a band ID indicating an identity of the second band.

In some embodiments of the present disclosure, the beam indication message is encoded using Uplink Control Information (UCI) including a band ID indicating an identity of the second frequency band.

In some embodiments of the present disclosure, the method 1400 may further include decoding a Physical Downlink Control Channel (PDCCH) received from a first AN, wherein the first AN scrambles the PDCCH using a Radio Network Temporary Identifier (RNTI) (e.g., scrambles Cyclic Redundancy Check (CRC) bits of DCI carried in the PDCCH), and the UE is configured with the RNTI after decoding the BFR configuration message. In AN example, in case the first AN scrambles CRC bits of DCI carried in the PDCCH using AN RNTI, the UE declares beam failure recovery successful when receiving the PDCCH with CRC bits scrambled by AN RNTI configured for beam failure recovery in the second frequency band.

In some embodiments of the present disclosure, the method 1400 may further include decoding a PDCCH received from the second AN, wherein the PDCCH is co-located with a new best beam quasi-location (QCLed). In an example, the UE will declare beam failure recovery successful when receiving PDCCH.

It is to be appreciated that certain content regarding method 1400 may refer to related content regarding the above-described embodiments, and that related content is not described in detail herein. Moreover, it is to be understood that method 1400 may include more or less or different steps in some other embodiments, without limitation.

Fig. 15 illustrates a flow chart of a method 1500 for beam fault recovery according to some embodiments of the present disclosure. In some embodiments, the method 1500 may be performed at a first AN associated with a first frequency band. Method 1500 may include steps 1510, 1520, and 1530.

At 1510, an indication received from the UE regarding beam failure in the second frequency band is decoded.

At 1520, a beam fault message is encoded for transmission to a second AN associated with the second frequency band, wherein the beam fault message indicates a beam fault in the second frequency band.

At 1530, a Beam Fault Recovery (BFR) configuration message is encoded for transmission to the UE, wherein the BFR configuration message includes BFR configuration information received from the second AN.

In some embodiments of the present disclosure, the method 1500 may further include encoding a beam indication message for transmission to the second AN, wherein the beam indication message indicates a new best beam determined by the UE.

In some embodiments of the present disclosure, method 1500 may further include encoding a PDCCH for transmission to the UE, wherein the PDCCH is scrambled using an RNTI carried in the BFR configuration message.

It is to be appreciated that certain content regarding the method 1500 may refer to related content regarding the above-described embodiments, and the related content is not described in detail herein. Moreover, it is to be understood that method 1500 may include more or fewer or different steps in some other embodiments, and is not limited in this regard.

Fig. 16 illustrates a flow chart of a method 1600 for beam fault recovery according to some embodiments of the present disclosure. In some embodiments, method 1600 may be performed at a second AN associated with a second frequency band. Method 1600 may include steps 1610 and 1620.

At 1610, a beam fault message received from a first AN associated with a first frequency band is decoded, wherein the beam fault message indicates that the UE has detected a beam fault in a second frequency band.

At 1620, beam Fault Recovery (BFR) configuration information is encoded for transmission to the first AN.

In some embodiments of the present disclosure, method 1600 may further include encoding one or more reference signals corresponding to the one or more candidate beams indicated in the BFR configuration information for transmission to the UE.

In some embodiments of the present disclosure, the method 1600 may further include decoding a Physical Random Access Channel (PRACH) preamble received from the UE to determine a new best beam selected by the UE.

It is to be appreciated that certain content pertaining to the method 1600 may refer to relevant content pertaining to the above-described embodiments, and that relevant content is not described in detail herein. Moreover, it is to be understood that method 1600 may include more or fewer or different steps in some other embodiments, and is not limited in this regard.

Fig. 17 illustrates a flow chart of a method 1700 for beam fault recovery according to some embodiments of the present disclosure. In some embodiments, the method 1700 may be performed at a UE. The method 1700 may include step 1710.

At 1710, a Beam Fault Recovery (BFR) request is encoded for transmission to a first AN associated with the first frequency band, wherein the BFR request indicates a beam fault in the second frequency band and a new best beam for the second frequency band, and the BFR request is further forwarded by the first AN to a second AN associated with the second frequency band.

In some embodiments of the present disclosure, prior to encoding the BFR request, method 1700 may further include: after detecting a beam failure in the second frequency band, a new best beam for the second frequency band is determined based on periodic beam measurements in the second frequency band.

In some embodiments of the present disclosure, the method 1700 may further comprise: the PDCCH received from the first AN is decoded, wherein the UE is configured with AN RNTI used by the first AN to scramble the PDCCH.

In some embodiments of the present disclosure, the method 1700 may further comprise: the PDCCH received from the second AN is decoded, wherein the PDCCH is quasi co-located with a new best beam (QCLed).

It is to be appreciated that certain content regarding the method 1700 may refer to related content regarding the above-described embodiments, and the related content is not described in detail herein. Moreover, it is to be understood that method 1700 may include more or fewer or different steps in some other embodiments, without limitation.

Fig. 18 illustrates a flow chart of a method 1800 for beam fault recovery according to some embodiments of the present disclosure. In some embodiments, the method 1800 may be performed at a UE. Method 1800 may include steps 1810 and 1820.

At 1810, after detecting a beam failure in a frequency band, a new best beam for the frequency band is determined based on periodic beam measurements in the frequency band.

At 1820, the PRACH preamble corresponding to the new best beam is encoded for transmission in Random Access Channel (RACH) resources corresponding to the new best beam to AN associated with the frequency band.

In some embodiments of the present disclosure, RACH resources are configured by AN, which is a assisted AN associated with a assisted frequency band (second frequency band described herein).

It is to be appreciated that certain content regarding the method 1800 may be referred to the relevant content regarding the above-described embodiments, and that the relevant content is not described in detail herein. Moreover, it is to be understood that method 1800 may include more or fewer or different steps in some other embodiments, and is not limited herein.

Fig. 19 illustrates an example of an infrastructure device 1900 according to some embodiments of the disclosure. Infrastructure device 1900 (or "system 1900") may be implemented as a base station, radio head, RAN node, etc., such as RAN nodes 111 and 112 and/or AP 106 shown and described previously. In other examples, system 1900 may be implemented in or by a UE, application server(s) 130, and/or any other element/device discussed herein. The system 1900 may include one or more of the following: application circuitry 1905, baseband circuitry 1910, one or more radio front end modules 1915, memory 1920, power management integrated circuits (power management integrated circuitry, PMIC) 1925, power tee 1930, network controller 1935, network interface connector 1940, satellite positioning circuitry 1945, and user interface 1950. In some embodiments, device 1900 may include additional elements, such as memory/storage, a display, a camera, sensors, or input/output (I/O) interface elements. 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 separately in more than one device).

As used herein, the term "circuitry" may refer to, be part of, or include, hardware components such as the following configured to provide the described functionality: electronic circuitry, logic circuitry, processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), application specific integrated circuit (Application Specific Integrated Circuit, ASIC), field-programmable device (field-programmable device, FPD) (e.g., field-programmable gate array (field-programmable gate array, FPGA), programmable logic device (programmable logic device, PLD), complex PLD (CPLD), high-capacity PLD (hcpll), structured ASIC, or programmable System on Chip (SoC)), digital signal processor (digital signal processor, DSP), and so forth. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functions. Furthermore, the term "circuitry" may also refer to a combination of one or more hardware elements (or circuitry for use in an electrical or electronic system) and program code for performing the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

The terms "application circuitry" and/or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry". As used herein, the term "processor circuit" may refer to, be part of, or include the following: the circuitry is capable of sequentially and automatically performing a sequence of arithmetic or logical operations; and recording, storing and/or transmitting digital data. The term "processor circuit" 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 otherwise operating computer executable instructions such as program code, software modules, and/or functional processes.

Further, various components of the core network 120 (or CN 120 previously discussed) may be referred to as "network elements. The term "network element" may describe a physical or virtualized device for providing wired or wireless communication network services. The term "network element" may be considered synonymous with and/or referred to by the following terms: networked computers, networking hardware, network devices, network nodes, routers, switches, hubs, bridges, radio network controllers, radio access network devices, gateways, servers, virtualized network functions (virtualized network function, VNF), network function virtualization infrastructure (network functions virtualization infrastructure, NFVI), and so forth.

The application circuitry 1905 may include one or more central processing unit (central processing unit, CPU) cores and one or more of the following: cache memory, low Drop Out (LDO) voltage regulator, interrupt controller, serial interface such as SPI, I2C or universal programmable serial interface module, real Time Clock (RTC), timer-counter including interval and watchdog timer, universal input/output (I/O or IO), memory card controller such as Secure Digital (SD)/multimedia card (MultiMediaCard, MMC), universalA serial bus (Universal Serial Bus, USB) interface, a mobile industrial processor interface (Mobile Industry Processor Interface, MIPI) interface, and a joint test access group (Joint Test Access Group, JTAG) test access port. By way of example, the application circuit 1905 may include one or more intelsOr->A processor; superfine semiconductor (Advanced Micro Devices, AMD)Processor, acceleration processing unit (Accelerated Processing Unit, APU) or +.>A processor; etc. In some embodiments, the system 1900 may not utilize the application circuit 1905, but may include, for example, a dedicated processor/controller to process IP data received from the EPC or 5 GC.

Additionally or alternatively, the application circuit 1905 may include circuitry such as (but not limited to) the following: one or more Field Programmable Devices (FPDs), such as Field Programmable Gate Arrays (FPGAs), and the like; programmable Logic Devices (PLDs), such as Complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), and the like; an ASIC, such as a structured ASIC, etc.; a programmable SoC (PSoC); etc. In such embodiments, the circuitry of application circuit 1905 may include logic blocks or logic architectures, including other interconnected resources, that can be programmed to perform various functions, such as the processes, methods, functions, etc., of the various embodiments discussed herein. In such an embodiment, the circuitry of application circuit 1905 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EEPROM), flash memory, static memory (e.g., static random access memory (static random access memory), SRAM), antifuse, etc.) for storing logic blocks, logic architectures, data, etc., in a look-up table (LUT), and so forth.

The baseband circuitry 1910 may be implemented, for example, as a solder-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Although not shown, baseband circuitry 1910 may include one or more digital baseband systems that may be coupled to a CPU subsystem, an audio subsystem, and an interface subsystem via an interconnect subsystem. The digital baseband subsystem may also be coupled to the digital baseband interface and mixed signal baseband subsystem via additional interconnect subsystems. Each interconnect subsystem may include a bus system, a point-to-point connection, a Network On Chip (NOC) architecture, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include digital signal processing circuitry, buffer memory, program memory, voice processing accelerator circuitry, data converter circuitry such as analog-to-digital and digital-to-analog converter circuitry, analog circuitry including one or more amplifiers and filters, and/or other similar components. In an aspect of the disclosure, the baseband circuitry 1910 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for digital baseband circuitry and/or radio frequency circuitry (e.g., the radio front end module 1915).

The user interface circuitry 1950 may include one or more user interfaces designed to enable user interaction with the system 1900 or peripheral component interfaces designed to enable interaction with peripheral components of the system 1900. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (light emitting diode, LEDs)), a physical keyboard or keypad, a mouse, a touch pad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, and so forth. Peripheral component interfaces may include, but are not limited to, non-volatile memory ports, universal Serial Bus (USB) ports, audio jacks, power supply interfaces, and the like.

Radio Front End Module (RFEM) 1915 may include millimeter wave RFEM and one or more sub-millimeter wave Radio Frequency Integrated Circuits (RFICs). In some implementations, one or more sub-millimeter wave RFICs may be physically separate from millimeter wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module 1915. RFEM 1915 may include both millimeter-wave and sub-millimeter-wave antennas.

The memory circuit 1920 may include one or more of the following: volatile memory, including dynamic random access memory (dynamic random access memory, DRAM) and/or synchronous dynamic random access memory (synchronous dynamic random access memory, SDRAM); and nonvolatile memory (nonvolatile memory, NVM) including high-speed electrically erasable memory (commonly referred to as flash memory), phase-change random access memory (phase change random access memory, PRAM), magnetoresistive random access memory (magnetoresistive random access memory, MRAM), and the like, and may include data fromAndthree-dimensional (3D) cross-point (XPOINT) memory. The memory circuit 1920 may be implemented as one or more of a soldered-in packaged integrated circuit, a socket-type memory module, and a plug-in memory card.

The PMIC 1925 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power supplies such as a battery or capacitor. The power alarm detection circuit may detect one or more of a power down (under voltage) and surge (over voltage) condition. The power tee circuit 1930 may provide power drawn from the network cable to provide both power supply and data connectivity to the infrastructure equipment 1900 using a single cable.

The network controller circuit 1935 may provide connectivity to the network using standard network interface protocols, such as Ethernet, GRE tunnel-based Ethernet, multiprotocol label switching (Multiprotocol Label Switching, MPLS) based Ethernet, or some other suitable protocol. Network connectivity may be provided to/from infrastructure device 1900 via network interface connector 1940 using physical connections, which may be electrical (commonly referred to as "copper interconnects"), optical, or wireless. The network controller circuitry 1935 may include one or more special purpose processors and/or FPGAs to communicate using one or more of the protocols described above. In some implementations, the network controller circuit 1935 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

The positioning circuitry 1945 may include circuitry to receive and decode signals transmitted by one or more navigation satellite constellations of a global navigation satellite system (global navigation satellite system, GNSS). Examples of navigation satellite constellations (or GNSS) may include the united states global positioning system (Global Positioning System, GPS), the russian global navigation system (Global Navigation System, GLONASS), the european union galileo system, the chinese beidou navigation satellite system, regional navigation system or GNSS augmentation system (e.g., indian constellation navigation (Navigation with Indian Constellation, NAVIC), the japanese Quasi-zenith satellite system (Quasi-Zenith Satellite System, QZSS), the french satellite integrated doppler orbital imaging and radio positioning (Doppler Orbitography and Radio-positioning Integrated by Satellite, DORIS), and so forth). The positioning circuitry 1945 may include various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate communication over-the-air (OTA) communication) to communicate with components of a positioning network (e.g., navigation satellite constellation nodes).

The node or satellite of the navigation satellite constellation(s) (the "GNSS node") may provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight that may be used by a GNSS receiver (e.g., positioning circuitry 1945 and/or positioning circuitry implemented by UEs 101, 102, etc.) to determine its GNSS position. The GNSS signals may include pseudo-random codes (e.g., a sequence of ones and zeros) known to the GNSS receiver and messages including the time of transmission of the code epoch (time of transmission, toT) (e.g., a defined point in the pseudo-random code sequence) and the GNSS node position at ToT. The GNSS receiver may monitor/measure GNSS signals transmitted/broadcast by a plurality of GNSS nodes (e.g., four or more satellites) and solve various equations to determine the corresponding GNSS positions (e.g., spatial coordinates). The GNSS receiver may also implement a clock that is generally less stable and accurate than the atomic clock of the GNSS node, and may use the measured GNSS signals to determine a bias of the GNSS receiver relative to real time (e.g., a bias of the GNSS receiver clock relative to the GNSS node time). In some embodiments, the positioning circuitry 1945 may include a Micro-technology (Micro-Technology for Positioning, navigation, and Timing) IC for positioning, navigation, and Timing that uses a master Timing clock to perform position tracking/estimation without GNSS assistance.

The GNSS receiver may measure time of arrival (ToA) of GNSS signals from the plurality of GNSS nodes according to its own clock. The GNSS receiver may determine a time of flight (ToF) value for each received GNSS signal based on ToA and ToT, and may then determine a three-dimensional (3D) position and clock bias based on ToF. The 3D location may then be converted to latitude, longitude, and altitude. The positioning circuitry 1945 may provide data to the application circuitry 1905, which may include one or more of location data or time data. The application circuitry 1905 may use the time data to operate synchronously with other radio base stations (e.g., RAN nodes 111, 112, etc.).

The components shown in fig. 19 may communicate with each other using interface circuitry. As used herein, the term "interface circuit" may refer to, be part of, or include circuitry that supports the exchange of information between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an input/output (I/O) interface, a peripheral component interface, a network interface card, and so forth. Any suitable bus technology may be used in various implementations, including any number of technologies, including industry standard architecture (industry standard architecture, ISA), extended ISA (EISA), peripheral component interconnect (peripheral component interconnect, PCI), extended peripheral component interconnect (peripheral component interconnect extended, PCIx), PCI express (PCIe), or any number of other technologies. The bus may be a proprietary bus, for example, used in SoC-based systems. Other bus systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, among others.

Fig. 20 schematically illustrates a wireless network 2000 in accordance with various embodiments. The wireless network 2000 may include a UE 2002 in wireless communication with AN 2004. UE 2002 and AN 2004 may be similar to and substantially interchangeable with the mission components described elsewhere herein.

UE 2002 may be communicatively coupled with AN 2004 via connection 2006. Connection 2006 is shown as an air interface to enable communicative coupling and may be consistent with a cellular communication protocol such as the LTE protocol or the 5G NR protocol operating at millimeter wave (mmWave) or sub-6 GHz frequencies.

UE 2002 may include a host platform 2008 coupled to a modem platform 2010. Host platform 2008 can include application processing circuitry 2012 that can be coupled to protocol processing circuitry 2014 of modem platform 2010. The application processing circuitry 2012 may run various applications of source/receiver application data for the UE 2002. The application processing circuit 2012 may also implement one or more layers of operations to transmit/receive application data to/from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

The protocol processing circuitry 2014 may implement one or more layer operations to facilitate the transmission or reception of data over the connection 2006. Layer operations implemented by the protocol processing circuitry 2014 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

The modem platform 2010 may further include digital baseband circuitry 2016, which digital baseband circuitry 2016 may implement one or more layer operations of "lower" layer operations performed by protocol processing circuitry 2014 in the network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, where these functions may include one or more of: space-time, space-frequency, or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

The modem platform 2010 may further include transmit circuitry 2018, receive circuitry 2020, RF circuitry 2022, and RF front end (RFFE) circuitry 2024, which may include or be connected to one or more antenna panels 2026. Briefly, the transmit circuitry 2018 may include digital-to-analog converters, mixers, intermediate Frequency (IF) components, and the like; the receive circuit 2020 may include analog-to-digital converters, mixers, IF components, etc.; the RF circuit 2022 may include low noise amplifiers, power tracking components, and the like; RFFE circuit 2024 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of the components of the transmit circuitry 2018, receive circuitry 2020, RF circuitry 2022, RFFE circuitry 2024, and antenna panel 2026 (collectively "transmit/receive components") may be specific to the specifics of the particular implementation, e.g., whether the communication is TDM or FDM, at mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in a plurality of parallel transmit/receive chains, and may be arranged in the same or different chips/modules, etc.

In some embodiments, the protocol processing circuitry 2014 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.

UE reception may be established through and via antenna panel 2026, RFFE circuitry 2024, RF circuitry 2022, receive circuitry 2020, digital baseband circuitry 2016, and protocol processing circuitry 2014. In some embodiments, the antenna panel 2026 may receive transmissions from the AN 2004 by receiving beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 2026.

UE transmissions may be established via and through the protocol processing circuitry 2014, digital baseband circuitry 2016, transmit circuitry 2018, RF circuitry 2022, RFFE circuitry 2024, and antenna panel 2026. In some embodiments, the transmit component of the UE 2004 may apply a spatial filter to the data to be transmitted to form a transmit beam that is transmitted by the antenna element of the antenna panel 2026.

Similar to UE 2002, AN 2004 can include a host platform 2028 coupled to a modem platform 2030. Host platform 2028 may include application processing circuitry 2032 coupled with protocol processing circuitry 2034 of modem platform 2030. The modem platform may also include digital baseband circuitry 2036, transmit circuitry 2038, receive circuitry 2040, RF circuitry 2042, RFFE circuitry 2044, and an antenna panel 2046. The components of AN 2004 may be similar to the components of UE 2002 under the same name and may be substantially interchangeable with the components of UE 2002 under the same name. In addition to performing data transmission/reception as described above, the components of the AN 2008 may also perform various logic functions including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 21 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. 21 shows a diagrammatic representation of a hardware resource 2100, which includes one or more processors (or processor cores) 2110, one or more memory/storage devices 2120, and one or more communication resources 2130, each of which can be communicatively coupled via a bus 2140. The hardware resource 2100 may be part of a UE, AN, or AN LMF. For embodiments that utilize node virtualization (e.g., NFV), the hypervisor 2102 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize hardware resources 2100.

The processor 2110 (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, a processor 2112 and a processor 2114.

Memory/storage 2120 may include main memory, disk memory, or any suitable combination thereof. Memory/storage 2120 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 2130 may include an interconnection or network interface component or other suitable device to communicate with one or more peripheral devices 2104 or one or more databases 2106 via network 2108. For example, the communication resources 2130 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, bluetooth components (e.g., bluetooth low energy), wi-Fi components, and other communication components.

The instructions 2150 may include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors 2110 to perform any one or more of the methods discussed herein. The instructions 2150 may reside, completely or partially, within at least one of the processor 2110 (e.g., within a processor's cache memory), the memory/storage 2120, or any suitable combination thereof. Further, any portion of instructions 2150 may be transferred from any combination of peripherals 2104 or databases 2106 to hardware resource 2100. Accordingly, the processor 2110, memory/storage 2120, peripheral devices 2104, and memory of database 2106 are examples of computer-readable and machine-readable media.

The following paragraphs describe examples of various embodiments.

Example 1 includes an apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to: encoding a beam fault indication for transmission to a first Access Node (AN) associated with a first frequency band, wherein the beam fault indication indicates a beam fault in a second frequency band; and decoding a Beam Fault Recovery (BFR) configuration message received from the first AN, wherein the BFR configuration message includes BFR configuration information received by the first AN from a second AN associated with the second frequency band.

Example 2 includes the apparatus of example 1, wherein the beam fault indication is encoded using a medium access control element (MAC-CE), wherein the MAC-CE comprises one or more of: a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify of beam faults in the second frequency band; and a band ID indicating an identity of the second band.

Example 3 includes the apparatus of example 1, wherein the beam failure indication is encoded using Uplink Control Information (UCI), wherein the UCI includes a band ID indicating an identity of the second band.

Example 4 includes the apparatus of example 2 or 3, wherein the MAC-CE or UCI further includes a beam index indicating an index of a new best beam for the second frequency band.

Example 5 includes the apparatus of example 1, wherein the BFR configuration message is received from the first AN via one or more of: dedicated Radio Resource Control (RRC) signaling, medium access control elements (MAC-CEs), downlink Control Information (DCI), or a combination of the above.

Example 6 includes the apparatus of example 1, wherein the BFR configuration message includes one or more of: a band ID indicating an identity of the second band; information related to one or more candidate beams in the second frequency band and corresponding reference signals; and a BFR method indicating whether information regarding a new best beam for the second frequency band is to be encoded by the UE using a Physical Random Access Channel (PRACH) preamble.

Example 7 includes the apparatus of example 1, wherein the processing circuitry is further configured to: a new best beam for the second frequency band is determined from the candidate beams based on a measurement of Reference Signal Received Power (RSRP) of one or more reference signals received from the second AN corresponding to the one or more candidate beams indicated in the BFR configuration message.

Example 8 includes the apparatus of example 7, wherein the reference signals comprise one or more channel state information reference signal (CSI-RS) signals or Synchronization Signal Block (SSB) signals.

Example 9 includes the apparatus of example 7, wherein the processing circuitry is further configured to: a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam is selected for transmission to the second AN.

Example 10 includes the apparatus of example 7, wherein the processing circuitry is further configured to: a beam indication message is encoded for transmission to the first AN, wherein the beam indication message indicates the new best beam and is further forwarded by the first AN to the second AN.

Example 11 includes the apparatus of example 10, wherein the beam indication message is encoded using a medium access control element (MAC-CE), wherein the MAC-CE comprises one or more of: a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify the first AN of a new best beam for the second frequency band; and a band ID indicating an identity of the second band.

Example 12 includes the apparatus of example 10, wherein the beam indication message is encoded using Uplink Control Information (UCI), wherein the UCI includes a band ID that indicates an identity of the second band.

Example 13 includes the apparatus of example 9 or 10, wherein the processing circuitry is further configured to: a Physical Downlink Control Channel (PDCCH) received from the first AN is decoded, wherein the first AN scrambles the PDCCH with a Radio Network Temporary Identifier (RNTI), and the UE is configured with the RNTI after decoding the BFR configuration message.

Example 14 includes the apparatus of example 9 or 10, wherein the processing circuitry is further configured to: a Physical Downlink Control Channel (PDCCH) received from the second AN is decoded, wherein the PDCCH is quasi co-located with the new best beam (QCLed).

Example 15 includes AN apparatus for a first Access Node (AN) associated with a first frequency band, wherein the apparatus comprises processing circuitry configured to: decoding an indication received from a User Equipment (UE) regarding beam faults in a second frequency band; encoding a beam fault message for transmission to a second AN associated with the second frequency band, wherein the beam fault message indicates a beam fault in the second frequency band; and encoding a Beam Fault Recovery (BFR) configuration message for transmission to the UE, wherein the BFR configuration message includes BFR configuration information received from the second AN.

Example 16 includes the apparatus of example 15, wherein the processing circuitry is further configured to: a beam indication message is encoded for transmission to the second AN, wherein the beam indication message indicates a new best beam determined by the UE.

Example 17 includes the apparatus of example 15, wherein the processing circuitry is further configured to: a Physical Downlink Control Channel (PDCCH) is encoded for transmission to the UE, wherein the PDCCH is scrambled using a Radio Network Temporary Identifier (RNTI) carried in the BFR configuration message.

Example 18 includes AN apparatus for a second Access Node (AN) associated with a second frequency band, wherein the apparatus comprises processing circuitry configured to: decoding a beam fault message received from a first AN associated with a first frequency band, wherein the beam fault message indicates that a User Equipment (UE) has detected a beam fault in the second frequency band; and encoding Beam Fault Recovery (BFR) configuration information for transmission to the first AN.

Example 19 includes the apparatus of example 18, wherein the processing circuitry is further configured to: one or more reference signals corresponding to one or more candidate beams indicated in the BFR configuration information are encoded for transmission to the UE.

Example 20 includes the apparatus of example 18, wherein the processing circuitry is further configured to: a Physical Random Access Channel (PRACH) preamble received from the UE is decoded to determine a new best beam selected by the UE.

Example 21 includes an apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to: a Beam Fault Recovery (BFR) request is encoded for transmission to a first Access Node (AN) associated with a first frequency band, wherein the BFR request indicates a beam fault in a second frequency band and a new best beam for the second frequency band, and the BFR request is further forwarded by the first AN to a second AN associated with the second frequency band.

Example 22 includes the apparatus of example 21, wherein the processing circuitry is further configured to: after detecting a beam failure in the second frequency band, a new best beam for the second frequency band is determined based on periodic beam measurements in the second frequency band.

Example 23 includes the apparatus of example 21, wherein the processing circuitry is further configured to: a Physical Downlink Control Channel (PDCCH) received from the first AN is decoded, wherein the UE is configured with a Radio Network Temporary Identifier (RNTI) used by the first AN to scramble the PDCCH.

Example 24 includes the apparatus of example 21, wherein the processing circuitry is further configured to: a Physical Downlink Control Channel (PDCCH) received from the second AN is decoded, wherein the PDCCH is quasi co-located with the new best beam (QCLed).

Example 25 includes an apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to: after detecting a beam fault in a frequency band, determining a new best beam for the frequency band based on periodic beam measurements in the frequency band; and encoding a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam for transmission in a Random Access Channel (RACH) resource corresponding to the new best beam to AN Access Node (AN) associated with the frequency band.

Example 26 includes a method for a User Equipment (UE), wherein the method comprises: encoding a beam fault indication for transmission to a first Access Node (AN) associated with a first frequency band, wherein the beam fault indication indicates a beam fault in a second frequency band; and decoding a Beam Fault Recovery (BFR) configuration message received from the first AN, wherein the BFR configuration message includes BFR configuration information received by the first AN from a second AN associated with the second frequency band.

Example 27 includes the method of example 26, wherein the beam fault indication is encoded using a medium access control element (MAC-CE), wherein the MAC-CE comprises one or more of: a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify of beam faults in the second frequency band; and a band ID indicating an identity of the second band.

Example 28 includes the method of example 26, wherein the beam failure indication is encoded using Uplink Control Information (UCI), wherein the UCI includes a band ID that indicates an identity of the second band.

Example 29 includes the method of example 27 or 28, wherein the MAC-CE or UCI further includes a beam index indicating an index of a new best beam for the second frequency band.

Example 30 includes the method of example 26, wherein the BFR configuration message is received from the first AN via one or more of: dedicated Radio Resource Control (RRC) signaling, medium access control elements (MAC-CEs), downlink Control Information (DCI), or a combination of the above.

Example 31 includes the method of example 26, wherein the BFR configuration message includes one or more of: a band ID indicating an identity of the second band; information related to one or more candidate beams in the second frequency band and corresponding reference signals; and a BFR method indicating whether information regarding a new best beam for the second frequency band is to be encoded by the UE using a Physical Random Access Channel (PRACH) preamble.

Example 32 includes the method of example 26, wherein the method further comprises: a new best beam for the second frequency band is determined from the candidate beams based on a measurement of Reference Signal Received Power (RSRP) of one or more reference signals received from the second AN corresponding to the one or more candidate beams indicated in the BFR configuration message.

Example 33 includes the method of example 32, wherein the reference signals comprise one or more channel state information reference signal (CSI-RS) signals or Synchronization Signal Block (SSB) signals.

Example 34 includes the method of example 32, wherein the method further comprises: a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam is selected for transmission to the second AN.

Example 35 includes the method of example 32, wherein the method further comprises: a beam indication message is encoded for transmission to the first AN, wherein the beam indication message indicates the new best beam and is further forwarded by the first AN to the second AN.

Example 36 includes the method of example 35, wherein the beam indication message is encoded using a medium access control element (MAC-CE), wherein the MAC-CE includes one or more of: a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify the first AN of a new best beam for the second frequency band; and a band ID indicating an identity of the second band.

Example 37 includes the method of example 35, wherein the beam indication message is encoded using Uplink Control Information (UCI), wherein the UCI includes a band ID that indicates an identity of the second band.

Example 38 includes the method of example 34 or 35, wherein the method further comprises: a Physical Downlink Control Channel (PDCCH) received from the first AN is decoded, wherein the first AN scrambles the PDCCH with a Radio Network Temporary Identifier (RNTI), and the UE is configured with the RNTI after decoding the BFR configuration message.

Example 39 includes the method of example 34 or 35, wherein the method further comprises: a Physical Downlink Control Channel (PDCCH) received from the second AN is decoded, wherein the PDCCH is quasi co-located with the new best beam (QCLed).

Example 40 includes a method for a first Access Node (AN) associated with a first frequency band, wherein the method comprises: decoding an indication received from a User Equipment (UE) regarding beam faults in a second frequency band; encoding a beam fault message for transmission to a second AN associated with the second frequency band, wherein the beam fault message indicates a beam fault in the second frequency band; and encoding a Beam Fault Recovery (BFR) configuration message for transmission to the UE, wherein the BFR configuration message includes BFR configuration information received from the second AN.

Example 41 includes the method of example 40, wherein the method further comprises: a beam indication message is encoded for transmission to the second AN, wherein the beam indication message indicates a new best beam determined by the UE.

Example 42 includes the method of example 40, wherein the method further comprises: a Physical Downlink Control Channel (PDCCH) is encoded for transmission to the UE, wherein the PDCCH is scrambled using a Radio Network Temporary Identifier (RNTI) carried in the BFR configuration message.

Example 43 includes a method for a second Access Node (AN) associated with a second frequency band, wherein the method comprises: decoding a beam fault message received from a first AN associated with a first frequency band, wherein the beam fault message indicates that a User Equipment (UE) has detected a beam fault in the second frequency band; and encoding Beam Fault Recovery (BFR) configuration information for transmission to the first AN.

Example 44 includes the method of example 43, wherein the method further comprises: one or more reference signals corresponding to one or more candidate beams indicated in the BFR configuration information are encoded for transmission to the UE.

Example 45 includes the method of example 43, wherein the method further comprises: a Physical Random Access Channel (PRACH) preamble received from the UE is decoded to determine a new best beam selected by the UE.

Example 46 includes a method for a User Equipment (UE), wherein the method comprises: a Beam Fault Recovery (BFR) request is encoded for transmission to a first Access Node (AN) associated with a first frequency band, wherein the BFR request indicates a beam fault in a second frequency band and a new best beam for the second frequency band, and the BFR request is further forwarded by the first AN to a second AN associated with the second frequency band.

Example 47 includes the method of example 46, wherein the method further comprises: after detecting a beam failure in the second frequency band, a new best beam for the second frequency band is determined based on periodic beam measurements in the second frequency band.

Example 48 includes the method of example 46, wherein the method further comprises: a Physical Downlink Control Channel (PDCCH) received from the first AN is decoded, wherein the UE is configured with a Radio Network Temporary Identifier (RNTI) used by the first AN to scramble the PDCCH.

Example 49 includes the method of example 46, wherein the method further comprises: a Physical Downlink Control Channel (PDCCH) received from the second AN is decoded, wherein the PDCCH is quasi co-located with the new best beam (QCLed).

Example 50 includes a method for a User Equipment (UE), wherein the method comprises: after detecting a beam fault in a frequency band, determining a new best beam for the frequency band based on periodic beam measurements in the frequency band; and encoding a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam for transmission in a Random Access Channel (RACH) resource corresponding to the new best beam to AN Access Node (AN) associated with the frequency band.

Example 51 includes a computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by processing circuitry, cause the processing circuitry to perform the method of any of examples 26 to 50.

Example 52 includes an apparatus comprising means for performing the method of any of examples 26 to 50.

Although certain embodiments have been illustrated and described herein for purposes of description, various alternative and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This disclosure is intended to cover any adaptations or variations of the embodiments discussed herein. Accordingly, it is readily understood that the embodiments described herein are limited only by the following claims and their equivalents.

Claims (25)

1. An apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to:

encoding a beam fault indication for transmission to a first Access Node (AN) associated with a first frequency band, wherein the beam fault indication indicates a beam fault in a second frequency band; and

a Beam Fault Recovery (BFR) configuration message received from the first AN is decoded, wherein the BFR configuration message includes BFR configuration information received by the first AN from a second AN associated with the second frequency band.

2. The apparatus of claim 1, wherein the beam fault indication is encoded using a medium access control element (MAC-CE), wherein the MAC-CE comprises one or more of:

a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify of beam faults in the second frequency band; and

a band ID indicating an identity of the second band.

3. The apparatus of claim 1, wherein the beam failure indication is encoded using Uplink Control Information (UCI) comprising a band ID indicating an identity of the second frequency band.

4. The apparatus of claim 2 or 3, wherein the MAC-CE or UCI further comprises a beam index indicating an index of a new best beam for the second frequency band.

5. The apparatus of claim 1, wherein the BFR configuration message is received from the first AN via one or more of: dedicated Radio Resource Control (RRC) signaling, medium access control elements (MAC-CEs), downlink Control Information (DCI), or a combination of the above.

6. The apparatus of claim 1, wherein the BFR configuration message includes one or more of:

a band ID indicating an identity of the second band;

information related to one or more candidate beams in the second frequency band and corresponding reference signals; and

a BFR method indicates whether information regarding a new best beam for the second frequency band is to be encoded by the UE using a Physical Random Access Channel (PRACH) preamble.

7. The apparatus of claim 1, wherein the processing circuit is further configured to:

a new best beam for the second frequency band is determined from the candidate beams based on a measurement of Reference Signal Received Power (RSRP) of one or more reference signals received from the second AN corresponding to the one or more candidate beams indicated in the BFR configuration message.

8. The apparatus of claim 7, wherein the reference signals comprise one or more channel state information reference signal (CSI-RS) signals or Synchronization Signal Block (SSB) signals.

9. The apparatus of claim 7, wherein the processing circuit is further configured to:

a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam is selected for transmission to the second AN.

10. The apparatus of claim 7, wherein the processing circuit is further configured to:

a beam indication message is encoded for transmission to the first AN, wherein the beam indication message indicates the new best beam and is further forwarded by the first AN to the second AN.

11. The apparatus of claim 10, wherein the beam indication message is encoded using a medium access control element (MAC-CE), wherein the MAC-CE comprises one or more of:

a Logical Channel ID (LCID) indicating that the MAC-CE is configured to notify the first AN of a new best beam for the second frequency band; and

a band ID indicating an identity of the second band.

12. The apparatus of claim 10, wherein the beam indication message is encoded using Uplink Control Information (UCI) including a band ID indicating an identity of the second frequency band.

13. The apparatus of claim 9 or 10, wherein the processing circuit is further configured to:

a Physical Downlink Control Channel (PDCCH) received from the first AN is decoded, wherein the first AN scrambles the PDCCH with a Radio Network Temporary Identifier (RNTI), and the UE is configured with the RNTI after decoding the BFR configuration message.

14. The apparatus of claim 9 or 10, wherein the processing circuit is further configured to:

a Physical Downlink Control Channel (PDCCH) received from the second AN is decoded, wherein the PDCCH is quasi co-located with the new best beam (QCLed).

15. AN apparatus for a first Access Node (AN) associated with a first frequency band, wherein the apparatus comprises processing circuitry configured to:

decoding an indication received from a User Equipment (UE) regarding beam faults in a second frequency band;

encoding a beam fault message for transmission to a second AN associated with the second frequency band, wherein the beam fault message indicates a beam fault in the second frequency band; and

a Beam Fault Recovery (BFR) configuration message is encoded for transmission to the UE, wherein the BFR configuration message includes BFR configuration information received from the second AN.

16. The apparatus of claim 15, wherein the processing circuit is further configured to:

a beam indication message is encoded for transmission to the second AN, wherein the beam indication message indicates a new best beam determined by the UE.

17. The apparatus of claim 15, wherein the processing circuit is further configured to:

a Physical Downlink Control Channel (PDCCH) is encoded for transmission to the UE, wherein the PDCCH is scrambled using a Radio Network Temporary Identifier (RNTI) carried in the BFR configuration message.

18. AN apparatus for a second Access Node (AN) associated with a second frequency band, wherein the apparatus comprises processing circuitry configured to:

decoding a beam fault message received from a first AN associated with a first frequency band, wherein the beam fault message indicates that a User Equipment (UE) has detected a beam fault in the second frequency band; and

beam Fault Recovery (BFR) configuration information is encoded for transmission to the first AN.

19. The apparatus of claim 18, wherein the processing circuit is further configured to:

one or more reference signals corresponding to one or more candidate beams indicated in the BFR configuration information are encoded for transmission to the UE.

20. The apparatus of claim 18, wherein the processing circuit is further configured to:

a Physical Random Access Channel (PRACH) preamble received from the UE is decoded to determine a new best beam selected by the UE.

21. An apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to:

a Beam Fault Recovery (BFR) request is encoded for transmission to a first Access Node (AN) associated with a first frequency band, wherein the BFR request indicates a beam fault in a second frequency band and a new best beam for the second frequency band, and the BFR request is further forwarded by the first AN to a second AN associated with the second frequency band.

22. The apparatus of claim 21, wherein the processing circuit is further configured to:

after detecting a beam failure in the second frequency band, a new best beam for the second frequency band is determined based on periodic beam measurements in the second frequency band.

23. The apparatus of claim 21, wherein the processing circuit is further configured to:

a Physical Downlink Control Channel (PDCCH) received from the first AN is decoded, wherein the UE is configured with a Radio Network Temporary Identifier (RNTI) used by the first AN to scramble the PDCCH.

24. The apparatus of claim 21, wherein the processing circuit is further configured to:

a Physical Downlink Control Channel (PDCCH) received from the second AN is decoded, wherein the PDCCH is quasi co-located with the new best beam (QCLed).

25. An apparatus for a User Equipment (UE), wherein the apparatus comprises processing circuitry configured to:

after detecting a beam fault in a frequency band, determining a new best beam for the frequency band based on periodic beam measurements in the frequency band; and

a Physical Random Access Channel (PRACH) preamble corresponding to the new best beam is encoded for transmission in a Random Access Channel (RACH) resource corresponding to the new best beam to AN Access Node (AN) associated with the frequency band.