Packet framing for application data unit transmission

Abstract

The present application relates to devices and components, including apparatus, systems, and methods for techniques for packet framing for application data unit transmission in wireless networks.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 282,929, entitled "Packet Framing for Application Data Unit Transmission," filed November 24, 2021, the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] The Third Generation Partnership Project (3GPP) Technical Specifications (TS) define standards for New Radio (NR) wireless networks. One area of ​​research for developing these TSs is to provide support for low latency communications and extended reality (XR) applications. [Brief description of the drawings]

[0003] [Figure 1] 1 illustrates a network environment according to some embodiments.

[0004] [Diagram 2] 1 illustrates data bursts that may be transmitted between application layers to exchange application data, according to some embodiments.

[0005] [Diagram 3] 4 illustrates network traffic according to some embodiments.

[0006] [Figure 4] 1 illustrates transmission and reception of an Application Data Unit (ADU) packet according to some embodiments.

[0007] [Diagram 5]13 illustrates additional transmission and reception of ADU packets according to some embodiments.

[0008] [Figure 6] 13 illustrates additional transmission and reception of ADU packets according to some embodiments.

[0009] [Figure 7] 13 illustrates additional transmission and reception of ADU packets according to some embodiments.

[0010] [Figure 8] 1 illustrates an operational flow / algorithm structure according to some embodiments.

[0011] [Figure 9] 1 illustrates another operational flow / algorithm structure according to some embodiments.

[0012] [Figure 10] 1 illustrates a user equipment according to some embodiments.

[0013] [Figure 11] 1 illustrates a network node according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details of certain structures, architectures, interfaces, and techniques are set forth in order to provide a thorough understanding of various aspects of various embodiments. However, it will be apparent to one of ordinary skill in the art having the benefit of this disclosure that various aspects of various embodiments may be practiced in other examples that depart from these specific details. In some cases, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For purposes of this document, the phrases "A / B" and "A or B" mean (A), (B), or (A and B).

[0015] Below is a glossary of terms that may be used in this disclosure.

[0016] The term "circuitry" as used herein refers to, is a part of, or includes a hardware component configured to provide a described function. The hardware component may include electronic circuits, logic circuits, processors (shared, dedicated, or group) or memories (shared, dedicated, or group), application specific integrated circuits (ASICs), field programmable devices (FPDs) (e.g., field programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high capacity PLDs (HCPLDs), structured ASICs, programmable systems on chips (SoCs)), or digital signal processors (DSPs). In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functions. The term "circuitry" may also refer to the combination of one or more hardware elements (or combinations of circuits used in an electrical or electronic system) and program code used to perform the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit configuration.

[0017] As used herein, the term "processor circuitry" refers to, is a part of, or includes circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations or the recording, storage, or transfer of digital data. The term "processor circuitry" may refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device that can execute or otherwise operate computer-executable instructions, such as program code, software modules, or functional processes.

[0018] As used herein, the term "interface circuitry" refers to, is a part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, and a network interface card.

[0019] The term "user equipment" or "UE" as used herein refers to a device having wireless communication capabilities that may enable a user to access network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with and may be referred to as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, wireless equipment, reconfigurable wireless equipment, or reconfigurable mobile device. Furthermore, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0020] As used herein, the term "computer system" refers to any type of interconnected electronic device, computing device, or components thereof. In addition, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computing devices or multiple computing systems that are communicatively coupled to each other and configured to share computing or networking resources.

[0021] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component in a computing environment, or a physical or virtual component in a particular device, such as a computer device, a mechanical device, memory space, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, databases and applications, or workload units. A "hardware resource" may refer to a computational, storage, or network resource provided by a physical hardware element. A "virtualized resource" may refer to a computational, storage, or network resource provided by a virtualization infrastructure to an application, device, or system. The term "network resource" or "communication resource" may refer to a resource accessible by a computer device / system through a communication network. The term "system resource" may refer to any kind of shared entity for providing a service and may include a computing resource or a network resource. A system resource may be considered as a set of coherent functions, network data objects, or services, where such system resources reside on a single host or multiple hosts and are accessible through a clearly identifiable server.

[0022] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to communicate data or data streams. The term "channel" may be synonymous or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a path or medium over which data is communicated. Additionally, as used herein, the term "link" refers to a connection between two devices for the purpose of transmitting and receiving information.

[0023] As used herein, the terms "instantiate," "instantiation," and the like refer to the creation of an instance. An "instance" also refers to a concrete occurrence of an object, such as may occur during the execution of program code.

[0024] The term "connected" may mean that two or more elements at a common communications protocol layer have an established signaling relationship with each other via a communications channel, link, interface, or reference point.

[0025] As used herein, the term "network element" refers to a physical or virtualized device or infrastructure used to provide wired or wireless communications network services. The term "network element" may be considered or referred to as synonymous with a networked computer, networking hardware, network equipment, network node, or virtualized network function.

[0026] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to an information element or an individual content of a data element that contains the content. An information element may contain one or more further information elements.

[0027] As briefly introduced above, one research area for developing 3GPP TS is supporting low latency communication and XR applications. Related key performance indicators (KPIs) and quality of service (QoS) aspects can specify Radio Access Network (RAN) support for extended granularity for QoS, Application Data Unit (ADU)-based QoS, and XR-specific QoS parameters. QoS flow handling and corresponding Data Radio Bearer (DRB) control can also be specified.

[0028] There may be multiple potential development areas for application awareness in RAN operations. For example, it may be beneficial for a next-generation Node B (gNB) to identify XR traffic characteristics and application layer attributes to be aware of QoS flow association, frame-level QoS, ADU-based QoS, and XR-specific QoS. Furthermore, application layer information such as frame rate, latency, and packet importance may assist XR-specific processing (e.g., scheduling and radio bearer processing). Embodiments of the present disclosure describe aspects for facilitating network awareness of the ADU to enable enhanced QoS.

[0029] 1 illustrates a network environment 100 according to some embodiments. The network environment 100 may include a UE 104 communicatively coupled to an access node (AN) 108. The UE 104 and the AN 108 may have access stratum (AS) layers 106 and 110, respectively, for communicating over an air interface compatible with a 3GPP TS, such as that defining a fifth generation (5G) NR system standard. The AN 108 may be a gNB for providing one or more 5G new radio (NR) cells, offering NR user plane and control plane protocol terminations towards the UE 104.

[0030] Briefly, protocol stack layers 106 and 110 may include various layers organized in a user plane AS and a control plane protocol stack. The user plane protocol stack may include a Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and a Physical (PHY) layer. The control plane protocol stack may include a Radio Resource Control (RRC), PDCP, RLC, MAC, and PHY.

[0031] The network environment 100 may further include a Core Network (CN) 112, such as a Fifth Generation Core Network (5GC). The CN 112 may include a Non-Access Stratum (NAS) layer 122 communicatively coupled to a NAS layer 120 in the UE 104.

[0032] The CN 112 may have a User Plane Function (UPF) responsible for routing and forwarding user plane packets between the access nodes 108 and external networks. The UPF may handle the user plane path of a Protocol Data Unit (PDU) session. The UPF may be coupled to a Session Management Function (SMF), which configures traffic steering, QoS control, and policy related functions in the SMF, and performs PDU session management, IP address allocation, General Packet Radio Service Tunneling Protocol-User Plane (GTP-U) tunnel management, user plane function selection and control, and downlink notification management. The CN 112 may also have an Access and Mobility Management Function (AMF) for handling connectivity and mobility management tasks.

[0033] The AN 108 may include a transport layer 144 communicatively coupled to a transport layer 148 in the CN 112. The transport layer 144 / 148 may handle various transport protocol functions over an N3 interface between the AN 108 and the UPF of the CN 112, or over an N9 interface between different UPFs. These functions may include, for example, rerouting, roaming, multihoming, etc., which may be similar to those described in TS 23.501 v17.2.0 (2021-09-24), TS 38.414 v16.0.0 (2020-07-17), TS 38.415 v16.5.0 (2021-07-01), and TS 38.410 v16.4.0 (2021-10-01).

[0034] Various components of the network environment 100 may perform QoS mapping operations for transmissions between the application layer 116 and the application layer 140 in the device 142. The device 142 may be a server, another UE, or another network node. Except as otherwise described herein, these QoS mapping operations may be similar to those described in the QoS model in section 5.7 of 3GPP TS 23.501 v17.2.0 (2021-09).

