CN112913169A

CN112913169A - Transmission, retransmission, and hybrid automatic repeat request (HARQ) for pre-configured uplink resources (PUR) in idle mode

Info

Publication number: CN112913169A
Application number: CN201980042948.4A
Authority: CN
Inventors: 巴拉特·什雷斯塔; 玛塔·马丁纳茨塔拉德尔; 林晓翔
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-11-01
Filing date: 2019-10-29
Publication date: 2021-06-04
Anticipated expiration: 2039-10-29
Also published as: EP3874649A1; EP3874649A4; CN112913169B; WO2020092415A1

Abstract

Techniques for a User Equipment (UE) for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3G5PP) network are disclosed. The UE may be configured to identify a D-PUR for transmission from the UE in idle mode to an evolved node b (enb). The UE may be configured to determine whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein the user data greater than the TBS is a first data segment and the remaining user data is a second data segment. The UE may be configured to multiplex the first data segment with a Radio Resource Control (RRC) resume request message when the user data is greater than the TBS.

Description

Transmission, retransmission, and hybrid automatic repeat request (HARQ) for pre-configured uplink resources (PUR) in idle mode

Background

Wireless systems typically include a plurality of User Equipment (UE) devices communicatively coupled to one or more Base Stations (BSs). The one or more BSs may be Long Term Evolution (LTE) Evolved node BS (eNB) or New Radio (NR) node BS (gNB), next Generation node BS (gNB), or new radio base stations (NR BS) that are communicatively couplable to one or more UEs through a Third-Generation Partnership Project (3GPP) network.

Next generation wireless communication systems are expected to be unified networks/systems with the goal of meeting very different and sometimes conflicting performance dimensions and services. New Radio Access Technology (RAT) is expected to support a wide range of usage scenarios, including Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mtc), Mission Critical Machine Type Communication (mtc), and similar service types operating in a frequency range up to 100 GHz.

Drawings

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

fig. 1 illustrates a block diagram of a third generation partnership project (3GPP) New Radio (NR) release 15 frame structure, according to an example;

fig. 2a depicts functionality of a User Equipment (UE) operable for hybrid automatic repeat request (HARQ) transmission according to an example;

fig. 2b depicts functionality of an evolved node b (enb) operable for hybrid automatic repeat request (HARQ) transmission according to an example;

fig. 3 depicts a dedicated pre-configured uplink resource (D-PUR) responsive Medium Access Control (MAC) Control Element (CE) (MAC CE) according to an example;

fig. 4 depicts functionality of a User Equipment (UE) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, according to an example;

fig. 5 depicts functionality of an evolved node b (enb) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, according to an example;

fig. 6 depicts a flowchart having a machine-readable storage medium having instructions embodied thereon for dedicated pre-configured uplink resources (D-PURs) in a third generation partnership project (3GPP) network, according to an example;

FIG. 7 illustrates an example architecture of a system according to an example network;

FIG. 8 illustrates an example of a platform or apparatus according to an example;

fig. 9 illustrates example components of a baseband circuit and Radio Front End Module (RFEM) according to an example;

FIG. 10 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium according to an example;

fig. 11 illustrates a diagram of a wireless device (e.g., UE) according to an example; and is

Fig. 12 illustrates various protocol functions according to an example.

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

Detailed Description

Before the present technology is disclosed and described, it is to be understood that this technology is not limited to the particular structures, process actions, or materials disclosed herein, but extends to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It is also to be understood that the terminology used herein is for the purpose of describing particular examples only and is not intended to be limiting. Like reference symbols in the various drawings indicate like elements. The numerals provided in the flowcharts and processes are provided for clarity in illustrating the acts and operations and do not necessarily indicate a particular order or sequence.

Example embodiments

An initial overview of technical embodiments is provided below, followed by a more detailed description of specific technical embodiments. This initial summary is intended to assist the reader in understanding the present technology more quickly, and is not intended to identify key features or essential features of the present technology, nor is it intended to limit the scope of the claimed subject matter.

In one example, a User Equipment (UE) may be configured for transmission in dedicated pre-configured uplink resources (D-PURs) in idle mode with a valid timing advance. In one example, in idle mode, a hybrid automatic repeat request (HARQ) may be configured for transmission in the D-PUR. In one example, a single HARQ may be configured. In another example, multiple HARQ processes may be configured. In another example, a Machine Type Communication (MTC) Physical Downlink Control Channel (PDCCH) (MPDCCH) search space may be configured.

In another example, for Uplink (UL) transmission in the pre-configured resource, a fallback mechanism for random-access channel (RACH) operation or Early Data Transmission (EDT) operation may be configured. For transmission in pre-configured UL resources (PURs), a Radio Resource Control (RRC) idle UE may be configured to use the latest Timing Advance (TA) that passes the validation criteria. The pre-configured UL resources for transmission of data may be indicated by RRC signaling. In another example, UE-specific RRC signaling may be configured.

In some cases, the UE may not be configured for HARQ in idle mode. When the UE is in a Connected mode (e.g., RRC _ Connected mode), the UE may be configured with pre-configured uplink resources (PURs) for idle mode. When configuring a HARQ process for a transmission in a PUR in idle mode, the HARQ process may be modified for connected mode.

In another example, D-PUR configuration, HARQ process ID calculation, HARQ retransmission may be configured. In one example, when configuring the PUR in idle mode, the D-PUR configuration can fall back to legacy random access. When the PUR is configured by dedicated RRC signaling or broadcast, a Transport Block Size (TBS), a period, a coverage enhancement level, the number of HARQ processes, and the like may be configured for the PUR in idle mode.

In one example, an apparatus of a User Equipment (UE) operable for dedicated pre-configured uplink resource (D-PUR) communication in a fifth generation (5G) New Radio (NR) third generation partnership project (3GPP) network may include one or more processors. The one or more processors may be configured to: identifying, at the UE, a D-PUR for transmission from the UE in idle mode to an evolved node B (eNB). The one or more processors may be configured to: it is determined at the UE whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein user data greater than the TBS is a first data segment and remaining user data is a second data segment. The one or more processors may be configured to multiplex, at the UE, the first data segment with a Radio Resource Control (RRC) resume request message when the user data is greater than the TBS. The one or more processors may be configured to encode, at the UE, a first data segment multiplexed with an RRC continuation request message in a D-PUR for transmission to the eNB. The one or more processors may be configured to encode, at the UE, the second data segment in a transport block for transmission in a D-PUR or in an RRC _ CONNECTED state. The UE may also include a memory interface configured to store the D-PUR in memory.

Fig. 1 provides an example of a 3GPP NR release 15 frame structure. In particular, fig. 1 illustrates a downlink radio frame structure. In this example, a radio frame 100 of a signal for transmitting data may be configured to have a duration T of 10 milliseconds (ms)_f. Each radio frame may be segmented or divided into ten subframes 110i, each 1ms long. Each subframe may be further subdivided into one or more slots 120a, 120i, and 120x, each slot having a duration T of 1/μms_slotWhere μ -1 for a 15kHz subcarrier spacing, μ -2 for 30kHz, μ -4 for 60kHz, μ -8 for 120kHz, and u-16 for 240 kHz. Each time slot may include a Physical Downlink Control Channel (PDCCH) and/or a Physical Downlink Shared Channel (PDSCH).

Each slot of a Component Carrier (CC) used by the node and the wireless device may include a plurality of Resource Blocks (RBs) 130a, 130b, 130i, 130m, and 130n based on a CC frequency bandwidth. The CC may have a carrier frequency with a bandwidth. Each slot of the CC may include Downlink Control Information (DCI) present in the PDCCH. The PDCCH is transmitted in a control channel resource set (CORESET), which may include one, two, or three Orthogonal Frequency Division Multiplexing (OFDM) symbols and a plurality of RBs.

Each RB (physical RB or PRB) may include 12 subcarriers (on a frequency axis) and 14 Orthogonal Frequency Division Multiplexing (OFDM) symbols (on a time axis) per slot. If a short or normal cyclic prefix is employed, the RB may use 14 OFDM symbols. If an extended cyclic prefix is used, the RB may use 12 OFDM symbols. A resource block may be mapped to 168 Resource Elements (REs) with a short or normal cyclic prefix, or a resource block may be mapped to 144 REs with an extended cyclic prefix (not shown). The RE may be a unit of one OFDM symbol 142 by one subcarrier (i.e., 15kHz, 30kHz, 60kHz, 120kHz, and 240kHz) 146.

Each RE 140i can transmit two bits 150a and 150b of information in case of quadrature phase-shift keying (QPSK) modulation. Other types of modulation, such as 16 Quadrature Amplitude Modulation (QAM) or 64QAM, may be used to transmit a larger number of bits in each RE, or bi-phase shift keying (BPSK) modulation may be used to transmit a smaller number of bits (single bits) in each RE. RBs may be configured for downlink transmission from the NR BS to the UE, or may be configured for uplink transmission from the UE to the NR BS.

This example of a 3GPP NR release 15 frame structure provides an example of a manner or transmission mode of transmitting data. This example is not intended to be limiting. Many release 15 features will evolve and change in the 5G frame structures included in 3GPP LTE release 15, MulteFire release 1.1, and beyond. In such systems, design constraints may coexist with multiple sets of 5G parameters (numerology) in the same carrier due to the coexistence of different network services, such as eMBB (enhanced mobile broadband), mtc (large scale machine type communication or large scale IoT), and URLLC (ultra-reliable low latency communication or critical communication). The carrier in a 5G system may be higher or lower than 6 GHz. In one embodiment, each network service may have a different set of parameters.

In one example, if the UE has UL data that is greater than a Transport Block (TB) Size (TBs), the UE may be configured to send one or more of an RRC connection request message, a Buffer Status Report (BSR), or an UL data segment in the PUR.

In another example, for a Control Plane (CP), a UE may be configured to send an RRC connection request message (e.g., RRC earlydatarequest) with a non-access stratum (NAS) Protocol Data Unit (PDU) with or without a BSR. If the CP data in the NAS PDU does not fit into the TBS of the PUR, the UE may be configured to send an RRC connection request message with one or more NAS service requests or BSRs.

In another example, signaling between the NAS and an Access Stratum (AS) may determine whether to transmit in the PUR based on the TBS limit of the PUR: (a) CP data plus NAS signaling, or (b) NAS signaling, or (c) NAS service request. The UE may be configured to signal between the NAS and the AS.

In another example, AS security may not be configured when a UE is configured for Control Plane (CP) cellular internet of things (C-IoT) Evolved Packet System (EPS) (CP-C-IoT EPS) optimization. In this example, NAS security may be leveraged to transport control plane data via NAS PDUs. In one example, the RRCEarlyDataRequest message may be configured to carry CP data via D-PUR resources in idle mode.

In another example, the UE may have additional UL data to transmit for which the UE may transmit after transitioning to a CONNECTED mode (e.g., RRC _ CONNECTED mode); however, segmentation or BSR may not be allowed when transmitting the RRCEarlyDataRequest message. In some cases, two establishment causes may be used, such as mo-Data-r15 and delayTolerataccess-r 15.

In another example, the RRCEarlyDataRequest message may be configured to carry one or more of CP data, Access Stratum (AS) Routing Area Identity (RAI) (AS RAI), or other establishment cause. The BSR MAC CE may also be transmitted with the RRC message. When the UE does not have additional UL data or when the BSR equals 0, then an indicator in the AS RAI in the RRC message may be transmitted.

