CN111918324A

CN111918324A - Method of SCell beam failure detection and beam failure recovery request transmission in NR

Info

Publication number: CN111918324A
Application number: CN202010391200.XA
Authority: CN
Inventors: 王国童; 张羽书; A·达维多夫; 熊岗
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-05-10
Filing date: 2020-05-11
Publication date: 2020-11-10
Anticipated expiration: 2040-05-11
Also published as: CN111918324B

Abstract

Described herein is an apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells). The apparatus includes a Radio Frequency (RF) interface and one or more processors coupled to the RF interface. The one or more processors are configured to: performing beam failure detection on the plurality of SCells to detect a beam failure event of one or more SCells of the plurality of SCells; and in response to detecting a beam failure event on the one or more scells, initiating transmission of a beam failure recovery request (BFRQ) by sending information regarding the beam failure event and the failed CC index to the gNB via the RF interface.

Description

Method of SCell beam failure detection and beam failure recovery request transmission in NR

Technical Field

Various embodiments herein relate generally to the field of wireless communications, and more particularly, to a method for secondary cell (SCell) beam failure detection and beam failure recovery request transmission in a new air interface (NR).

Background

Mobile communications have evolved significantly from early speech systems to today's highly sophisticated integrated communication platforms. The next generation wireless communication system 5G (or new air interface (NR)) will enable various users and applications to access information and share data anytime and anywhere. NR promises to be a unified network/system, aimed at satisfying distinct and sometimes conflicting performance dimensions and services. These different multidimensional requirements are driven by different services and applications. In general, NR will be based on 3GPP (third generation partnership project) LTE (long term evolution) -Advanced evolution, with the addition of potentially new Radio Access Technologies (RATs), enriching people's lives with better, simple and seamless radio connection solutions. NR will enable everything to be connected wirelessly and provide fast, rich content and services.

Drawings

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

fig. 1 illustrates an example method for beam failure detection of an SCell in accordance with some embodiments.

Fig. 2A-2C illustrate three example processes for transmitting a beam failure event, a failed CC index, and new beam information, under three options, respectively, in accordance with some embodiments.

Fig. 3A-3C illustrate three example processes for sending beam failure recovery requests, under three options, respectively, in accordance with some embodiments.

Fig. 4 illustrates an example process for SCell beam failure recovery operation after receiving an SCell activation/deactivation command, in accordance with some embodiments.

Fig. 5 illustrates an example architecture of a system of networks according to various embodiments.

Fig. 6 illustrates an example of an infrastructure device in accordance with various embodiments.

Fig. 7 illustrates an example of a platform (or "device") according to various embodiments.

Fig. 8 illustrates example components of a baseband circuit and Radio Front End Module (RFEM) in accordance with various embodiments.

Fig. 9 illustrates various protocol functions that may be implemented in a wireless communication device, in accordance with various embodiments.

Fig. 10 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 methodologies discussed herein, according to some example embodiments.

Fig. 11 shows an example scenario for reporting a beam failure event, a failed CC index, and new beam information using option 2.

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

Detailed Description

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

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

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

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

Example embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel, concurrently or with simultaneous execution. In addition, the order of the operations may be rearranged. A process may terminate when its operations are completed, but may also have additional operations not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function and/or the main function.

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

In some NR implementations, the UE may trigger a mechanism to detect, report, and recover from beam failures, which may be referred to as a "beam failure recovery procedure. A beam failure event may occur, for example, when the quality of a beam pair link of an associated control channel drops below a threshold, when an associated timer times out, etc. The transmission of a beam failure recovery request may be triggered when a beam failure event occurs. The network may illustratively configure the UE with resources for UL transmission of signals for recovery purposes.

In some NR implementations, a UE may operate with multiple Component Carriers (CCs) including a primary cell (PCell) and multiple secondary cells (scells). For Beam Failure Recovery (BFR) in PCell, various BFR mechanisms have been proposed. Similar to PCell, beam failure may also occur in SCell. Thus, it may need to be considered how to report a beam failure of the SCell.

In NR Rel-16, three options are discussed for SCell beam failure recovery operation for UE reporting failed Component Carrier (CC) index and new beam information (if present) through PUSCH or PUCCH on PCell. These three options include:

option 1: reporting, by a Medium Access Control (MAC) Control Element (CE), a failed CC index, new beam information (if any), and a beam failure event in a single report;

option 2: step 1: UE transmits beam failure event, step 2: UE reports new beam information (if any) and failed CC index;

step 1 is carried by special PUCCH/PRACH resources;

step 2 is carried by MAC CE or Uplink Control Information (UCI)

Option 3: step 1: UE transmits the wave beam fault event and the fault CC index, and the step 2: UE reports new beam information (if present);

step 2 is carried by MAC CE or UCI;

PUCCH/PRACH is used for step 1 to implicitly carry failed CC index