[0035] Each QoS flow may be associated with a set of QoS characteristics, such as, for example, a resource type, a packet delay budget (PDB), a packet error rate (PER), a priority level, and an averaging window. The QoS characteristics are part of a QoS profile stored in the AN 108. The QoS profile may be referenced by a QoS identifier (e.g., a 5G QoS Identifier (5QI)).

[0036] Section 5.7 of 3GPP TS23.501 v17.2.0 (2021-09-24) defines a set of standardized 5QIs and associated QoS characteristics. An extended range of operator-specific 5QIs may also be configured. For non-guaranteed bit rate (GBR) QoS flows with standardized 5QI values, the 5QI value may be used as the QFI and a default allocation / retention priority (ARP) may be assumed. No additional signaling over the N2 interface (between the AMF and the AN108) may be required. For GBR and non-GBR QoS flows, all required QoS parameters corresponding to the QFI may be sent as a QoS profile to the AN108 as a PDU session establishment or modification.

[0037] The QoS rules may be signaled from the NAS layer 120 to the NAS layer 122 using PDU session establishment / modification, pre-configured in the UE 104, or derived implicitly by applying reflective QoS. The QoS rules may include the QFI, packet filter set, and priority value of the associated QoS flow. In case of dynamically assigned QFI, the QoS rules may include QoS parameters (e.g., 5QI, GBR, maximum bit rate (MBR), and averaging window) relevant to the UE 104. The complete QoS characteristics may not be transferred over the air. The UE 104 may instead be provided with the QoS rules.

[0038] FIG. 2 illustrates a data burst 204 that may be transmitted between the application layers 116 and 140 to exchange application data, according to some embodiments. The data burst may be a bit stream of interrelated application data. The data may correspond to an application, such as an XR application. The bit stream may be divided into multiple ADUs. An ADU may be considered the smallest data unit that can be independently processed by the application layer. One ADU may include multiple lower layer packets for wireless transmission. For example, one ADU may be packetized into multiple lower layer packets. The lower layer packets may also be referred to as ADU packets or data units (DUs) throughout this specification. A DU may be a protocol data unit (PDU) or a service data unit (SDU). For example, one ADU may include multiple lower layer packets. Although FIG. 7 illustrates each ADU with m packets, different ADUs may have different numbers of packets.

[0039] An ADU may be specified for a coding format in a 3GPP file format (3GP) file and an RTP payload format. For audio and speech, an ADU may be specified as a coded frame intended for transport. For audio codecs, an ADU may be defined as an audio frame. For the H.263 video compression standard, an ADU may include the entire RTP payload. For the H.264 Advanced Video Coding (AVC) standard or the H.265 High Efficiency Video Coding (HEVC) standard, an ADU may be a Network Adaptation Layer Unit (NALU). For timed text, an ADU may include any of the RTP payload units of types 1-5. Further definitions and explanations of ADU can be found in 3GPP Technical Specifications (TS) 26.234 v16.2.0 (2020-12-23), TS 26.244 v16.1.0 (2020-09-25), TS 26.346 v16.9.1 (2021-05-26), IETF RFC 6363 (October 2011), or IETF RFC 2736 (December 1999).

[0040] In some video compression standards (e.g., H.264), an image may be divided into regions called slices. Each slice may contain a set of macroblocks and may be reconstructed independently from other slices in the same picture. A frame may contain one or more slices. A slice may be a segment of a frame that may be processed independently. H.264 may include three slice types: intra-coded picture (I) slices, predictive (P) slices, and bidirectionally predictive (B) slices. I slices may be formed as I frames, P slices may be formed as P frames, and B slices may be formed as B frames. The transmission of I frames, which serve as references for other frames, may be prioritized over the transmission of P / B frames. P / B frames may be transmitted at a higher compression rate.

[0041] An ADU may contain an entire frame or one or more slices, according to one or more of the following options: In the first option, lower layers may treat a slice as an ADU. However, an RTP packet may, for example, contain only a single slice mapped to a single UDP packet (e.g., as described in 3GPP TS26.114 v17.2.0 (2021-09-24)). In this case, multiple slices may be considered to form an ADU. In the second option, lower layers may treat a frame as an ADU. In the third option, an ADU may refer to a single frame, a single slice, multiple slices, or a union of special ADU types.

[0042] FIG. 3 illustrates network traffic 300 according to some embodiments. Network traffic 300 may include packets belonging to five different ADUs. Packets marked with "A" belong to the first ADU, packets marked with "B" belong to the second ADU, and so on. Typically, when packets are close to each other in a burst, they often stay together until they reach their common destination. A poor connection or congestion at a network node may cause an outgoing queue to fill up. A burst may occur when a hop has free capacity and the node immediately transmits all waiting packets. This may cause network traffic 300 to appear as "chunks" where packets belonging to the same ADU are likely adjacent to each other.

[0043] Embodiments provide awareness of ADUs at the RAN / CN level to improve the routing and processing of data through the network. When a network node has knowledge of packets belonging to a particular ADU, it can forward or otherwise process the packets in an advantageous manner. For example, the network node can prioritize transmission of packets corresponding to some ADUs (e.g., I-frame ADUs) over others, or coordinate the routing / forwarding / dropping of packets belonging to the same ADU. Knowledge of which RLC / PDCP / SDAP DUs carry the same ADU can also facilitate behavior when DUs and packets are delivered out of sequence.

[0044] Although the embodiments describe knowledge of which packets belong to which ADU, different packets may still be carried within the same QoS flow, and the lower layers may then ensure that these packets can be treated as a group.

[0045] Providing ADU awareness to lower layers can facilitate reliable and efficient transmission of ADUs through the network. For example, a recipient application may require successful receipt of all (or a large number of) DUs, otherwise the ADUs may not be processed. If data cannot be delivered on time (e.g., a packet delay budget is exceeded), subsequent transmissions of the data may be dropped.

[0046] Some aspects of the present disclosure address ADU-based QoS objectives. For example, it may be desirable to provide QoS differentiation by enabling the ability to transmit ADUs with different QoS / protection. This may require I-frames / slices and P-frames / slices to be processed with different reliability. It may be further desirable for a network node (e.g., UE 104, AN 108, UPF, or intermediate node) to identify that all desired IP packets of an ADU have been received, even if lower layers have spread the packets across multiple chunks of packets that were received and delivered out of sequence. It may be further desirable to identify all packets that form an ADU, identify ADU boundaries (e.g., start, stop, ADU length), or identify the importance / criticality of the ADU.

[0047] Various embodiments are described providing ADU information in the header of a DU to facilitate processing of out-of-sequence ADU packets, allowing the ADU to be mapped to lower layer packets, and providing a parameter set that may describe the ADU along with any other desired parameters. Some embodiments focus on the RAN layer (and in particular the Uu interface), although aspects of the embodiments (e.g., header fields and ADU parameters) may also be applied to network interfaces.

[0048] Providing ADU information in the header of the DU may enable ADU packet aggregation and scheduling optimization in view of the chunk / burst characteristics associated with network traffic described above. By knowing which packets belong to which ADU, the scheduler may aggregate the packets and send them together. The scheduler may delay forwarding a packet until a threshold number of packets (e.g., all packets) of the ADU are received from the previous hop. This may be particularly beneficial for traffic traveling over the air interface. For example, the scheduler of the AN 108 may not only optimize physical resources based on the type of ADU, but all packets of the ADU may be discarded early in the process if a subset of the packets do not arrive within a latency bound. This may be accomplished by utilizing ADU burst start / end times or through assistance information provided from the CN 112 to the AN 108. This information may also affect both uplink and downlink scheduling by the AN 108.

[0049] 4 illustrates transmission and reception of ADU packets according to some embodiments. Two ADUs, ADU#1 and ADU#2, may be generated at the application layer at 404. The ADUs may be packetized into lower layer packets (e.g., Layer 2 (L2) DUs) based on existing principles of data formatting and preparation at the transmitter.