In another example, the eNB may be configured to store the D-PUR configuration when the UE is released to an idle mode with the D-PUR configuration. To verify that the UL transmission in the D-PUR is from the intended UE before forwarding the UL data, an Identifier (ID) of the D-PUR or a serving temporary mobile subscriber identity (S-TMSI) may be configured. In another example, the eNB may be configured to map the dedicated PUR configuration to one or more UE identifiers including one or more of an S-TMSI, a cell radio network temporary identifier (C-RNTI), or an allocated UE-specific Radio Network Temporary Identifier (RNTI).

In another example, for the user plane, the UE may be configured to activate AS security when the UE receives a next-hop chain count (NCC) in a previous connection before transmitting an RRC connection continuation request message with or without one or more multiplexed user plane data or BSRs. Different message classes of the RRC connection continuation request message may be configured to indicate to the eNB that security has been activated. If the user data is greater than the TBS of the PUR, the data segment may be multiplexed with the RRC Continue request message.

In another example, based on the BSR, the eNB may schedule additional UL grants to transmit the remaining segments or UL data. When the remaining segments are empty or the received BSR is equal to 0, then the eNB may be configured to release the UE. This may be applicable to either the control plane or the user plane.

In another example, when configuring D-PUR for UP, the UE may be configured to activate AS security. In this example, a Signaling Radio Bearer (SRB), a Data Radio Bearer (DRB), or a Packet Data Convergence Protocol (PDCP) may be recovered, and a Timing Advance (TA) may be valid. In this example, the RRC message may not be configured. The UE may be configured to transmit a ULInformationTransfer in a Downlink Control Channel (DCCH) to deliver CP data or NAS signaling with an implicit establishment cause. The UE may be configured to transmit MAC PDUs in a Dedicated Traffic Channel (DTCH) to deliver any user plane UL data with PDCP ciphering. In another example, an RRC message in DCCH may be defined. In another example, the ULInformationTransfer may be configured to transmit CP data and a request to establish or continue an RRC connection with an establishment cause to transition to a CONNECTED state (e.g., RRC _ CONNECTED). The continuation ID may also be included in a Dedicated Control Channel (DCCH) message.

In another example, the eNB may be configured to transition the UE to a CONNECTED state (e.g., RRC _ CONNECTED) when the UE does not send an RRC message. In this example, the UE receives one or more RRCConnectionSetup messages or rrcconnectionsesume messages in response to the D-PUR transmission. When security is activated and RRCConnectionSetup is received, UL data transmission in D-PUR may be identified as unsuccessful.

In another example, when the UE transmits multiplexed user UL data in the PUR, the UE may be configured to activate AS security. In another example, the UE may be configured to send the rrcconnectionresponse message with or without a BSR in the PUR. In another example, when the UE does not receive NCC in response to a PUR, the UE may be configured for the AS key of the next PUR occasion. The UE may also request the eNB to enable the AS key for the next PUR occasion. This request may be indicated by the BSR or based on the amount of UL data available in the PUR transmission. In another example, the UE may transition to an idle state with a suspend indication and may be configured for NCC to initiate transmission in D-PUR or to initiate early data transmission, EDT, in a subsequent time period.

In another example, when a UE starts Random Access Channel (RACH) communication and transitions to a CONNECTED state (e.g., RRC CONNECTED), the UE may be configured for D-PUR in CONNECTED mode. In one example, the UE may be configured to transmit one or more of a Scheduling Request (SR), a BSR, or UL data when the D-PUR has not been released. In another example, the eNB may release the D-PUR via one or more of message 2(Msg2), message 4(Msg4), or CONNECTED mode (e.g., RRC _ CONNECTED). In another example, the eNB may be configured to notify the UE to transition to the RRC CONNECTED mode via an Acknowledgement (ACK) in the D-PUR.

In another example, one or more HARQ processes may be configured for a UE or eNB. In one example, a UE or eNB may be configured to apply HARQ processes from a random access operation. In another example, the UE or eNB may be configured to apply the modified HARQ process from a random access operation.

In another example, when multiple HARQ processes are supported, then a separate random access process may be initiated for each HARQ process. The feedback communication, the new grant communication, or the retransmission communication in response to the transmission in the PUR may be configured to indicate the HARQ process ID.

In another example, as depicted in fig. 2a, the functionality 200 of the HARQ process may include uplink transmissions from the UE, as depicted in block 202. In another example, after UL transmission, the UE may be configured to start a PUR retransmission timer, as depicted in block 204. In another example, the UE may be configured to monitor a Physical Downlink Control Channel (PDCCH) in a Common Search Space (CSS) provided in the common configuration with a new Radio Network Temporary Identifier (RNTI) provided in the PUR configuration, as depicted in block 206.

In another example, a retransmission timer at the UE may expire before the UE receives the response, as depicted in block 208. In this example, the UE may be configured to indicate a failure status and retransmit in another PUR, as shown in block 212. In another example, the UE may be configured to back-off to initiate a legacy or EDT random access operation, as shown in block 214. In another example, the UE may be configured to indicate success, as shown in block 216.

In another example, as depicted in fig. 2b, the eNB may be configured to include functionality as shown in 250. In one example, when the retransmission timer is running (e.g., before the retransmission timer expires, as depicted in block 251), the eNB may be configured to: (a) providing a retransmission grant addressed to the current RNTI, as shown in block 252, (b) providing a non-acknowledgement (NACK), indicating a fallback to the UE to initiate legacy or EDT random access operations, as shown in block 254, (c) providing a successful ID or contention resolution MAC CE, indicating entry into a sleep mode to the UE, as shown in block 256, or (d) scheduling an RRC message informing the UE to stay in an idle mode (e.g., EarlyDataComplete or RRCConnectionRelease message in EDT) or to transition to a connected mode (e.g., RRCConnectionSetup or rrcconnectionresponse message), as shown in block 258.

In another example, the PUR retransmission timer may be restarted after each retransmission by the UE.

In another example, the UE may be configured for asynchronous UL HARQ. After the UL transmission, the UE may be configured to start a HARQ Round Trip Time (RTT) and start a Discontinuous Reception (DRX) retransmission timer. When the timer expires and nothing is received, a failure may be indicated and a retransmission may occur in another PUR. When the timer expires and nothing is received, the UE may be configured to fall back to conventional EDT random access operation. When the timer expires and nothing is received, the UE may indicate success.

In another example, the UE may be configured for synchronous UL HARQ. In this example, the HARQ process may correspond to a Transmission Time Interval (TTI). After the last repetition of the Physical Uplink Shared Channel (PUSCH), the UE may be configured to monitor the PDCCH for ACK/NACK in a predetermined search space (e.g., CSS). In another example, the UE may be configured to monitor the PDCCH starting in the xth TTI (e.g., 4 th TTI) after the last repetition of the PUSCH, where x may be a positive integer. When the UE does not receive anything, the UE may indicate a failure and may retransmit in the next PUR or may initiate a legacy RACH EDT operation. When the UE receives the NACK, the UE may be configured to retransmit with the same resource configuration in the TTI corresponding to the same HARQ process of the initial transmission. When the UE receives the ACK, the UE may be configured to indicate success.

In another example, when the PUR transmission is successful, the UE may be configured to receive an RRC message to indicate to the UE to stay in idle mode or to transition to CONNECTED mode (e.g., RRC _ CONNECTED). In another example, in response to a transmission in the PUR, the UE may be configured to receive a TA command, receive a NCC, or restart a TA validity timer.

Based on the BSR, the eNB may be configured to provide additional UL grants to the UE to transmit remaining UL data indicating additional HARQ processes. The eNB may also be configured to include D-PUR reconfiguration to modify or cancel D-PUR. The UE may be configured to receive a PDCCH-based HARQ acknowledgement and determine that a transmission in D-PUR is successful. The UE may be configured to stay in idle mode.

In another example, the UE may transition back to idle mode when the UE does not receive an ACK in response to the transmission in the PUR and the transmission is successful. In another example, when the UE is using UP C-IoT and security has been activated for transmission in the PUR, in the next PUR, the UE may be configured to use the existing key until the current TA is valid. In another example, when the UE is configured to use EDT in the PUR, the UE may indicate EDT when multiple packets are transmitted. In this example, EDT may be used for PUR.

In another example, the HARQ process ID may be 0 for a single HARQ process. In another example, for multiple HARQ processes, the HARQ process ID may be determined using the following equation: HARQ process ID ═ [ flow (CURRENT _ TTI/PURinterval) ] modulo number of HARQ-Processes, where CURRENT _ TTI ═ SFN [ (SFN x 10) + subframe number code ] and may refer to the subframe where the first transmission of the bundle occurs. In another example, for synchronous HARQ, the HARQ process ID may be CURRENT _ TTI modulo number of HARQ-Processes.

In another example, when multiple D-PUR configurations are configured, each D-PUR configuration may correspond to a different HARQ process. When the D-PUR retransmission timer expires, the UE may determine that the HARQ process failed and may start additional HARQ processes to retransmit the data in the next D-PUR. Each D-PUR may be assigned a HARQ process ID during configuration. In another example, the HARQ process offset may be configured for each D-PUR and HARQ process ID using the following equation: HARQ process ID ═ floor (CURRENT _ TTI/PURinterval) modulo numberOfHARQ-Processes + HARQ-Offset.

In another example, the HARQ-offset may be a starting HARQ process ID for a given D-PUR configuration. For a one-time D-PUR, the HARQ process ID may be configured to be a constant, e.g., the HARQ process ID is 0. In another example, the first periodic D-PUR configuration may have a value of HARQ-offset-1. In another example, the second periodic D-PUR configuration may have a HARQ offset of numberOfHARQ-Processes + 1. In another example, the nth periodic D-PUR configuration may have a HARQ offset of (n X number of HARQ-Processes) + 1.

In another example, HARQ processes may be jointly computed for a disposable D-PUR and a periodic D-PUR. In one example, the UE may assume x one-time configurations and y periodic D-PUR configurations, where for the ith one-time D-PUR (0< i < x + 1); for HARQ process ID ═ HARQ-offset (i) ═ i-1; and for the jth periodic D-PUR (0< j < y + 1). In this example, the HARQ process ID ═ floor (CURRENT _ TTI/PURinterval) modulo numberOfHARQ-Processes + HARQ-Offset, where HARQ-Offset ═ X numberOfHARQ-Processes + X.

In another example, PURinterval and HARQ-Offset may be configured separately for each D-PUR configuration to avoid collisions between HARQ process IDs.

In another example, after transmission in the D-PUR, the UE may be configured to monitor the PDCCH for an acknowledgement with the RNTI. The RNTI may be derived from the time and frequency at which the UE uses D-PUR resources. In another example, the RNTI may be common to all UEs and cell-specific. In another example, a group RNTI for a group of UEs may be allocated. The UE may receive a PDSCH scheduled by a PDCCH to: resolving contention, receiving an acknowledgement, receiving a retransmission grant, or receiving an additional transmission. In another example, multiple UEs may receive a D-PUR response SDU corresponding to the ID of the UE (e.g., S-TMSI) or corresponding to the first 48 bits of a PDU transmitted in the D-PUR. The response SDU may contain one or more of an acknowledgement, a retransmission grant, or a DL assignment.