However, there may be some issues to consider when reporting beam failure events, failed CC indexes, and new beam information. For example, fig. 11 shows an example scenario for reporting using option 2. As shown in fig. 11, if a beam failure occurs on an SCell (e.g., SCell # a), the UE may need to report a beam failure event to the gNB and generate a corresponding MAC CE or UCI. Before transmitting the MAC CE/UCI, if there is another SCell (e.g., SCell # B) failed, it needs to be considered whether information of the latest failed SCell can be put in the same MAC CE/UCI.

Another problem is how to maintain timers and counters for SCell beam failure detection and beam failure recovery request transmission on PCell. Different schemes may be applied for timer and counter maintenance, allowing for different options.

A third problem is that after receiving an SCell deactivation command, the UE may stop beam failure detection on the corresponding SCell.

Another problem is that beam failure recovery requests (BFRQ) for different CCs may be multiplexed in overlapping symbols. Thus, consideration needs to be given to how to handle conflicts.

In the following, it is discussed how to perform a beam failure recovery procedure for an SCell according to different options, in particular for SCell beam failure recovery operations, maintenance for beam failure detection and beam failure recovery request transmission.

Timer and counter for SCell beam failure detection

In an embodiment, for SCell beam failure recovery operations, the UE may maintain a counter C1 and a timer T1 for SCell beam failure detection, either for each SCell or for each SCell configured with beam failure detection. In an example, the counter C1 and the timer T1 may be maintained in the physical layer or the MAC layer. Further, a counter C1 and a timer T1 may be maintained separately for each SCell or for each SCell configured with beam failure detection.

Fig. 1 illustrates an example method 100 for beam failure detection of an SCell in accordance with some embodiments. The method 100 may be performed by a UE or a portion thereof.

As shown in fig. 1, the method may begin by: at block 102, a beam failure is detected for the SCell. At block 104, the method may include: the timer T1 is restarted each time a beam failure instance is detected by incrementing the counter C1. In an example, it may be determined that one instance of beam failure is detected when a block error rate (BLER) exceeds a certain threshold. At block 106, the method may include: if the timer T1 expires, the counter C1 is reset. At block 108, the method may include: if the counter C1 reaches a predefined maximum value, a beam failure event is declared and a beam failure recovery request is triggered.

As described above, when a beam failure occurs on the SCell, the UE may transmit a beam failure event, a failed CC index, and new beam information to the gNB. Fig. 2A-2C illustrate three example processes 200a-200C for transmitting a beam failure event, a failed CC index, and new beam information, depending on three options, respectively, in accordance with some embodiments. These procedures may be performed by the UE or a portion thereof.

Fig. 2A depicts a process 200a when option 1 is used (i.e., a beam failure event, a failed CC index, and new beam information (if any) are transmitted in a single report by the MAC CE). In an embodiment, the UE may determine that the counter C1 has reached a predefined maximum value for the SCell (e.g., SCell # a), as in block 202 a. In block 204a, the UE may check whether there is already a MAC CE transmission. In an example, the UE may check whether the corresponding MAC CE has been transmitted for another SCell (e.g., SCell # B) that detected the beam failure event. If the UE determines that there is no MAC CE transmission yet (block 206a), the UE may trigger a MAC CE to transmit beam failure information including a beam failure event, a failed CC index, and new beam information for all failed scells (e.g., SCell # a and another SCell # B that detected the beam failure event but has not transmitted the corresponding MAC CE) (block 208 a). However, if the UE determines that a MAC CE for another SCell (e.g., SCell # B) beam failure information has been transmitted and does not receive an Acknowledgement (ACK) for the MAC CE, the UE may trigger a new MAC CE to transmit the beam failure information for SCell # a (block 212 a).

Fig. 2B depicts a procedure 200B when option 2 is used, i.e., the beam failure event is transmitted over the dedicated PUCCH/PRACH resource in step 1, and the failed CC index and new beam information (if present) are transmitted over the MAC CE (or UCI) in step 2. In an embodiment, the UE may determine that the counter C1 has reached a predefined maximum value for the SCell (e.g., SCell # a), as in block 202 b. At block 204B, the UE may check whether step 1 operation for another SCell (e.g., SCell # B) is running and, if so, whether a MAC CE for SCell # B has been transmitted. If the UE determines that no step 1 is triggered (i.e., no step 1 operation is running) (block 206b), the UE may trigger step 1 operation for SCell # a (block 208 b). If the UE determines that step 1 has been triggered for SCell # B (i.e., there is a step 1 operation running), but a MAC CE for SCell # B has not yet been transmitted (block 210B), the UE may update the MAC CE to include beam failure information for all failed scells (e.g., including SCell # a and SCell # B) (block 212B). If the UE determines that a MAC CE for SCell # B beam failure information has been transmitted and no ACK for the MAC CE is received (block 214B), the UE may trigger separate step 1 and step 2 operations to transmit beam failure information for SCell # a (block 216B). In some embodiments, the step 1 and step 2 operations for SCell # a may occur immediately after a beam failure event is declared for SCell # a. Alternatively, the step 1 and step 2 operations for SCell # a may occur after transmission/retransmission (successful or unsuccessful) of the existing MAC CE is completed.

In an embodiment, the number of failed scells that can be transmitted via one MAC CE may be configurable or predefined. Alternatively, it may be indicated by a header of the MAC CE, e.g. including a specific field in the MAC CE header indicating the number of failed scells.

In another embodiment, the failed SCell index information and/or new beam information within one MAC CE is limited to only one SCell. In this case, for an SCell (e.g., SCell # a), when counter C1 reaches a predefined maximum, the UE may trigger separate step 1 and step 2 operations for SCell # a, regardless of whether there is a step 1 or step 2 operation running for other scells.

Fig. 2C depicts a procedure 200C when option 3 is used, i.e., beam failure event and implicit failed CC index are transmitted over dedicated PUCCH/PRACH resources in step 1, and new beam information (if any) is transmitted over MAC CE (or UCI) in step 2. In an embodiment, the UE may determine that the counter C1 has reached a predefined maximum value for the SCell (e.g., SCell # a), as in block 202C. At block 204c, the UE may trigger separate step 1 and step 2 operations for SCell # a, regardless of whether there is a step 1 or step 2 operation running for other scells.

Timer and counter for SCell beam failure recovery request transmission through PCell

In some embodiments, in addition to the timer T1 and counter C1 for SCell beam failure detection, the UE may additionally maintain another timer T2 and another counter C2 for SCell beam failure recovery request transmission (including beam failure event, failed CC index, and new beam information) to avoid unnecessary transmissions. In an embodiment, the timer T2 and the counter C2 may be maintained in the physical layer or the MAC layer, as the timer T1 and the counter C1. Figures 3A-3C illustrate three example processes 300a-300C for sending beam failure recovery requests depending on three options, respectively, in accordance with some embodiments. These procedures may be performed by the UE or a portion thereof.

Fig. 3A depicts a process 300a when option 1 is used (i.e., the beam failure event, failed CC index, and new beam information (if any) are transmitted in a single report by the MAC CE). As shown in fig. 3A, the UE may start a timer T2 after declaring a beam failure event for an SCell, and start a counter C2 after transmitting a corresponding MAC CE, as in block 302 a. The UE may then increment a counter C2 by one each time the MAC CE is retransmitted, as in block 304 a. After receiving the ACK for the MAC CE, the UE may stop/reset the timer T2 and the counter C2, as in block 306 a. If the predefined maximum value of timer T2 or counter C2 is reached, the UE may stop transmitting a beam failure recovery request (or equivalently, a MAC CE) for the SCell on the PCell, as in block 308 a.

It should be understood that for option 1, the timer T2 and the counter C2 may be optional, since hybrid automatic repeat request (HARQ) may perform control of the retransmission MAC CE. It should also be understood that while both timer T2 and counter C2 are used herein, in other embodiments, only one of timer T2 and counter C2 may be used.

Fig. 3B depicts a procedure 300B when option 2 is used, i.e., the beam failure event is transmitted over dedicated PUCCH/PRACH resources in step 1, and the failed CC index and new beam information (if present) is transmitted over MAC CE (or UCI) in step 2. In this case, the UE may maintain a timer T2 and a counter C2 for step 1. As shown in fig. 3B, after transmitting the beam failure event for the first time in step 1, the UE may start a timer T2 and a counter C2, as in block 302B. Then, each time a beam failure event is transmitted in step 1, the counter C2 may be incremented by one, as in block 304 b. After reaching the predefined maximum of timer T2 or counter C2, or having received an uplink grant, or beginning to transmit a MAC CE, the UE may stop running/resetting timer T2 and counter C2, as in block 306 b. If the predefined maximum of the timer T2 or the counter C2 is reached and the transmission of the MAC CE has not started, the UE may stop the transmission of the MAC CE, as in block 308 b.

It should be appreciated that for option 2, the UE may maintain only one timer T2 and/or counter C2 for all scells. For example, if a beam failure event is declared for an SCell (e.g., SCell # a) (e.g., counter C1 reaches a predefined maximum value for SCell # a), the UE may first check whether timer T2 and/or counter C2 are running before triggering step 1 transmission. If timer T2 and/or counter C2 are running, the UE may cancel step 1 transmission for SCell # a and update the MAC CE to include beam failure information for SCell # a, as described above. Conversely, if the timer T2 and/or the counter C2 are not running, the UE may trigger the step 1 transmission and start the timer T2 and/or the counter C2.

It should also be understood that while both timer T2 and counter C2 are used herein, in other embodiments, only one of timer T2 and counter C2 may be used.

Fig. 3C depicts a procedure 300C when option 3 is used, i.e., beam failure event and implicit failed CC index are transmitted over dedicated PUCCH/PRACH resources in step 1, and new beam information (if any) is transmitted over MAC CE (or UCI) in step 2. In this case, the UE may maintain a separate timer T2 and counter C2 for each SCell transmission for step 1 because the failed SCell index is implicitly transmitted in step 1. As shown in fig. 3C, after triggering step 1 transmission for an SCell (e.g., SCell # a) for the first time, the UE may start a corresponding timer T2 and counter C2 for SCell # a, as in block 302C. Then, after each step 1 retransmission, the UE may increment a counter C2 by one, as in block 304C. After reaching a predefined maximum value for timer T2 or counter C2, or starting to transmit the corresponding MAC CE for SCell # a, the UE may stop running/reset timer T2 and counter C2 for SCell # a, as in block 306C.

It should be appreciated that although both timer T2 and counter C2 are used herein, in other embodiments, only one of timer T2 and counter C2 may be used.

SCell beam failure recovery operation upon reception of SCell activation/deactivation

In some cases, the gNB may activate/deactivate the SCell through an SCell activation/deactivation MAC CE. After receiving the deactivation command, the UE may cease beam failure recovery operations on the corresponding SCell.

Fig. 4 illustrates an example process 400 for SCell beam failure recovery operation after receiving SCell activation/deactivation in accordance with some embodiments. Process 400 may be performed by a UE or a portion thereof.

As shown in fig. 4, at block 402, the UE may receive an SCell deactivation command through an SCell activation/deactivation MAC CE. After receiving the SCell deactivation command, the UE may cease beam failure recovery operations on the corresponding SCell (e.g., SCell # a), including beam failure detection on the corresponding SCell, at block 404. At block 406, the UE may reset the counter C1 and the timer T1 for SCell # a. In addition, if the UE also maintains timer T2 and counter C2 for SCell # a, timer T2 and counter C2 for SCell # a may also be stopped.

Conflict handling for BFRQ of different CCs

In some cases, the UE may report BFRQs from different CCs over different resources. For example, the UE may report a BFRQ for the PCell through the PRACH, while the UE may report a BFRQ for the SCell through the PUCCH or another PRACH.

In an embodiment, resources for BFRQ for different CCs may be multiplexed in a Time Division Multiplexing (TDM) manner. In another embodiment, the resources for BFRQ may be multiplexed in overlapping symbols. In this case, the UE may transmit BFRQ resources at the highest priority, where the priority may be defined based on the CC index, e.g., the lowest CC ID has higher priority, and/or on the channel type, e.g., contention-based PRACH > contention-free PRACH > PUCCH.

Fig. 5 illustrates an example architecture of a system 500 of networks according to various embodiments. The following description is provided for an example system 500 that operates in conjunction with the 5G or NR system standards provided by the LTE system standards and 3GPP technical specifications. However, example embodiments are not limited thereto, and the described embodiments may be applicable to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and so forth.

As shown in fig. 5, system 500 includes UE 501a and UE 501b (collectively "UE 501"). In this example, the UE 501 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronic device, a cellular phone, a smartphone, a feature phone, a tablet computer, a wearable computer device, a Personal Digital Assistant (PDA), a pager, a wireless phone, a desktop computer, a laptop computer, an in-vehicle infotainment (IVI), an in-vehicle entertainment (ICE) device, an instrument panel (IC), a heads-up display (HUD) device, an in-vehicle diagnostics (OBD) device, a dashboard mobile Device (DME), a Mobile Data Terminal (MDT), an Electronic Engine Management System (EEMS), an electronic/Engine Control Unit (ECU), an electronic/Engine Control Module (ECM), an embedded system, a mobile computing device (MDT), a mobile computing system (EEMS), a mobile computing system (, Microcontrollers, control modules, Engine Management Systems (EMS), network or "smart" appliances, MTC devices, M2M, IoT devices, and the like.

In some embodiments, any of the UEs 501 may be 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 exchange data with MTC servers or devices via PLMN, ProSe, or D2D communications, sensor networks, or IoT networks using technologies such as M2M or MTC. The M2M or MTC data exchange may be a machine initiated data exchange. IoT networks describe interconnecting IoT UEs with short-term connections, which may include uniquely identifiable embedded computing devices (within the internet infrastructure). The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

The UE 501 may be configured to connect (e.g., communicatively couple) with the RAN 510. In an embodiment, RAN510 may be a NG RAN or a 5G RAN, an E-UTRAN, or a legacy RAN (e.g., UTRAN or GERAN). As used herein, the term "NG RAN" or the like may refer to the RAN510 operating in the NR or 5G system 500, while the term "E-UTRAN" or the like may refer to the RAN510 operating in the LTE or 4G system 500. The UE 501 utilizes connections (or channels) 503 and 504, respectively, each of which includes a physical communication interface or layer (discussed in further detail below).

In this example,

connections

503 and 504 are shown as implementing communicatively coupled air interfaces, and may conform to a cellular communication protocol, such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, an NR protocol, and/or any other communication protocol discussed herein. In an embodiment, the UE 501 may exchange communication data directly via the ProSe interface 505. The ProSe interface 505 may alternatively be referred to as SL interface 505 and may include one or more logical channels including, but not limited to, PSCCH, pscsch, PSDCH, and PSBCH.

The UE 501b is shown as being configured to access an AP 506 (also referred to as "WLAN node 506", "WLAN terminal 506", "WT 506", etc.) via a connection 507. Connection 507 may comprise a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, wherein AP 506 will include wireless fidelity

A router. In this example, the AP 506 is shown connected to the internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, the UE 501b, RAN510, and AP 506 may be configured to operate with LWA and/or LWIP. LWA operations may involve: UE 501b under RRC _ CONNECTED is configured by RAN nodes 511a-b to utilize radio resources of LTE and WLAN. LWIP operations may involve: the UE 501b uses WLAN radio resources (e.g., connection 507) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) sent over connection 507. The IPsec tunnel may include: the entire original IP packet is encapsulated and a new packet header is added, thereby protecting the original header of the IP packet.

The RAN510 may include one or more AN nodes or

RAN nodes

511a and 511b (collectively "RAN nodes 511") that implement the

connections

503 and 504. As used herein, the terms "access node," "access point," and the like may describe a device that provides 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 BSs, gnbs, RAN nodes, enbs, nodebs, RSUs, trxps, TRPs, or the like, and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the term "NG RAN node" or the like may refer to a RAN node 511 (e.g., a gNB) operating in the NR or 5G system 500, while the term "E-UTRAN node" or the like may refer to a RAN node 511 (e.g., an eNB) operating in the LTE or 4G system 500. According to various embodiments, the RAN node 511 may be implemented as a dedicated physical device (e.g., a macro cell base station) and/or one or more of a Low Power (LP) base station for providing a femto cell, pico cell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macro cell.

In some embodiments, all or part of the RAN nodes 511 may be implemented 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 and/or virtual baseband unit pool (vbbp). In these embodiments, the CRAN or vbbp may implement RAN functionality separation, for example: PDCP detach, wherein the RRC layer and PDCP layer are operated by the CRAN/vbbp, while other L2 protocol entities are operated by each RAN node 511; MAC/PHY separation, where RRC, PDCP, RLC and MAC layers are operated by the CRAN/vbbp, while PHY layers are operated by each RAN node 511; or "lower PHY" separation, where the upper parts of the RRC, PDCP, RLC, MAC and PHY layers are operated by the CRAN/vbbp, while the lower parts of the PHY layers are operated by the respective RAN nodes 511. The virtualization framework allows the processor core of the vacating RAN node 511 to execute other virtualized applications. In some implementations, a single RAN node 511 may represent each gNB-DU connected to a gNB-CU via each F1 interface (not shown in fig. 5). In these implementations, the gNB-DUs may include one or more remote radio heads or RFEMs (see, e.g., fig. 6), and the gNB-CUs may be operated by a server (not shown) located in the RAN510, or by a server pool in a similar manner as the CRAN/vbbp. Additionally or alternatively, one or more RAN nodes 511 may be next generation enbs (NG-enbs), which are RAN nodes providing E-UTRA user plane and control plane protocol terminations towards the UE 501, and are connected to a 5GC via an NG interface (discussed below).

In the V2X scenario, one or more RAN nodes 511 may be or act as RSUs. The term "road side unit" or "RSU" may refer to any traffic infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or a fixed (or relatively fixed) UE, wherein the RSU implemented in or by the UE may be referred to as a "UE-type RSU", the RSU implemented in or by the eNB may be referred to as an "eNB-type RSU", the RSU implemented in or by the gbb may be referred to as a "gbb-type RSU", and so on. In one example, the RSU is a computing device coupled with radio frequency circuitry located on the roadside providing connection support to passing vehicle UEs 501 (vues 501). The RSU may also include internal data storage circuitry for storing the geometry of the intersection map, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9GHz Dedicated Short Range Communications (DSRC) band to provide the extremely low latency communications required for high speed events (e.g., avoiding collisions, traffic warnings, etc.). Additionally or alternatively, the RSU may operate over the cellular V2X frequency band to provide the aforementioned low latency communication as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4GHz band) and/or provide a connection to one or more cellular networks to provide uplink and downlink communications. The computing device and some or all of the radio frequency circuitry of the RSU may be enclosed in a weatherproof 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 and/or a backhaul network.

Any of the RAN nodes 511 may terminate the air interface protocol and may be the first point of contact for the UE 501. In some embodiments, any of the RAN nodes 511 may perform various logical functions of the RAN510, including, but not limited to, functions of a Radio Network Controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In an embodiment, the UE 501 may be configured to: OFDM communication signals may be used to communicate with each other or any of RAN nodes 511 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communications) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

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

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

To operate in unlicensed spectrum, the UE 501 and the RAN node 511 may operate using LAA, eLAA, and/or feLAA mechanisms. In these implementations, UE 501 and RAN node 511 may perform one or more known medium sensing operations and/or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or occupied prior to transmitting 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 501, RAN node 511, etc.) may listen to a medium (e.g., a channel or carrier frequency) and transmit when it senses that the medium is idle (or when it senses that a particular channel in the medium is unoccupied). The medium sensing operation may include a CCA that utilizes at least the ED to determine whether there are other signals on the channel in order to determine whether the channel is occupied or clear. This LBT mechanism allows the cellular/LAA network to coexist with incumbent systems in unlicensed spectrum as well as other LAA networks. The ED may include: RF energy on the desired transmission band is sensed for a period of time and the sensed RF energy is compared to a predefined or configured threshold.

Generally, an incumbent system in the 5GHz band is a WLAN based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called CSMA/CA. Here, when a WLAN node (e.g., a Mobile Station (MS) (e.g., UE 501, AP 506, etc.)) intends to transmit, the WLAN node may first perform a CCA before transmitting. Furthermore, in case more than one WLAN node senses that the channel is idle and transmits at the same time, a back-off mechanism is used to avoid collisions. The back-off mechanism may be a counter drawn randomly within the CWS that increases exponentially when collisions occur and resets to a minimum value when a transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA/CA of WLAN. In some implementations, LBT procedures for DL or UL transmission bursts (including PDSCH or PUSCH transmissions), respectively, may have an LAA contention window, the length of which may vary between X and Y ECCA slots, where X and Y are the minimum and maximum values of CWS for LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μ β); however, the size of the CWS and MCOT (e.g., transmission bursts) may be based on government regulatory requirements.

The LAA mechanism builds on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is referred to as a CC. The CCs may have a bandwidth of 1.4, 3, 5, 10, 15, or 20MHz and may be capable of aggregating up to five CCs, and thus, the maximum aggregated bandwidth is 100 MHz. In an FDD system, the number of aggregated carriers may be different for DL and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, each CC may have a different bandwidth than other CCs. In a TDD system, the number of CCs and the bandwidth of each CC are typically the same for DL and UL.

The CA also includes respective serving cells to provide respective CCs. The coverage of the serving cell may be different because, for example, CCs on different frequency bands will experience different path losses. The primary serving cell or PCell may provide PCC for UL and DL and may handle RRC and NAS related activities. The other serving cells are referred to as scells, and each SCell may provide a separate SCC for UL and DL. SCCs may be added and removed as needed, while changing the PCC may require the UE 501 to switch. 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 a PCell operating in licensed spectrum. When the UE is configured with more than one LAA SCell, the UE may receive UL grants indicating different PUSCH starting positions within the same subframe on the configured LAA SCell.

The PDSCH carries user data and higher layer signaling to the UE 501. The PDCCH carries information on a transmission format and resource allocation, etc. related to the PDSCH channel. It may also inform the UE 501 of transport format, resource allocation and HARQ information related to the uplink shared channel. In general, downlink scheduling (assigning control channel resource blocks and shared channel resource blocks to UEs 501b within a cell) may be performed at any one of the RAN nodes 511 based on channel quality information fed back from any one of the UEs 501. The downlink resource assignment information may be sent on a PDCCH for (e.g., assigned to) each UE 501.

The PDCCH transmits control information using CCEs. The PDCCH complex-valued symbols may first be organized into quadruplets before being mapped to resource elements, and they 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 REGs. Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. Depending on the size of the DCI and the channel conditions, the PDCCH may be transmitted using one or more CCEs. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L ═ 1, 2, 4, or 8).

Some embodiments may use the concept as an extension of the above concept for resource allocation of control channel information. For example, some embodiments may utilize EPDCCH, which uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similar to the above, each ECCE may correspond to nine sets of four physical resource elements called EREGs. In some cases, ECCE may have other numbers of EREGs.

RAN nodes 511 may be configured to communicate with each other via an interface 512. In embodiments where system 500 is an LTE system (e.g., when CN 520 is an EPC), interface 512 may be an X2 interface 512. An X2 interface may be defined between two or more RAN nodes 511 (e.g., two or more enbs, etc.) connected to EPC 520 and/or between two enbs connected to EPC 520. The X2 interfaces 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 the transmission of user data between enbs. For example, X2-U may provide: specific sequence number information for user data transmitted from the MeNB to the SeNB; information on successful in-order delivery of PDCP PDUs from the SeNB to the UE 501 for user data; information of PDCP PDUs that have not been transmitted to the UE 501; information on a current minimum expected buffer size at the SeNB for transmitting user data to the UE; and the like. X2-C may provide intra-LTE access mobility functions including context transfer from source eNB to target eNB, user plane transport control, etc.; a load management function; and an inter-cell interference coordination function.

In embodiments where system 500 is a 5G or NR system (e.g., when CN 520 is a5 GC), interface 512 may be an Xn interface 512. An Xn interface is defined between two or more RAN nodes 511 (e.g., two or more enbs) connected to the 5GC 520, between a RAN node 511 (e.g., a gNB) connected to the 5GC 520 and an eNB, and/or between two enbs connected to the 5GC 520. In some implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functionality. The Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for a UE 501 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality for managing CONNECTED mode UE mobility between one or more RAN nodes 511. Mobility support may include context transfer from the old (source) serving RAN node 511 to the new (target) serving RAN node 511; and control of user plane tunnels between the old (source) serving RAN node 511 and the new (target) serving RAN node 511. The protocol stack of the Xn-U may include a transport network layer built on top of an Internet Protocol (IP) transport layer, and a GTP-U layer for carrying user plane PDUs above the UDP and/or IP layers. 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 over SCTP. SCTP can be located above the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, signaling PDUs are transmitted using point-to-point transmission. 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 and/or control plane protocol stacks shown and described herein.

RAN510 is shown communicatively coupled to a core network, in this embodiment Core Network (CN) 520. CN 520 may include a plurality of network elements 522 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UE 501) connected to CN 520 via RAN 510. The components of CN 520 may be implemented in one physical node, or in separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be utilized to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). The logical instantiation of CN 520 may be referred to as a network slice, and the logical instantiation of a portion of CN 520 may be referred to as a network subslice. The NFV architecture and infrastructure may be used to virtualize one or more network functions (alternatively performed by proprietary hardware) onto physical resources that contain a combination of industry standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components/functions.

In general, the application server 530 may be an element that provides applications (e.g., UMTS PS domain, LTE PS data services, etc.) that use IP bearer resources to the core network. Application server 530 may also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE 501 via EPC 520.

In an embodiment, CN 520 may be a 5GC (referred to as "5 GC 520", etc.), and RAN510 may be connected with CN 520 via NG interface 513. In an embodiment, NG interface 513 may be split into two parts: a NG user plane (NG-U) interface 514, which carries traffic data between RAN node 511 and the UPF; and an S1 control plane (NG-C) interface 515, which is a signaling interface between the RAN node 511 and the AMF.

In an embodiment, CN 520 may be a 5G CN (referred to as "5 GC 520", etc.), while in other embodiments, CN 520 may be an EPC. In the case where CN 520 is an EPC (referred to as "EPC 520", etc.), RAN510 may be connected with CN 520 via S1 interface 513. In an embodiment, the S1 interface 513 may be split into two parts: an S1 user plane (S1-U) interface 514, which carries traffic data between the RAN node 511 and the S-GW; and S1-MME interface 515, which is a signaling interface between RAN node 511 and the MME.

Fig. 6 illustrates an example of an infrastructure device 600 according to various embodiments. Infrastructure device 600 (or "system 600") may be implemented as a base, radio head, RAN node (e.g., RAN node 511 and/or AP 506 shown and described previously), application server 530, and/or any other element/device discussed herein. In other examples, system 600 may be implemented in or by a UE.

The system 600 includes an application circuit 605, a baseband circuit 610, one or more Radio Front End Modules (RFEM)615, a memory circuit 620, a Power Management Integrated Circuit (PMIC)625, a power source circuit 630, a network controller circuit 635, a network interface connector 640, a satellite positioning circuit 645, and a user interface 650. In some embodiments, device 600 may include additional elements, such as memory/storage, a display, a camera, sensors, or input/output (I/O) interfaces. In other embodiments, the components described below may be included in more than one device. For example, for a CRAN, vbub, or other similar implementation, the circuitry may be included separately in more than one device.

The application circuit 605 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of a low dropout regulator (LDO), an interrupt controller, a serial interface (e.g., SPI, I2C, or a universal programmable serial interface module), a real-time clock (RTC), a timer-counter (including interval timers and watchdog timers), a universal input/output (I/O or IO), a memory card controller (e.g., a Secure Digital (SD) multimedia card (MMC), etc.), a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. The processor (or core) of the application circuit 605 may be coupled with or may include memory/storage elements and may be configured to: instructions stored in the memory/storage are executed to enable various applications or operating systems to run on system 600. In some implementations, the memory/storage elements may be on-chip memory circuits that may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid state memory, and/or any other type of memory device technology (such as those discussed herein).

The processors of application circuit 605 may include, for example, one or more processor Cores (CPUs), one or more application processors, one or more Graphics Processing Units (GPUs), one or more Reduced Instruction Set Computing (RISC) processors, one or more Acorn RISC Machine (ARM) processors, one or more Complex Instruction Set Computing (CISC) processors, one or more Digital Signal Processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, the application circuit 605 may include or may be a dedicated processor/controller that operates in accordance with various embodiments herein. As an example, the processor of the application circuit 605 may include one or more Intels

Or

A processor; advanced Micro Devices (AMD)

A processor; accelerated Processing Unit (APU) or

A processor; ARM-based processors that have been licensed by ARM Holdings, Ltd., such as the ARM Cortex-A family of processors and the processor provided by Cavium (TM), Inc

MIPS-based designs from MIPS Technologies, inc, such as MIPS Warrior class P processors; and the like. In some embodiments, the system 600 may not utilize the application circuit 605 and instead may include a dedicated processor/controller to process IP data received, for example, from the EPC or 5 GC.

In some implementations, the application circuit 605 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, Computer Vision (CV) and/or Deep Learning (DL) accelerators. By way of example, the programmable processing device may be one or more Field Programmable Devices (FPDs), such as Field Programmable Gate Arrays (FPGAs), or the like; programmable Logic Devices (PLDs), such as complex PLDs (cplds), large capacity PLDs (hcplds), and the like; ASICs, such as structured ASICs and the like; programmable soc (psoc); and the like. In such implementations, the circuitry of the application circuitry 605 may include logic blocks or logic constructs and other interconnected resources that may be programmed to perform various functions, such as the processes, methods, functions, etc., of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuit 605 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, static memory (e.g., Static Random Access Memory (SRAM), antifuse, etc.) for storing logic blocks, logic constructs, data, and so forth in a look-up table (LUT) or the like).