[0050] The ADU convergence layer of the transmitter may also add ADU information (ADU info) to one or more of the L2 DUs. The ADU convergence layer may be integrated into an existing layer (SDAP, PDCP, RLC, MAC, GTP-U DU, or PDU session user plane protocol, XN-U, F1-U, or E1-U interface representing functions) or implemented separately. The L2 DU may include four DUs corresponding to ADU#1 and two DUs corresponding to ADU#2. The L2 DUs may correspond to SDAP, PDCP, RLC, MAC, GTP-U, PDU session user plane protocol, Xn-U, F1-U, or E1-U DU, or ADU convergence protocol DU (if this layer is implemented separately).

[0051] The L2 DUs may be transmitted by lower layers of a transmitter at 408 and received by lower layers of a receiver at 412. As shown, the L2 DUs may be received at 412 in a different order than they were transmitted.

[0052] In some embodiments, the ADU information added to the DU may be added as a header called an ADU descriptor or an ADU header. The ADU descriptor may be the larger of the two headers. One packet in every ADU may carry the ADU descriptor, which may indicate ADU parameters common to all packets in the ADU. For example, the ADU parameters that may be included in the ADU descriptor may be parameters that describe the ADU, such as ADU type or importance. In some embodiments, the ADU descriptor may be included in only one packet of the ADU, e.g., the first packet. As shown, the ADU descriptor may be present in the ADU information of L2 DU1 ADU#1 and L2 DU1 ADU#2.

[0053] The ADU information for each individual packet may also include an ADU header that includes packet-specific fields. For example, the ADU parameters that may be included in the ADU header may be parameters that describe the location of the packet relative to the set of packets that carry the ADU. The ADU descriptor and the ADU parameters provided in the ADU header are described in further detail below with respect to various embodiments.

[0054] Successful transmission of a packet carrying an ADU descriptor may be prioritized over transmission of other packets. If that packet is lost, the ADU must be dropped. However, in some embodiments, loss of a certain amount of low priority packets may occur without the need to drop the ADU. Thus, some embodiments provide features to reduce the likelihood that packets carrying an ADU descriptor will be lost. For example, the ADU descriptor may be placed in a high importance packet, and the receiver may buffer early packets until it receives the ADU descriptor. At that point, the receiver can begin full interpretation of the ADU. Additionally / alternatively, the use of the ADU descriptor may be applied in acknowledged mode transmissions or other configurations / environments where packets are less likely to be lost.

[0055] In some embodiments, instead of sending the ADU descriptor in a packet carrying a portion of the ADU, the UE 104 can provide the ADU descriptor to the AN 108 in the AS scheduling assistance information. The AS scheduling assistance information can be transmitted via an L2 protocol. The AS scheduling assistance information may be transmitted by RRC (e.g., using UE assistance information), SDAP control PDU, PDCP control PDU, or MAC CE. Transmitting the AS scheduling assistance information by the RRC UE assistance information can be used for stable QoS flows where the ADU parameters remain the same over a long period of time. Transmitting the AS scheduling assistance information by the MAC CE can allow for faster adjustments.

[0056] In some embodiments, the UE 104 can provide the ADU descriptor to the CN 112 through NAS signaling. The ADU descriptor can be signaled to the SMF via a NAS message using a modified existing NAS message or a new NAS message / parameter set. The ADU descriptor can be carried in the NAS assistance information together with other scheduling assistance information related to the QoS flow or PDU session.

[0057] The ADU descriptor provided by the AS scheduling assistance information or NAS message may include typical ADU parameter values ​​associated with a QoS flow, a DRB, or a PDU session. The AN 108 or CN 112 can map / configure appropriate signaling options based on the ADU parameter values. Additionally / alternatively, the signaling options may be predefined by 3GPP TS.

[0058] In some embodiments, in addition to providing the ADU descriptor by the AS scheduling assistance information or NAS message, one or more user data ADU packets may also include an ADU descriptor. Since most ADU parameters may already be known to the AN 108 or CN 112 from AS / NAS signaling, the ADU parameters signaled in the ADU packet may be a delta set of parameters (e.g., an update to a pre-signaled common set). The ADU descriptor received in the packet may be valid only for the current ADU, or may be valid for the current ADU and subsequent ADUs.

[0059] In some embodiments, the ADU header can be included in every packet without transmitting an ADU descriptor. The ADU header can convey at least a minimal set of ADU parameters that provide the most basic information such as the ADU type and the boundaries of the ADU. Various options are described below.

[0060] 5 illustrates the transmission and reception of an ADU packet according to some embodiments. Two ADUs are generated and transmitted in a total of six DUs similar to those described above with respect to FIG. 4. In this embodiment, an ADU header having both common and packet-specific ADU parameters can be added to each DU. For example, the ADU header can include common ADU parameters such as ADU tag, type, and number of packets, and can include packet-specific parameters such as packet number.

[0061] The ADU tag (ADU_tag) may indicate the ADU tag number. The tag number may be an ID common to all packets of an ADU. The ADU tag may be used to identify packets that all belong to the same ADU, or to identify ADU boundaries. In some embodiments, the ADU tag may be considered a small-range sequence number, if desired. ADU sequence numbering may be applicable to scenarios with interdependencies between ADUs.

[0062] The ADU type (ADU_type) may be used to identify the type (e.g., frame type or slice type) or importance of the ADU. The ADU type field may contain a number that may be mapped to a level of importance of the DU. The type field may be an indication of a desired level of protection (e.g., reliability), prioritization, packet dropping, etc. In some embodiments, the ADU type may not be required if the ADU is mapped to different QoS flows.

[0063] Typically, an ADU can be used (or configured to contain) either a frame or a slice. If a distinction between frames and slices is desired, the following options can be used:

[0064] In the first option, an additional parameter (F / S) may be added to the ADU header. The F / S parameter may be a one-bit parameter indicating whether the current header is for a frame or a slice.

[0065] In a second option, the ADU type field may have dedicated values ​​for frames and slices. For example, 0 may correspond to a P frame, 1 may correspond to an I frame, 2 may correspond to a B frame, 3 may correspond to another frame, 4 may correspond to a P slice, 5 may correspond to an I slice, 6 may correspond to a B slice, 7 may correspond to a Switched I (SI) slice, 8 may correspond to a Switched P (SP) slice, 9 may correspond to an Instantaneous Decoding Refresh (IDR) slice, 10 may correspond to a Random Access Intra Picture (IRAP) slice, and 11 may correspond to another slice type. In other embodiments, other values ​​may correspond to other frame or slice types.

[0066] In a third option, the type can indicate a priority or class value, which can be mapped according to higher layer or control configuration.

[0067] The Nof_packets field, sometimes referred to as ADU_window_size, can be used to indicate the total number of DUs in an ADU. If there is no ADU descriptor, this field can be present in all ADU headers. Otherwise, it is sufficient for this field to be present in the ADU descriptor.