In another example, when the response SDU does not correspond to the UE, the UE may continue to monitor the PDCCH until the PUR retransmission timer expires. In another example, the response SDU may contain one or more of a contention resolution MAC CE, TA command, UL grant, DL grant, temporary C-RNTI, or HARQ process ID. There may be multiple responding SDUs for multiple UEs. The contention resolution ID may include a new D-PUR ID assigned to the UE. The length of the D-PUR ID may be x bits (e.g., 8 bits, 16 bits, 24 bits, or 40 bits), where x may be a positive integer.

In another example, as shown in fig. 3, the D-PUR response MAC CE 300 may be configured with a reserved Logical Channel ID (LCID) or an enhanced LCID (eLCID). The MAC CE 300 may comprise 8 bits (301-: a D-PUR ID 312, one or more reserved bits 322, an uplink/downlink indication 324, an uplink/downlink grant 326, an uplink/downlink grant 332, a temporary C-RNTI 342, or a temporary C-RNTI 352. The MAC CE may include one or more bytes (e.g., 318, 328, 338, 348, or 358). When multiple HARQ processes are configured, reserved bits 322 (or 2 reserved bits in the MAC subheader with the etlcid) may be used to indicate the HARQ process ID.

In another example, when configuring the UE-specific RNTI for the D-PUR, the UE may not indicate the UE ID (e.g., S-TMSI or ResumeID) in the RRC message for UL transmissions in the D-PUR. The UE may indicate the establishment cause or the continuation cause in an RRC message.

In another example, a UL Common Control Channel (CCCH) message class extension may be defined for the RRCConnectionRequest message or the rrcconnectionresumerrequest message to carry one or more of an establishment cause, a continuation cause, or a NAS PDU (CP data). For the user plane, an UL DCCH message class extension may be defined.

In another example, when the UE wishes to release the PUR, but the TA validity timer is still running, the UE may send one or more of an RRC message, a MAC CE, or an L1 signal in the PUR to indicate to the eNB to release the PUR. The PUR may also be released when the UE initiates a legacy RRC connection, a continued establishment procedure using legacy PRACH resources, or EDT using EDT PRACH.

In another example, the D-PUR may be released when AS security is not enabled. After the D-PUR transmission, the UE may monitor the PDCCH until the D-PUR timer expires. The eNB may schedule retransmissions before the timer expires. When the timer expires with reception, the D-PUR transmission may be indicated as failed. After a D-PUR failure, the UE may determine whether to: the next D-PUR opportunity is used to start the legacy RACH, or to start the EDT to transmit UL data.

In another example, AS security may not be enabled for HARQ NACK-to-ACK errors of RRC response messages including D-PUR release indications (i.e., when CCCH is used). In this example, the eNB may determine that the D-PUR transmission by the UE was successful and that the D-PUR was released by the UE. In this example, the UE may determine that the D-PUR is failed and may not be informed of the D-PUR release. In this particular case, the UE may not be configured for the next D-PUR. The UE may trigger a legacy RACH or a Mobile Originating (MO) EDT.

In another example, when the eNB sends a D-PUR release command to the UE, the eNB may not be able to verify that the UE successfully received the D-PUR release (e.g., the UE did not receive the release message, entered idle mode after the timer expires; the UE sends a HARQ ACK and enters idle mode, but the eNB receives a HARQ NACK). In this case, the eNB may rely on the implicit release mechanism of D-PUR and ignore the D-PUR release order sent by the eNB to the UE.

In another example, the UE may not be able to verify that the eNB successfully received the ACK/NACK for the D-PUR release command (e.g., the UE sent a HARQ NACK, but the eNB received a HARQ ACK and determined that the UE is in idle mode). In this example, the UE may reuse the next D-PUR opportunity.

In another example, when a D-PUR transmission fails due to HARQ NACK-to-ACK or ARQ (i.e., after receiving a response message), the UE may not use the D-PUR opportunity because the UE cannot properly decode the response message with the D-PUR release order.

In another example, the UE may not use existing D-PUR resources when the UE receives the D-PUR release order but cannot decode or read the D-PUR release order.

In another example, the UE may not use the D-PUR resources that may be released when the UE transitions to idle mode without properly receiving an RRC release message (e.g., RRCConnectionRelease or RRCEarlyDataComplete). In another example, the eNB cannot release the D-PUR when the eNB cannot verify that the RRC release message was successful.

In another example, the eNB may assign a D-PUR ID to identify the UE context and D-PUR resources to enable the eNB to retrieve the context of the UE. In another example, the UE may identify itself by providing the UE ID in the D-PUR transmission. In one example, the UE for which the D-PUR resources are allocated may not be used by other UEs. In another example, the continuation ID may be used in the user plane and the S-TMSI may be used in the control plane. In another example, an "EDT session" indication may be configured for D-PUR transmission to enable the MME to control D-PUR.

Another example provides functionality 400 of a User Equipment (UE) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, as shown in fig. 4. The UE may include one or more processors. The one or more processors may be configured to identify, at a UE, a D-PUR for transmission from the UE in idle mode to an evolved node b (enb), as shown in block 410. The one or more processors may be configured to determine, at the UE, whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein the user data greater than the TBS is a first data segment and the remaining user data is a second data segment, as shown in block 420. The one or more processors may be configured to encode, at the UE, a Radio Resource Control (RRC) resume request message with the user data for transmission to the eNB when the user data is less than or equal to the TBS, as shown in block 430. The one or more processors may be configured to multiplex, at the UE, the first data segment with an RRC continuation request message when the user data is greater than the TBS, as shown in block 440. The one or more processors may be configured to encode, at the UE, the first data segment multiplexed with the RRC continuation request message in a D-PUR for transmission to the eNB, as shown in block 450. The one or more processors may be configured to encode, at the UE, the second data segment in a transport block for transmission in the D-PUR or in the RRC _ CONNECTED state, as shown in block 460. Further, the UE may include a memory interface configured to store the D-PUR in memory.

Another example provides functionality 500 of an evolved node b (enb) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, as shown in fig. 5. The eNB may include one or more processors. The one or more processors may be configured to encode, at an eNB, D-PUR configuration information for D-PUR transmission from a User Equipment (UE) in idle mode for transmission to the UE, as shown in block 510. The one or more processors may be configured to decode, at the eNB, a first data segment multiplexed with a Radio Resource Control (RRC) resume request message received from the UE in the D-PUR, as shown in block 520. The one or more processors may be configured to decode, at the eNB, a second data segment in a transport block received from the UE in the D-PUR or in the RRC _ CONNECTED state, as shown in block 530. Further, the eNB may include a memory interface configured to store the D-PUR in memory.

Another example provides at least one machine readable storage medium having instructions 600 embodied thereon for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, as shown in fig. 6. The instructions may be executed on a machine, where the instructions are included on at least one computer-readable medium or at least one non-transitory machine-readable storage medium. The instructions when executed perform: a D-PUR is identified at the UE for transmission from the UE in idle mode to an evolved node B (eNB), as shown in block 610. The instructions when executed perform: it is determined at the UE whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein user data greater than the TBS is a first data segment and remaining user data is a second data segment, as shown in block 620. The instructions when executed perform: when the user data is less than or equal to the TBS, a Radio Resource Control (RRC) resume request message with the user data is encoded at the UE for transmission to the eNB, as shown in block 430. The instructions when executed perform: when the user data is greater than the TBS, the first data segment is multiplexed with the RRC continuation request message at the UE, as shown in block 640. The instructions when executed perform: the first data segment multiplexed with the RRC continuation request message is encoded in the D-PUR at the UE for transmission to the eNB, as shown in block 650. The instructions when executed perform: the second data segment is encoded in a transport block at the UE for transmission in a D-PUR or in an RRC _ CONNECTED state, as shown in block 660.

Although examples are provided in which enbs are specified, they are not intended to be limiting. Instead of an eNB, an evolved node b (eNB), a next generation node b (gnb), a new radio node b (gnb), or a new radio base station (NR BS) may be used. Thus, any example herein in which an eNB is disclosed may be similarly disclosed using an eNB, a gNB, or a new radio base station (NR BS), unless otherwise stated.

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

As shown in fig. 7, system 700 includes UE 701a and UE 701b (collectively "UEs 701" or "UE 701"). In this example, UE 701 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 electronics device, a cellular phone, a smartphone, a feature phone, a tablet computer, a wearable computer device, a Personal Digital Assistant (PDA), a pager, a wireless handset, a desktop computer, a laptop computer, an in-vehicle infotainment (IVI), an in-vehicle entertainment (ICE) device, an Instrument Cluster (IC), a head-up display (HUD) device, an on-board diagnostics (OBD) device, a dashboard mobile Device (DME), a Mobile Data Terminal (MDT) device, a mobile phone, an Electronic Engine Management System (EEMS), an Electronic/Engine Control Unit (ECU), an Electronic/Engine Control Module (ECM), an embedded System, a microcontroller, a control module, an Engine Management System (EMS), a networked or "smart" appliance, an MTC device, M2M, an IoT device, and so forth.

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

UE 701 may be configured to connect, e.g., communicatively couple, with RAN 710. In an embodiment, RAN 710 may be a NG RAN or a 5G RAN, an E-UTRAN, or a legacy RAN such as UTRAN or GERAN. As used herein, the term "NG RAN" or the like may refer to RAN 710 operating in NR or 5G system 700, and the term "E-UTRAN" or the like may refer to RAN 710 operating in LTE or 4G system 700. The UE 701 utilizes connections (or channels) 704 and 704, respectively, each of the connections (or channels) 703 and 704 including a physical communication interface or layer (discussed in more detail below).

In this example,

connections

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

UE 701b is shown configured to access AP 706 (also referred to as "WLAN node 706", "WLAN termination 706", or "WT 706" and the like) via connection 707. Connection 707 may comprise a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, wherein AP 706 would comprise wireless fidelity

A router. In this example, the AP 706 is shown connected to the internet, rather than to the core network of the wireless system (described in more detail below). In various entitiesIn an embodiment, UE 701b, RAN 710, and AP 706 may be configured to operate with LWA and/or LWIP. LWA operation may involve a UE 701b in RRC _ CONNECTED being configured by RAN nodes 711a-b to utilize radio resources of LTE and WLAN. LWIP operations may involve the UE 701b utilizing WLAN radio resources (e.g., connection 707) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) sent over the connection 707. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

RAN 710 may include one or more AN nodes or

RAN nodes

711a and 711b (collectively "RAN nodes 711") that enable

connections

703 and 704. As used herein, the terms "access node," "access point," and the like may describe a device that provides radio baseband functionality for data and/or voice connectivity between a network and one or more users. These access nodes may be referred to as BSs, gnbs, RAN nodes, enbs, nodebs, RSUs, trxps or TRPs, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a certain geographic area (e.g., a cell). As used herein, the term "NG RAN node" or the like may refer to a RAN node 711 (e.g., a gNB) operating in the NR or 5G system 700, and the term "E-UTRAN node" or the like may refer to a RAN node 711 (e.g., an eNB) operating in the LTE or 4G system 700. According to various embodiments, the RAN node 711 may be implemented as one or more of the following: a dedicated physical device such as a macrocell base station, and/or a Low Power (LP) base station for providing a femtocell, picocell or other similar cell with a smaller coverage area, smaller user capacity or higher bandwidth than a macrocell.

