CN114222010A - Apparatus and method for transparent or header-less layer 2 protocol - Google Patents

Abstract

The present disclosure provides apparatus and methods for transparent or header-less layer 2 protocols. An apparatus includes a processor circuit. The processor circuit is to: decoding one or more packets, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field indicating a PDCP SN of a respective packet of the one or more packets; and determining the PDCP SN based on a mapping between the PDCP SNs and resources for the corresponding packet. Other embodiments may be disclosed and claimed.

Description

Apparatus and method for transparent or header-less layer 2 protocol

Priority declaration

This application is based on and claims priority from international application serial No. PCT/CN2020/116153 filed on 18/9/2020. The entire contents of this application are incorporated herein by reference in their entirety.

Technical Field

Embodiments of the present disclosure relate generally to the field of communications, and in particular, to an apparatus and method for a transparent or header-less layer 2(L2) protocol.

Background

Mobile communications have evolved significantly from early speech systems to today's highly sophisticated integrated communication platforms. Next generation wireless communication systems, fifth generation (5G) or New Radios (NR) will provide information access and data sharing through various terminals and applications anytime and anywhere. NR promises to be a unified network/system, aimed at satisfying distinct and sometimes conflicting performance dimensions and services. This different multidimensional requirement is driven by different services and applications. In general, NRs can evolve based on third generation partnership project (3GPP) Long Term Evolution (LTE) -advanced and other potential new Radio Access Technologies (RATs), enriching people's lives with better, simple, and seamless wireless connectivity solutions. The NR can enable everything over the wireless connection and provide fast, rich content and services.

Disclosure of Invention

An aspect of the present disclosure provides an apparatus, comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: decoding one or more packets received from a communication element via the interface circuitry, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets; and determining the PDCP SN based on a mapping between the PDCP SN and resources for the corresponding packet.

An aspect of the present disclosure provides an apparatus, comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding one or more packets for transmission to a communication element via the interface circuit, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets, wherein the PDCP SN is based on a mapping between the PDCP SN and resources for the respective packet.

An aspect of the present disclosure provides an apparatus, comprising: an apparatus, comprising: a memory; and a processor circuit coupled with the memory, wherein the processor circuit is to: generating a keystream for a packet based, in part, on a fixed size value configured for the packet prior to decoding the packet; and performing encryption or decryption based on the keystream, and wherein the memory is to store the fixed-size value.

An aspect of the present disclosure provides an apparatus, comprising: an apparatus, comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: in a transparent Medium Access Control (MAC) mode, decoding a MAC Protocol Data Unit (PDU) received from a communication element via the interface circuit, wherein the MAC PDU does not include a MAC header, the MAC PDU corresponds to a single MAC Service Data Unit (SDU), and a size of the MAC SDU is fixed.

Drawings

Embodiments of the present disclosure will be described by way of example, and not limitation, in the figures of the accompanying drawings in which like references indicate similar elements.

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

Fig. 2 illustrates an example of the NR L2 protocol stack and the functionality of each layer according to some embodiments of the present disclosure.

Figure 3 illustrates an example of a PDCP data PDU format, according to some embodiments of the present disclosure.

Figure 4 illustrates an example of mapping between PDCP counts and Configuration Grant (CG) resources according to some embodiments of the present disclosure.

Figure 5 illustrates a flow diagram of a method for a header-less PDCP layer or a header reduced PDCP layer, according to some embodiments of the present disclosure.

Figure 6 illustrates a flow diagram of a method for a header-less PDCP layer or a header reduced PDCP layer, according to some embodiments of the present disclosure.

Fig. 7 illustrates a flow diagram of a method for pre-generating a keystream, in accordance with some embodiments of the disclosure.

Fig. 8 illustrates an example of a MAC subheader according to some embodiments of the present disclosure.

Fig. 9 illustrates a flow diagram of a method for a headerless MAC layer in accordance with some embodiments of the disclosure.

Fig. 10 illustrates a network according to various embodiments of the present disclosure.

Fig. 11 schematically illustrates a wireless network in accordance with various embodiments of the disclosure.

Fig. 12 illustrates example components of a device according to some embodiments of the present disclosure.

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

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

Detailed Description

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

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

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

Ultra-Reliable and Low Latency (URLLC) operation in NR targets Low Latency and high reliability. To achieve low latency, NR provides the following:

short slot length (by larger subcarrier spacing (SCS) at higher frequencies)

Data transmission in a duration shorter than one slot (mini-slot in Downlink (DL), as short as 2 symbols)

Flexible Time Division Duplex (TDD) time slot structure (time slot containing both DL and Uplink (UL) symbols)

Preemption of enhanced mobile broadband (eMBB) data: ongoing DL eMBB data transmission may be punctured by urrllc data

Semi-persistent scheduling: pre-configuring resources without performing Physical Downlink Control Channel (PDCCH) decoding; further, for the uplink, configuration grants may be used to reduce the need for scheduling requests

Frequent PDCCH transmission opportunities and monitoring capability

Short Physical Uplink Control Channel (PUCCH): one or two symbol PUCCH to minimize hybrid automatic repeat request (HARQ) feedback delay

Frequent Scheduling Requests (SR): the UE may be configured with scheduling request occasions every 2 symbols to minimize the delay of uplink resource allocation

Retransmission without HARQ feedback: the configuration may enable 2, 4, or 8 repetitions without waiting for HARQ feedback

Front-loaded demodulation reference signal (DMRS): time-slotted early DMRS to enable early channel estimation

Frequency-first mapping of data to resource elements to allow symbol-by-symbol processing (rather than buffering all symbols of a slot).

This operation allows NR to achieve 1ms User Plane (UP) delay. In NR Rel-16, a mapping restriction between Logical Channel (LCH) to Configuration Grant (CG) resources can be defined, which can reduce processing delay because a header (header) can be prepared in advance. Thus, the UE may pre-construct an L2 header (PDCP/Radio Link Control (RLC)/MAC) based on its mapping between traffic pattern and quality of service (QoS) flows → Data Radio Bearers (DRBs) → CG resources. In this case, the L2 processing can be reduced, and thus the overall user plane delay can be reduced.

For next generation technologies, goals include significantly reducing the delay (e.g., by about a factor of 10) compared to the delay reduction achievable by NR. Typically, the lowest delay is achieved under favorable radio conditions (e.g., when HARQ or automatic repeat request (ARQ) retransmissions are not required and single slot transmission is sufficient). The L2 processing is in the path of the user plane processing, and reducing the L2 processing may help to minimize the overall user plane delay.

Embodiments of the present disclosure include, among other things, making the L2 layer transparent (transparent) or header-less, or implementing header simplification of the L2 layer. With transparent L2 layers, fewer layers are involved in the data processing and therefore lower delays can be achieved. When a layer is header-less or its headers are simplified, there is less processing and copying/buffering, which may also reduce latency. Furthermore, the reduction of delay in L2 helps to reduce the overall delay of the user plane. Reducing latency may enable more types of services and provide a better user experience.

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

As shown in FIG. 1, the system 100 can include a UE101 a and a UE101 b (collectively referred to as "UE(s) 101"). As used herein, the term "user equipment" or "UE" may refer to devices having radio communication capabilities and may describe remote users of network resources in a communication network. The terms "user equipment" or "UE" may be considered synonyms and may be referred to as a client, a mobile phone, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access agent, a user agent, a receiver, a radio, a reconfigurable mobile, and the like. Furthermore, the terms "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface. In this example, the UE101 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronic device, a cellular phone, a smartphone, a feature phone, a tablet, a wearable computer device, a Personal Digital Assistant (PDA), a pager, a wireless handheld device, a desktop computer, a laptop computer, an in-vehicle infotainment system (IVI), an in-vehicle entertainment (ICE) device, an Instrument panel (Instrument Cluster, IC), a head-up display (HUD) device, an in-vehicle diagnostics (OBD) device, a dashboard mobile Device (DME), a Mobile Data Terminal (MDT), an Electronic Engine Management System (EEMS), an electronic/Engine Control Unit (ECU), an electronic/Engine Control Module (ECM), a mobile computing device(s), a mobile computing device, a mobile device, Embedded systems, microcontrollers, control modules, Engine Management Systems (EMS), networked or "smart" devices, Machine Type Communication (MTC) devices, machine-to-machine (M2M), internet of things (IoT) devices, and/or the like.