[0068] The packet number (packet#) field may indicate the current ADU packet (DU) number, e.g., the i-th packet in the ADU. This field may not be needed if the sender / receiver relies on the PDCP / RLC sequence number (SN) to count packets in a window (e.g., ADU_window_size).

[0069] The presence of the packet number and packet count parameters may allow for a better estimation of when to drop subsequent packets. If an ADU cannot be successfully received due to the loss of more than a certain number of packets, the remaining packets may be dropped. It may be desirable to drop the remaining packets as soon as possible after determining that a successful transmission has not occurred.

[0070] Providing a mix of both common and packet-specific ADU parameters in the ADU header may have a slightly higher signaling overhead compared to using both the ADU descriptor and the ADU header as described above, or compared to using the ADU header in FIG. 6 as described below. However, this embodiment may provide resilience to loss of a packet that includes an ADU descriptor. This embodiment may be used in unacknowledged mode, acknowledged mode, or some other scenario where packet delivery is less certain.

[0071] Figure 6 illustrates the transmission and reception of an ADU packet according to some embodiments. Two ADUs are generated and transmitted in a total of six DUs similar to those described above with respect to Figure 4. The ADU header added to each DU may include both common and packet-specific ADU parameters. Figure 6 provides three options for providing ADU parameters in the ADU header.

[0072] In the first option, the ADU header may include an ADU type and an end marker. The end marker may be a one-bit value to identify if the DU is the last packet of an ADU. The use of the end marker may be based on the assumption that ADU packets are always packetized in order by the sender (upper layer). The receiver can delimit the ADU by observing the end marker bit. This option may be most beneficial in scenarios where the last packet is not lost.

[0073] In the second option, the ADU header may include ADU type and delimiter information. The delimiter information may provide information of the ADU boundary. For example, the delimiter information may be a two-bit value indicating whether the DU contains all bytes of ADU(00), is the first packet of ADU(01), is the last packet of ADU(10), or is neither the first nor the last packet of ADU(11). The two-bit values ​​shown in brackets are some examples. Other combinations may be used. This option may add more protection compared to the first option, because the receiver can still get the start marker or the no start and no end marker even if the end marker is lost, and vice versa.

[0074] In a third option, the ADU header includes the ADU tag, the ADU type, and the delimiter information. Adding the tag may provide some redundancy that results in better reliability of ADU synchronicity.

[0075] Compared with the third option, the second option may consume slightly more time to detect the lost ADU packet or to detect when to drop the rest of the ADU if the lost ADU packet number needs to be retrieved from another layer, and an ADU may be eligible for early drop only if a certain percentage of all ADU packets are lost.

[0076] The three options of this embodiment may provide a relatively small signaling overhead (e.g., up to 2 bits). These options may be suitable for environments where packet loss does not typically occur, such as in transport network links in the core / access network or RAN, when there are relatively stable radio conditions or good error protection. These options may be primarily intended for acknowledged modes, but may also be used with other modes.

[0077] With any of these three options, out-of-sequence packets can be detected by evaluating the existing PDCP / RLC SN, which can imply that the sender (upper layers) submits ADU packets (DUs) in sequence to the lower layers.

[0078] 7 illustrates the transmission and reception of an ADU packet according to some embodiments. Two ADUs are generated and transmitted in a total of six DUs similar to those described above with respect to FIG. 4. The ADU header added to each DU may include both common and packet-specific ADU parameters. In particular, the ADU header may include a continuation flag, a header size extension, and an ADU packet length.

[0079] The ADU header may contain a 1-bit continuation flag. If the continuation flag is set to "1", the data in the DU containing the continuation flag is a continuation of an ADU that was too large to fit in one or more previous DUs; otherwise, the continuation flag is set to "0". For example, for ADU#1, the continuation flag is set to "0" in DU1 and to "1" in DU2, DU3, and DU4. The continuation flag may be combined with one or more other options, or may be used in place of an end marker, for example.

[0080] The header size extension flag may be used to indicate the size of the ADU packet length field among multiple configurable options (according to other L2 layers) or the size of the entire ADU header in bytes. The header size extension flag may be x bits, where x is an integer depending on the maximum DU length that can be configured.

[0081] The ADU packet length may indicate the length of the ADU packet carrying the DU. The length, which may be in bytes, may be conveyed by y bits, where y is an integer.

[0082] The header size extension flag and ADU packet length fields may be useful if the ADU function is located in a separate ADU convergence layer that does not have access to existing DU lengths in, for example, the SDAP or other layers. If the ADU function has access to existing DU lengths in other layers, these fields may not be needed.

[0083] Features of this embodiment may be interchanged with features of other embodiments.

[0084] By providing ADU information in the DU as described above, the ADU convergence layer function creates awareness of the ADU in the RAN or CN, which may enable a recipient to recreate the ADU structure or an intermediate node to efficiently forward the DU carrying the ADU.

[0085] The ADU convergence layer may be configured with an ADU descriptor by receiving a data structure, an Attention (AT) command, or an Application Programming Interface (API) command. The configured ADU descriptor may contain all the information necessary to describe the ADU and may have parameters common to the entire ADU. The ADU descriptor may be associated with an application for a given service or 5QI. Thus, the higher layer will have knowledge of the association of the content and its parameters. The ADU descriptor may be provided to the ADU convergence layer according to one of the following options:

[0086] In the first option, the upper layer can convey the ADU descriptor to the ADU convergence layer as a data structure, which can be a local conveyance.

[0087] In the second option, a standardized API can be defined (e.g., via the at command described in 3GPP TS27.007 v17.3.0 (2021-09-25)) to include all necessary ADU parameters.

[0088] In a third option, the ADU convergence layer may receive the ADU descriptor from the network via RRC signaling or NAS signaling.

[0089] During the packetization process, the ADU convergence layer can derive packet-specific ADU parameters based on the configured ADU descriptor. The ADU convergence layer can then generate ADU information with common or packet-specific ADU parameters as described elsewhere herein, which can be included in the header of the ADU packet.

[0090] The ADU descriptor that the ADU convergence layer signals with the transmission of the ADU (e.g., through the header information of the DU or through AS / NAS signaling) may include some or all of the parameters of the configured ADU descriptor. The configured ADU descriptor may configure the ADU convergence layer for an operation mode. The configuration may come from higher layers via control plane signaling, pre-configuration, or manual configuration, as described above. Having an ADU convergence layer configured with one set of ADU information on one side of the communication does not mean that the entire set of ADU information needs to be conveyed to the other side of the communication. Once configured for operation, the ADU convergence layer can function as a sender or a receiver. For example, a sender may be configured with an ADU descriptor via one of three options. The receiver may not necessarily know the ADU descriptor, and therefore the sender may convey some or all of it to the receiver via signaling. In another variation, all the "intelligence" may be in the network, so that the network commonly configures the ADU descriptor for both sender and receiver. Or, in yet another variation, both ends are configured locally, and all two endpoints need to exchange ADU information for the actual user plane packets sent. In some examples, the ADU descriptor can be an ADU Descriptor Data Structure (a common data structure used in devices or nodes), or an ADU Descriptor Message Part (a message part transmitted as a primitive between layers or as a message between UEs / nodes). Both options represent the same principal information.

[0091] In some embodiments, the ADU descriptor may be mapped to an identifier to facilitate communication of the desired information to other nodes in the network. For example, one or more ADU parameters may be associated with an ADU flow identifier (AFI). The UE 104 or the network may signal all parameters intended to describe the ADU via AS or NAS assistance information similar to that described above with respect to FIG. 4. In this manner, multiple parameter sets may be configured, each parameter set being associated with a respective AFI. The ADU convergence layer may include the AFI in the ADU header of the ADU packet. This may be done instead of including the ADU descriptor or as the only header. The AFI may additionally / alternatively be used to identify the ADU flow as needed (e.g., in a signaling message). The AFI may function as a pointer to the ADU descriptor or the entire ADU parameter set, both in the UE 104 and in the network. In this manner, all desired ADU parameters are available to the appropriate nodes during transmission and can be easily referenced by the appropriate nodes.

[0092] This embodiment may be most advantageous when the ADU parameters are relatively stable, in some embodiments, the AFI may be associated with a stable set of ADU parameters, while more dynamic parameters are conveyed in the ADU header.

[0093] In some embodiments, the ADU descriptor or ADU parameter set may be pre-configured for a given AFI in the network and in the UE 104. Pre-configuration may be achieved by defining various parameter sets and associated AFIs in the 3GPP TS.

[0094] In other embodiments, the parameter set (e.g., the ADU descriptor or the entire ADU parameter set) may be associated with other identifiers. For example, the parameter set may be associated with a Differentiated Services (DiffServ) value or a Flow Label value instead of using the AFI. The parameter set associated with such identifiers may be configured by the AS / NAS as described above or may be predefined in the 3GPP TS.

[0095] In some embodiments, the ADU information may be linked to QoS information, such as 5QI / QFI. A common ADU descriptor may be defined to match the associated traffic characteristics. The common ADU descriptor may be associated with a QoS profile and QoS characteristics along with the 5QI / QFI. This may be achieved by adding parameters of the ADU descriptor to the QoS profile (e.g., QoS characteristics) associated with the 5QI / QFI. In this way, the set of QoS parameters standardized by 3GPP TS23.501 v17.2.0 (2021-09-24), section 5.7, may be extended to include ADU parameters.

[0096] In some embodiments, the QoS profiles associated with operator-specific 5QI / QFIs may be extended by providing additional ADU parameters through NAS signaling.

[0097] Linking ADU parameters to QoS information may be associated with the advantage of not needing to signal ADU parameters (at least those related to standardized or extended 5QI / QFIs), which may also provide the network with the opportunity to build suitable packet filters to modify QoS rules or map to QFI / AFIs, respectively.

[0098] In some embodiments, the AFI may be linked with the QFI / 5QI by defining the AFI as a subfield to the QFI. While this embodiment may be desirable in some situations, extending the parameter set associated with the QFI may be an easier way to implement the linking.

[0099] In some embodiments, the 5QI / QFI may be dynamically updated with ADU specific parameters through NAS signaling. In this embodiment, the UE 104 may utilize a basic set of QoS characteristics associated with the 5QI / QFI and may dynamically add an additional set of ADU parameters. Extending the 5QI / QFI characteristics to include ADU parameters may be an optional feature to be used as needed.

[0100] The aspect of linking ADU information to QoS information may be used in conjunction with other aspects described herein.

[0101] The configured ADU descriptor may be a parameter set that includes one or more of the following ADU parameters: The ADU descriptor of a particular embodiment may include only a portion of the listed parameters.

[0102] Total ADU length (ADU_length) indicating the total number of bytes in the ADU.

[0103] ADU window size (ADU_window_size) indicating the number of packets contained in the ADU. The ADU window size may also be referred to as the number of packets (Nof_packets) in some cases. The ADU window defines the packets associated with the ADU and can be used to reassemble the complete ADU before delivering it to the upper sublayer (unless the reassembly is held up to the upper layer). For example, with respect to FIG. 4, the ADU window size may be equal to four ADU packets for ADU#1 and two ADU packets for ADU#2. The ADU window size may be used by the ADU convergence layer to perform ADU lower layer packet assembly (at the transmitter) and ADU reassembly (at the receiver, to the upper layer), or to deliver a set of separate smaller ADU packets at a time (at the receiver) to the upper layer (when the reassembly function exists in the application layer). The ADU convergence layer may also rely on the ADU window for packet delivery to the upper layer, early dropping, and setting of the ADU header.

[0104] In some cases, the ADU convergence layer can deliver ADU packets to higher sublayers early (e.g., before the ADU window closes) if desired for performance reasons, and if packet dropping is configured, the ADU convergence layer can drop transmission or reception of packets after a threshold number of packets have been processed or based on an event such as a failure.

[0105] ADU threshold (ADU_threshold) (or packet drop preference) that indicates the minimum number of packets required to decode or process an ADU, or the minimum percentage of bytes in an ADU required to decode or process an ADU. If an ADU requires that all ADU packets be successfully received and ordered such that the entire ADU is usable, this parameter is set equal to the value of ADU_window_size or Nof_packets, or 100%. If the node determines that fewer packets than ADU_threshold have been received, the ADU convergence layer may not deliver the ADU to a higher sub-layer or the next top. Alternatively, the ADU convergence layer may have already delivered some packets, but may drop the transmission or reception of the remaining packets. If a node (e.g., UE 104, AN 108, or UPF) receives a subset of ADU packets for an ADU, the scheduler may also use the ADU_threshold parameter to optimize resource allocation or scheduling of packets in its queue. The scheduler can decide when to drop packets early (if packets are aggregated at a node), or drop packets that arrive late (if other packets have already been transmitted), or when to stop triggering retransmissions, etc.

[0106] ADU tag (ADU_tag) indicating the ADU tag number. The tag number may be an ID common to all packets of an ADU. The ADU tag can be used to identify packets that all belong to the same ADU, or to identify ADU boundaries. In some embodiments, the ADU tag can be considered a small range sequence number, if desired. ADU sequence numbering may be applicable to scenarios with interdependencies between ADUs.

[0107] ADU type (ADU_type), which provides information about the importance or class of the ADU as a whole. The ADU type may be similar to those described above with respect to the ADU types included in the ADU header. The ADU type field may indicate, as subfields, frame type, slice type, or slice sequence. The ADU type may provide important information that may be used to select traffic routes and inform scheduling related decisions such as packet prioritization or reliability settings (e.g., when to map traffic to a configuration with high reliability). The AN108 may use the ADU type to map transmission parameters (e.g., DRB, QoS flow, configured grant configuration, PHY configuration, or logical channel prioritization (LCP)) to the appropriate higher or lower reliability / priority.

[0108] Different services may use the ADU container in different ways and may set the ADU type subfield based on higher layer information. For example, if the packets in the ADU belong to an I-frame, the subfield may be set to "frame". However, if the frame is segmented into different slice types (such as IPPP), the subfield may be set to "slice sequence". Whether the ADU concept is frame-based or slice-based should be handled consistently throughout the network, which is also part of the traffic detection in the UPF and UE 104. However, the distinction between frame and slice may not necessarily be essential for the lower sublayers. Some embodiments may preserve this information to higher layers as well.

[0109] Slice_type, which is similar to ADU type, but only for slices.

[0110] Frame_type is similar to ADU type, but for frames only.

[0111] ADU slice group (ADU_slice_group) that provides a slice group ID. All packets belonging to the same slice within an ADU can carry the same slice group ID. The ADU slice group can be combined with an indication of the slice type. For example, slice group 1 may indicate an I slice, slice group 2 may indicate a P slice, and so on. Real-time Transport Control Protocol (RTCP) or other control packets (e.g., Transmission Control Protocol (TCP) acknowledgments) can also be mapped to an ADU or slice group.

[0112] The ADU slice sequence (ADU_slice_sequence) advertises how many slices are included in the ADU (each identified by its own ADU slice group), what their slice types are, and in what order they occur in the ADU. The ADU slice sequence may be, for example, I-slice, P-slice, P-slice, P-slice (IPPP). The ADU slice sequence may be used to map RTCP packets (or other control information) to the ADU and provide higher priority to packets within the ADU. As currently specified for Multimedia Telephony Services or IP Multimedia Services (MTSI) in 3GPP TS 26.114, it may be assumed that one slice fits into one ADU packet (DU). If a slice spans multiple ADU packets, the ADU type may be used instead of the ADU slice sequence, or an additional substructure may be inserted.

[0113] In some embodiments, the ADU descriptor may include additional parameters to specify different QoS requirements for the ADU. Some examples may be as follows: ADU latency class (ADU_delay_budget) to define an upper limit at which an ADU packet may be delayed. ADU reliability class (ADU_error_rate) indicates the transmission requirements (in terms of probability of loss, duplication, missequence, or corruption of DUs) required by the application. ADU priority level (ADU_priority) provides enumerated priority levels for transmitting the ADU. In general, lower priority levels may be associated with higher priorities. ADU packet size provides the size of the ADU packet. ADU transmission rate (distribution) parameter describing the statistical distribution of expected transmission / arrival rates of ADUs or packets contained in the ADU (e.g., Pareto, truncated Gaussian, or fully random, etc.). ADU periodicity defining the period between the start of two bursts. The ADU burst timing provides the latest possible time at which the first packet of a data burst arrives at either the ingress interface of the RAN (in the downlink flow direction) or the egress interface of the UE 104 (in the uplink flow direction). ADU direction (e.g., uplink or downlink). The duration provides the time period an application can last without bursts.

[0114] In some embodiments, at least a subset of the ADU parameters of the ADU descriptor described herein may be used in the transport layer function over the N3 / N9 interface.

[0115] 8 illustrates an operational flow / algorithm structure 800 according to some embodiments. The operational flow / algorithm structure 800 may be implemented by, for example, an ADU convergence layer of a node such as a UE 104 or 1000, a device 142, a network node 1100, or a component thereof, for example, a processing circuit 1004 or 1104.

[0116] The operational flow / algorithm structure 800 may include determining, at 804, that a DU is associated with an ADU. The DU may contain some or all of the data of the ADU. In some embodiments, multiple DUs may be used to convey data for one ADU.

[0117] The operational flow / algorithm structure 800 may further include, at 808, adding ADU information to the DU. The ADU information may indicate one or more parameters associated with the ADU. The parameters may describe the ADU itself and thus may be common to all DUs that carry the data of the ADU. Additionally / alternatively, the parameters may be specific to the DU. For example, the parameters may describe the role of the DU in carrying that portion of the data of the ADU.

[0118] In some embodiments, the common parameters may be referred to as an ADU descriptor that is transmitted in a subset (e.g., one) of the DUs that carry the data of the ADU, and the packet-specific parameters are referred to as an ADU header that is added to each packet. In some embodiments, the ADU header may include a combination of common parameters and packet-specific parameters. Some or all of the common parameters may also be signaled by AS or NAS signaling separately from the DU itself.

[0119] In some embodiments, the ADU information added to the DU (or signaled together with the transmission of the DU) may be based on an ADU descriptor with which the ADU convergence layer is configured. The ADU convergence layer may be configured with the ADU descriptor by an upper layer of the device implementing the ADU convergence layer or by a network node.

[0120] The operational flow / algorithm structure 800 may further include, at 812, transmitting the DU.

[0121] 9 illustrates an operational flow / algorithm structure 900 according to some embodiments. The operational flow / algorithm structure 900 may be implemented by a device such as, for example, the UE 104, the AN 108, the device 142, the UE 1000, the network node 1100, or components thereof, for example, the processing circuit 1104 or 1204.

[0122] The operational flow / algorithm structure 900 may include receiving a DU, at 904. The DU may be an L2 DU that includes some or all of the data of the ADU.

[0123] The operational flow / algorithm structure 900 may further include determining an identifier associated with the DU, at 908. The identifier may be an AFI, a QoS indicator (e.g., 5QI / QFI), a DiffServ value, or a flow label value.

[0124] The operational flow / algorithm structure 900 may further include accessing 912 a set of ADU parameters based on the identifier. In some embodiments, a device implementation in the operational flow / algorithm structure 900 may be configured with an association between a parameter set and an identifier. This configuration may be stored in memory and accessed upon receipt of the identifier. In some embodiments, the identifier is a QoS indicator, and the association between the parameter set and the identifier is stored in a QoS profile defined by a standard or updated by network signaling.

[0125] The operational flow / algorithm structure 900 may further include, at 916, processing the DU based on the set of ADU parameters. In some embodiments, the processing of the DU may be performed by a lower layer of the receiver. In these embodiments, the lower layer may determine whether a sufficient number of DUs of the ADU have been successfully received in time, and if so, provide the DU to a higher layer for further processing. If a sufficient number of DUs have not been successfully received in time, the processing of the DU may include dropping the DU.

[0126] In some embodiments, the processing of the DU may be performed by an intermediate node in the network. In these embodiments, the processing may include determining whether one or more DUs of the ADU are received within a predetermined period of time and coordinating transmission of a group of DUs. In these embodiments, the processing may additionally / alternatively include forwarding the DU using resources consistent with the ADU or signaling characteristics of the DU (e.g., importance, latency constraint, or priority level). In some embodiments, the processing of the DU may include dropping the DU if it is determined that successful transmission of the ADU is no longer possible (e.g., assuming delay or loss of other DUs).

[0127] 10 illustrates a UE 1000 according to some embodiments. The UE 1000 may be similar to and substantially interchangeable with the UE 104 or device 142 of FIG.

[0128] The UE 1000 may be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an XR device, glasses, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, an air pressure sensor, a moisture sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter, or an actuator), a video surveillance / monitoring device (e.g., a camera or a video camera), a wearable device (e.g., a smart watch), or an Internet of Things device.

