WO2018119458A2

WO2018119458A2 - Pre-grant packet header processing

Info

Publication number: WO2018119458A2
Application number: PCT/US2017/068341
Authority: WO
Inventors: Satish C. Jha; Yaser FOUAD; Guangjie Li; Qian Li; Xiaoyun Wu; Geng Wu; JoonBeom Kim; Dawei YING; Vesh Raj SHARMA BANJADE; Hassan GHOZLAN; Ye Wu; Lu LU; Song Noh
Original assignee: Intel Corporation
Priority date: 2016-12-22
Filing date: 2017-12-22
Publication date: 2018-06-28
Also published as: WO2018119458A3

Abstract

Described is an apparatus of a User Equipment (UE). The apparatus may comprise a first circuitry and a second circuitry. The first circuitry may be operable to establish one or more headers respectively corresponding with one or more Service Data Units (SDUs). The second circuitry may be operable to form one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs. The second circuitry may also be operable to form a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY). The one or more resource grants may be available from the PHY after the one or more first PDUs are formed.

Description

PRE-GRANT PACKET HEADER PROCESSING

CLAIM OF PRIORITY

[0001] The present application claims priority under 35 U.S.C. § 119(e) to United

States Provisional Patent Application Serial Number 62/438,199 filed December 22, 2016, which is herein incorporated by reference in its entirety.

BACKGROUND

[0002] A variety of wireless cellular communication systems have been implemented, including a 3rd Generation Partnership Project (3 GPP) Universal Mobile

Telecommunications System, a 3GPP Long-Term Evolution (LTE) system, and a 3GPP LTE- Advanced (LTE-A) system. Next-generation wireless cellular communication systems based upon LTE and LTE-A systems are being developed, such as a 5th Generation wireless system / 5th Generation mobile networks (5G) system or 5G New Radio (NR) system. Next- generation wireless cellular communication systems may provide support for massive numbers of user devices like Narrowband Internet-of-Things (NB-IoT) devices, Cellular Internet-of-Things (CIoT) devices, or Machine-Type Communication (MTC) devices. Such devices may have very low device complexity, may be latency -tolerant, and may be designed for low throughput and very low power consumption.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The embodiments of the disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the disclosure. However, while the drawings are to aid in explanation and understanding, they are only an aid, and should not be taken to limit the disclosure to the specific embodiments depicted therein.

[0004] Fig. 1 illustrates a system architecture for a 5th Generation (5G) New Radio

(NR) system, in accordance with some embodiments of the disclosure.

[0005] Fig. 2 illustrates a protocol stack for a 5G NR system, in accordance with some embodiments of the disclosure.

[0006] Figs. 3A-3B illustrate a functional overview of 5G NR Higher Layer (HL) protocol-layer mechanisms, in accordance with some embodiments of the disclosure.

[0007] Figs. 4A-4B illustrate a flow for generating a final HL Protocol Data Unit

(PDU) packet, in accordance with some embodiments of the disclosure. l [0008] Fig. 5 illustrates a pre-grant HL PDU structure, in accordance with some embodiments of the disclosure.

[0009] Figs. 6-8 illustrate final HL PDU structures, in accordance with some embodiments of the disclosure.

[0010] Fig. 9 illustrates a header for a final Acknowledged Mode (AM) HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0011] Fig. 10 illustrates a header for a final AM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0012] Fig. 11 illustrates a header for a final Unacknowledged Mode (UM) HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0013] Fig. 12 illustrates a header for a final UM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0014] Figs. 13A-13B illustrate a flow for generating a final HL PDU packet, in accordance with some embodiments of the disclosure.

[0015] Fig. 14 illustrates a header for a final AM HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0016] Fig. 15 illustrates a header for a final AM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0017] Fig. 16 illustrates a header for a final UM HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0018] Fig. 17 illustrates a header for a final UM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[0019] Fig. 18 illustrates an Evolved Node B (eNB) and a User Equipment (UE), in accordance with some embodiments of the disclosure. [0020] Fig. 19 illustrates hardware processing circuitries for a UE for reducing PDU processing time after getting a resource grant, in accordance with some embodiments of the disclosure.

[0021] Fig. 20 illustrates methods for a UE for reducing PDU processing time after getting a resource grant, in accordance with some embodiments of the disclosure.

[0022] Fig. 21 illustrates methods for a UE for reducing PDU processing time after getting a resource grant, in accordance with some embodiments of the disclosure.

[0023] Fig. 22 illustrates example components of a device, in accordance with some embodiments of the disclosure.

[0024] Fig. 23 illustrates example interfaces of baseband circuitry, in accordance with some embodiments of the disclosure.

DETAILED DESCRIPTION

[0025] Various wireless cellular communication systems have been implemented or are being proposed, including a 3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications System (UMTS), a 3GPP Long-Term Evolution (LTE) system, a 3GPP LTE-Advanced system (LTE- A), and a 5th Generation wireless system / 5th Generation mobile networks (5G) system or 5G New Radio (NR) wireless cellular communication system. Next-generation wireless cellular communication systems may provide support for massive numbers of user devices like Narrowband Internet-of-Things (NB-IoT) devices, Cellular Internet-of-Things (CIoT) devices, or Machine-Type Communication (MTC) devices.

[0026] Fig. 1 illustrates a system architecture for a 5G NR system, in accordance with some embodiments of the disclosure. A system 100 may comprise various network nodes and interfaces, and may support various Things devices. (For the purposes of this disclosure, the term "Things" may comprise CIoT technologies, NB-IoT technologies, and/or MTC technologies. Accordingly, the term "Things devices" may comprise CIoT devices, NB-IoT devices, and/or MTC devices. For example, Things devices may include wearable devices.)

[0027] In some embodiments, system 100 may comprise one or more network User

Equipment (nUE) devices, which may implement a full sidelink protocol stack and/or a full direct link protocol stack (e.g., full Control-Plane and/or User-Plane functions). nUE devices may act as master UEs in a sidelink cell. For some embodiments, system 100 may comprise one or more Things User Equipment (tUE) devices (e.g., wearable UE devices), which may at least implement a full sidelink protocol stack, and in some embodiments may implement standalone direct link protocol stacks. tUE devices may act as slave UEs in a sidelink cell. System 100 may also comprise one or more 5G Radio Access Network (5G-RAN) nodes (e.g., Evolved Node-B (eNB) devices), and may also comprise one or more 5G Core Network (CN) nodes.

[0028] For some embodiments, nUE devices may be coupled to 5G-RAN nodes over a 5G NR direct link (Xu-d) interface. In some embodiments, tUE devices may be coupled to nUE devices and/or other tUE devices over a 5G NR sidelink (Xu-s) interface, and/or may be coupled to 5G-RAN nodes over an Xu-d interface.

[0029] Accordingly, Xu-d interfaces may provide radio links between nUE devices and/or tUE devices at one end and a 5G infrastructure at another end, and Xu-s may provide a radio link between nUE devices at one end and tUE devices at another end, or between two tUE devices. In various embodiments, an nUE and one or more associated tUEs may form a sidelink cell (which may also be termed a 5G Things personal area network (tPAN)).

[0030] A tUE device may communicate with an Evolved Universal Mobile

Telecommunications System (UMTS) Terrestrial Radio Access Network (EUTRAN) via an nUE device. An nUE may in turn be associated with one or more tUEs, and may form a tPAN with those tUEs. A large number of nUEs may coexist in a geographical region, and one or more tPANs associated with them may result in a highly-dense network scenario.

[0031] Meanwhile, an EUTRAN may assign a common resource pool for 5G NR

Things sidelink communication (e.g., via Xu-s interfaces). This resource pool may be shared among multiple tPANs in a nearby geographical area and/or among tUEs within each tPAN (e.g., on a contention-based resource access basis).

[0032] nUEs and tUEs coupled to other devices via Xu-d and Xu-s interfaces may implement one or more Higher Layer (HL) protocol stacks. nUEs and tUEs coupled to another device via an Xu-d interface may implement a direct-link HL protocol stack, while nUEs and tUEs coupled to another device via an Xu-s interface may implement a 5G NR Things sidelink Higher Layer (tSL-HL) protocol stack.

[0033] Fig. 2 illustrates a protocol stack for a 5G NR system, in accordance with some embodiments of the disclosure. A protocol stack 200 may comprise an Internet Protocol (IP) / Application layer, a tSL-HL, a tSL Radio Resource Control (tSL-RRC), and/or a tSL Physical Layer (tSL-PHY). As disclosed herein, an HL (e.g., a tSL-HL) may comprise one or more protocol layers between a Physical Layer (PHY) (e.g., a tSL-PHY) and an IP/ Application layer in a User Plane (UP), and/or between a PHY and a Radio Resource Control (RRC) (e.g., a tSL-RRC) in a Control Plane (CP). For example, an HL may comprise layers substantially similar to a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, and/or a Packet Data Convergence Protocol (PDCP) layer of a legacy LTE system.

[0034] In some systems, packet processing mechanisms and methods may be targeted at least in part to reduce packet headers per HL Protocol Data Unit (PDU), for cases in which an HL PDU size may be from a few bytes to a few tens of bytes (e.g., less than 75 bytes). An HL PDU might be kept small when one PDU is transmitted for one or more allocated Physical Resource Blocks (PRBs), due to the contention environment among nearby tPANs, intra-tPAN contention, or both. Smaller PDU sizes may help minimize resource waste in cases of collision. In such cases, it may be advantageous to reduce sizes of packet headers added at an HL so that a data-to-packet-header ratio may remain more manageable.

[0035] For some embodiments, an HL PDU (which may comprise a PDU header and a PDU payload) may be generated after getting a grant. Moreover, if more than one PDU is to be generated in the same transmission Time Interval (TTI) by an HL transmitting entity of a tUE, the HL PDUs may be generated in sequence. However, in some embodiments there may be a very stringent processing time budget to prepare one or more HL PDUs after receiving a resource grant in via an Xu-s interface.

[0036] Moreover, resource allocation, data PDU generation, PDU transmission, and/or ACK transmission/reception may take place within a TTI or a subframe (e.g., within 1 millisecond (ms)) for Uplink (UL) transmission over an Xu-s interface. At the same time, resource allocation for a tUE may also be for more than 1 HL PDU in a TTI. Since there may be a relatively small amount of time for an HL to prepare one or more HL PDUs after getting a resource allocation (e.g., a few microseconds), it may not be feasible to prepare one or more HL PDUs in the available time budget. Furthermore, the time budget from a grant indication to the transmission of data by a PHY may be shared as processing times at an HL and a PHY, which may make processing time available for PDU generation at an HL more stringent.

[0037] Disclosed herein are various mechanisms and methods for reducing PDU processing time after getting a resource grant. Some embodiments may incorporate increased pre-processing calculations for a PDU header and PDU payload of one or more PDUs before receiving a grant. Some embodiments may incorporate reduced processing time requirements after receiving a grant for calculation for a PDU header and PDU payload of one or more PDUs. Some embodiments may incorporate increased overlapping of processing times for generated PDUs in cases of more than one generated PDU in a TTI (e.g., enabling or increasing parallel processing of multiple PDUs in a TTI). Some embodiments may incorporate increased overlapping of processing times at an HL and a PHY for one or more PDUs.

[0038] In the following description, numerous details are discussed to provide a more thorough explanation of embodiments of the present disclosure. It will be apparent to one skilled in the art, however, that embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring embodiments of the present disclosure.

[0039] Note that in the corresponding drawings of the embodiments, signals are represented with lines. Some lines may be thicker, to indicate a greater number of constituent signal paths, and/or have arrows at one or more ends, to indicate a direction of information flow. Such indications are not intended to be limiting. Rather, the lines are used in connection with one or more exemplary embodiments to facilitate easier understanding of a circuit or a logical unit. Any represented signal, as dictated by design needs or preferences, may actually comprise one or more signals that may travel in either direction and may be implemented with any suitable type of signal scheme.

[0040] Throughout the specification, and in the claims, the term "connected" means a direct electrical, mechanical, or magnetic connection between the things that are connected, without any intermediary devices. The term "coupled" means either a direct electrical, mechanical, or magnetic connection between the things that are connected or an indirect connection through one or more passive or active intermediary devices. The term "circuit" or "module" may refer to one or more passive and/or active components that are arranged to cooperate with one another to provide a desired function. The term "signal" may refer to at least one current signal, voltage signal, magnetic signal, or data/clock signal. The meaning of "a," "an," and "the" include plural references. The meaning of "in" includes "in" and "on."

[0041] The terms "substantially," "close," "approximately," "near," and "about" generally refer to being within +/- 10% of a target value. Unless otherwise specified the use of the ordinal adjectives "first," "second," and "third," etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0042] It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.

[0043] The terms "left," "right," "front," "back," "top," "bottom," "over," "under," and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions.

[0044] For purposes of the embodiments, the transistors in various circuits, modules, and logic blocks are Tunneling FETs (TFETs). Some transistors of various embodiments may comprise metal oxide semiconductor (MOS) transistors, which include drain, source, gate, and bulk terminals. The transistors may also include Tri-Gate and FinFET transistors, Gate All Around Cylindrical Transistors, Square Wire, or Rectangular Ribbon Transistors or other devices implementing transistor functionality like carbon nanotubes or spintronic devices. MOSFET symmetrical source and drain terminals i.e., are identical terminals and are interchangeably used here. A TFET device, on the other hand, has asymmetric Source and Drain terminals. Those skilled in the art will appreciate that other transistors, for example, Bi-polar junction transistors-BJT PNP/NPN, BiCMOS, CMOS, etc., may be used for some transistors without departing from the scope of the disclosure.