Baseband circuit 610 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. Various hardware electronic components of the baseband circuitry 610 are discussed below with reference to fig. 8.

The user interface circuitry 650 may include one or more interfaces designed to enable a user to interact with the system 600 or peripheral component interfaces designed to enable peripheral components to interact with the system 600. 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 (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, 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. The peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a Universal Serial Bus (USB) port, an audio jack, a power interface, and the like.

The Radio Front End Module (RFEM)615 may include a millimeter wave (mmWave) RFEM and one or more sub-mmWave Radio Frequency Integrated Circuits (RFICs). In some implementations, one or more sub-mmWave RFICs may be physically separated from the mmWave RFEM. RFICs may include connections to one or more antennas or antenna arrays (see, e.g., antenna array 811 of fig. 8 below), and RFEMs may be connected to multiple antennas. In an alternative implementation, both mmWave and sub-mmWave radio functions may be implemented in the same physical RFEM615, the physical RFEM615 containing both mmWave and sub-mmWave antennas.

The memory circuit 620 may include one or more of the following: volatile memory including Dynamic Random Access Memory (DRAM) and/or Synchronous Dynamic Random Access Memory (SDRAM); and non-volatile memory (NVM), including high speed electrically erasable memory (often referred to as "Flash memory"), phase change random access memory (PRAM), Magnetoresistive Random Access Memory (MRAM), etc., and may include

And

a three-dimensional (3D) cross point (XPOINT) memory. Memory circuit 620 may be implemented as one or more of a solder-in package integrated circuit, a socket memory module, and a plug-in memory card.

PMIC 625 may include a voltage regulator, a surge protector, power alarm detection circuitry, and one or more backup power sources (e.g., batteries or capacitors). The power alarm detection circuit may detect one or more of power down (under-voltage) and surge (over-voltage) conditions. Power source circuitry 630 may provide power drawn from a network cable to provide both power and data connections to infrastructure device 600 using a single cable.

Network controller circuit 635 may provide connectivity to a network using a standard network interface protocol (e.g., ethernet over GRE tunnels, ethernet over multiprotocol label switching (MPLS), or some other suitable protocol). The network connection may be provided to/from the infrastructure device 600 via the network interface connector 640 using a physical connection, which may be electrical (commonly referred to as a "copper interconnect"), optical, or wireless. Network controller circuit 635 may include one or more special purpose processors and/or FPGAs to communicate using one or more of the above-described protocols. In some implementations, the network controller circuit 635 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

The positioning circuitry 645 includes circuitry for receiving and decoding signals transmitted/broadcast by a positioning network of a Global Navigation Satellite System (GNSS). Examples of navigation satellite constellations (or GNSS) include the Global Positioning System (GPS) in the united states, the global navigation system in russia (GLONASS), the galileo system in the european union, the beidou navigation satellite system in china, the regional navigation system or GNSS augmentation system (e.g., indian constellation Navigation (NAVIC), the quasi-zenith satellite system in japan (QZSS), the doppler orbit imaging in france, and the satellite integrated radio positioning (DORIS), etc.), and so forth. The positioning circuitry 645 includes various hardware elements (e.g., including hardware devices for facilitating OTA communication, such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of a positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuitry 645 may include a Micro-technology (Micro-PNT) IC for positioning, navigation, and timing that performs position tracking/estimation using a master timing clock without GNSS assistance. The positioning circuitry 645 may also be part of the baseband circuitry 610 and/or the RFEM615 or interact with the baseband circuitry 610 and/or the RFEM615 to communicate with nodes and components of the positioning network. The positioning circuitry 645 may also provide location data and/or time data to the application circuitry 605, which the application circuitry 605 may use to operate in synchronization with various infrastructure (e.g., RAN node 511, etc.).

The components shown in fig. 6 may communicate with each other using interface circuitry that may include any number of bus and/or Interconnect (IX) technologies such as Industry Standard Architecture (ISA), extended ISA (eisa), Peripheral Component Interconnect (PCI), peripheral component interconnect extended (PCI x), PCI Express (PCIe), or any number of other technologies. The bus/IX may be a proprietary bus, such as used in SoC-based systems. Other bus/IX systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, a power bus, and the like.

Fig. 7 illustrates an example of a platform 700 (or "device 700") according to various embodiments. In embodiments, computer platform 700 may be suitable for use as UE 501, application server 530, and/or any other element/device discussed herein. The platform 700 may include any combination of the components shown in the examples. The components of platform 700 may be implemented as Integrated Circuits (ICs), portions thereof, discrete electronic or other modules, logic, hardware, software, firmware, or combinations thereof, as appropriate in computer platform 700, or as components incorporated within the chassis of a larger system. The block diagram of FIG. 7 is intended to illustrate a high-level view of the components of computer platform 700. However, some of the components shown may be omitted, additional components may be present, and a different arrangement of the components shown may occur in other implementations.

Application circuitry 705 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of LDOs, interrupt controllers, serial interfaces (e.g., SPI, I2C, or a universal programmable serial interface module), RTC, timer-counters (including interval timers and watchdog timers), universal I/O, memory card controllers (e.g., SD MMC, etc.), USB interfaces, MIPI interfaces, and JTAG test access ports. The processor (or core) of the application circuitry 705 may be coupled with or may include memory/storage elements and may be configured to: instructions stored in the memory/storage are executed to enable various applications or operating systems to run on system 700. In some implementations, the memory/storage elements may be on-chip memory circuits that may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid state memory, and/or any other type of memory device technology (e.g., those discussed herein).

The processors of application circuit 605 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, multi-threaded processors, ultra-low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof. In some embodiments, the application circuit 605 may include or may be a dedicated processor/controller that operates in accordance with various embodiments herein.

As an example, the processor of the application circuit 705 may include a microprocessor based microprocessor

Architecture Core^TMProcessors of, e.g. Quark^TM、Atom^TMI3, i5, i7 or another MCU-like processor, or may be from Santa Clara

Corporation. The processor of the application circuit 705 may also be one or more of the following: advanced Micro Devices (AMD)

A processor or an Accelerated Processing Unit (APU);

an a5-a9 processor, inc;

snapdagon of Technologies, Inc^TMA processor; the number of Texas Instruments was,

open Multimedia Application Platform (OMAP)^TMA processor; MIPS-based designs of MIPS Technologies, Inc., such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, ltd, for exampleARM Cortex-A, Cortex-R and Cortex-M series processors; and the like. In some implementations, the application circuit 705 may be part of a system on a chip (SoC) in which the application circuit 705 and other components are formed as a single integrated circuit or a single package, e.g.

Edison from Corporation^TMOr Galileo^TMAnd (6) an SoC board.

Additionally or alternatively, the application circuitry 705 may include circuitry such as, but not limited to, one or more Field Programmable Devices (FPDs), such as FPGAs, etc.; programmable Logic Devices (PLDs), such as complex PLDs (cplds), large capacity PLDs (hcplds), and the like; ASICs, such as structured ASICs and the like; programmable soc (psoc); and the like. In such embodiments, the circuitry of the application circuitry 705 may include logic blocks or logic constructs and other interconnected resources that may be programmed to perform various functions, such as the processes, methods, functions, etc., of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuit 705 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, static memory (e.g., Static Random Access Memory (SRAM), antifuse, etc.) for storing logic blocks, logic constructs, data, and so forth in a look-up table (LUT) or the like.

Baseband circuitry 710 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. The various hardware electronics of baseband circuitry 710 are discussed below with respect to fig. 8.

The RFEM715 may include a millimeter wave (mmWave) RFEM and one or more sub-mmWave Radio Frequency Integrated Circuits (RFICs). In some implementations, one or more sub-mmWave RFICs may be physically separated from the mmWave RFEM. RFICs may include connections to one or more antennas or antenna arrays (see, e.g., antenna array 811 of fig. 8 below), and RFEMs may be connected to multiple antennas. In an alternative implementation, both mmWave and sub-mmWave radio functions may be implemented in the same physical RFEM715 that contains both mmWave and sub-mmWave antennas.

Memory circuit 720 may include any number and type of memory devices for providing a given amount of system memory. As an example, memory circuit 720 may include one or more of the following: volatile memory including Random Access Memory (RAM), Dynamic RAM (DRAM), and/or Synchronous Dynamic RAM (SDRAM); and non-volatile memory (NVM), including high speed electrically erasable memory (often referred to as Flash memory), phase change random access memory (PRAM), Magnetoresistive Random Access Memory (MRAM), and the like. The memory circuit 720 may be developed according to the Joint Electron Device Engineering Commission (JEDEC) design based on Low Power Double Data Rate (LPDDR), such as LPDDR2, LPDDR3, LPDDR4, and the like. The memory circuit 720 may be implemented as one or more of the following: a solder-in package integrated circuit, a Single Die Package (SDP), a Dual Die Package (DDP), or a quad die package (Q17P), a socket memory module, a dual in-line memory module (DIMM) (including micro DIMM or MiniDIMM), and/or soldered to a motherboard via a Ball Grid Array (BGA). In a low power implementation, memory circuit 720 may be an on-die memory or register associated with application circuit 705. To provide for persistent storage of information (e.g., data, applications, operating systems, etc.), the memory circuit 720 may include one or more mass storage devices, which may include, among other things, a Solid State Disk Drive (SSDD), a Hard Disk Drive (HDD), a miniature HDD, a resistive memory, a phase change memory, a holographic memory, or a chemical memory. For example, computer platform 700 may include a computer program from

And

a three-dimensional (3D) cross point (XPOINT) memory.

Removable memory circuit 723 may comprise a device, circuit, enclosure/housing, port or receptacle, etc. for coupling a portable data storage device with platform 700. These portable data storage devices may be used for mass storage purposes and may include, for example, Flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD graphics cards, etc.) as well as USB Flash drives, optical disks, external HDDs, and the like.

Platform 700 may also include interface circuitry (not shown) for interfacing external devices with platform 700. External devices connected to platform 700 via interface circuits include sensor circuits 721 and electromechanical components (EMC)722, as well as removable memory devices coupled to removable memory circuit 723.

The sensor circuit 721 includes a device, module or subsystem whose purpose is to detect events or changes in its environment and to send information (sensor data) about the detected events to other devices, modules, subsystems, etc. Examples of such sensors include, among others: an Inertial Measurement Unit (IMU) comprising an accelerometer, a gyroscope, and/or a magnetometer; a micro-electromechanical system (MEMS) or a nano-electromechanical system (NEMS) comprising a 3-axis accelerometer, a 3-axis gyroscope, and/or a magnetometer; a liquid level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; an air pressure sensor; a gravimeter; an altimeter; an image capture device (e.g., a camera or a lens-less aperture); a light detection and ranging (LiDAR) sensor; a proximity sensor (e.g., an infrared radiation detector, etc.), a depth sensor, an ambient light sensor, an ultrasound transceiver; a microphone or other similar audio capture device; and the like.

EMC 722 includes devices, modules, or subsystems whose purpose is to enable platform 700 to change its state, position, and/or orientation, or to move or control a mechanism or (sub) system. Further, EMC 722 may be configured to: messages/signaling are generated and sent to other components of the platform 700 to indicate the current state of the EMC 722. Examples of EMCs 722 include one or more power switches, relays (including electromechanical relays (EMRs) and/or Solid State Relays (SSRs)), actuators (e.g., valve actuators, etc.), sound generators, visual alert devices, motors (e.g., DC motors, stepper motors, etc.), wheels, propellers, claws, clamps, hooks, and/or other similar electromechanical components. In an embodiment, platform 700 is configured to: the one or more EMCs 722 are operated based on one or more captured events and/or instructions or control signals received from the service provider and/or various clients.

In some implementations, interface circuitry may connect platform 700 with positioning circuitry 745. The positioning circuitry 745 includes circuitry for receiving and decoding signals transmitted/broadcast by the positioning network of the GNSS. Examples of navigation satellite constellations (or GNSS) include GPS in the united states, GLONASS in russia, galileo system in the european union, beidou navigation satellite system in china, regional navigation system or GNSS augmentation system (e.g., NAVIC), QZSS in japan, DORIS in france, etc. The positioning circuit 745 includes various hardware elements (e.g., including hardware devices for facilitating OTA communication, such as switches, filters, amplifiers, antenna elements) to communicate with components of a positioning network (e.g., navigation satellite constellation nodes). In some embodiments, the positioning circuitry 745 may comprise a Micro-PNT IC that uses a master timing clock to perform position tracking/estimation without GNSS assistance. The positioning circuitry 745 may also be part of, or interact with, the baseband circuitry 610 and/or the RFEM715 to communicate with nodes and components of the positioning network. The positioning circuitry 745 may also provide location data and/or time data to the application circuitry 705, which the application circuitry 705 may use to operate in synchronization with various infrastructure (e.g., radio base stations) for route planning navigation applications, and the like.

In some implementations, interface circuitry may connect platform 700 with Near Field Communication (NFC) circuitry 740. NFC circuitry 740 is configured to: contactless short-range communication is provided based on Radio Frequency Identification (RFID) standards, where magnetic field induction is used to enable communication between NFC circuitry 740 and NFC-enabled devices external to platform 700 (e.g., "NFC contacts"). NFC circuitry 740 includes an NFC controller coupled with the antenna element and a processor coupled with the NFC controller. The NFC controller may be a chip/IC that provides NFC functionality to NFC circuitry 740 by executing NFC controller firmware and an NFC stack. The NFC stack may be executable by the processor to control the NFC controller, and the NFC controller firmware may be executable by the NFC controller to control the antenna element to transmit the short-range RF signal. The RF signal may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to send stored data to NFC circuit 740, or initiate a data transfer between NFC circuit 740 and another active NFC device (e.g., a smartphone or NFC-enabled POS terminal) in the vicinity of platform 700.

Driver circuit 746 may include software and hardware elements that operate to control specific devices embedded in platform 700, attached to platform 700, or communicatively coupled with platform 700. Driver circuit 746 may include drivers to allow other components of platform 700 to interact with or control various input/output (I/O) devices that may be present within platform 700 or connected to platform 700. For example, driver circuit 746 may include a display driver for controlling and allowing access to a display device, a touch screen driver for controlling and allowing access to a touch screen interface of platform 700, a sensor driver for obtaining sensor readings of sensor circuit 721 and controlling and allowing access to sensor circuit 721, an EMC driver for obtaining EMC actuator positions 722 and/or controlling and allowing access to EMC 722, a camera driver for controlling and allowing access to an embedded image capture device, an audio driver for controlling and allowing access to one or more audio devices.

A Power Management Integrated Circuit (PMIC)725 (also referred to as "power management circuit 725") may manage power provided to various components of platform 700. In particular, with respect to the baseband circuitry 710, the PMIC 725 may control power supply selection, voltage scaling, battery charging, or DC-DC conversion. The PMIC 725 may often be included when the platform 700 is capable of being powered by the battery 730 (e.g., when the device is included in the UE 501).

In some embodiments, PMIC 725 may control, or be part of, various power saving mechanisms of platform 700. For example, if platform 700 is in an RRC _ Connected state (where it is still Connected to the RAN node because it is expected to receive traffic soon), it may enter a state referred to as discontinuous reception mode (DRX) after a period of inactivity. During this state, platform 700 may be powered down for short time intervals, thereby saving power. If there is no data traffic activity for an extended period of time, platform 700 may transition to the RRC Idle state (where it is disconnected from the network and no operations such as channel quality feedback, handover, etc. are performed). Platform 700 enters a very low power state and it performs paging, where it again periodically wakes up to listen to the network and then powers down again. In this state, platform 700 may not receive data; in order to receive data, it must transition back to the RRC _ Connected state. Additional power-save modes may make the device unavailable to the network for periods longer than the paging interval (ranging from seconds to hours). During this time, the device is completely unreachable to the network and may be completely powered down. Any data sent during this time causes a large delay and it is assumed that the delay is acceptable.

The battery 730 may provide power to the platform 700, although in some examples, the platform 700 may be installed deployed in a fixed location and may have a power source coupled to a power grid. Battery 730 may be a lithium ion battery, a metal-air battery (e.g., zinc-air battery, aluminum-air battery, lithium-air battery), or the like. In some implementations, such as in a V2X application, battery 730 may be a typical lead-acid automotive battery.

In some implementations, the battery 730 may be a "smart battery" that includes or is coupled to a Battery Management System (BMS) or battery monitoring integrated circuit. A BMS may be included in the platform 700 to track the state of charge (SoCh) of the battery 730. The BMS may be used to monitor other parameters of the battery 730 to provide fault predictions, such as the state of health (SoH) and the functional state (SoF) of the battery 730. The BMS may communicate information of the battery 730 to the application circuit 705 or other components of the platform 700. The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit 705 to directly monitor the voltage of the battery 730 or the current from the battery 730. The battery parameters may be used to determine actions that platform 700 may perform, such as transmission frequencies, network operations, listening frequencies, and the like.

A power block or other power source coupled to the grid may be coupled with the BMS to charge the battery 730. In some examples, the power block may be replaced with a wireless power receiver, for example, by a loop antenna in computer platform 700 to obtain power wirelessly. In these examples, a wireless battery charging circuit may be included in the BMS. The particular charging circuit selected may depend on the size of the battery 730, and thus the current required. The charging may be performed using the Airfuel standard promulgated by Airfuel Alliance, the Qi Wireless charging standard promulgated by Wireless Power Consortium, or the Rezence charging standard promulgated by Alliance for Wireless Power, or the like.

User interface circuitry 750 includes various input/output (I/O) devices present within platform 700 or connected to platform 700, and includes one or more user interfaces designed to enable a user to interact with platform 700 and/or peripheral component interfaces designed to enable peripheral components to interact with platform 700. The user interface circuit 750 includes an input device circuit and an output device circuit. The input device circuitry includes any physical or virtual means for accepting input, including, inter alia, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying information or communicating information (e.g., sensor readings, actuator position, or other similar information). Output device circuitry may include any number and/or combination of audio and/or visual displays, including, among other things, one or more simple visual outputs/indicators (e.g., binary status indicators (e.g., Light Emitting Diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touch screens (e.g., Liquid Crystal Displays (LCDs), LED displays, quantum dot displays, projectors, etc.), where output of characters, graphics, multimedia objects, etc., is generated or produced from operation of platform 700. Actuators providing haptic feedback, etc.). In another example, NFC circuitry (including an NFC controller coupled with the antenna element and the processing device) may be included to read the electronic tag and/or connect with another NFC enabled device. The peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, and the like.

Although not shown, the components of platform 700 may communicate with each other using suitable bus or Interconnect (IX) technology, which may include any number of technologies, including ISA, EISA, PCI x, PCIe, Time Triggered Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus/IX may be a proprietary bus/IX, such as used in SoC-based systems. Other bus/IX systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, a power bus, and the like.

Fig. 8 illustrates example components of a baseband circuit 810 and a Radio Front End Module (RFEM)815, in accordance with various embodiments. Baseband circuitry 810 corresponds to baseband circuitry 610 of fig. 6 and baseband circuitry 710 of fig. 7. The RFEM 815 corresponds to the RFEM615 of fig. 6 and the RFEM715 of fig. 7. As shown, the RFEM 815 may include Radio Frequency (RF) circuitry 806, Front End Module (FEM) circuitry 808, antenna array 811 coupled together at least as shown.

The baseband circuitry 810 includes circuitry and/or control logic configured to perform various radio/network protocols and radio control functions that enable communication with one or more radio networks via the RF circuitry 806. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 810 may include Fast Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 810 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments. The baseband circuitry 810 is configured to: processes baseband signals received from the receive signal path of RF circuitry 806 and generates baseband signals for the transmit signal path of RF circuitry 806. The baseband circuitry 810 is configured to: interface with application circuitry 605/705 (see fig. 6 and 7) for generating and processing baseband signals and controlling operation of the RF circuitry 806. The baseband circuitry 810 may handle various radio control functions.

The aforementioned circuitry and/or control logic of baseband circuitry 810 may include one or more single-core or multi-core processors. For example, the one or more processors may include a 3G baseband processor 804A, a 4G/LTE baseband processor 804B, a 5G/NR baseband processor 804C, or some other baseband processor 804D for other existing generations, generations in development or to be developed in the future (e.g., sixth generation (6G), etc.). In other embodiments, some or all of the functionality of the baseband processors 804A-D may be included in modules that are stored in the memory 804G and executed via a Central Processing Unit (CPU) 804E. In other embodiments, some or all of the functionality of the baseband processors 804A-D may be provided as hardware accelerators (e.g., FPGAs, ASICs, etc.) loaded with appropriate bit streams or logic blocks stored in respective memory units. In various embodiments, memory 804G may store program code for a real-time os (rtos) that, when executed by CPU 804E (or other baseband processor), causes CPU 804E (or other baseband processor) to manage resources, schedule tasks, etc. of baseband circuitry 810. Examples of RTOS may include:

embedded Operating System (OSE) provided^TM、

Provided nucleous RTOS^TMMultifunctional real-time actuator (VRTX) provided by Mentor Graphics,

Provided ThreadX^TM、

Provided with FreeRTOS, REX OS, Open Kernel (OK)

OKL4 provided or any other suitable RTOS, such as those discussed herein. In addition, the baseband circuitry 810 includes one or more audio Digital Signal Processors (DSPs) 804F. The audio DSP 804F includes elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments.

In some embodiments, each processor 804A-804E includes a respective memory interface for transmitting data to and receiving data from memory 804G. Baseband circuitry 810 may further include one or more interfaces communicatively coupled to other circuitry/devices, such as an interface for sending/receiving data to/from memory external to baseband circuitry 810; an application circuit interface for sending/receiving data to/from the application circuit 605/705 of fig. 6-8; an RF circuit interface for transmitting/receiving data to/from the RF circuit 806 of fig. 8; for transmitting data to and from one or more wireless hardware elements (e.g., Near Field Communication (NFC) components,

Low power consumption

A component,

Component, etc.) a wireless hardware connection interface to send/receive data; and a power management interface for transmitting/receiving power signals or control signals to/from the PMIC 725.

In an alternative embodiment (which may be combined with the embodiments described above), the baseband circuitry 810 includes one or more digital baseband systems coupled to each other via an interconnection subsystem and to the CPU subsystem, the audio subsystem, and the interface subsystem. The digital baseband subsystem may also be coupled to the digital baseband interface and the mixed signal baseband subsystem via another interconnection subsystem. Each interconnect subsystem may include a bus system, a point-to-point connection, a Network On Chip (NOC) fabric, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include DSP circuitry, buffer memory, program memory, speech processing accelerator circuitry, data converter circuitry (e.g., analog-to-digital and digital-to-analog converter circuitry), analog circuitry including one or more of amplifiers and filters, and/or other similar components. In an aspect of the disclosure, the baseband circuitry 810 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functionality for digital baseband circuitry and/or radio frequency circuitry (e.g., radio front end module 815).

Although not shown in fig. 8, in some embodiments, baseband circuitry 810 includes processing devices (e.g., "multi-protocol baseband processors" or "protocol processing circuits") for operating one or more wireless communication protocols and processing devices for implementing PHY layer functionality. In these embodiments, the PHY layer functions include the aforementioned radio control functions. In these embodiments, the protocol processing circuitry operates or implements various protocol layers/entities of one or more wireless communication protocols. In a first example, when baseband circuitry 810 and/or RF circuitry 806 are part of mmWave communication circuitry or some other suitable cellular communication circuitry, protocol processing circuitry may operate LTE protocol entities and/or 5G/NR protocol entities. In this first example, the protocol processing circuitry will operate MAC, RLC, PDCP, SDAP, RRC and NAS functionality. In a second example, when baseband circuitry 810 and/or RF circuitry 806 are part of a Wi-Fi communication system, protocol processing circuitry may operate one or more IEEE-based protocols. In this second example, the protocol processing circuitry will operate Wi-Fi MAC and Logical Link Control (LLC) functions. The protocol processing circuit may include: one or more memory structures (e.g., 804G) for storing program code and data for operating protocol functions; and one or more processing cores for executing program code and performing various operations using the data. The baseband circuitry 810 may also support radio communications for more than one wireless protocol.

The various hardware elements of baseband circuitry 810 discussed herein may be implemented as, for example, a solder-in substrate including one or more Integrated Circuits (ICs), a single package IC soldered to a main circuit board, or a multi-chip module containing two or more ICs. In one example, the components of baseband circuitry 810 may be suitably combined in a single chip or chip set, or arranged on the same circuit board. In another example, some or all of the constituent components of baseband circuitry 810 and RF circuitry 806 may be implemented together, for example, on a system on a chip (SoC) or a System In Package (SiP). In another example, some or all of the constituent components of baseband circuitry 810 may be implemented as a separate SoC that is communicatively coupled with RF circuitry 806 (or multiple instances of RF circuitry 806). In yet another example, some or all of the constituent components of baseband circuitry 810 and application circuitry 605/705 may be implemented together as individual socs mounted to the same circuit board (e.g., "multi-chip packages").

In some embodiments, baseband circuitry 810 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 810 may support communication with an E-UTRAN or other WMANs, WLANs, WPANs. Embodiments in which the baseband circuitry 810 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

The RF circuitry 806 may enable communication with a wireless network through a non-solid medium using modulated electromagnetic radiation. In various embodiments, the RF circuitry 806 may include switches, filters, amplifiers, and the like to facilitate communication with the wireless network. RF circuitry 806 may include a receive signal path that may include circuitry to down-convert RF signals received from FEM circuitry 808 and provide baseband signals to baseband circuitry 810. RF circuitry 806 may also include a transmit signal path that may include circuitry to upconvert baseband signals provided by baseband circuitry 810 and provide an RF output signal to FEM circuitry 808 for transmission.

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

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

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

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

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

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

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

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by the baseband circuitry 810 or the application circuitry 605/705 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application circuit 605/705.

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

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

FEM circuitry 808 may include a receive signal path, which may include circuitry configured to operate on RF signals received from antenna array 811, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 806 for further processing. FEM circuitry 808 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by RF circuitry 806 for transmission by one or more antenna elements of antenna array 811. In various embodiments, amplification by the transmit signal path or the receive signal path may be done in only RF circuitry 806, only FEM circuitry 808, or both RF circuitry 806 and FEM circuitry 808.

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

Antenna array 811 includes one or more antenna elements, each configured to: converts an electric signal into a radio wave to propagate in the air, and converts a received radio wave into an electric signal. For example, digital baseband signals provided by baseband circuitry 810 are converted to analog RF signals (e.g., modulation waveforms) that are amplified and transmitted via antenna elements of antenna array 811 comprising one or more antenna elements (not shown). The antenna elements may be omnidirectional, directional, or a combination thereof. The antenna elements may be formed in a variety of arrangements as is known and/or discussed herein. Antenna array 811 may include microstrip antennas or printed antennas fabricated on the surface of one or more printed circuit boards. The antenna array 811 may be formed as a metal foil (e.g., patch antenna) of various shapes and may be coupled with the RF circuitry 806 and/or the FEM circuitry 808 using metal transmission lines or the like.

The processor of the application circuitry 605/705 and the processor of the baseband circuitry 810 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of the baseband circuitry 810 may be used, alone or in combination, to perform layer 3, layer 2, or layer 1 functions, while the processor of the application circuitry 605/705 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., TCP layer and UDP layer). As referred to herein, layer 3 may include an RRC layer, described in further detail below. As referred to herein, the layer 2 may include a MAC layer, an RLC layer, and a PDCP layer, described in further detail below. As referred to herein, layer 1 may include the PHY layer of the UE/RAN node, described in further detail below.

Fig. 9 illustrates various protocol functions that may be implemented in a wireless communication device, in accordance with various embodiments. In particular, fig. 9 includes an arrangement 900 that illustrates interconnections between various protocol layers/entities. The following description of fig. 9 is provided with respect to various protocol layers/entities operating in conjunction with the 5G/NR system standard and the LTE system standard, although some or all aspects of fig. 9 may also be applicable to other wireless communication network systems.

The protocol layers of arrangement 900 may include one or more of PHY 910, MAC 920, RLC 930, PDCP 940, SDAP 947, RRC 955, and NAS 957, as well as other higher layer functions not shown. The protocol layers may include one or more serving access points (e.g.,

items

959, 956, 950, 949, 945, 935, 925, and 915 in fig. 9), which may provide communication between two or more protocol layers.

PHY 910 may transmit and receive physical layer signals 905, and physical layer signals 905 may be received from or transmitted to one or more other communication devices. Physical layer signal 905 may include one or more physical channels, such as those discussed herein. PHY 910 may also perform link Adaptive Modulation and Coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers (e.g., RRC 955). PHY 910 may also perform error detection for transport channels, Forward Error Correction (FEC) encoding/decoding for transport channels, modulation/demodulation for physical channels, interleaving, rate matching, mapping to physical channels, and MIMO antenna processing. In an embodiment, an instance of PHY 910 may process requests from an instance of MAC 920 via one or more PHY-SAPs 915 and provide indications thereto via one or more PHY-SAPs 915. The requests and instructions communicated via the PHY-SAP 915 may include one or more transport channels, according to some embodiments.

An instance of the MAC 920 may process requests from an instance of the RLC 930 via one or more MAC-SAPs 925 and provide indications thereto via one or more MAC-SAPs 925. These requests and indications communicated via the MAC-SAP 925 may include one or more logical channels. MAC 920 may perform mapping between logical channels and transport channels, multiplexing MAC SDUs from one or more logical channels onto TBs to be transmitted to PHY 910 via transport channels, demultiplexing MAC SDUs from TBs transmitted from PHY 910 via transport channels onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction by HARQ, and logical channel prioritization.

The instance of the RLC 930 may process requests from the instance of the PDCP 940 via one or more radio link control service access points (RLC-SAPs) 935 and provide indications thereto via one or more radio link control service access points (RLC-SAPs) 935. These requests and indications communicated via the RLC-SAP 935 may include one or more RLC channels. RLC 930 may operate in a variety of operating modes, including: transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC 930 may perform the transfer of upper layer Protocol Data Units (PDUs), error correction by automatic repeat request (ARQ) (for AM data transfer), and concatenation, segmentation and reassembly of RLC SDUs (for UM and AM data transfer). RLC 930 may also perform re-segmentation of RLC data PDUs (for AM data transfer), re-ordering RLC data PDUs (for UM and AM data transfer), detecting duplicate data (for UM and AM data transfer), discarding RLC SDUs (for UM and AM data transfer), detecting protocol errors (for AM data transfer), and performing RLC re-establishment.

Instances of the PDCP 940 may process requests from instances of the RRC 955 and/or instances of the SDAP 947 via one or more packet data convergence protocol service access points (PDCP-SAP)945 and provide indications thereto via the one or more packet data convergence protocol service access points (PDCP-SAP) 945. These requests and indications communicated via the PDCP-SAP 945 may include one or more radio bearers. PDCP 940 may perform header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-order delivery of upper layer PDUs when lower layers are re-established, eliminate duplication of lower layer SDUs for radio bearers mapped onto RLC AM when lower layers are re-established, cipher and decipher control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discard, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

Instances of the SDAP 947 may process requests from one or more higher layer protocol entities via one or more SDAP-SAPs 949 and provide indications thereto via one or more SDAP-SAPs 949. These requests and indications communicated via the SDAP-SAP 949 may include one or more QoS flows. The SDAP 947 may map QoS flows to DRBs and vice versa and may also mark QFIs in DL and UL packets. A single SDAP entity 947 may be configured for a single PDU session. In the UL direction, the NG-RAN 510 can control the mapping of QoS flows to DRBs in two different ways, i.e. reflection mapping or explicit mapping. For reflective mapping, the SDAP 947 of the UE 501 may monitor the QFI of the DL packets of each DRB and may apply the same mapping to packets flowing in the UL direction. For a DRB, the SDAP 947 of the UE 501 may map UL packets belonging to a QoS flow corresponding to a PDU session and a QoS flow ID observed in DL packets of the DRB. To enable the reflection mapping, the NG-RAN may tag the DL packet on the Uu interface with the QoS flow ID. Explicit mapping may involve the RRC 955 configuring the SDAP 947 with an explicit QoS flow to DRB mapping rule, which the SDAP 947 may store and follow. In an embodiment, the SDAP 947 may be used only in NR implementations and may not be used in LTE implementations.

The RRC 955 may configure aspects of one or more protocol layers, which may include one or more instances of the PHY 910, MAC 920, RLC 930, PDCP 940, and SDAP 947, via one or more management service access points (M-SAPs). In an embodiment, an instance of RRC 955 may process requests from one or more NAS entities 957 via one or more RRC-SAPs 956 and provide indications thereto via one or more RRC-SAPs 956. The primary services and functions of RRC 955 may include broadcasting system information (e.g., included in MIB or SIB related NAS), broadcasting system information related to Access Stratum (AS), paging, establishing, maintaining, and releasing RRC connections between UE 501 and RAN510 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishing, configuring, maintaining, and releasing point-to-point radio bearers, security functions (including key management), inter-RAT mobility, and measurement configuration for UE measurement reporting. The MIB and SIBs may include one or more IEs, each of which may include a separate data field or data structure.

NAS 957 may form the highest layer of the control plane between UE 501 and the AMF. NAS 957 may support mobility and session management procedures for UE 501 to establish and maintain an IP connection between UE 501 and a P-GW in an LTE system.

According to various embodiments, one or more protocol entities of the arrangement 900 may be implemented in the UE 501, the RAN node 511, the MME in an AMF or LTE implementation in an NR implementation, the S-GW and the P-GW in a UPF or LTE implementation in an NR implementation, or the like to be used in a control plane or user plane communication protocol stack between the above mentioned devices. In such embodiments, one or more protocol entities that may be implemented in one or more of UE 501, gNB 511, AMF, etc. may communicate with a corresponding peer protocol entity that may be implemented in or on another device using the services of the corresponding lower layer protocol entity to perform such communication. In some embodiments, the gNB-CU of the gNB 511 may host RRC 955, SDAP 947, and PDCP 940 of the gNB that control operation of one or more gNB-DUs, and the gNB-DUs of the gNB 511 may each host RLC 930, MAC 920, and PHY 910 of the gNB 511.

In a first example, the control plane protocol stack may include NAS 957, RRC 955, PDCP 940, RLC 930, MAC 920 and PHY 910 in order from the highest layer to the lowest layer. In this example, upper layer 960 may be built on top of NAS 957 and include IP layer 961, SCTP 962, and application layer signaling protocol (AP) 963.

In NR implementations, the AP 963 may be a NG application protocol layer (NGAP or NG-AP)963 for the NG interface 513 defined between the NG-RAN node 511 and the AMF, or the AP 963 may be an Xn application protocol layer (XnAP or Xn-AP)963 for the Xn interface 512 defined between two or more RAN nodes 511.

NG-AP 963 may support the functionality of NG interface 513 and may include a basic procedure (EP). The NG-AP EP may be the unit of interaction between the NG-RAN node 511 and the AMF. The NG-AP 963 service may include two groups: UE-associated services (e.g., services related to UE 501) and non-UE-associated services (e.g., services related to the entire NG interface instance between NG-RAN node 511 and the AMF). These services may include functions including, but not limited to: a paging function for sending a paging request to NG-RAN nodes 511 involved in a specific paging area; a UE context management function for allowing the AMF to establish, modify and/or release UE contexts in the AMF and NG-RAN nodes 511; mobility functions for the UE 501 in ECM-CONNECTED mode, support mobility in NG-RAN for intra-system HO, support mobility from/to EPS system for inter-system HO; NAS signaling transport function, configured to transport or reroute NAS messages between UE 501 and AMF; NAS node selection function to determine the association between the AMF and the UE 501; the NG interface management function is used for establishing an NG interface and monitoring errors on the NG interface; a warning message transmission function for providing a means of transmitting a warning message or canceling an ongoing warning message broadcast via the NG interface; a configuration transfer function for requesting and transferring RAN configuration information (e.g., SON information, Performance Measurement (PM) data, etc.) between the two RAN nodes 511 via CN 520; and/or other similar functions.

XnAP 963 may support the functionality of the Xn interface 512 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedure may include procedures for handling UE mobility within the NG RAN 511 (or E-UTRAN), such as handover preparation and cancellation procedures, SN state transfer procedures, UE context acquisition and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and so on. The XnAP global procedures may include procedures unrelated to the particular UE 501, such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, and the like.

In an LTE implementation, the AP 963 may be an S1 application protocol layer (S1-AP)963 for an S1 interface 513 defined between the E-UTRAN node 511 and the MME, or the AP 963 may be an X2 interface 512X2 application protocol layer (X2AP or X2-AP)963 for an X2 interface defined between two or more E-UTRAN nodes 511.

The S1 application protocol layer (S1-AP)963 may support the functionality of the S1 interface, and similar to the NG-AP discussed previously, the S1-AP may include the S1-AP EP. The S1-AP EP may be the unit of interaction between the E-UTRAN node 511 and the MME within the LTE CN 520. The S1-AP 963 service may include two groups: UE-associated services and non-UE-associated services. These services perform functions including, but not limited to: E-UTRAN radio Access bearer (E-RAB) management, UE capability indication, mobility, NAS signaling, RAN Information Management (RIM), and configuration transfer.

The X2AP 963 may support the functionality of the X2 interface 512 and may include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedure may include procedures for handling UE mobility within the E-UTRAN 520, such as handover preparation and cancellation procedures, SN state transfer procedures, UE context acquisition and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and the like. The X2AP global procedures may include procedures unrelated to the particular UE 501, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, and the like.

The SCTP layer (alternatively referred to as the SCTP/IP layer) 962 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1-AP or X2AP messages in LTE implementations). SCTP 962 may ensure reliable transport of signaling messages between RAN node 511 and the AMF/MME based in part on IP protocols supported by IP 961. An internet protocol layer (IP)961 may be used to perform packet addressing and routing functions. In some implementations, the IP layer 961 may use point-to-point transport to transmit and deliver PDUs. In this regard, the RAN node 511 may include L2 and L1 layer communication links (e.g., wired or wireless) with the MME/AMF to exchange information.