In some embodiments, all or some portions of the RAN node 711 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a CRAN and/or a virtual baseband unit pool (vbbp). In these embodiments, the CRAN or vbbp may implement RAN functionality partitioning, e.g., PDCP partitioning, where RRC and PDCP layers are operated by the CRAN/vbbp and other L2 protocol entities are operated by the individual RAN node 711; MAC/PHY segmentation, where RRC, PDCP, RLC and MAC layers are operated by the CRAN/vbup and PHY layers are operated by the individual RAN node 711; or "lower PHY" segmentation, where the RRC, PDCP, RLC, MAC layers and the upper part of the PHY layers are operated by the CRAN/vbup and the lower part of the PHY layers are operated by the individual RAN node 711. This virtualization framework allows the vacated processor core of RAN node 711 to execute other virtualized applications. In some implementations, the individual RAN node 711 may represent an individual gNB-DU connected to a gNB-CU via an individual F1 interface (not shown in fig. 7). In these implementations, the gNB-DUs may include one or more remote radio heads or RFEMs, and the gNB-CUs may be operated by a server located in the RAN 710 (not shown) or by a server pool in a similar manner as the CRAN/vbupp. Additionally or alternatively, one or more of the RAN nodes 711 may be next generation enbs (NG-enbs), which are RAN nodes providing E-UTRA user plane and control plane protocol terminations towards the UE 701 and are connected to the 5GC via an NG interface (discussed below).

In the V2X scenario, one or more of the RAN nodes 711 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 an appropriate RAN node or stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a "UE-type RSU", an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU", and so on. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the curb side that provides connectivity support to passing vehicle UEs 701 (vues 701). The RSU may also include internal data storage circuitry to store intersection map geometry, traffic flow statistics, media, and applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9GHz Direct Short Range Communications (DSRC) band to provide very low latency Communications required for high speed events, such as collision avoidance, traffic flow warnings, and the like. Additionally or alternatively, the RSU may operate over 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 Wi-Fi hotspot (2.4GHz band) and/or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the radio frequency circuitry of the computing device(s) and RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide wired connections (e.g., ethernet) to a traffic flow signal controller and/or a backhaul network.

Any of the RAN nodes 711 may terminate the air interface protocol and may be the first point of contact for the UE 701. In some embodiments, any of RAN nodes 711 may perform various logical functions for RAN 710, 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, UEs 701 may be configured to communicate with each other or with RAN node 711 using OFDM communication signals over a multicarrier communication channel in accordance with various communication techniques such as, but not limited to, OFDMA communication techniques (e.g., for downlink communications) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any of the RAN nodes 711 to the UE 701, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. This time-frequency plane representation is a common practice of OFDM systems, which makes it intuitive for radio resource allocation. Each column and first 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 denoted as a resource element. Each resource grid comprises several resource blocks, which describe the mapping of a specific physical channel to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this may represent the minimum number of resources that are currently allocable. There are several different physical downlink channels carried with such resource blocks.

According to various embodiments, UE 701 and RAN node 711 communicate data (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 UE 701 and the RAN node 711 may operate using LAA, eLAA, and/or feLAA mechanisms. In these implementations, UE 701 and RAN node 711 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 media/carrier sensing operation may be performed according to the listen-before-talk (LBT) protocol.

LBT is a mechanism by which a device (e.g., UE 701, RAN node 711, etc.) detects a medium (e.g., a channel or carrier frequency) and transmits when it detects that the medium is idle (or when it detects that a particular channel in the medium is unoccupied). The medium detection operation may include CCA that utilizes at least the ED to determine the presence or absence of other signals on the channel in order to determine whether the channel is occupied or clear. This LBT mechanism allows cellular/LAA networks to coexist with incumbent systems in unlicensed spectrum and with other LAA networks. ED may include detecting RF energy over an expected transmission band for a period of time and comparing the detected 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 called CSMA/CA. Here, when a WLAN node (e.g., a Mobile Station (MS) such as UE 701, AP 706, etc.) wants to transmit, the WLAN node may first perform a CCA before transmitting. Furthermore, a back-off mechanism is used to avoid collisions when more than one WLAN node detects a channel as idle and transmits at the same time. The backoff mechanism may be a counter that is randomly drawn within the CWS, exponentially increased when collisions occur and reset to a minimum value when a transmission is successful. The LBT mechanism designed for LAA is sometimes similar to CSMA/CA of WLAN. In some implementations, an LBT procedure including a DL or UL transmission burst of a PDSCH or PUSCH transmission, respectively, may have an LAA contention window of variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values of a CWS for the LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μ s); however, the size of the CWS and MCOT (e.g., send bursts) may be based on government regulatory requirements.

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

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

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

The PDCCH uses CCEs to convey control information. The PDCCH complex-valued (complex-valued) symbols may first be organized into quadruplets before being mapped to resource elements, which may then be permuted with a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements called REGs. Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped for each REG. Depending on the size of the DCI and the channel conditions, the PDCCH may be transmitted using one or more CCEs. There may be four or more different PDCCH formats defined in LTE, with different numbers of CCEs (e.g., aggregation 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 utilize EPDCCH which uses PDSCH resources for control information transmission. One or more ECCEs may be utilized for transmission of EPDCCH. Similar to the above, each ECCE may correspond to nine sets of four physical resource elements called EREGs. ECCE may have other numbers of EREGs in some cases.

The RAN nodes 711 may be configured to communicate with each other via an interface 712. In embodiments where system 700 is an LTE system, interface 712 may be an X2 interface 712. An X2 interface may be defined between two or more RAN nodes 711 (e.g., two or more enbs, etc.) connected to EPC 720 and/or between two enbs connected to EPC 720. In some implementations, the X2 interfaces can 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 transfer information between enbs regarding the delivery of user data. For example, X2-U may provide specific sequence number information for user data transmitted from MeNB to SeNB; information on success of sequence delivery of PDCP PDUs for user data from the SeNB to the UE 701; information of PDCP PDUs that are not delivered to the UE 701; information on a current minimum expected buffer size for transmitting user data to the UE at the SeNB; and so on. X2-C may provide intra-LTE access mobility functions including context transfer from source to target eNB, user plane transport control, etc.; a load management function; and an inter-cell interference coordination function.

In embodiments where system 700 is a 5G or NR system, interface 712 may be an Xn interface 712. An Xn interface is defined between two or more RAN nodes 711 (e.g., such as two or more gnbs) connected to 5GC 720, between a RAN node 711 (e.g., a gNB) and an eNB connected to 5GC 720, and/or between two enbs connected to 5GC 720. 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 may provide for non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functionality. Xn-C may provide management and error handling functions, managing the functionality of the Xn-C interface; mobility support for a UE 701 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality to manage CONNECTED mode UE mobility between one or more RAN nodes 711. Mobility support may include a context transfer from an old (source) serving RAN node 711 to a new (target) serving RAN node 711; and control of the user plane tunnel between the old (source) serving RAN node 711 to the new (target) serving RAN node 711. The Protocol stack of the Xn-U may include a transport network layer built on top of an Internet Protocol (IP) transport layer and a GTP-U layer on top of UDP and/or IP layer(s) to carry user plane PDUs. The Xn-C Protocol stack may include an Application layer signaling Protocol (referred to as Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP can be 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.

The RAN 710 is shown communicatively coupled to a core network, in this embodiment a Core Network (CN) 720. The CN 720 may include a plurality of network elements 722 configured to provide various data and telecommunications services to clients/subscribers (e.g., users of the UE 701) connected to the CN 720 via the RAN 710. The components of CN 720 may be implemented in one physical node or separate physical nodes that include components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be utilized to virtualize any or all of the above network node functions via executable instructions stored in one or more computer-readable storage media (described in more detail below). The logical instantiation of the CN 720 may be referred to as a network slice, and the logical instantiation of a portion of the CN 720 may be referred to as a network subslice. The NFV architecture and infrastructure may be used to virtualize one or more network functions onto physical resources including industry standard server hardware, storage hardware, or a combination of switches, or performed by proprietary hardware. 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 730 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). Application server 730 may also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE 701 via EPC 720.

In an embodiment, CN 720 may be a 5GC (referred to as "5 GC 720" or the like), and RAN 710 may connect with CN 720 via NG interface 713. In an embodiment, the NG interface 713 may be split into two parts: an NG user plane (NG-U) interface 714 that carries traffic data between RAN node 711 and the UPF; and an S1 control plane (NG-C) interface 715, which is a signaling interface between the RAN node 111 and the AMF.

In an embodiment, CN 720 may be a 5G CN (referred to as "5 GC 720" or the like), while in other embodiments, CN 720 may be an EPC. In the case where CN 720 is an EPC (referred to as "EPC 720" or the like), RAN 710 may connect with CN 720 via S1 interface 713. In an embodiment, the S1 interface 713 may be split into two parts: an S1 user plane (S1-U) interface 714 that carries traffic data between the RAN node 711 and the S-GW; and S1-MME interface 715, which is a signaling interface between RAN node 111 and the MME.

Fig. 8 illustrates an example of a platform 800 (or "device 800"), in accordance with various embodiments. In embodiments, computer platform 800 may be suitable for use as UE 701, application server 730, and/or any other element/device discussed herein. Platform 800 may include any combination of the components shown in the examples. The components of platform 800 may be implemented as an Integrated Circuit (IC), a portion thereof, discrete electronics, or other module adapted in computer platform 800, logic, hardware, software, firmware, or a combination thereof, or as components otherwise contained within the chassis of a larger system. The block diagram of FIG. 8 is intended to illustrate a high-level view of the components of computer platform 800. However, in other implementations, some of the components shown may be omitted, additional components may be present, and a different arrangement of the components shown may occur.

Application circuitry 805 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: LDO, interrupt controller, such as SPI, I²A serial interface such as a C or universal programmable serial interface module, RTC, timer-counters including interval and watchdog timers, universal I/O, memory card control such as SD MMCThe device comprises a USB interface, an MIPI interface and a JTAG test access port. The processor (or core) of the application circuitry 805 may be coupled with or may include memory/storage elements and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the system 800. In some implementations, the memory/storage elements may be on-chip memory circuits, which may include any suitable volatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid state memory, and/or any other type of memory device technology, such as those discussed herein.

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

As an example, the processor(s) of the application circuitry 805 may include a processor based on

Architecture Core^TMProcessors of, e.g. Quark^TM、Atom^TMI3, i5, i7 or MCU type processors, or may be available from santa clara, ca

Additional such processors available from companies. The processor of the application circuit 805 may also be one or more of the following: ultra-Micro semiconductor(s) (Advanced Micro Devices, AMD)

A processor or Accelerated Processing Unit (APU); from

Company's A5-A9 processor(s), from

Snapdagon(s) of technical company^TMA processor for processing the received data, wherein the processor is used for processing the received data,

open Multimedia Applications Platform(s) (OMAP)^TMA processor; MIPS-based designs from MIPS technologies, Inc., such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM holdings, such as the ARM Cortex-A, Cortex-R and Cortex-M processor families; and so on. In some implementations, the application circuit 805 may be part of a system on a chip (SoC) in which the application circuit 805 and other components are formed as a single integrated circuit, or a single package, e.g., from

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

Additionally or alternatively, the application circuitry 805 may include circuitry such as, but not limited to, the following: one or more field-programmable devices (FPDs), such as FPGAs and the like; 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 (programmable SoC, PSoC); and so on. In such embodiments, the circuitry of the application circuitry 805 may include logic blocks or logic architectures and other interconnected resources that may be programmed to perform various functions, such as the processes, methods, functions, and so forth, of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuitry 805 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 logical blocks, logical architectures, data, and/or the like in a look-up table (LUT) or the like.

Baseband circuitry 810 may be implemented, for example, as a solder-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. Various hardware electronics of the baseband circuitry 810 are discussed below with reference to fig. 9.

The RFEM 815 may include a millimeter wave (mmWave) RFEM and one or more sub-mmWave Radio Frequency Integrated Circuits (RFICs). In some implementations, the one or more sub-mmWave RFICs may be physically separate from the mmWave RFEM. The RFIC may include a connection to one or more antennas or antenna arrays (see, e.g., antenna array 911 of fig. 9 below), and the RFEM may be connected to multiple antennas. In an alternative implementation, both mmWave and sub-mmWave radio functions may be implemented in the same physical RFEM 815, which RFEM 815 contains both mmWave antennas and sub-mmWave.

Memory circuit 820 may include any number and type of memory devices for providing a given amount of system memory. As an example, memory circuit 820 may include one or more of the following: volatile memory including Random Access Memory (RAM), Dynamic RAM (DRAM), and/or Synchronous Dynamic RAM (SDRAM); and nonvolatile memories (NVMs) including high-speed electrically erasable memories (generally referred to as flash memories), phase change random access memories (PRAMs), Magnetoresistive Random Access Memories (MRAMs), and the like.Memory circuit 820 may be developed according to a Joint Electron Device Engineering Council (JEDEC) based Low Power Double Data Rate (LPDDR) design, such as LPDDR2, LPDDR3, LPDDR4, and so on. The memory circuit 820 may be implemented as one or more of a solder-in package integrated circuit, a Single Die Package (SDP), a Dual Die Package (DDP), or a quad die package (Q17P), a socket memory module, a Dual Inline Memory Module (DIMM) including a micro DIMM or a MiniDIMM, and/or soldered to a motherboard via a Ball Grid Array (BGA). In a low power implementation, memory circuit 820 may be an on-chip memory or register associated with application circuit 805. To support persistent storage of information such as data, applications, operating systems, etc., memory circuit 820 may include one or more mass storage devices, which may include Solid State Disk Drives (SSDDs), Hard Disk Drives (HDDs), micro HDDs, resistance change memories, phase change memories, holographic or chemical memories, among others. For example, computer platform 800 may include a software module from

And

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

Removable memory circuit 823 may include devices, circuitry, enclosures/housings, ports or sockets, etc. for coupling portable data storage devices with platform 800. These portable data storage devices may be used for mass storage purposes and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD picture cards, etc.), as well as USB flash drives, optical disks, external HDDs, and the like.