In some embodiments, any of the UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via PLMNs, proximity-based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks. The data exchange of M2M or MTC may be a machine initiated data exchange. An IoT network describes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

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

In this example, connections 103 and 104 are shown as air interfaces to enable communicative coupling, and may be consistent with a cellular communication protocol, such as a global system for mobile communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a push-to-talk (PTT) protocol, a cellular PTT (poc) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and/or any other communication protocol discussed herein. In an embodiment, the UE101 may exchange communication data directly via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a Sidelink (SL) interface 105 and may include one or more logical channels including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a physical sidelink shared channel (PSCCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

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

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

In some embodiments, all or part of the RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud Radio Access Network (CRAN) and/or a virtual baseband unit pool (vbbp). In these embodiments, the CRAN or vbbp may implement RAN functional partitioning, such as: PDCP partitioning, wherein RRC and PDCP layers are operated by the CRAN/vbbp, while other layer 2(L2) protocol entities are operated by individual RAN nodes 111; MAC/PHY division, where RRC, PDCP, RLC and MAC layers are operated by the CRAN/vbup, and PHY layers are operated by individual RAN nodes 111; or "lower PHY" division, where the RRC, PDCP, RLC, MAC layers and upper parts of the PHY layers are operated by the CRAN/vbup and lower parts of the PHY layers are operated by the individual RAN node 111. The virtualization framework allows freeing up processor cores of RAN node 111 to execute other virtualized applications. In some implementations, the individual RAN nodes 111 may represent individual gNB-DUs that are connected to the gNB-CUs via individual F1 interfaces (not shown in fig. 1). In these implementations, the gbb-DUs may include one or more remote radio heads or radio front-end modules (RFEM), and the gbb-CUs may be operated by a server (not shown) located in the RAN110 or by a server pool in a similar manner to the CRAN/vbbp. Additionally or alternatively, one or more RAN nodes 111 may be next generation enbs (NG-enbs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations towards the UE101 and which are connected to the 5GC via an NG interface.

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

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

In an embodiment, the UEs 101 may be configured to communicate with each other or any of the RAN nodes 111 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, Orthogonal Frequency Division Multiple Access (OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communications), using Orthogonal Frequency Division Multiplexing (OFDM) communication signals, although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

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

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

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

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

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

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

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

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

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

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

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

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

RAN110 is shown communicatively coupled to a core network, in this embodiment, Core Network (CN) 120. CN120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UE101) connected to CN120 through RAN 110. The term "network element" may describe a physical or virtualized device used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with and/or referred to as: a networking computer, network hardware, network device, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, Virtualized Network Function (VNF), Network Function Virtualization Infrastructure (NFVI), and/or the like. The components of CN120 may be implemented in one physical node or separate physical nodes, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, Network Function Virtualization (NFV) may be used to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). Logical instantiations of the CN120 may be referred to as network slices, and logical instantiations of a portion of the CN120 may be referred to as network subslices. The NFV architecture and infrastructure may be used to virtualize one or more network functions or be executed by dedicated hardware onto physical resources including a combination of industry standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components/functions.

In general, the application server 130 may be an element that provides applications that use IP bearer resources with a core network (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.). The application server 130 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE101 via the EPC 120.

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

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

According to various embodiments, three-way L2 simplification may be included to reduce processing delay.

One possible aspect to reduce the delay is to make the layer completely transparent, e.g. the layer is bypassed (transparent mode may mean that the layer does nothing). For example, RLC of LTE and NR have Transparent Mode (TM). However, TM is not used for DRB but for some types of data, e.g. broadcast channel, paging channel, and also for initial uplink signaling from the UE. Thus, TM is only applicable to special cases, not to general cases.

Another possible aspect to reduce latency is to leave the layers without headers. This can be used in situations where the transparent mode cannot be considered because the functionality is still needed. Thus, some functions may still be performed, but a header may not be needed. No header may mean that the layer still performs some functions, but no header is added. By having no header, there are some benefits in reducing overhead and delay. If a header is needed, the data needs to be manipulated around the header and copied. But if a header is not needed, the data can be translated in place (in place), thus reducing latency.

Yet another possible delay reduction aspect is the simplification of the layer header. In this case, the header is required but simplified, and thus the processing delay can be reduced to some extent.

In some embodiments, such as in some cases in NR, the L2 protocol stack has four layers. Fig. 2 illustrates an example of the NR L2 protocol stack and functions for each layer according to some embodiments of the present disclosure.

As can be seen in fig. 2, the L2 protocol stack may include four layers: a Service Data Adaptation Protocol (SDAP) layer, a PDCP layer, an RLC layer, and a MAC layer. The SDAP layer may be responsible for QoS flow processing. The PDCP layer may be responsible for RObust Header Compression (ROHC) and security. The RLC layer may be responsible for segmentation and ARQ. The MAC layer may be responsible for concatenation/scheduling/priority handling, multiplexing, and HARQ.

In some embodiments, the L2 protocol stack may include more or fewer layers. In some embodiments, the L2 protocol stack may include different layers. The present disclosure is not limited in these respects.

Some of these L2 protocol layers may be transparent or header-less, or some header may be simplified, as will be explained in more detail below.

Figure 3 illustrates an example of a PDCP data PDU format, according to some embodiments of the present disclosure.

In some embodiments, for example, as shown in FIG. 3, the PDCP data PDUs may include 12-bit SNs. In some embodiments, PDCP data PDUs may be for SNs of other sizes. The present disclosure is not limited in this respect.

In some embodiments, the PDCP data PDU may include a header portion and a data portion. For example, as shown in fig. 3, the header may include a D/C field, PDCP SN field(s), message authentication code(s) (MAC-I) field(s) (optional as the case may be), and some reserved (R) fields. The PDCP data PDU format shown in figure 3 with the third generation partnership project; technical specification group radio access network; NR; the format of PDCP data PDUs with 12-bit SNs described in the Packet Data Convergence Protocol (PDCP) specification, release 16 (3GPP TS 38.323V16.1.0(2020-07)) is substantially identical and a description of each field is not detailed herein in order to avoid obscuring the concepts of the present disclosure.

In particular, the D/C field may be used to distinguish between control PDUs and data PDUs. The control PDU may be used for ROHC/Ethernet Header Compression (EHC) feedback and PDCP status reporting. If ROHC/EHC is not used and PDCP status report is not needed (e.g., in RLC Unacknowledged Mode (UM)), the D/C field is not needed.

The PDCP SN field may be used for ciphering/integrity protection, PDCP window management, reordering, and the like. The PDCP COUNT (COUNT) value may include a Hyper Frame Number (HFN) and a PDCP SN. In some embodiments, a technique is proposed to make the characteristic of reflecting the PDCP sequence number (PDCP SN or PDCP COUNT) predictable. In embodiments of the present disclosure, "PDCP SN" and "PDCP COUNT" may be interchanged to some extent when understanding the concepts of the present disclosure, the only difference being that the PDCP SN wraps around (wrap) to 0 when the maximum allowed value is reached, whereas PDCP COUNT does not wrap around as in NR.

In some embodiments, for example for periodic traffic, PDCP COUNT may be predicted without air interface transmission, e.g., COUNT 0 for packets in the first resource, COUNT 1 for packets in the second resource, and so on. For example, for semi-persistent scheduling (SPS)/CG, PDCP COUNT may be linked to the SPS/CG resource configuration, e.g., set to 0 at the inspired resource of the SPS/CG resource configuration and incremented for each allocated resource.

In some embodiments, when configured with CG type 1, no additional configuration is required in RRC, e.g., the first CG occasion corresponds to COUNT 0. In some embodiments, for SPS and CG type 2, the activated resource corresponds to COUNT 0.

In some embodiments, a starting resource location for a link between PDCP COUNT and a resource may be configured in RRC signaling.