In a second example, the user plane protocol stack may include, in order from the highest layer to the lowest layer, the SDAP 947, the PDCP 940, the RLC 930, the MAC 920, and the PHY 910. The user plane protocol stack may be used for communication between the UE 501, RAN node 511, and the UPF in NR implementations or S-GW and P-GW in LTE implementations. In this example, the upper layers 951 may be constructed above the SDAP 947 and may include a User Datagram Protocol (UDP) and IP Security layer (UDP/IP)952, a General Packet Radio Service (GPRS) tunneling protocol (GTP-U)953 for the user plane layer, and a user plane PDU layer (UP PDU) 963.

Transport network layer 954 (also referred to as a "transport layer") may be built on top of IP transport, and GTP-U953 may be used on top of UDP/IP layer 952 (including UDP layer and IP layer) to carry user plane PDUs (UP-PDUs). The IP layer (also referred to as the "internet layer") may be used to perform packet addressing and routing functions. The IP layer may assign IP addresses to user data packets, for example, in any of IPv4, IPv6, or PPP formats.

GTP-U953 may be used to carry user data within the GPRS core network and between the radio access network and the core network. The user data transmitted may be packets in any of IPv4, IPv6, or PPP formats, for example. UDP/IP 952 may provide a checksum for data integrity, port numbers for addressing different functions at source and destination, and encryption and authentication of selected data streams. The RAN node 511 and S-GW may exchange user plane data via a protocol stack including an L1 layer (e.g., PHY 910), an L2 layer (e.g., MAC 920, RLC 930, PDCP 940, and/or SDAP 947), a UDP/IP layer 952, and a GTP-U953 using an S1-U interface. The S-GW and the P-GW may exchange user-plane data via a protocol stack including a L1 layer, a L2 layer, a UDP/IP layer 952, and a GTP-U953 using an S5/S8a interface. As previously discussed, the NAS protocol may support mobility of the UE 501 and session management procedures to establish and maintain an IP connection between the UE 501 and the P-GW.