[0045] For the purposes of the present disclosure, the phrases "A and/or B" and "A or

B" mean (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and/or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).

[0046] In addition, the various elements of combinatorial logic and sequential logic discussed in the present disclosure may pertain both to physical structures (such as AND gates, OR gates, or XOR gates), or to synthesized or otherwise optimized collections of devices implementing the logical structures that are Boolean equivalents of the logic under discussion.

[0047] In addition, for purposes of the present disclosure, the term "eNB" may refer to a legacy LTE capable Evolved Node-B (eNB), a Narrowband Internet-of-Things (NB-IoT) capable eNB, a Cellular Intemet-of-Things (CIoT) capable eNB, a Machine-Type

Communication (MTC) capable eNB, an Access Point (AP), and/or another base station for a wireless communication system. The term "gNB" may refer to a 5G-capable or NR-capable eNB. For purposes of the present disclosure, the term "UE" may refer to a legacy LTE capable User Equipment (UE), an NB-IoT capable UE, a CIoT capable UE, an MTC capable UE, a Station (STA), and/or another mobile equipment for a wireless communication system. The term "UE" may also refer to a next-generation or 5G capable UE. [0048] Various embodiments of eNBs and/or UEs discussed below may process one or more transmissions of various types. Some processing of a transmission may comprise demodulating, decoding, detecting, parsing, and/or otherwise handling a transmission that has been received. In some embodiments, an eNB or UE processing a transmission may determine or recognize the transmission's type and/or a condition associated with the transmission. For some embodiments, an eNB or UE processing a transmission may act in accordance with the transmission's type, and/or may act conditionally based upon the transmission's type. An eNB or UE processing a transmission may also recognize one or more values or fields of data carried by the transmission. Processing a transmission may comprise moving the transmission through one or more layers of a protocol stack (which may be implemented in, e.g., hardware and/or software-configured elements), such as by moving a transmission that has been received by an eNB or a UE through one or more layers of a protocol stack.

[0049] Various embodiments of eNBs and/or UEs discussed below may also generate one or more transmissions of various types. Some generating of a transmission may comprise modulating, encoding, formatting, assembling, and/or otherwise handling a transmission that is to be transmitted. In some embodiments, an eNB or UE generating a transmission may establish the transmission's type and/or a condition associated with the transmission. For some embodiments, an eNB or UE generating a transmission may act in accordance with the transmission's type, and/or may act conditionally based upon the transmission's type. An eNB or UE generating a transmission may also determine one or more values or fields of data carried by the transmission. Generating a transmission may comprise moving the transmission through one or more layers of a protocol stack (which may be implemented in, e.g., hardware and/or software-configured elements), such as by moving a transmission to be sent by an eNB or a UE through one or more layers of a protocol stack.

[0050] In various embodiments, resources may span various Resource Blocks (RBs),

Physical Resource Blocks (PRBs), and/or time periods (e.g., frames, subframes, and/or slots) of a wireless communication system. In some contexts, allocated resources (e.g., channels, Orthogonal Frequency -Division Multiplexing (OFDM) symbols, subcarrier frequencies, resource elements (REs), and/or portions thereof) may be formatted for (and prior to) transmission over a wireless communication link. In other contexts, allocated resources (e.g., channels, OFDM symbols, subcarrier frequencies, REs, and/or portions thereof) may be detected from (and subsequent to) reception over a wireless communication link. [0051] In various embodiments, a range of HL functionalities (which may be substantially similar to legacy LTE MAC functionalities, RLC functionalities, and/or PDCP functionalities) for UP and CP data processing may be merged into a single layer (e.g., a tSL-HL), which may advantageously reduce PDU generation and/or processing time for a resource grant of one or more PDUs in a TTI for transmission over an Xu-s interface.

[0052] In addition, although the mechanisms and methods disclosed herein may be suitable for use in an Xu-s interface HL (e.g., a sidelink interface HL for tUEs and/or nUEs), the mechanisms and methods disclosed herein may also be appropriate for use in an Xu-d interface HL (e.g., a direct link interface HL for tUEs and/or nUEs), and references herein to HL concepts may apply in the context of HLs in general, and in the context of 5G NR Things sidelink HLs specifically. Accordingly, references in general to, for example, HL SDUs, HL PDUs (both pre-grant HL PDUs and final HL PDUs), HL buffers, HL CEs, HL SNs, HL entities, HL transmitting sides or HL transmitting entities, HL receiving sides or HL receiving entities, RRCs, and/or PHYs, may include, respectively, tSL-HL SDUs, tSL-HL HL PDUs (both pre-grant tSL-HL PDUs and final tSL-HL PDUs), tSL-HL buffers, tSL-HL CEs, tSL-HL SNs, tSL-HL entities, tSL-HL transmitting sides or tSL-HL transmitting entities, tSL-HL receiving sides or tSL-HL receiving entities, tSL-RRCs, and/or tSL-PHYs.

[0053] With reference to Figs. 1 and 2, an Xu-s interface may couple a tUE and an nUE. A data packet to be transmitted over the Xu-s interface may be received as an HL Service Data Unit (SDU) from an IP/Appli cation layer (e.g., via UP data), or from an RRC (e.g., via CP data). The RRC may handle configuration of the HL. One or more received HL SDUs may then be processed substantially immediately (e.g., such as through pre-processing before receiving a grant) to form a pre-grant HL PDU.

[0054] Figs. 3A-3B illustrate a functional overview of 5G NR HL protocol-layer mechanisms, in accordance with some embodiments of the disclosure. A system 300 may comprise a transmitting entity 310 and a receiving entity 360 (either or both of which may be portions of an nUE or a tUE, and either or both of which may implement various layers of a protocol stack for an Xu-s interface or an Xu-d interface). Transmitting entity 310 may comprise an HL transmitting entity 312, and receiving entity 360 may comprise an HL receiving entity 362 (either or both of which may be portions of tSL-HLs). As shown, data packets transmitted through HL transmitting entity 312 and received through HL receiving entity 362 may be processed in a variety of ways.

[0055] In HL transmitting entity 312, one or more pre-grant HL PDUs, one or more pre-grant HL PDU segments, and/or one or more Control Elements (CEs) may be multiplexed to prepare a final HL PDU after receiving a grant. The final HL PDU size may be matched with a Transport Block (TB) size indicated by a PHY (e.g., a grant size), which may be disposed to carrying padding in some cases. HL transmitting entity 312 may then pass a final HL PDU to the PHY for transmission via a Hybrid Automatic Repeat Request (HARQ) entity. In various embodiments, HL transmitting entity 312 and/or HL receiving entity 362 may be coupled with an RRC.

[0056] HL transmitting entity 312 might not be disposed to preparing the completed final HL PDU before beginning to transfer it to the PHY. Instead, HL transmitting entity 312 may start sending one or more pre-grant HL PDUs to the PHY substantially immediately after getting the grant indication, so that the PHY may start processing partial HL PDUs (e.g., portions of the final HL PDU), while HL transmitting entity 312 works on generating remaining portions of the final HL PDU (such as CEs, and/or remaining header parts that may be generated and added at the end of the final HL PDU after sending initial portions of the HL PDUs to the PHY).

[0057] HARQ entities at transmitting entity 310 and receiving entity 360 may perform HARQ retransmission. In some embodiments, HARQ retransmission may be performed on a per-PDU basis, while in some embodiments, HARQ retransmission may be performed on a per-PRB basis (e.g., for part of a PDU in cases of multi-PRB PDUs), based on configuration set by RRC.

[0058] A data packet HL SDU may go through various operations in HL transmitting entity 312, and HL transmitting entity 312 (along with HL receiving entity 362) may implement a variety of functions and/or capabilities for processing data packets. HL transmitting entity 312 and/or HL receiving entity 362 may maintain HL Sequence Numbers (SNs), which may provide a unique SN for each HL SDU. HL transmitting entity 312 and/or HL receiving entity 362 may at least partially implement in-sequence delivery of Upper Layer data via HL SDUs, detection and/or discarding of duplicate HL SDUs, and/or timer- based discarding of HL SDUs.

[0059] In some embodiments, HL transmitting entity 312 and/or HL receiving entity

362 may implement various security functions. Some embodiments may implement header compression and/or decompression of IP data flows (e.g., UP data flows). Some

embodiments may implement ciphering and deciphering of UP data and CP data. Some embodiments may implement integrity protection of CP data. The various security functions may optionally be configured by RRC. [0060] In various embodiments, HL transmitting entity 312 and/or HL receiving entity 362 may implement the addition of a length field, an HL SN, and/or other flags to one or more SDUs to get one or more pre-grant HL PDUs before getting a resource grant. There might not be a combination and/or a concatenation of SDUs to form a pre-grant HL PDU, and instead there may be one-to-one mapping between HL SDUs and pre-grant HL PDUs. As a result, pre-grant HL PDUs may have unique SNs.

[0061] In some embodiments, pre-grant HL PDUs may be stored in a transmission and retransmission buffer at the HL. Some embodiments may implement segmentation of pre-grant HL PDUs during a new transmission at a transmitting entity (e.g., at transmitting entity 310), and some embodiments may implement re-segmentation of pre-grant HL PDUs during re-transmission of pre-grant HL PDUs at a transmitting entity. At a receiving entity (e.g., at receiving entity 360), some embodiments may implement reassembly of pre-grant HL PDUs.

[0062] Some embodiments may implement multiplexing of pre-grant HL PDUs, pre- grant HL PDU segments, and/or CEs (such as buffer Status Report (BSR) and/or Power HeadRoom Report (PHR)) to form a final HL PDU at the transmitting entity (e.g., at HL transmitting entity 312). Some embodiments may implement demultiplexing of these elements at a receiving entity (e.g., at HL receiving entity 362). Some embodiments may also implement detection and discarding of duplicate HL PDUs at the receiving entity.

[0063] Some embodiments may implement protocol error detection and/or recovery by retransmission at one or both of two different levels. In some embodiments, HARQ may be implemented at a TB level, which may in turn implement HARQ retransmission on a per HL PDU basis and/or HARQ retransmission on a per PRB basis (e.g., one or more HARQ retransmission processes per HL PDU, based on whether resource allocation is one or more PRBs). In some embodiments, Automatic Repeat Request (ARQ) may be implemented at a pre-grant HL PDU level.

[0064] An HL may have various types of transmission and ARQ retransmission buffers, which may store different types of traffic. Various embodiments may comprise a Mission Critical (MC) and/or Ultra-high Reliability and Low Latency Communication (URLLC) data transmission and retransmission buffer, a CP data transmission and retransmission buffer, and/or a UP data transmission and retransmission buffer. Storing these three types of data in separate buffers may advantageously enable various embodiments to treat these traffic types differently while asking for resource grants and multiplexing data during final HL PDU generation. For example, if a packet comes in an MC/URLLC data transmission and retransmission buffer, an HL entity (e.g., an HL entity within a tUE) may be disposed to requesting a resource grant immediately.

[0065] In determining priority for multiplexing and assembly or generation of new

HL PDUs, an HL entity (e.g., an HL transmitting entity and/or an HL receiving entity) may account for various sources for data to be transmitted. In some embodiments, the sources may include MC/URLLC data, such as MC/URLLC data (whether UP or CP) in an ARQ retransmission buffer, or MC/URLLC data (whether UP or CP) in a transmission buffer. In some embodiments, the sources may include BSR CE's. In some embodiments, the sources may include PHR CE's. In some embodiments, the sources may include non-MC and/or non- URLLC data.

[0066] Non-MC/non-URLLC data may come from a variety of sources. If control

PRBs and non-control PRBs are not separated, the sources may include CP PDUs in an ARQ retransmission buffer pending to be retransmitted, CP data in a CP transmission buffer, UP data in an AR retransmission buffer pending to be retransmitted, and UP data in a CP transmission buffer. If control PRBs and non-control PRBs are separated, the sources may include, for control PRB resource grants, CP PDUs in an ARQ retransmission buffer pending to be retransmitted, and CP data in a CP transmission buffer; and for non-control PRB resource grants, UP data in an ARQ retransmission buffer pending to be retransmitted, and UP data in a CP transmission buffer.

[0067] In some embodiments, the sources as listed above may be granted relative priorities, in decreasing order.

[0068] For some embodiments, CP PRBs may be separated from UP PRBs (and/or non-CP PRBs). In such embodiments, if a resource grant is for control PRBs, the resulting HL PDUs may merely include CP data. If the resource grant is for non-control PRBs, the resulting HL PDUs may merely include UP data. Note that if MC/URLLC data is waiting for transmission, then on any PRB, MC/URLLC data may gain priority, and merely MC/URLLC data may be transmitted for all resource grant. In some embodiments, once all MC/URLLC data is transmitted, regular data may be transmitted based on the PRB type (e.g., control PRB versus non-control PRB).

[0069] In various embodiments, various types of PDU may be selected for a given resource grant. An HL PDU may merely contain one type of data (e.g., MC, CP, or UP). So, an HL PDU may be an MC HL PDU, a CP HL PDU, or a UP HL PDU. MC data may primarily be UP data; however, it may have a higher priority than other, non-MC UP data. HL CEs such as BSR and PHR may be added at the end of PDUs for any of an MC HL PDU, a CP HL PDU, and/or a UP HL PDU.