Figure 4 illustrates an example of mapping between PDCP COUNT and CG resources, according to some embodiments of the present disclosure. As shown in fig. 4, the increased PDCP count value may be mapped to a corresponding CG resource.

In some embodiments, HARQ retransmission (ReTx) is based on the HARQ process of the initial transmission, whose PDCP SN is linked to the original resource as described above (for HARQ retransmission, the gNB sends the UL grant associated with the HARQ process of the initial transmission). In other words, the HARQ retransmission can know the corresponding PDCP SN through the HARQ process of the initial transmission.

In some embodiments, during handover, the source gNB may forward configuration regarding the linking aspect of the resource location with PDCP COUNT to the target gNB, and the target gNB may perform reconfiguration of resources while maintaining continuation of PDCP.

In some embodiments, for periodic traffic, if a packet is not successfully received by the receiver, PDCP COUNT is still reserved based on the resource location. For example, if a packet corresponding to PDCP COUNT 1 is lost, the sender uses COUNT 2 for the next resource and the receiver also uses COUNT 2 for PDCP layer processing, independent of the sender/receiver status, while COUNT may be determined only by the resource location (e.g., based only on timing).

The message authentication code (MAC-I) field may be used for integrity protection. This field is optional and UP integrity protection is disabled when MAC-I is not present.

Since PDCP COUNT is used for ciphering and integrity protection, MAC-I can be calculated based on the above-described technical scheme without explicit transmission of PDCP SN.

In summary, the header of the PDCP layer can be simplified. For example, if ROHC, EHC, and PDCP status reports are not required, the D/C field may not be included; the MAC-I field may not be included if integrity protection is not required; and if the PDCP COUNT/PDCP SN is linked to a resource location, the PDCP SN field may not be included. This can reduce the processing delay to some extent. Further, if these three conditions are simultaneously satisfied, the PDCP layer may be header-less. Therefore, the processing delay can be further reduced.

Figure 5 illustrates a flow diagram of a method 500 for a header-less PDCP layer or a header reduced PDCP layer, according to some embodiments of the present disclosure. Method 500 may be performed by a UE (e.g., UE101) or a RAN node (e.g., RAN node 111). Method 500 may include steps 510 and 520.

At 510, one or more packets received from a communication element may be decoded. The header of each of the one or more packets may not include a PDCP SN field for indicating a PDCP SN of the corresponding packet of the one or more packets.

At 520, a PDCP SN can be determined based on a mapping between PDCP SNs and resources for a corresponding packet.

In some embodiments, method 500 may include more or fewer steps. The present disclosure is not limited in this respect. Further, the method 500 may be understood in conjunction with the embodiments described above.

In some embodiments, the header may not include the D/C field when ROHC/EHC and PDCP status reports are not required.

In some embodiments, the MAC-I of the respective packet may be verified based in part on the PDCP SN.

In some embodiments, the PDCP SNs may be sequentially increased based on the resource allocation for one or more packets.

In some embodiments, the resource allocation for the one or more packets may comprise an SPS/CG resource allocation. The PDCP SN corresponding to the starting resource of the SPS/CG resource allocation may be set to 0.

In some embodiments, the mapping may be determined based on RRC signaling.

In some embodiments, the PDCP COUNT value of the corresponding packet may be determined based in part on the PDCP SN.

In some embodiments, a keystream (keystream) may be generated based in part on the PDCP COUNT value prior to decoding the corresponding packet.

The method 500 describes a method for a header-less PDCP layer or a header-reduced PDCP layer from the perspective of a receiving party. Figure 6 illustrates a flow diagram of a method 600 for a headerless PDCP layer or a header reduced PDCP layer, which describes a method for the headerless PDCP layer or the header reduced PDCP layer from the perspective of the sender, in accordance with some embodiments of the present disclosure. The method 600 may be performed by a UE (e.g., UE101) or a RAN node (e.g., RAN node 111). Method 600 may include step 610.

At 610, one or more packets may be encoded for transmission to a communication element. The header of each of the one or more packets may not include a PDCP SN field for indicating a PDCP SN of the corresponding packet of the one or more packets. The PDCP SNs may be based on a mapping between the PDCP SNs and resources used for the corresponding packets.

In some embodiments, method 600 may include more or different steps. The present disclosure is not limited in this respect. Further, the method 600 may be understood in conjunction with the embodiments described above.

In some cases where the method 600 is performed by a RAN node (e.g., a gNB), the mapping may be signaled to the UE via RRC signaling. Further, the mapping may be notified to the target gNB of the UE during handover.

Some embodiments will be described below to minimize real-time processing of encryption/decryption.

Such as the third generation partnership project; technical specification group services and system aspects; figure d.2.1.1-1 in the security architecture and procedure of the 5G system, release 16 (3GPP TS 33.501V16.3.0(2020-07)), for ciphering there are some inputs, such as security key, COUNT (PDCP COUNT, incremented by 1 for each packet within the DRB although this value is changing, this value is known, based on the embodiments described in this disclosure, bearer ID, direction (UL/DL), and length (which determines the input/output size of the keystream block). From the input of the block, the keystream is generated in advance, independent of the actual packets/messages. The keystream is then exclusive-or (XOR) with the input/SDU. Decryption requires the reverse process.

Such as the third generation partnership project; technical specification group radio access network; NR; radio Resource Control (RRC) protocol specification Release 16 (3GPP TS 38.331V16.1.0(2020-07), AS applies four different security keys, one for integrity protection (K) for RRC signaling_RRCint) Encryption (K) for RRC signaling_RRCenc) Integrity protection (K) for user data_UPint) Encryption (K) for user data_UPenc). All four AS keys are derived from K_gNBA key. The security key for UP encryption is known in advance for a particular DRB. The security key may be changed upon a handover or other event.

The processing load of the encryption/decryption operation may be large. However, the compute intensive tasks (generating keystream blocks) may be processed offline (e.g., not in a latency critical data path).

In some embodiments, one way to accelerate the encryption process is to pre-generate a keystream. The main problem with pre-generating a keystream for each packet is that the length of the packet is unknown. Thus, the keystream can be pre-generated for a maximum length, which results in significant computational power waste.

In some embodiments, a fixed packet size may be configured so that pre-generation of the keystream may be performed without waiting for actual packets to arrive. The benefit of a fixed packet size is that no computational resources are wasted, since the keystream block need not be generated for the largest possible size. When the actual packet arrives, a simple xor operation with the keystream can be performed. Thus, for a fixed packet size, the encryption/decryption operation can be very fast.

In some embodiments, one way to handle variable packet sizes is to introduce fragmentation in layers above the PDCP. Each DRB may be configured with a threshold value and the upper layer packet may be fragmented if the actual size of the upper layer packet is greater than the threshold value. Keystream blocks having a threshold size may then be pre-generated. There is a waste of computational resources for the last segment, but the overall computational resource requirements are much less than normal (handling up to the PDCP SDU size limit, e.g. 9000 bytes in NR).

In some embodiments, another possible approach is to generate only keystream blocks of a particular size (e.g., an average size), and perform dynamic processing to generate other keystream blocks for the remaining size of the actual packet. In this case, the worst-case delay requirement is met, e.g., the longest time to generate the remaining blocks is within the delay budget. For example, the size of the upcoming packet may be predicted, e.g., 1500 bytes. The key stream may be generated in advance based on a size of 1500 bytes. If the actual size of the packet is 2000 bytes, a further keystream can be generated from the remaining 500 byte size. The processing delay is only due to the generation of the further keystream. In this way, the delay can be reduced.

Security algorithms have two categories: one is block-based encryption (e.g., Advanced Encryption Standard (AES)), where every 16 bytes are processed independently and a keystream can be generated every 16 bytes (adjacent keystream blocks are generated independently)); the other is stream-based encryption (e.g., ZUC), which operates like a linear shift register and is difficult to maintain state to make it operational.

Different embodiments based on fixed packet size, threshold and average size may be performed adaptively for different security algorithms and are not described in detail herein.

Fig. 7 illustrates a flow diagram of a method 700 for pre-generating a keystream, in accordance with some embodiments of the disclosure. Method 700 may be performed by a UE (e.g., UE101) or a RAN node (e.g., RAN node 111). Method 700 may include steps 710 and 720.