[0129] The UE 1000 may include a processor 1004, an RF interface circuit 1008, a memory / storage 1012, a user interface 1016, a sensor 1020, a driver circuit 1022, a power management integrated circuit (PMIC) 1024, an antenna structure 1026, and a battery 1028. The components of the UE 1000 may be implemented as an integrated circuit (IC), a portion thereof, a separate electronic device or other module, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 10 is intended to illustrate a high-level view of some of the components of the UE 1000. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0130] The components of the UE 1000 may be coupled to various other components via one or more interconnects 1032, which may represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, optical connection, or the like that allows various circuit components (on a common or different chips or chipsets) to interact with one another.

[0131] The processor 1004 may include processor circuitry such as, for example, a baseband processor circuit (BB) 1004A, a central processing unit circuit (CPU) 1004B, and a graphics processing unit circuit (GPU) 1004C. The processor 1004 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 1012 to cause the UE 1000 to perform the operations described herein.

[0132] In some embodiments, the baseband processor circuit 1004A may access a communications protocol stack 1036 in the memory / storage 1012 to communicate over a 3GPP compliant network. Generally, the baseband processor circuit 1004A may access the communications protocol stack 1036 to perform user plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, SDAP sublayer, and higher layers, and control plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, RRC layer, and NAS layer. In some embodiments, PHY layer operations may additionally / alternatively be performed by components of the RF interface circuit 1008.