[0070] Meanwhile, in some embodiments, an HL entity (e.g., in a tUE) may receive a single resource grant in a TTI to generate a single HL PDU, while in some embodiments, the HL entity may receive multiple resource grants in a TTI to generate multiple HL PDUs.

[0071] In embodiments in which an HL entity receives a single resource grant in a

TTI to generate a single HL PDU, the type of PDU generated after getting a resource grant may be as follows. First, if there is any MC/URLLC data (UP or CP) in an ARQ

retransmission buffer or MC/URLLC data (UP or CP) in a transmission buffer, an MC HL PDU may be generated.

[0072] Next, if there is non-MC/non-URLLC data (e.g., in the ARQ retransmission buffer and/or in the transmission buffer), the type of PDU generated may depend upon whether or not control PRBs and non-control PRBs are separated. If control PRBs and non- control PRBs are not separated, then if there is CP data in ARQ retransmission buffer pending to be retransmitted or control plane data in CP transmission buffer, a CP HL PDU may be generated. If not, and if there is UP data in an ARQ retransmission buffer pending to be retransmitted, or UP data in a UP transmission buffer, a UP HL PDU may be generated. If not, a CP PDU or a UP PDU with merely padding may be generated.

[0073] If control PRBs and non-control PRBs are separated, then for control PRB resource grants, and if there is CP data in an ARQ retransmission buffer pending to be retransmitted, or CP data in a CP transmission buffer, a CP HL PDU may be generated. If not, a CP PDU with merely padding may be generated. For non-control PRB resource grants, if there is UP data in an ARQ retransmission buffer pending to be retransmitted, or UP data in a UP transmission buffer, a UP HL PDU may be generated. If not, a UP PDU with merely padding may be generated.

[0074] If there is no MC/URLLC data, and if there is also no non-MC/non-URLLC data, then a CP PDU or a UP PDU with merely padding may be generated.

[0075] In embodiments in which an HL entity (e.g., an HL entity within a tUE) receives multiple resource grants in a TTI to generate multiple HL PDUs, the type of PDU generated after getting a resource grant may be in accordance with the following method. (Note that in various embodiments, a PDU may be generated for each resource grant, and/or each resource grant may be for one or more PRBs.)

[0076] First, let Ντ-otai, grant be a number of resource grants received (e.g., by a tUE) to generate a number Ντ-otai, grant of HL PDUs in the same TTI. [0077] If there is any MC/URLLC data (e.g., UP or CP) in an ARQ Retransmission buffer or any MC/URLLC data (e.g., UP or CP) in a transmission buffer, then estimate how many resource grants may be occupied by available MC/URLLC data. If MC/URLLC data is sufficient to occupy a number NMC of resource grants (where NMC <= Ντ-otai, grant), then NMC MC HL PDUs may be generated. In some embodiments, generation of the NMC PDUS may be performed in parallel. Next, a number NRemainingi of remaining resource grants may be calculated (where NRemainingi = Ντ-otai, grant - NMC).

[0078] If there is not any MC/URLLC data (e.g., UP or CP) in an ARQ

Retransmission buffer or any MC/URLLC data (e.g., UP or CP) in a transmission buffer, then

Set NRemainingi ⁼ NTotal, grant.

[0079] Then, if NRemainingi is greater than zero, and if there is non-MC/non-URLLC data, a Number NRemainin_g2 of remaining resource grants may be set (where NRemainin_g2 = NRemainingi). If control PRBs and non-control PRBs are not separated, then determine whether there is CP data in an ARQ retransmission buffer pending to be retransmitted, or CP data in a CP transmission buffer. If so, and if available CP data is sufficient to occupy an estimated number of resource grants NCP (where NCP <= NRemainin_g2), a number NCP of CP HL PDUs may be generated. (Generation of these NCP CP HL PDUs may be performed in parallel.) The remaining resource grants NRemainin_g2 may then be updated (where NRemainin_g2 = NRemainin_g2 - NCP).

[0080] Then determine whether both NRemainin_g2 is greater than 0 and there is either UP data in an ARQ retransmission buffer pending to be retransmitted, or UP data in a UP transmission buffer. If so, and if available UP data is sufficeint to occupy an estimated number of resource grants NTJP (where NTJP <= NRemainin_g2), a number NTJP of UP may be generated. (Generation of these these NTJP UP HL PDUs may be performed in parallel.) The remaining resource grants NRemainin_g2 may then be updated (where NRemainin_g2 = NRemainin_g2 -

[0081] Then detemine whether NRemainin_g2 is greater than zero. If so, generate

NRemaining2 CP HL PDUs and/or UP HL PDUs with merely padding.

[0082] If control PRBs and non-control PRBs are separated, then for a control PRB resource grant, if available CP data is sufficient to occupy an estimated number of resource grants NCP (where NCP <= NRemainin_g2), a number NCP of CP HL PDUs may be generated. (Generation of these NCP CP HL PDUs may be performed in parallel.) The remaining resource grants NRemainin_g2 may then be updated (where NRemainin_g2 = NRemainin_g2 - NCP). Then detemine whether NRemainin_g2 is greater than zero. If so, generate NRemainin_g2 CP HL PDUs with merely padding.

[0083] Then for a non-control PRB resource grant, and if available UP data is sufficient to occupy an estimated number of resource grants NUP (where NUP <= NRemainin_g2), a number NUP of UP HL PDUs may be generated. (Generation of these NUP UP HL PDUs can be performed in parallel.) The remaining resource grants NRemaining2 may the be updated (where NRemainin_g2 = NRemaining2 - NUP). Then determine whether NRemainin_g2 is greater than 0. If so, generate NRemaining2 CP HL PDUs with merely padding.

[0084] Otherwise (e.g., if there is no non-MC/non-URLLC data), a number NRemainingi of CP PDUs and/or UP PDUs may be generated with merely padding.

[0085] Various embodiments may incorporate major processing steps and header additions. In some embodiments, these processing steps may be substantially similar for MC

PDU generation, CP PDU generation, and/or UP PDU generation. Some processing may occur before getting resource grants, while other processing may occur after getting resource grants.

[0086] Figs. 4A-4B illustrate a flow for generating a final HL PDU packet, in accordance with some embodiments of the disclosure. A flow 400 may pertain to one or more pre-grant HL PDUs 410, and may result in the generating of a final HL PDU 420 on the basis of the one or more pre-grant HL PDUs 410.

[0087] In flow 400, with respect to pre-processing and/or pre-calculation before getting resource grants, when an HL receives a packet from a higher layer (e.g., an

IP/ Application layer, or an RRC), the packet may become an HL SDU for an HL. A unique HL SN may be added to each packet (e.g., to each HL SDU). Pools of HL SNs may be separate for MC data, CP data, and UP data.

[0088] In various embodiments, header compression, encryption (e.g., ciphering and/or deciphering), and/or integrity protection may optionally be enabled, such as by RRC. If one or more HL SDUs are UP IP packets and header compression is enabled by RRC, HL may perform header compression. Otherwise, the HL SDUs may skip header compression. Header compression may advantageously reduce a size of the HL SDUs.

[0089] If integrity protection is enabled (such as by RRC) HL may perform integrity protection operation merely on one or more HL SDUs (e.g., CP HL SDUs). Otherwise, the HL SDUs may skip integrity protection operations. Integrity protection operations may increase the size of the HL SDUs by adding some integrity check bytes. [0090] If encryption is enabled, such as by RRC, one or more HL SDUs may go through ciphering operations, which may advantageously add security to an air-interface transmission. In various embodiments, ciphering may not change the size of the HL SDUs.

[0091] Header compression, encryption (ciphering/deciphering), and integrity protection operations MC/URLLC data may be performed based on whether the data is high priority UP or CP data.

[0092] In various embodiments, the one or more HL SDUs (which may have been modified if header compression, integrity protection, and/or encryption operations were performed) may be processed and added with various header fields at the beginning to form one or more respectively corresponding pre-grant HL PDUs (e.g., HL PDUs 410). The various header fields may comprise an HL SN, a Length Indicator (LI), a

Resegmented/Segmented (RSeg) field, and/or a Last SDU or SDU segment data field flag (L- SDU-F). The HL SN may be added as a header field. LI, which may indicate a size of an HL SDU, e.g. in bytes) may be added as another header field.

[0093] RSeg may be added as another header field. Before getting a grant, it may not be known whether an SDU (or a corresponding pre-grant PDU) will be segmented or not. So, RSeg may be set to a first value (e.g., a value of "0") to indicate that the SDU (or pre-grant PDU) is not segmented. L-SDU-F flag that may indicate whether an SDU or SDU segment is the last SDU or SDU segment (or pre-grant PDU or pre-grant PDU segment). L-SDU-F may be included as a data field in a final HL PDU for a given resource grant. Before getting the grant, L-SDU-F might not be known, so, L-SDU-F may be set to a first value (e.g., a value of "0") to indicate that the SDU is not the last SDU or SDU segment data field.

[0094] A pre-grant PDU may then be stored in a transmission buffer (e.g., a UL transmission buffer). Buffering of the pre-grant PDU in the transmission buffer may trigger sending a scheduling request to an HL entity (e.g., of an nUE or a tUE) in order to request a UL grant.

[0095] In flow 400, with respect to processing or calculations after getting resource grants, once one or more UL grants are received at a PHY, the PHY may pass the UL grants to the HL asking to provide the HL PDUs for transmission. The final HL PDU may then be selected to be generated one the basis of each grant. The size of the final HL PDU may be made equal to a TB size (e.g., a size of UL grant). Final HL PDU may implement various operations.

[0096] In one operation, based on the grant size, one or more pre-grant HL PDUs and/or one or more pre-grant HL PDU segments (e.g., 0, 1, or 2 HL PDU segments) may be included as SDU or SDU segment data fields in the final HL PDU. If pre-grant HL PDU segments are included, they may be the first and/or the last SDU/SDU segment data fields.

[0097] In another operation, all pre-grant HL PDUs (except a last pre-grant HL PDU, or pre-grant HL PDU segment) may be passed to the PHY immediately via a HARQ entity, so that the PHY can start processing. Accordingly, the HL and the PHY may advantageously share a time budget by overlapping their processing times.

[0098] In another operation, the HL may adjust the header fields of the last pre-grant

HL PDU or pre-grant HL PDU segment, and may pass it to the PHY via a HARQ entity.

[0099] In another operation, the HL may then calculate HL CEs (and/or header and data fields for these CEs) and other remaining PDU header fields. The HL may pass this last portion of the HL PDU to the PHY via a HARQ entity. Note that although HL CEs and/or remaining header fields may be added at the end of the final HL PDU at the end of packet processing, the required estimated resource grant size for these fields may be reserved at the beginning, before including any pre-grant HL PDUs or pre-grant HL PDU segments in the final HL PDU.

[00100] The PHY may transmit the HL PDU multiple times unless it is either received successfully at an HL entity (e.g., of an nUE or a tUE), or a maximum HARQ retransmission limit is reached. In some embodiments, a HARQ retransmission may be performed on a per HL PDU basis (e.g., over one or more PRBs). In some embodiments, a HARQ

retransmission may be performed on a per PRB basis (e.g., via one or more HARQ retransmission processes per HL PDU, based on whether an HL PDU corresponds to one or more PRBs). In some embodiments, HARQ processes may be maintained on a per PRB basis, and each part of a PDU (e.g., each part of a PDU on a PRB) may be retransmitted separately multiple times (unless it is either received successfully at the HL entity) or a maximum HARQ retransmission limit is reached. In some embodiments, failure of any part of the PDU transmission during HARQ retransmission may cause a HARQ failure (e.g.., a HARQ Not Acknowledged (NACK)) for the HL PDU.

[00101] When an HL entity (e.g., of an nUE or a tUE) is unable to successfully receive an HL PDU after a maximum number of HARQ retransmission trials, an HL receiving entity may invoke an ARQ retransmission request by sending an ARQ NACK for the missing pre- grant HL PDUs. The ARQ may be performed by HL at a pre-grant PDU level as follows.

[00102] In one operation, an HL transmitting entity may retransmit one or more pre- grant HL PDUs for which it gets ARQ NACK from an HL receiving entity. [00103] In another operation, during ARQ retransmission, an original pre-grant HL

PDU may be disposed to being re-segmented (e.g., if a grant size is smaller).

[00104] In another operation, for each ARQ retransmission, the PHY may try maximum number of H ARQ retransmission times to deliver the PDU. An individual ARQ retransmission trial may fail if the PHY cannot deliver it to an HL receiving entity in a maximum number of HARQ retransmission times.

[00105] In another operation, after a maximum number of ARQ retransmission tries, if a pre-grant HL PDU fails to be successfully received at an HL receiving side, the HL may discard the associated SDU, and may inform a higher layer (e.g., an HL) of the failure.

[00106] Accordingly, packet headers may be added by the HL while creating one or more HL PDUs. As discussed herein, one type of HL PDU (e.g., an MC HL PDU, a CP HL PDU, or a UP HL PDU) may be generated for each grant.