At 710, prior to decoding a packet, a keystream for the packet can be generated based in part on a fixed size value configured for the packet.

At 720, encryption or decryption may be performed based on the keystream.

In some embodiments, method 700 may include more or different steps. The present disclosure is not limited in this respect. Further, the method 700 may be understood in conjunction with the embodiments described above.

In some embodiments, when the actual size of the packet is greater than the fixed size value, the packet may be partitioned based on the fixed size value.

In some embodiments, the keystream is a first keystream and, when the actual size of a packet is greater than a fixed size value, a second keystream for the packet may be generated based on the actual size of the packet minus the fixed size value. The first keystream and the second keystream are concatenated to form a final keystream for encryption or decryption.

The above embodiments mainly relate to the PDCP layer. Next, an embodiment will be described with respect to the MAC layer.

Multiplexing and concatenation are performed at the MAC layer and differentiated using headers. Fig. 8 illustrates an example of a MAC subheader according to some embodiments of the present disclosure.

In NR, the MAC subheader includes three parts: a logical channel id (lcid) field to identify the LCH/MAC CE, an F field to identify the subheader length, and L field(s) (possibly one or two bytes, indicated by the F field) to identify the size of the MAC SDU.

In some embodiments, the MAC layer may be transparent if the following conditions/restrictions are met:

only one MAC SDU per MAC PDU, e.g., no MAC multiplexing for MAC SDUs and MAC CEs.

MAC SDUs have a fixed size and therefore do not need to indicate the length of the SDU and do not need MAC subheader indication padding. In the whole L2, only the MAC layer can introduce padding (padding indication is needed if the MAC SDU size is smaller than the Transport Block Size (TBS)).

The PHY layer does not provide granularity of one byte due to channel coding limitations. For example in the third generation partnership project; technical specification group radio access network; NR; in table 5.1.3.2-1 of the physical layer flow of data (release 16) (3GPP TS 38.214V16.2.0(2020-06)), when TBS < 192, the granularity is 8 bits (1 byte); otherwise, the granularity is 2 bytes, 4 bytes, 8 bytes, etc. However, as long as the MAC SDU has a fixed size (for both DL and UL this can be signaled separately from the TBS), even padding is not a problem since the padding length is known. Padding addition/deletion may be performed in the MAC, and even in the RLC/PDCP.

Typically, the TBS varies based on what PHY provides, depending on the channel. The packet size may be fixed. However, the TBS may be chosen such that segmentation may be avoided.

Similar to embodiments in the PDCP layer, the transparent MAC mode may be linked to a specific resource (e.g., SPS/CG) so that the sender/receiver can bypass the MAC layer for the configured resource (knowing that for a specific resource there is no MAC multiplexing and the MAC can be bypassed).

Fig. 9 illustrates a flow diagram of a method 900 for a headerless MAC layer in accordance with some embodiments of the disclosure. Method 900 may be performed by a UE (e.g., UE101) or a RAN node (e.g., RAN node 111). Method 900 may include step 910.

At 910, a MAC PDU received from a communication element can be decoded in a transparent MAC mode. The MAC PDU may not include a MAC header, the MAC PDU corresponds to a single MAC SDU, and the size of the MAC SDU is fixed.

In some embodiments, method 900 may include more or different steps. The present disclosure is not limited in this respect. Further, the method 900 may be understood in conjunction with the above-described embodiments.

In some embodiments, the MAC PDU may be configured with resources configured for transparent MAC mode.

The above embodiments describe the transparent L2 layer(s), the header-less L2 layer(s), or the L2 layer with simplified headers(s) primarily based on the PDCP layer and the MAC layer. However, these layers are merely examples, and other layers of the L2 layer may be transparent or header-less, or include a simplified header. The present disclosure is not limited in this respect.

According to the concepts of the present disclosure, when a certain layer is transparent, there are fewer layers involved in data processing, and thus lower latency can be achieved. When a layer is header-less or its headers are reduced, there is less processing and duplication/buffering, which may also reduce latency. Furthermore, the reduction of delay in L2 helps to reduce the overall delay of the user plane. Reducing latency may enable more types of services and provide a better user experience.

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

Network 1000 may include a UE 1002, which may include any mobile or non-mobile computing device designed to communicate with RAN 1004 via an over-the-air connection. The UE 1002 may be, but is not limited to, a smartphone, a tablet, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, an instrument cluster, a heads-up display device, an in-vehicle diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic/engine control unit, an electronic/engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an internet of things device, and/or the like.

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

In some embodiments, the UE 1002 may also communicate with the AP 1006 over an over-the-air connection. The AP 1006 may manage WLAN connections that may be used to offload some/all network traffic from the RAN 1004. The connection between the UE 1002 and the AP 1006 may be with any IEEE 80213 protocol consistent, wherein the AP 1006 may be wireless fidelity

A router. In some embodiments, the UE 1002, RAN 1004, and AP 1006 may utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA)/lightweight ip (lwip)). Cellular WLAN aggregation may involve a UE 1002 configured by a RAN 1004 utilizing both cellular radio resources and WLAN resources.

RAN 1004 may include one or more access nodes, e.g., AN 1008. The AN 1008 may terminate the air interface protocols of the UE 1002 by providing access stratum protocols including RRC, Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and L1 protocols. In this manner, AN 1008 may enable data/voice connectivity between CN 1020 and UE 1002. In some embodiments, AN 1008 may be implemented in a separate device or as one or more software entities running on a server computer, as part of a virtual network, for example, which may be referred to as a CRAN or virtual baseband unit pool. AN 1008 may be referred to as a Base Station (BS), a gNB, a RAN node, AN evolved node b (eNB), a next generation eNB (ng-eNB), a node b (nodeb), a roadside unit (RSU), a TRxP, a TRP, and so on. The AN 1008 may be a macrocell base station or a low power base station that provides a microcell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.

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

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

The RAN 1004 may provide an air interface over a licensed spectrum or an unlicensed spectrum. To operate in unlicensed spectrum, a node may use a Licensed Assisted Access (LAA), enhanced LAA (elaa), and/or further enhanced LAA (felaa) mechanism based on Carrier Aggregation (CA) technology with PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform a media/carrier sensing operation based on, for example, a Listen Before Talk (LBT) protocol.

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

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

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

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

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

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

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

In some embodiments, CN 1020 may be LTE CN 1022, which may also be referred to as Evolved Packet Core (EPC). LTE CN 1022 may include a Mobility Management Entity (MME)1024, a Serving Gateway (SGW)1026, a Serving GPRS Support Node (SGSN)1028, a Home Subscriber Server (HSS)1030, a Proxy Gateway (PGW)1032, and a policy control and charging rules function (PCRF)1034, which are coupled to each other by an interface (or "reference point") as shown. The functions of the elements of LTE CN 1022 may be briefly introduced as follows.

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

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

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

The HSS 1030 may comprise a database for network users that includes subscription related information that supports network entities handling communication sessions. The HSS 1030 may provide support for routing/roaming, authentication, admission, naming/addressing resolution, location dependency, etc. An S6a reference point between the HSS 1030 and the MME 1024 may enable the transmission of subscription and authentication data to authenticate/grant a user access to the LTE CN 1020.

PGW 1032 may terminate the SGi interface towards a Data Network (DN)1036 that may include an application/content server 1038. PGW 1032 may route data packets between LTE CN 1022 and data network 1036. PGW 1032 may be coupled with SGW 1026 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 1032 may also include a node (e.g., PCEF) for policy enforcement and charging data collection. Additionally, the SGi reference point between PGW 1032 and data network 1036 may be, for example, an operator external public, private PDN, or operator internal packet data network for providing IMS services. PGW 1032 may be coupled with PCRF 1034 via the Gx reference point.

The PCRF 1034 is a policy and charging control element of the LTE CN 1022. The PCRF 1034 can be communicatively coupled to the application/content server 1038 to determine the appropriate QoS and charging parameters for the service flow. The PCRF 1032 may provide the associated rules to the PCEF (via the Gx reference point) with the appropriate TFT and QCI.