Platform 800 may also include interface circuitry (not shown) for interfacing external devices with platform 800. External devices connected to the platform 800 via interface circuits include sensor circuits 821 and electro-mechanical components (EMC) 822, and a removable memory device coupled to a removable memory circuit 823.

Sensor circuit 821 includes a device, module, or subsystem whose purpose is to detect an event or change in its environment and send information (sensor data) about the detected event to some other device, module, subsystem, or the like. Examples of such sensors include, inter alia, Inertial Measurement Units (IMUs), including accelerometers, gyroscopes, and/or magnetometers; microelectromechanical Systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes and/or magnetometers; a level sensor; a flow sensor; temperature sensors (e.g., thermistors); a pressure sensor; an air pressure sensor; a gravimeter; an altimeter; an image capture device (e.g., a camera or a lens-less aperture); a light detection and ranging (LiDAR) sensor; proximity sensors (e.g., infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; a microphone or other similar audio capture device; and so on.

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

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

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

Driver circuit 846 may include software and hardware elements that operate to control particular devices embedded in platform 800, attached to platform 800, or otherwise communicatively coupled with platform 800. Driver circuit 846 may include individual drivers to allow other components of platform 800 to interact with or control various input/output (I/O) devices that may be present within platform 800 or connected to platform 800. For example, driver circuit 846 may include display drivers to control and enable access to a display device, touch screen drivers to control and enable access to a touch screen interface of platform 800, sensor drivers to obtain sensor readings of sensor circuit 821 and to control and enable access to sensor circuit 821, EMC drivers to obtain actuator positions of EMC 822 and/or to control and enable access to EMC 822, camera drivers to control and enable access to an embedded image capture device, and audio drivers to control and enable access to one or more audio devices.

Power Management Integrated Circuit (PMIC) 825 (also referred to as "Power management Circuit 825") may manage power provided to various components of platform 800. Specifically, for the baseband circuit 810, the PMIC 825 may control power supply selection, voltage scaling, battery charging, or DC-to-DC conversion. PMIC 825 may often be included when platform 800 is capable of being powered by battery 830, such as when the device is included in UE 701.

In some embodiments, PMIC 825 may control or otherwise be part of various power saving mechanisms of platform 800. For example, if platform 800 is in an RRC _ Connected state where it is still Connected to the RAN node because it is expected to receive traffic very soon, it may enter a state called Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, platform 800 may be powered down for brief time intervals and thereby conserve power. If there is no data traffic activity for a longer period of time, the platform 800 may transition off to the RRC _ Idle state, in which it is disconnected from the network and no operations such as channel quality feedback, handover, etc. are performed. The platform 800 enters a very low power state and it performs a page in which it again periodically wakes up to listen to the network and then powers down again. Platform 800 may not receive data in this state; to receive data, it must transition back to the RRC _ Connected state. The additional power saving mode may allow the device to be unavailable to the network for periods longer than the paging interval (ranging from seconds to hours). During this time, the device is completely inaccessible to the network and can be completely powered down. Any data sent during this time is subject to a large delay and it is assumed that the delay is acceptable.

Battery 830 may power platform 800, although in some examples platform 800 may be installed deployed in a fixed location and may have a power supply source coupled to the power transmission network. The battery 830 may be a lithium ion battery, a metal air battery, such as a zinc air battery, an aluminum air battery, a lithium air battery, or the like. In some implementations, such as in a V2X application, battery 830 may be a typical lead-acid automotive battery.

In some implementations, the Battery 830 may be a "smart Battery" that includes or is coupled to a Battery Management System (BMS) or a Battery monitoring integrated circuit. A BMS may be included in the platform 800 to track the state of charge (SoCh) of the battery 830. The BMS may be used to monitor other parameters of the battery 830 to provide failure predictions, such as state of health (SoH) and functional state (SoF) of the battery 830. The BMS may communicate information of the battery 830 to the application circuitry 805 or other components of the platform 800. The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit 805 to directly monitor the voltage of the battery 830 or the current flowing from the battery 830. The battery parameters may be used to determine actions that platform 800 may perform, such as transmit frequency, network operation, sense frequency, and so on.

A power block or other power supply coupled to the power transmission network may be coupled to the BMS to charge the battery 830. In some examples, the power block may be replaced with a wireless power receiver to obtain power wirelessly, such as through a loop antenna in computer platform 800. In these examples, a wireless battery charging circuit may be included in the BMS. The particular charging circuit selected may depend on the size of the battery 830 and thus on the current required. Charging may be performed using the Airfuel standard promulgated by the international Wireless charging industry Consortium (Airfuel Alliance), the Qi Wireless charging standard promulgated by the Wireless Power Consortium (Wireless Power Consortium), or the Rezence charging standard promulgated by the Wireless Power Consortium (Alliance for Wireless Power), among others.

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

Although not shown, the components of platform 800 may communicate with each other using suitable bus or Interconnect (IX) technology, which may include any number of technologies, including ISA, EISA, PCI x, PCIe, Time-Trigger Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus/IX may be a proprietary bus/IX, such as used in SoC-based systems. May include other bus/IX systems, e.g. I²C-interface, SPI-interface, point-to-point interface, and power bus, among others.

Fig. 9 illustrates baseband circuitry 910 and example components of a Radio Front End Module (RFEM) 915, in accordance with various embodiments. The baseband circuits 910 respectively correspond to the baseband circuits 810 of fig. 8. The RFEMs 915 respectively correspond to the RFEM 815 of fig. 8. As shown, the RFEM 915 may include Radio Frequency (RF) circuitry 906, front-end module (FEM) circuitry 908, and an antenna array 911 coupled together at least as shown.

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

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

Providing an Embedded Operating System (OSE)^TMFrom Mentor

Provided nucleous RTOS^TMFrom Mentor

The universal Real-Time execution (VRTX) provided by Express

Provided ThreadX^TMFreeRTOS, consisting of

REX OS, provided by Open Kernel (OK)

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

In some embodiments, each of the processors 904A-904E includes a respective memory interface to send and receive data to and from the memory 904G. Baseband circuitry 910 may also include one or more interfaces to communicatively couple to other circuitry/devices, e.g., including interfaces to send/receive data to/from memory external to baseband circuitry 910; an application circuit interface to transmit/receive data to/from the application circuit 805 of fig. 9; an RF circuitry interface to transmit/receive data to/from the RF circuitry 906 of fig. 9; a wireless hardware connectivity interface to connect to and from one or more wireless hardware elements (e.g., Near Field Communication (NFC) components,

Low energy consumption

A component,

Component, etc.) transmit/receive data; and a power management interface to send/receive power or control signals to/from the PMIC 825.

In alternative embodiments (which may be combined with the embodiments described above), baseband circuitry 910 includes one or more digital baseband systems coupled to each other and to the CPU subsystem, audio subsystem, and 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 interconnect subsystem may include a bus system, a point-to-point connection, a network-on-chip (NOC) fabric, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include DSP circuitry, buffer memory, program memory, 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 910 may include protocol processing circuitry having 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 915).

Although not shown in fig. 9, in some embodiments, baseband circuitry 910 includes individual processing device(s) to operate one or more wireless communication protocols (e.g., "multi-protocol baseband processor" or "protocol processing circuitry") and includes individual processing device(s) to implement PHY layer functions. In these embodiments, the PHY layer functions include the radio control functions described above. In these embodiments, the protocol processing circuitry operates or implements various protocol layers/entities of one or more wireless communication protocols. In a first example, when baseband circuitry 910 and/or RF circuitry 906 are part of mmWave communication circuitry or some other suitable cellular communication circuitry, the protocol processing circuitry may operate the LTE protocol entity and/or the 5G/NR protocol entity. In a first example, the protocol processing circuitry will operate MAC, RLC, PDCP, SDAP, RRC and NAS functionality. In a second example, the protocol processing circuitry may operate one or more IEEE-based protocols when the baseband circuitry 910 and/or the RF circuitry 906 are part of a Wi-Fi communication system. In a second example, the protocol processing circuit will operate Wi-Fi MAC and Logical Link Control (LLC) functions. The protocol processing circuitry may include one or more memory structures (e.g., 904G) to store program code and data to operate protocol functions, and one or more processing cores to execute the program code and to perform various operations with the data. The baseband circuitry 910 may also support radio communication for more than one wireless protocol.

