Secondary cell beam failure recovery operation in new radio (NR)

Abstract

Embodiments of systems, methods, and computer program products for performing beam failure recovery are disclosed herein. One embodiment operates by detecting a beam failure on a secondary cell (SCell). The embodiment transmits a beam failure recovery request (BFRQ) for the SCell to a base station via a primary cell (PCell). The embodiment transmits the BFRQ for the SCell via a primary uplink control channel (PUCCH), a physical random access channel (PRACH), or a primary uplink shared channel (PUSCH) via the PCell. The embodiment may transmit a schedule request (SR) for allocating PUSCH via the PCell. The embodiment receives a response to the BFRQ for the SCell from the base station via the SCell or PCell. Subsequently, the embodiment uses a new beam for the SCell based on the response to the BFRQ for the SCell.

Description

Technology Field

[0001] Cross-reference of related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 805,864 filed February 14, 2019, the entirety of which is incorporated herein by reference. Background Technology

[0003] Various embodiments can generally be related to the field of wireless communications.

[0004] Some embodiments of the present invention include methods, apparatus, and computer-readable media for performing beam failure recovery.

[0005] Some embodiments relate to an apparatus comprising a processor circuit and a wireless front-end circuit. The processor circuit can detect a beam failure on a secondary cell (SCell). The processor circuit can generate a beam failure recovery request (BFRQ) for the SCell. The BFRQ may include a component carrier identifier for the SCell or a candidate beam identifier for a new beam to be used for recovery. The processor circuit can transmit the BFRQ for the SCell to a base station via a primary cell (PCell) using the wireless front-end circuit. The processor circuit can receive a response to the BFRQ for the SCell from the base station via the SCell or PCell. Subsequently, the processor circuit can use a new beam for the SCell based on the response to the BFRQ for the SCell.

[0006] In embodiments, the processor circuit may use the wireless front-end circuit to transmit a BFRQ for SCell via a primary uplink control channel (PUCCH) or a physical random access channel (PRACH) through PCell. The processor circuit may also use the wireless front-end circuit to transmit a BFRQ for SCell via a primary uplink shared channel (PUSCH) through PCell. The processor circuit may determine whether there is a primary uplink shared channel (PUSCH) available through PCell. If not, the processor circuit may use the wireless front-end circuit to transmit a schedule request (SR) to the base station for allocating a PUSCH through PCell. In response, the processor circuit may receive an indication from the base station of the allocated PUSCH through PCell. The processor circuit can use the wireless front-end circuit to transmit a BFRQ for the SCell to the base station using a media access control control element (MAC-CE) via a PUSCH assigned through the PCell. Brief explanation of the drawing

[0007] FIG. 1 is a flowchart illustrating a process for beam failure recovery according to some embodiments. FIG. 2 illustrates an exemplary system architecture according to some embodiments. FIG. 3 illustrates other exemplary system architectures according to some embodiments. FIG. 4 illustrates other exemplary system architectures according to some embodiments. FIG. 5 illustrates a block diagram of an exemplary infrastructure equipment according to some embodiments. FIG. 6 illustrates a block diagram of an exemplary platform according to some embodiments. FIG. 7 illustrates a block diagram of a baseband circuit and front-end modules according to some embodiments. FIG. 8 illustrates a block diagram of exemplary protocol functions that can be implemented in a wireless communication device according to some embodiments. FIG. 9 illustrates a block diagram of the components of a core network according to some embodiments. FIG. 10 illustrates a block diagram of components of a system for supporting Network functions virtualization (NFV) according to some embodiments. FIG. 11 illustrates a block diagram of an exemplary computer system that can be utilized to implement various embodiments. FIG. 12 is a flowchart illustrating a process for beam failure recovery according to some embodiments. FIG. 13 is a flowchart illustrating a process for beam failure recovery according to some embodiments. FIG. 14 is a flowchart illustrating a process for beam failure recovery according to some embodiments. The features and advantages of the embodiments will become more apparent from the detailed description below when taken together with the drawings, and similar reference numerals in the drawings identify corresponding elements throughout. In the drawings, similar reference numerals represent elements that are generally identical, functionally similar, and / or structurally similar. The drawing in which an element appears first is indicated by the leftmost number(s) in the corresponding reference numeral. Specific details for implementing the invention

[0008] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify identical or similar elements. In the following description, specific details such as specific structures, architectures, interfaces, techniques, etc., are described for the purpose of explanation rather than limitation and to provide a thorough understanding of various aspects of various embodiments. However, it will be apparent to those skilled in the art who have an interest in this application that various aspects of various embodiments may be practiced in other examples other than these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of various embodiments with unnecessary details. For the purposes of the present invention, the phrase “A or B” means (A), (B), or (A and B).

[0009] The embodiments described herein may relate to the 3GPP (3rd Generation Partnership Project) New Radio (NR) Release 16 (Rel-16) Working Item(s, WI).

[0010] In the case of secondary cell (SCell) beam failure recovery, for transmitting a beam failure recovery request (BFRQ), it has been agreed upon in radio access network 1 (RAN1) New Radio (NR) that the first scenario to consider is a SCell having only a downlink (DL). This means that if a beam failure occurs for a SCell, a beam failure recovery request for the SCell must be transmitted through the primary cell (PCell). In some embodiments, one method of transmitting a beam failure recovery request for the SCell through the PCell is for the beam failure recovery request to be transmitted by the Media Access Control-Control Element (MAC-CE).

[0011] However, in legacy implementations, there may be issues with MAC-CE in transmitting a BFRQ for a SCell. For example, a method for triggering MAC-CE transmission when the UE does not have available PUSCH resources for transmission. In some embodiments, MAC-CE content for the BFRQ for the SCell, such as how many candidate beams should be transmitted, may be defined.

[0012] Some embodiments may relate to a next-generation node B (gNB) response to a SCell beam failure recovery request. The gNB may also be referred to as a base station. It may be defined whether the gNB response is transmitted via a PCell or a SCell. And, the gNB response format may be clarified accordingly.

[0013] Some embodiments described herein may relate to systems, devices, or techniques for SCell beam failure recovery operations in NR, including a scheme for transmitting a MAC-CE-based beam failure recovery request and a method for transmitting a gNB response to a beam failure recovery request.

[0014] 1. Beam Failure Recovery Request (BFRQ) for SCell Transmission

[0015] It was agreed at the RAN1 NR Ad-Hoc meeting in January 2019 that, in the case of SCell beam failure recovery, the first scenario to be considered for sending a beam failure recovery request (BFRQ) is a SCell with only a downlink (DL). This means that if a beam failure occurs for a SCell, a beam failure recovery request for the SCell can be transmitted through a PCell.

[0016] In some embodiments, one method of transmitting a beam failure recovery request to SCell via PCell is that the beam failure recovery request is transmitted by MAC-CE.

[0017] However, there are some issues with MAC-CE in transmitting BFRQs for SCells. For example, how to trigger MAC-CE transmission when the User Equipment (UE) does not have physical uplink shared channel (PUSCH) resources available for transmission. Also, MAC-CE content for the BFRQ for SCell, such as how many candidate beams should be delivered, can be defined.

[0018] A) BFRQ MAC-CE delivery

[0019] In the event of a beam failure, beam failure recovery operations must be performed as quickly as possible to restore the communication link. For SCell beam failure recovery, the BFRQ must be transmitted rapidly through the PCell.

[0020] However, for MAC-CE-based BFRQ transmission, if the UE does not have resources available for PUSCH transmission, for example, if the UE does not have available uplink acknowledgments, BFRQ transmission may be delayed.

[0021] In some embodiments, to transmit a BFRQ to a SCell in a MAC-CE through a PCell, the UE must check whether it has a PUSCH resource / uplink acknowledgment available through the PCell. If the UE has a PUSCH resource available, the BFRQ MAC-CE to the SCell is transmitted through the available PUSCH resource. If the UE does not have a PUSCH resource / uplink acknowledgment available, the UE may first trigger the transmission of a Scheduling Request (SR) to request a PUSCH resource for transmitting the BFRQ. After the gNB receives the SR, the gNB may subsequently allocate a PUSCH resource, and the UE transmits the BFRQ MAC-CE through the allocated PUSCH resource.

[0022] FIG. 1 is a flowchart of a method (100) for performing beam failure recovery according to some embodiments. The method (100) may be performed by hardware (e.g., circuits, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or processing logic that may include a combination thereof. It will be understood that not all steps may be required to perform the disclosure provided herein. Also, as understood by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG. 1.

[0023] In step (102), the UE identifies a beam failure through SCell.

[0024] In step (104), the UE determines whether it has available PUSCH resources. If so, step (106) is performed. If not, step (108) is performed.

[0025] In step (106), the UE uses MAC-CE through available PUSCH resources via PCell to transmit BFRQ for SCell to the base station (e.g., gNB).

[0026] In step (108), the UE triggers a schedule request (SR) to the base station through the PCell. The UE can transmit the SR through the PUCCH via the PCell or through a physical random access channel (PRACH).

[0027] In step (110), the UE receives an uplink (UL) acknowledgment from the base station to allocate PUSCH resources through the PCell.

[0028] In step (112), the UE uses MAC-CE through the allocated PUSCH resources via the PCell to send a BFRQ for the SCell to the base station.

[0029] The processes and functions described in FIG. 1 may be performed by one or more of the application circuit section (505 or 605), baseband circuit section (510 or 610), or processors (1112 and 1114).

[0030] In some embodiments, if the UE does not have available PUSCH resources / uplink acknowledgments, after N milliseconds / slots from the UE identifying a SCell beam failure, the UE must first trigger the transmission of a scheduling request (SR), where N is configurable and N can be predefined, e.g., N=0. The SR may be a dedicated SR for beam failure recovery, or the same SR may be shared for other purposes.

[0031] In some embodiments, a new type of buffer status report (BSR) may be defined to trigger an SR transmission for a BFRQ (e.g., BFRQ BSR). After the UE detects a beam failure through the SCell, the UE may generate a BFRQ MAC-CE for the SCell and trigger the BFRQ BSR. If the UE does not have available PUSCH resources, the BFRQ BSR may trigger an SR transmission.

[0032] B) BFRQ MAC-CE Content

[0033] In embodiments, BFRQ MAC-CE may include the following information:

[0034] One or more component carrier identifiers (IDs) representing the SCell where beam failure occurs. It may also be a bitmap of component carriers.

[0035] One or more candidate beam(s) IDs representing the identified new beam(s) for the corresponding SCell.

[0036] Layer 1 reference signal received power (L1-RSRP) and / or layer 1 signal-to-interference-plus-noise ratio (L1-SINR) information for candidate beam(s). L1-RSRP and / or L1-SINR information may be optional.

[0037] 2. Beam failure recovery response for SCell

[0038] In addition to MAC-CE-based BFRQs for SCell, another method for transmitting BFRQs for SCell is to use the Physical Uplink Control Channel (PUCCH) through the PCell. The PUCCH can transmit the following information regarding the BFRQ: one or more component carrier IDs where the beam failure occurred, one or more candidate beam IDs, and optional L1-RSRP and / or L1-SINR for the candidate beam(s). After the UE transmits the BFRQ for SCell via the PCell, the UE may wait for a response to the BFRQ from the gNB.

[0039] In some embodiments, the gNB response is transmitted via SCell. The response may be transmitted via a dedicated Control Resource Set (CORESET) / search space, which is used exclusively for transmitting SCell beam failure recovery responses. In this way, the response may be Downlink Control Information (DCI) addressed to the UE. After successfully receiving the DCI, the UE may assume that the communication link has been restored.

[0040] If a BFRQ for a SCell is transmitted via MAC-CE or PUCCH through a PCell at time instance T1, the UE may begin monitoring a dedicated CORESET through the corresponding SCell starting from T1 + N slots / symbols, where N is configurable or predefined and N can be 0 or greater. Additionally, the slots / symbols may be defined according to the PCell's numerology. Alternatively, the slots / symbols may be defined according to the SCell's numerology.

[0041] If the BFRQ for a SCell by MAC-CE or PUCCH contains only one candidate beam for the corresponding SCell, the UE can monitor a dedicated CORESET through the SCell using the spatial QCL (Quasi co-location) assumption as identified by MAC-CE, for example, the gNB can use the identified candidate beam to transmit a gNB response through the SCell. In other words, the gNB and the UE can assume that the TCI state of the Physical Downlink Control Channel (PDCCH) through the SCell is identical to the identified candidate beam until the TCI state is reconfigured or reactivated. In the case of PDSCH reception, the gNB and the UE can assume that the Demodulation Reference Signal (DMRS) ports of the PDSCH through the SCell are spatially QCLed with the identified candidate beam until the TCI state is reconfigured or reactivated.

[0042] If the BFRQ for a SCell by MAC-CE or PUCCH contains more than one candidate beam for the corresponding SCell, the default beam may be applied for PDCCH (e.g., dedicated CORESET) and PDSCH transmissions until the TCI state is reconfigured or reactivated. For example, the default beam may be one of the following:

[0043] The first / last candidate beam included in MAC-CE or PUCCH

[0044] Candidate beams with the best L1-RSRP or best L1-SINR

[0045] Alternatively, if the UE transmits a BFRQ to a SCell via MAC-CE or PUCCH through a PCell at time instance T2, the UE may begin monitoring the previously configured CORESET / search space through the corresponding SCell starting from T2 + M slots / symbols, where M is configurable or predefined and M can be 0 or greater. Also, the slots / symbols may be defined according to the numerology of the PCell or SCell. For monitoring the CORESET / search space through the SCell, the UE may apply a default space QCL assumption. The default space QCL assumption may be the identified candidate beam if only one candidate beam is transmitted in the BFRQ by MAC-CE or PUCCH. Also, the default space QCL assumption may be the first / last candidate beam, or if the BFRQ by MAC-CE or PUCCH includes more than one candidate beam, it may be the candidate beam having the best L1-RSRP or L1-SINR. If the DCI addressed to the UE is successfully received, it can be assumed that a gNB response for the BFRQ is received. In this manner, there is no need to configure a dedicated CORESET for SCell beam failure recovery operations.

[0046] In embodiments, the gNB response to the SCell BFRQ is transmitted via the PCell. The gNB response may be a reconfiguration / reactivation message by the radio resource control (RRC layer) or MAC layer. For example, the message may be used to reconfigure the TCI status for the SCell, or the gNB Tx beam or control resource set (CORESET), such as CSI-RS and / or SS / PBCH blocks. After the UE receives the reconfiguration / reactivation message, the UE may assume that the BFRQ for the SCell has been received by the gNB.

[0047] If the gNB response to the SCell BFRQ contains only one beam information (e.g., only one TCI state), the UE may assume that the DMRS port of the SCell's PDCCH / PDSCH is spatially QCL with that included in the gNB response. If the gNB response to the SCell BFRQ contains more than one beam information, the UE may assume a default beam for receiving PDCCH / PDSCH through the SCell prior to receiving the MAC-CE reactivation command. For example, the default beam may be the first beam or the last beam included in the gNB response.

[0048] If a gNB response or MAC-CE reactivation command is received via PCell at time instance T3, after T3 + K slots / symbols, the UE may apply a reconfigured / reactivated spatial QCL assumption for receiving PDCCH / PDSCH via SCell, where K is configurable or predefined and K can be 0 or greater. Also, slots / symbols may be defined according to the PCell's numerology. Alternatively, slots / symbols may be defined according to the SCell's numerology.

[0049] For both embodiments, if the UE does not receive a response from the gNB in ​​X slots or ms after transmitting the MAC CE for the BFRQ, the UE may retransmit the MAC CE until it reaches a maximum number of retransmissions, where X and the maximum number of retransmissions may be configured or predefined by RRC signaling.

[0050] In some embodiments, it is configurable whether the gNB response to a SCell beam failure recovery request is delivered via PCell or SCell. Consequently, the UE can monitor PCell or SCell for the gNB response after sending a BFRQ to SCell.

[0051] Systems and implementation examples

[0052] FIG. 2 illustrates an exemplary architecture of a network system (200) according to various embodiments. The following description is provided for an exemplary system (200) operating with LTE system standards and 5G or NR system standards as provided by 3GPP technical specifications. However, exemplary embodiments are not limited thereto and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., 6G (Sixth Generation) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.).

[0053] As illustrated in FIG. 2, the system (200) includes UE (201a) and UE (201b) (collectively referred to as "UEs (201)" or "UE (201)"). In this example, the UEs (201) are exemplified as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but also any mobile or non-mobile computing device, e.g., consumer electronic devices, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handsets, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, instrument clusters (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashboard mobile equipment (DME), mobile data terminals (MDT), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control It may include modules, EMS (engine management systems), networked or "smart" devices, MTC devices, M2M, IoT devices, etc.

[0054] In some embodiments, any of the UEs (201) may be IoT UEs, which may include a network access layer designed for low-power IoT applications utilizing short-lifetime UE connections. The IoT UE may utilize technologies such as MTC or M2M to exchange data with an MTC server or device via PLMN, ProSe or D2D communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. The IoT network describes interconnecting the IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) utilizing short-lifetime connections. The IoT UEs may run background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connections to the IoT network.

[0055] UEs (201) may be configured to connect with a RAN (210), for example, to be coupled to communicate with it. In embodiments, the RAN (210) may be an NG RAN or a 5G RAN, an E-UTRAN, or a legacy RAN, e.g., a UTRAN or a GERAN. As used herein, terms “NG RAN,” etc. may refer to a RAN (210) operating in an NR or 5G system (200), and terms “E-UTRAN,” etc. may refer to a RAN (210) operating in an LTE or 4G system (200). Each of the UEs (201) utilizes connections (or channels) (203 and 204), each of which includes a physical communication interface or layer (discussed in more detail below).

[0056] In this example, the connections (203 and 204) are illustrated as air interfaces for enabling communication coupling and may be compatible with cellular communication protocols, e.g., GSM protocol, CDMA network protocol, PTT protocol, POC protocol, UMTS protocol, 3GPP LTE protocol, 5G protocol, NR protocol, and / or any of other communication protocols discussed herein. In embodiments, UEs (201) may directly exchange communication data through the ProSe interface (205). The ProSe interface (205) may alternatively be referred to as the SL interface (205) and may include one or more logic channels, including but not limited to PSCCH, PSSCH, PSDCH, and PSBCH.