[00107] One or more HL SDUs received by an HL may be byte-aligned in size. The maximum size of an HL SDU may determine a number of bits to be used to represent a length of an HL SDU. For example, if the maximum supported size of an HL SDU is 8188 bytes (as in a legacy LTE system), a length field of 13 bits may suffice to represent the length of an HL SDU. Furthermore, a size (e.g., a length field) of a pre-grant HL PDU may also be byte-aligned in size.

[00108] HL PDUs may be generated for various different cases. HL PDUs may be categorized into SL-HL data PDUs and HL internal control PDUs. HL data PDUs may be used by HL entities to transfer upper layer UP data and/or CP data (e.g., HL SDUs). Some UP data (and/or CP data) may be of higher priority, such as MC/URLLC data. HL internal control PDUs may be used by an HL entity to perform HL procedures, such as an ARQ procedure.

[00109] HL data PDUs are discussed primarily herein. The figures and tables herein may represent bit strings and/or portions of bit strings. In the figures, the most significant bit of the PDU may be the left-most bit and the least significant bit of the PDU may be the rightmost bit. In the tables, the most significant bits may correspond with the upper rows of the table, and the least significant bits of the PDU may correspond with the lower rows of the table. In general, the bit strings depicted may be read from left to right (and then, for bit strings comprising multiple rows, from upper rows to lower rows).

[00110] Fig. 5 illustrates a pre-grant HL PDU structure, in accordance with some embodiments of the disclosure. A pre-grant HL PDU 500 may comprise an HL PDU header 510 and an HL PDU data field 520. [00111] Pre-grant HL PDU 500 may be a bit string. Pre-grant HL PDU header 510 may comprise the most significant bits of pre-grant HL PDU 500, while pre-grant HL PDU data field 520 may comprise the least significant bits of pre-grant HL PDU 500. The most significant bits of pre-grant HL PDU header 510 may be oriented toward the most significant bits of pre-grant HL PDU 500. The most significant bits of pre-grant HL PDU data field 520 may also be oriented toward the most significant bits of pre-grant HL PDU 500.

[00112] HL PDU data field 520 may comprise an HL SDU, which may be byte-aligned in length (e.g., may include an integer multiple of 8 bits). The HL SDU may be included into pre-grant HL PDU from its first bit onward (e.g., a most significant bit of the HL SDU may be oriented toward the most significant bit of pre-grant HL PDU 500).

[00113] Figs. 6-8 illustrate final HL PDU structures, in accordance with some embodiments of the disclosure. A final HL PDU may comprise two parts: a first part comprising one or more pre-grant HL PDUs and/or one or more pre-grant HL PDU segments, and a second part comprising HL CEs and header fields for the final HL PDU. The first part and the second part may be separately byte-aligned. When padding is used to fill a grant, it may be added to the second part (e.g., a last data field of the second part). Accordingly, as discussed herein, such padding may be positioned between the first part and the second part.

[00114] With reference to Fig. 6, a final HL PDU 600 may have a bit string structure comprising a first part 610 and a second part 620. A first and most significant bit of first part 610 may be oriented toward a first and most significant bit of final HL PDU 600, and a last and least significant bit of first part 610 may be oriented toward a last and least significant bit of final HL PDU 600. In contrast, a first and most significant bit of second part 620 may be oriented toward a last and least significant bit of final HL PDU 600, and a last and least significant bit of second part 620 may be oriented toward a first and most significant bit of final HL PDU 600.

[00115] The orientation of the most significant bits and the least significant bits of second part 620 may accordingly be reversed in comparison with the orientation of the most significant bits and the least significant bits of first part 610. Thus, while a most significant bit of HL PDU 600 and a most significant bit of first part 610 may be first bits (e.g., left-most bits), a most significant bit of second part 620 may be a last bit (e.g., right-most bit).

[00116] With reference to Fig. 7, in some embodiments, a final HL PDU 700 may have a bit string structure comprising a first part 710 and a second part 720. Final HL PDU 700 may be substantially similar to final HL PDU 600, first part 710 may be substantially similar to first part 610, and second part 720 may be substantially similar to second part 620. [00117] A first and most significant byte of first part 710 may be oriented toward a first and most significant byte of final HL PDU 700, and a last and least significant byte of first part 710 may be oriented toward a last and least significant byte of final HL PDU 700. In contrast, a first and most significant byte of second part 720 may be oriented toward a last and least significant byte of final HL PDU 700, and a last and least significant byte of second part 720 may be oriented toward a first and most significant byte of final HL PDU 700.

[00118] Moreover, in accordance with a first byte structure 715, various bytes of a bit string of first part 710 may be read from left (at a most significant bit) to right (at a least significant bit). In accordance with a second byte structure 725, various bytes of a bit string of second part 720 may be read from right (at a most significant bit) to left (at a least significant bit).

[00119] With reference to Fig. 8, in some embodiments, a final HL PDU 800 may have a bit string structure comprising a first part 810 and a second part 820. First part 810 may be substantially similar to first part 710, and second part 820 may be substantially similar to second part 720.

[00120] A first and most significant byte of first part 810 may be oriented toward a first and most significant byte of final HL PDU 800, and a last and least significant byte of first part 810 may be oriented toward a last and least significant byte of final HL PDU 800. In contrast, a first and most significant byte of second part 820 may be oriented toward a last and least significant byte of final HL PDU 800, and a last and least significant byte of second part 820 may be oriented toward a first and most significant byte of final HL PDU 800.

[00121] However, an orientation of the most significant bits and least significant bits within each byte of second part 820 may be reversed in comparison with an orientation of the most significant bits and least significant bits within each byte of second part 720. In accordance with a first byte structure 815, various bytes of a bit string of first part 810 may be read from left (at a most significant bit) to right (at a least significant bit). In accordance with a second byte structure 825, various bytes of a bit string of second part 720 may also be read from left (at a most significant bit) to right (at a least significant bit). Accordingly, while the bytes of second part 820 are oriented in a manner similar to the bytes of second part 720, the bits of each byte of second part 820 may be oriented in manner that is reversed in comparison with an orientation of the bits of each byte of second part 720.

[00122] With reference to Fig. 4 (and various other Figures herein), Table 1 below provides descriptions of various parameters included in and/or carried by headers for pre- grant HL PDUs and headers for final HL PDUs. TABLE 1 : Description of various parameters related to headers of pre-grant HL PDUs and final HL PDUs

May indicate whether a next field is BSR, PHR, or Padding

Buffer Status Report (BSR)

00

This Field Type may have one corresponding BSR data field in the PDU.

Field-

Power Headroom Report (PHR)

Type

(2 bits) 01

This Field Type may have one corresponding PHR data field in the PDU.

10 No field in the second part

Padding of zero or more bytes at the end of the second part (e.g., in

11

between the first part and the second part) of the final HL PDU.

BSR-Type Various types of BSR CEs in the corresponding BSR data field of (2 or 4 the PDU. Each BSR type may have a known-length BSR data field, bits) so a length indicator might not be used.

Various types of PHR control elements in the corresponding PHR

PHR-Type

data field of the PDU. Each PHR type may have a known-length (2 bits)

PHR data field, so a length indicator might not be used.

Length Indicator for Header Size for the second part of the final HL

LI-2 PDU

(2, 3, 5

bits) My specify a length in bytes. LI may be of 2 or 3 or 5 bits, which may be configured by a higher layer (e.g., an RRC).

variable Padding

Pad number

of Os May be used to make a PDU header/subheader byte-aligned

[00123] A final HL PDU may comprise two parts (e.g., a first part and a second part as described herein). The first part may comprise one or more pre-grant HL PDUs and/or one or more pre-grant HL PDU segments (e.g., 0, 1, or 2 segments). The second part may comprise various fields as discussed herein (e.g., fields related to CEs) that may serves as header fields for a final HL PDU, such as various fields discussed in Table 1.

[00124] After getting one or more resource grants, an HL may estimate a size of a second part and may separate resource for the second part. The HL may then form the first part based on the remaining grant. In some embodiments, the HL may complete the second part before finalizing the last SDU or SDU-segment field in the first part (e.g., pertaining to the last pre-grant HL PDU, or pre-grant HL PDU segment), so that there may not be a resource gap. For example, if more resources have been separated at the beginning for the second part, then that resource may be filled with a last SDU/SDU-segment field (e.g., pertaining to a last pre-grant HL PDU or pre-grant HL PDU segment).

[00125] Fig. 9 illustrates a header for a final Acknowledged Mode (AM) HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Fig. 10 illustrates a header for a final AM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Fig. 11 illustrates a header for a final Unacknowledged Mode (UM) HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Fig. 12 illustrates a header for a final UM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure.

[00126] With reference to Figs. 9-12, various bits within various bytes of a second part of a final HL PDU may be structured to contain various fields described herein (e.g., in Table 1). As depicted, the most significant bytes of second parts may be on top rows, the least significant bytes may be on bottom rows, the most significant bit of each byte may be on the right-hand side, and the least significant bit of each byte may be on the left-hand side.

[00127] Various embodiments may support AM operation and UM operation. ARQ retransmission may be performed merely for AM mode. In cases of AM mode, a second part (e.g. a final HL PDU header) may have a Polling bit to request a receiving entity to send an ARQ ACK/NACK status. UM mode may be advantageous for some specific types of data, such as voice data. UM may also be advantageous for MC data, since MC data may be less able to tolerate ARQ retransmission delay.

[00128] In some embodiments, an AM/UM indication bit (and a Polling bit) may be added per pre-grant HL PDU in the first, rather than in the second. Doing so may advantageously facilitate inclusion of AM and UM traffic in the same final HL PDU.

[00129] In various embodiments, a second part of an HL PDU may comprise a data field (e.g., CE data fields and/or padding) and a header. The header of the second part of an AM HL PDU may comprise a fixed length common part (which may comprise fields that may be present once at the beginning for every AM HL PDU) and a variable length data- field-specific part (which may comprise a set of header/sub-header field(s) that may be present, one set for each of data-field element included in the second part).

[00130] The common part of a header of a second part of a final AM HL PDU may comprise one or more of the following fields: an R field, an LI-2 field, a PDU-Type field, an SDU-Field-F field, an AM/UM field, and a P field. The data-field-specific part of the second part of the final AM HL PDU, which may be of variable length, may comprise one or more of: an El field, a Field-Type field, and/or a 0 or 1 sub-field (which may depend on a Field- Type field). [00131] The Field-Type based 0 or 1 field or sub-field may be as follows. If Field-

Type indicates BSR, an associated data field element may comprise a BSR CE. A field called BSR-Type may be included in the header. BSR-Type may indicate a length of a BSR CE. If Field-Type indicates PHR, an associated data field element may comprise a PHR CE. A field called PHR-Type may be included in the header. PHR-Type may indicate a length of a PHR CE. If Field-Type indicates Padding, there may not be a subfield.

[00132] A header portion of a second part of a final AM HL PDU may be made byte- aligned by adding zero or more padding bits. The data fields of the second part may start at a new byte. Associated data fields for various Field-Types may be in the same order as they occur in the header of the second part.

[00133] With reference to Fig. 9, a header 900 may carry: an AM/UM field having a first value (e.g., a value of "0") indicating AM; a Polling bit; a second Extension field E having a first value (e.g., a value of "0") indicating no more Field-Type fields after the next Field-Type field; and/or three Pad bits at the end.

[00134] With reference to Fig. 10, a header 1000 may cany: an AM/UM field with the first value indicating AM; a Polling bit; a second Extension bit E having a second value (e.g., a value of "1") indicating at least one more Field-Type fields after the next Field-Type field; a third Extension bit E having the first value indicating no more Field-Type fields after the next Field-Type field; and/or a third Field-Type field having a value indicating Padding (e.g., a value of "11").

[00135] With reference to Fig. 11, a header 1100 may carry: an AM/UM field with a second value (e.g., a value of "1") indicating UM; a second Extension field E having the first value indicating no more Field-Type fields after the next Field-Type field; and/or four Pad bits. Header 1100 might not carry a Polling bit.

[00136] With reference to Fig. 12, a header 1200 may cany: an AM/UM field with the second value indicating UM; a second Extension bit E having the second value indicating at least one more Field-Type fields after the next Field-Type field; a third Extension bit E having the first value indicating no more Field-Type fields after the next Field-Type field; a third Field-Type field having the value indicating Padding; and/or a Pad bit. Header 1200 might not carry a Polling bit.

[00137] In various embodiments, a final HL PDU may be adjusted in order to match its size with an allocated grant size. When a PHY or Layer 1 (LI) indicates provision of a final HL PDU of a specific size, the HL may ensure that the final HL PDU is provided to the same size as indicated (e.g., by LI). A grant size allocation for an HL PDU may be byte-aligned. Padding may be used to match a size of an HL PDU to a grant size.

[00138] A last SDU or SDU segment field of a first part of a final HL PDU may be a segment of a pre-grant PDU. However, a segment of a pre-grant PDU may merely be included in the first part if the segment of a pre-grant HL PDU contains at least 1 byte of associated SDU data in the remaining grant. As a result, there may be cases in which merely a few bytes (e.g., 1, 2, 3 or 4 bytes) of grant may be left over after including the first part of the final HL PDU and the second part of the final HL PDU while preparing the HL data PDU. In this left-over grant, no segment of pre-grant HL PDU may be included. In other cases, there may not be sufficient data to fill the grant, padding (e.g., 1 or more bytes) may be used to fill the grant. In such cases, padding may be added as follows.