The various hardware elements of baseband circuitry 910 discussed herein may be implemented, for example, as a solder-in substrate including one or more Integrated Circuits (ICs), a single packaged IC soldered to a main circuit board, or a multi-chip module including two or more ICs. In one example, the components of baseband circuitry 910 may be combined in a single chip or chipset, or disposed on the same circuit board, as appropriate. In another example, some or all of the constituent components of baseband circuitry 910 and RF circuitry 906 may be implemented together, for example, as a System on a chip (SoC) or a System-in-Package (SiP). In another example, some or all of the constituent components of baseband circuitry 910 may be implemented as a separate SoC communicatively coupled with RF circuitry 906 (or multiple instances of RF circuitry 906). In another example, some or all of the constituent components of baseband circuitry 910 and application circuitry 805 may be implemented together as an individual SoC (e.g., "multi-chip package") mounted to the same circuit board.

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

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

In some embodiments, the receive signal path of the RF circuitry 906 may include mixer circuitry 906a, amplifier circuitry 906b, and filter circuitry 906 c. In some embodiments, the transmit signal path of the RF circuitry 906 may include filter circuitry 906c and mixer circuitry 906 a. The RF circuitry 906 may also include synthesizer circuitry 906d for synthesizing frequencies for use by the mixer circuitry 906a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 906a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuitry 908 based on the synthesized frequency provided by the synthesizer circuitry 906 d. The amplifier circuit 906b may be configured to amplify the downconverted signal and the filter circuit 906c may be a low-pass filter (LPF) or 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 910 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, although this is not a necessary requirement. In some embodiments, mixer circuitry 906a 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 906a of the transmit signal path may be configured to up-convert the input baseband signal based on the synthesis frequency provided by the synthesizer circuitry 906d to generate the RF output signal for the FEM circuitry 908. The baseband signal may be provided by the baseband circuitry 910 and may be filtered by the filter circuitry 906 c.

In some embodiments, mixer circuitry 906a of the receive signal path and mixer circuitry 906a of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion and up-conversion, respectively. In some embodiments, the mixer circuitry 906a of the receive signal path and the mixer circuitry 906a 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, the mixer circuitry 906a of the receive signal path and the mixer circuitry 906a of the transmit signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, mixer circuitry 906a of the receive signal path and mixer circuitry 906a 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 906 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 910 may include a digital baseband interface to communicate with the RF circuitry 906.

In some dual-mode embodiments, separate radio IC circuits 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 906d may be a fractional-N synthesizer or a fractional-N/N +1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuit 906d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

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

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), although this is not a necessary requirement. The divider control input may be provided by either baseband circuitry 910 or application circuitry 805, 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 circuitry 805.

The synthesizer circuit 906d of the RF circuit 906 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 Module 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 divide 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 Nd equal phase packets, where Nd is the number of delay elements in the delay line. Thus, 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 906d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with a quadrature generator and frequency divider circuit to generate multiple signals at the carrier frequency having multiple different phases from each other. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuitry 906 may include an IQ/polar converter.

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

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

The antenna array 911 includes one or more antenna elements, each configured to convert an electrical signal into a radio wave to travel through the air and convert a received radio wave into an electrical signal. For example, digital baseband signals provided by the baseband circuitry 910 are converted to analog RF signals (e.g., modulation waveforms) that are to be amplified and transmitted via antenna elements of an antenna array 911 comprising one or more antenna elements (not shown). The antenna elements may be omnidirectional, directional, or a combination of these. The antenna elements may be formed in a variety of arrangements that are known and/or discussed herein. Antenna array 911 may comprise a microstrip antenna or a printed antenna fabricated on the surface of one or more printed circuit boards. The antenna array 911 may be formed in a sheet of metal foil (e.g., a patch antenna) in a variety of shapes and may be coupled with the RF circuitry 906 and/or the FEM circuitry 908 using metal transmission lines or the like.

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

Fig. 10 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 10 shows a diagrammatic representation of hardware resources 1000, hardware resources 1000 including one or more processors (or processor cores) 1010, one or more memory/storage devices 1020, and one or more communication resources 1030, each of which may be communicatively coupled via a bus 1040. For embodiments utilizing node virtualization (e.g., NFV), a hypervisor 1002 may be executed to provide an execution environment for one or more network slices/subslices utilizing hardware resources 1000.

Processor 1010 may include, for example, a processor 1012 and a processor 1014. The processor(s) 1010 may be, for example, a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination of these.

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

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

(or low energy consumption)

) The components of the device are combined into a whole,

components and other communication components.

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

Fig. 11 provides an example illustration of a wireless apparatus, such as a User Equipment (UE), a Mobile Station (MS), a mobile wireless apparatus, a mobile communication apparatus, a tablet, a handset, or other type of wireless apparatus. The wireless device may include one or more antennas configured to communicate with a Node, a macro Node, a Low Power Node (LPN), or a transmitter station, such as a Base Station (BS), an evolved Node B (eNB), a baseband processing unit (BBU), a Remote Radio Head (RRH), a Remote Radio Equipment (RRE), a Relay Station (RS), a Radio Equipment (RE), or other type of Wireless Wide Area Network (WWAN) access point. The wireless device may be configured to communicate using at least one wireless communication standard, such as, but not limited to, 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), bluetooth, and WiFi. Wireless devices may communicate by utilizing separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. Wireless devices may communicate in a Wireless Local Area Network (WLAN), a Wireless Personal Area Network (WPAN), and/or a WWAN. The wireless device may also include a wireless modem. The wireless modem may, for example, include a wireless radio transceiver and baseband circuitry (e.g., a baseband processor). The wireless modem, in one example, can modulate signals transmitted by the wireless device via one or more antennas and demodulate signals received by the wireless device via one or more antennas.

Fig. 11 also provides an illustration of a microphone and one or more speakers that may be used for audio input and output from the wireless device. The display screen may be a Liquid Crystal Display (LCD) screen, or other types of display screens, such as an Organic Light Emitting Diode (OLED) display. The display screen may be configured as a touch screen. The touch screen may use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor may be coupled to internal memory to provide processing and display capabilities. The non-volatile memory port may also be used to provide data input/output options to a user. The non-volatile memory port may also be used to expand the memory capabilities of the wireless device. The keyboard may be integrated with or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard may also be provided using a touch screen.

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

The protocol layers of arrangement 1200 may include one or more of PHY 1210, MAC 1220, RLC 1230, PDCP 1240, SDAP1247, RRC 1255 and NAS layer 1257, among other higher layer functions not illustrated. The protocol layers may include one or more service access points (e.g.,

items

1259, 1256, 1250, 1249, 1245, 1235, 1225, and 1215 in fig. 12) that may provide communication between two or more protocol layers.

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

The instance(s) of MAC 1220 may process requests from instances of RLC 1230 via one or more MAC-SAPs 1225 and provide indications to instances of RLC 1230. These requests and indications communicated via MAC-SAP 1225 may include one or more logical channels. MAC 1220 may perform mapping between logical channels and transport channels, multiplexing MAC SDUs from one or more logical channels onto TBs for delivery to PHY 1210 via transport channels, demultiplexing MAC SDUs from TBs delivered from PHY 1210 via transport channels onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction by HARQ, and logical channel prioritization.

The instance(s) of RLC 1230 may process requests from instances of PDCP 1240 via one or more radio link control service access points (RLC-SAP) 1235 and provide indications to the instances of PDCP 1240. These requests and indications communicated via the RLC-SAP 1235 may include one or more RLC channels. RLC 1230 may operate in a variety of operating modes including: transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC 1230 may perform transmission of upper layer Protocol Data Units (PDUs), error correction by automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. RLC 1230 may also perform re-segmentation of RLC data PDUs for AM data transfer, re-order RLC data PDUs for UM and AM data transfer, detect duplicate data for UM and AM data transfer, discard RLC SDUs for UM and AM data transfer, detect protocol errors for AM data transfer, and perform RLC re-establishment.

The instance(s) of PDCP 1240 may process and provide indications of requests from the instance(s) of RRC 1225 and/or the instance(s) of SDAP1247 via packet data convergence protocol service access point (PDCP-SAP) 1245. These requests and indications communicated via the PDCP-SAP1245 may include one or more radio bearers. The PDCP 1240 may perform header compression and decompression of IP data, maintain PDCP Sequence Number (SN), perform in-order delivery of upper layer PDUs at lower layer re-establishment, eliminate duplication of lower layer SDUs at lower layer re-establishment for radio bearers mapped on the RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, control timer-based dropping of data, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

The instance(s) of the SDAP1247 may process requests from and provide indications to one or more higher layer protocol entities via one or more SDAP-SAP 1249. These requests and indications communicated via the SDAP-SAP 1249 may include one or more QoS flows. The SDAP1247 may map QoS flows to DRBs and vice versa and may also mark QFIs in DL and UL packets. A single SDAP entity 1247 may be configured for individual PDU sessions. In the UL direction, the NG-RAN 710 can control the mapping of QoS flows to DRB(s) in two different ways, i.e. either a reflective mapping or an explicit mapping. For reflective mapping, the SDAP1247 of the UE 701 may monitor the QFI of the DL packets for each DRB and may apply the same mapping for packets flowing in the UL direction. For a DRB, the SDAP1247 of the UE 701 may map UL packets belonging to the QoS flow(s) corresponding to the QoS flow ID(s) and PDU sessions observed for the DRB in DL packets. To enable reflective mapping, the NG-RAN may tag DL packets over the Uu interface with a QoS flow ID. Explicit mapping may involve the RRC 1255 configuring the SDAP1247 with an explicit QoS flow to DRB mapping rule, which may be stored and followed by the SDAP 1247. In an embodiment, the SDAP1247 may be used only in NR implementations and may not be used in LTE implementations.

The RRC 1255 may configure aspects of one or more protocol layers via one or more management service access points (M-SAPs), which may include one or more instances of PHY 1210, MAC 1220, RLC 1230, PDCP 1240, and SDAP 1247. In an embodiment, an instance of RRC 1255 may process requests from one or more NAS entities 1257 via one or more RRC-SAPs 1256 and provide an indication to one or more NAS entities 1257. The main services and functions of RRC 1255 may include the broadcast of system information (e.g., included in MIB or SIB related NAS), the broadcast of system information related to Access Stratum (AS), the paging, establishment, maintenance and release of RRC connections between UE 701 and RAN 710 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification and RRC connection release), the establishment, configuration, maintenance and release of point-to-point radio bearers, security functions including key management, inter-RAT mobility, and measurement configuration for UE measurement reporting. The MIB and SIBs may include one or more IEs, each of which may include an individual data field or data structure.

The NAS 1257 may form the highest layer of a control plane between the UE 701 and the AMF. The NAS 1257 may support mobility and session management procedures for the UE 701 to establish and maintain IP connectivity between the UE 701 and the P-GW in the LTE system.

According to various embodiments, one or more protocol entities of the arrangement 1200 may be implemented in the UE 701, in the RAN node 711, in an NR implementation in an AMF or in an LTE implementation in an MME, in an NR implementation in an UPF or in an LTE implementation in an S-GW and a P-GW, etc. for a control plane or user plane communication protocol stack between the above mentioned devices. In such embodiments, one or more protocol entities that may be implemented in one or more of the UE 701, the gNB 711, the AMF, etc. may communicate with various peer protocol entities that may be implemented in or on another device, such communication being performed using the services of various lower layer protocol entities. In some embodiments, the gNB-CU of the gNB 711 may host RRC 1255, SDAP1247, and PDCP 1240 of the gNB that control the operation of one or more gNB-DUs, and the gNB-DUs of the gNB 711 may each host RLC 1230, MAC 1220, and PHY 1210 of the gNB 711.