[0057] The UE (201b) is illustrated as being configured to access the AP (206) (also referred to as "WLAN node (206)", "WLAN (206)", "WLAN end (206)", "WT (206)", etc.) via a connection (207). The connection (207) may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, where the AP (206) will include a Wi-Fi® (wireless fidelity) router. In this example, the AP (206) is illustrated as being connected to the Internet without being connected to the core network of the wireless system (described in more detail below). In various embodiments, the UE (201b), RAN (210), and AP (206) may be configured to utilize LWA operation and / or LWIP operation. LWA operation may involve the UE (201b) being in RRC_CONNECTED configured by the RAN node (211a-b) to utilize LTE and WLAN wireless resources. LWIP operation may involve the UE (201b) using WLAN wireless resources (e.g., connection (207)) through IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) transmitted through connection (207). IPsec tunneling may include protecting the original headers of the IP packets by encapsulating the entire original IP packets and adding a new packet header.

[0058] The RAN (210) may include one or more AN nodes or RAN nodes (211a, 211b) (collectively referred to as “RAN nodes (211”) or “RAN nodes (211”)) that enable connections (203, 204). As used herein, terms “access node,” “access point,” etc. may describe equipment that provides wireless baseband functions for data and / or voice connectivity between a network and one or more users. Such access nodes may be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs, or TRPs, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographical area (e.g., a cell). As used herein, terms “NG RAN node,” etc. may refer to a RAN node (211) operating in an NR or 5G system (200) (e.g., gNB), and terms “E-UTRAN node,” etc. may refer to a RAN node (211) operating in an LTE or 4G system (200) (e.g., eNB). According to various embodiments, the RAN nodes (211) may be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells, or other similar cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0059] In some embodiments, all or part of the RAN nodes (211) may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as CRAN and / or vBBUP (virtual baseband unit pool). In these embodiments, CRAN or vBBUP may implement a RAN function partition, such as a PDCP partition, in which RRC and PDCP layers are operated by CRAN / vBBUP and other L2 protocol entities are operated by individual RAN nodes (211); a MAC / PHY partition in which RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP and the PHY layer is operated by individual RAN nodes (211); or a “lower PHY” partition in which the upper parts of the RRC, PDCP, RLC, MAC layers and PHY layer are operated by CRAN / vBBUP and the lower parts of the PHY layer are operated by individual RAN nodes (211). This virtualized framework enables the freed-up processor cores of the RAN nodes (211) to perform other virtualized applications. In some embodiments, an individual RAN node (211) may represent individual gNB-DUs connected to the gNB-CU through individual F1 interfaces (not shown in FIG. 2). In these embodiments, the gNB-DUs may include one or more remote radio heads or radio front end modules (RFEMs) (e.g., see FIG. 5), and the gNB-CU may be operated by a server located in the RAN (210) (not shown) or by a server pool in a manner similar to CRAN / vBBUP.Additionally or alternatively, one or more of the RAN nodes (211) may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol endpoints toward the UEs (201) and are connected to the 5GC (e.g., CN (420) in FIG. 4) through the NG interface (discussed below).

[0060] In V2X scenarios, one or more of the RAN nodes (211) may be RSUs or may act as them. The terms "Road Side Unit" or "RSU" may refer to any transportation infrastructure entity used in V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE may be referred to as a "UE-type RSU," an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU," and so on. In one example, an RSU is a computing device coupled with a radio frequency circuit located on the roadside that provides connectivity support for passing vehicle UEs (201) (vUEs (201)). The RSU may also include an internal data storage circuitry for storing cross-map geometry, traffic statistics, media, as well as applications / software for detecting and controlling ongoing vehicle and pedestrian traffic. The RSU may operate in the 5.9 GHz DSRC (Direct Short Range Communications) band to provide very low-latency communications required for high-speed events such as collision avoidance and traffic warnings. Additionally or alternatively, the RSU may operate in the cellular V2X band to provide other cellular communication services in addition to the aforementioned low-latency communications. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide uplink and downlink communications by providing connectivity to one or more cellular networks.Part or all of the radio frequency circuitry of the computing device(s) and RSU may be packaged within a weatherproof enclosure suitable for outdoor installation and may include a network interface controller for providing wired connections (e.g., Ethernet) to a traffic signal controller and / or backhaul network.

[0061] Any of the RAN nodes (211) may terminate the air interface protocol and may be a first contact point for the UEs (201). In some embodiments, any of the RAN nodes (211) may perform various logical functions for the RAN (210), including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0062] In embodiments, UEs (201) may be configured to communicate with each other or with any of the RAN nodes (211) using OFDM communication signals over a multicarrier communication channel according to 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), but not limited thereto, but the scope of embodiments is not limited in this respect. OFDM signals may include multiple orthogonal subcarriers.

[0063] In some embodiments, a downlink resource grid may be used for downlink transmissions from any of the RAN nodes (211) to the UEs (201), while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is a physical resource in the downlink within each slot. Such a time-frequency plane representation is a common practice for OFDM systems, making it intuitive for wireless resource allocation. 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 within a wireless frame. The minimum time-frequency unit in the resource grid is denoted as a resource element. Each resource grid contains a plurality of resource blocks, which describe the mapping of a given physical channel to the resource elements. Each resource block contains a set of resource elements; in the frequency domain, this may represent the minimum amount of resources currently available for allocation. There exist several different physical downlink channels that are transmitted using such resource blocks.

[0064] According to various embodiments, UEs (201, 202) and RAN nodes (211, 212) communicate data (e.g., transmit and receive) through a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum may include a 5 GHz band.

[0065] To operate in the unlicensed spectrum, UEs (201, 202) and RAN nodes (211, 212) may operate using LAA, eLAA, and / or feLAA mechanisms. In these embodiments, UEs (201, 202) and RAN nodes (211, 212) may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels within the unlicensed spectrum are unavailable or otherwise occupied prior to transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to the listen-before-talk (LBT) protocol.

[0066] LBT is a mechanism by which equipment (e.g., UEs (201, 202), RAN nodes (211, 212), etc.) senses a medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a specific channel within the medium is sensed not to be occupied). The medium sense operation may include CCA, which utilizes at least ED to determine the presence or absence of other signals on the channel to determine whether the channel is occupied or clear. This LBT mechanism enables cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing RF energy across an intended transmission band for a certain period and comparing the sensed RF energy to a predefined or configured threshold.

[0067] Typically, existing systems within the 5 GHz band are WLANs based on IEEE 802.11 technologies. WLANs utilize a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as a UE (201 or 202), AP (206), etc.) intends to transmit, the WLAN node may perform CCA before transmission. Additionally, a backoff mechanism is used to avoid collisions in situations where more than one WLAN node detects the channel as idle and transmits simultaneously. The backoff mechanism may be a counter randomly generated within the CWS, which increases exponentially upon the occurrence of a collision and is reset to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to the WLAN's CSMA / CA. In some embodiments, the LBT procedure for DL ​​or UL transmit bursts, each containing PDSCH or PUSCH transmits, may have an LAA contention window of variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values ​​for CWS for LAA. In one example, the minimum CWS for LAA transmit may be 9 microseconds (μs); however, the size of the CWS and MCOT (e.g., transmit burst) may be based on government regulatory requirements.

[0068] LAA mechanisms are built upon the CA technologies of LTE Advanced systems. In CA, each aggregated carrier is referred to as a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, so the maximum aggregated bandwidth is 100 MHz. In FDD systems, the number of aggregated carriers may differ for DL ​​and UL, where the number of UL CCs is less than or equal to the number of DL component carriers. In some cases, individual CCs may have different bandwidths from other CCs. In TDD systems, not only the number of CCs but also the bandwidths of each CC are typically the same for DL ​​and UL.

[0069] CA also includes individual serving cells to provide individual CCs. The coverage of serving cells may differ, for example, because CCs on different frequency bands will experience different path losses. A primary service cell or PCell may provide PCCs for both UL and DL and handle RRC and NAS-related activities. Other serving cells are referred to as SCells, and each SCell may provide individual SCCs for both UL and DL. SCCs may be added and removed as needed, while changing PCCs may require the UE (201, 202) to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in unlicensed spectrum (referred to as "LAA SCells"), and LAA SCells are assisted by PCells operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE can receive UL acknowledgments representing different PUSCH start positions within the same subframe on the configured LAA SCells.

[0070] The PDSCH transmits user data and higher-level signaling to the UEs (201). The PDCCH transmits, among other things, information regarding transmission formats and resource allocations associated with the PDSCH channel. It may also notify the UEs (201) regarding transmission formats, resource allocations, and HARQ information associated with the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to UEs (201b) within a cell) may be performed at any of the RAN nodes (211) based on channel quality information fed back from any of the UEs (201). Downlink resource allocation information may be transmitted over the PDCCH used for each of the UEs (201) (e.g., assigned to them).

[0071] PDCCH transmits control information using CCEs. Before being mapped to resource elements, PDCCH complex symbols can first be organized into quadruplets, which can then be substituted using a sub-block interleaver for rate matching. Each PDCCH can be transmitted using one or more of these CCEs, where each CCE can correspond to nine sets of four physical resource elements known as REGs. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the DCI size and channel conditions, PDCCH can 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).

[0072] Some embodiments may use concepts for resource allocation for control channel information that are extensions of the concepts described above. For example, some embodiments may utilize EPDCCH that uses PDSCH resources for transmitting control information. EPDCCH may be transmitted using one or more ECCEs. Similarly, each ECCE may correspond to nine sets of four physical resource elements known as EREGs. In some situations, an ECCE may have a different number of EREGs.

[0073] RAN nodes (211) may be configured to communicate with each other through an interface (212). In embodiments where the system (200) is an LTE system (e.g., when the CN (220) is an EPC (320) as in FIG. 3), the interface (212) may be an X2 interface (212). The X2 interface may be defined between two or more RAN nodes (211) (e.g., two or more eNBs, etc.) connected to the EPC (220), and / or between two eNBs connected to the EPC (220). In some embodiments, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide flow control mechanisms for user data packets transmitted through the X2 interface and may be used to communicate information regarding the transfer of user data between eNBs. For example, X2-U may provide specific sequence number information for user data transmitted from MeNB to SeNB; information regarding the successful sequential delivery of PDCP PDUs for user data from SeNB to UE (201); information regarding PDCP PDUs that were not delivered to UE (201); information regarding the current minimum desired buffer size in SeNB for transmission as UE user data, etc. X2-C may provide intra-LTE access mobility functions, including context transmissions from source to target eNBs and user plane transmission control; load management functions; as well as inter-cell interference coordination functions.

[0074] In embodiments where the system (200) is a 5G or NR system (e.g., when the CN (220) is a 5GC (420) as in FIG. 4), the interface (212) may be an Xn interface (212). The Xn interface is defined between two or more RAN nodes (211) (e.g., two or more gNBs, etc.) connected to the 5GC (220), between a RAN node (211) (e.g., gNB) connected to the 5GC (220) and an eNB, and / or between two eNBs connected to the 5GC (220). In some embodiments, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. Xn-C may provide mobility support for a UE (201) in a connection mode (e.g., CM-CONNECTED), which includes management and error handling functions, functions for managing Xn-C interfaces; and functions for managing UE mobility for a connection mode between one or more RAN nodes (211). Mobility support may include context transfer from an old (source) serving RAN node (211) to a new (target) serving RAN node (211); and control of user plane tunnels between the old (source) serving RAN node (211) and the new (target) serving RAN node (211). The protocol stack of Xn-U may include a transport network layer built on top of an Internet Protocol (IP) transport layer, and a GTP-U layer on top of the UDP and / or IP layer(s) for delivering user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on top of SCTP. SCTP may sit on top of the IP layer and can provide guaranteed delivery of application layer messages.At the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other embodiments, the Xn-U protocol stack and / or Xn-C protocol stack may be identical or similar to the user plane and / or control plane protocol stack(s) illustrated and described herein.

[0075] The RAN (210) is illustrated as being communicably coupled to a core network, in this embodiment, a core network (CN) (220). The CN (220) may include a plurality of network elements (222), which are configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UEs (201)) who connect to the CN (220) through the RAN (210). The components of the CN (220) may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transient machine-readable storage medium). In some embodiments, NFV is utilized to virtualize any or all of the aforementioned network node functions through executable instructions stored on one or more computer-readable storage media (described further in detail below). A logical instantiation of CN (220) may be referred to as a network slice, and a logical instantiation of a part of CN (220) may be referred to as a network subslice. NFV architectures and infrastructures may be used to virtualize one or more network functions performed on physical resources, including a combination of industry-standard server hardware, storage hardware, or switches, or alternatively by private hardware. In other words, NFV systems may be used to execute virtual or reconfigurable implementations of one or more EPC components / functions.

[0076] Generally, the application server (230) may be an element that provides applications using IP bearer resources with the core network (e.g., UMTS PS domains, LTE PS data services, etc.). The application server (230) 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 UEs (201) through the EPC (220).

[0077] In embodiments, CN (220) may be 5GC (referred to as "5GC (220)", etc.), and RAN (210) may be connected to CN (220) through NG interface (213). In embodiments, NG interface (213) may be divided into two parts: an NG user plane (NG-U) interface (214) that transmits traffic data between RAN nodes (211) and UPFs, and an S1 control plane (NG-C) interface (215) which is a signaling interface between RAN nodes (211) and AMFs. Embodiments in which CN (220) is 5GC (220) are discussed in more detail in relation to FIG. 4.

[0078] In embodiments, CN (220) may be a 5G CN (referred to as "5GC (220)", etc.), while in other embodiments, CN (220) may be an EPC. When CN (220) is an EPC (referred to as "EPC (220)", etc., RAN (210) may be connected to CN (220) via an S1 interface (213). In embodiments, the S1 interface (213) may be divided into two parts: an S1 user plane (S1-U) interface (214) that transmits traffic data between RAN nodes (211) and the S-GW, and an S1-MME interface (215) which is a signaling interface between RAN nodes (211) and MMEs. An exemplary architecture in which CN (220) is an EPC (220) is illustrated in FIG. 3.

[0079] FIG. 3 illustrates an exemplary architecture of a system (300) including a first CN (320) according to various embodiments. In this example, the system (300) may implement an LTE standard, wherein the CN (320) is an EPC (320) corresponding to the CN (220) of FIG. 2. Additionally, the UE (301) may be identical or similar to the UEs (201) of FIG. 2, and the E-UTRAN (310) may be a RAN identical or similar to the RAN (210) of FIG. 2, which may include the previously discussed RAN nodes (211). The CN (320) may include MMEs (321), an S-GW (322), a P-GW (323), an HSS (324), and an SGSN (325).

[0080] The MMEs (321) may be functionally similar to the control plane of a legacy SGSN and may implement MM functions for tracking the current location of the UE (301). The MMEs (321) may perform various MM procedures for managing mobility suns in access, such as gateway selection and tracking area list management. MM (also referred to as "EPS MM" or "EMM" in E-UTRAN systems) may refer to any applicable procedures, methods, data storage, etc. used to maintain knowledge of the current location of the UE (301) and / or, provide user identity confidentiality, or perform other similar services to users / subscribers. Each UE (301) and MME (321) may include an MM or EMM sublayer, and an MM context may be established within the UE (301) and MME (321) when the attach procedure is successfully completed. The MM context may be a data structure or database object that stores MM-related information of the UE (301). The MMEs (321) may be coupled to the HSS (324) via the S6a reference point, coupled to the SGSN (325) via the S3 reference point, and coupled to the S-GW (322) via the S11 reference point.

[0081] The SGSN (325) may be a node serving the UE (301) by tracking the location of the individual UE (301) and performing security functions. Additionally, the SGSN (325) may perform inter-EPC node signaling for mobility between 2G / 3G and E-UTRAN 3GPP access networks; PDN and S-GW selection as specified by the MMEs (321); handling of UE (301) time zone functions as specified by the MMEs (321); and MME selection for handovers to the E-UTRAN 3GPP access network. An S3 reference point between the MMEs (321) and the SGSN (325) may enable the exchange of user and bearer information regarding inter-3GPP access network mobility in idle and / or active states.

[0082] The HSS (324) may include a database of network users containing subscription-related information to support the handling of network entities for communication sessions. The EPC (320) may include one or several HSSs (324) depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, the HSS (324) may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc. The S6a reference point between the HSS (324) and the MMEs (321) may enable the transmission of subscription and authentication data to authenticate / authorize user access to the EPC (320) between the HSS (324) and the MMEs (321).

[0083] The S-GW (322) can terminate the S1 interface (213) ("S1-U" in FIG. 3) toward the RAN (310) and route data packets between the RAN (310) and the EPC (320). Additionally, the S-GW (322) may be a local mobility anchor point for inter-RAN node handovers and may also provide an anchor for inter-3GPP mobility. Other tasks may include lawful intercept, billing, and some policy enforcement. The S11 reference point between the S-GW (322) and the MMEs (321) may provide a control plane between the MMEs (321) and the S-GW (322). The S-GW (322) may be coupled to the P-GW (323) via the S5 reference point.

[0084] The P-GW (323) can terminate an SGi interface toward the PDN (330). The P-GW (323) can route data packets between the EPC (320) and external networks, such as a network containing an application server (230) (alternatively referred to as "AF"), via an IP interface (225) (e.g., see FIG. 2). In embodiments, the P-GW (323) can be communicateably coupled to an application server (the application server (230) in FIG. 2 or the PDN (330) in FIG. 3) via an IP communication interface (225) (e.g., see FIG. 2). An S5 reference point between the P-GW (323) and the S-GW (322) can provide user plane tunneling and tunnel management between the P-GW (323) and the S-GW (322). The S5 reference point may also be used for the relocation of the S-GW (322) when, due to UE (301) mobility, the S-GW (322) needs to connect to a non-juxtended P-GW (323) for the required PDN access. The P-GW (323) may additionally include a node (e.g., PCEF (not shown)) for policy enforcement and billing data collection. Additionally, the SGi reference point between the P-GW (323) and the packet data network (PDN) (330) may be, for example, an operator-external public or private PDN or an intra-operator packet data network for the provision of IMS services. The P-GW (323) may be coupled to the PCRF (326) via the Gx reference point.

[0085] The PCRF (326) is a policy and billing control element of the EPC (320). In a non-roaming scenario, there may be a single PCRF (326) within the Home Public Land Mobile Network (HPLMN) associated with the Internet Protocol Connectivity Access Network (IP-CAN) session of the UE (301). In a roaming scenario with a local breakout of traffic, there may be two PCRFs associated with the IP-CAN session of the UE (301): the Home PCRF (H-PCRF) within the HPLMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). The PCRF (326) can be coupled to the application server (330) via the P-GW (323) for communication. The application server (330) can signal the PCRF (326) to indicate a new service flow and select appropriate QoS and billing parameters. The PCRF (326) may provision these rules to the PCEF (not shown) along with the appropriate TFT and QCI, and the PCEF initiates QoS and billing as specified by the application server (330). A Gx reference point between the PCRF (326) and the P-GW (323) may allow the transmission of QoS policies and billing rules from the PCRF (326) to the PCEF within the P-GW (323). An Rx reference point may exist between the PDN (330) (or "AF (330)") and the PCRF (326).