Further, although not shown in fig. 9, there may be an application layer above the AP 963 and/or the transport network layer 954. The application layer may be a layer at which a user of UE 501, RAN node 511, or other network element interacts with, for example, a software application being executed by application circuitry 605 or application circuitry 705, respectively. The application layer may also provide one or more interfaces for software applications to interact with the communication system (e.g., baseband circuitry 810) of UE 501 or RAN node 511. In some implementations, the IP layer and/or the application layer can provide the same or similar functionality as or portions of layers 5-7 of the Open Systems Interconnection (OSI) model (e.g., layer 7 of OSI-the application layer, layer 6 of OSI-the presentation layer and layer 5 of OSI-the session layer).

Fig. 10 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 methodologies discussed herein, according to some example embodiments. In particular, fig. 10 shows a pictorial representation of hardware resources 1000, hardware resources 1000 including one or more processors (or processor cores) 1010, one or more memory/storage devices 1020, and one or more communication resources 1030, each of which may be communicatively coupled via a bus 1040. For embodiments that utilize node virtualization (e.g., NFV), hypervisor 1002 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 1000.

Processor 1010 may include, for example, a processor 1012 and a processor 1014. Processor 1010 may be, for example, 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 DSP (e.g., baseband processor), an ASIC, an FPGA, a Radio Frequency Integrated Circuit (RFIC), another processor (including the processors discussed herein), or any suitable combination thereof.