[0133] The baseband processor circuit 1004A may generate or process baseband signals or waveforms that carry information in a 3GPP-compliant network. In some embodiments, waveforms for NR may be based on Cyclic Prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Spread OFDM (DFT-S-OFDM) in the uplink.

[0134] The memory / storage 1012 may include one or more non-transitory computer-readable media (e.g., communication protocol stack 1036) that include instructions that may be executed by one or more of the processors 1004 to cause the UE 1000 to perform various operations described herein. The memory / storage 1012 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 1000. In some embodiments, some of the memory / storage 1012 may be located on the processor 1004 itself (e.g., L1 and L2 caches), while other memory / storage 1012 is external to the processor 1004 but accessible via a memory interface. The memory / storage 1012 may include any suitable volatile or non-programmable ROM, such as, but not limited to, volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory, or any other type of memory device technology.

[0135] The RF interface circuitry 1008 may include transceiver circuitry and a radio frequency front end module (RFEM) that enables the UE 1000 to communicate with other devices over a radio access network. The RF interface circuitry 1008 may include various elements disposed in the transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, combiner circuits, and control circuits.

[0136] In the receive path, the RFEM may receive radiated signals from the air interface via the antenna structure 1026 and filter and amplify the signals (using a low noise amplifier). The signals may be provided to a transceiver receiver that downconverts the RF signals to baseband signals that are provided to a baseband processor in the processor 1004.

[0137] In the transmit path, the transmitter of the transceiver upconverts the baseband signal received from the baseband processor and provides an RF signal to the RFEM, which may amplify the RF signal through a power amplifier before the signal is radiated over the air interface via the antenna 1026.

[0138] In various embodiments, the RF interface circuitry 1008 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0139] The antenna 1026 may include antenna elements that convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. The antenna elements may be arranged in one or more antenna panels. The antenna 1026 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple-input multiple-output communication. The antenna 1026 may include microstrip antennas, printed antennas assembled on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. The antenna 1026 may have one or more panels designed for a particular frequency band, including the FR1 or FR2 bands.

[0140] The user interface circuitry 1016 includes various input / output (I / O) devices designed to enable user interaction with the UE 1000. The user interface 1016 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual means for accepting input, including, among others, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, a headset, etc. The output device circuitry includes any physical or virtual means for displaying or otherwise communicating information, such as a sensor reading, an actuator position(s), or other similar information. The output device circuitry may include any number or combination of audio or visual displays, including, among others, one or more simple visual outputs / indicators (e.g., binary status indicators such as light emitting diodes (LEDs) and multi-character visual outputs), or more complex outputs such as display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, and projectors), where output of characters, graphics, multimedia objects, and the like are generated or created from operation of the UE1000.

[0141] The sensors 1020 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and transmit information about the detected events (sensor data) to some other devices, modules, or subsystems. Examples of such sensors include inertial measurement units with accelerometers, gyroscopes, or magnetometers; microelectromechanical or nanoelectromechanical systems with 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless apertures); light detection and ranging sensors, proximity sensors (e.g., infrared detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers, and microphones or other similar audio capture devices.

[0142] The driver circuit 1022 may include software and hardware elements that operate to control specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 1000. The driver circuit 1022 may include individual drivers that allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the UE 1000. For example, the driver circuit 1022 may include a display driver that controls and enables access to a display device, a touchscreen driver that controls and enables access to a touchscreen interface, a sensor driver that obtains sensor readings of the sensor circuit 1020 and controls and enables access to the sensor circuit 1020, a driver that obtains actuator positions of electromechanical components or controls and enables access to electromechanical components, a camera driver that controls and enables access to an embedded image capture device, an audio driver that controls and enables access to one or more audio devices.

[0143] The PMIC 1024 may manage the power provided to various components of the UE 1000. In particular, with respect to the processor 1004, the PMIC 1024 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0144] In some embodiments, the PMIC 1024 may control, or otherwise be a part of, various power saving mechanisms of the UE 1000, including DRX as discussed herein.