[0086] FIG. 4 illustrates the architecture of a system (400) including a second CN (420) according to various embodiments. The system (400) is illustrated as comprising: a UE (401) which may be identical or similar to the previously discussed UEs (201) and UE (301); a (R)AN (410) which may be identical or similar to the previously discussed RAN (210) and RAN (310) and may include the previously discussed RAN nodes (211); a data network (DN) (403) which may be, for example, operator services, internet access, or third-party services; and a 5GC (420). The 5GC (420) includes an AUSF (422); AMF (421); SMF (424); NEF (423); PCF (426); NRF (425); UDM (427); AF (428); UPF (402); and may include NSSF (429).

[0087] The UPF (402) can serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to the DN (403), and a branch point to support multi-homed PDU sessions. The UPF (402) can also perform packet routing and forwarding, perform packet inspection, enforce the user plane portion of policy rules, legally intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., flow mapping from SDF to QoS), transmit level packet markings within the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF (402) may include an uplink classifier to support routing traffic flows to the data network. DN (403) may represent various network operator services, internet access, or third-party services. DN (403) may include the previously discussed application server (230) or be similar. UPF (402) may interact with SMF (424) through an N4 reference point between SMF (424) and UPF (402).

[0088] The AUSF (422) can store data for the authentication of the UE (401) and handle authentication-related functions. The AUSF (422) can facilitate a common authentication framework for various access types. The AUSF (422) can communicate with the AMF (421) via an N12 reference point between the AMF (421) and the AUSF (422); and can communicate with the UDM (427) via an N13 reference point between the UDM (427) and the AUSF (422). Additionally, the AUSF (422) can represent a Nausf service-based interface.

[0089] The AMF (421) may be responsible for registration management (e.g., for registering the UE (401), etc.), access management, accessibility management, mobility management, legitimate interception of AMF-related events, and access authentication and authorization. The AMF (421) may be an endpoint for the N11 reference point between the AMF (421) and the SMF (424). The AMF (421) may provide transmission for SM messages between the UE (401) and the SMF (424) and may act as a transparent proxy for routing SM messages. The AMF (421) may also provide transmission for SMS messages between the UE (401) and the SMSF (not shown in FIG. 4). The AMF (421) may act as a SEAF, which may include interaction with the AUSF (422) and the UE (401), and reception of an intermediate key established as a result of the UE (401) authentication process. When USIM-based authentication is used, the AMF (421) can retrieve security materials from the AUSF (422). The AMF (421) may also include an SCM function, which receives keys from the SEA that it uses to derive access-network specific keys. Additionally, the AMF (421) may be an endpoint of a RAN CP interface, which may be or include an N2 reference point between the (R)AN (410) and the AMF (421); the AMF (421) may be an endpoint of NAS (N1) signaling and may perform NAS encryption and integrity protection.

[0090] The AMF (421) can also support NAS signaling with the UE (401) through the N3 IWF interface. The N3 IWF can be used to provide access to untrusted entities. The N3 IWF can be an endpoint for the N2 interface between the (R)AN (410) for the control plane and the AMF (421), and an endpoint for the N3 reference point between the (R)AN (410) for the user plane and the UPF (402). As such, the AMF (421) can handle N2 signaling from the SMF (424) and the AMF (421) for PDU sessions and QoS, encapsulate / decapsulate packets for IPSec and N3 tunneling, mark N3 user plane packets on the uplink, and enforce QoS corresponding to N3 packet markings by taking into account QoS requirements associated with such markings received through N2. N3IWF can also relay uplink and downlink control plane NAS signaling between UE (401) and AMF (421) via N1 reference point between UE (401) and AMF (421), and relay uplink and downlink user plane packets between UE (401) and UPF (402). N3IWF also provides mechanisms for establishing an IPsec tunnel with UE (401). AMF (421) may represent a Namf service-based interface and may be an endpoint for N14 reference point between two AMFs (421) and N17 reference point between AMF (421) and 5G-EIR (not shown in FIG. 4).

[0091] The UE (401) may need to register with the AMF (421) to receive network services. The RM is used to register or unregister the UE (401) with a network (e.g., the AMF (421)) and to establish a UE context within the network (e.g., the AMF (421)). The UE (401) may operate in an RM-REGISTERED state or an RM-DEREGISTERED state. In the RM-DEREGISTERED state, the UE (401) is not registered with the network, and since the UE context within the AMF (421) does not maintain valid location or routing information for the UE (401), the UE (401) is not accessible by the AMF (421). In the RM-REGISTERED state, the UE (401) is registered with the network, and since the UE context within the AMF (421) may maintain valid location or routing information for the UE (401), the UE (401) is accessible by the AMF (421). In the RM-REGISTERED state, the UE (401) may, among other things, perform mobility registration update procedures, perform periodic registration update procedures triggered by the expiration of a periodic update timer (e.g., to notify the network that the UE (401) is still active), and perform registration update procedures to update UE capability information or to renegotiate protocol parameters with the network.

[0092] The AMF (421) may store one or more RM contexts for the UE (401), each RM context being associated with a specific access to the network. The RM contexts may be data structures, database objects, etc., that display or store registration status and periodic update timers per access type. The AMF (421) may also store a 5GC MM context that may be identical or similar to the (E)MM context discussed earlier. In various embodiments, the AMF (421) may store the CE mode B limit parameters of the UE (401) within the associated MM context or RM context. The AMF (421) may also derive values ​​from the UE's usage setting parameters already stored within the UE context (and / or MM / RM context) when necessary.

[0093] The CM can be used to establish and release signaling connections between the UE (401) and the AMF (421) through the N1 interface. The signaling connections are used to enable NAS signaling exchanges between the UE (401) and the CN (420) and include both signaling connections between the UE and the AN (e.g., an RRC connection for non-3GPP access or a UE-N3IWF connection) and N2 connections for the UE (401) between the AN (e.g., the RAN (410)) and the AMF (421). The UE (401) can operate in one of two CM states: CM-IDLE mode or CM-CONNECTED mode. When the UE (401) is operating in the CM-IDLE state / mode, the UE (401) may not have an established NAS signaling connection with the AMF (421) through the N1 interface, and there may be an (R)AN (410) signaling connection for the UE (401) (e.g., N2 and / or N3 connections). When the UE (401) is operating in the CM-CONNECTED state / mode, the UE (401) may have an established NAS signaling connection with the AMF (421) through the N1 interface, and there may be an (R)AN (410) signaling connection for the UE (401) (e.g., N2 and / or N3 connections). The establishment of an N2 connection between (R)AN (410) and AMF (421) can cause the UE (401) to transition from CM-IDLE mode to CM-CONNECTED mode, and the UE (401) can transition from CM-CONNECTED mode to CM-IDLE mode when the N2 signaling between (R)AN (410) and AMF (421) is released.

[0094] The SMF (424) may be responsible for SM (including session establishment, modification, and release, such as maintaining a tunnel between the UPF and the AN node); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuration of traffic steering in the UPF to route traffic to appropriate destinations; termination of interfaces toward policy control functions; control of QoS and policy enforcement parts; legitimate interception (for SM events and interfaces to LI systems); termination of SM parts of NAS messages; downlink data notification; initiation of AN-specific SM information transmitted to the AN via the AMF through the N2; and determining the SSC mode of the session. The SM may refer to the management of PDU sessions, and the PDU session or “session” may refer to a PDU access service that provides or enables the exchange of PDUs between the UE (401) and the data network (DN) (403) identified by the Data Network Name (DNN). PDU sessions can be established upon request by UE (401), modified upon request by UE (401) and 5GC (420), and released upon request by UE (401) and 5GC (420) using NAS SM signaling exchanged through the N1 reference point between UE (401) and SMF (424). Upon request from the application server, 5GC (420) can trigger a specific application within UE (401). In response to receipt of a trigger message, UE (401) can forward the trigger message (or related parts / information of the trigger message) to one or more identified applications within UE (401). The identified application(s) within UE (401) can establish a PDU session for a specific DNN. SMF (424) can determine whether the UE (401) requests correspond to user subscription information associated with UE (401).In this regard, SMF (424) may request UDM (427) to retrieve and / or receive update notifications for SMF (424) level subscription data.

[0095] The SMF (424) may include the following roaming functions: handling of local enforcement for applying QoS SLAs (VPLMN); billing data collection and billing interface (VPLMN); legal interception (that which is within the VPLMN for SM events and interfaces to the LI system); and support for interaction with an external DN for the transmission of signaling for PDU session authorization / authentication by the external DN. An N16 reference point between two SMFs (424) may be included in the system (400), which may be between another SMF (424) in the visiting network and the SMF (424) in the home network in roaming scenarios. Additionally, the SMF (424) may represent an Nsmf service-based interface.

[0096] NEF (423) may provide means for securely exposing services and capabilities provided by 3GPP network functions to third parties, internal exposure / re-exposure, application functions (e.g., AF (428)), edge computing or fog computing systems, etc. In such embodiments, NEF (423) may authenticate, authorize, and / or throttle AFs. NEF (423) may also convert information exchanged with AF (428) and information exchanged with internal network functions. For example, NEF (423) may convert between AF-service-identifiers and internal 5GC information. NEF (423) may also receive information from other network functions (NFs) based on the exposed capabilities of other network functions. This information may be stored in NEF (423) as structured data, or in data storage NFs using standardized interfaces. Subsequently, the stored information may be re-exposed to other NFs and AFs by the NEF (423) and / or used for other purposes such as analyses. Additionally, the NEF (423) may represent an Nnef service-based interface.

[0097] NRF (425) supports service discovery functions, receives NF discovery requests from NF instances, and can provide information about discovered NF instances to NF instances. NRF (425) also maintains information about available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and similar may refer to the creation of an instance, and “instance” may refer to the specific occurrence of an object, which may occur, for example, during the execution of program code. Additionally, NRF (425) may represent an Nnrf service-based interface.

[0098] PCF (426) can provide policy rules to control plane function(s) to enforce them, and can also support an integrated policy framework to manage network behavior. PCF (426) can also implement FE to access subscriber information related to policy decisions in the UDR of UDM (427). PCF (426) can communicate with AMF (421) via the N15 reference point between PCF (426) and AMF (421), which may include PCF (426) and AMF (421) within the visiting network in the case of roaming scenarios. PCF (426) can communicate with AF (428) via the N5 reference point between PCF (426) and AF (428); and with SMF (424) via the N7 reference point between PCF (426) and SMF (424). The system (400) and / or CN (420) may also include an N24 reference point between the PCF (426) (in the home network) and the PCF (426) in the visit network. Additionally, the PCF (426) may represent an Npcf service-based interface.

[0099] The UDM (427) can handle subscription-related information to support the handling of network entities of communication sessions and can store subscription data of the UE (401). For example, subscription data can be communicated between the UDM (427) and the AMF (421) via the N8 reference point between the UDM (427) and the AMF. The UDM (427) may include two parts, namely an application FE and a UDR (FE and UDR are not shown in FIG. 4). The UDR can store structured data for subscription data and policy data for the UDM (427) and the PCF (426), and / or exposure and application data for the NEF (423) (including PFDs for application detection and application request information for a number of UEs (401)). The Nudr service-based interface is represented by the UDR (221), which allows the UDM (427), PCF (426), and NEF (423) to access a specific set of stored data, as well as to read notifications of changes to related data within the UDR, update (e.g., add, modify), delete, and subscribe to it. The UDM may include a UDM-FE, which is responsible for processing credentials, location management, subscription management, etc. Multiple different front-ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored within the UDR and performs authentication credential processing, user identification handling, access authorization, enrollment / mobility management, and subscription management. The UDR may interact with the SMF (424) through the N10 reference point between the UDM (427) and the SMF (424). UDM (427) can also support SMS management, where the SMS-FE implements application logic similar to that previously discussed. Additionally, UDM (427) can represent a Nudm service-based interface.

[0100] The AF (428) provides application influence on traffic routing, provides access to the NCE, and can interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC (420) and AF (428) to provide information to each other via the NEF (423), which can be used in edge computing implementations. In such implementations, network operators and third-party services may be hosted close to the UE (401) access connection point to achieve efficient service delivery with reduced end-to-end latency and load on the transport network. For edge computing implementations, the 5GC may select a UPF (402) close to the UE (401) and execute traffic steering from the UPF (402) to the DN (403) via the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF (428). In this way, AF (428) can influence UPF (re)selection and traffic routing. Based on operator placement, when AF (428) is considered a trusted entity, the network operator can allow AF (428) to interact directly with relevant NFs. Additionally, AF (428) can represent a Naf service-based interface.

[0101] The NSSF (429) may select a set of network slice instances to serve the UE (401). The NSSF (429) may also determine, if necessary, mapping to allowed NSSAIs and joined S-NSSAIs. The NSSF (429) may also determine a set of AMFs or a list of candidate AMF(s) (421) to be used to serve the UE (401) based on a suitable configuration and possibly by querying the NRF (425). The selection of a set of network slice instances for the UE (401) may be triggered by an AMF (421) that is registered by the UE (401) interacting with the NSSF (429), which may lead to a change in the AMF (421). The NSSF (429) may interact with the AMF (421) through an N22 reference point between the AMF (421) and the NSSF (429); It can communicate with other NSSFs (429) within the visiting network through an N31 reference point (not shown in FIG. 4). Additionally, the NSSF (429) may represent an Nnssf service-based interface.

[0102] As previously discussed, the CN (420) may include an SMSF responsible for SMS subscription confirmation and verification, and relaying SM messages from other entities, such as SMS-GMSC / IWMSC / SMS routers, to the UE (401) and from the UE to other entities. The SMS may also interact with the AMF (421) and the UDM (427) for a notification procedure to make the UE (401) available for SMS transmission (e.g., setting the UE to an inaccessible flag and notifying the UDM (427) when the UE (401) is available for SMS).

[0103] CN (120) may also include other elements not illustrated in FIG. 4, such as a data storage system / architecture, 5G-EIR, SEPP, etc. The data storage system may include SDSF, UDSF, etc. Any NF may store and retrieve unstructured data into and from a UDSF (e.g., UE contexts) through an N18 reference point between any NF and a UDSF (not illustrated in FIG. 4). Individual NFs may share a UDSF to store their respective unstructured data, or individual NFs may each have their own UDSF located in or near the individual NFs. Additionally, a UDSF may represent a Nudsf service-based interface (not illustrated in FIG. 4). The 5G-EIR may be an NF that checks the state of a PEI to determine whether specific equipment / entities are blacklisted from the network; SEPP may be an opaque proxy that performs topology concealment, message filtering, and monitoring on inter-PLMN control plane interfaces.

[0104] Additionally, there may be more reference points and / or service-based interfaces between NF services within the NFs; however, these interfaces and reference points have been omitted from FIG. 4 for clarity. In one example, CN (420) may include an Nx interface, which is an inter-CN interface between an MME (e.g., MME (321)) and an AMF (421) to enable interworking between CN (420) and CN (320). Other exemplary interfaces / reference points may include the N5g-EIR service-based interface represented by 5G-EIR, the N27 reference point between an NRF in the visiting network and an NRF in the home network; and the N31 reference point between an NSSF in the visiting network and an NSSF in the home network.

[0105] FIG. 5 illustrates examples of infrastructure equipment (500) according to various embodiments. Infrastructure equipment (500) (or "system (500)") may be implemented as a base station, a radio head, a RAN node such as the RAN nodes (211) and / or AP (206) previously illustrated and described, an application server(s) (230), and / or any other element / device discussed herein. In other examples, the system (500) may be implemented in or by a UE.

[0106] The system (500) includes an application circuit (505), a baseband circuit (510), one or more radio front-end modules (RFEM) (515), a memory circuit (520), a power management integrated circuitry (PMIC) (525), a power tee circuit (530), a network controller circuit (535), a network interface connector (540), a satellite positioning circuit (545), and a user interface (550). In some embodiments, the device (500) may include additional elements, such as, for example, memory / storage, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, the components described below may be included in more than one device. For example, the circuits may be individually included in more than one device for a CRAN, vBBU, or other similar implementations.

[0107] The application circuit section (505) comprises one or more processors (or processor cores), cache memory, and LDOs (low drop-out voltage regulators), interrupt controllers, serial interfaces, such as SPI, I 2It includes circuitry such as, but not limited to, one or more of C, or a universal programmable serial interface module, a real-time clock (RTC), timer-counters including interval and watchdog timers, universal input / output (I / O or IO), memory card controllers such as SD (Secure Digital) MMC (MultiMediaCard) or similar, USB (Universal Serial Bus) interfaces, MIPI (Mobile Industry Processor Interface) interfaces, and JTAG (Joint Test Access Group) test access ports. Processors (or cores) of the application circuitry (505) may be coupled with or include memory / storage elements and may be configured to execute instructions stored in memory / storage so that various applications or operating systems can be executed on the system (500). In some embodiments, 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.

[0108] The processor(s) of the application circuit (505) 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 field-programmable gate arrays (FPGAs), one or more programmable logic devices (PLDs), one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, the application circuit (505) may be a special purpose processor / controller for operating according to various embodiments of this specification, or may include such a. As examples, the processor(s) of the application circuit (505) may be one or more Intel Pentium®, Core®, or Xeon® processor(s); AMD (Advanced Micro Devices) Ryzen® processor(s), APUs (Accelerated Processing Units), or Epyc® processors; ARM-based processor(s) licensed from ARM Holdings, Ltd., e.g., ARM Cortex-A series processors and ThunderX2® provided by Cavium(TM), Inc.; MIPS Technologies, Inc.It may include MIPS-based designs from, e.g., MIPS Warrior P-class processors; etc. In some embodiments, the system (500) may not be able to use the application circuitry (505) and instead may include a special purpose processor / controller for processing IP data received from, for example, an EPC or 5GC.

[0109] In some embodiments, the application circuit (505) may include one or more hardware accelerators, such as microprocessors, programmable processing devices, etc. One or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. Examples of programmable processing devices may include one or more field-programmable devices (FPDs), such as FPGAs, etc.; PLDs, such as CPLDs, HCPLDs, etc.; ASICs, such as structured ASICs, etc.; programmable SoCs (PSoCs); etc. In such embodiments, the circuit of the application circuit (505) may include logic blocks or logic fabrics, and other interconnected resources that can be programmed to perform various functions, such as procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuit of the application circuit (505) may include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, anti-fuses, etc.)) used to store logic blocks, logic structures, data, etc. in look-up tables (LUTs).

[0110] The baseband circuit section (510) may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single-package integrated circuit soldered to a main circuit board, or a multi-chip module including two or more integrated circuits. Various hardware electronic elements of the baseband circuit section (510) are discussed below in relation to FIG. 7.