[00139] In cases in which merely one byte of UL grant is left over, one padding header may be added in a header of a second part of a final HL PDU using a PDU Type having a value indicating "Padding" of 1 byte at the beginning of the header of the second part of the final HL PDU. Note that this padding header may be separately made byte-aligned by adding padding bits at the end of the header. A receiving side (e.g., of an HL receiving entity) may simply ignore padding headers during decoding when an HL receiving entity finds a padding header with a PDU Type having a value indicating "Padding" at the beginning of the header of the second part of the final HL PDU.

[00140] In cases in which two or more bytes of grant are left over, there may be sufficient grant to add a padding header using a Field Type of "Padding" at the end of a header of the second part of a final HL PDU. The padding header using a Field Type of "Padding" at the end of the header of the second part of the final HL PDU may indicate that a remaining grant may be filled with padding at the end of the second part (e.g., a Padding field may be added after CE data fields). The Padding field may be zero or more bytes. An HL Receiving side (e.g., an HL Receiving entity) may simply ignore the padding part while decoding.

[00141] In cases in which there is no data to transmit (or retransmit), or no data bytes, and related headers may be accommodated in the allocated grant, one of the following options may be employed.

[00142] The grant may be ignored, if possible. Alternatively, if a design is disposed to create a final HL PDU, then a final HL PDU with merely a second part is created.