[0145] The battery 1028 may power the UE 1000, although in some examples the UE 1000 may be mounted and deployed at a fixed location and may have a power source coupled to a power grid. The battery 1028 may be a lithium ion battery, a metal air battery such as a zinc air battery, an aluminum air battery, a lithium air battery, etc. In some implementations, such as vehicle-based applications, the battery 1028 may be a typical automotive lead acid battery.

[0146] 11 illustrates a network node 1100 according to some embodiments. The network node 1100 may be similar to and substantially interchangeable with the access node 108, the device 142, or the CN 112 of FIG.

[0147] The network node 1100 may include a processor 1104, RF interface circuitry 1108 (if implemented as an access node), core network (CN) interface circuitry 1112, memory / storage circuitry 1116, and an antenna structure 1126 (if implemented as an access node).

[0148] The components of network node 1100 may be coupled to various other components via one or more interconnects 1128.

[0149] The processor 1104, RF interface circuitry 1108, memory / storage circuitry 1116 (including communications protocol stack 1110), antenna structure 1126, and interconnect 1128 may be similar to similarly named elements shown and described with respect to Figure 10. If the network node 1100 is implemented as an access node, the communications protocol stack 1110 may include an access stratum layer. If the network node 1100 is implemented as a device in a core network, e.g., as a UPF or SMF, the communications protocol stack 1110 may include a NAS layer.

[0150] The CN interface circuitry 1112 can provide connectivity to a core network, e.g., a fifth generation network interface (5GC), using a 5GC-compatible core network protocol, such as the Carrier Ethernet protocol, or some other suitable protocol. Network connectivity can be provided to / from the network node 1100 via optical fiber or wireless backhaul. The CN interface circuitry 1112 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 1112 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0151] In some embodiments, the network node 1100 may be coupled to a transmission receiving point (TRP) using an antenna structure 1126, a CN interface circuit, or other interface circuit.

[0152] It is understood that use of personally identifiable information should comply with privacy policies and practices generally recognized as meeting or exceeding industry or governmental requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of permitted uses should be clearly indicated to users.

[0153] For one or more embodiments, at least one of the components described in one or more of the preceding figures may be configured to perform one or more of the operations, techniques, processes, or methods as described in the example section below. For example, the baseband circuitry described above in connection with one or more of the preceding figures may be configured to operate according to one or more of the examples described below. As another example, the circuitry associated with a UE, base station, or network element as described above in connection with one or more of the preceding figures may be configured to operate according to one or more of the examples described below in the Example section. Working Example

[0154] Further exemplary embodiments are provided in the following sections.

[0155] Example 1 includes a method of operating a user equipment (UE), the method including determining that a data unit (DU) is associated with an application data unit (ADU), adding ADU information to the DU to indicate one or more parameters associated with the ADU, and transmitting the DU.

[0156] Example 2 includes the method of example 1 or any other example herein, where the ADU information includes an ADU descriptor.

[0157] Example 3 includes the method of Example 2 or any other example herein, and further includes determining that a plurality of DUs including the DU are associated with the ADU, generating an ADU descriptor to indicate one or more parameters that are common to the plurality of DUs, and adding the ADU descriptor to only the DU of the plurality of DUs.

[0158] Example 4 includes the method of Example 3 or any other example herein, where the DU is a first DU, and the method further includes adding a first ADU header to the first DU, the first ADU header including ADU parameters specific to the first DU of the multiple DUs, and adding a second ADU header to the second DU, the second ADU header including ADU parameters specific to the second DU of the multiple DUs.

[0159] Example 5 includes the method of Example 1 or any other example herein, wherein the DU is a first DU of multiple DUs associated with the ADU, the ADU information is an ADU header, and the one or more parameters include an ADU parameter specific to the first DU, and the method further includes transmitting an ADU descriptor including at least one ADU parameter common to the multiple DUs via access stratum, transport network, or non-access stratum signaling.

[0160] Example 6 includes the method of example 5 or any other example herein, wherein the ADU descriptor is a first ADU descriptor and the ADU information includes a second ADU descriptor having an update to at least one ADU parameter of the first ADU descriptor.

[0161] Example 7 includes the method of example 1 or any other example herein, wherein the ADU information is an ADU header including a tag number that identifies the ADU within a sequence of ADUs, a type value that identifies a type or level of importance of the ADU, a packet number that indicates the position of the DU within a sequence of multiple DUs in the ADU, or an ADU size that indicates the total number of DUs in the ADU.

[0162] Example 8 includes the method of example 7 or any other example herein, wherein the ADU header includes a type value to identify the ADU as a frame or slice, to identify the ADU as a type of frame or slice, or to identify the ADU as associated with a priority or class value.

[0163] Example 9 includes the method of example 1 or any other example herein, wherein the DU is a first DU and the ADU information is a first ADU header, and the method further includes determining that a second DU is associated with the ADU and adding a second ADU header to the second ADU.

[0164] Example 10 includes the method of example 1 or any other example herein, and the ADU information includes an ADU header including a type value to identify the type or level of importance of the ADU, an end marker to indicate that the DU is the last packet of the ADU, a 2-bit delimiter value to indicate that the DU contains all bytes of the ADU, is the first packet of the ADU, is the last packet of the ADU, or is neither the first packet nor the last packet of the ADU, or a tag number to identify the ADU in a sequence of ADUs.

[0165] Example 11 includes the method of example 1 or any other example herein, wherein the ADU information includes a continuation flag to indicate that data of the DU is combined with data from one or more DUs of an ADU preceding the DU in the sequence, a header size extension to indicate the size of the ADU packet length field of the ADU header or the size of the ADU header, or an ADU packet length field to indicate the length of the DU.

[0166] Example 12 includes the method of example 1 or any other example herein, further including implementing an ADU convergence layer to perform the determining and adding.

[0167] Example 13 includes the method of Example 12 or any other example herein, and further includes receiving, by the ADU convergence layer, an ADU descriptor, and determining, based on the ADU descriptor, that the DU is associated with the ADU.

[0168] Example 14 includes the method of Example 13 or any other example herein, and further includes receiving the ADU descriptor as a data structure, an attention (AT) command, or an application programming interface (API) command from another layer of the UE or from a network node.

[0169] Example 15 includes the method of Example 13 or any other example herein, further including receiving the ADU descriptor from the network node via radio resource control (RRC) signaling or non-access stratum (NAS) signaling.

[0170] Example 16 includes a method of operating a device, the method including receiving a data unit (DU) including application data unit (ADU) data, determining an identifier associated with the DU, accessing a set of ADU parameters based on the identifier, and processing the DU based on the set of ADU parameters.

[0171] Example 17 includes the method of example 16 or any other example herein, wherein the DU has a header including an identifier, the identifier being an application data unit (ADU) flow identifier (AFI).

[0172] Example 18 includes the method of example 16 or any other example herein, further including receiving the set of ADU parameters via access stratum or non-access stratum signaling.

[0173] Example 19 includes the method of example 16 or any other example herein, wherein the set of ADU parameters is pre-configured in the device.

[0174] Example 20 includes the method of example 16 or any other example herein, wherein the DU is part of a flow, and the method further includes determining the identifier based on a Differentiated Services (DiffServ) value or a flow label value associated with the flow.

[0175] Example 21 includes the method of Example 16 or any other example herein, wherein the DU is part of a flow, the identifier is a Quality of Service (QoS) indicator that identifies a QoS profile corresponding to the flow, and the set of ADU parameters is included in the QoS profile.

[0176] Example 22 includes the method of example 21 or any other example herein, further including receiving non-access stratum (NAS) signaling to update the QoS profile to include the set of ADU parameters.

[0177] Example 23 includes receiving information for constructing an application data unit (ADU) descriptor corresponding to an ADU of a data burst, generating ADU information based on the ADU descriptor, adding the ADU information to a header of a DU having data of the ADU, and transmitting the DU together with the header.

[0178] Example 24 includes the method of example 23 or any other example herein, wherein the ADU descriptor includes an ADU type indicating an importance or class of the ADU.

[0179] Example 25 includes the method of example 24 or any other example herein, wherein the ADU type indicates a frame type, a slice type, or a slice sequence of the ADU.