[0111] The user interface circuit section (550) may include one or more user interfaces designed to enable user interaction with the system (500) or peripheral component interfaces designed to enable interaction with the system (500). The user interfaces may include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, speakers or other audio emitting devices, microphones, a printer, a scanner, a headset, a display screen or a display device, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power supply interface, etc.

[0112] Wireless front-end modules (RFEMs) (515) may include a millimeter wave (mmWave) RFEM and one or more sub-mmWave RFICs (radio frequency integrated circuits). In some embodiments, one or more sub-mmWave RFICs may be physically separated from the mmWave RFEM. The RFICs may include connections to one or more antennas or antenna arrays (e.g., see antenna array (711) in FIG. 7 below), and the RFEM may be connected to multiple antennas. In alternative embodiments, both mmWave and sub-mmWave radio functions may be implemented in the same physical RFEM (515) that integrates both mmWave antennas and sub-mmWave.

[0113] The memory circuit (520) may include one or more of volatile memory including DRAM and / or SDRAM (synchronous dynamic random access memory), and nonvolatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as flash memory), PRAM (phase change random access memory), MRAM (magnetoresistive random access memory), etc., and may include 3D XPOINT (cross-point) memories from Intel® and Micron®. The memory circuit (520) may be implemented as one or more of solder-down packaged integrated circuits, socketed memory modules, and plug-in memory cards.

[0114] The PMIC (525) may include voltage regulators, surge protectors, a power alarm detection circuit, and one or more backup power sources such as a battery or capacitor. The power alarm detection circuit may detect one or more of the conditions of a brown out (voltage shortage) and a surge (overvoltage). The power tee circuit (530) may provide electrical power drawn from a network cable to provide both power supply and data access to infrastructure equipment (500) using a single cable.

[0115] The network controller circuit (535) may provide access to a network using standard network interface protocols such as Ethernet, Ethernet over GRE tunnels, Ethernet over MPLS (Multiprotocol Label Switching), or some other suitable protocol. Network access may be provided to / from the infrastructure equipment (500) via a network interface connector (540) using a physical connection that may be electrical (commonly referred to as "copper interconnection"), optical, or wireless. The network controller circuit (535) may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some embodiments, the network controller circuit (535) may include multiple controllers to provide access to different networks using the same or different protocols.

[0116] The positioning circuit section (545) includes a circuit section for receiving and decoding signals transmitted / broadcast by the positioning network of the GNSS (global navigation satellite system). Examples of navigation satellite constellations (or GNSS) include the US GPS (Global Positioning System), Russia's GLONASS (Global Navigation System), the European Union's Galileo system, China's BeiDou navigation satellite system, regional navigation systems or GNSS augmentation systems (e.g., NAVIC (Navigation with Indian Constellation), Japan's QZSS (Quasi-Zenith Satellite System), France's DORIS (Doppler Orbitography and Radio-positioning Integrated by Satellite), etc.). The positioning circuit (545) includes various hardware elements (e.g., hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate OTA communications) to communicate with components of the positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuit (545) may include a Micro-PNT (Micro-Technology for Positioning, Navigation, and Timing) IC that performs position tracking / estimation without GNSS assistance using a master timing clock. The positioning circuit (545) may also be part of or interact with the baseband circuit (510) and / or RFEMs (515) to communicate with nodes and components of the positioning network.The positioning circuit section (545) may also provide position data and / or time data to the application circuit section (505), which can use the data to synchronize operations with various infrastructures (e.g., RAN nodes (211), etc.).

[0117] The components illustrated in FIG. 5 may communicate with each other using an interface circuitry that may include any number of bus and / or interconnect (IX) technologies, such as ISA (industry standard architecture), EISA (extended ISA), PCI (peripheral component interconnect), PCIx (peripheral component interconnect extended), PCIe (PCI express), or any number of other technologies. The bus / IX may be, for example, a proprietary bus used in an SoC-based system. Other bus / IX systems, such as, among others, I 2 C interface, SPI interface, point-to-point interfaces, and power bus may be included.

[0118] FIG. 6 illustrates examples of a platform (600) (or "device (600)") according to various embodiments. In embodiments, the computer platform (600) may be suitable for use as UEs (201, 202, 301), application servers (230), and / or any other element / device discussed herein. The platform (600) may include any combination of the components illustrated in the examples. The components of the platform (600) may be implemented as integrated circuits (ICs), parts thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or combinations thereof adapted to the computer platform (600), or otherwise as components integrated within the chassis of a larger system. The block diagram of FIG. 6 is intended to illustrate a high-level view of the components of the computer platform (600). However, some of the illustrated components may be omitted, additional components may exist, and different arrangements of the illustrated components may occur in different implementations.

[0119] The application circuit section (605) comprises one or more processors (or processor cores), cache memory, and LDOs, interrupt controllers, serial interfaces, such as SPI, I 2The circuit includes, but is not limited to, one or more of C or general-purpose programmable serial interface modules, RTCs, timer-counters including interval and watch timers, general-purpose I / O, memory card controllers such as SD MMC or similars, USB interfaces, MIPI interfaces, and JTAG test access ports. Processors (or cores) of the application circuit (605) may be coupled with or include memory / storage elements and may be configured to execute instructions stored in memory / storage so that various applications or operating systems can be executed on the system (600). In some embodiments, 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.

[0120] The processor(s) of the application circuit (505) 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, a multithreaded processor, an ultra-low voltage processor, an embedded processor, some other known processing element, or any suitable combination thereof. In some embodiments, the application circuit (505) may be a special purpose processor / controller for operating according to various embodiments of this specification, or may include such a.

[0121] As examples, the processor(s) of the application circuit (605) may include Intel® Architecture Core™-based processors, such as Quark™, ​​ATOM™, i3, i5, i7, or MCU-class processors, or other such processors available from Intel® Corporation, Santa Clara, California, USA. The processors of the application circuit (605) may also be one or more of AMD Ryzen® processor(s) or APUs; A5-A9 processor(s) from Apple® Inc., Snapdragon™ processors from Qualcomm® Technologies, Inc., Texas Instruments, Inc.® OMAP™ (Open Multimedia Applications Platform) processor(s); MIPS-based designs from 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, such as ARM Cortex-A, Cortex-R, and Cortex-M series processors. In some embodiments, the application circuit (605) may be part of a system on a chip (SoC) in which the application circuit (605) and other components are formed on a single integrated circuit or a single package, such as Edison™ or Galileo™ SoC boards from Intel® Corporation.

[0122] Additionally or alternatively, the application circuit (605) may include, but is not limited to, one or more FPDs, e.g., FPGAs, etc.; PLDs, e.g., CPLDs, HCPLDs, etc.; ASICs, e.g., structured ASICs, etc.; programmable SoCs (PSoCs); etc. In such embodiments, the circuit of the application circuit (605) may include logic blocks or logic structures, and other interconnected resources that can be programmed to perform various functions such as procedures, methods, functions, etc. of the various embodiments discussed herein. In such embodiments, the circuit of the application circuit (605) may include memory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g., SRAM, anti-fuses, etc.)) used to store logic blocks, logic structures, data, etc. in lookup tables (LUTs), etc.

[0123] The baseband circuit section (610) may be implemented, for example, as a solder-down substrate containing one or more integrated circuits, a single-package integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Various hardware electronic elements of the baseband circuit section (610) are discussed below in relation to FIG. 7.

[0124] RFEMs (615) may include a millimeter wave (mmWave) RFEM and one or more sub-mmWave RFICs. In some embodiments, 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 (e.g., see antenna array (711) in FIG. 7 below), and the RFEM may be connected to multiple antennas. In alternative embodiments, both mmWave and sub-mmWave radio functions may be implemented in the same physical RFEM (615) that incorporates both mmWave antennas and sub-mmWave.

[0125] The memory circuit (620) may include any number and type of memory devices used to provide a given amount of system memory. As examples, the memory circuit (620) may include one or more of volatile memory including RAM, DRAM and / or SDRAM, and high-speed electrically erasable memory (commonly referred to as flash memory), PRAM, MRAM, etc. The memory circuit (620) may be developed according to JEDEC (Joint Electron Devices Engineering Council) LPDDR (low power double data rate)-based designs such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit (620) may be implemented in one or more of solder-down packaged integrated circuits, single-die package (SDP), dual-die package (DDP) or quad-die package (Q17P), socketed memory modules, and dual inline memory modules (DIMM) including microDIMMs or MiniDIMMs, or may be soldered onto a motherboard via a ball grid array (BGA). In low-power embodiments, the memory circuit (620) may be on-die memory or registers associated with the application circuit (605). To provide permanent storage of information such as data, applications, operating systems, etc., the memory circuit (620) may include one or more mass storage devices, which, among others, may include solid-state disk drives (SSDs), hard disk drives (HDDs), micro HDDs, resistive change memories, phase change memories, holographic memories, or chemical memories. For example, the computer platform (600) may include three-dimensional (3D) XPOINT memories from Intel® and Micron®.

[0126] The removable memory circuit section (623) may include devices, circuit sections, enclosures / housings, ports, or receptacles, etc., used to couple portable data storage devices to the platform (600). These portable data storage devices may be used for mass storage purposes and may include, for example, flash memory cards (e.g., SD cards, microSD cards, xD picture cards, etc.), and USB flash drives, optical discs, external HDDs, etc.

[0127] The platform (600) may also include an interface circuit (not shown) used to connect external devices to the platform (600). External devices connected to the platform (600) through the interface circuit include a sensor circuit (621) and electro-mechanical components (622), as well as removable memory devices coupled to a removable memory circuit (623).