[00143] If the grant is of one byte, the second part may comprise one padding header in a header of the second part of a final HL PDU using a PDU Type of "Padding" of 1 Byte at the beginning of the second part. (Notably, the first part of the final HL PDU may be included in the final HL PDU merely if at least one byte of a corresponding SDU may be included along with a pre-grant header (which may be at least 2 bytes). Therefore, if a final HL PDU size is less than four bytes, the first part of the final HL PDU may implicitly be known to be absent.

[00144] If the grant is not one byte, a fixed length common part (e.g., an R field, a

PDU-Type field, an SDU-Field-F field, an AM/UM field, and/or a P field) and a padding header using a Field Type indicating "Padding" followed by zero or more padding bits may be added to create an exclusive padding PDU.

[00145] In various embodiments, a first byte of a second part of a final HL PDU may be calculated before getting a grant and may be sent to a PHY as a first byte of the first part of a final HL PDU. Figs. 13A-13B illustrate a flow for generating a final HL PDU packet, in accordance with some embodiments of the disclosure. A flow 1300 may pertain to one or more pre-grant HL PDUs 1310 and a one-byte pre-grant header 1312 (which may be a header of the final HL PDU), and may result in the generating of a final HL PDU 1320 on the basis of the pre-grant header 1312 and the pre-grant HL PDUs 1310. Pre-grant header 1312 may comprise one or more fields that may otherwise be included in a second part of a final HL PDU (e.g., in a second part of final HL PDU 420

[00146] In flow 1300, with respect to pre-processing and/or pre-calculation before getting resource grants, when an HL receives a packet from a higher layer (e.g., an

IP/ Application layer, or an RRC), the packet may become an HL SDU for an HL. A unique HL SN may be added to each packet (e.g., to each HL SDU). Pools of HL SNs may be separate for MC data, CP data, and UP data. A pre-grant header may be calculated before getting a grant, and may provide various information to an HL receiving side, which may then advantageously start decoding each HL SDU (e.g., from associated pre-grant HL PDUs) without waiting to receive the entire final HL PDU. As a result, a receiving side may advantageously decode a partial final HL PDU.

[00147] Pre-grant HL PDUs 1310 may be substantially similar to pre-grant HL PDUs

410. Final HL PDU 1320 may be substantially similar to final HL PDU 420, but pre-grant header 1312 may occupy the most significant bits of final HL PDU 1320.

[00148] After receiving a pre-grant header, an HL receiving side may determine whether there are one or more pre-grant HL PDUs in a final HL PDU based on an SDU- Field-F flag. If SDU-Field-F has a first value (e.g., a value of "1"), there may be at least one pre-grant PDU or a segment of a pre-grant PDU. [00149] The receiving side may then decode a pre-grant HL PDU (or segment of one) if there is any. The last pre-grant PDU or pre-grant PDU segment is known to Receiver side looking at the header (more specifically 'L-SDU-F' flag of the header) of the pre-grant PDU or pre-grant PDU segment.

[00150] Subsequently, after a last pre-grant HL PDU or pre-grant HL PDU segment field of the first part of the final HL PDU is created, the second part of the final HL PDU may be present.

[00151] Fig. 14 illustrates a header for a final AM HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Fig. 15 illustrates a header for a final AM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Fig. 16 illustrates a header for a final UM HL PDU without a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Fig. 17 illustrates a header for a final UM HL PDU with a Field-Type field having a value indicating "Padding," in accordance with some embodiments of the disclosure. Figs. 14-17 depict modified headers of the second part of final HL PDUs, after moving a first byte of the second part of a final HL PDU to the first part of a final HL PDU as a pre-grant header.

[00152] With reference to Fig. 14, a header 1400 may carry: a Polling bit; a second Extension field E having a first value (e.g., a value of "0") indicating no more Field-Type fields after the next Field-Type field; and/or three Pad bits at the end.

[00153] With reference to Fig. 15, a header 1500 may carry: a Polling bit; a second Extension bit E having a second value (e.g., a value of "1") indicating at least one more Field-Type fields after the next Field-Type field; a third Extension bit E having the first value indicating no more Field-Type fields after the next Field-Type field; and/or a third Field- Type field having a value indicating Padding (e.g., a value of "11").

[00154] With reference to Fig. 16, a header 1600 may carry: a second Extension field E having the first value indicating no more Field-Type fields after the next Field-Type field; and/or four Pad bits. Header 1600 might not carry a Polling bit.

[00155] With reference to Fig. 17, a header 1700 may carry: a second Extension bit E having the second value indicating at least one more Field-Type fields after the next Field- Type field; a third Extension bit E having the first value indicating no more Field-Type fields after the next Field-Type field; a third Field-Type field having the value indicating Padding; and/or a Pad bit. Header 1700 might not carry a Polling bit. [00156] Fig. 18 illustrates an eNB and a UE, in accordance with some embodiments of the disclosure. Fig. 18 includes block diagrams of an eNB 1810 and a UE 1830 which are operable to co-exist with each other and other elements of an LTE network. High-level, simplified architectures of eNB 1810 and UE 1830 are described so as not to obscure the embodiments. It should be noted that in some embodiments, eNB 1810 may be a stationary non-mobile device.

[00157] eNB 1810 is coupled to one or more antennas 1805, and UE 1830 is similarly coupled to one or more antennas 1825. However, in some embodiments, eNB 1810 may incorporate or comprise antennas 1805, and UE 1830 in various embodiments may incorporate or comprise antennas 1825.

[00158] In some embodiments, antennas 1805 and/or antennas 1825 may comprise one or more directional or omni-directional antennas, including monopole antennas, dipole antennas, loop antennas, patch antennas, microstrip antennas, coplanar wave antennas, or other types of antennas suitable for transmission of RF signals. In some MIMO (multiple- input and multiple output) embodiments, antennas 1805 are separated to take advantage of spatial diversity.

[00159] eNB 1810 and UE 1830 are operable to communicate with each other on a network, such as a wireless network. eNB 1810 and UE 1830 may be in communication with each other over a wireless communication channel 1850, which has both a downlink path from eNB 1810 to UE 1830 and an uplink path from UE 1830 to eNB 1810.

[00160] As illustrated in Fig. 18, in some embodiments, eNB 1810 may include a physical layer circuitry 1812, a MAC (media access control) circuitry 1814, a processor 1816, a memory 1818, and a hardware processing circuitry 1820. A person skilled in the art will appreciate that other components not shown may be used in addition to the components shown to form a complete eNB.

[00161] In some embodiments, physical layer circuitry 1812 includes a transceiver

1813 for providing signals to and from UE 1830. Transceiver 1813 provides signals to and from UEs or other devices using one or more antennas 1805. In some embodiments, MAC circuitry 1814 controls access to the wireless medium. Memory 1818 may be, or may include, a storage media/medium such as a magnetic storage media (e.g., magnetic tapes or magnetic disks), an optical storage media (e.g., optical discs), an electronic storage media (e.g., conventional hard disk drives, solid-state disk drives, or flash-memory-based storage media), or any tangible storage media or non-transitory storage media. Hardware processing circuitry 1820 may comprise logic devices or circuitry to perform various operations. In some embodiments, processor 1816 and memory 1818 are arranged to perform the operations of hardware processing circuitry 1820, such as operations described herein with reference to logic devices and circuitry within eNB 1810 and/or hardware processing circuitry 1820.

[00162] Accordingly, in some embodiments, eNB 1810 may be a device comprising an application processor, a memory, one or more antenna ports, and an interface for allowing the application processor to communicate with another device.

[00163] As is also illustrated in Fig. 18, in some embodiments, UE 1830 may include a physical layer circuitry 1832, a MAC circuitry 1834, a processor 1836, a memory 1838, a hardware processing circuitry 1840, a wireless interface 1842, and a display 1844. A person skilled in the art would appreciate that other components not shown may be used in addition to the components shown to form a complete UE.

[00164] In some embodiments, physical layer circuitry 1832 includes a transceiver

1833 for providing signals to and from eNB 1810 (as well as other eNBs). Transceiver 1833 provides signals to and from eNBs or other devices using one or more antennas 1825. In some embodiments, MAC circuitry 1834 controls access to the wireless medium. Memory 1838 may be, or may include, a storage media/medium such as a magnetic storage media (e.g., magnetic tapes or magnetic disks), an optical storage media (e.g., optical discs), an electronic storage media (e.g., conventional hard disk drives, solid-state disk drives, or flash- memory-based storage media), or any tangible storage media or non-transitory storage media. Wireless interface 1842 may be arranged to allow the processor to communicate with another device. Display 1844 may provide a visual and/or tactile display for a user to interact with UE 1830, such as a touch-screen display. Hardware processing circuitry 1840 may comprise logic devices or circuitry to perform various operations. In some embodiments, processor 1836 and memory 1838 may be arranged to perform the operations of hardware processing circuitry 1840, such as operations described herein with reference to logic devices and circuitry within UE 1830 and/or hardware processing circuitry 1840.

[00165] Accordingly, in some embodiments, UE 1830 may be a device comprising an application processor, a memory, one or more antennas, a wireless interface for allowing the application processor to communicate with another device, and a touch-screen display.

[00166] Elements of Fig. 18, and elements of other figures having the same names or reference numbers, can operate or function in the manner described herein with respect to any such figures (although the operation and function of such elements is not limited to such descriptions). For example, Figs. 19 and 22-23 also depict embodiments of eNBs, hardware processing circuitry of eNBs, UEs, and/or hardware processing circuitry of UEs, and the embodiments described with respect to Fig. 18 and Figs. 19 and 22-23 can operate or function in the manner described herein with respect to any of the figures.

[00167] In addition, although eNB 1810 and UE 1830 are each described as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements and/or other hardware elements. In some embodiments of this disclosure, the functional elements can refer to one or more processes operating on one or more processing elements. Examples of software and/or hardware configured elements include Digital Signal Processors (DSPs), one or more microprocessors, DSPs, Field-Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Radio-Frequency Integrated Circuits (RFICs), and so on.

[00168] Fig. 19 illustrates hardware processing circuitries for a UE for reducing PDU processing time after getting a resource grant, in accordance with some embodiments of the disclosure. With reference to Fig. 18, a UE may include various hardware processing circuitries discussed herein (such as hardware processing circuitry 1900 of Fig. 19), which may in rum comprise logic devices and/or circuitry operable to perform various operations. For example, in Fig. 18, UE 1830 (or various elements or components therein, such as hardware processing circuitry 1840, or combinations of elements or components therein) may include part of, or all of, these hardware processing circuitries.

[00169] In some embodiments, one or more devices or circuitries within these hardware processing circuitries may be implemented by combinations of software-configured elements and/or other hardware elements. For example, processor 1836 (and/or one or more other processors which UE 1830 may comprise), memory 1838, and/or other elements or components of UE 1830 (which may include hardware processing circuitry 1840) may be arranged to perform the operations of these hardware processing circuitries, such as operations described herein with reference to devices and circuitry within these hardware processing circuitries. In some embodiments, processor 1836 (and/or one or more other processors which UE 1830 may comprise) may be a baseband processor.

[00170] Returning to Fig. 19, an apparatus of UE 1830 (or another UE or mobile handset), which may be operable to communicate with one or more eNBs on a wireless network, may comprise hardware processing circuitry 1900. In some embodiments, hardware processing circuitry 1900 may comprise one or more antenna ports 1905 operable to provide various transmissions over a wireless communication channel (such as wireless

communication channel 1850). Antenna ports 1905 may be coupled to one or more antennas 1907 (which may be antennas 1825). In some embodiments, hardware processing circuitry 1900 may incorporate antennas 1907, while in other embodiments, hardware processing circuitry 1900 may merely be coupled to antennas 1907.

[00171] Antenna ports 1905 and antennas 1907 may be operable to provide signals from a UE to a wireless communications channel and/or an eNB, and may be operable to provide signals from an eNB and/or a wireless communications channel to a UE. For example, antenna ports 1905 and antennas 1907 may be operable to provide transmissions from UE 1830 to wireless communication channel 1850 (and from there to eNB 1810, or to another eNB). Similarly, antennas 1907 and antenna ports 1905 may be operable to provide transmissions from a wireless communication channel 1850 (and beyond that, from eNB 1810, or another eNB) to UE 1830.

[00172] Hardware processing circuitry 1900 may comprise various circuitries operable in accordance with the various embodiments discussed herein. With reference to Fig. 19, hardware processing circuitry 1900 may comprise a first circuitry 1910, a second circuitry 1920, and/or a third circuitry 1930.

[00173] In a variety of embodiments, first circuitry 1910 may be operable to establish one or more headers respectively corresponding with one or more SDUs. Second circuitry 1920 may be operable to form one or more respectively corresponding first PDUs to include the one or more headers and the one or more SDUs. First circuitry 1910 may be operable to provide information for the one or more headers corresponding with the one or more SDUs to second circuitry 1920 via an interface 1915. Second circuitry 1920 may also be operable to form a second PDU to include the one or more first PDUs based on one or more resource grants from a PHY. The one or more resource grants may be available from the PHY after the one or more first PDUs are formed. Hardware processing circuitry 1900 may also comprise a memory for storing at least one of: the one or more headers, the first PDUs, or the second PDU.

[00174] For some embodiments, third circuitry 1930 may be operable to assign one or more respectively corresponding SNs to the one or more SDUs. Third circuitry 1930 may be operable to provide information for the one or more SNs to first circuitry 1910 via an interface 1935.

[00175] In some embodiments, the one or more SNs may be assigned from one of: an

MC SN pool, a CP SN pool, or a UP SN pool. For some embodiments, the one or more SNs may be assigned from one of a number N of SN pools, the number N being a number of supported priorities. [00176] For some embodiments, third circuitry 1930 may be operable to assign a type to the second PDU. In some embodiments, the type may be selected from one of: an MC type, a CP type, or a UP type. Third circuitry 1930 may be operable to provide information for the type to first circuitry 1910 via an interface 1935.

[00177] In some embodiments, the one or more headers may include a resegmentation flag, a last SDU or segment flag, a length indicator, and/or or an SN. For some embodiments, the memory may be a transmission buffer, or a retransmission buffer. In some embodiments, the one or more SDUs may be received from an IP layer, an Application layer, or a RRC layer.

[00178] For some embodiments, the RRC layer may be a sidelink RRC layer. In some embodiments, the second PDU may have a first part including the one or more first PDUs and a second part including a header for the second PDU, and the second part may be positioned at the end of the second PDU. For some embodiments, the second part may include one or more CEs. In some embodiments, the one or more CEs may be selected from: a BSR or a power headroom report.

[00179] In a variety of embodiments, second circuitry 1920 may be operable to form one or more first PDUs to include one or more respectively corresponding SDUs. First circuitry 1910 may be operable to establish a header for a second PDU based at least in part upon the one or more first PDUs. First circuitry 1910 may be operable to provide information for the for the second PDU to second circuitry 1920 via an interface 1915.

Second circuitry 1920 may also be operable to form the second PDU to have a first part including the one or more first PDUs and a second part including the header for the second PDU. The second part may be positioned at the end of the second PDU. Hardware processing circuitry 1920 may also comprise an interface for sending the second PDU to a PHY circuitry.

[00180] In some embodiments, an MSB of the first part may be positioned toward the beginning of the second PDU, and an LSB of the first part may be positioned toward the end of the second PDU. For some embodiments, an MSB of the second part may be positioned toward the end of the second PDU, and an LSB of the second part may be positioned toward the beginning of the second PDU.

[00181] For some embodiments, the first part may have at least one segment of a first

PDU. In some embodiments, the header for the second PDU may include one or more CEs. For some embodiments, the one or more CEs may be selected from: a BSR or a power headroom report. [00182] In some embodiments, the header for the second PDU may be a first header for the second PDU, and second circuitry 1920 may be operable to form the second PDU to have a third part including a second header for the second PDU. The third part may be positioned at the beginning of the second PDU.

[00183] For some embodiments, the one or more SDUs may be received from an IP layer, an Application layer, or a RRC layer. In some embodiments, the RRC layer may be a sidelink RRC layer.

[00184] For some embodiments, first circuitry 1910 may be operable to establish one or more headers respectively corresponding with the one or more SDUs. Second circuitry 1920 may be operable to form the one or more first PDUs to include the one or more headers and the one or more SDUs in a respectively corresponding manner.

[00185] In some embodiments, second circuitry 1920 may be operable to form the second PDU to include the one or more first PDUs based on one or more resource grants from a PHY. The one or more resource grants may be available from the PHY after the one or more first PDUs are formed.

[00186] For some embodiments, hardware processing circuitry 1900 may comprise one or more HARQ circuitries coupled to receive the one or more first PDUs in a respectively corresponding manner.

[00187] In some embodiments, first circuitry 1910, second circuitry 1920, and/or third circuitry 1930 may be implemented as separate circuitries. In other embodiments, first circuitry 1910, second circuitry 1920, and/or third circuitry 1930 may be combined and implemented together in a circuitry without altering the essence of the embodiments.

[00188] Fig. 20 illustrates methods for a UE for reducing PDU processing time after getting a resource grant, in accordance with some embodiments of the disclosure. Fig. 21 illustrates methods for a UE for reducing PDU processing time after getting a resource grant, in accordance with some embodiments of the disclosure. With reference to Fig. 18, methods that may relate to UE 1830 and hardware processing circuitry 1840 are discussed herein. Although the actions in method 2000 of Fig. 20 and method 2100 of Fig. 21 are shown in a particular order, the order of the actions can be modified. Thus, the illustrated embodiments can be performed in a different order, and some actions may be performed in parallel. Some of the actions and/or operations listed in Figs. 20 and 21 are optional in accordance with certain embodiments. The numbering of the actions presented is for the sake of clarity and is not intended to prescribe an order of operations in which the various actions must occur. Additionally, operations from the various flows may be utilized in a variety of combinations. [00189] Moreover, in some embodiments, machine readable storage media may have executable instructions that, when executed, cause UE 1830 and/or hardware processing circuitry 1840 to perform an operation comprising the methods of Figs. 20 and 21. Such machine readable storage media may include any of a variety of storage media, like magnetic storage media (e.g., magnetic tapes or magnetic disks), optical storage media (e.g., optical discs), electronic storage media (e.g., conventional hard disk drives, solid-state disk drives, or flash-memory-based storage media), or any other tangible storage media or non-transitory storage media.

[00190] In some embodiments, an apparatus may comprise means for performing various actions and/or operations of the methods of Figs. 20 and 21.

[00191] Returning to Fig. 20, various methods may be in accordance with the various embodiments discussed herein. A method 2000 may comprise an establishing 2010, a forming 2015, and a forming 2020. Method 2000 may also comprise an assigning 2030 and/or an assigning 2040.

[00192] In establishing 2010, one or more headers respectively corresponding with one or more SDUs may be established. In forming 2015, one or more respectively corresponding first PDUs may be formed to include the one or more headers and the one or more SDUs. In forming 2020, a second PDU may be formed to include the one or more first PDUs based on one or more resource grants from a PHY. The one or more resource grants may be available from the PHY after the one or more first PDUs are formed.

[00193] For some embodiments, in assigning 2030, one or more respectively corresponding SNs may be assigned to the one or more SDUs.

[00194] In some embodiments, the one or more SNs may be assigned from one of: an

MC SN pool, a CP SN pool, or a UP SN pool. For some embodiments, the one or more SNs may be assigned from one of a number N of SN pools, the number N being a number of supported priorities.

[00195] For some embodiments, in assigning 2040, a type may be assigned to the second PDU. In some embodiments, the type may be selected from one of: an MC type, a CP type, or a UP type.

[00196] In some embodiments, the one or more headers may include a resegmentation flag, a last SDU or segment flag, a length indicator, and/or or an SN. For some embodiments, the memory may be a transmission buffer, or a retransmission buffer. In some embodiments, the one or more SDUs may be received from an IP layer, an Application layer, or a RRC layer. [00197] For some embodiments, the RRC layer may be a sidelink RRC layer. In some embodiments, the second PDU may have a first part including the one or more first PDUs and a second part including a header for the second PDU, and the second part may be positioned at the end of the second PDU. For some embodiments, the second part may include one or more CEs. In some embodiments, the one or more CEs may be selected from: a BSR or a power headroom report.

[00198] Returning to Fig. 21, various methods may be in accordance with the various embodiments discussed herein. A method 2100 may comprise a forming 2110, an establishing 2115, and a forming 2120. Method 2100 may also comprise a forming 2130, an establishing 2140, a forming 2145, and/or a forming 2150.

[00199] In forming 2110, one or more first PDUs may be formed to include one or more respectively corresponding SDUs. In establishing 2115, a header for a second PDU may be established based at least in part upon the one or more first PDUs. In forming 2120, the second PDU may be formed to have a first part including the one or more first PDUs and a second part including the header for the second PDU. The second part may be positioned at the end of the second PDU; and

[00200] In some embodiments, an MSB of the first part may be positioned toward the beginning of the second PDU, and an LSB of the first part may be positioned toward the end of the second PDU. For some embodiments, an MSB of the second part may be positioned toward the end of the second PDU, and an LSB of the second part may be positioned toward the beginning of the second PDU.

[00201] For some embodiments, the first part may have at least one segment of a first

PDU. In some embodiments, the header for the second PDU may include one or more CEs. For some embodiments, the one or more CEs may be selected from: a BSR or a power headroom report.

[00202] In some embodiments, the header for the second PDU may be a first header for the second PDU, and in forming 2130, the second PDU may be formed to have a third part including a second header for the second PDU. The third part may be positioned at the beginning of the second PDU.

[00203] For some embodiments, the one or more SDUs may be received from an IP layer, an Application layer, or a RRC layer. In some embodiments, the RRC layer may be a sidelink RRC layer.

[00204] In some embodiments, in establishing 2140, one or more headers respectively corresponding with the one or more SDUs may be established. In forming 2145, the one or more first PDUs may be formed to include the one or more headers and the one or more SDUs in a respectively corresponding manner.

[00205] In some embodiments, in forming 2150, the second PDU may be formed to include the one or more first PDUs based on one or more resource grants from a PHY. The one or more resource grants may be available from the PHY after the one or more first PDUs are formed.

[00206] Fig. 22 illustrates example components of a device, in accordance with some embodiments of the disclosure. In some embodiments, the device 2200 may include application circuitry 2202, baseband circuitry 2204, Radio Frequency (RF) circuitry 2206, front-end module (FEM) circuitry 2208, one or more antennas 2210, and power management circuitry (PMC) 2212 coupled together at least as shown. The components of the illustrated device 2200 may be included in a UE or a RAN node. In some embodiments, the device 2200 may include less elements (e.g., a RAN node may not utilize application circuitry 2202, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 2200 may include additional elements such as, for example, memory /storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C- RAN) implementations).

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

[00208] The baseband circuitry 2204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 2204 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 2206 and to generate baseband signals for a transmit signal path of the RF circuitry 2206. Baseband processing circuity 2204 may interface with the application circuitry 2202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 2206. For example, in some embodiments, the baseband circuitry 2204 may include a third generation (3G) baseband processor 2204A, a fourth generation (4G) baseband processor 2204B, a fifth generation (5G) baseband processor 2204C, or other baseband processor(s) 2204D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), and so on). The baseband circuitry 2204 (e.g., one or more of baseband processors 2204A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 2206. In other embodiments, some or all of the functionality of baseband processors 2204A-D may be included in modules stored in the memory 2204G and executed via a Central Processing Unit (CPU) 2204E. The radio control functions may include, but are not limited to, signal modulation/demodulation,

encoding/decoding, radio frequency shifting, and so on. In some embodiments,

modulation/demodulation circuitry of the baseband circuitry 2204 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 2204 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and

encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

[00209] In some embodiments, the baseband circuitry 2204 may include one or more audio digital signal processor(s) (DSP) 2204F. The audio DSP(s) 2204F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 2204 and the application circuitry 2202 may be implemented together such as, for example, on a system on a chip (SOC).

[00210] In some embodiments, the baseband circuitry 2204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 2204 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 2204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[00211] RF circuitry 2206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 2206 may include switches, filters, amplifiers, and so on to facilitate the communication with the wireless network. RF circuitry 2206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 2208 and provide baseband signals to the baseband circuitry 2204. RF circuitry 2206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 2204 and provide RF output signals to the FEM circuitry 2208 for transmission.

[00212] In some embodiments, the receive signal path of the RF circuitry 2206 may include mixer circuitry 2206A, amplifier circuitry 2206B and filter circuitry 2206C. In some embodiments, the transmit signal path of the RF circuitry 2206 may include filter circuitry 2206C and mixer circuitry 2206A. RF circuitry 2206 may also include synthesizer circuitry 2206D for synthesizing a frequency for use by the mixer circuitry 2206A of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 2206A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 2208 based on the synthesized frequency provided by synthesizer circuitry 2206D. The amplifier circuitry 2206B may be configured to amplify the down-converted signals and the filter circuitry 2206C may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 2204 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 2206A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[00213] In some embodiments, the mixer circuitry 2206A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 2206D to generate RF output signals for the FEM circuitry 2208. The baseband signals may be provided by the baseband circuitry 2204 and may be filtered by filter circuitry 2206C.

[00214] In some embodiments, the mixer circuitry 2206A of the receive signal path and the mixer circuitry 2206A of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 2206A of the receive signal path and the mixer circuitry 2206A 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 2206A of the receive signal path and the mixer circuitry 2206A may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 2206A of the receive signal path and the mixer circuitry 2206A of the transmit signal path may be configured for super-heterodyne operation.

[00215] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 2206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 2204 may include a digital baseband interface to communicate with the RF circuitry 2206.

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

[00217] In some embodiments, the synthesizer circuitry 2206D may be a fractional-N synthesizer or a fractional N/N+l 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 circuitry 2206D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[00218] The synthesizer circuitry 2206D may be configured to synthesize an output frequency for use by the mixer circuitry 2206A of the RF circuitry 2206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 2206D may be a fractional N/N+l synthesizer.

[00219] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 2204 or the applications processor 2202 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 2202. [00220] Synthesizer circuitry 2206D of the RF circuitry 2206 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[00221] In some embodiments, synthesizer circuitry 2206D 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 quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 2206 may include an IQ/polar converter.

[00222] FEM circuitry 2208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 2210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 2206 for further processing. FEM circuitry 2208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 2206 for transmission by one or more of the one or more antennas 2210. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 2206, solely in the FEM 2208, or in both the RF circuitry 2206 and the FEM 2208.

[00223] In some embodiments, the FEM circuitry 2208 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 2206). The transmit signal path of the FEM circuitry 2208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 2206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 2210).