In some embodiments, CN 1020 may be a 5G core network (5GC) 1040. The 5GC 1040 may include an authentication server function (AUSF)1042, an access and mobility management function (AMF)1044, a Session Management Function (SMF)1046, a User Plane Function (UPF)1048, a Network Slice Selection Function (NSSF)1050, a network open function (NEF)1052, an NF storage function (NRF)1054, a Policy Control Function (PCF)1056, a Unified Data Management (UDM)1058, and an Application Function (AF)1060, which are coupled to one another by interfaces (or "reference points") as shown. The functions of the elements of the 5GC 1040 may be briefly described as follows.

The AUSF 1042 may store data for authentication of the UE 1002 and process authentication related functions. AUSF 1042 may facilitate a common authentication framework for various access types. The AUSF 1042 may also exhibit a Nausf service based interface in addition to communicating with other elements of the 5GC 1040 through reference points as shown.

The AMF 1044 may allow other functions of the 5GC 1040 to communicate with the UE 1002 and the RAN 1004 and subscribe to notifications regarding mobility events of the UE 1002. The AMF 1044 may be responsible for registration management (e.g., registering the UE 1002), connection management, reachability management, mobility management, lawful interception of AMF related events, and access authentication and permissions. AMF 1044 may provide for the transmission of Session Management (SM) messages between UE 1002 and SMF 1046 and act as a transparent proxy for routing SM messages. The AMF 1044 may also provide for the transmission of SMS messages between the UE 1002 and the SMSF. The AMF 1044 may interact with the AUSF 1042 and the UE 1002 to perform various security anchoring and context management functions. Further, the AMF 1044 may be a termination point of the RAN CP interface, which may include or be an N2 reference point between the RAN 1004 and the AMF 1044; the AMF 1044 may act as a termination point for NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF 1044 may also support NAS signaling with the UE 1002 over the N3 IWF interface.

The SMF 1046 may be responsible for SM (e.g., session establishment, tunnel management between UPF 1048 and AN 1008); UE IP address assignment and management (including optional permissions); selection and control of the UP function; configuring flow control at UPF 1048 to route the flow to the appropriate destination; termination of the interface to the policy control function; controlling a portion of policy enforcement, charging, and QoS; lawful interception (for SM events and interface to the LI system); terminate the SM portion of the NAS message; a downlink data notification; initiating AN-specific SM message (sent to AN 1008 on N2 through AMF 1044); and determining an SSC pattern for the session. SM may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 1002 and the data network 1036.

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

The NSSF 1050 may select a set of network slice instances that serve the UE 1002. NSSF 1050 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and mapping to a single NSSAI (S-NSSAI) of the subscription, if desired. The NSSF 1050 may also determine a set of AMFs to be used to serve the UE 1002, or determine a list of candidate AMFs, based on a suitable configuration and possibly by querying the NRF 1054. The selection of a set of network slice instances for the UE 1002 may be triggered by the AMF 1044 (with which the UE 1002 registers by interacting with the NSSF 1050), which may result in a change in the AMF. NSSF 1050 may interact with AMF 1044 via the N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). Further, NSSF 1050 may expose an interface based on NSSF services.

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

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

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

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

AF 1060 can provide application impact on traffic routing, provide access to NEF, and interact with a policy framework for policy control.

In some embodiments, the 5GC 1040 may enable edge computing by selecting an operator/third party service that is geographically close to the point at which the UE 1002 attaches to the network. This may reduce latency and load on the network. To provide an edge computing implementation, the 5GC 1040 may select a UPF 1048 near the UE 1002 and perform traffic steering from the UPF 1048 to the data network 1036 through an N6 interface. This may be based on the UE subscription data, UE location, and information provided by AF 1060. In this way, AF 1060 can affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow AF 1060 to interact directly with the relevant NFs when AF 1060 is considered a trusted entity. In addition, AF 1060 can expose interfaces based on Naf services.

Data network 1036 may represent various network operator services, internet access, or third party services that may be provided by one or more servers including, for example, application/content server 1038.

Fig. 11 schematically illustrates a wireless network 1100 in accordance with various embodiments. The wireless network 1100 may include a UE 1102 in wireless communication with AN 1104. The UE 1102 and AN 1104 can be similar to and substantially interchangeable with the co-located components described elsewhere herein.

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

UE 1102 can include a host platform 1108 coupled to a modem platform 1110. Host platform 1108 may include application processing circuitry 1112, which may be coupled with protocol processing circuitry 1114 of modem platform 1110. The application processing circuitry 1112 may run various applications of source/receiver application data for the UE 1102. The application processing circuitry 1112 may also implement one or more layers of operations to send/receive application data to/from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

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

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

Modem platform 1110 may further include transmit circuitry 1118, receive circuitry 1120, RF circuitry 1122, and RF front end (RFFE) circuitry 1124, which may include or be connected to one or more antenna panels 1126. Briefly, the transmit circuit 1118 may include a digital-to-analog converter, a mixer, an Intermediate Frequency (IF) component, and the like; the receive circuit 1120 may include analog-to-digital converters, mixers, IF components, and the like; RF circuitry 1122 may include low noise amplifiers, power tracking components, and the like; RFFE circuitry 1124 can include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of components of transmit circuitry 1118, receive circuitry 1120, RF circuitry 1122, RFFE circuitry 1124, and antenna panel 1126 (collectively, "transmit/receive components") may be specific to the details of a particular implementation, e.g., whether the communication is TDM or FDM, at mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, and may be arranged in the same or different chips/modules, etc.

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

UE reception may be established by and via antenna panel 1126, RFFE circuitry 1124, RF circuitry 1122, receive circuitry 1120, digital baseband circuitry 1116, and protocol processing circuitry 1114. In some embodiments, the antenna panel 1126 may receive transmissions from the AN 1104 by receiving beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 1126.

UE transmissions may be established via and through protocol processing circuitry 1114, digital baseband circuitry 1116, transmit circuitry 1118, RF circuitry 1122, RFFE circuitry 1124, and antenna panel 1126. In some embodiments, the transmit component of UE 1104 may apply a spatial filter to the data to be transmitted to form a transmit beam transmitted by the antenna elements of antenna panel 1126.

Similar to UE 1102, AN 1104 may include a host platform 1128 coupled to a modem platform 1130. Host platform 1128 may include application processing circuitry 1132 coupled to protocol processing circuitry 1134 of modem platform 1130. The modem platform may also include digital baseband circuitry 1136, transmit circuitry 1138, receive circuitry 1140, RF circuitry 1142, RFFE circuitry 1144, and antenna panel 1146. The components of AN 1104 may be similar to, and substantially interchangeable with, the synonymous components of UE 1102. In addition to performing data transmission/reception as described above, the components of AN 1108 may also perform various logical functions including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 12 illustrates example components of a device 1200 according to some embodiments. In some embodiments, device 1200 may include application circuitry 1202, baseband circuitry 1204, Radio Frequency (RF) circuitry 1206, Front End Module (FEM) circuitry 1208, one or more antennas 1210, and Power Management Circuitry (PMC)1212 coupled together at least as shown. The illustrated components of the apparatus 1200 may be included in a UE or AN. In some embodiments, the apparatus 1200 may include fewer elements (e.g., the AN may not use the application circuitry 1202 but include a processor/controller to process IP data received from the EPC). In some embodiments, device 1200 may include additional elements, such as memory/storage devices, displays, cameras, sensors, or input/output (I/O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., for a Cloud-RAN (C-RAN) implementation, the circuitry may be included separately in more than one device).

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

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

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

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

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

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

In some embodiments, the mixer circuitry 1206a of the transmit signal path may be configured to upconvert the input baseband signal based on a synthesis frequency provided by the synthesizer circuitry 1206d to generate an RF output signal for the FEM circuitry 1208. The baseband signal may be provided by baseband circuitry 1204 and may be filtered by filter circuitry 1206 c.

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

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

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

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

The synthesizer circuit 1206d may be configured to synthesize an output frequency for use by the mixer circuit 1206a of the RF circuit 1206 based on the frequency input and the divider control input. In some embodiments, the synthesizer circuit 1206d may be a fractional-N/N +1 type synthesizer.

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

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

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