[0128] The sensor circuit section (621) includes devices, modules, or subsystems intended to detect events or changes in its environment and transmit information (sensor data) regarding the detected events to some other device, module, subsystem, etc. Examples of such sensors include, in particular, inertia measurement units (IMUs) including accelerometers, gyroscopes, and / or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes, and / or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless apertures); light detection and ranging (LIDAR) sensors; proximity sensors (e.g., infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; Microphones or other similar audio capture devices; etc.

[0129] EMCs (622) include devices, modules, or subsystems intended to enable the platform (600) to change its state, position, and / or orientation, or to move or control a mechanism or (sub)system. Additionally, EMCs (622) may be configured to generate messages / signaling to indicate the current state of the EMCs (622) and transmit them to other components of the platform (600). Examples of EMCs (622) include one or more power switches, relays including electromechanical relays (EMRs) and / or solid state relays (SSRs), actuators (e.g., valve actuators, etc.), audible sound generators, visual warning devices, motors (e.g., DC motors, stepper motors, etc.), wheels, thrusters, propellers, claws, clamps, hooks, and / or other similar electromechanical components. In embodiments, the platform (600) is configured to operate one or more EMCs (622) based on one or more captured events and / or commands or control signals received from service providers and / or various clients.

[0130] In some embodiments, the interface circuit may connect the platform (600) to the positioning circuit (645). The positioning circuit (645) includes a circuit for receiving and decoding signals transmitted / broadcast by a positioning network of GNSS. Examples of navigation satellite constellations (or GNSS) include the US GPS, Russia's GLONASS, the European Union's Galileo system, China's Beidou navigation satellite system, a regional navigation system, or a GNSS augmentation system (e.g., NAVIC, Japan's QZSS, France's DORIS, etc.). The positioning circuit (645) includes various hardware elements (e.g., hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate OTA communications) to communicate with components of the positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuit (645) may include a micro-PNT IC that uses a master timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit (645) may also be part of or interact with the baseband circuit (510) and / or RFEMs (615) to communicate with nodes and components of the positioning network. The positioning circuit (645) may also provide position data and / or time data to the application circuit (605), which can use the data to synchronize operations with various infrastructures (e.g., radio base stations) for turn-by-turn navigation applications, etc.

[0131] In some embodiments, the interface circuit may connect the platform (600) to the NFC (Near-Field Communication) circuit (640). The NFC circuit (640) is configured to provide contactless short-range communications based on RFID (radio frequency identification) standards, wherein magnetic field induction is used to enable communication between the NFC circuit (640) and NFC-enabled devices (e.g., "NFC touchpoints") outside the platform (600). The NFC circuit (640) includes an NFC controller coupled with an antenna element and a processor coupled with the NFC controller. The NFC controller may be a chip / IC that provides NFC functions to the NFC circuit (640) by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to emit near-field RF signals. RF signals can power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transmit stored data to the NFC circuit (640) or to initiate data transmission between the NFC circuit (640) and another active NFC device (e.g., a smartphone or an NFC-enabled POS terminal) located near the platform (600).

[0132] The driver circuit section (646) may include software and hardware elements that operate to control specific devices that are embedded within the platform (600), connected to the platform (600), or otherwise coupled to the platform (600) for communication. The driver circuit section (646) may include individual drivers that allow other components of the platform (600) to interact with or control various input / output (I / O) devices that may exist within the platform (600) or be connected thereto. For example, the driver circuit section (646) may include a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface of the platform (600), sensor drivers for acquiring sensor readings of the sensor circuit section (621) and controlling and allowing access to the sensor circuit section (621), EMC drivers for acquiring actuator positions of EMCs (622) and / or controlling and allowing access to the EMCs (622), a camera driver for controlling and allowing access to an embedded image capture device, and audio drivers for controlling and allowing access to one or more audio devices.

[0133] A power management integrated circuit (PMIC) (625) (also referred to as "power management circuit (625)") can manage power supplied to various components of the platform (600). In particular, with respect to the baseband circuit (610), the PMIC (625) can control power selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMIC (625) may often be included when the platform (600) can be powered by a battery (630), for example, when the device is included in the UE (201, 202, 301).

[0134] In some embodiments, the PMIC (625) may control various power saving mechanisms of the platform (600) or, alternatively, be part of them. For example, if the platform (600) is in the RRC_Connected state, which is still connected to a RAN node as it expects the device to receive traffic soon, the device may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the platform (600) may be powered off for short time intervals and thus power-saving. If there is no data traffic activity for an extended period, the platform (600) may transition to the RRC_Idle state, in which the device is disconnected from the network and does not perform operations such as channel quality feedback, handover, etc. The platform (600) enters a very low power state and performs paging, in which the device periodically wakes up to listen to the network again and then powers down again. The platform (600) may not receive data in this state; to receive data, it must transition back to the RRC_Connected state. An additional power saving mode may allow the device to be unavailable to the network for periods longer than the paging interval (ranging from a few seconds to several hours). During this time, the device may be completely unreachable to the network and completely powered off. Any data transmitted during this time will cause a large delay, and it is assumed that the delay is acceptable.

[0135] The battery (630) can supply power to the platform (600), but in some examples, the platform (600) may be mounted in a fixed position and may have a power source coupled to an electric grid. The battery (630) may be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some embodiments, such as in V2X applications, the battery (630) may be a typical lead-acid automotive battery.

[0136] In some embodiments, the battery (630) may be a "smart battery" that includes or is coupled with a Battery Management System (BMS) or a battery monitoring integrated circuit. The BMS may be included within the platform (600) to track the state of charge (SoCh) of the battery (630). The BMS may be used to monitor other parameters of the battery (630) to provide failure predictions, such as the state of health (SoH) and state of function (SoF) of the battery (630). The BMS may transmit information about the battery (630) to the application circuit (605) or other components of the platform (600). The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit (605) to directly monitor the voltage of the battery (630) or the current flow from the battery (630). Battery parameters such as transmission frequency, network operation, and detection frequency can be used to determine the actions that the platform (600) can perform.

[0137] A power block (625), or another power source coupled to the electric grid, can be coupled to the BMS to charge the battery (630). In some examples, the power block (625) may be replaced with a wireless power receiver to obtain power wirelessly, for example, through a loop antenna within the computer platform (600). In these examples, a wireless battery charging circuit may be included in the BMS. The specific charging circuits selected may depend on the size of the battery (630) and the current required accordingly. Charging may be performed using, among other things, the Airfuel standard published by the Airfuel Alliance, the Qi wireless charging standard published by the Wireless Power Consortium, or the Rezence charging standard published by the Wireless Power Alliance.

[0138] The user interface circuit section (650) includes various input / output (I / O) devices present within or connected to the platform (600) and includes one or more user interfaces designed to enable user interaction with the platform (600) and / or peripheral component interfaces designed to enable interaction with the platform (600). The user interface circuit section (650) includes an input device circuit section and an output device circuit section. The input device circuit section includes any physical or virtual means for receiving input, in particular, including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, microphones, a scanner, a headset, etc. The output device circuit section includes any physical or virtual means for displaying information, such as sensor readings, actuator position(s), or other similar information, or otherwise conveying information. The output device circuit may include any number of audio or visual displays and / or combinations thereof, particularly including one or more simple visual outputs / indicators (e.g., binary state indicators (e.g., LEDs)) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (e.g., Liquid Crystal Displays (LCDs), LED displays, quantum dot displays, projectors, etc.), wherein the outputs, such as characters, graphics, multimedia objects, etc., are generated or produced from the operation of the platform (600). The output device circuit may also include speakers or other audio emitting devices, printer(s), etc.In some embodiments, the sensor circuit (621) may be used as an input device circuit (e.g., an image capture device, a motion capture device, etc.), and one or more EMCs may be used as an output device circuit (e.g., an actuator for providing haptic feedback). In other examples, an NFC circuit comprising an NFC controller and a processing device coupled with an antenna element may be included to read electronic tags and / or connect with other NFC-enabled devices. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power supply interface, etc.

[0139] Although not illustrated, components of the platform (600) may communicate with each other using a suitable bus or interconnect (IX) technology that may include any number of technologies, such as ISA, EISA, PCI, PCIx, PCIe, Time-Trigger Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus / IX may be, for example, a proprietary bus / IX used in an SoC-based system. Other bus / IX systems, such as, among others, I 2 C interface, SPI interface, point-to-point interfaces, and power bus may be included.

[0140] FIG. 7 illustrates exemplary components of a baseband circuit (710) and a wireless front-end module (RFEM) (715) according to various embodiments. The baseband circuit (710) corresponds to the baseband circuits (510, 610) of FIG. 5 and FIG. 6, respectively. The RFEM (715) corresponds to the RFEMs (515, 615) of FIG. 5 and FIG. 6, respectively. As illustrated, the RFEMs (715) may include at least a Radio Frequency (RF) circuit (706), a Front-End Module (FEM) circuit (708), and an antenna array (711) coupled together as illustrated.

[0141] The baseband circuit (710) includes circuits and / or control logic configured to perform various wireless / network protocols and wireless control functions that enable communication with one or more wireless networks through the RF circuit (706). Wireless control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, and wireless frequency shifting. In some embodiments, the modulation / demodulation circuit of the baseband circuit (710) may include Fast-Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuit of the baseband circuit (710) may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder / decoder functions. Embodiments of modulation / demodulation and encoder / decoder functions are not limited to these examples and may include other suitable functions in other embodiments. The baseband circuit (710) is configured to process baseband signals received from the receiving signal path of the RF circuit (706) and to generate baseband signals for the transmitting signal path of the RF circuit (706). The baseband circuit (710) is configured to interface with the application circuit (505 / 605) (see FIG. 5 and FIG. 6) for generating and processing baseband signals and for controlling the operations of the RF circuit (706). The baseband circuit (710) can handle various wireless control functions.

[0142] The control logic of the circuit section and / or baseband circuit section (710) described above may include one or more single or multi-core processors. For example, one or more processors may include a 3G baseband processor (704A), a 4G / LTE baseband processor (704B), a 5G / NR baseband processor (704C), or some other baseband processor(s) (704D) for other existing generations, generations under development or to be developed in the future (e.g., 6G, etc.). In other embodiments, some or all of the functions of the baseband processors (704A to 704D) may be included in modules that are stored in memory (704G) and executed through a central processing unit (CPU) (704E). In other embodiments, some or all of the functions of the baseband processors (704A to 704D) may be provided as hardware accelerators (e.g., FPGAs, ASICs, etc.) loaded with appropriate bit streams or logic blocks stored in their respective memory cells. In various embodiments, the memory (704G) may store program code of a real-time OS (RTOS), which, when executed by the CPU (704E) (or other baseband processor), enables the CPU (704E) (or other baseband processor) to manage the resources of the baseband circuit (710), schedule tasks, etc.Examples of RTOS may include OSE™ (Operating System Embedded) provided by Enea®, Nucleus RTOS™ provided by Mentor Graphics®, VRTX (Versatile Real-Time Executive) provided by Mentor Graphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OS provided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or any other suitable RTOS such as those discussed herein. Additionally, the baseband circuit (710) includes one or more audio digital signal processor(s) (DSP) (704F). The audio DSP(s) (704F) include elements for compression / decompression and echo removal, and may include other suitable processing elements in other embodiments.

[0143] In some embodiments, each of the processors (704A to 704E) includes its own memory interfaces for transmitting / receiving data to / from memory (704G). The baseband circuit (710) may further include one or more interfaces for communicatingly coupling to other circuits / devices, such as an interface for transmitting / receiving data to / from memory outside the baseband circuit (710); an application circuit interface for transmitting / receiving data to / from the application circuit (505 / 605) of FIG. 5 and FIG. XT; an RF circuit interface for transmitting / receiving data to / from the RF circuit (706) of FIG. 7; a wireless hardware connection interface for transmitting / receiving data to / from one or more wireless hardware elements (e.g., NFC components, Bluetooth® / low-power Bluetooth® components, Wi-Fi® components, etc.); and a power management interface for transmitting / receiving power or control signals to / from the PMIC (625).

[0144] In alternative embodiments (which may be combined with the embodiments described above), the baseband circuit section (710) comprises one or more digital baseband systems, which are coupled to each other and to the CPU subsystem, audio subsystem, and interface subsystem through an interconnection subsystem. The digital baseband subsystems may also be coupled to the digital baseband interface and the mixed-signal baseband subsystem through other interconnection subsystems. Each of the interconnection subsystems may include some other suitable bus or interconnection technology, such as a bus system, point-to-point connections, network-on-chip (NOC) structures, and / or those discussed herein. The audio subsystem may include a DSP circuit section, buffer memory, program memory, speech processing accelerator circuit section, data converter circuit section such as analog-to-digital and digital-to-analog converter circuit sections, an analog circuit section including one or more of amplifiers and filters, and / or other similar components. In one aspect of the present disclosure, the baseband circuit (710) may include a protocol processing circuit having one or more instances of a control circuit (not shown) to provide control functions for a digital baseband circuit and / or a radio frequency circuit (e.g., radio front-end modules (715)).

[0145] Although not illustrated in FIG. 7, in some embodiments, the baseband circuit (710) includes one or more wireless communication protocols (e.g., a "multiprotocol baseband processor" or a "protocol processing circuit") and individual processing device(s) that operate individual processing device(s) to implement PHY layer functions. In these embodiments, the PHY layer functions include the aforementioned wireless control functions. In these embodiments, the protocol processing circuit operates or implements various protocol layers / entities of one or more wireless communication protocols. In the first example, the protocol processing circuit may operate LTE protocol entities and / or 5G / NR protocol entities if the baseband circuit (710) and / or RF circuit (706) is part of a mmWave communication circuit or some other suitable cellular communication circuit. In the first example, the protocol processing circuit will operate MAC, RLC, PDCP, SDAP, RRC, and NAS functions. In the second example, the protocol processing circuit may operate one or more IEEE-based protocols if the baseband circuit (710) and / or RF circuit (706) are part of a Wi-Fi communication system. In the second example, the protocol processing circuit will operate Wi-Fi MAC and LLC (logical link control) functions. The protocol processing circuit may include one or more memory structures (e.g., 704G) for storing program code and data for operating protocol functions, as well as one or more processing cores for executing program code and performing various operations using data. The baseband circuit (710) may also support wireless communications for more than one wireless protocol.

[0146] Various hardware elements of the baseband circuit (710) discussed in this specification may be implemented, for example, as a solder-down substrate containing one or more integrated circuits (ICs), a single packaged IC soldered to a main circuit board, or a multi-chip module containing two or more ICs. In one example, the components of the baseband circuit (710) may be suitably combined on a single chip or chipset, or placed on the same circuit board. In another example, some or all of the constituent components of the baseband circuit (710) and the RF circuit (706) may be implemented together, for example, as an SoC or a System-in-Package (SiP). In another example, some or all of the constituent components of the baseband circuit (710) may be implemented as a separate SoC coupled to the RF circuit (706) (or multiple instances of the RF circuit (706)). In another example, some or all of the components of the baseband circuit (710) and the application circuit (505 / 605) may be implemented together as individual SoCs mounted on the same circuit board (e.g., "multichip package").

[0147] In some embodiments, the baseband circuit (710) may provide communication compatible with one or more wireless technologies. For example, in some embodiments, the baseband circuit (710) may support communication with an E-UTRAN or other WMAN, WLAN, or WPAN. Embodiments in which the baseband circuit (710) is configured to support wireless communication of more than one wireless protocol may be referred to as a multimode baseband circuit.

[0148] The RF circuit section (706) can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuit section (706) may include switches, filters, amplifiers, etc. to facilitate communication with wireless networks. The RF circuit section (706) may include a receiving signal path that may include a circuit section for down-converting RF signals received from the FEM circuit section (708) and providing baseband signals to the baseband circuit section (710). The RF circuit section (706) may also include a transmitting signal path that may include a circuit section for up-converting baseband signals provided by the baseband circuit section (710) and providing RF output signals to the FEM circuit section (708) for transmission.

[0149] In some embodiments, the receiving signal path of the RF circuit (706) may include a mixer circuitry (706a), an amplifier circuitry (706b), and a filter circuitry (706c). In some embodiments, the transmitting signal path of the RF circuit (706) may include a filter circuitry (706c) and a mixer circuitry (706a). The RF circuit (706) may also include a synthesizer circuitry (706d) for synthesizing frequencies for use by the mixer circuitry (706a) of the receiving signal path and the transmitting signal path. In some embodiments, the mixer circuitry (706a) of the receiving signal path may be configured to down-convert RF signals received from the FEM circuitry (708) based on the synthesized frequencies provided by the synthesizer circuitry (706d). The amplifier circuit (706b) may be configured to amplify the down-converted signals, and the filter circuit (706c) may be a low-pass filter (LPF) or bandpass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. The output baseband signals may be provided to the baseband circuit (710) for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, but this is not a requirement. In some embodiments, the mixer circuit (706a) of the receiving signal path may include passive mixers, but the scope of embodiments is not limited in this respect.

[0150] In some embodiments, the mixer circuit (706a) of the transmission signal path may be configured to upconvert input baseband signals based on a synthesized frequency provided by the synthesizer circuit (706d) to generate RF output signals for the FEM circuit (708). The baseband signals may be provided by the baseband circuit (710) and may be filtered by the filter circuit (706c).

[0151] In some embodiments, the mixer circuit section (706a) of the receiving signal path and the mixer circuit section (706a) of the transmitting signal path may include two or more mixers and may be arranged for orthogonal down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit section (706a) of the receiving signal path and the mixer circuit section (706a) of the transmitting signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit section (706a) of the receiving signal path and the mixer circuit section (706a) of the transmitting signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, the mixer circuit section (706a) of the receiving signal path and the mixer circuit section (706a) of the transmitting signal path may be configured for super-heterodyne operation.

[0152] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, but the scope of embodiments is not limited in this respect. In some alternative embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternative embodiments, the RF circuit (706) may include an ADC and a digital-to-analog converter (DAC) circuit, and the baseband circuit (710) may include a digital baseband interface for communicating with the RF circuit (706).

[0153] In some dual-mode embodiments, individual radio IC circuits may be provided to process signals for each spectrum, but the scope of embodiments is not limited in this respect.

[0154] In some embodiments, the synthesizer circuit (706d) may be a fractional-N synthesizer or a fractional N / N+1 synthesizer, but the scope of embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, the synthesizer circuit (706d) may be a synthesizer comprising a delta-sigma synthesizer, a frequency multiplier, or a phase-locked loop having a frequency divider.

[0155] The synthesizer circuit section (706d) may be configured to synthesize an output frequency for use by the mixer circuit section (706a) of the RF circuit section (706) based on frequency input and divider control input. In some embodiments, the synthesizer circuit section (706d) may be a fractional N / N+1 synthesizer.

[0156] In some embodiments, the frequency input may be provided by a voltage-controlled oscillator (VCO), but this is not a requirement. The divider control input may be provided by either the baseband circuit (710) or the application circuit (505 / 605) depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on a channel indicated by the application circuit (505 / 605).

[0157] The synthesizer circuit (706d) of the RF circuit (706) may include a divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on carry-out) to provide a fractional division ratio. In some exemplary embodiments, the DLL may include a set of cascaded and tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to divide the VCO cycle 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.

[0158] In some embodiments, the synthesizer circuit (706d) may be configured to generate a carrier frequency as an output frequency, whereas 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 may be used in conjunction with an orthogonal generator and a divider circuit to generate multiple signals at the carrier frequency having multiple different phases relative to each other. In some embodiments, the output frequency may be an LO frequency (fLO). In some embodiments, the RF circuit (706) may include an IQ / polar converter.

[0159] The FEM circuit section (708) may include a receiving signal path, which may include a circuit section configured to operate on RF signals received from the antenna array (711), amplify the received signals, and provide amplified versions of the received signals to the RF circuit section (706) for further processing. The FEM circuit section (708) may also include a transmitting signal path, which may include a circuit section configured to amplify signals for transmission provided by the RF circuit section (706) for transmission by one or more of the antenna elements of the antenna array (711). In various embodiments, amplification through the transmitting or receiving signal paths may be performed only in the RF circuit section (706), only in the FEM circuit section (708), or in both the RF circuit section (706) and the FEM circuit section (708).

[0160] In some embodiments, the FEM circuit section (708) may include a TX / RX switch for switching between a transmit mode and a receive mode operation. The FEM circuit section (708) may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit section (708) may include an LNA for amplifying received RF signals and providing the amplified received RF signals as outputs (e.g., to the RF circuit section (706)). The transmit signal path of the FEM circuit section (708) may include a power amplifier (PA) for amplifying input RF signals (e.g., provided by the RF circuit section (706)) and one or more filters for generating RF signals for subsequent transmission by one or more antenna elements of the antenna array (711).

[0161] The antenna array (711) comprises one or more antenna elements, each configured to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. For example, digital baseband signals provided by the baseband circuit (710) are converted into analog RF signals (e.g., modulated waveforms) to be amplified and transmitted through the antenna elements of the antenna array (711) 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 plurality of arrays as known and / or discussed herein. The antenna array (711) may include microstrip antennas or printed antennas manufactured on the surface of one or more printed circuit boards. The antenna array (711) can be formed as a patch of metal foil (e.g., a patch antenna) in various shapes and can be coupled with the RF circuit (706) and / or FEM circuit (708) using metal transmission lines, etc.

[0162] Processors of the application circuit (505 / 605) and processors of the baseband circuit (710) may be used to execute elements of one or more instances of the protocol stack. For example, processors of the baseband circuit (710) may be used, either alone or in combination, to execute Layer 3, Layer 2, or Layer 1 functions, while processors of the application circuit (505 / 605) may utilize data (e.g., packet data) received from these layers and additionally execute Layer 4 (e.g., TCP and UDP layers) functions. As mentioned herein, Layer 3 may include an RRC layer, which is described in more detail below. As mentioned herein, Layer 2 may include a MAC layer, an RLC layer, and a PDCP layer, which are described in more detail below. As mentioned herein, Layer 1 may include a PHY layer of a UE / RAN node, which is described in more detail below.

[0163] FIG. 8 illustrates various protocol functions that can be implemented in a wireless communication device according to various embodiments. In particular, FIG. 8 includes an array (800) showing interconnections between various protocol layers / entities. The following description of FIG. 8 is provided for various protocol layers / entities operating in relation to 5G / NR system standards and LTE system standards, but some or all of FIG. 8 may be applicable to other wireless communication network systems.

[0164] The protocol layers of the array (800) may include one or more of PHY (810), MAC (820), RLC (830), PDCP (840), SDAP (847), RRC (855), and NAS layers (857), in addition to other higher layer functions not exemplified. The protocol layers may include one or more service access points capable of providing communication between two or more protocol layers (e.g., items of FIG. 8 (859, 856, 850, 849, 845, 835, 825, 815)).

[0165] The PHY (810) can transmit and receive physical layer signals (805) that may be received from or transmitted to one or more other communication devices. The physical layer signals (805) may include one or more physical channels such as those discussed herein. The PHY (810) may further perform other measurements used by higher layers, such as link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and RRC (855). The PHY (810) may also further perform error detection for transmission channels, forward error correction (FEC) coding / decoding of transmission channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping of physical channels, and MIMO antenna processing. In embodiments, an instance of PHY (810) may process requests from an instance of MAC (820) and provide instructions to an instance of MAC through one or more PHY-SAPs (815). According to some embodiments, requests and instructions communicated through the PHY-SAP (815) may include one or more transmission channels.

[0166] Instance(s) of MAC (820) can process requests from instances of RLC (830) and provide instructions to instances of RLC through one or more MAC-SAPs (825). These requests and instructions communicated through MAC-SAPs (825) may include one or more logic channels. MAC (820) can perform mapping between logic channels and transport channels, multiplexing MAC SDUs from one or more logic channels onto TBs to be delivered to PHY (810) via transport channels, demultiplexing MAC SDUs from TBs delivered from PHY (810) via transport channels onto one or more logic channels, multiplexing MAC SDUs onto TBs, reporting scheduling information, error correction via HARQ, and logic channel prioritization.

[0167] Instance(s) of RLC (830) can process requests from instances of PDCP (840) and provide instructions to instances of PDCP (840) through one or more RLC-SAP (radio link control service access points) (835). These requests and instructions communicated through RLC-SAP (835) may include one or more RLC channels. RLC (830) can operate in multiple modes of operation, including Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC (830) can perform transmission of upper-layer PDUs, error correction via automatic repeat request (ARQ) for AM data transmissions, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmissions. RLC (830) can also perform re-segmentation of RLC data PDUs for AM data transmissions, reorder RLC data PDUs for UM and AM data transmissions, detect duplicate data for UM and AM data transmissions, discard RLC SDUs for UM and AM data transmissions, detect protocol errors for AM data transmissions, and perform RLC re-establishment.

[0168] Instance(s) of PDCP (840) can process requests from instance(s) of SDAP (847) and / or instance(s) of RRC (855) and provide instructions to instance(s) of SDAP (847) and / or instance(s) of RRC (855) via one or more PDCP-SAP (packet data convergence protocol service access points) (845). These requests and instructions communicated via PDCP-SAP (845) may include one or more wireless bearers. PDCP (840) can perform header compression and decompression of IP data, maintain PDCP sequence numbers (SN), perform sequential delivery of upper layer PDUs in lower layer re-establishment, remove duplicates of lower layer SDUs in lower layer re-establishment for wireless bearers mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discarding of data, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0169] Instance(s) of SDAP (847) can process requests from one or more higher-tier protocol entities and provide instructions to one or more higher-tier protocol entities through one or more SDAP-SAPs (849). These requests and instructions communicated through SDAP-SAPs (849) may include one or more QoS flows. SDAP (847) can map QoS flows to DRBs and vice versa, and can also mark QFIs within DL and UL packets. A single SDAP entity (847) can be configured for individual PDU sessions. In the UL direction, NG-RAN (210) can control the mapping of QoS flows to DRB(s) in two different ways, namely reflective mapping or explicit mapping. In the case of reflection mapping, the SDAP (847) of the UE (201) can monitor the QFIs of DL packets for each DRB and apply the same mapping to packets flowing toward the UL. In the case of a DRB, the SDAP (847) of the UE (201) can map the PDU sessions observed in UL packets belonging to QoS flow(s) corresponding to QoS flow ID(s) and DL packets for that DRB. To enable reflection mapping, the NG-RAN (410) can mark DL packets with QoS flow IDs through the Uu interface. Explicit mapping may involve the RRC (855) configuring the SDAP (847) with an explicit QoS flow for the DRB mapping rule, and the DRB mapping rule may be stored and adhered to by the SDAP (847). In the embodiments, SDAP (847) may be used only in NR implementations and may not be used in LTE implementations.

[0170] RRC (855) may configure suns of one or more protocol layers that may include one or more instances of PHY (810), MAC (820), RLC (830), PDCP (840), and SDAP (847) through one or more M-SAPs (management service access points). In embodiments, an instance of RRC (855) may process requests from one or more NAS entities (857) and provide instructions to one or more NAS entities (857) through one or more RRC-SAPs (856). The main services and functions of the RRC (855) may include broadcasting of system information (e.g., included in SIBs or MIBs related to NAS), broadcasting of system information related to the access stratum (AS), paging, establishment, maintenance, and release of RRC connections between the UE (201) and the RAN (210) (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), security functions including the establishment, configuration, maintenance, and release of point-to-point wireless bearers, key management, inter-RAT mobility, and measurement configuration for UE measurement reporting. The MIBs and SIBs may include one or more IEs, each of which may include individual data fields or data structures.

[0171] The NAS (857) can form the highest layer of the control plane between the UE (201) and the AMF (421). The NAS (857) can support the mobility of the UEs (201) and session management procedures for establishing and maintaining IP connectivity between the P-GW and the UE (201) within LTE systems.