[00224] In some embodiments, the PMC 2212 may manage power provided to the baseband circuitry 2204. In particular, the PMC 2212 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 2212 may often be included when the device 2200 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 2212 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[00225] While Fig. 22 shows the PMC 2212 coupled only with the baseband circuitry 2204. However, in other embodiments, the PMC 2212 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 2202, RF circuitry 2206, or FEM 2208.

[00226] In some embodiments, the PMC 2212 may control, or otherwise be part of, various power saving mechanisms of the device 2200. For example, if the device 2200 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 2200 may power down for brief intervals of time and thus save power.

[00227] If there is no data traffic activity for an extended period of time, then the device 2200 may transition off to an RRC Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, and so on. The device 2200 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 2200 may not receive data in this state, in order to receive data, it must transition back to

RRC Connected state.

[00228] An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[00229] Processors of the application circuitry 2202 and processors of the baseband circuitry 2204 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 2204, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 2204 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

[00230] Fig. 23 illustrates example interfaces of baseband circuitry, in accordance with some embodiments of the disclosure. As discussed above, the baseband circuitry 2204 of Fig. 22 may comprise processors 2204A-2204E and a memory 2204G utilized by said processors. Each of the processors 2204A-2204E may include a memory interface, 2304A- 2304E, respectively, to send/receive data to/from the memory 2204G.

[00231] The baseband circuitry 2204 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 2312 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 2204), an application circuitry interface 2314 (e.g., an interface to send/receive data to/from the application circuitry 2202 of Fig. 22), an RF circuitry interface 2316 (e.g., an interface to send/receive data to/from RF circuitry 2206 of Fig. 22), a wireless hardware connectivity interface 2318 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 2320 (e.g., an interface to send/receive power or control signals to/from the PMC 2212.

[00232] It is pointed out that elements of any of the Figures herein having the same reference numbers and/or names as elements of any other Figure herein may, in various embodiments, operate or function in a manner similar those elements of the other Figure (without being limited to operating or functioning in such a manner).

[00233] Reference in the specification to "an embodiment," "one embodiment," "some embodiments," or "other embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments. The various appearances of "an embodiment," "one embodiment," or "some embodiments" are not necessarily all referring to the same embodiments. If the specification states a component, feature, structure, or characteristic "may," "might," or "could" be included, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to "a" or "an" element, that does not mean there is only one of the elements. If the specification or claims refer to "an additional" element, that does not preclude there being more than one of the additional element.

[00234] Furthermore, the particular features, structures, functions, or characteristics may be combined in any suitable manner in one or more embodiments. For example, a first embodiment may be combined with a second embodiment anywhere the particular features, structures, functions, or characteristics associated with the two embodiments are not mutually exclusive.

[00235] While the disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications and variations of such embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures e.g., Dynamic RAM (DRAM) may use the

embodiments discussed. The embodiments of the disclosure are intended to embrace all such alternatives, modifications, and variations as to fall within the broad scope of the appended claims.

[00236] In addition, well known power/ground connections to integrated circuit (IC) chips and other components may or may not be shown within the presented figures, for simplicity of illustration and discussion, and so as not to obscure the disclosure. Further, arrangements may be shown in block diagram form in order to avoid obscuring the disclosure, and also in view of the fact that specifics with respect to implementation of such block diagram arrangements are highly dependent upon the platform within which the present disclosure is to be implemented (i.e., such specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that the disclosure can be practiced without, or with variation of, these specific details. The description is thus to be regarded as illustrative instead of limiting.

[00237] The following examples pertain to further embodiments. Specifics in the examples may be used anywhere in one or more embodiments. All optional features of the apparatus described herein may also be implemented with respect to a method or process.

[00238] Example 1 provides an apparatus of a User Equipment (UE) operable to communicate with an Evolved Node B (eNB) on a wireless network, comprising: one or more processors to: establish one or more headers respectively corresponding with one or more Service Data Units (SDUs); form one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs; and form a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed; and a memory for storing at least one of: the one or more headers, the first PDUs, or the second PDU.

[00239] In example 2, the apparatus of example 1, wherein the one or more processors are to: assign one or more respectively corresponding sequence numbers (SNs) to the one or more SDUs.

[00240] In example 3, the apparatus of example 2, wherein the one or more SNs are assigned from one of: a Mission Critical (MC) SN pool, a Control Plane (CP) SN pool, or a User Plane (UP) SN pool.

[00241] In example 4, the apparatus of example 2, wherein the one or more SNs are assigned from one of a number N of SN pools, the number N being a number of supported priorities.

[00242] In example 5, the apparatus of any of examples 1 through 4, wherein the one or more processors are to: assign a type to the second PDU.

[00243] In example 6, the apparatus of any of example 5, wherein the type is selected from one of: a Mission Critical (MC) type, a Control Plane (CP) type, or a User Plane (UP) type.

[00244] In example 7, the apparatus of any of examples 1 through 6, wherein the one or more headers include at least one of: a resegmentation flag, a last SDU or segment flag, a length indicator, or a sequence number (SN).

[00245] In example 8, the apparatus of any of examples 1 through 7, wherein the memory is one of: a transmission buffer, or a retransmission buffer.

[00246] In example 9, the apparatus of any of examples 1 through 8, wherein the one or more SDUs are received from one of: an Internet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00247] In example 10, the apparatus of example 9, wherein the RRC layer is a sidelink RRC layer.

[00248] In example 11, the apparatus of any of examples 1 through 10, wherein the second PDU has a first part including the one or more first PDUs and a second part including a header for the second PDU; and wherein the second part is positioned at the end of the second PDU. [00249] In example 12, the apparatus of example 11, wherein the second part includes one or more Control Elements (CEs).

[00250] In example 13, the apparatus of example 12, wherein the one or more Control

Elements (CEs) are selected from: a Buffer Status Report (BSR) or a power headroom report.

[00251] Example 14 provides a User Equipment (UE) device comprising an application processor, a memory, one or more antennas, a wireless interface for allowing the application processor to communicate with another device, and a touch-screen display, the UE device including the apparatus of any of examples 1 through 13.

[00252] Example 15 provides a method comprising: establishing, for a User

Equipment (UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network, one or more headers respectively corresponding with one or more Service Data Units (SDUs); forming one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs; and forming a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

[00253] In example 16, the method of example 15, comprising: assigning one or more respectively corresponding sequence numbers (SNs) to the one or more SDUs.

[00254] In example 17, the method of example 16, wherein the one or more SNs are assigned from one of: a Mission Critical (MC) SN pool, a Control Plane (CP) SN pool, or a User Plane (UP) SN pool.

[00255] In example 18, the method of example 16, wherein the one or more SNs are assigned from one of a number N of SN pools, the number N being a number of supported priorities.

[00256] In example 19, the method of any of examples 15 through 18, the operation comprising: assigning a type to the second PDU.

[00257] In example 20, the method of example 19, the operation comprising: wherein the type is selected from one of: a Mission Critical (MC) type, a Control Plane (CP) type, or a User Plane (UP) type.

[00258] In example 21, the method of any of examples 15 through 20, wherein the one or more headers include at least one of: a resegmentation flag, a last SDU or segment flag, a length indicator, or a sequence number (SN).

[00259] In example 22, the method of any of examples 15 through 21, wherein the memory is one of: a transmission buffer, or a retransmission buffer. [00260] In example 23, the method of any of examples 15 through 22, wherein the one or more SDUs are received from one of: an Internet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00261] In example 24, the method of example 23, wherein the RRC layer is a sidelink

RRC layer.

[00262] In example 25, the method of any of examples 15 through 24, wherein the second PDU has a first part including the one or more first PDUs and a second part including a header for the second PDU; and wherein the second part is positioned at the end of the second PDU.

[00263] In example 26, the method of example 25, wherein the second part includes one or more Control Elements (CEs).

[00264] In example 27, the method of example 26, wherein the one or more Control

[00265] Example 28 provides machine readable storage media having machine executable instructions stored thereon that, when executed, cause one or more processors to perform a method according to any of examples 15 through 27.

[00266] Example 29 provides an apparatus of a User Equipment (UE) operable to communicate with an Evolved Node B (eNB) on a wireless network, comprising: means for establishing one or more headers respectively corresponding with one or more Service Data Units (SDUs); means for forming one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs; and means for forming a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

[00267] In example 30, the apparatus of example 29, comprising: means for assigning one or more respectively corresponding sequence numbers (SNs) to the one or more SDUs.

[00268] In example 31, the apparatus of example 30, wherein the one or more SNs are assigned from one of: a Mission Critical (MC) SN pool, a Control Plane (CP) SN pool, or a User Plane (UP) SN pool.

[00269] In example 32, the apparatus of example 30, wherein the one or more SNs are assigned from one of a number N of SN pools, the number N being a number of supported priorities.

[00270] In example 33, the apparatus of any of examples 29 through 32, the operation comprising: means for assigning a type to the second PDU. [00271] In example 34, the apparatus of example 33, the operation comprising:

wherein the type is selected from one of: a Mission Critical (MC) type, a Control Plane (CP) type, or a User Plane (UP) type.

[00272] In example 35, the apparatus of any of examples 29 through 34, wherein the one or more headers include at least one of: a resegmentation flag, a last SDU or segment flag, a length indicator, or a sequence number (SN).

[00273] In example 36, the apparatus of any of examples 29 through 35, wherein the memory is one of: a transmission buffer, or a retransmission buffer.

[00274] In example 37, the apparatus of any of examples 29 through 36, wherein the one or more SDUs are received from one of: an Internet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00275] In example 38, the apparatus of example 37, wherein the RRC layer is a sidelink RRC layer.

[00276] In example 39, the apparatus of any of examples 29 through 38, wherein the second PDU has a first part including the one or more first PDUs and a second part including a header for the second PDU; and wherein the second part is positioned at the end of the second PDU.

[00277] In example 40, the apparatus of example 39, wherein the second part includes one or more Control Elements (CEs).

[00278] In example 41, the apparatus of example 40, wherein the one or more Control

[00279] Example 42 provides machine readable storage media having machine executable instructions that, when executed, cause one or more processors of a User

Equipment (UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network to perform an operation comprising: establish one or more headers respectively corresponding with one or more Service Data Units (SDUs); form one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs; and form a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

[00280] In example 43, the machine readable storage media of example 42, the operation comprising: assign one or more respectively corresponding sequence numbers (SNs) to the one or more SDUs. [00281] In example 44, the machine readable storage media of example 43, wherein the one or more SNs are assigned from one of: a Mission Critical (MC) SN pool, a Control Plane (CP) SN pool, or a User Plane (UP) SN pool.

[00282] In example 45, the machine readable storage media of example 43, wherein the one or more SNs are assigned from one of a number N of SN pools, the number N being a number of supported priorities.

[00283] In example 46, the machine readable storage media of any of examples 42 through 45, the operation comprising: assign a type to the second PDU.

[00284] In example 47, the machine readable storage media of example 46, the operation comprising: wherein the type is selected from one of: a Mission Critical (MC) type, a Control Plane (CP) type, or a User Plane (UP) type.

[00285] In example 48, the machine readable storage media of any of examples 42 through 47, wherein the one or more headers include at least one of: a resegmentation flag, a last SDU or segment flag, a length indicator, or a sequence number (SN).

[00286] In example 49, the machine readable storage media of any of examples 42 through 48, wherein the memory is one of: a transmission buffer, or a retransmission buffer.

[00287] In example 50, the machine readable storage media of any of examples 42 through 49, wherein the one or more SDUs are received from one of: an Internet Protocol

(IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00288] In example 51, the machine readable storage media of example 50, wherein the RRC layer is a sidelink RRC layer.

[00289] In example 52, the machine readable storage media of any of examples 42 through 51, wherein the second PDU has a first part including the one or more first PDUs and a second part including a header for the second PDU; and wherein the second part is positioned at the end of the second PDU.

[00290] In example 53, the machine readable storage media of example 52, wherein the second part includes one or more Control Elements (CEs).

[00291] In example 54, the machine readable storage media of example 53, wherein the one or more Control Elements (CEs) are selected from: a Buffer Status Report (BSR) or a power headroom report.

[00292] Example 55 provides an apparatus of a User Equipment (UE) operable to communicate with an Evolved Node B (eNB) on a wireless network, comprising: one or more processors to: form one or more first Protocol Data Units (PDUs) to include one or more respectively corresponding Service Data Units (SDUs); establish a header for a second PDU based at least in part upon the one or more first PDUs; and form the second PDU to have a first part including the one or more first PDUs and a second part including the header for the second PDU, wherein the second part is positioned at the end of the second PDU; and an interface for sending the second PDU to a physical layer (PHY) circuitry.

[00293] In example 56, the apparatus of example 55, wherein a Most Significant Bit

(MSB) of the first part is positioned toward the beginning of the second PDU; wherein a Least Significant Bit (LSB) of the first part is positioned toward the end of the second PDU; wherein an MSB of the second part is positioned toward the end of the second PDU; and wherein an LSB of the second part is positioned toward the beginning of the second PDU.

[00294] In example 57, the apparatus of any of examples 55 through 56, wherein the first part has at least one segment of a first PDU.

[00295] In example 58, the apparatus of any of examples 55 through 57, wherein the header for the second PDU includes one or more Control Elements (CEs).

[00296] In example 59, the apparatus of example 58, wherein the one or more Control

[00297] In example 60, the apparatus of any of examples 55 through 59, wherein the header for the second PDU is a first header for the second PDU, and wherein the one or more processors are to: form the second PDU to have a third part including a second header for the second PDU; wherein the third part is positioned at the beginning of the second PDU.

[00298] In example 61, the apparatus of any of examples 55 through 60, wherein the one or more SDUs are received from one of: an Internet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00299] In example 62, the apparatus of example 61, wherein the RRC layer is a sidelink RRC layer.