The FEM circuitry 1208 may include a receive signal path that may include circuitry configured to operate on RF signals received from the one or more antennas 1210, amplify the received signals, and provide amplified versions of the received signals to the RF circuitry 1206 for further processing. The FEM circuitry 1208 may also include a transmit signal path that may include circuitry configured to amplify signals provided by the RF circuitry 1206 for transmission by one or more of the one or more antennas 1210. In various embodiments, amplification across the transmit signal path or the receive signal path may be done only in the RF circuitry 1206, only in the FEM 1208, or in both the RF circuitry 1206 and the FEM 1208.

In some embodiments, FEM circuitry 1208 may include TX/RX switches to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a Low Noise Amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuitry 1206). The transmit signal path of the FEM circuitry 1208 may include a Power Amplifier (PA) to amplify an input RF signal (e.g., provided by the RF circuitry 1206) and one or more filters to generate an RF signal for subsequent transmission (e.g., by one or more of the one or more antennas 1210).

In some embodiments, PMC 1212 may manage power provided to baseband circuitry 1204. Specifically, PMC 1212 may control power selection, voltage scaling, battery charging, or DC-DC conversion. PMC 1212 may typically be included when device 1200 is capable of being powered by a battery, for example, when the device is included in a UE. PMC 1212 may improve power conversion efficiency while providing desired implementation size and heat dissipation characteristics.

Although figure 12 shows the PMC 1212 coupled only to the baseband circuitry 1204. However, in other embodiments, PMC 1212 may additionally or alternatively be coupled with and perform similar power management operations on other components, such as, but not limited to, application circuitry 1202, RF circuitry 1206, or FEM 1208.

In some embodiments, PMC 1212 may control or otherwise be part of various power saving mechanisms of device 1200. For example, if the device 1200 is in an RRC _ Connected state where the device 1200 is still Connected to the RAN node when it expects to receive traffic soon, and then may enter a state referred to as discontinuous reception mode (DRX) after a period of inactivity. During this state, the device 1200 may be powered down for a brief interval of time, thereby saving power.

If there is no data traffic activity for an extended period of time, device 1200 may transition to an RRC _ Idle state in which device 1200 is disconnected from the network and no operations such as channel quality feedback, handovers, etc. are performed. The device 1200 enters a very low power state and performs paging, where the device 1200 again periodically wakes up to listen to the network and then powers down again. Device 1200 may not receive data in this state and it may transition back to the RRC Connected state in order to receive data.

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

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

In some embodiments, AN or RAN node herein may comprise a server as described above.

Fig. 13 illustrates an example of an infrastructure device 1300 according to various embodiments. Infrastructure equipment 1300 (or "system 1300") may be implemented as base stations, radio heads, RAN nodes, and so on, such as RAN nodes 111 and 112 shown and described previously. In other examples, system 1300 may be implemented in or by a UE, application server(s) 130, and/or any other elements/devices discussed herein. System 1300 may include one or more of the following: an application circuit 1305, a baseband circuit 1310, one or more radio front-end modules 1315, a memory 1320, a Power Management Integrated Circuit (PMIC) 1325, a power tee circuit 1330, a network controller 1335, a network interface connector 1340, a satellite positioning circuit 1345, and a user interface 1350. In some embodiments, device 1300 may include additional elements, such as memory/storage, a display, a camera, sensors, or input/output (I/O) interface elements. In other embodiments, the components described below may be included in more than one device (e.g., for a cloud RAN (C-RAN) implementation, the circuitry may be included separately in more than one device).

As used herein, the term "circuitry" may refer to, be part of, or include hardware components such as the following configured to provide the described functionality: electronic circuits, logic circuits, processors (shared, dedicated, or group) and/or memories (shared, dedicated, or group), Application Specific Integrated Circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), Programmable Logic Devices (PLDs), complex PLDs (complex PLDs, CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or System on Chip (socs)), Digital Signal Processors (DSPs), and so forth. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. Furthermore, the term "circuitry" may also refer to a combination of one or more hardware elements (or circuitry used in an electrical or electronic system) and program code for performing the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

The terms "application circuitry" and/or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry". As used herein, the term "processor circuit" may refer to, be part of, or include circuitry that: the circuit is capable of sequentially and automatically performing a sequence of arithmetic or logical operations; and recording, storing and/or transmitting digital data. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, physical Central Processing Units (CPUs), single-core processors, dual-core processors, tri-core processors, quad-core processors, and/or any other device capable of executing or otherwise manipulating computer-executable instructions, such as program code, software modules, and/or functional processes.

The application circuitry 1305 may include one or more Central Processing Unit (CPU) cores and one or more of the following: a cache memory, a Low Drop Out (LDO) regulator, an interrupt controller, a Serial Interface such as SPI, I2C, or a Universal programmable Serial Interface module, a Real Time Clock (RTC), a timer-counter including interval and watchdog timers, a Universal input/output (I/O or IO), a memory card controller such as a Secure Digital (SD)/multimedia card (MMC), a Universal Serial Bus (USB) Interface, a Mobile Industrial Processor Interface (MIPI) Interface, and a Joint Test Access Group (JTAG) Test Access port. By way of example, the application circuitry 1305 may include one or more Intels

Or

A processor; ultramicron semiconductor (Advanced Micro Devices, AMD)

A processor, an Accelerated Processing Unit (APU), or

A processor; and so on. In some embodiments, system 1300 may not utilize application circuitry 1305, but may instead include, for example, a dedicated processor/controller to process IP data received from the EPC or 5 GC.

Additionally or alternatively, the application circuitry 1305 may include circuitry such as (but not limited to) the following: one or more Field Programmable Devices (FPDs), such as Field Programmable Gate Arrays (FPGAs), etc.; programmable Logic Devices (PLDs), such as complex PLDs (cplds), high capacity PLDs (hcplds), and the like; ASICs, such as structured ASICs and the like; programmable soc (psoc); and so on. In such embodiments, the circuitry of the application circuitry 1305 may comprise a logic block or logic architecture, including other interconnected resources, that may be programmed to perform various functions, such as the processes, methods, functions, etc., of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuitry 1305 may include storage units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., Static Random Access Memory (SRAM), antifuse, etc.) for storing logic blocks, logic architectures, data, etc. in a lookup table (LUT), and so forth.

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

The user interface circuitry 1350 may include one or more user interfaces designed to enable user interaction with the system 1300 or peripheral component interfaces designed to enable interaction with peripheral components of the system 1300. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., a Light Emitting Diode (LED)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, and so forth. The peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a Universal Serial Bus (USB) port, an audio jack, a power supply interface, and the like.

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

The memory circuitry 1320 may include one or more of the following: volatile memory including Dynamic Random Access Memory (DRAM) and/or Synchronous Dynamic Random Access Memory (SDRAM); and nonvolatile memory (NVM), including high speed electrically erasable memory (often referred to as flash memory), phase change random access memory (PRAM), Magnetoresistive Random Access Memory (MRAM), and the like, and may include data from one or more of the above-mentioned sources

And

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

The PMIC 1325 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources such as a battery or a capacitor. The power alarm detection circuit may detect one or more of power down (under voltage) and surge (over voltage) conditions. Power tee circuit 1330 can provide power drawn from a network cable to provide both power supply and data connectivity to infrastructure device 1300 using a single cable.

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

The positioning circuitry 1345 may include circuitry to receive and decode signals transmitted by one or more constellations of navigation satellites of a Global Navigation Satellite System (GNSS). Examples of a Navigation Satellite Constellation (or GNSS) may include the Global Positioning System (GPS) in the united states, the Global Navigation System (GLONASS) in russia, the galileo System in the european union, the beidou Navigation Satellite System in china, the regional Navigation System or the GNSS augmentation System (e.g., Indian Constellation Navigation with Indian Navigation, NAVIC), the Quasi-Zenith Satellite System (QZSS) in japan, the Satellite Integrated Doppler orbit imaging and Radio Positioning in france (dongler and Radio-Positioning Integrated by Satellite System, DORIS), and so forth. The positioning circuitry 1345 may include various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, and so forth to facilitate communication over-the-air (OTA) communication) to communicate with components of a positioning network (e.g., navigation satellite constellation nodes).