Memory/storage 1020 may include main memory, disk storage, or any suitable combination thereof. Memory/storage 1020 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.

The communication resources 1030 may include interconnection or network interface components or other suitable devices for communicating with one or more peripheral devices 1004 or one or more databases 1006 via the network 1008. For example, communication resources 1030 may include wired communication components (e.g., for coupling via USB), cellular communication components, NFC components,

(or low power consumption)

) A component,

Components and other communication components.

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

The following examples pertain to further embodiments.

Example 1 may include an apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells), the apparatus comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: performing beam failure detection on the plurality of SCells to detect beam failure events for one or more SCells of the plurality of SCells; and in response to detecting a beam failure event on the one or more scells, initiating transmission of a beam failure recovery request (BFRQ) by transmitting information regarding the beam failure event and a failed CC index to the gNB via the RF interface, wherein the information regarding the beam failure event and the failed CC index is transmitted as a single report by a Medium Access Control (MAC) Control Element (CE).

Example 2 may include the subject matter of example 1 and any other example herein, wherein the one or more processors are further configured to: when a beam failure event is detected for the first SCell: triggering a MAC CE to transmit information of the first SCell and the second SCell if the MAC CE for the second SCell with the beam failure event has not been transmitted; and if the second MAC CE for the second SCell has been transmitted but an Acknowledgement (ACK) for the second MAC CE is not received, triggering the first MAC CE to transmit information of the first SCell.