[0172] According to various embodiments, one or more protocol entities of the array (800) may be implemented in UEs (201), RAN nodes (211), AMF (421) in NR implementations, or MME (321) in LTE implementations, UPF (402) in NR implementations, or S-GW (322) and P-GW (323) in LTE implementations, etc., to be used in a control plane or user plane communication protocol stack between the aforementioned devices. In such embodiments, one or more protocol entities that may be implemented in one or more of the UE (201), gNB (211), AMF (421), etc., may communicate with their respective peer protocol entities that may be implemented on or within other devices by using the services of their respective lower layer protocol entities to perform such communication. In some embodiments, the gNB-CU of the gNB (211) may host the gNB's RRC (855), SDAP (847), and PDCP (840) which control the operation of one or more gNB-DUs, and the gNB-DUs of the gNB (211) may each host the gNB's RLC (830), MAC (820), and PHY (810).

[0173] In the first example, the control plane protocol stack may include NAS (857), RRC (855), PDCP (840), RLC (830), MAC (820), and PHY (810) in order from the highest layer to the lowest layer. In this example, upper layers (860), including IP layer (861), SCTP (862), and application layer signaling protocol (AP) (863), may be built on top of NAS (857).

[0174] In NR implementation examples, the AP (863) may be an NG application protocol layer (NGAP or NG-AP) (863) for an NG interface (213) defined between an NG-RAN node (211) and an AMF (421), or the AP (863) may be an Xn application protocol layer (XnAP or Xn-AP) (863) for an Xn interface (212) defined between two or more RAN nodes (211).

[0175] The NG-AP (863) can support the functions of the NG interface (213) and may include Elementary Procedures (EPs). The NG-AP EP may be a unit of interaction between the NG-RAN node (211) and the AMF (421). The NG-AP (863) services may include two groups: UE-associated services (e.g., services related to the UE (201, 202)) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN node (211) and the AMF (421)).These services include: a paging function for transmitting paging requests to NG-RAN nodes (211) associated with a specific paging area; a UE context management function for allowing the AMF (421) to establish, modify, and / or release the UE context within the AMF (421) and the NG-RAN node (211); a mobility function for UEs (201) in ECM-CONNECTED mode for intra-system HOs to support mobility within the NG-RAN and inter-system HOs to support mobility from / to EPS systems; a NAS signaling transmission function for transmitting or rerouting NAS messages between the UE (201) and the AMF (421); a NAS node selection function for determining the association between the AMF (421) and the UE (201); and NG interface management function(s) for setting up the NG interface and monitoring errors through the NG interface; It may include a warning message transmission function for providing means to transmit warning messages through an NG interface or to cancel an ongoing broadcast of warning messages; a configuration transmission function for requesting and transmitting RAN configuration information (e.g., SON information, performance measurement (PM) data, etc.) between two RAN nodes (211) through a CN (220); and / or other similar functions, but not limited thereto.

[0176] XnAP (863) can support the functions of the Xn interface (212) and may include XnAP-based mobility procedures and XnAP global procedures. XnAP-based mobility procedures may include procedures used to handle UE mobility within the NG RAN (211) (or E-UTRAN (310)), such as handover preparation and cancellation procedures, SN state transfer procedures, UE context search and UE context release procedures, RAN paging procedures, duplex access related procedures, etc. XnAP global procedures may include procedures not related to a specific UE (201), such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, etc.

[0177] In LTE implementations, the AP (863) may be an S1 Application Protocol layer (S1-AP) (863) for an S1 interface (213) defined between an E-UTRAN node (211) and an MME, or the AP (863) may be an X2 Application Protocol layer (X2AP or X2-AP) (863) for an X2 interface (212) defined between two or more E-UTRAN nodes (211).

[0178] The S1 Application Protocol Layer (S1-AP) (863) can support the functions of the S1 interface, and similar to the NG-AP discussed previously, the S1-AP may include S1-AP EPs. The S1-AP EP may be a unit of interaction between the MME (321) and the E-UTRAN node (211) within the LTE CN (220). The S1-AP (863) services 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 transmission, RAN Information Management (RIM), and configuration transmission.

[0179] X2AP (863) can support the functions of the X2 interface (212) and may include X2AP-based mobility procedures and X2AP global procedures. X2AP-based mobility procedures may include procedures used to handle UE mobility within the E-UTRAN (220), such as handover preparation and cancellation procedures, SN status transmission procedures, UE context search and UE context release procedures, RAN paging procedures, duplex connection related procedures, etc. X2AP global procedures may include procedures not related to a specific UE (201), such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, etc.

[0180] The SCTP layer (alternatively referred to as the SCTP / IP layer) (862) 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). The SCTP (862) can guarantee reliable delivery of signaling messages between the RAN node (211) and the AMF (421) / MME (321) based in part on the IP protocol supported by the IP (861). The Internet Protocol (IP) layer (861) can be used to perform packet addressing and routing functions. In some implementations, the IP layer (861) may use point-to-point transmission to deliver and carry PDUs. In this regard, the RAN node (211) may include L2 and L1 layer communication links (e.g., wired or wireless) with the MME / AMF to exchange information.

[0181] In the second example, the user plane protocol stack may include SDAP (847), PDCP (840), RLC (830), MAC (820), and PHY (810) in order from the highest layer to the lowest layer. The user plane protocol stack may be used for communication between the UE (201), RAN node (211), and UPF (402) in NR implementations, or between the S-GW (322) and P-GW (323) in LTE implementations. In this example, the upper layers (851) may be built on top of the SDAP (847) and may include a User Datagram Protocol (UDP) and IP Security Layer (UDP / IP) (852), a General Packet Radio Service (GPRS) tunneling protocol layer (GTP-U) for the user plane (853), and a user plane PDU layer (UP PDU) (863).

[0182] The transport network layer (854) (also referred to as the "transport layer") can be built over IP transport, and GTP-U (853) can be used on top of the UDP / IP layer (852) (including the UDP layer and the IP layer) to deliver user plane PDUs (UP-PDUs). The IP layer (also referred to as the "Internet layer") can be used to perform packet addressing and routing functions. The IP layer can assign IP addresses to user data packets of any of the IPv4, IPv6, or PPP formats, for example.

[0183] GTP-U (853) can be used to transmit user data within the GPRS core network and between the wireless access network and the core network. The user data being transmitted may be packets of any of the formats, for example, IPv4, IPv6, or PPP. UDP / IP (852) may provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data streams. The RAN node (211) and S-GW (322) may utilize the S1-U interface to exchange user plane data through a protocol stack including an L1 layer (e.g., PHY (810)), an L2 layer (e.g., MAC (820), RLC (830), PDCP (840), and / or SDAP (847)), a UDP / IP layer (852), and a GTP-U layer (853). The S-GW (322) and P-GW (323) can utilize the S5 / S8a interface to exchange user plane data through a protocol stack including the L1 layer, L2 layer, UDP / IP layer (852), and GTP-U layer (853). As previously discussed, NAS protocols can support the mobility of the UE (201) and session management procedures to establish and maintain IP connectivity between the UE (201) and the P-GW (323).

[0184] Additionally, although not illustrated in FIG. 8, an application layer may exist above the AP (863) and / or the transport network layer (854). The application layer may be a layer where users of the UE (201), RAN node (211), or other network elements interact with software applications running, for example, by the application circuit (505) or the application circuit (605), respectively. The application layer may also provide one or more interfaces for software applications to interact with communication systems of the UE (201) or RAN node (211), such as the baseband circuit (710). In some embodiments, the IP layer and / or the application layer may provide functions identical or similar to layers 5 through 7 of the OSI (Open Systems Interconnection) model (e.g., OSI layer 7 - application layer, OSI layer 6 - presentation layer, and OSI layer 5 - session layer) or parts thereof.

[0185] FIG. 9 illustrates components of a core network according to various embodiments. Components of CN (320) may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transient machine-readable storage medium). In embodiments, components of CN (420) may be implemented in the same or similar manner as described herein in relation to the components of CN (320). In some embodiments, NFV is utilized to virtualize any or all of the aforementioned network node functions through executable instructions stored in one or more computer-readable storage media (described further in detail below). A logic instantiation of CN (320) may be referred to as a network slice (901), and individual logic instantiations of CN (320) may provide specific network capabilities and network characteristics. A portion of the logic instantiation of CN (320) may be referred to as a network subslice (902) (e.g., the network subslice (902) is shown to include P-GW (323) and PCRF (326)).

[0186] As used herein, the terms “instantiate,” “instantiation,” and similar terms may refer to the creation of an instance, and “instance” may refer to the specific occurrence of an object, which may occur, for example, during the execution of program code. A network instance may refer to information identifying a domain, which may be used for traffic detection and routing in the case of different IP domains or overlapping IP addresses. A network slice instance may refer to a set of network function (NF) instances and resources (e.g., compute, storage, and networking resources) required to deploy a network slice.

[0187] In relation to 5G systems (e.g., see FIG. 4), a network slice always includes a RAN portion and a CN portion. Support for network slicing relies on the principle that traffic for different slices is handled by different PDU sessions. The network can realize different network slices by scheduling and also by providing different L1 / L2 configurations. The UE (401) provides auxiliary information for selecting a network slice within an appropriate RRC message, if provided by the NAS. Although the network can support multiple slices, the UE does not need to support more than eight slices simultaneously.

[0188] A network slice may include CN (420) control planes and user plane NFs, NG-RANs (410) within a serving PLMN, and N3IWF functions within a serving PLMN. Individual network slices may have different S-NSSAIs and / or different SSTs. An NSSAI includes one or more S-NSSAIs, and each network slice is uniquely identified by an S-NSSAI. Network slices may differ for the optimization of supported features and network functions, and / or multiple network slice instances may deliver the same service / feature unless they are different groups of UEs (401) (e.g., enterprise users). For example, individual network slices may deliver different committed service(s) or be dedicated to a specific customer or enterprise. In this example, each network slice may have different S-NSSAIs that have the same SST but different slice differentiators. Additionally, a single UE can be served to one or more network slice instances simultaneously via a 5G AN and can be associated with eight different S-NSSAIs. Furthermore, the AMF (421) instance serving an individual UE (401) can belong to each of the network slice instances serving such UE.

[0189] Network slicing in NG-RAN (410) involves RAN slice awareness. RAN slice awareness involves the differential handling of traffic for different network slices that are pre-configured. Slice awareness in NG-RAN (410) is introduced at the PDU session level by indicating the S-NSSAI corresponding to the PDU session in all signaling containing PDU session resource information. How NG-RAN (410) supports slice enabling in terms of NG-RAN functions (e.g., a set of network functions including each slice) is implementation-dependent. NG-RAN (410) selects the RAN portion of a network slice using auxiliary information provided by the UE (401) or 5GC (420), which clearly identifies one or more of the pre-configured network slices within the PLMN. Additionally, NG-RAN (410) supports resource management and policy enforcement between slices according to SLAs. A single NG-RAN node can support multiple slices, and the NG-RAN (410) can also apply an appropriate RRM policy to an appropriate SLA for each supported slice. The NG-RAN (410) can also support QoS differentiation within a slice.

[0190] Additionally, the NG-RAN (410) may use UE auxiliary information to select an AMF (421) during the initial attachment, if available. The NG-RAN (410) uses auxiliary information to route the initial NAS to the AMF (421). If the NG-RAN (410) cannot select an AMF (421) using auxiliary information, or if the UE (401) does not provide any such information, the NG-RAN (410) sends NAS signaling to a default AMF (421), which may be in a pool of AMFs (421). For subsequent accesses, the UE (401) provides a temporary ID assigned to the UE (401) by the 5GC (420), so that the NG-RAN (410) can route the NAS message to the appropriate AMF (421) as long as the temporary ID is valid. NG-RAN (410) recognizes the AMF (421) associated with the temporary ID and can reach it. Otherwise, the method for initial attachment is applied.

[0191] NG-RAN (410) supports resource isolation between slices. NG-RAN (410) resource isolation can be achieved by protection mechanisms and RRM policies that must avoid a shortage of shared resources when one slice stops service-level consensus for another slice. In some implementations, it is possible to dedicate NG-RAN (410) resources entirely to a specific slice. How NG-RAN (410) supports resource isolation is implementation-dependent.

[0192] Some slices may be available only in parts of the network. The recognition of slices supported in neighboring cells by the NG-RAN (410) may be beneficial for inter-frequency mobility in access mode. Slice availability may not change within the UE's registration area. The NG-RAN (410) and 5GC (420) are responsible for handling service requests for slices that may or may not be available in a given area. The approval or denial of access to a slice may depend on factors such as support for the slice, availability of resources, and support for the requested service by the NG-RAN (410).

[0193] A UE (401) may be associated with multiple network slices simultaneously. When a UE (401) is associated with multiple slices simultaneously, only one signaling connection is maintained, and for intra-frequency cell reselection, the UE (401) attempts to camp on the best cell. For inter-frequency cell reselection, dedicated priorities are used to control the frequency on which the UE (401) camps on. 5GC (420) verifies that the UE (401) has the right to access the network slice. Before receiving the initial context setup request message, the NG-RAN (410) may be allowed to apply some provisional / local policies based on the recognition of the specific slice that the UE (401) is requesting to access. During the initial context setup, the NG-RAN (410) is notified of the slice for which resources are being requested.

[0194] NFV architectures and infrastructures can be used to virtualize one or more NFs performed on physical resources, including combinations of industry-standard server hardware, storage hardware, or switches, or alternatively on private hardware. In other words, NFV systems can be used to run virtual or reconfigurable implementations of one or more EPC components / functions.

[0195] FIG. 10 is a block diagram illustrating components according to some exemplary embodiments of a system (1000) for supporting NFV. The system (1000) is illustrated as including VIM (1002), NFVI (1004), VNFM (1006), VNF (1008), EM (1010), NFVO (1012), and NM (1014).

[0196] VIM (1002) manages the resources of NFVI (1004). NFVI (1004) may include physical or virtual resources and applications (including hypervisors) used to run the system (1000). VIM (1002) may manage the lifecycle of virtual resources (e.g., creation, maintenance, and decommissioning of VMs associated with one or more physical resources) to NFVI (1004), track VM instances, track the performance, faults, and security of VM instances and associated physical resources, and expose VM instances and associated physical resources to other management systems.

[0197] The VNFM (1006) can manage the VNFs (1008). The VNFs (1008) can be used to execute EPC components / functions. The VNFM (1006) can manage the lifecycle of the VNFs (1008) and track the performance, faults, and security of the virtual suns of the VNFs (1008). The EM (1010) can track the performance, faults, and security of the functional suns of the VNFs (1008). Tracking data from the VNFM (1006) and the EM (1010) may include PM data used, for example, by the VIM (1002) or NFVI (1004). Both the VNFM (1006) and the EM (1010) can scale up or down the number of VNFs in the system (1000).

[0198] The NFVO (1012) can coordinate, authorize, release, and engage the resources of the NFVI (1004) to provide the requested service (e.g., to execute an EPC function, component, or slice). The NM (1014) can provide a package of end-user functions responsible for the management of the network, which may include network elements with VNFs, non-virtualized network functions, or both (the management of VNFs may occur through the EM (1010)).

[0199] FIG. 11 is a block diagram illustrating components according to some exemplary embodiments capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transient machine-readable storage medium) and performing any one or more of the methodologies discussed herein. Specifically, FIG. 11 illustrates a schematic representation of hardware resources (1100) including one or more processors (or processor cores) (1110), one or more memory / storage devices (1120), and one or more communication resources (1130), each of which may be coupled to communicate via a bus (1140). In embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor (1102) may be executed to provide an execution environment for one or more network slices / subslices to utilize the hardware resources (1100).

[0200] The processors (1110) may include, for example, a processor (1112) and a processor (1114). The processor(s) (1110) may be, for example, a CPU, a RISC processor, a CISC processor, a GPU, a DSP, such as a baseband processor, an ASIC, an FPGA, an RFIC, other processors (including those discussed in this specification), or any suitable combination thereof.

[0201] The memory / storage devices (1120) may include main memory, disk storage, or any suitable combination thereof. The memory / storage devices (1120) may include any type of volatile or non-volatile memory such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state storage, etc., but are not limited to these.

[0202] Communication resources (1130) may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices (1104) or one or more databases (1106) via a network (1108). For example, communication resources (1130) may include wired communication components (e.g., for coupling via USB), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.