Nodes or satellites of the navigation satellite constellation(s) ("GNSS nodes") may provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight that may be used by GNSS receivers (e.g., positioning circuitry 1345 and/or positioning circuitry implemented by UEs 101, 102, etc.) to determine their GNSS positions. The GNSS signals may include a pseudorandom code known to the GNSS receiver (e.g., a sequence of ones and zeros) and a message including a time of transmission ToT (e.g., a defined point in the pseudorandom code sequence) of code epochs and a GNSS node position at ToT. A GNSS receiver may monitor/measure GNSS signals transmitted/broadcast by multiple GNSS nodes (e.g., four or more satellites) and solve various equations to determine a corresponding GNSS location (e.g., spatial coordinates). The GNSS receiver also implements a clock that is generally less stable and accurate than the atomic clock of the GNSS node, and the GNSS receiver may use the measured GNSS signals to determine a deviation of the GNSS receiver from real time (e.g., a deviation of the GNSS receiver clock from the GNSS node time). In some embodiments, the Positioning circuitry 1345 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a master Timing clock to perform position tracking/estimation without GNSS assistance.

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

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

Fig. 14 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 14 shows a diagrammatic representation of hardware resources 1400 that includes one or more processors (or processor cores) 1410, one or more memory/storage devices 1420, and one or more communication resources 1430, each of which may be communicatively coupled via a bus 1440. Hardware resources 1400 may be part of a UE, AN, or LMF. For embodiments utilizing node virtualization (e.g., NFV), hypervisor 1402 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 1400.

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

The memory/storage 1420 may include main memory, disk storage, or any suitable combination thereof. Memory/storage 1420 may include, but is not limited to, any type of volatile or non-volatile memory, such as Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state storage, and the like.

The communication resources 1430 may include interconnection or network interface components or other suitable devices to communicate with one or more peripherals 1404 or one or more databases 1406 via a network 1408. For example, the communication resources 1430 can include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, bluetooth components (e.g., bluetooth low energy), Wi-Fi components, and other communication components.

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

The following paragraphs describe examples of various embodiments.

Example 1 includes an apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: decoding one or more packets received from a communication element via the interface circuitry, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets; and determining the PDCP SN based on a mapping between the PDCP SN and resources for the corresponding packet.

Example 2 includes the apparatus of example 1, wherein the header does not include a D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status reporting are not required.

Example 3 includes the apparatus of example 1 or 2, wherein the processor circuit is further to: verifying a message authentication code (MAC-I) of the corresponding packet based in part on the PDCP SN.

Example 4 includes the apparatus of example 1, wherein the PDCP SNs are sequentially incremented based on a resource allocation for the one or more packets.

Example 5 includes the apparatus of example 4, wherein the resource allocation for the one or more packets includes a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

Example 6 includes the apparatus of example 1, wherein the mapping is determined based on Radio Resource Control (RRC) signaling.

Example 7 includes the apparatus of example 1, wherein the processor circuit is further to: determining a PDCP count value of the corresponding packet based in part on the PDCP SNs.

Example 8 includes the apparatus of example 7, wherein the processor circuit is further to: generating a keystream based in part on the PDCP count value prior to decoding the corresponding packet.

Example 9 includes the apparatus of any one of examples 1 to 8, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Example 10 includes an apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: encoding one or more packets for transmission to a communication element via the interface circuit, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets, wherein the PDCP SN is based on a mapping between the PDCP SN and resources for the respective packet.

Example 11 includes the apparatus of example 10, wherein the header does not include a D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

Example 12 includes the apparatus of example 10, wherein the PDCP SNs are sequentially incremented based on a resource allocation for the one or more packets.

Example 13 includes the apparatus of example 12, wherein the resource allocation for the one or more packets comprises a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

Example 14 includes the apparatus of any one of examples 10 to 13, wherein the communication element comprises a User Equipment (UE).

Example 15 includes the apparatus of example 14, wherein the processor circuit is further to: notifying the UE of the mapping via Radio Resource Control (RRC) signaling.

Example 16 includes the apparatus of example 14, wherein the processor circuit is further to: notifying a target next generation node B (gNB) of the UE of the mapping during handover.

Example 17 includes the apparatus of any one of examples 10 to 13, wherein the communication element comprises a next generation node b (gnb).

Example 18 includes an apparatus comprising: a memory; and a processor circuit coupled with the memory, wherein the processor circuit is to: generating a keystream for a packet based, in part, on a fixed size value configured for the packet prior to decoding the packet; and performing encryption or decryption based on the keystream, and wherein the memory is to store the fixed-size value.

Example 19 includes the apparatus of example 18, wherein the processor circuit is further to: when the actual size of the packet is greater than the fixed size value, the packet is partitioned based on the fixed size value.

Example 20 includes the apparatus of example 18, wherein the keystream is a first keystream, and wherein the processor circuit is further to: when the actual size of the packet is greater than the fixed size value, generating a second keystream for the packet based on the actual size of the packet minus the fixed size value after decoding the packet.

Example 21 includes an apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit, wherein the processor circuit is configured to: in a transparent Medium Access Control (MAC) mode, decoding a MAC Protocol Data Unit (PDU) received from a communication element via the interface circuit, wherein the MAC PDU does not include a MAC header, the MAC PDU corresponds to a single MAC Service Data Unit (SDU), and a size of the MAC SDU is fixed.

Example 22 includes the apparatus of example 21, wherein the MAC PDU is configured with resources configured for the transparent MAC mode.

Example 23 includes the apparatus of example 21 or 22, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Example 24 includes a method comprising: decoding one or more packets received from a communication element, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets; and determining the PDCP SN based on a mapping between the PDCP SN and resources for the corresponding packet.

Example 25 includes the method of example 24, wherein the header does not include the D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

Example 26 includes the method of example 24 or 25, further comprising: verifying a message authentication code (MAC-I) of the corresponding packet based in part on the PDCP SN.

Example 27 includes the method of example 24, wherein the PDCP SNs are sequentially incremented based on a resource allocation for the one or more packets.

Example 28 includes the method of example 27, wherein the resource allocation for the one or more packets comprises a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

Example 29 includes the method of example 24, wherein the mapping is determined based on Radio Resource Control (RRC) signaling.

Example 30 includes the method of example 24, further comprising: determining a PDCP count value of the corresponding packet based in part on the PDCP SNs.

Example 31 includes the method of example 30, further comprising: generating a keystream based in part on the PDCP count value prior to decoding the corresponding packet.

Example 32 includes the method of any one of examples 24 to 31, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Example 33 includes a method, comprising: encoding one or more packets for transmission to a communication element, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets, wherein the PDCP SN is based on a mapping between the PDCP SN and resources for the respective packet.

Example 34 includes the method of example 33, wherein the header does not include the D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

Example 35 includes the method of example 33, wherein the PDCP SNs are sequentially incremented based on a resource allocation for the one or more packets.

Example 36 includes the method of example 35, wherein the resource allocation for the one or more packets includes a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

Example 37 includes the method of any one of examples 33 to 36, wherein the communication element comprises a User Equipment (UE).

Example 38 includes the method of example 37, further comprising: notifying the UE of the mapping via Radio Resource Control (RRC) signaling.

Example 39 includes the method of example 37, further comprising: notifying a target next generation node B (gNB) of the UE of the mapping during handover.

Example 40 includes the method of any one of examples 33 to 36, wherein the communication element comprises a next generation node b (gnb).

Example 41 includes a method, comprising: generating a keystream for a packet based, in part, on a fixed size value configured for the packet prior to decoding the packet; and performing encryption or decryption based on the keystream.

Example 42 includes the method of example 41, further comprising: when the actual size of the packet is greater than the fixed size value, the packet is partitioned based on the fixed size value.

Example 43 includes the method of example 41, wherein the keystream is a first keystream, and the method further comprises: when the actual size of the packet is greater than the fixed size value, generating a second keystream for the packet based on the actual size of the packet minus the fixed size value after decoding the packet.