[0180] Example 26 includes the method of example 23 or any other example herein, wherein the ADU descriptor includes a slice group identifier of the ADU.

[0181] Example 27 includes the method of example 23 or any other example herein, wherein the ADU descriptor includes a latency class, a reliability class, or a priority level of the ADU.

[0182] Example 28 includes the method of example 23 or any other example herein, wherein the ADU descriptor includes a maximum packet size or transmission rate for a DU of the ADU.

[0183] Example 29 includes the method of Example 23 or any other example herein, wherein the ADU descriptor includes a periodicity defining a period between the start of two data bursts, a burst timing providing a latest possible arrival time of a first packet of a data burst, or a duration providing a period during which an application may survive without receiving a data burst.

[0184] Example 30 may include an apparatus comprising means for performing one or more elements of the method described or related to any of Examples 1-29, or any other method or process described herein.

[0185] Example 31 may include one or more non-transitory computer-readable media containing instructions that, upon execution by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any of Examples 1-29, or any other method or process described herein.

[0186] Example 32 may include an apparatus having logic, modules, or circuitry for performing one or more elements of the method described or related to any of Examples 1-29, or any other method or process described herein.

[0187] Example 33 may include any method, technique, or process described or related to any of Examples 1-29, or any part or portion thereof.

[0188] Example 34 may include an apparatus having one or more processors and one or more computer-readable media having instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described or related to any of Examples 1-29, or portions thereof.

[0189] Example 35 may include a signal described or related to any of Examples 1-29, or a portion or part thereof.

[0190] Example 36 may include a datagram, information element, packet, frame, segment, PDU, or message described or related to any of Examples 1-29, or a portion or part thereof, or others described in this disclosure.

[0191] Example 37 may include a signal encoded with data described or related to any of Examples 1-29, or a portion or part thereof, or any other signal described in this disclosure.

[0192] Example 38 may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message described or related to any of Examples 1-29, or a portion or part thereof, or a signal described otherwise in this disclosure.

[0193] Example 39 may include an electromagnetic signal carrying a plurality of computer-readable instructions, where execution of the plurality of computer-readable instructions by one or more processors causes the one or more processors to perform a method, technique, or process described in or related to any of Examples 1-29 or portions thereof.

[0194] Example 40 may include a computer program including instructions, the execution of which by a processing element causes the processing element to perform a method, technique, or process described in or related to any of Examples 1-29, or a portion thereof.

[0195] Example 41 may include a signal in a wireless network as shown and described herein.

[0196] Example 42 may include a method of communicating in a wireless network as shown and described herein.

[0197] Example 43 may include a system for providing wireless communication as shown and described herein.

[0198] Example 44 may include a device for providing wireless communication as shown and described herein.

[0199] Any of the above examples may be combined with any other example (or combination of examples) unless otherwise stated. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0200] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated, and it is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1. One or more computer-readable media having instructions that, when executed by one or more processors, cause a user equipment (UE) to: determining that a data unit (DU) is associated with an application data unit (ADU); adding ADU information to the DU to indicate one or more parameters associated with the ADU; One or more computer-readable media for transmitting the DU.

2. The ADU information includes an ADU descriptor, and the instructions, when executed, cause the UE to further: determining that a plurality of DUs including the DU are associated with the ADU; generating the ADU descriptor to indicate the one or more parameters that are common to the plurality of DUs; The one or more computer-readable media of claim 1 , further comprising: causing the ADU descriptor to be added to only the DU of the plurality of DUs.

3. The DU is a first DU, and the instructions, when executed, further cause the UE to: adding a first ADU header to the first DU, the first ADU header being for including ADU parameters specific to the first DU of the plurality of DUs; 3. The one or more computer-readable media of claim 2, further comprising: adding a second ADU header to a second DU, the second ADU header being for including ADU parameters specific to the second DU of the plurality of DUs.

4. The DU is a first DU of a plurality of DUs associated with the ADU, the ADU information is an ADU header, the one or more parameters include an ADU parameter specific to the first DU, and the instructions, when executed, further cause the UE to:

10. The one or more computer-readable media of claim 1, further comprising: transmitting an ADU descriptor including at least one ADU parameter common to the plurality of DUs via access stratum, transport network, or non-access stratum signaling.

5. 2. The one or more computer-readable media of claim 1, wherein the ADU information is an ADU header including a tag number that identifies the ADU within a sequence of ADUs, a type value that identifies the type or level of importance of the ADU, a packet number that indicates the position of the DU within a sequence of multiple DUs of the ADU, or an ADU size that indicates the total number of DUs of the ADU.

6. The DU is a first DU, the ADU information is a first ADU header, and the instructions, when executed, further cause the UE to: determining that a second DU is associated with the ADU; The one or more computer-readable media of claim 1 , further comprising: adding a second ADU header to the second DU.

7. 2. The one or more computer-readable media of claim 1, wherein the ADU information is an ADU header including a type value to identify the type or level of importance of the ADU, an end marker to indicate that the DU is the last packet of the ADU, a 2-bit delimiter value to indicate that the DU contains all bytes of the ADU, is the first packet of the ADU, is the last packet of the ADU, or is neither the first nor the last packet of the ADU, or a tag number to identify the ADU in a sequence of ADUs.

8. 2. The one or more computer-readable media of claim 1, wherein the ADU information is an ADU header including a continuation flag to indicate that data of the DU is combined with data from one or more DUs preceding the ADU in a sequence, a header size extension to indicate the size of an ADU packet length field of the ADU header or a size of the ADU header, or an ADU packet length field to indicate the length of the DU.

9. The instructions, when executed, further cause the UE to: Implementing the ADU convergence layer, determining that the DU is associated with the ADU; adding the ADU information to the DU; The one or more computer-readable media of claim 1 , further comprising: receiving an ADU descriptor; and determining that the DU is associated with the ADU based on the ADU descriptor.

10. 10. The one or more computer-readable media of claim 9, wherein the ADU convergence layer is for receiving the ADU descriptor from another layer of the UE or from a network node as a data structure, an attention (AT) command, or an application programming interface (API) command.

11. 10. The one or more computer-readable media of claim 9, wherein the ADU convergence layer is for receiving the ADU descriptor from a network node via Radio Resource Control (RRC) signaling or Non-Access Stratum (NAS) signaling.

12. 1. A method of operating a device, the method comprising: receiving a data unit (DU) including data of an application data unit (ADU); determining an identifier associated with the DU; accessing a set of ADU parameters based on the identifier; and processing the DU based on the set of ADU parameters.

13. The method of claim 12, wherein the DU has a header that includes the identifier, the identifier being an Application Data Unit (ADU) Flow Identifier (AFI).

14. receiving the set of ADU parameters via access stratum or non-access stratum signaling; or The method of claim 12 , further comprising determining the set of ADU parameters based on preconfigured information at the device.

15. The DU is part of a flow, and the method comprises: The method of claim 12 , further comprising determining the identifier based on a Differentiated Services (DiffServ) value or a flow label value associated with the flow.

16. The DU is part of a flow, the identifier is a Quality of Service (QoS) indicator that identifies a QoS profile corresponding to the flow, and the set of ADU parameters is included in the QoS profile, and the method comprises:

13. The method of claim 12, further comprising receiving Non-Access Stratum (NAS) signaling to update the QoS profile to include the set of ADU parameters.

17. An apparatus comprising: A radio frequency (RF) interface; a processing circuit coupled to the RF interface, the processing circuit comprising: receiving information for constructing application data units (ADU) descriptors corresponding to ADUs of the data burst; Generate ADU information based on the ADU descriptor; Adding the ADU information to a header of a DU having data of the ADU; An apparatus for transmitting the DU together with the header over the RF interface.

18. The apparatus of claim 17 , wherein the ADU descriptor includes an ADU type to indicate a frame type, a slice type, or a slice sequence of the ADU.

19. The apparatus of claim 17 , wherein the ADU descriptor comprises a slice group identifier, a latency class, a reliability class, a priority level, a maximum packet size, or a transmission rate of a DU of the ADU.

20. 18. The apparatus of claim 17, wherein the ADU descriptor includes a periodicity to define a time period between the start of two data bursts, a burst timing to provide a latest possible arrival time of a first packet of the data burst, or a duration to provide a time period an application may survive without receiving a data burst.

Images