[00300] In example 63, the apparatus of any of examples 55 through 62, wherein the one or more processors are to: establish one or more headers respectively corresponding with the one or more SDUs; and form the one or more first PDUs to include the one or more headers and the one or more SDUs in a respectively corresponding manner.

[00301] In example 64, the apparatus of example 63, wherein the one or more processors are to: form the second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed. [00302] In example 65, the apparatus of any of examples 55 through 64, the apparatus comprising: one or more Hybrid Automatic Repeat Request (HARQ) circuitries coupled to receive the one or more first PDUs in a respectively corresponding manner.

[00303] Example 66 provides a User Equipment (UE) device comprising an application processor, a memory, one or more antennas, a wireless interface for allowing the application processor to communicate with another device, and a touch-screen display, the UE device including the apparatus of any of examples 55 through 65.

[00304] Example 67 provides a method comprising: forming, for a User Equipment

(UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network, one or more first Protocol Data Units (PDUs) to include one or more respectively corresponding Service Data Units (SDUs); establishing a header for a second PDU based at least in part upon the one or more first PDUs; and forming the second PDU to have a first part including the one or more first PDUs and a second part including the header for the second PDU, wherein the second part is positioned at the end of the second PDU; and

[00305] In example 68, the method of example 67, wherein a Most Significant Bit

[00306] In example 69, the method of any of examples 67 through 68, wherein the first part has at least one segment of a first PDU.

[00307] In example 70, the method of any of examples 67 through 69, wherein the header for the second PDU includes one or more Control Elements (CEs).

[00308] In example 71, the method of example 70, wherein the one or more Control

[00309] In example 72, the method of any of examples 67 through 71, wherein the header for the second PDU is a first header for the second PDU, comprising: forming the second PDU to have a third part including a second header for the second PDU; wherein the third part is positioned at the beginning of the second PDU.

[00310] In example 73, the method of any of examples 67 through 72, wherein the one or more SDUs are received from one of: an Intemet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00311] In example 74, the method of example 73, wherein the RRC layer is a sidelink

RRC layer. [00312] In example 75, the method of any of examples 67 through 74, comprising: establishing one or more headers respectively corresponding with the one or more SDUs; and forming the one or more first PDUs to include the one or more headers and the one or more SDUs in a respectively corresponding manner.

[00313] In example 76, the method of example 75, comprising: forming the second

PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

[00314] Example 77 provides machine readable storage media having machine executable instructions stored thereon that, when executed, cause one or more processors to perform a method according to any of examples 67 through 76.

[00315] Example 78 provides an apparatus of a User Equipment (UE) operable to communicate with an Evolved Node B (eNB) on a wireless network, comprising: means for forming one or more first Protocol Data Units (PDUs) to include one or more respectively corresponding Service Data Units (SDUs); means for establishing a header for a second PDU based at least in part upon the one or more first PDUs; and means for forming the second PDU to have a first part including the one or more first PDUs and a second part including the header for the second PDU, wherein the second part is positioned at the end of the second PDU; and

[00316] In example 79, the apparatus of example 78, wherein a Most Significant Bit

[00317] In example 80, the apparatus of any of examples 78 through 79, wherein the first part has at least one segment of a first PDU.

[00318] In example 81, the apparatus of any of examples 78 through 80, wherein the header for the second PDU includes one or more Control Elements (CEs).

[00319] In example 82, the apparatus of example 81, wherein the one or more Control

[00320] In example 83, the apparatus of any of examples 78 through 82, wherein the header for the second PDU is a first header for the second PDU, comprising: means for forming the second PDU to have a third part including a second header for the second PDU; wherein the third part is positioned at the beginning of the second PDU. [00321] In example 84, the apparatus of any of examples 78 through 83, wherein the one or more SDUs are received from one of: an Internet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00322] In example 85, the apparatus of example 84, wherein the RRC layer is a sidelink RRC layer.

[00323] In example 86, the apparatus of any of examples 78 through 85, comprising: means for establishing one or more headers respectively corresponding with the one or more SDUs; and means for forming the one or more first PDUs to include the one or more headers and the one or more SDUs in a respectively corresponding manner.

[00324] In example 87, the apparatus of example 86, comprising: means for forming the second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

[00325] Example 88 provides machine readable storage media having machine executable instructions that, when executed, cause one or more processors of a User

Equipment (UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network to perform an operation comprising: form one or more first Protocol Data Units (PDUs) to include one or more respectively corresponding Service Data Units (SDUs);

establish a header for a second PDU based at least in part upon the one or more first PDUs; and form the second PDU to have a first part including the one or more first PDUs and a second part including the header for the second PDU, wherein the second part is positioned at the end of the second PDU; and

[00326] In example 89, the machine readable storage media of example 88, wherein a

Most Significant Bit (MSB) of the first part is positioned toward the beginning of the second PDU; wherein a Least Significant Bit (LSB) of the first part is positioned toward the end of the second PDU; wherein an MSB of the second part is positioned toward the end of the second PDU; and wherein an LSB of the second part is positioned toward the beginning of the second PDU.

[00327] In example 90, the machine readable storage media of any of examples 88 through 89, wherein the first part has at least one segment of a first PDU.

[00328] In example 91, the machine readable storage media of any of examples 88 through 90, wherein the header for the second PDU includes one or more Control Elements

(CEs). [00329] In example 92, the machine readable storage media of example 91, wherein the one or more Control Elements (CEs) are selected from: a Buffer Status Report (BSR) or a power headroom report.

[00330] In example 93, the machine readable storage media of any of examples 88 through 92, wherein the header for the second PDU is a first header for the second PDU, the operation comprising: form the second PDU to have a third part including a second header for the second PDU; wherein the third part is positioned at the beginning of the second PDU.

[00331] In example 94, the machine readable storage media of any of examples 88 through 93, wherein the one or more SDUs are received from one of: an Internet Protocol (IP) layer, an Application layer, or a Radio Resource Control (RRC) layer.

[00332] In example 95, the machine readable storage media of example 94, wherein the RRC layer is a sidelink RRC layer.

[00333] In example 96, the machine readable storage media of any of examples 88 through 95, the operation comprising: establish one or more headers respectively

corresponding with the one or more SDUs; and form the one or more first PDUs to include the one or more headers and the one or more SDUs in a respectively corresponding manner.

[00334] In example 97, the machine readable storage media of example 96, the operation comprising: form the second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY), wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

[00335] In example 98, the apparatus of any of examples 1 through 12, and 55 through

65, wherein the one or more processors comprise a baseband processor.

[00336] In example 99, the apparatus of any of examples 1 through 12, and 55 through

65, comprising a memory for storing instructions, the memory being coupled to the one or more processors.

[00337] In example 100, the apparatus of any of examples 1 through 12, and 55 through 65, comprising a transceiver circuitry for at least one of: generating transmissions, encoding transmissions, processing transmissions, or decoding transmissions.

[00338] In example 101, the apparatus of any of examples 1 through 12, and 55 through 65, comprising a transceiver circuitry for generating transmissions and processing transmissions.

[00339] An abstract is provided that will allow the reader to ascertain the nature and gist of the technical disclosure. The abstract is submitted with the understanding that it will not be used to limit the scope or meaning of the claims. The following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims

claim:

An apparatus of a User Equipment (UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network, comprising:

one or more processors to:

establish one or more headers respectively corresponding with one or more

Service Data Units (SDUs);

form one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs; and form a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY),

wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed; and

a memory for storing at least one of: the one or more headers, the first PDUs, or the second PDU.

The apparatus of claim 1, wherein the one or more processors are to:

assign one or more respectively corresponding sequence numbers (SNs) to the one or more SDUs.

The apparatus of claim 2,

wherein the one or more SNs are assigned from one of: a Mission Critical (MC) SN pool, a Control Plane (CP) SN pool, or a User Plane (UP) SN pool.

The apparatus of claim 2,

wherein the one or more SNs are assigned from one of a number N of SN pools, the number N being a number of supported priorities.

The apparatus of any of claims 1 through 4, wherein the one or more processors are to: assign a type to the second PDU.

6. The apparatus of any of claim 5, wherein the type is selected from one of: a Mission Critical (MC) type, a Control Plane (CP) type, or a User Plane (UP) type.

7. Machine readable storage media having machine executable instructions that, when executed, cause one or more processors of a User Equipment (UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network to perform an operation comprising:

establish one or more headers respectively corresponding with one or more Service Data Units (SDUs);

form one or more respectively corresponding first Protocol Data Units (PDUs) to include the one or more headers and the one or more SDUs; and

form a second PDU to include the one or more first PDUs based on one or more resource grants from a Physical Layer (PHY),

wherein the one or more resource grants are available from the PHY after the one or more first PDUs are formed.

The machine readable storage media of claim 7, the operation comprising:

assign one or more respectively corresponding sequence numbers (SNs) to the more SDUs.

9. The machine readable storage media of claim 8,

10. The machine readable storage media of claim 8,

11. The machine readable storage media of any of claims 7 through 10, the operation

comprising:

assign a type to the second PDU.

12. The machine readable storage media of claim 11, the operation comprising:

13. An apparatus of a User Equipment (UE) operable to communicate with an Evolved

Node-B (eNB) on a wireless network, comprising:

one or more processors to:

form one or more first Protocol Data Units (PDUs) to include one or more respectively corresponding Service Data Units (SDUs);

establish a header for a second PDU based at least in part upon the one or more first PDUs; and

form the second PDU to have a first part including the one or more first PDUs and a second part including the header for the second PDU,

wherein the second part is positioned at the end of the second PDU; and an interface for sending the second PDU to a physical layer (PHY) circuitry.

14. The apparatus of claim 13,

wherein a Most Significant Bit (MSB) of the first part is positioned toward the

beginning of the second PDU;

wherein a Least Significant Bit (LSB) of the first part is positioned toward the end of the second PDU;

wherein an MSB of the second part is positioned toward the end of the second PDU; and

wherein an LSB of the second part is positioned toward the beginning of the second PDU.

15. The apparatus of any of claims 13 through 14,

wherein the first part has at least one segment of a first PDU.

16. The apparatus of any of claims 13 through 14,

wherein the header for the second PDU includes one or more Control Elements (CEs).

17. The apparatus of claim 16,

wherein the one or more Control Elements (CEs) are selected from: a Buffer Status Report (BSR) or a power headroom report.

18. The apparatus of any of claims 13 through 14, wherein the header for the second PDU is a first header for the second PDU, and wherein the one or more processors are to:

form the second PDU to have a third part including a second header for the second PDU;

wherein the third part is positioned at the beginning of the second PDU.

19. Machine readable storage media having machine executable instructions that, when

executed, cause one or more processors of a User Equipment (UE) operable to communicate with an Evolved Node-B (eNB) on a wireless network to perform an operation comprising:

form one or more first Protocol Data Units (PDUs) to include one or more

respectively corresponding Service Data Units (SDUs);

wherein the second part is positioned at the end of the second PDU; and

20. The machine readable storage media of claim 19,

wherein a Most Significant Bit (MSB) of the first part is positioned toward the

beginning of the second PDU;

21. The machine readable storage media of any of claims 19 through 20,

wherein the first part has at least one segment of a first PDU.

22. The machine readable storage media of any of claims 19 through 20, wherein the header for the second PDU includes one or more Control Elements (CEs).

23. The machine readable storage media of claim 22,

24. The machine readable storage media of any of claims 19 through 20, wherein the header for the second PDU is a first header for the second PDU, the operation comprising:

wherein the third part is positioned at the beginning of the second PDU.