Example 44 includes a method, comprising: in a transparent Medium Access Control (MAC) mode, a MAC Protocol Data Unit (PDU) received from a communication element is decoded, wherein the MAC PDU does not include a MAC header, the MAC PDU corresponds to a single MAC Service Data Unit (SDU), and a size of the MAC SDU is fixed.

Example 45 includes the method of example 44, wherein the MAC PDU is configured with resources configured for the transparent MAC mode.

Example 46 includes the method of example 44 or 45, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Example 47 includes an apparatus comprising: a component for decoding one or more packets received from a communication element, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets; and means for determining the PDCP SN based on a mapping between the PDCP SN and resources for the corresponding packet.

Example 48 includes the apparatus of example 47, wherein the header does not include the D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

Example 49 includes the apparatus of example 47 or 48, further comprising: means for verifying a message authentication code (MAC-I) of the corresponding packet based in part on the PDCP SN.

Example 50 includes the apparatus of example 47, wherein the PDCP SNs are sequentially incremented based on a resource allocation for the one or more packets.

Example 51 includes the apparatus of example 50, wherein the resource allocation for the one or more packets comprises a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

Example 52 includes the apparatus of example 47, wherein the mapping is determined based on Radio Resource Control (RRC) signaling.

Example 53 includes the apparatus of example 47, further comprising: means for determining a PDCP count value of the corresponding packet based in part on the PDCP SNs.

Example 54 includes the apparatus of example 53, further comprising: means for generating a keystream based in part on the PDCP count value prior to decoding the respective packet.

Example 55 includes the apparatus of any one of examples 47-54, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Example 56 includes an apparatus comprising: a component for encoding one or more packets for transmission to a communication element, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field for indicating a PDCP SN of a respective packet of the one or more packets, wherein the PDCP SN is based on a mapping between the PDCP SN and resources for the respective packet.

Example 57 includes the apparatus of example 56, wherein the header does not include the D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

Example 58 includes the apparatus of example 56, wherein the PDCP SNs are sequentially incremented based on a resource allocation for the one or more packets.

Example 59 includes the apparatus of example 58, wherein the resource allocation for the one or more packets comprises a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

Example 60 includes the apparatus of any one of examples 56 to 59, wherein the communication element comprises a User Equipment (UE).

Example 61 includes the apparatus of example 60, further comprising: means for notifying the UE of the mapping via Radio Resource Control (RRC) signaling.

Example 62 includes the apparatus of example 60, further comprising: means for notifying a target next generation node B (gNB) of the UE of the mapping during handover.

Example 63 includes the apparatus of any one of examples 56 to 59, wherein the communication element comprises a next generation node b (gnb).

Example 64 includes an apparatus comprising: means for generating a keystream for a packet based, in part, on a fixed size value configured for the packet prior to decoding the packet; and a component for performing encryption or decryption based on the keystream.

Example 65 includes the apparatus of example 64, further comprising: means for partitioning the packet based on the fixed size value when the actual size of the packet is greater than the fixed size value.

Example 66 includes the apparatus of example 64, wherein the keystream is a first keystream, and the apparatus further comprises: means for generating a second keystream for the packet based on the actual size of the packet minus the fixed size value after decoding the packet when the actual size of the packet is greater than the fixed size value.

Example 67 includes an apparatus comprising: means for decoding a MAC Protocol Data Unit (PDU) received from a communication element in a transparent Medium Access Control (MAC) mode, wherein the MAC PDU does not include a MAC header, the MAC PDU corresponds to a single MAC Service Data Unit (SDU), and a size of the MAC SDU is fixed.

Example 68 includes the apparatus of example 67, wherein the MAC PDU is configured with resources configured for the transparent MAC mode.

Example 69 includes the apparatus of example 67 or 68, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Example 70 includes a computer-readable medium having instructions stored thereon, which, when executed by a processor circuit, causes the processor circuit to perform the method of any of examples 24-46.

Example 71 includes a User Equipment (UE) as shown and described in the specification.

Example 72 includes a method performed at a User Equipment (UE) as shown and described in the specification.

Example 73 includes a next generation node b (gnb) as shown and described in the specification.

Example 74 includes a method performed at a next generation node b (gnb) as shown and described in the specification.

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

Claims (23)

1. An apparatus, comprising:

an interface circuit; and

a processor circuit coupled with the interface circuit,

wherein the processor circuit is to:

decoding one or more packets received from a communication element via the interface circuitry, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets; and

determining the PDCP SNs based on a mapping between the PDCP SNs and resources for the corresponding packet.

2. The apparatus of claim 1, wherein the header does not include a D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

3. The apparatus of claim 1, wherein the processor circuit is further to:

verifying a message authentication code (MAC-I) of the corresponding packet based in part on the PDCP SN.

4. The apparatus of claim 1, wherein the PDCP SN is incremented sequentially based on a resource allocation for the one or more packets.

5. The apparatus of claim 4, wherein the resource allocation for the one or more packets comprises a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

6. The apparatus of claim 1, wherein the mapping is determined based on Radio Resource Control (RRC) signaling.

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

determining a PDCP count value of the corresponding packet based in part on the PDCP SNs.

8. The apparatus of claim 7, wherein the processor circuit is further to:

generating a keystream based in part on the PDCP count value prior to decoding the corresponding packet.

9. The apparatus of any one of claims 1 to 8, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

10. An apparatus, comprising:

an interface circuit; and

a processor circuit coupled with the interface circuit,

wherein the processor circuit is to:

encoding one or more packets for transmission to a communication element via the interface circuit, wherein a header of each of the one or more packets does not include a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) field to indicate a PDCP SN of a respective packet of the one or more packets,

wherein the PDCP SNs are based on a mapping between the PDCP SNs and resources for the corresponding packets.

11. The apparatus of claim 10, wherein the header does not include a D/C field when robust header compression (ROHC)/Ethernet Header Compression (EHC) and PDCP status report are not required.

12. The apparatus of claim 10, wherein the PDCP SN is incremented in sequence based on a resource allocation for the one or more packets.

13. The apparatus of claim 12, wherein the resource allocation for the one or more packets comprises a semi-persistent scheduling (SPS)/Configuration Grant (CG) resource allocation, and wherein a PDCP SN corresponding to a starting resource of the SPS/CG resource allocation is set to 0.

14. The apparatus of any of claims 10 to 13, wherein the communication element comprises a User Equipment (UE).

15. The apparatus of claim 14, wherein the processor circuit is further to:

notifying the UE of the mapping via Radio Resource Control (RRC) signaling.

16. The apparatus of claim 14, wherein the processor circuit is further to:

notifying a target next generation node B (gNB) of the UE of the mapping during handover.

17. The apparatus of any of claims 10 to 13, wherein the communication element comprises a next generation node b (gnb).

18. An apparatus, comprising:

a memory; and

a processor circuit coupled with the memory,

wherein the processor circuit is to:

generating a keystream for a packet based, in part, on a fixed size value configured for the packet prior to decoding the packet; and

performing encryption or decryption based on the keystream, and

wherein the memory is to store the fixed size value.

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

when the actual size of the packet is greater than the fixed size value, the packet is partitioned based on the fixed size value.

20. The apparatus of claim 18, wherein the keystream is a first keystream, and wherein the processor circuit is further to:

when the actual size of the packet is greater than the fixed size value, generating a second keystream for the packet based on the actual size of the packet minus the fixed size value after decoding the packet.

21. An apparatus, comprising:

an interface circuit; and

a processor circuit coupled with the interface circuit,

wherein the processor circuit is to:

in a transparent Medium Access Control (MAC) mode, decoding a MAC Protocol Data Unit (PDU) received from a communication element via the interface circuit,

wherein the MAC PDU does not include a MAC header, the MAC PDU corresponds to a single MAC Service Data Unit (SDU), and a size of the MAC SDU is fixed.

22. The apparatus of claim 21, wherein the MAC PDU is configured with resources configured for the transparent MAC mode.

23. The apparatus of claim 21 or 22, wherein the communication element comprises a next generation node b (gnb) or a User Equipment (UE).

Images