Example 3 may include the subject matter of example 1 and any other example herein, wherein the information further includes information on a new beam, and one or both of the information on the failed CC index and the information on the new beam transmitted within the MAC CE is restricted to a first SCell of the one or more scells, and wherein the one or more processors are further configured to: triggering a second MAC CE for a second SCell of the one or more SCells when a beam failure event is detected for the second SCell.

Example 4 may include the subject matter of example 1 and any other example herein, wherein a first counter and a first timer are maintained separately for each SCell for beam failure detection, and wherein the one or more processors are further configured to: for each SCell, when one beam failure instance is detected, incrementing a first counter and restarting a first timer; resetting the first counter if the first timer expires; and declaring a beam failure event if the first counter reaches a predefined maximum value.

Example 5 may include the subject matter of example 1 and any other example herein, wherein a second timer and a second counter are maintained for transmission of the beam failure recovery request, and wherein the one or more processors are further configured to: starting a second timer after detecting the beam failure event; starting a second counter after transmission of the MAC CE; incrementing a second counter after retransmitting the MAC CE; resetting the second timer and the second counter after receiving an Acknowledgement (ACK) of the MAC CE; and stopping transmission of the MAC CE if a predefined maximum value of the second timer or the second counter is reached.

Example 6 may include the subject matter of example 1 and any other example herein, wherein the number of scells with beam failure events that can be transmitted via one MAC CE is configurable or predefined, or indicated by a header of the MAC CE.

Example 7 may include an apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells), the apparatus comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: performing beam failure detection on the plurality of SCells to detect beam failure events for one or more SCells of the plurality of SCells; and in response to detecting a beam failure event on the one or more scells, initiating transmission of a beam failure recovery request (BFRQ) by sending information about the beam failure event and a failed CC index to the gNB via the RF interface, wherein first information about the beam failure event is sent in a first step over a dedicated Physical Uplink Control Channel (PUCCH) or a Physical Random Access Channel (PRACH) resource and second information about the failed CC index is sent in a second step over a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI).

Example 8 may include the subject matter of example 7 and any other example herein, wherein the one or more processors are further configured to: when a beam failure event is detected for the first SCell: updating the MAC CE or UCI for the second SCell with the beam failure event to include second information of the first SCell if the first step has been triggered for the second SCell with the beam failure event but the MAC CE or UCI for the second SCell has not been transmitted; and triggering separate first and second steps for the first SCell if the MAC CE or UCI for the second SCell has been transmitted and an Acknowledgement (ACK) of the MAC CE or UCI is not received.

Example 9 may include the subject matter of example 7 and any other example herein, wherein the second information further includes information on a new beam, and one or both of the information on the failed CC index and the information on the new beam transmitted within the MAC CE or UCI is restricted to a first SCell of the one or more scells, and wherein the one or more processors are further configured to: triggering a second MAC CE for a second SCell of the one or more SCells when a beam failure event is detected for the second SCell.

Example 10 may include the subject matter of example 7 and any other example herein, wherein a first counter and a first timer are maintained separately for each SCell for beam failure detection, and wherein the one or more processors are further configured to: for each SCell, when one beam failure instance is detected, incrementing a first counter and restarting a first timer; resetting the first counter if the first timer expires; and declaring a beam failure event if the first counter reaches a predefined maximum value.

Example 11 may include the subject matter of example 7 and any other example herein, wherein only one second timer and one second counter are maintained for the plurality of scells for transmission of beam failure recovery requests, and wherein the one or more processors are further configured to: starting a second timer and a second counter after the first transmission of the beam failure event in the first step; incrementing a second counter each time a beam failure event is transmitted in the first step; resetting the second timer and the second counter if one of the following conditions is met: a predefined maximum value of the second timer or second counter is reached, an uplink grant has been received, or transmission of the MAC CE is started; and stopping transmission of the MAC CE if the predefined maximum value of the second timer or the second counter is reached and transmission of the MAC CE has not started.

Example 12 may include the subject matter of example 7 and any other example herein, wherein the number of scells with beam failure events that can be transmitted via one MAC CE is configurable or predefined, or indicated by a header of the MAC CE.

Example 13 may include an apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells), comprising: a Radio Frequency (RF) interface; and one or more processors coupled to the RF interface and configured to: performing beam failure detection on the plurality of SCells to detect beam failure events for one or more SCells of the plurality of SCells; and in response to detecting a beam failure event on the one or more scells, initiating transmission of a beam failure recovery request (BFRQ) by sending information about the beam failure event and failed CC index to the gNB via the RF interface, wherein the information about the beam failure event and failed CC index is sent in a first step over a dedicated Physical Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) resource.

Example 14 may include the subject matter of example 13 and any other example herein, wherein the one or more processors are further configured to: when a beam failure event is detected for an SCell, a separate first step is triggered for that SCell.

Example 15 may include the subject matter of example 13 and any other example herein, wherein a first counter and a first timer are maintained separately for each SCell for beam failure detection, and wherein the one or more processors are further configured to: for each SCell, when one beam failure instance is detected, incrementing a first counter and restarting a first timer; resetting the first counter if the first timer expires; and declaring a beam failure event if the first counter reaches a predefined maximum value.