In a first example, the control plane protocol stack may include, in order from the highest layer to lower layers, NAS 1257, RRC 1255, PDCP 1240, RLC 1230, MAC 1220 and PHY 1210. In this example, upper layer 1260 may be built on top of NAS 1257, which includes IP layer 1261, SCTP 1262, and application layer signaling protocol (AP) 1263.

In NR implementations, AP 1263 may be a NG application protocol layer (NGAP or NG-AP)1263 for NG interfaces 713 defined between NG-RAN nodes 711 and AMFs, or AP 1263 may be an Xn application protocol layer (XnAP or Xn-AP)1263 for Xn interfaces 712 defined between two or more RAN nodes 711.

NG-AP 1263 may support the functionality of NG interface 713 and may include Elementary Procedure (EP). The NG-AP EP may be a unit of interaction between the NG-RAN node 711 and the AMF. NG-AP 1263 service may include two groups: UE-associated services (e.g., services related to UE 701) and non-UE-associated services (e.g., services related to the entire NG interface instance between NG-RAN node 711 and the AMF). These services may include functions including, but not limited to: a paging function for sending a paging request to the NG-RAN node 711 involved in a specific paging area; a UE context management function for allowing the AMF to establish, modify and/or release a UE context in the AMF and NG-RAN node 711; mobility functions for the UE 701 in ECM-CONNECTED mode, for intra-system HO to support intra-NG-RAN mobility and for inter-system HO to support mobility from/to the EPS system; NAS signaling transport functionality for transporting or rerouting NAS messages between the UE 701 and the AMF; NAS node selection functionality for determining an association between an AMF and a UE 701; NG interface management function(s) for establishing NG interfaces and monitoring errors on the NG interfaces; a warning message transmission function for providing means to transmit a warning message or cancel an ongoing broadcast of a warning message via the NG interface; a configuration transfer function for request and transfer of RAN configuration information (e.g., SON information, Performance Measurement (PM) data, etc.) between two RAN nodes 711 via CN 720; and/or other similar functions.

XnAP 1263 may support the functionality of Xn interface 712 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may include procedures for handling UE mobility within the NG RAN 711 (or E-UTRAN), such as handover preparation and cancellation procedures, SN state transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and so forth. The XnAP global procedures may include procedures unrelated to the particular UE 701, such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, and so forth.

In an LTE implementation, AP 1263 may be an S1 application protocol layer (S1-AP)1263 for an S1 interface 713 defined between E-UTRAN node 711 and an MME, or AP 1263 may be an X2 application protocol layer (X2AP or X2-AP)1263 for an X2 interface 712 defined between two or more E-UTRAN nodes 711.

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

X2AP 1263 may support the functionality of X2 interface 712 and may include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may include procedures for handling UE mobility within E-UTRAN 720, such as handover preparation and cancellation procedures, SN state transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, dual connectivity related procedures, and so forth. The X2AP global procedures may include procedures unrelated to the particular UE 701, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, and so forth.

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

In a second example, the user plane protocol stack may include, in order from the highest layer to the lowest layer, SDAP1247, PDCP 1240, RLC 1230, MAC 1220 and PHY 1210. The user plane protocol stack may be used for communication between the UE 701, RAN node 711 and UPF in NR implementations and between the S-GW and P-GW in LTE implementations. In this example, the upper layer 1251 may be built on top of the SDAP1247 and may include a User Datagram Protocol (UDP) and IP security layer (UDP/IP)1252, a General Packet Radio Service (GPRS) Tunneling Protocol for the User Plane layer 1253, and a User Plane PDU layer (UP PDU) 1263.

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

GTP-U1253 may be used to carry user data within the GPRS core network and between the radio access network and the core network. The user data transmitted may be packets in any one of the formats, e.g., IPv4, IPv6, or PPP. UDP/IP 1252 may provide a checksum for data integrity, port numbers for addressing different functions at source and destination, and encryption and authentication on selected data streams. The RAN node 711 and the S-GW may utilize the S1-U interface to exchange user plane data via a protocol stack including an L1 layer (e.g., PHY 1210), an L2 layer (e.g., MAC 1220, RLC 1230, PDCP 1240, and/or SDAP 1247), UDP/IP layer 1252, and GTP-U1253. The S-GW and the P-GW may utilize the S5/S8a interface to exchange user plane data via a protocol stack including a L1 layer, a L2 layer, a UDP/IP layer 1252, and a GTP-U layer 1253. As previously described, the NAS protocol may support mobility and session management procedures for the UE 701 to establish and maintain IP connectivity between the UE 701 and the P-GW.

Additionally, although not shown in fig. 12, an application layer may exist above AP 1263 and/or transport network layer 1254. The application layer may be a layer: in this layer, a user of UE 701, RAN node 711, or other network element interacts with a software application, for example, executed by application circuitry 805. The application layer may also provide one or more interfaces for software applications to interact with the communication system (e.g., baseband circuitry 910) of the UE 701 or RAN node 711. In some implementations, the IP layer and/or the application layer can provide the same or similar functionality as layers 5-7 of the Open Systems Interconnection (OSI) model (e.g., OSI layer 7-application layer, OSI layer 6-presentation layer, and OSI layer 5-session layer), or some portion thereof.

For one or more embodiments, at least one of the components set forth in one or more of the foregoing figures may be configured to perform one or more of the operations, techniques, processes, and/or methods set forth in the example section below. For example, the baseband circuitry described above in connection with one or more of the foregoing figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc., described above in connection with one or more of the preceding figures, can be configured to operate in accordance with one or more of the examples set forth below in the example section.

Examples of the invention

The following examples relate to particular technology embodiments and indicate particular features, elements or actions that may be used or otherwise combined in implementing such embodiments.

Example 1 includes an apparatus of a User Equipment (UE) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, comprising: one or more processors configured to: identifying, at the UE, a D-PUR for transmission from the UE to an evolved node B (eNB); determining, at the UE, whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein the user data greater than the TBS is a first data segment and remaining user data is a second data segment; encoding, at the UE, a Radio Resource Control (RRC) resume request message with the user data for transmission to the eNB when the user data is less than or equal to the TBS; multiplexing, at the UE, the first data segment with the RRC Continue request message when the user data is greater than the TBS; encoding, at the UE, the first data segment multiplexed with the RRC continuation request message in the D-PUR for transmission to the eNB; and encoding, at the UE, the second data segment in the transport block for transmission in the D-PUR or in an RRC _ CONNECTED state; and a memory interface configured to store the D-PUR in a memory.

Example 2 includes the apparatus of example 1, wherein the one or more processors are further configured to: identifying, at the UE, a hybrid automatic repeat request (HARQ) process Identifier (ID); starting a PUR retransmission timer at the UE after transmission in the D-PUR; and restarting the PUR retransmission timer at the UE after retransmission in the D-PUR.

Example 3 includes the apparatus of example 2, wherein the one or more processors are further configured to: prior to expiration of the PUR retransmission timer, decoding, at the UE, one or more of: a retransmission grant received from the eNB; a NACK received from the eNB signaling the UE to initiate Early Data Transmission (EDT) random access; a successful ID received from the eNB signaling the UE to transition to sleep mode; or an RRC resume request message received from the eNB signaling the UE to stay in an idle mode or to transition to an RRC connected mode.

Example 4 includes the apparatus of example 2, wherein the one or more processors are further configured to: retransmitting, at the UE, the first data segment of the D-PUR multiplexed with the RRC continuation request message when the PUR retransmission timer expires; or initiating Early Data Transmission (EDT) random access or non-EDT random access at the UE when the PUR retransmission timer expires.

Example 5 includes the apparatus of example 1, wherein the one or more processors are further configured to: monitoring, at the UE, a Physical Downlink Control Channel (PDCCH) using a Radio Network Temporary Identifier (RNTI) provided in the D-PUR.

Example 6 includes the apparatus of example 1, wherein the one or more processors are further configured to: terminating a D-PUR occasion at the UE, if: a D-PUR transmission failure is indicated; or the UE does not receive an RRC message.

Example 7 includes the apparatus of example 1, wherein the one or more processors are further configured to: decoding, at the UE, a Timing Advance (TA) command received from the eNB, wherein the TA command signals the UE to restart a TA validity timer.

Example 8 includes the apparatus of example 1, wherein the one or more processors are further configured to: encoding, at the UE, the RRC Continue request message without the user data for transmission to the eNB when the user data is greater than the TBS; or encoding, at the UE, a Buffer Status Report (BSR) in the D-PUR for transmission to the eNB.

Example 9 includes the apparatus of example 1, wherein the one or more processors are further configured to: encoding, at the UE, the first data segment multiplexed with the RRC Continue request message in the D-PUR for transmission to the eNB, wherein the RRC Continue request message comprises a UE Identifier (ID) or control plane data in an RRC EarlyDataRequest encapsulated in the D-PUR.

Example 10 includes the apparatus of any of examples 1-9, wherein the one or more processors are further configured to: decoding, at the UE, a D-PUR response Service Data Unit (SDU) comprising one or more of: an Acknowledgement (ACK); retransmitting the transmission grant; a new downlink assignment; a contention resolution Medium Access Control (MAC) Control Element (CE); a Timing Advance (TA) command; a new uplink grant; a temporary cell radio network temporary identifier (C-RNTI); or a hybrid automatic repeat request (HARQ) process Identifier (ID).

Example 11 includes an apparatus of an evolved node b (enb) operable for dedicated preconfigured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, the apparatus comprising: one or more processors configured to: encoding, at the eNB, D-PUR configuration information for D-PUR transmissions from UEs in idle mode; decoding, at the eNB, a first data segment multiplexed with a Radio Resource Control (RRC) resume request message received from the UE in the D-PUR; and decoding, at the eNB, a second data segment in a transport block received from the UE in the D-PUR or in an RRC _ CONNECTED state; and a memory interface configured to store the D-PUR in a memory.

Example 12 includes the apparatus of example 11, wherein the one or more processors are further configured to: encoding, at the eNB, a Timing Advance (TA) command for transmission to the UE, wherein the TA command signals the UE to restart a TA validity timer.

Example 13 includes the apparatus of example 11, wherein the one or more processors are further configured to: decoding, at the eNB, a Buffer Status Report (BSR) received from the UE in the D-PUR.

Example 14 includes the apparatus of example 11, wherein the one or more processors are further configured to: decoding, at the eNB, the first data segment multiplexed with the RRC resume request message received from the UE in the D-PUR, wherein the RRC resume request message comprises a UE Identifier (ID) or a RRCEarlyDataRequest message comprising control plane data.

Example 15 includes the apparatus of example 11, wherein the one or more processors are further configured to: encoding, at the eNB, one or more of: retransmitting the transmission grant; receiving a NACK signaling the UE to initiate an Early Data Transmission (EDT) random access or normal random access procedure; signaling a successful ID of the UE to transition to sleep mode; or an RRC continue message signaling the UE to stay in the idle mode or an RRC connection setup message signaling the UE to transition to an RRC connected mode.