[0203] Instructions (1150) may include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors (1110) to perform any one or more of the methodologies discussed herein. Instructions (1150) may exist wholly or partially in at least one of the processors (1110) (e.g., in the processor's cache memory), memory / storage devices (1120), or any suitable combination thereof. Additionally, any portion of instructions (1150) may be transferred to hardware resources (1100) from any combination of peripheral devices (1104) or databases (1106). Thus, the memory of the processors (1110), memory / storage devices (1120), peripheral devices (1104), and databases (1106) are examples of computer-readable and machine-readable media.

[0204] Exemplary procedures

[0205] In some embodiments, electronic device(s), network(s), system(s), chip(s) or component(s), or parts or implementations thereof of FIG. 2 through 11, or of some other figures in this specification, may be configured to perform one or more processes, techniques, or methods, or parts thereof as described herein. One such process is illustrated in FIG. 12. FIG. 12 is a flowchart of a method (1200) for performing beam failure recovery according to some embodiments. The method (1200) may be performed by processing logic that may include hardware (e.g., circuits, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof. It will be understood that not all steps may be required to perform the disclosure provided herein. Also, as understood by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that illustrated in FIG. 12.

[0206] In step (1202), the UE performs or causes beam failure detection on the SCell.

[0207] In step (1204), the UE identifies or causes to identify a BFRQ signal to indicate a beam failure recovery request (BFRQ).

[0208] In step (1206), the UE transmits or causes to transmit the BFRQ signal to a base station (e.g., gNB).

[0209] The processes and functions described in FIG. 12 may be performed by one or more of the application circuit section (505 or 605), baseband circuit section (510 or 610), or processors (1112 and 1114).

[0210] In some embodiments, electronic device(s), network(s), system(s), chip(s) or component(s), or parts or implementations thereof of FIGS. 2 through 11, or of some other figures in this specification, may be configured to perform one or more processes, techniques, or methods, or parts thereof as described herein. One such process is illustrated in FIG. 13. FIG. 13 is a flowchart of a method (1300) for performing beam failure recovery according to some embodiments. The method (1300) may be performed by hardware (e.g., circuits, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or processing logic that may include a combination thereof. It will be understood that not all steps may be required to perform the disclosure provided herein. Also, as understood by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that illustrated in FIG. 13.

[0211] In step (1302), the base station (e.g., gNB) identifies or causes to identify the signal received from the UE.

[0212] In step (1304), the base station determines or causes to determine a beam failure recovery response based on the received signal.

[0213] In step (1306), the base station transmits or causes to transmit a beam failure recovery signal to the UE based on the determined beam failure recovery response.

[0214] The processes and functions described in FIG. 13 may be performed by one or more of the application circuit section (505 or 605), baseband circuit section (510 or 610), or processors (1112 and 1114).

[0215] FIG. 14 is a flowchart of a method (1400) for performing beam failure recovery according to some embodiments. The method (400) may be performed by processing logic that may include hardware (e.g., circuits, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof. It will be understood that not all steps may be required to perform the disclosure provided herein. Also, as understood by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG. 14.

[0216] In step (1402), the UE detects a beam failure on the secondary cell (SCell).

[0217] In step (1404), the UE generates a beam failure recovery request (BFRQ) for the SCell. The BFRQ may include a component carrier identifier for the SCell or a candidate beam identifier for the candidate beam to be used for recovery. The BFRQ may further include an L1-RSRP for the candidate beam or an L1-SINR for the candidate beam.

[0218] In step (1406), the UE transmits a BFRQ for SCell to a base station (e.g., gNB) via a primary cell (PCell). In some embodiments, the UE may transmit the BFRQ for SCell via a PUCCH or PRACH via the PCell. In some other embodiments, the UE may determine whether there is a PUSCH available via the PCell. If there is a PUSCH available, the UE may transmit the BFRQ for SCell via the available PUSCH via the PCell. The UE may transmit the BFRQ for SCell using a MAC-CE via the available PUSCH via the PCell. The MAC-CE may include a component carrier identifier for SCell and a candidate beam identifier for candidate beams. The MAC-CE may further include an L1-RSRP for candidate beams or an L1-SINR for candidate beams.

[0219] If no PUSCH is available, the UE may send a scheduling request (SR) to the base station to allocate a PUSCH through the PCell. In response to sending the SR, the UE may receive an indication from the base station of the allocated PUSCH through the PCell. Subsequently, the UE may send a BFRQ for the SCell using MAC-CE through the allocated PUSCH through the PCell. MAC-CE may include a component carrier identifier for the SCell and a candidate beam identifier for the candidate beam. MAC-CE may further include an L1-RSRP for the candidate beam or an L1-SINR for the candidate beam.

[0220] In some embodiments, the UE can detect a beam failure on the SCell and transmit an SR to the base station after N milliseconds. N milliseconds may be a configurable value or a predefined value.

[0221] In some embodiments, the UE can transmit a BFRQ for the SCell to the base station using a buffer status report (BSR) via an assigned PUSCH through the PCell.

[0222] In step (1408), the UE receives a response to a BFRQ for the SCell from the base station via the SCell or PCell. The UE may receive a response to a BFRQ for the SCell via a control resource set (CORESET) via the SCell. The response to the BFRQ may be a reactivation command.

[0223] In step (1410), the UE uses a new beam for the SCell based on the response to the BFRQ for the SCell.

[0224] The processes and functions described in FIG. 14 may be performed by one or more of the application circuit section (505 or 605), baseband circuit section (510 or 610), or processors (1112 and 1114).

[0225] For one or more embodiments, at least one of the components described in one or more of the prior drawings may be configured to perform one or more operations, techniques, processes, and / or methods as described in the following embodiment section. For example, a baseband circuit as described in connection with one or more of the prior drawings may be configured to operate according to one or more of the embodiments described below. As another example, a circuit associated with a UE, base station, network element, etc. as described in connection with one or more of the prior drawings may be configured to operate according to one or more of the embodiments described below in the embodiment section.

[0226] Examples

[0227] Example 1 may include a device, the device comprising: means for performing or causing to perform beam failure detection on SCell; means for identifying or causing to identify a BFRQ signal to indicate a beam failure recovery request (BFRQ); and means for transmitting or causing to transmit a BFRQ signal to gNB.

[0228] Example 2 may include the subject of Example 1 or any other embodiment of the present specification, wherein the means for transmitting or causing to transmit a beam failure recovery signal is through a PCell.

[0229] Example 3 may include the subject matter of Example 2 or any other embodiment of the present specification, wherein the means for transmitting or causing to transmit a beam failure recovery signal through a PCell further includes means for transmitting or causing to transmit a signal through a MAC-CE or PUCCH.

[0230] Example 4 may include the subject of Example 1 or any other example of the present specification and further includes means for determining or causing to determine whether there is a PUSCH resource or uplink approval available through PCell.

[0231] Example 5 may include the subject of Example 4 or any other embodiment of the present specification, and further includes means for transmitting or causing to transmit a BFRQ MAC-CE signal to SCell through the available PUSCH resource when it is determined that there is a PUSCH resource available therein.

[0232] Example 6 may include the subject of Example 5 or any other embodiment of the present specification, and further includes means for transmitting or causing to transmit an SR signal to request a PUSCH resource for BFRQ transmission when it is determined that no PUSCH resource is available therein.

[0233] Example 7 may include the subject of Example 6 or any other embodiment of the present specification, and further includes means for waiting or waiting for N milliseconds or slots prior to means for transmitting or causing to transmit an SR signal, wherein N is configurable or predefined.

[0234] Example 8 may include the subject of Example 7 or any other example of this specification, where SR is dedicated to beam failure recovery.

[0235] Example 9 may include the subject matter of Example 3 or any other embodiment of the present specification, wherein the BFRQ MAC-CE or MAC-CE through PUCCH comprises: one or more component carrier IDs for indicating a SCell where a beam failure occurs; one or more component carrier IDs for indicating a bitmap of component carriers; one or more candidate beam identifications for indicating one or more new beams for a corresponding SCell; or one selected from L1-RSRP or L1-SINR information for candidate beams.

[0236] Example 10 may include the subject matter of any one of Examples 1 to 9, or any other example of the present specification, wherein the device is implemented in the UE or a part thereof.

[0237] Example 11 may include a device, the device comprising: means for identifying or causing to identify a received signal from a UE; means for determining or causing to determine a beam failure recovery response based on the received signal; and means for transmitting or causing to transmit a beam failure recovery signal to a UE based on the determination of the beam failure recovery response.

[0238] Example 12 may include the subject matter of Example 11 or any other embodiment of the present specification, wherein the means for transmitting or causing to transmit a beam failure recovery signal further includes means for transmitting or causing to transmit a beam failure recovery signal through a PCell or SCell.

[0239] Example 13 may include the subject of Example 11 or any other embodiment of the present specification, wherein the received signal represents a beam failure recovery request of the PCell.

[0240] Example 14 may include the subject matter of any one of Examples 11 to 13 or any other embodiment of the present specification, wherein the device is implemented in gNB or a part thereof.

[0241] Example 15 may include gNode B, wherein it may operate with a plurality of component carriers including PCell and SCell.

[0242] Example 16 may include a user equipment (UE), which may operate with a plurality of component carriers including PCell and SCell, and may perform beam failure detection on SCell and transmit a beam failure recovery request to gNB.

[0243] Example 17 may include the subject matter of Example 16 or some other examples of this specification, wherein a beam failure recovery request (BFRQ) to SCell may be transmitted via PCell. And, the BFRQ to SCell may be transmitted via MAC-CE or PUCCH through PCell.

[0244] Example 18 may include the subject matter of Examples 15 and 17, or some other embodiments of this specification, wherein to transmit a BFRQ to a SCell in a MAC-CE through a PCell, the UE must check whether it has a PUSCH resource / uplink acknowledgment available through the PCell. If the UE has a PUSCH resource available, the BFRQ MAC-CE to the SCell is transmitted through the available PUSCH resource. If the UE does not have a PUSCH resource / uplink acknowledgment available, the UE must first trigger the transmission of a Scheduling Request (SR) to request a PUSCH resource for transmitting the BFRQ. After the gNB receives the SR, the gNB may subsequently allocate a PUSCH resource, and the UE transmits the BFRQ MAC-CE through the allocated PUSCH resource.

[0245] Example 19 may include the subject matter of Example 18 or some other embodiment of this specification, wherein, where the UE does not have available PUSCH resources / uplink acknowledgments, after N milliseconds / slots from the time the UE identifies a SCell beam failure, the UE must first trigger the transmission of a scheduling request (SR), where N is configurable and N can be predefined, e.g., N=0. The SR may be a dedicated SR for beam failure recovery, or the same SR may be shared for other purposes.

[0246] Example 20 may include the subject matter of Example 18 or some other embodiments of this specification, wherein, alternatively, a new type of buffer status report (BSR), e.g., a BFRQ BSR, may be defined to trigger an SR transmission for a BFRQ. After the UE detects a beam failure through the SCell, the UE must generate a BFRQ MAC-CE for the SCell and trigger the BFRQ BSR. If the UE does not have available PUSCH resources, the BFRQ BSR must trigger an SR transmission.

[0247] Example 21 may include the subject matter of Example 17 or some other examples of this specification, wherein MAC-CE or BFRQ MAC-CE via PUCCH may include the following information:

[0248] - One or more component carrier IDs representing the SCell where beam failure occurs. It can also be a bitmap of component carriers.

[0249] - Identify one or more candidate beam(s) representing the identified new beam(s) for the corresponding SCell.

[0250] - L1-RSRP and / or L1-SINR information for candidate beam(s). L1-RSRP and / or L1-SINR information may be optional.

[0251] Example 22 may include the subject matter of Example 15 or some other embodiment of this specification, wherein after receiving a BFRQ to SCell via PCell (the BFRQ to SCell may be transmitted via MAC-CE or PUCCH via PCell), gNB must transmit a response to the BFRQ to SCell. And, the gNB response may be transmitted via PCell or SCell.

[0252] Example 23 may include the subject matter of Example 22 or some other embodiment of this specification, wherein the gNB response is transmitted via SCell. The response is transmitted via a dedicated CORESET / search space used exclusively for transmitting SCell beam failure recovery responses. In this manner, the response is a DCI addressed to the UE. After successfully receiving the DCI, the UE assumes that the communication link has been restored.

[0253] Example 24 may include the subject matter of Example 23 or some other embodiment of this specification, wherein when a BFRQ for SCell is transmitted by MAC-CE or PUCCH through PCell at time instance T1, the UE may begin monitoring a dedicated CORESET through the corresponding SCell starting from T1 + N slots / symbols, where N is configurable or predefined and N may be 0 or greater. And, the slots / symbols are defined according to the numerology of PCell. Alternatively, the slots / symbols are defined according to the numerology of SCell.

[0254] Example 25 may include the subject matter of Example 23 or some other example of this specification, wherein, where the BFRQ for a SCell by MAC-CE or PUCCH includes only one candidate beam for the corresponding SCell, the UE must monitor a dedicated CORESET through the SCell using the spatial QCL assumption as identified by MAC-CE. That is, the gNB must transmit a gNB response through the SCell using the identified candidate beam. In other words, the gNB and the UE must assume that the TCI state of the PDCCH through the SCell is identical to the identified candidate beam until the TCI state of the PDCCH through the SCell is reconfigured or reactivated. In the case of PDSCH reception, the gNB and the UE must assume that the DMRS ports of the PDSCH through the SCell are spatially QCLed with the identified candidate beam until the TCI state is reconfigured or reactivated.

[0255] Example 26 may include the subject matter of Example 23 or some other examples of this specification, wherein where the BFRQ for a SCell by MAC-CE or PUCCH includes more than one candidate beam for the corresponding SCell, the default beam must be applied for PDCCH (dedicated CORESET) and PDSCH transmission until the TCI state is reconfigured or reactivated. For example, the default beam may be one of the first / last candidate beams included in MAC-CE or PUCCH, or one of the candidate beams having the best L1-RSRP or best L1-SINR.

[0256] Example 27 may include the subject matter of Example 23 or some other embodiment of this specification, wherein alternatively, when a UE transmits a BFRQ to a SCell via MAC-CE or PUCCH through a PCell at time instance T2, the UE must begin monitoring a previously configured CORESET / search space through the corresponding SCell starting from T2 + M slots / symbols, where M is configurable or predefined and M may be 0 or greater. And, slots / symbols are defined according to the numerology of the PCell or Scell. For monitoring the CORESET / search space through the SCell, the UE applies a default space QCL assumption. The default space QCL assumption may be that only one candidate beam is identified when transmitted in the BFRQ by MAC-CE or PUCCH. Additionally, the default spatial QCL assumption may be the first / last candidate beam, or, if the BFRQ by MAC-CE or PUCCH includes more than one candidate beam, the candidate beam having the best L1-RSRP or L1-SINR. It is assumed that a gNB response to the BFRQ is received when the DCI addressed to the UE is successfully received. In this manner, there is no need to configure a dedicated CORESET for SCell beam failure recovery operations.

[0257] Example 28 may include the subject matter of Example 22 or some other embodiment of this specification, wherein the gNB response to the SCell BFRQ is transmitted via the PCell. The gNB response may be a reconfiguration / reactivation message by the RRC layer or the MAC layer. For example, the message may be used to reconfigure the gNB Tx beam or TCI state for the SCell, or the control resource set (CORESET), i.e., the CSI-RS and / or SS / PBCH block. After the UE receives the reconfiguration / reactivation message, the UE assumes that the BFRQ for the SCell has been received by the gNB.

[0258] Example 29 may include the subject matter of Example 28 or some other embodiments of this specification, wherein if the gNB response to the SCell BFRQ contains only one beam information, e.g., only one TCI state, the UE assumes that the DMRS port of the SCell's PDCCH / PDSCH is spatially QCL with that included in the gNB response. If the gNB response to the SCell BFRQ contains more than one beam information, the UE may assume a default beam for receiving the PDCCH / PDSCH through the SCell before the MAC-CE reactivation command is received. For example, the default beam may be the first beam or the last beam included in the gNB response.

[0259] Example 30 may include the subject matter of Example 28 or some other embodiment of this specification, wherein when a gNB response or MAC-CE reactivation command is received via PCell at time instance T3, after T3 + K slots / symbols, the UE may apply a reconfigured / reactivated spatial QCL assumption for receiving PDCCH / PDSCH via SCell, where K is configurable or predefined and K may be greater than or equal to 0. And, slots / symbols are defined according to the numerology of PCell. Alternatively, slots / symbols are defined according to the numerology of SCell.

[0260] Example 31 may include the subject matter of Example 22 or some other embodiment of the present specification, wherein if the UE transmits a MAC CE for BFRQ and does not receive a response from the gNB after X slots or ms, the UE may retransmit the MAC CE until it reaches a maximum number of retransmissions, wherein X and the maximum number of retransmissions may be configured or predefined by RRC signaling.

[0261] Example 32 may include the subject matter of Example 22 or some other embodiment of this specification, wherein whether the gNB response to the SCell beam failure recovery request is delivered via PCell or SCell is configurable. Consequently, the UE must monitor PCell or SCell for the gNB response after sending the BFRQ to SCell.

[0262] Example 33 may include a UE device, said UE device for performing or causing beam failure detection on SCell; for identifying or causing a BFRQ signal to indicate a beam failure recovery request (BFRQ); and for transmitting or causing a BFRQ signal to gNB.

[0263] Example 34 may include the subject of Example 33 or any other embodiment of the present specification, wherein the transmission or transmission of a beam failure recovery signal is through a PCell.

[0264] Example 35 may include the subject matter of Example 34 or any other embodiment of the present specification, wherein transmitting or causing a beam failure recovery signal through a PCell further includes transmitting or causing a signal through a MAC-CE or PUCCH.

[0265] Example 36 may include the subject of Example 33 or any other example of this specification, and further includes determining or causing to determine whether there are PUSCH resources or uplink approvals available through PCell.

[0266] Example 37 may include the subject of Example 36 or any other embodiment of the present specification, and further includes transmitting or causing to transmit a BFRQ MAC-CE signal to SCell through the available PUSCH resource when it is determined that there is a PUSCH resource available.

[0267] Example 38 may include the subject matter of Example 37 or any other embodiment of the present specification, and further includes transmitting or causing an SR signal to request a PUSCH resource for BFRQ transmission when it is determined that no PUSCH resource is available.

[0268] Example 39 may include the subject of Example 38 or any other embodiment of the present specification, and further includes waiting or waiting for N milliseconds or slots before transmitting an SR signal, wherein N is configurable or predefined.

[0269] Example 40 may include the subject of Example 39 or any other example of the present specification, wherein SR is dedicated to beam failure recovery.

[0270] Example 41 may include the subject matter of Example 35 or any other embodiment of the present specification, wherein the BFRQ MAC-CE or MAC-CE through PUCCH comprises: one or more component carrier IDs for indicating a SCell where a beam failure occurs; one or more component carrier IDs for indicating a bitmap of component carriers; one or more candidate beam identifications for indicating one or more new beams for a corresponding SCell; or one selected from L1-RSRP or L1-SINR information for candidate beams.

[0271] Example 42 may include a gNB device, said gNB device for identifying or causing to identify a signal received from a UE; for determining or causing to determine a beam failure recovery response based on the received signal; and for transmitting or causing to transmit a beam failure recovery signal to the UE based on the determination of the failure recovery response.

[0272] Example 43 may include the subject matter of Example 42 or any other embodiment of the present specification, wherein transmitting or causing a beam failure recovery signal further includes transmitting or causing a beam failure recovery signal through a PCell or SCell.

[0273] Example 44 may include the subject of Example 42 or any other example of the present specification, wherein the received signal represents a beam failure recovery request of the PCell.

[0274] Example 45 may include a method for implementing a user equipment (UE), the method comprising: a step of performing or causing beam failure detection on a SCell; a step of identifying or causing a BFRQ signal to indicate a beam failure recovery request (BFRQ); and a step of transmitting or causing a BFRQ signal to a gNB.

[0275] Example 46 may include the subject of Example 45 or any other embodiment of the present specification, wherein the step of transmitting or causing a beam failure recovery signal to be transmitted is through a PCell.

[0276] Example 47 may include the subject matter of Example 46 or any other embodiment of the present specification, wherein the step of transmitting or causing a beam failure recovery signal through a PCell further includes the step of transmitting or causing a signal through a MAC-CE or PUCCH.

[0277] Example 48 may include the subject of Example 45 or any other example of the present specification and further includes the step of determining or causing to determine whether there is a PUSCH resource or uplink approval available through PCell.

[0278] Example 49 may include the subject of Example 48 or any other embodiment of the present specification, and further includes the step of transmitting or causing to transmit a BFRQ MAC-CE signal to SCell through the available PUSCH resource when it is determined that there is a PUSCH resource available.

[0279] Example 50 may include the subject of Example 49 or any other embodiment of the present specification, and further includes the step of transmitting or causing an SR signal to request a PUSCH resource for BFRQ transmission when it is determined that there is no PUSCH resource available.

[0280] Example 51 may include the subject of Example 50 or any other embodiment of the present specification, and further includes the step of waiting or waiting for N milliseconds or slots before transmitting or causing to transmit an SR signal, wherein N is configurable or predefined.

[0281] Example 52 may include the subject of Example 51 or any other embodiment of this specification, wherein SR is dedicated to beam failure recovery.

[0282] Example 53 may include the subject matter of Example 47 or any other embodiment of the present specification, wherein the BFRQ MAC-CE or MAC-CE through PUCCH comprises: one or more component carrier IDs for indicating a SCell where a beam failure occurs; one or more component carrier IDs for indicating a bitmap of component carriers; one or more candidate beam identifications for indicating one or more new beams for a corresponding SCell; or one selected from L1-RSRP or L1-SINR information for candidate beams.

[0283] Example 54 may include a method for implementing a gNB, the method comprising: identifying or causing to identify a signal received from a UE; determining or causing to determine a beam failure recovery response based on the received signal; and transmitting or causing to transmit a beam failure recovery signal to a UE based on the determination of the beam failure recovery response.

[0284] Example 55 may include the subject matter of Example 54 or any other embodiment of the present specification, wherein the step of transmitting or causing a beam failure recovery signal to be transmitted further includes the step of transmitting or causing a beam failure recovery signal to be transmitted through a PCell or SCell.

[0285] Example 56 may include the subject of Example 54 or any other embodiment of the present specification, wherein the received signal indicates a beam failure recovery request of the PCell.

[0286] Example 57 may include a device comprising means for performing one or more elements of a method described in any of Examples 1 to 56 or related thereto, or any other method or process described herein.

[0287] Example 58 may comprise one or more non-transient computer-readable media containing instructions, the instructions causing an electronic device to perform one or more elements of a method described in any of Examples 1 to 56 or related thereto, or any other method or process described herein, when the instructions are executed by one or more processors of the electronic device.

[0288] Example 59 may include a device comprising logic, modules, or circuits for performing one or more elements of a method described in any of Examples 1 to 56 or related thereto, or any other method or process described herein.

[0289] Example 60 may include any of the examples 1 to 56, or parts thereof, or methods, techniques, or processes described or related thereto.

[0290] Example 61 may include an apparatus comprising one or more processors and one or more computer-readable media comprising instructions, wherein the instructions, when executed by one or more processors, cause one or more processors to perform methods, techniques, or processes such as those described or related thereto in any of Examples 1 to 56 or parts thereof.

[0291] Example 62 may include a signal as described or related thereto in any of Examples 1 to 56, or parts thereof.

[0292] Example 63 may include a signal within a wireless network as illustrated and described in this specification.

[0293] Example 64 may include a method of communicating in a wireless network as illustrated and described in this specification.

[0294] Example 65 may include a system for providing wireless communication as illustrated and described in this specification.

[0295] Example 66 may include a device for providing wireless communication as illustrated and described in this specification.

[0296] Any of the embodiments described above may be combined with any other embodiments (or combinations of embodiments) unless otherwise clearly indicated. The foregoing description of one or more embodiments is for illustrative and descriptive purposes only and is not intended to be comprehensive or to limit the scope of embodiments to the exact form disclosed. Modifications and variations may be obtained from the practice of possible or various embodiments in consideration of the above teachings.

[0297] Abbreviations

[0298] For the purposes of this document, the following abbreviations may be applied to the examples and embodiments discussed herein, but are not intended to be limiting.

[0299]

[0300]

[0301]

[0302]

[0303]

[0304]

[0305]

[0306]

[0307]

[0308]

[0309]

[0310]

[0311]

[0312]

[0313]

[0314]

[0315]

[0316]

[0317]

[0318] terminology

[0319] For the purposes of this document, the following terms and definitions are applicable to the examples and embodiments discussed herein, but are not intended to be limiting.

[0320] As used herein, the term “circuit” refers to, is part of, or includes hardware components such as electronic circuits, logic circuits, processors (shared, dedicated, or group), and / or memory (shared, dedicated, or group), ASICs, FPDs (e.g., FPGAs, PLDs, CPLDs, HCPLDs, structured ASICs, or PSoCs), DSPs, etc., configured to provide the described functions. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functions. The term “circuit” may also refer to a combination of program code and one or more hardware elements used to perform the functions of the program code (or a combination of circuits used in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a specific type of circuit.

[0321] As used herein, the term “processor circuit” may refer to, be part of, or include a circuit capable of performing a sequence of arithmetic or logical operations sequentially and automatically, or recording, storing, and / or transmitting digital data. The term “processor circuit” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions such as program code, software modules, and / or functional processes. The terms “application circuit” and / or “baseband circuit” may be considered synonymous with and referred to as “processor circuit.”

[0322] As used herein, the term “interface circuit” refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term “interface circuit” may refer to one or more hardware interfaces, e.g., buses, I / O interfaces, peripheral component interfaces, network interface cards, and / or similar ones.

[0323] As used herein, the term “User Equipment” or “UE” refers to a device having wireless communication capabilities and may describe a remote user of network resources in a communication network. The term “User Equipment” or “UE” may be considered synonymous with and referred to as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, wireless equipment, reconfigurable wireless equipment, reconfigurable mobile device, etc. Furthermore, the term “User Equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communication interface.

[0324] As used herein, the term “network element” refers to physical or virtualized equipment and / or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous with and / or referred to by networked computers, networking hardware, network equipment, network nodes, routers, switches, hubs, bridges, wireless network controllers, RAN devices, RAN nodes, gateways, servers, virtualized VNFs, NFVIs, etc.

[0325] As used herein, the term “computer system” refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the terms “computer system” and / or “system” may refer to various components of a computer that are coupled to communicate with one another. Furthermore, the terms “computer system” and / or “system” may refer to a number of computer devices and / or a number of computing systems that are coupled to communicate with one another and configured to share computing and / or networking resources.

[0326] As used herein, terms “device,” “computer device,” etc. refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide specific computing resources. “Virtual device” is a virtual machine image implemented by a hypervisor-equipped device dedicated to virtualizing or mimicking a computer device, or otherwise providing specific computing resources.

[0327] As used herein, the term “resource” refers to a physical or virtual device, a physical or virtual component within a computing environment, and / or computer devices, a physical or virtual component within a specific device such as a machine device, memory space, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, I / O operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and applications, workload units, and / or similar items. “Hardware resource” may refer to computing, storage, and / or network resources provided by physical hardware element(s). “Virtualized resource” may refer to computing, storage, and / or network resources provided by applications, devices, systems, etc., by virtualization infrastructure. The terms “network resource” or “communication resource” may refer to resources accessible by computer devices / systems through a communication network. The term "system resources" may refer to any kind of shared entities that provide services and may include computing and / or network resources. System resources may be considered as a set of coherent functions, network data objects, or services that exist on a single host or multiple hosts and are accessible through a clearly identifiable server.

[0328] As used herein, the term “channel” refers to any transmission medium, whether tangible or intangible, used to communicate data or a data stream. The term “channel” is synonymous with and / or equivalent to any other similar term referring to a path or medium through which data is communicated, such as “communication channel,” “data communication channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radio frequency carrier,” and / or any other similar term. Additionally, the term “link” refers to a connection between two devices via a RAT for the purpose of transmitting and receiving information.

[0329] As used herein, terms such as "instantiate," "instantiation," etc. refer to the creation of an instance. "Instance" also refers to the specific occurrence of an object that may occur, for example, during the execution of program code.

[0330] The terms “coupled” and “communicably coupled” are used herein together with their derivatives. The term “coupled” may mean that two or more elements are in direct physical or electrical contact with each other, and / or may mean that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and / or may mean that one or more other elements are coupled or connected between elements said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with each other. The term “communicably coupled” may mean that two or more elements are in contact with each other by communication, including through a wire or other interconnection part, through a wireless communication channel or link, and / or other etc.

[0331] The term "information element" refers to a structural element comprising one or more fields. The term "field" refers to individual contents of an information element, or a data element containing content.

[0332] The term "SMTC" is SSB-MeasurementTimingConfiguration It refers to the SSB-based measurement timing configuration configured by.

[0333] The term "SSB" refers to an SS / PBCH block.

[0334] The term "primary cell" refers to an MCG cell operating at the primary frequency, where the UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure.

[0335] The term "primary SCG cell" refers to an SCG cell in which the UE performs random access when performing reconstruction using the Sync procedure for DC operation.

[0336] The term "secondary cell" refers to a cell that provides additional wireless resources on top of a special cell for a UE configured with CA.

[0337] The term "secondary cell group" refers to a subset of serving cells including zero or more secondary cells and PSCells for a UE composed of DCs.

[0338] The term "serving cell" refers to a primary cell for a UE that is RRC_CONNECTED and not configured as CA / DC, and there is only one serving cell configured as a primary cell.

[0339] The term "serving cell" or "serving cells" refers to a set of cells including all secondary cells and special cell(s) for a UE in RRC_CONNECTED configured with CA / .

[0340] The term "special cell" refers to the PSCell of the SCG or the PCell of the MCG for DC operation; otherwise, the term "special cell" refers to the Pcell.

[0341] As described above, aspects of the present technology may include, for example, the collection and use of data available from various resources to improve or enhance functionality. The present invention considers that, in some cases, such collected data may include personal data that can be used to uniquely identify a specific individual, or to contact him / her, or to determine his / her location. Such personal data may include demographic data, location-based data, telephone numbers, email addresses, Twitter IDs, home addresses, data or records regarding a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other identifying or personal information. The present invention recognizes that the use of such personal data in the present technology may be used to benefit users.

[0342] The present invention considers that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal data will comply with well-established privacy policies and / or privacy practices. In particular, these entities must implement and consistently use privacy policies and practices that are recognized as meeting or exceeding industrial or administrative requirements for keeping personal data private and secure. Such policies must be readily accessible to users and updated as the collection and / or use of data changes. Personal data from users must be collected for the entity's lawful and proper use and must not be shared or sold outside of these lawful uses. Additionally, such collection / sharing must occur only after receiving the users' notified consent. Furthermore, such entities must consider taking any necessary steps to protect and secure access to such personal data and to ensure that others with access to the personal data adhere to their privacy policies and procedures. Furthermore, these entities may be evaluated by third parties to demonstrate their adherence to widely recognized privacy policies and practices. Additionally, policies and practices must be adapted to the specific types of personal data being collected and / or accessed, and to applicable laws and standards that include jurisdiction-specific considerations.For example, in the United States, the collection or access to certain health data may be controlled by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); whereas health data in other countries may be subject to and must be handled by other laws and policies. Therefore, different privacy practices must be maintained for different types of personal data in each country.

[0343] Notwithstanding the foregoing, the present invention also considers embodiments in which users selectively block the use of or access to personal information data. That is, the present invention considers that hardware and / or software elements may be provided to prevent or block access to such personal information data. For example, the present invention may be configured to allow users to selectively "agree" or "disagree" to participation in the collection of personal information data, for example, during registration for services or at any time thereafter. In addition to providing "agree" and "disagree" options, the present invention considers providing notifications regarding the access or use of personal information. For example, a user may be notified that their personal information data will be accessed when downloading an app, and subsequently may be reminded again just before the personal information data is accessed by the app.

[0344] Furthermore, it is the intent of the present invention that personal data be managed and processed in a manner that minimizes the risks of unintended or unauthorized access or use. Risks can be minimized by limiting the collection of data and by deleting data when it is no longer needed. Additionally, and where applicable, including in certain health-related applications, data de-identification may be used to protect user privacy. Where appropriate, de-identification may be facilitated by removing specific identifiers (e.g., date of birth, etc.), by controlling the amount or specificity of stored data (e.g., by collecting location data at the city level rather than the address level), by controlling the way data is stored (e.g., by aggregating data across users), and / or by other methods.

[0345] Accordingly, while the present invention may extensively cover the use of personal information data to implement one or more various disclosed embodiments, the present invention also takes into account that various embodiments may be implemented without the need to access such personal information data. That is, various embodiments of the present technology are not rendered inoperable due to the absence of all or part of such personal information data.

Claims

Claim 1 A base station (BS) comprises: a wireless front-end circuit; and a processor circuit coupled to the wireless front-end circuit, wherein the processor circuit comprises: receiving a beam failure recovery request (BFRQ) for a secondary cell (SCell) via a primary cell (PCell) from a user equipment (UE) - wherein the BFRQ comprises a component carrier identifier for the SCell and a first plurality of candidate beam identifiers for a new beam to be used for recovery, and a layer 1 reference signal received power (L1-RSRP) for the new beam or a layer 1 signal-to-interference-plus-noise ratio (L1-SINR) for the new beam -; and selecting a candidate beam from the first plurality of candidate beam identifiers; A BS configured to transmit a response to the BFRQ for the SCell to the UE via the SCell using the selected candidate beam, wherein the response comprises a second plurality of candidate beams for selection by the UE of one beam to be used as the new beam for the UE to receive a downlink transmission via the SCell. Claim 2 In claim 1, for receiving the BFRQ for the SCell, the processor circuit is further configured to receive the BFRQ for the SCell to the base station via the Primary Uplink Control Channel (PUCCH) or Physical Random Access Channel (PRACH) through the PCell using the wireless front-end circuit. Claim 3 In claim 1, for receiving the BFRQ for the SCell, the processor circuit is further configured to receive the BFRQ for the SCell to the base station via a Primary Uplink Shared Channel (PUSCH) through the PCell using the wireless front-end circuit. Claim 4 In claim 1, for transmitting the response to the BFRQ to the SCell, the processor circuit is further configured to transmit the response to the BFRQ to the SCell through a control-resource set (CORESET) through the SCell using the selected beam, BS. Claim 5 In paragraph 1, the response to the BFRQ for the SCell is a reactivation command, BS. Claim 6 delete Claim 7 In claim 1, the processor circuit is further configured to receive a schedule request (SR) for allocating a PUSCH through the PCell from the UE using the wireless front-end circuit; and in response to receiving the SR, to transmit to the UE an indication of the allocated PUSCH through the PCell; and to receive the BFRQ for the SCell, the processor circuit is further configured to receive the BFRQ for the SCell from a media access control control element (MAC-CE) through the allocated PUSCH through the PCell from the UE using the wireless front-end circuit, BS. Claim 8 In claim 7, for receiving the SR, the processor circuit is further configured to use the wireless front-end circuit to detect the beam failure on the SCell and receive the SR from the UE after N milliseconds, wherein N is a configurable non-negative value or a predefined non-negative value, BS. Claim 9 In claim 7, for receiving the SR, the processor circuit is further configured to receive the BFRQ for the SCell in a buffer status report (BSR) via the assigned PUSCH through the PCell from the UE using the wireless front-end circuit. Claim 10 A method for performing beam failure recovery, comprising: receiving a beam failure recovery request (BFRQ) for a secondary cell (SCell) through a primary cell (PCell) from a user device (UE) - wherein the BFRQ includes a component carrier identifier for the SCell and a first plurality of candidate beam identifiers for a new beam to be used for recovery, and a layer 1 reference signal received power (L1-RSRP) for the new beam or a layer 1 signal-to-interference-plus-noise ratio (L1-SINR) for the new beam -; selecting a candidate beam from the first plurality of candidate beam identifiers; and transmitting a response to the BFRQ for the SCell to the UE through the SCell using the selected candidate beam - wherein the response includes a second plurality of candidate beams for selection by the UE of one beam to be used as the new beam for the UE to receive a downlink transmission through the SCell - Claim 11 A method according to claim 10, wherein the step of receiving the BFRQ for the SCell further comprises the step of receiving the BFRQ for the SCell from the UE through a primary uplink control channel (PUCCH) or a physical random access channel (PRACH) through the PCell. Claim 12 A method according to claim 10, wherein the step of transmitting the response to the BFRQ to the SCell further comprises the step of transmitting the response to the BFRQ to the SCell through a control resource set (CORESET) through the SCell using the selected beam. Claim 13 The method of claim 10 further comprises the steps of: receiving a schedule request (SR) from the UE for allocating a PUSCH through the PCell; and transmitting a indication of the allocated PUSCH through the PCell to the UE in response to receiving the SR; wherein the step of receiving the BFRQ for the SCell further comprises the step of receiving the BFRQ for the SCell from the UE in a media access control control element (MAC-CE) through the allocated PUSCH through the PCell. Claim 14 In claim 13, the step of receiving the SR further comprises the step of detecting the beam failure on the SCell and receiving the SR from the UE after N milliseconds, wherein N is a configurable non-negative value or a predefined non-negative value. Claim 15 In claim 13, the step of receiving the SR further comprises the step of receiving the BFRQ for the SCell in the buffer status report (BSR) from the UE through the assigned PUSCH through the PCell. Claim 16 A non-transient computer-readable storage medium in which instructions are stored, which, when executed by one or more processors of a base station (BS), causes the BS to perform operations, said operations include receiving a beam failure recovery request (BFRQ) for a secondary cell (SCell) via a primary cell (PCell) from a user equipment (UE) - said BFRQ comprises a component carrier identifier for said SCell and a first plurality of candidate beam identifiers for a new beam to be used for recovery, and a layer 1 reference signal received power (L1-RSRP) for said new beam or a layer 1 signal-to-interference-plus-noise ratio (L1-SINR) for said new beam -; and selecting a candidate beam from said first plurality of candidate beam identifiers. A non-transient computer-readable storage medium comprising: transmitting a response to the BFRQ for the SCell to the UE via the SCell using the selected candidate beam—the response comprising a second plurality of candidate beams for selection by the UE of one beam to be used as the new beam for the UE to receive a downlink transmission via the SCell. Claim 17 A non-transient computer-readable storage medium, wherein, in paragraph 16, transmitting the response to the BFRQ to the SCell further comprises transmitting the response to the BFRQ to the SCell through a control resource set (CORESET) through the SCell using the selected beam. Claim 18 In claim 16, the operations further comprise receiving a schedule request (SR) from the UE for allocating a PUSCH through the PCell; and in response to receiving the SR, transmitting to the UE an indication of the allocated PUSCH through the PCell; and receiving the BFRQ for the SCell further comprises receiving the BFRQ for the SCell from the UE via the allocated PUSCH through the PCell at a media access control control element (MAC-CE). Claim 19 A non-transient computer-readable storage medium, wherein receiving the SR further comprises detecting the beam failure on the SCell and receiving the SR from the UE after N milliseconds, where N is a configurable non-negative value or a predefined non-negative value. Claim 20 A non-transient computer-readable storage medium, wherein receiving the SR further comprises receiving the BFRQ for the SCell in the buffer status report (BSR) through the assigned PUSCH through the PCell from the UE.

Images