Example 16 may include the subject matter of example 13 and any other example herein, wherein a second timer and a second counter are maintained separately for each SCell for transmission of beam failure recovery requests, and wherein the one or more processors are further configured to: for each SCell, after triggering the first step for the first time, starting a second timer and a second counter; incrementing a second counter each time the first step is triggered; and resetting the second timer and the second counter after a predefined maximum value of the second timer or the second counter is reached or transmission of a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) carrying new beam information is started.

Example 17 may include a computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors of a User Equipment (UE), cause the one or more processors to: detecting a beam failure on a secondary cell (SCell) of a new air interface (NR) wireless cellular network; based on the detection, incrementing a counter and resetting a timer; determining that the counter has reached a threshold before the timer expires; and initiating a beam failure report based on the determination.

Example 18 may include the subject matter of example 17 and any other example herein, wherein the instructions, when executed, further cause the one or more processors to: encoding a beam failure report in a Medium Access Control (MAC) Control Element (CE) for transmission, the beam failure report including a Component Carrier (CC) index of an SCell and new beam information.

Example 19 may include the subject matter of example 18 and any other example herein, wherein the SCell is a first SCell, and wherein the beam failure report further includes a CC index of a second SCell that has detected a beam failure.

Example 20 may include the subject matter of example 17 and any other example herein, wherein initiating beam failure reporting comprises: encoding a Physical Uplink Control Channel (PUCCH) or a Physical Random Access Channel (PRACH) including an indication of a beam failure for transmission to a gNB on a primary cell (PCell); and encoding a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) including a CC index of the SCell for transmission to the gNB on the PCell.

Example 21 may include the subject matter of example 20 and any other example herein, wherein the SCell is a first SCell, and wherein the instructions, when executed, further cause the one or more processors to: determining that the UE previously transmitted an indication of the beam failure in a Physical Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) based on the beam failure of the second SCell, and that a MAC CE or UCI associated with the beam failure of the second SCell has not been transmitted; and encode a MAC CE or UCI including CC indices of the first SCell and the second SCell for transmission on a primary cell (PCell).

Example 22 may include the subject matter of example 20 and any other example herein, wherein the MAC CE or UCI further includes new beam information.

Example 23 may include the subject matter of example 20 and any other example herein, wherein the instructions, when executed, further cause the one or more processors to: determining a maximum number of SCells that can report beam failure in the same MAC CE or UCI, wherein the MAC CE or UCI is encoded based on the determination.

Example 24 may include the subject matter of example 23 and any other example herein, wherein the instructions, when executed, further cause the one or more processors to: configuration information is received to indicate a maximum number.

Example 25 may include the subject matter of example 23 and any other example herein, wherein the MAC CE or UCI includes a field to indicate a number of scells in which a beam failure is reported in the MAC CE or UCI.

Example 26 may include the subject matter of example 17 and any other example herein, wherein initiating beam failure reporting comprises: encoding a Physical Uplink Control Channel (PUCCH) or a Physical Random Access Channel (PRACH) indicating a Component Carrier (CC) index of the SCell to indicate beam failure on the SCell for transmission to the gNB on a primary cell (PCell); and encoding a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) including the new beam information for transmission to the gNB on the PCell.

Example 27 may include the subject matter of example 17 and any other example herein, wherein the instructions, when executed, further cause the one or more processors to: receiving a deactivation command from the gNB indicating deactivation of the SCell; and stopping listening for beam failure on the SCell based on the deactivation command.

Claims

1. An apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells), the apparatus comprising:

a Radio Frequency (RF) interface; and

one or more processors coupled to the RF interface and configured to:

performing beam failure detection on the plurality of SCells to detect beam failure events for one or more SCells of the plurality of SCells; and

in response to detecting a beam failure event on the one or more SCells, initiating transmission of a beam failure recovery request (BFRQ) by sending information about the beam failure event and failed CC index to the gNB via the RF interface,

wherein the information on the beam failure event and the failed CC index is transmitted as a single report through a Medium Access Control (MAC) Control Element (CE).

2. The apparatus of claim 1, wherein the one or more processors are further configured to:

when a beam failure event is detected for the first SCell:

triggering a MAC CE to transmit information of the first SCell and the second SCell if the MAC CE for the second SCell with the beam failure event has not been transmitted; and

triggering the first MAC CE to transmit information of the first SCell if a second MAC CE for the second SCell has been transmitted but an Acknowledgement (ACK) for the second MAC CE is not received.

3. The apparatus of claim 1, wherein the information further comprises information on a new beam, and one or both of the information on a failed CC index and the information on a new beam transmitted within the MAC CE is restricted to a first SCell of the one or more SCells, and

wherein the one or more processors are further configured to:

triggering a second MAC CE for a second SCell of the one or more SCells when a beam failure event is detected for the second SCell.

4. The apparatus of claim 1, wherein a first counter and a first timer are maintained separately for each SCell for beam failure detection, and

wherein the one or more processors are further configured to: for each SCell,

incrementing a first counter and restarting the first timer when a beam failure instance is detected;

resetting the first counter if the first timer expires; and

if the first counter reaches a predefined maximum value, a beam failure event is declared.

5. The apparatus of claim 1, wherein a second timer and a second counter are maintained for transmission of a beam failure recovery request, and

wherein the one or more processors are further configured to:

starting a second timer after detecting the beam failure event;

starting a second counter after transmission of the MAC CE;

incrementing a second counter after retransmitting the MAC CE;

resetting the second timer and the second counter after receiving an Acknowledgement (ACK) of the MAC CE; and

the transmission of the MAC CE is stopped if a predefined maximum value of the second timer or the second counter is reached.

6. The apparatus of claim 1, wherein the number of scells with beam failure events that can be transmitted via one MAC CE is configurable or predefined, or indicated by a header of the MAC CE.

7. An apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells), the apparatus comprising:

a Radio Frequency (RF) interface; and

one or more processors coupled to the RF interface and configured to:

wherein the first information on the beam failure event is transmitted through a dedicated Physical Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) resource in the first step, and the second information on the failed CC index is transmitted through a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) in the second step.

8. The apparatus of claim 7, wherein the one or more processors are further configured to:

when a beam failure event is detected for the first SCell:

updating the MAC CE or UCI for the second SCell with the beam failure event to include second information of the first SCell if the first step has been triggered for the second SCell with the beam failure event but the MAC CE or UCI for the second SCell has not been transmitted; and

if the MAC CE or UCI for the second SCell has been transmitted and an Acknowledgement (ACK) of the MAC CE or UCI is not received, separate first and second steps are triggered for the first SCell.

9. The apparatus of claim 7, wherein the second information further comprises information on a new beam, and one or both of the information on a failed CC index and the information on a new beam transmitted within the MAC CE or UCI is restricted to a first SCell of the one or more SCells, and

wherein the one or more processors are further configured to:

10. The apparatus of claim 7, wherein a first counter and a first timer are maintained separately for each SCell for beam failure detection, and

wherein the one or more processors are further configured to: for each SCell,

resetting the first counter if the first timer expires; and

11. The apparatus of claim 7, wherein only one second timer and one second counter are maintained for the plurality of SCells for transmission of a beam failure recovery request, and

wherein the one or more processors are further configured to:

starting a second timer and a second counter after the first transmission of the beam failure event in the first step;

incrementing a second counter each time a beam failure event is transmitted in the first step;

resetting the second timer and the second counter if one of the following conditions is met: a predefined maximum value of the second timer or second counter is reached, an uplink grant has been received, or transmission of the MAC CE is started; and

if the predefined maximum value of the second timer or the second counter is reached and the transmission of the MAC CE has not started, the transmission of the MAC CE is stopped.

12. The apparatus of claim 7, wherein the number of SCells with beam failure events that can be transmitted via one MAC CE is configurable or predefined or is indicated by a header of a MAC CE.

13. An apparatus of a User Equipment (UE) configured to operate with a plurality of Component Carriers (CCs) including a primary cell (PCell) and a plurality of secondary cells (scells), the apparatus comprising:

a Radio Frequency (RF) interface; and

one or more processors coupled to the RF interface and configured to:

wherein the information on the beam failure event and the failed CC index is transmitted through a dedicated Physical Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) resource in the first step.

14. The apparatus of claim 13, wherein the one or more processors are further configured to:

when a beam failure event is detected for an SCell, a separate first step is triggered for that SCell.

15. The apparatus of claim 13, wherein a first counter and a first timer are maintained separately for each SCell for beam failure detection, and

wherein the one or more processors are further configured to: for each SCell,

resetting the first counter if the first timer expires; and

16. The apparatus of claim 13, wherein a second timer and a second counter are maintained separately for each SCell for transmission of beam failure recovery requests, and

wherein the one or more processors are further configured to: for each SCell,

after triggering the first step for the first time, starting a second timer and a second counter;

incrementing a second counter each time the first step is triggered; and

the second timer and the second counter are reset after a predefined maximum value of the second timer or the second counter is reached or transmission of a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) carrying new beam information is started.

17. A computer-readable storage medium having instructions stored thereon, which when executed by one or more processors of a User Equipment (UE) cause the one or more processors to:

detecting a beam failure on a secondary cell (SCell) of a new air interface (NR) wireless cellular network;

based on the detection, incrementing a counter and resetting a timer;

determining that the counter has reached a threshold before the timer expires; and

based on the determination, a beam failure report is initiated.

18. The medium of claim 17, wherein the instructions, when executed, further cause the one or more processors to:

encoding a beam failure report in a Medium Access Control (MAC) Control Element (CE) for transmission, the beam failure report including a Component Carrier (CC) index of an SCell and new beam information.

19. The medium of claim 18, wherein the SCell is a first SCell, and wherein the beam failure report further includes a CC index for a second SCell that has detected a beam failure.

20. The medium of claim 17, wherein initiating beam failure reporting comprises:

encoding a Physical Uplink Control Channel (PUCCH) or a Physical Random Access Channel (PRACH) including an indication of a beam failure for transmission to a gNB on a primary cell (PCell); and

a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) including a CC index of the SCell is encoded for transmission to the gNB on the PCell.

21. The media of claim 20, wherein the SCell is a first SCell, and wherein the instructions, when executed, further cause the one or more processors to:

determining that the UE previously transmitted an indication of the beam failure in a Physical Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) based on the beam failure of the second SCell, and that a MAC CE or UCI associated with the beam failure of the second SCell has not been transmitted; and

the MAC CE or UCI including the CC indices of the first SCell and the second SCell is encoded for transmission on a primary cell (PCell).

22. The medium of claim 20, wherein the MAC CE or UCI further includes new beam information.

23. The medium of claim 20, wherein the instructions, when executed, further cause the one or more processors to:

determining a maximum number of SCells that can report beam failure in the same MAC CE or UCI, wherein the MAC CE or UCI is encoded based on the determination.

24. The medium of claim 23, wherein the instructions, when executed, further cause the one or more processors to:

configuration information is received to indicate a maximum number.

25. The medium of claim 23, wherein the MAC CE or UCI includes a field to indicate a number of scells for which a beam failure is reported in the MAC CE or UCI.

26. The medium of claim 17, wherein initiating beam failure reporting comprises:

encoding a Physical Uplink Control Channel (PUCCH) or a Physical Random Access Channel (PRACH) indicating a Component Carrier (CC) index of the SCell to indicate beam failure on the SCell for transmission to the gNB on a primary cell (PCell); and

a Medium Access Control (MAC) Control Element (CE) or Uplink Control Information (UCI) including the new beam information is encoded for transmission to the gNB on the PCell.

27. The medium of claim 17, wherein the instructions, when executed, further cause the one or more processors to:

receiving a deactivation command from the gNB indicating deactivation of the SCell; and

based on the deactivation command, stopping listening for beam failure on the SCell.