Example 16 includes the apparatus of example 11, wherein the one or more processors are further configured to: continuing the D-PUR at the eNB with: the eNB has not verified that the UE received a D-PUR release indicator; or the D-PUR release operation is unsuccessful; or the D-PUR reconfiguration operation is unsuccessful.

Example 17 includes the apparatus of any one of examples 11 to 16, wherein the one or more processors are further configured to: encoding, at the eNB, a D-PUR response Service Data Unit (SDU) comprising one or more of: an Acknowledgement (ACK); retransmitting the transmission grant; a new downlink assignment; a contention resolution Medium Access Control (MAC) Control Element (CE); a Timing Advance (TA) command; a new uplink grant; a temporary cell radio network temporary identifier (C-RNTI); or a hybrid automatic repeat request (HARQ) process Identifier (ID).

Example 18 includes at least one machine readable storage medium having instructions embodied thereon for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, the instructions when executed by one or more processors at a User Equipment (UE) to perform operations comprising: identifying, at the UE, a D-PUR for transmission from the UE in idle mode to an evolved node B (eNB); determining, at the UE, whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein the user data greater than the TBS is a first data segment and remaining of the user data is a second data segment; encoding, at the UE, a Radio Resource Control (RRC) resume request message with the user data for transmission to the eNB when the user data is less than or equal to the TBS; multiplexing, at the UE, the first data segment with the RRC Continue request message when the user data is greater than the TBS; encoding, at the UE, the first data segment multiplexed with the RRC continuation request message in the D-PUR for transmission to the eNB; and encoding, at the UE, the second data segment in the transport block for transmission in the D-PUR or in an RRC _ CONNECTED state.

Example 19 includes the at least one machine readable storage medium of example 18, further comprising instructions that when executed perform the following: identifying, at the UE, a hybrid automatic repeat request (HARQ) process Identifier (ID); starting a PUR retransmission timer at the UE after transmission in the D-PUR; and restarting the PUR retransmission timer at the UE after retransmission in the D-PUR.

Example 20 includes the at least one machine readable storage medium of example 19, further comprising instructions that when executed perform operations comprising: prior to expiration of the PUR retransmission timer, decoding, at the UE, one or more of: a retransmission grant received from the eNB; a NACK received from the eNB signaling the UE to initiate an Early Data Transmission (EDT) random access or normal random access procedure; a successful ID received from the eNB signaling the UE to transition to sleep mode; or an RRC message received from the eNB signaling the UE to stay in the idle mode or to transition to an RRC connected mode. Retransmitting, at the UE, the first data segment of the D-PUR multiplexed with the RRC continuation request message when the PUR retransmission timer expires; or initiating an Early Data Transmission (EDT) random access or normal random access procedure at the UE when the PUR retransmission timer expires.

The various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact-disk read-only memories (CD-ROMs), hard drives, non-transitory computer-readable storage media, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be random-access memory (RAM), erasable programmable read-only memory (EPROM), flash drives, optical drives, magnetic hard drives, solid state drives, or other media for storing electronic data. The nodes and wireless devices may also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or timer module (i.e., timer). In one example, selected components of the transceiver module may be located in a cloud radio access network (C-RAN). One or more programs that may implement or utilize the various techniques described herein may use an Application Programming Interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

As used herein, the term "circuitry" may refer to, be part of, or include the following: an Application Specific Integrated Circuit (ASIC), an electronic Circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic Circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or the functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, the circuitry may comprise logic operable, at least in part, in hardware.

It should be appreciated that many of the functional units described in this specification have been labeled as modules, in order to more clearly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module may not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. A module may be passive or active, including an agent operable to perform a desired function.

Reference throughout this specification to "an example" or "exemplary" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present technology. Thus, the appearances of the phrase "in one example" or the word "exemplary" in various places throughout this specification are not necessarily all referring to the same embodiment.

As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list were individually identified as a separate and unique member. Thus, without an indication to the contrary, individual members of such a list should not be construed as equivalent to any other member of the same list solely based on their presentation in a common group. Moreover, various embodiments and examples of the present technology may be referred to herein along with alternatives for the various components thereof. It is to be understood that such embodiments, examples, and alternatives are not to be construed as true equivalents of one another, but are to be considered separate and autonomous representations of the present technology.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the present technology. One skilled in the relevant art will recognize, however, that the technology can be practiced without one or more of the specific details, or with other methods, components, arrangements, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the technology.

While the foregoing examples illustrate the principles of the present technology in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and implementation details may be made without the exercise of inventive faculty, and without departing from the principles and concepts of the technology. Accordingly, it is not intended that the present technology be limited except as by the claims set forth below.

Claims

1. An apparatus of a User Equipment (UE) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, the apparatus comprising:

one or more processors configured to:

identifying, at the UE, a D-PUR for transmission from the UE to an evolved node B (eNB);

determining, at the UE, whether user data for transmission on the D-PUR is less than or equal to or greater than a transport block having a Transport Block Size (TBS) for the D-PUR, wherein the user data greater than the TBS is a first data segment and the remaining of the user data is a second data segment;

encoding, at the UE, a Radio Resource Control (RRC) resume request message with the user data for transmission to the eNB when the user data is less than or equal to the TBS;

multiplexing, at the UE, the first data segment with the RRC Continue request message when the user data is greater than the TBS;

encoding, at the UE, the first data segment multiplexed with the RRC continuation request message in the D-PUR for transmission to the eNB; and is

Encoding, at the UE, the second data segment in the transport block for transmission in the D-PUR or in an RRC _ CONNECTED state; and

a memory interface configured to store the D-PUR in a memory.

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

identifying, at the UE, a hybrid automatic repeat request (HARQ) process Identifier (ID);

starting a PUR retransmission timer at the UE after transmission in the D-PUR; and is

Restarting the PUR retransmission timer at the UE after retransmission in the D-PUR.

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

prior to expiration of the PUR retransmission timer, decoding, at the UE, one or more of:

a retransmission grant received from the eNB;

a NACK received from the eNB signaling the UE to initiate Early Data Transmission (EDT) random access;

a successful ID received from the eNB signaling the UE to transition to sleep mode; or

An RRC Continue request message received from the eNB signaling the UE to stay in idle mode or to transition to RRC connected mode.

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

retransmitting, at the UE, the first data segment of the D-PUR multiplexed with the RRC continuation request message when the PUR retransmission timer expires; or

Initiating Early Data Transmission (EDT) random access or non-EDT random access at the UE when the PUR retransmission timer expires.

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

monitoring, at the UE, a Physical Downlink Control Channel (PDCCH) using a Radio Network Temporary Identifier (RNTI) provided in the D-PUR.

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

terminating a D-PUR occasion at the UE, if:

a D-PUR transmission failure is indicated; or

The UE does not receive an RRC message.

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

decoding, at the UE, a Timing Advance (TA) command received from the eNB, wherein the TA command signals the UE to restart a TA validity timer.

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

encoding, at the UE, the RRC Continue request message without the user data for transmission to the eNB when the user data is greater than the TBS; or

Encoding, at the UE, a Buffer Status Report (BSR) in the D-PUR for transmission to the eNB.

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

encoding, at the UE, the first data segment multiplexed with the RRC Continue request message in the D-PUR for transmission to the eNB, wherein the RRC Continue request message comprises a UE Identifier (ID) or control plane data in an RRC EarlyDataRequest encapsulated in the D-PUR.

10. The apparatus of any of claims 1-9, wherein the one or more processors are further configured to:

decoding, at the UE, a D-PUR response Service Data Unit (SDU) comprising one or more of:

an Acknowledgement (ACK);

retransmitting the transmission grant;

a new downlink assignment;

a contention resolution Medium Access Control (MAC) Control Element (CE);

a Timing Advance (TA) command;

a new uplink grant;

a temporary cell radio network temporary identifier (C-RNTI); or

A hybrid automatic repeat request (HARQ) process Identifier (ID).

11. An apparatus of an evolved node b (enb) operable for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, the apparatus comprising:

one or more processors configured to:

encoding, at the eNB, D-PUR configuration information for D-PUR transmissions from UEs in idle mode;

decoding, at the eNB, a first data segment multiplexed with a Radio Resource Control (RRC) resume request message received from the UE in the D-PUR; and is

Decoding, at the eNB, a second data segment in a transport block received from the UE in the D-PUR or in an RRC _ CONNECTED state; and

a memory interface configured to store the D-PUR in a memory.

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

encoding, at the eNB, a Timing Advance (TA) command for transmission to the UE, wherein the TA command signals the UE to restart a TA validity timer.

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

decoding, at the eNB, a Buffer Status Report (BSR) received from the UE in the D-PUR.

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

decoding, at the eNB, the first data segment multiplexed with the RRC resume request message received from the UE in the D-PUR, wherein the RRC resume request message comprises a UE Identifier (ID) or a RRCEarlyDataRequest message comprising control plane data.

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

encoding, at the eNB, one or more of the following for transmission to the UE:

retransmitting the transmission grant;

receiving a NACK signaling the UE to initiate an Early Data Transmission (EDT) random access or normal random access procedure;

signaling a successful ID of the UE to transition to sleep mode; or

An RRC continue message signaling the UE to stay in the idle mode or an RRC connection setup message signaling the UE to transition to an RRC connected mode.

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

continuing the D-PUR at the eNB with:

the eNB has not verified that the UE received a D-PUR release indicator; or

The D-PUR release operation was unsuccessful; or

The D-PUR reconfiguration operation was unsuccessful.

17. The apparatus of any of claims 11-16, wherein the one or more processors are further configured to:

encoding, at the eNB, a D-PUR response Service Data Unit (SDU) comprising one or more of:

an Acknowledgement (ACK);

retransmitting the transmission grant;

a new downlink assignment;

a contention resolution Medium Access Control (MAC) Control Element (CE);

a Timing Advance (TA) command;

a new uplink grant;

a temporary cell radio network temporary identifier (C-RNTI); or

A hybrid automatic repeat request (HARQ) process Identifier (ID).

18. At least one machine readable storage medium having instructions embodied thereon for dedicated pre-configured uplink resource (D-PUR) communication in a third generation partnership project (3GPP) network, the instructions, when executed by one or more processors at a User Equipment (UE), perform the following:

identifying, at the UE, a D-PUR for transmission from the UE in idle mode to an evolved node B (eNB);

encoding, at the UE, the first data segment multiplexed with the RRC continuation request message into the D-PUR for transmission to the eNB; and is

At the UE, encoding the second data segment into the transport block for transmission in the D-PUR or in an RRC _ CONNECTED state.

19. The at least one machine readable storage medium of claim 18, further comprising instructions that when executed perform the following:

Restarting the PUR retransmission timer at the UE after a retransmission in the D-PUR.

20. The at least one machine readable storage medium of claim 19, further comprising instructions that when executed perform the following:

a retransmission grant received from the eNB;

a NACK received from the eNB signaling the UE to initiate an Early Data Transmission (EDT) random access or normal random access procedure;

An RRC message received from the eNB signaling the UE to stay in the idle mode or to transition to an RRC connected mode,

Initiating an Early Data Transmission (EDT) random access or normal random access procedure at the UE when the PUR retransmission timer expires.