Application awareness in radio access networks

Abstract

APPLICATION AWARENESS IN RADIO ACCESS NETWORKS Various aspects of the present disclosure relate to application awareness in radio access networks. A data packet of an application data flow is obtained at a first protocol layer. The data packet includes a payload associated with a data unit of an application and metadata including one or more attributes of the data unit. An identification operation is performed to identify, from the data packet, the metadata and the data unit. A protocol header including information associated with the data unit is generated based on the identified metadata. A protocol data unit including the protocol header and the payload of the data packet is generated and output to a second protocol layer for transmission to a receiving entity. The receiving entity may obtain the PDU, identify the data unit and the metadata based on the protocol header of the PDU, and accordingly, output a response.

Description

APPLICATION AWARENESS IN RADIO ACCESS NETWORKSTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to application awareness in radio access networks.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilising resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

[0003] 5G radio access technology generally follows an information-agnostic design principle, in which neither the content of incoming data packets nor their attributes (such as importance, aging information, or dependencies) are taken into account for radio resource allocation (e.g., for uplink (UL) radio resource allocation). For example, a UE may simply select the next packet data unit (PDU) in the transmission buffer for transmission (i.e., the selection is performed in an information-agnostic manner, without prioritising the transmission of PDUs based on importance).

[0004] For radio access technologies beyond 5G (e.g., 6G), it would be desirable for application awareness to be natively supported in the RAN, to help the network utilise the resources more efficiently and improve the quality of experience (QoE) and / or the quality of control (QoC) (e.g., by prioritising more important packets for the application).SUMMARY

[0005] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be constmed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0006] Some implementations of the method and apparatuses described herein may include, in a first aspect: obtaining, at a first protocol layer, a data packet of an application data flow, wherein the data packet comprises a payload associated with a data unit of an application and metadata including one or more attributes of the data unit; performing an identification operation to identify, from the data packet, the metadata and the data unit; generating, based on the identified metadata, a protocol header comprising information associated with the data unit; generating a protocol data unit “PDU” comprising the protocol header and the pay load of the data packet; and outputting the PDU to a second protocol layer for transmission to a receiving entity. The metadata may be prepared by a layer higher than the first protocol layer. The one or more attributes of the data unit may include one or more application-specific attributes. The protocol header may include other information not associated with the data unit. In one example, the data packet may be a service data unit (SDU) of a layer (e.g., the Packet Data Convergence Protocol “PDCP” layer), wherein the SDU (e.g., PDCP SDU) represents only a segment of the data unit.

[0007] In some implementations of the method and apparatuses described herein, in the first aspect, the identification operation includes identifying the metadata from the datapacket, and identifying the data unit with which the payload of the data packet is associated based on the identified metadata.

[0008] In some implementations of the method and apparatuses described herein, in the first aspect, the identification of the metadata is based on one or more identification rules, which may be obtained from a network entity, such as a session management function node “SMF”.

[0009] In some implementations of the method and apparatuses described herein, in the first aspect, the generation of the protocol header comprises mapping one or more attributes contained in the metadata to one or more corresponding fields in the protocol header. The mapping can be considered as data formatting procedure. As an example, an importance level of the data unit in the metadata may be translated to a priority level (which can also be considered as an importance level) in the protocol header. The protocol header can contain other information not mapped from the metadata. The mapping may be performed based on one or more mapping rules, which may be obtained from a network entity, such as a session management function node “SMF”. The one or more mapping rules may, for example, include information on how the data packet should be parsed to identify the metadata or specific attribute(s) contained in the metadata.

[0010] In some implementations of the method and apparatuses described herein, in the first aspect, the one or more attributes of the data unit is associated with a context of the application. The one or more attributes may include, e.g., importance of the data unit to the application and / or dependency of the data unit on one or more other data units for the application.

[0011] In some implementations of the method and apparatuses described herein, in the first aspect, the protocol header comprises sequence number of the data unit, size of the data unit, an end PDU of the data unit, sequence number of the PDU, importance of the data unit to the application, type of the data unit, dependency of the data unit on one or more other data units for the application, or any combination thereof. The protocol header may further comprise one or more of: inter-media component synchronisation threshold, application-layer forward error correction related information, timestamp information, codec related information, burst related information, or any combination thereof.

[0012] In some implementations of the method and apparatuses described herein, the first aspect includes assigning a transmission priority to the PDU, and outputting the transmission priority to the second protocol layer. The transmission priority affects a priority for transmitting the PDU to the receiving entity. The transmission priority may be provided to the second protocol layer separately from the PDU.

[0013] In some implementations of the method and apparatuses described herein, the first aspect includes discarding a PDU and / or the associated data unit (associated with the PDU) based on: importance of the corresponding PDU or the associated data unit, remaining delay associated with the corresponding PDU or the associated data unit, linear or quadratic cost associated with the corresponding PDU or the associated data unit, mean square error associated with the corresponding PDU or the associated data unit, energy consumption-related parameter associated with the corresponding PDU or the associated data unit, dependency information associated with the corresponding PDU or the associated data unit, or any combination thereof. The discarded PDU may not be output to the second protocol layer or otherwise will not be transmitted to the receiving entity.

[0014] In some implementations of the method and apparatuses described herein, in the first aspect, the first protocol layer is a Packet Data Convergence Protocol “PDCP” layer with application awareness, and the second protocol layer is a layer below the PDCP layer.

[0015] In some implementations of the method and apparatuses described herein, in the first aspect, the first protocol layer is a layer with application awareness and is above a Packet Data Convergence Protocol “PDCP” layer, and the second protocol layer is a layer below the first protocol layer (e.g., the PDCP layer).

[0016] In some implementations of the method and apparatuses described herein, the first aspect includes, in response to outputting the PDU for transmission, receiving a response from the receiving entity. The response may include a status report that includes an acknowledgement of successful reception of the PDU or the data unit by the receiving entity, a request for re-transmission of the PDU or the data packet, and / or a request for transmission of a (e.g., a specific) data unit.

[0017] In some implementations of the method and apparatuses described herein, in the first aspect, the data unit comprises payload of one or more data packets, including the pay load of the data packet.

[0018] In some implementations of the method and apparatuses described herein, operations in the first aspect may be performed by a user equipment “UE”.

[0019] In some implementations of the method and apparatuses described herein, operations in the first aspect may be performed by a network equipment “NE”.

[0020] In some implementations of the method and apparatuses described herein, in the first aspect, the receiving entity is a user equipment “UE”

[0021] In some implementations of the method and apparatuses described herein, in the first aspect, the receiving entity is a network equipment “NE”.

[0022] Some implementations of the method and apparatuses described herein may include, in a second aspect: obtaining, at a first protocol layer, a protocol data unit “PDU”, wherein the PDU comprises a payload of a data packet associated with a data unit and a protocol header including information associated with the data unit; performing an identification operation to identify, based on the protocol header, the data unit and metadata comprising one or more attributes of the data unit; and outputting, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

[0023] In some implementations of the method and apparatuses described herein, in the second aspect, the response comprises: a status report that includes an acknowledgement of successful reception of the PDU or the data unit, a request for re-transmission of the PDU or the data packet, and / or a request for transmission of a (e.g., a specific) data unit.

[0024] In some implementations of the method and apparatuses described herein, the second aspect includes providing the pay load of the PDU to a second protocol layer for processing based on importance and / or delay criticality of the PDU and / or the data unit.

[0025] In some implementations of the method and apparatuses described herein, operations in the second aspect may be performed by a user equipment “UE”.

[0026] In some implementations of the method and apparatuses described herein, operations in the second aspect may be performed by a network equipment “NE”.

[0027] In some implementations of the method and apparatuses described herein, in the second aspect, the transmission entity is a user equipment “UE”.

[0028] In some implementations of the method and apparatuses described herein, in the second aspect, the transmission entity is a network equipment “NE”.

[0029] As used herein, a “data unit (DU)” refers to a piece of information that cannot be further fragmented without losing its context. As used herein, “context” may refer to a task (e.g., change actuator state within provided delay budget constraints), a sub-task, or a group of tasks to be executed by an application (e.g., control and time-sensitive application), or to the contextual content (e.g., video, audio, haptic, sensor data) associated with an application, i.e., the content parts immediately preceding or following a content object, i.e., a DU, (e.g., video frame / slice, audio utterance, haptic trigger / actuation, sensor samples / values). In other words, a DU can be considered as a representation of an application quantity transmitted / for transmission from a source application to one or more receiving applications, and the DU cannot be divided further into smaller chunks before being processed and used on the receiving end of the application. A DU may be provided by one or more data packets (the associated payload) hence one or more PDUs.

[0030] Other features and aspects will become apparent by consideration of the detailed description and accompanying drawings. Any feature(s) described herein may be combined with any other feature(s) described herein, where appropriate and / or applicable.BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0032] Figure 2 illustrates an example 5G system QoS framework with legacy handling of QoS for each PDU within a QoS flow in accordance with aspects of the present disclosure.

[0033] Figure 3 illustrates an example core network (CN) extended reality media (XRM) architecture and the handling of PDU Sets in accordance with aspects of the present disclosure.

[0034] Figure 4A illustrates an example 1 -byte real-time protocol (RTP) header extension for PDU Set marking by the application server as per the 3rd generation partnership project (3GPP) technical specification (TS) 26.522 (vO.1.1 - Sep 2023) in accordance with aspects of the present disclosure.

[0035] Figure 4B illustrates an example 2-byte RTP header extension for PDU Set marking by the application server as per the 3GPP TS 26.522 (vO.1.1 - Sep 2023) in accordance with aspects of the present disclosure.

[0036] Figure 5 illustrates an example of using QUIC to add PDU Set information within HTTP datagrams in accordance with aspects of the present disclosure.

[0037] Figure 6 illustrates an example implementation of a user plane (UP) protocol stack in a transmitting entity and in a receiving entity in accordance with aspects of the present disclosure.

[0038] Figure 7 illustrates an example PDCP layer with application awareness in accordance with aspects of the present disclosure.

[0039] Figure 8 illustrates an example UP protocol stack in accordance with aspects of the present disclosure.

[0040] Figure 9 illustrates an example implementation of the UP protocol stack of Figure 8 in a transmitting entity and in a receiving entity in accordance with aspects of the present disclosure.

[0041] Figure 10 illustrates an example UP protocol stack in accordance with aspects of the present disclosure.

[0042] Figure 11 A illustrates an example packet data convergence protocol (PDCP) and radio link control (RLC) reception in accordance with aspects of the present disclosure.

[0043] Figure 1 IB illustrates an example PDCP and RLC reception after t-Reordering expiry in accordance with aspects of the present disclosure.

[0044] Figure 12 illustrates an example implementation of a UP protocol stack in a transmitting entity and in a receiving entity in accordance with aspects of the present disclosure.

[0045] Figure 13 illustrates an example implementation of a UP protocol stack in accordance with aspects of the present disclosure.

[0046] Figure 14 illustrates an example data flow across protocol layers in a UP protocol stack in accordance with aspects of the present disclosure.

[0047] Figure 15 illustrates an example operation for generating a feedback or status report in accordance with aspects of the present disclosure.

[0048] Figure 16 illustrates an example of a user equipment (UE) in accordance with aspects of the present disclosure.

[0049] Figure 17 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0050] Figure 18 illustrates an example of a network equipment (NE) in accordance with aspects of the present disclosure.

[0051] Figure 19 illustrates a flowchart of a method performed by an apparatus for wireless communication in accordance with aspects of the present disclosure.

[0052] Figure 20 illustrates a flowchart of a method performed by an apparatus for wireless communication in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0053] In order for radio access technologies beyond 5G (e.g., 6G) to achieve better (e.g., full) convergence of communication and control, it would be necessarily to provide specific, new end-to-end system architecture and protocol.

[0054] To this end, some implementations of the method and apparatuses described herein provide a new signalling procedure to enable the Access Stratum of RAN to achieveapplication awareness. In some implementations of the method and apparatuses described herein, a new Layer 2 protocol layer is introduced to enable the identification of (application) data units and their corresponding attributes. Thus, the new Layer 2 protocol layer has application awareness. The application awareness empowers the Layer 2 protocols to utilise the radio resources more efficiently by considering the importance of a PDU from an application perspective, e.g., to perform discarding, prioritisation / routing, and / or reordering based on the importance / context of a PDU for the application.

[0055] Some implementations of the method and apparatuses described herein provide a new L2 protocol layer in the L2 user plane protocol stack. The new L2 protocol layer provides various functions allowing the RAN to utilise the limited radio resources more efficiently and improve the QoE and / or the QoC by considering the content of a data packet / protocol data unit (PDU) / data unit and the attributes associated with the data packet / protocol data unit (PDU) / data unit. The new L2 protocol layer is operable to receive and identify (application) data units and their corresponding attributes. In one example, the identification of data units is performed based on metadata provided to the new L2 protocol layer. The new L2 protocol layer may be a layer added to an existing L2 protocol stack or may be a modified layer in an existing L2 protocol stack. Some implementations of the method and apparatuses described herein provide a protocol header for the new L2 protocol layer. For example, a protocol header is added to the incoming data packets, e.g., IP packets arriving at the new L2 protocol layer (e.g., application awareness layer (AAL)), and outgoing data (e.g., AAL PDU) is generated and outputted. A function within the new L2 protocol layer may map the identified encapsulated metadata received in user plane at L2 ingest reference point on the uplink (UL) to the outgoing protocol header. In one example, each AAL PDU contains all necessary information to enable the receiving entity (e.g., receiving AAL entity) to identify the data unit and its corresponding attribute(s). Some implementations of the method and apparatuses described herein provide a PDCP layer (of the user plane Access Stratum (AS) protocol stack) that supports application awareness related functionalities. For example, the PDCP layer supports the identification of data units and their corresponding attributes (e.g., importance, dependency information, etc.).

[0056] Aspects of the present disclosure are described in the context of a wireless communications system.

[0057] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0058] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0059] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one ormultiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0060] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of- Things (loT) device, an Intemet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0061] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0062] An NE 102 may support communications with the CN 106, or with another NE102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0063] The CN 106 may support user authentication, access authorisation, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0064] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0065] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0066] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilise one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0067] A time interval of a resource (e.g., a communication resource) may be organised according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0068] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organised according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / r=0, jU=l , / r=2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilise a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0069] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0070] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0071] The existing 3 GPP QoS framework is designed to support different types of services considering their traffic characteristics and QoS requirements. Figure 2 illustrates an example QoS handling in a 5G network. Referring to Figure 2, the 3GPP QoS is defined at QoS flow level, where each QoS flow supports specific QoS characteristics (e.g., latency, priority, reliability). Each packet, or equivalently, protocol data unit (PDU), from anapplication that needs to be handled using specific QoS characteristics is routed via a specific QoS flow that is marked by a QoS Flow Identifier (QFI). Each of the QoS flows is mapped to a respective radio bearer (e.g., data radio bearer (DRB)) over the RAN which supports the QoS characteristics defined for the QoS flow per PDU basis. Thus, each PDU is prioritised at the core network (CN) and RAN according to the QoS characteristics of the QoS flow.

[0072] As illustrated, the QoS flow is the finest granularity of QoS differentiation in a PDU session. The QoS flow may either be of guaranteed bit rate (GBR) type or a non-GBR type. Each QoS flow is associated with specific QoS parameters that characterise the service it demands from the 5G System (5GS). These QoS parameters can be in the form of maximum packet loss rate, packet delay budget between a UE and user plane function (UPF), guaranteed bit rate, maximum bit rate, etc. The specifications also support parameters applicable to industrial applications, such as nominal message size, transfer interval, survival time, maximum end-to-end latency, etc. Each packet that belongs to a QoS flow is characterised by a single QoS parameter set, and hence is treated equally by the 5G user plane protocol stack. This equal treatment may not be optimal from an application perspective.

[0073] For applications and services in the domain of extended reality (XR), multimedia flows are multiplexed under a single network application session (i.e., a 5-tuple containing a source IP address, a destination IP address, a source network port, a destination network port, and a protocol number as identifier). As an example, an XR application based on WebRTC or on real-time protocol (RTP) / secure real-time protocol (SRTP) protocol stack, may contain one or more multiple video streams and audio streams multiplexed with control and feedback metadata and application metadata (e.g., such as user pose information, user input actions, etc.) over a single application data network session.

[0074] XR is a general term for different realities, including virtual reality (VR), augmented reality (AR), and mixed reality (MR):• VR is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual and audio sensory stimuli of the real world as naturallyas possible to an observer / user as the observer / user moves within the limits defined by the application. VR usually, but not necessarily, requires a user to wear a head mounted display (HMD), which completely replace the user’s field of view with a simulated visual component, and to wear headphones, which provides the user with the accompanying audio. In VR, some form of head and motion tracking of the user may also be necessary to allow the simulated visual and audio components to be updated, to ensure that, from the user's perspective, items and sound sources remain consistent with the user’s movements. In some implementations, additional means to interact with the virtual reality simulation may be provided.• AR is when a user is provided with additional information or artificially generated items, or content overlaid upon the environment the user is in. Such additional information or content will usually be visual and / or audible, and the observation of the current environment by the user may be direct (e.g., with no intermediate sensing, processing, and rendering), or indirect (e.g., the perception of the environment by the user relayed via sensors and may be enhanced or processed).• MR is an advanced form of AR in which some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

[0075] More generally, XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR, and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. A key aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0076] The support of immersive extended reality (XR) experiences in 5G systems, with their demand for high data rates, low latency, and high reliability in 5G systems, represents some significant challenges and requires some adaptation or modification of the QoS architecture.

[0077] In 3GPP Release 18, the QoS framework is arranged to support a limited extent of XR awareness at the radio access network (RAN) level. In both uplink and downlink, XR awareness contributes to optimisations of radio resource and relies on the notions of a PDU Set and data burst defined by 3GPP Working Group SA2. PDU Sets and data bursts enable the RAN to identify the PDUs which carry content that the application is arranged to process as a single data unit (e.g., portion of an image, an audio frame). Since XR content (e.g., media unit of information such as video frame / slice) usually corresponds to a set of PDUs (e.g., PDU Set) logically connected at the application level, it may be advantageous to treat the PDU Sets commonly since an XR application (i.e., a decoder) processes the set of PDUs together and at the same time as mentioned.

[0078] In 3GPP Releases 18 and 19, the QoS framework is arranged to jointly handle the QoS of a set of one or more logically related PDUs as a PDU Set, based on PDU Set QoS requirements, which include:• PDU Set Delay Budget (PSDB): time limit for all PDUs of a PDU Set to be delivered by the 5G system since the arrival of the first PDU of the PDU Set• PDU Set Error Rate (PSER): upper bound for a rate of non-congestion related PDU Set losses at the access network• PDU Set Integrated Handling Information (PSIHI): signals whether all PDUs of a PDU Set are needed at the application, i.e., decoder, to recover the PDU Set

[0079] The PDU Set QoS requirements are requested for an XR session by an XR application to the Policy Control Function (PCF) of the 5G-Advanced network through the available 5G service-based architecture application programming interfaces (APIs). The network in turn determines the policy PDU Set rules and configures the QoS rules for the session. The Session Management Function (SMF) incorporates these QoS rules and PDU Set packet detection rules (e.g., via a semi-static protocol description including also protocol headers / header extensions information) and configures the CN User Plane Function (UPF), and respectively, the RAN and the XR device modem, i.e., the UE, through the Access Mobility Function (AMF) thus ensuring establishment of a QoS flowand associated DRBs for the XR service with support of the XR application PDU Set QoS requirements.

[0080] Figure 3 illustrates such an example CN XRM architecture and the handling of PDU Sets.

[0081] One important feature of the PDU Set QoS framework is for the RAN to identify PDU Sets to be handled according to the PDU Set QoS requirements of a QoS flow. Since only the application layer is aware of the concept of PDU Sets, in 3 GPP Release 18, a cross-layer interaction has been defined to enable the CN and the UE to aid the RAN in acquiring PDU Set awareness (i.e., XR media awareness) by means of in-band data plane signaling of PDU Set information. The PDU Set information may include, e.g.,• PDU Set Sequence Number: Sequence number of a PDU Set among PDU Sets of an XR session• PDU Set Size: Size of the PDU Set (in bytes) including the transport headers encapsulation overhead• End PDU of the PDU Set: Indicator of the last PDU, as transmitted by the sender, of the PDU Set• PDU Sequence Number: Sequence number of a PDU within a PDU Set• PDU Set Importance: Importance value of the PDU Set relative to other PDU Sets on the same QoS flow

[0082] 3GPP defines a generally applicable RTP header extension for PDU Set and end of data burst marking, by XR applications. This can be used to convey PDU Set information to lower layers through the same RTP stack used to transport the PDU Set across networks. It thus aids the UPF in DL and the UE in UL to identify PDU Sets and PDUs set information by inspecting the RTP headers of XR traffic.

[0083] RAN XR awareness relies on QoS flows, PDU Sets, data bursts (a set of multiple PDUs generated by the application in a short period of time) and traffic assistance information provided by the UE. The PDU Set related information can be classified into thesemi-static PDU Set QoS Parameters and dynamic PDU Set information. As shown in Figure 3, the RAN obtains the PDU Set QoS parameters (i.e., PSDB, PSER, PSIHI) from the SMF as part of the QoS profile associated with a QoS flow. In downlink (DL), the UPF- identified PDU Set information is relayed to the 5G NR RAN base station (i.e., the “gNB”) in the headers of the 5G user plane tunnelling protocol (GTP-U). Jitter information, e.g., average arrival time offset statistics, as well as UE / DL periodicity, are provided to the gNB as part of the traffic assistance information. The end of data bursts may be optionally marked in GTP-U headers to aid the gNB in reducing UE power consumption, e.g., by managing the connected discontinuous receive (DRECEIVING) mode into a lower power state. The QoS parameters and PDU Set information thus enable RAN to determine how to best schedule PDU Sets. In uplink (UL), the UE is responsible to identify PDU Sets and data bursts as well as to identify the PDU Set importance. These identifications are, however, not specified in the standards and are left up to UE implementation, e.g., on how to rely on RTP header extension and the interactions between UE modem and XR application. Moreover, UE provides to RAN XR-related UL user assistance information, e.g., jitter range, Burst Arrival Time (BAT), traffic periodicity information, per QoS flow for efficient UL resource allocation.

[0084] The XR awareness (i.e., PDU Set awareness) allows the RAN in UL / DL to utilise the scarce radio resources more efficiently by per PDU Set QoS scheduling. For instance, in case of wireless medium congestion, RAN may discard lower importance PDU Sets and allocate the limited radio resources to more important PDU Sets for a better user experience.

[0085] In one example, the AS PDU Set information listed above can be provided via a 1-byte RTP Header Extension for the marking of PDU Sets and End of Bursts as defined by the 3GPP Technical specification (TS) 26.522 (vO.1.1 - Sep 2023). Figure 4A illustrates an example 1-byte RTP header extension for PDU Set marking by the application server as per the 3GPP Technical specification (TS) 26.522 (vO.1.1 - Sep 2023).

[0086] In another example, the AS may use the 2-byte RTP Header Extension for the marking of PDU Sets and End of Bursts as defined by the 3GPP Technical specification (TS) 26.522 (vO.1.1 - Sep 2023). Figure 4B illustrates an example 2-byte RTP header extensionfor PDU Set marking by the application server as per the 3GPP Technical specification (TS) 26.522 (vO.1.1 - Sep 2023).

[0087] The semantics of the fields denoted in Figures 4A and 4B of the RTP Header Extension for the marking of PDU Set and End of Bursts are:• End PDU of the PDU Set [E] (1 -bit field), which is a flag set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.• Reserved [R] (2-bits field), which is reserved for future use.• End of Data Burst [D] (1 -bit field), which indicates the end of a Data Burst being set to a non-zero value when the end of data burst is present and 0 otherwise.• PDU Set Importance [PSI] (4-bits field), which indicates the importance of a PDU Set compared to other PDU Sets within the same QoS flow. Lower values indicate a higher importance PDU Set with the highest importance PDU Set of 0 and the lowest importance PDU Set of 15.• PDU Set Sequence Number [PSSN] (10-bits field), which encodes the sequence number of the PDU Set to which the current PDU belongs acting as a 10-bit numerical identifier for the PDU Set and wraps around at 1023.• PDU Sequence Number within a PDU Set [PSN] (6-bits field), which indicates the sequence number of the current PDU within the PDU Set. The PSN is set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU Set in order of transmission from the sender. PSN wraps around 63.• PDU Set Size [PSSize] (24-bits field), which indicates the total size of all PDUs of the PDU Set to which this PDU belongs. This field is optional and subject to an SDP signaling offer / answer negotiation, where the AS may indicate whether it will be able to provide the size of the PDU Set for that RTP stream. If not enabled, the field is not present. If enabled, but the AS is not able to determine the PDU Set Size for a particular PDU Set, it should set the value to 0 in all PDUs of that PDU Set. The PSSize indicates the size of a PDU Set including RTP / UDP / IP headerencapsulation overhead of its corresponding PDUs. The PSSize is expressed in bytes.

[0088] A reciprocal processing is applicable to UL whereas the role of UPF packet inspection is taken by the UE which is expected to inspect packets, determine packets belonging to a PDU Set, and transmit the PDU Sets to the RAN on an associated DRB capable of fulfilling the PDU Set QoS requirements (i.e., PSDB and PSER).

[0089] In relation to identification of encrypted traffic, 3 GPP Release 19 provides methods that allow the core network to be aware of the PDU Set information when the end- to-end XRM application is fully encrypted. Specifically, the method uses a “QUIC tunnel” between the UPF and the Application Server including within the headers of the HTTP datagram, metadata that includes PDU Set information. The UPF extracts the PDU Set metadata and includes the PDU Set within GTP-U headers towards the RAN. Figure 5 illustrates a related example of using QUIC to add PDU Set information within HTTP datagrams in accordance with aspects of the present disclosure.

[0090] As mentioned, 5G generally follows an information-agnostic design principle, in which neither the content of incoming data packets nor their attributes (such as importance, aging information or dependencies) are taken into account in radio resource allocation. In 3 GPP Releases 18 and 19, for the efficient support of immersive services (e.g., XR services), a limited extent of application awareness is introduced at RAN. However, such application awareness is only limited to the congestion scenario, in which the importance associated with a PDU or the corresponding PDU Set is used for discarding less important data. It should be appreciated that the importance is associated with a data unit or a PDU set, hence the PDU(s) belonging to the same PDU set (which may have one or more PDUs) have the same importance as the PDU set. Currently, only the identification of PDU Sets is supported at RAN and the RAN is not aware of the content of a PDU Set, e.g., I-frame or P-frame. Specifically, RAN is only aware of the packet delay requirements or packet error rate of a received packet (if in the downlink), and is not aware of the type of application that sent this packet or the traffic characteristics of the application.

[0091] Further, it should be emphasised that the network is not aware of any PDU Set information for UL data transmissions. For example, the gNB does not know which PDUs ofa radio bearer are logically connected and belong to a PDU Set. This limits the possibilities of an optimised radio resource handling / scheduling.

[0092] Application awareness at the RAN level is important not only for immersive media applications like XR services but also for other type of applications / services such as network control system (NCS). Networked control system (NCS) is generally a type of distributed control systems where sensors, actuators, and other devices are interconnected by communication networks. Examples of NCS include factory automation, mobile robots, and unmanned aerial vehicles (UAVs). NCSs and many other example vertical applications exchange information to execute a particular task in the physical world. F or instance, a sensor sends real-time process data to a controller, through which the system state is driven to the desired value. The performance of the application is quantified neither by the amount of data packets that are successfully sent by the network nor by how fast they arrive at the destination. Instead, the performance of the application is entirely characterised by the success level in the (control) task achievement, which is also referred to as Quality of Control (QoC). Basically, the current 5 G- Advanced QoS framework does not suffice to ensure / guarantee an application performance, e.g., QoS parameters which are currently used in 5G Advanced systems are not sufficient to guarantee a certain application performance. In other words, 5GS does not feature any KPIs that quantify the QoC. Instead, the packet error rate, average bit rate, end-to-end latency, and round-trip time are used as service requirements that the 5GS has to meet, and the actual application performance, given the control task at hand, is not considered.

[0093] As discussed, introducing application awareness to 5GS, or more generally to RAN, can help the network utilise the limited resources more efficiently and improve the QoC and / or QoE, e.g., by prioritising more important packets.

[0094] For radio access technologies beyond 5G (e.g., 6G), it would be ideal for application awareness to be natively supported in the RAN to help network utilise the limited resources more efficiently and improve the QoE and QoC, e.g., by prioritising more important packets. Ideally, resource allocation should not be limited to granting users time and frequency resources considering radio conditions and buffer status (delay information), and instead, the RAN should also assess semantics and context of the data andconsequently specify for which particular information the allocated resources should be used. For example, UL radio resources can be used more efficiently when the context and importance are considered (compared to the case where UE selects the next PDU in the transmission buffer in an information-agnostic fashion). Whenever communication occurs to convey a meaning or to accomplish a goal, what matters is the impact that the received bits have on the interpretation of the meaning intended by the transmitter or on the accomplishment of a common goal. It is important to identify the relevant information, i.e., the information strictly necessary to recover the meaning intended by the transmitter or to accomplish a goal. By focusing on semantics and by clearly identifying the goal of the communication, data that is more relevant to conveying the information intended by the source or to fulfilling a predefined goal can be identified and such relevant / important data can be transmitted reliably. In some cases, down prioritising or even discarding non- relevant / important data can reduce the amount of data to be transmitted and recovered, thus allowing savings in bandwidth, delay, and energy.

[0095] An example definition of the term “context” is provided herein. However, it should be noted that the term “context” may not be limited to the example definition provided. In an example definition, a context may be a task (e.g., change actuator state within provided delay budget constraints), a sub-task, or a group of tasks to be executed by an application (e.g., control and time-sensitive application). In an example definition, a context may refer to the contextual content (e.g., video, audio, haptic, sensor data) associated with an application, i.e., the content parts immediately preceding or following a content object, i.e., a DU (e.g., video frame / slice, audio utterance, haptic trigger / actuation, sensor samples / values).

[0096] In order for beyond 5G (e.g., 6G) systems to achieve a better (e.g., full) convergence of communication and control, specific end-to-end system architecture and protocol designs are required. The following disclosure provides some example architecture and protocol designs for this purpose.

[0097] In one aspect of the example architecture and protocol designs, a new layer 2 protocol, e.g., a new protocol layer, is introduced in the L2 user plane protocol stack. In one example implementation, the new protocol layer is also referred to as ApplicationAwareness Layer (AAL) (e.g., 602 in Figure 6). The AAL provides several functions, which allow the RAN to utilise the limited radio resources more efficiently and improve the QoE and QoC by considering the content of a data packet / PDU / data unit and its associated attributes. In one example implementation, the AAL receives a data packet of an application data flow (data flow of an application) and identifies from the data packet, a (application) data unit (DU) and its corresponding attributes. The identification of DU may be performed based on metadata provided to the AAL.

[0098] In one example implementation, the AAL, as transmitting entity, is operable to obtain a data packet of an application data flow. The data packet includes a payload associated with a data unit of an application and metadata including one or more attributes of the data unit, the AAL, as transmitting entity, is also operable to perform an identification operation to identify, from the data packet, the metadata and the data unit, generate, based on the identified metadata, a protocol header comprising information associated with the data unit, generate a protocol data unit (PDU) comprising the protocol header and the payload of the data packet, and output the PDU to a lower protocol layer for transmission to a receiving entity.

[0099] In one example implementation, the AAL, as receiving entity, is operable to obtain a PDU which includes a payload of a data packet associated with a data unit and a protocol header including information associated with the data unit. The AAL, as receiving entity, is further operable to perform an identification operation to identify, based on the protocol header, the data unit and metadata including one or more attributes of the data unit, and output, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

[0100] As used herein, the term “data unit (DU)” refers to a piece of information that cannot be further fragmented without losing its context (an example definition of the term “context” has been provided above). Essentially, a data unit (DU) is a representation of an application quantity that is transmitted from a source application to one or more receiving applications and it cannot be divided further into smaller chunks before being processed and used on the receiving end of the application. In one example implementation, the smallest DU may be a UDP packet. In one example implementation, in the context of XRapplications, a DU may be a PDU Set or an Application Data Unit (ADU) (i.e., the smallest unit of data that can be processed independently by an application). On the client (e.g., receiving) side, a minimum set of PDUs in each video frame needs to be available before the next level of processing (e.g., decoding of the video slice) can be performed. This minimum set of PDUs may be referred to as “PDU Sets”. A PDU Set is defined as including one or more PDUs carrying the payload of one unit of information generated at the application level. Split XR traffic consist of bursts that can carry one or more PDU Sets. In one example implementation, at the simplest level, a PDU Set can correspond to a video frame or a “slice” of a video frame (for a video frame that has been subject to slice-based encoding).

[0101] In one example implementation, the AAL provides an identification function for identifying the DU with which a received data packet is associated. In one example implementation, the identification function serves as the entry point of DUs to the AAL at the transmitting side. The AAL is operable to identify DUs upon arrival of data packets, e.g., IP packets, from a higher layer to the AAL. In one example implementation, the identification function is configured with rules for the identification ofDU(s) and associated metadata. The rules may be provided by a network entity such as the session management function node.

[0102] In one example implementation, the AAL further provides a prioritisation function for filtering and / or prioritising DUs based on, e.g., a pre-configured policy. An example is the prioritisation of DUs with a high importance, which may be provided to the AAL by the application as metadata per DU to assist the AAL in the prioritisation. Another example is the consideration of the delay status, e.g., remaining delay, of a DU / data packet. In one example implementation, the AAL may have the ability to discard DUs / PDUs actively at the transmitting side based on any one or more of: their importance, remaining delay, linear / quadratic cost, mean square error, energy consumption-related parameters / metrics, dependency information (dependency of data unit on other data unit(s)), or other attributes associated with a DU. In one example implementation, at the receiving side, the AAL may identify PDUs belonging to one (the same) DU and may differentiate among different PDUs. In one example implementation, this identification isperformed based on header information signalled together with a PDU as described further below, e.g., header information contained in a AAL protocol data unit (PDU). Based on the identification, the receiving entity may also request specific DUs for a QoS flow / radio bearer or PDUs of a DU by some new request information signalled from the receiving entity to the AAL transmitting entity. The receiving entity may acknowledge the reception of a DU to the transmitting entity by providing a status report to the transmitting entity. By using the knowledge of DUs and their associated attributes at the receiving side and providing some feedback / status to the transmitting side, UL radio resources can be used more efficiently (compared to the case where UE selects the next PDU in the transmission buffer in an information-agnostic fashion). In one example implementation, a new status reporting procedure from the receiving side to the transmitting side is introduced for the AAL. The status report may be transmitted via a control PDU generated at the receiving side. In one example implementation, the status report may include information on successfully received DUs, e.g., identified by a DU sequence number, or a request for one or more DUs or one or more PDUs of a DU. Application awareness at the receiving entity also enables an optimised reordering functionality. For example, high importance and / or delay critical packets / DU could be delivered to higher layer immediately (without having to wait for the reordering of other PDUs stored in the receiving window, or PDU / DUs which are required for the successful decoding of other dependent DUs can be received even beyond their delay budget (after the corresponding delay budget is already exceeded). In one example implementation, the AAL may support the QoS flow to DRB mapping functionality.

[0103] Figure 6 illustrates an example implementation of a user plane (UP) protocol stack with the AAL 602A in a transmitting entity (e.g., UE) and the AAL 602B in a receiving entity (e.g., gNB) respectively in accordance with aspects of the present disclosure. As shown in Figure 6, the AAL 602 A, 602B is located above the service data adaptation protocol (SDAP) and PDCP layers in the UP protocol stack. In another example implementation, the AAL 6602A, 602B may be located between PDCP layer and SDAP layer, e.g., radio bearer specific.

[0104] In one example implementation, the AAL provides an indication to lower layers, e.g., MAC / RLC layer, to prioritise certain packets during logical channel prioritisation (LCP). In one example implementation, since the identification of DUs and their corresponding attributes (such as importance, dependency information, etc.) is performed at the AAL, inter-layer communication is necessary to provide DU-specific information to the other UP protocol layers. The AAL is aware of the content of a PDU / DU and the corresponding metadata, and based on this, the AAL determines the priority of a PDU for the transmission within the RAN. In another example implementation, the AAL may indicate to PDCP layer the importance of a PDU / DU and / or the dependency information associated with a PDU / DU which is used at the PDCP layer for discarding at the transmitting side. In one example implementation, the AAL supports a reordering functionality. In one example implementation, the reordering is performed at the AAL based on the content and attributes of a PDU / DU (i.e., the reordering is not performed at the PDCP layer as in the legacy).

[0105] In one example implementation, an encapsulation protocol (e.g., based on QUIC) is used for proxy ing / encapsulating application traffic between the UE and the network. In-band user plane signaling is used to provide the metadata to the lower Layer 2 protocols such as the new AAL (for instance based on an encapsulation protocol such as Connect-UDP, Connect-IP, QUIC-Aware proxy or any other QUIC method where metadata may be added as part of the headers of the QUIC protocol or embedded in control payloads as correspondingly defined header metadata, control frames, and / or control PDUs). In one example, the encapsulation protocol is used to add QoS flow control metadata dynamically to the packets / DUs of the application, and the metadata based on the QoS requirements and traffic characteristics of the application traffic. In one example implementation, the metadata and encapsulation are used by the AAL to identify DUs as described above to efficiently transmit / treat data packets / DUs of a QoS flow in the RAN based on the attributes of the corresponding data packet / DU as described by the associated metadata.

[0106] For the UL direction, the SMF may configure the UE to inspect encapsulated metadata received in user-plane at L2 ingest reference point on the UL based on the encapsulation protocol, QoS rules and DU media / payload components descriptionassociated with the session (e.g., an application function (AF) session with QoS) comprising the DUs traffic. The UE may use the SMF configuration to process the encapsulated metadata and perform the corresponding procedures / functions of the AAL, e.g., identification of DUs and prioritisation of important DUs.

[0107] In another example implementation, the UE may expose programmatic interfaces, i.e., APIs via OS libraries or service-based interfaces (e.g., through a 3 GPP- aware media session handler, or more generally, a session handler entity) to applications or other entities under the control of applications. The applications configure the UE with QoS requirements for the session and the UE modem determines the QoS rules associated with the required QoS for the session. Additionally, the configuration may further include packet detection rules and or protocol description information elements detailing the content delivery protocols employed by the application in UL and applicable packet detection filters the UE may need to apply for appropriate filtering of content and its mapping to network QoS flows and lower layer radio bearers. Such configuration may be used for the control of AAL functionality (e.g., extracting application awareness related information from ingress traffic and optimizing handling of DUs based on marked and determined DU characteristics).

[0108] In one example implementation, the service-based interfaces included within a UE (e.g., the ones exposed by a media session handler, or alternatively, a session handler) may be used by other network functions, e.g., the AF, under the control of an ASP, to provide the UE with the associated packet detection rules and protocol description for UL traffic.

[0109] In one example implementation, a UE may access service-based interfaces exposed by other network functions under the control of an ASP, e.g., such as an AF, or by the core network / radio access network to fetch a session configuration for the DU content delivery in UL. The configuration may include the associated packet detection rules and protocol description, e.g., as set by an ASP for UL traffic.

[0110] For the DL, the AS may include application data further embedding metadata, e.g., by including metadata in the header of the encapsulation protocol. The 5GUPF may identify and mars the DUs based on the header information, e.g., the UPF extracts PDUs(e.g., UDP packets) and embedded application metadata from encapsulation protocol and maps the metadata and corresponding PDUs over GTP-U over the QoS flow based on received configuration rules. Along with each PDU of a DU, the UPF provides the 5G- RAN with associated information, so that the 5G-RAN can identify that a PDU belongs to a specific DU. This associated information, which can be referred to as Data Unit Meta Data (DUMD), is provided by the UPF to the 5G-RAN through the N3 interface. The RAN, e.g., gNB, identifies DUs and their corresponding attributes based on the metadata info and uses this information for performing the corresponding functions within the AAL.

[0111] In one example implementation, the AAL is operable to add a protocol header, AAL header, to the incoming data packets, e.g., IP packets arriving at the AAL, and generates outgoing data, e.g., AAL PDU. In one example implementation, a function within AAL maps the metadata received over N3 (e.g., within GTP-U headers) to the outgoing protocol header. In one example, the function may be configured with rules for mapping the metadata received over N3 to the corresponding protocol header fields / information in the AAL header. In one example implementation, a function within AAL maps the identified encapsulated metadata received in user-plane at L2 ingest reference point on the UL to the outgoing protocol header. The function may be configured with rules for the mapping of the metadata to the corresponding protocol header fields / information of the AAL header. Each AAL PDU contains all necessary information to enable the receiving entity, e.g., receiving AAL entity, to identify DUs from the data packets. In one example implementation, the AAL header contains DU specific information to support application layer awareness at the network / gNB side for uplink data transmissions. In one example implementation, certain functions at the receiving side, such as the reordering mechanism, uses the DU specific information carried in the header to provide an optimised handling of the functionality (e.g., mapping and / or routing packets corresponding to a DU characteristics to an appropriate QoS flow, including prioritisation, or alternatively, to the application) and thereby increasing the user perception at the application layer by considering the DU characteristics such as, e.g., importance, delay requirements, dependency information, etc. In one example implementation, the receiving entity may deliver important, delay-critical DU(s) and / or the corresponding PDUs to higher layer without waiting for the reordering function to complete the reordering, e.g., before expiryof t-reordering timer. In another example implementation, the receiving side may request certain data packets / DUs of an application / QoS flow, e.g., missing packets / DU necessary for a successful processing at the application layer, or the receiving side may provide a feedback / status report to the transmitting side. As the receiver is aware of DUs and their corresponding attributes, the feedback from the receiving side to the transmitting side is possible.

[0112] In one example implementation, the header information (the fields of the AAL header) contains one or more of the following example DU related information:• DU Sequence Number: Sequence number of a DU among DUs of an QoS flow / service / session• DU Size: Size of the DU in bytes, e.g., including the transport headers encapsulation overhead• End PDU of the DU: Indicator of the last PDU, as transmitted by the sender, of the DU or alternatively indicator of the PDU of a data burst• PDU Sequence Number: Sequence number of a PDU within a DU• Importance: Importance value of the DU relative to other DUs on the same QoS flow for determining dynamic prioritisation of media component packets, e.g., packets of higher importance may be moved into a transmission queue associated with a higher transmission priority whereas packets of lower importance may be moved into a different transmission queue associated with a different (lower) QoS treatment policy. The importance may be also considered during the logical channel prioritisation procedure (LCP) for UL transmissions as well as the discarding behaviour may also consider the importance of a DU, e.g., during congestion.• Type of DU: Identification of the media components e.g., audio, video, haptic, or sensor data (temperature, etc.), meter data (e.g., increasing energy value) etc. The type of DU may be used for determining the corresponding QoS treatment within RAN, e.g., for transmission over the air interface.• Dependency information: Provides dependency information among DUs of one QoS flow / radio bearer and may also contain dependency information among DUs of different QoS flow (for the case where different QoS flows belong to one application (multi-modal service). The dependency information may be used within RAN for the prioritisation of DUs, e.g., DUs which are required for the successfully processing / decoding of other DUs are prioritised. Also, the discarding functionality may consider the dependency information for an active discarding of DUs in order to optimise the radio resource efficiency, e.g., capacity increase.• Inter-media component synchronisation thresholds for media delivery of the radio access network (e.g., maximum absolute audio / video synchronisation delay, maximum video / haptic synchronisation delay, maximum absolute caption / Video synchronisation delay, or more generally maximum absolute media component #l / media component #2 synchronisation delay etc.). Such synchronisation thresholds may be used at the transmitter side during the prioritisation / LCP or on the receiving side for an efficient reordering operation.• Application-layer forward error correction (AL-FEC) related information, i.e., identification of a PDU / DU as a source packet / DU or as a redundant PDU / DU, codebook type such as MDS codes (i.e., Reed-Solomon), near MDS codes (Raptor / RaptorQ as per RFC 5053 / RFC 6330), FlexFEC (RFC 8627), systematic / non-systematic code, content ratio, or alternatively, redundancy ratio, number of source packets, or alternatively, number of redundant packets, discarding behaviour of AL-FEC obsolete redundant packets (i.e., keep or discard in case of congestion or non-congestion) as well as QoS requirements (bit rate, delay budget, tolerable error rates) taking into account the AL-FEC configuration• Timestamp information: information on the time of ingress at Layer 2, e.g., AAL at the Transmitting side, or alternatively, information on the time of egress from the source encoder (i.e., encoding time when packets / DU are put on the wire) given that source encoder and network are synchronised within same time domain (e.g., such as based on PTP, PTPv2, RFC 8173, or alike network synchronisation mechanisms). Based on the timestamp information the receiving side may calculatethe remaining delay of a data packet / DU which may be used as an input for the reordering functionality.• Codec related information: information on the used codec, e.g., codec type.• Burst related information: Information on the burst characteristics, which may be used for radio resource scheduling, such as burst size information (size of current burst, size of next burst), time to next burst, burst arrival time, end of burst information.• Any of their combination

[0113] In one example implementation, the AAL header is inspected by lower layers, e.g., PDCP layer, RLC / MAC layer to enable an optimised handling of data packets considering the content of a PDU / DU and the corresponding attributes. In one example implementation, the PDCP layer inspects the AAL header to identify PDUs belonging to one DU and performing the discarding on a DU level (also considering, e.g., some dependency information or importance information associated with a DU). Similarly, MAC layer may inspect the AAL header to perform prioritisation of certain PDUs during the logical channel prioritisation (LCP) procedure.

[0114] In one example implementation, the AAL protocol layer may not be present for each radio bearer, since application awareness may not be required or may not be beneficial for each and every radio bearer (depending on the service carried on the corresponding radio bearer). In one example, the network may configure whether AAL is present or bypassed, e.g., for a radio bearer / QoS flow. If AAL is not configured for a radio bearer, a legacy NR stack may be used.

[0115] In one aspect of the example architecture and protocol designs, the PDCP layer of the user plane Access Stratum (AS) protocol stack is arranged to support application awareness related functionalities. In one example implementation, the PDCP layer supports the identification of data units (DUs) and their corresponding attributes, e.g., importance, dependency information, etc.

[0116] In one example implementation, the modified PDCP layer, as transmitting entity, is operable to obtain a data packet of an application data flow. The data packet includes a payload associated with a data unit of an application and metadata including one or more attributes of the data unit, the AAL, as transmitting entity, is also operable to perform an identification operation to identify, from the data packet, the metadata and the data unit, generate, based on the identified metadata, a protocol header comprising information associated with the data unit, generate a protocol data unit (PDU) comprising the protocol header and the payload of the data packet, and output the PDU to a lower protocol layer for transmission to a receiving entity.

[0117] In one example implementation, the modified PDCP layer, as receiving entity, is operable to obtain a PDU which includes a payload of a data packet associated with a data unit and a protocol header including information associated with the data unit. The AAL, as receiving entity, is further operable to perform an identification operation to identify, based on the protocol header, the data unit and metadata including one or more attributes of the data unit, and output, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

[0118] As outlined in previous aspect, for UL, the UE may inspect encapsulated metadata received in user-plane on the UL based on the encapsulation protocol, QoS rules and media components description associated with an AF session. The UE may use an SMF configuration to process the encapsulated metadata and perform the corresponding procedures / functions of the PDCP layer, e.g., identification of DUs and prioritisation of high importance DUs during congestion. For DL, the 5GUPF identifies and marks the DUs based on header information, e.g., the UPF extracts UDP packet and application metadata from encapsulation protocol and maps the metadata over GTP-U over the QoS flow based on received configuration rules. The Data Unit Meta Data (DUMD) is provided by the UPF to the 5G-RAN through the N3 interface. The PDCP Transmitting entity in the gNB identifies DUs and their corresponding attributes based on the metadata info. Since the PDCP layer is the L2 protocol layer that mostly enforces QoS by supporting certain functionalities such as discarding, reordering, etc., in some cases it may be beneficial to place the application awareness functionalities (such as identification of DUs and theircontent and / or DUs associated attributes) directly within the PDCP layer (rather than introducing a new L2 protocol layer as described above). In one example implementation, the support of application awareness at the PDCP layer enables efficient discarding operation at the transmitting side, e.g., considering the importance of a PDU / DU and / or dependency information associated with a PDU / DU without an increased complexity (e.g., complexity due to inter-layer communications).

[0119] In one example implementation, the network is arranged to selectively enable and disable the support of application awareness for a PDCP entity. In one example implementation, the network may configure, on a radio bearer level / PDCP level, whether application awareness is supported for the corresponding radio bearer / PDCP entity. As discussed, not all services may benefit from or may strictly require the support of application awareness. At the receiving side, the reordering functionality may also consider the content of a PDU / DU and / or the attributes attached with a PDU / DU to optimise the reordering functionality and thereby increase the user perception of a services or the QoC. In one example implementation, the PDCP receiving entity may deliver important, delay- critical DU(s) respectively the corresponding PDUs to higher layer without waiting for the reordering function to complete the reordering, e.g., before expiry of t-reordering timer. In one example implementation, PDU / DUs which are required for the successful decoding of other dependent DUs or which are required for the successful execution of a task can be received even beyond their delay budget (after the corresponding delay budget is already exceeded). In the legacy PDCP reordering procedure, t-reordering is maintained on a PDU / SDU level without considering inter-dependencies of the PDUs / SDUs. Upon expiry of the timer t-reordering, the receiving window is advanced and late packets will be discarded. Basically, the reordering / waiting time is enforced on a data packet / PDU / SDU level, e.g., same t-reordering time for each PDU / SDU, without considering interdependency information or other DU-specific information. In one example implementation, the PDCP header includes metadata associated with a PDCP SDU, thus enabling application awareness at the receiving (PDCP) entity. In one example, DU specific information as discussed with reference to the AAL header is included in the PDCP header. In one example implementation, the application awareness function within PDCP maps the metadata received over N3 (e.g., within GTP-U headers) to the PDCP protocol header, e.g.,for the DL case. In one example, the function may be configured with rules for the mapping of the metadata received over N3 to the corresponding protocol header fields / information, PDCP header. In one example implementation, the function within PDCP maps the identified encapsulated metadata received in user-plane at L2 ingest reference point on the UL to the outgoing PDCP protocol header. In one example, the function may be configured with rules for the mapping of the metadata to the corresponding protocol header fields / information, PDCP header. In one example implementation, the PDCP layer may be configured to operate in two different modes, one mode supporting application awareness and related functionalities, another mode not supporting application awareness and related functionalities (but legacy PDCP layer operations are supported). Figure 7 illustrates an example application-aware PDCP layer 702A of the transmitting entity and an example application-aware PDCP layer 702B of the receiving entity respectively in accordance with aspects of the present disclosure. Different PDCP headers are supported for the two different modes. For the application aware PDCP mode (i.e., application awareness is supported), the PDCP header includes DU-specific information (e.g., DU sequence number, importance, dependency, type of DU, etc., as mentioned above). For the legacy PDCP mode (i.e., application awareness is not supported), the PDCP header may be similar to the PDCP header in 5G NR. In one example, the network configures the PDCP mode of a PDCP entity / radio bearer.

[0120] In one example implementation, the PDCP entity may support an application- optimised retransmission protocol, e.g., feedback / status reporting from the PDCP receiving entity is supported. As the receiving PDCP entity is able to identify and differentiate DUs based on the PDCP header information carrying DU-specific information / metadata for an PDU, the receiving PDCP entity can also provide DU specific feedback or status reports to the PDCP transmitting entity. In one example implementation, the PDCP receiving entity may request the (re)transmission of some specific DUs, e.g., by signaling of a DU SN or ID to the transmitting PDCP entity. In one example implementation, a new status reporting procedure from the receiving side to the transmitting side is introduced for the PDCP layer. The status report may be transmitted via a new control PDU which is generated at the receiving side. The status report can also be referred to as DU status report. The DU status report may include information on successfully received DUs, e.g., identified by a DUsequence number, or a request for certain DUs, respectively certain (missing) PDUs of a DU. When AL-FEC is used / enabled, the DU status report may notify the transmitting entity that the receiving entity has received a sufficient number of PDUs for a DU, e.g., sufficient number of info PDUs and / or redundant PDUs, for decoding the DU at the application layer. In response to such indication, the transmitting entity, e.g., UE for the UL case, could discard the remaining pending PDUs of the DU to avoid unnecessary transmissions. The PDCP header, carrying DU-specific information, may signal the number of required PDUs for a successful decoding of a DU, in case AL-FEC is applied / enabled.

[0121] In one example implementation, a new DU-specific status reporting procedure is introduced for the PDCP layer. Some predefined conditions for triggering such new DU- specific status report are introduced. In one example, timer-based DU status reporting is introduced. In one example, the transmitting entity may also request a DU-specific status report. Such request may be indicated within the PDCP header or sent via a PDCP control PDU. In one example implementation, a common PDCP status report is designed which includes PDU / SDU specific status / feedback, e.g., similar to the legacy PDCP status report, as well as DU-specific status / feedback.

[0122] Based on the feedback or status report, UL radio resources can be used more efficiently when the retransmission protocol, e.g., PDCP receiving entity, considers the context or importance of a PDU for the application. Unnecessary retransmission, from which the application does not benefit, could be avoided. This may increase the resource efficiency and ultimately the capacity. Significant gains in the QoE and / or QoC may be obtained if the RAN protocols can assess semantics and context and consequently specify for which particular information the allocated resources should be used.

[0123] In one aspect of the example architecture and protocol designs, the PDCP layer is split into two sub-layers. Figure 8 illustrates an example Layer 2 UP protocol stack with a PDCP layer split into two sub-layers 802-1, 802-2. One sub-layer is referred to as PDCP AAL sub-layer 802-1, which includes application awareness related functionalities, such as the identification functionality (identification of DUs and their associated content / attributes), and optionally discarding functionality and / or prioritisation / routing functionality. The functions of a PDCP layer that are largely not impacted by applicationawareness reside in the other PDCP sublayer, referred to as PDCP base sub-layer 802-2. In one example implementation, header compression and ciphering functions are located in the PDCP base sub-layer 802-2. Sequence number maintenance is performed in the PDCP AAL sub-layer. PDCP header information including DU-specific information / metadata for a PDCP SDU is generated in the PDCP AAL sub-layer, even though the PDCP PDU, after integrity protection and ciphering, may be generated in the PDCP base sub-layer. Figure 9 illustrates an example implementation of the UP protocol stack of Figure 8 in a transmitting entity and in a receiving entity in accordance with aspects of the present disclosure.

[0124] In one aspect of the example architecture and protocol designs, the concept of sub-RBs (radio bearer) is introduced. To support differentiated treatments ofPDUs / DU (packet-level granularity) carried in one radio bearer over the Uu interface, prioritisation / routing of PDCP SDUs / PDUs to different PDCP base entities is supported. In one example implementation, the UE may use different sub-RBs to prioritise different packets (i.e., PDUs), or prioritise different DUs based on the encapsulated metadata information available in the encapsulation protocol at the UE. In one example, PDUs / DUs associated with different importance levels may be routed to different sub-RBs to allow for a QoS treatment within the Radio Access Network (RAN) tailored to the content of a PDU / DU. It should be noted that different data units, e.g., media units, contribute differently to the user experience or QoC. Thus, it may be useful to support a differentiated handling of DUs within RAN. In one example implementation, a mapping between one parameter or a combination of multiple parameters included in the metadata and RAN QoS requirements, e.g., packet error rate, latency requirement, discarding priority, is provided to the UE (e.g., the PDCP layer of the UE). In one example, the SMF configures the UE with the mapping information or QoS rules for the different types of data. Based on the provided mapping information or QoS rules respectively provided to the UE, the PDCP layer performs the routing of packets to the sub-RBs. It should be noted that the routing of PDUs is not limited to (sub)-radio bearers within a 3 GPP system. In one example implementation, the PDCP entity may also route packets / PDUs to different RATs, e.g., Wi-Fi, based on the characteristic of a PDU as described by the corresponding metadata. Figure 10 illustrates an example UP protocol stack in accordance with aspects of the present disclosure, whichincludes multiple PDCP base entities, and multiple corresponding RLCs, for supporting the concept of sub-RBs (radio bearer).

[0125] In one aspect of the example architecture and protocol designs, functionalities of the NR PDCP protocol layer and the NR RLC protocol layer are combined into one new protocol layer. In one example implementation, a common retransmission protocol that supports the functionality of the legacy NR RLC AM retransmission protocol as well as the reordering / receiving window operation of the NR PDCP layer is placed in the new protocol layer. Both functionalities are integrated into one retransmission protocol which is simultaneously application-optimised.

[0126] The motivation to have only one receiving window operation and one common retransmission protocol (except the HARQ protocol) is based on the current NR layer 2 protocol stack design and its corresponding inefficiencies. According to the current specified 5G system, the PDCP and RLC layers in the user plane protocol stack function independently from each other. On the receiving side, the PDCP layer maintains a reordering window to receive PDCP PDUs and transmit them in-sequence to higher layers. In RLC, the RLC receiving entity maintains a reception window to receive RLC PDUs and transmit them to higher layers. In PDCP, the reordering window is controlled by a t- reordering timer that is configured by RRC. When this timer expires, it causes the reordering window to slide forward, i.e., update the lower bound of the reordering window. If a packet is received outside of this reordering window, it is discarded by the PDCP receiving entity. In RLC AM Mode, the receiving entity slides its reception window when the lowest packet in the window (i.e., packet with SN that matches the lower bound of the RLC AM reception window) has been completely received and an acknowledgement has been sent for the same. As the two layers operate independently, the reception window and reordering window may not be updated at the same time. If the PDCP reordering window moves forward while the RLC window is not updated, the RLC layer might transmit packets to the PDCP layer that are outside of the reordering window leading to discard of such packets.

[0127] As an example, Figure 11 A illustrates an example packet data convergence protocol (PDCP) and radio link control (RLC) reception and Figure 1 IB illustrates anexample PDCP and RLC reception after t-Reordering expiry in accordance with aspects of the present disclosure. More specifically, Figure 11 A shows the reordering window in PDCP and reception window in RLC AM mode wherein the lower bounds of both windows are expecting PDU with SN = 0 (COUNT = 0 in case of PDCP wherein COUNT = [HFN, SN]). As shown in Figure 11 A, the RLC receiving entity has correctly and fully received packets numbered 0, 2 and 3, and hence transmitted this to PDCP layer. PDCP has also received packets numbered 0, 2 and 3, with a missing packet numbered 1. Hence the PDCP receiving entity starts the t-Reordering timer when it receives packet 2 before 1. On the other hand, in RLC, the t-reassembly timer is started since one or more segments of packet 1 are not received yet. When the t-Reordering timer expires, the PDCP reordering window updates its lower bound to the next packet that has not been consecutively received. For example, in Figure 1 IB, packet 4 is the next packet that has not been consecutively received after the t-Reordering expires. Hence, the lower bound of the PDCP reordering window is moved to packet 4, whereas in RLC, the t-reassembly only triggers a status report upon expiry and the reception window does not update unless the status report contains an ACK for packet 1. Since the RLC receiving entity has not received packet 1, it still tries to recover the packet by means of (re)transmissions. Once the packet is recovered by the RLC, it transmits this to PDCP which will discard the packet as it is outside of the reordering window. These redundant transmissions are not only a waste of resources and can also add unwanted latency on the user plane. Hence, for future wireless communication systems (e.g., 6G) it will be desirable to avoid such inefficiencies in the current Layer 2 protocol stack design.

[0128] In one aspect of the example architecture and protocol designs, the above problem or inefficiency is addressed. Figure 12 illustrates an example implementation of a UP protocol stack in a transmitting entity and in a receiving entity in accordance with aspects of the present disclosure, for addressing the above problem or inefficiency.

[0129] As shown in Figure 12, the new L2 protocol stack is leaner (has less number of layers) compared to the NR L2 protocol stack, since a retransmission protocol is supported in the new protocol layer, e.g., referred to as PDCP AAL 1202A, 1202B. The PDCP AAL supports the functionalities disclosed in the above aspects, e.g., identification of DUs,application-optimised discarding functionality, and prioritisation / routing functionality. It should be noted that one PDCP AAL entity may be associated with multiple logical channels (LCHs). In this example, a logical channel is referred to as a link between PDCP AAL layer and the MAC layer. By supporting multiple LCHs being associated with one PDCP entity, it is possible to prioritise packets differently during the logical channel prioritisation (LCP) procedure. In one example implementation, the PDCP AAL routes the packets / DUs which are identified by the application-awareness functionality within the PDCP AAL as high importance packets to a LCH configured with a higher LCH priority.

[0130] Figure 13 illustrates an example implementation of a UP protocol stack in accordance with aspects of the present disclosure. As shown in Figure 13, UL prioritisation based on application / DU-awareness is supported by associating multiple LCHs with one PDCP entity, the LCHs being the input for the LCP procedure.

[0131] Figure 14 illustrates an example data flow across protocol layers in a UP protocol stack in accordance with aspects of the present disclosure. More specifically Figure 14 illustrates the data flow across the UP protocol layers for two LCHs / RBs.

[0132] In one example implementation, at the PDCP receiving entity, the reordering functionality may also consider the content of a PDU / DU and / or the attributes attached with a PDU / DU to optimise the reordering functionality and thereby increase the user perception of a services. As shown in Figure 14, the PDCP header includes metadata associated with a PDCP SDU enabling application awareness at the receiving (PDCP) entity. As shown in Figure 14, DU specific information as discussed above is included in the PDCP header.

[0133] In one example implementation, the PDCP entity supports an application- optimised retransmission protocol, e.g., feedback / status reporting from the PDCP receiving entity is supported. As the receiving PDCP entity is able to identify and differentiate DUs based on the PDCP header information carrying DU-specific metadata for an PDU, the receiving PDCP entity can also provide DU specific feedback / status reports to the PDCP transmitting entity. Similar to the RLC ARQ protocol, the PDCP Receiving entity may request based on some defined trigger conditions the (re)transmission of some specific SDUs / DUs, e.g., by signaling a status report including a DU / SDU SN or ID to thetransmitting PDCP entity. Thus, UL radio resources can be used more efficiently when the retransmission protocol, e.g., PDCP receiving entity, considers the context or importance of a PDU for the application. As such, unnecessary retransmission from which the application does not benefit could be avoided, and, in turn, the resource efficiency and ultimately the capacity can be increased.

[0134] In one example implementation, for the (uplink) split bearer case or dual connectivity (DC) scenario, where the UE may be connected with multiple gNBs, the PDCP entity may receive the PDCP PDUs from each gNBs (e.g., MAC layer). The PDCP receiving entity stores the received PDCP SDUs / segments in the receiving window and generates a feedback or status report (e.g., if triggered). Figure 15 illustrates an example for generating such a feedback or status report. The PDCP transmitting entity may receive the feedback or status report, and may, based on the feedback or status report, retransmit missing (e.g., not acknowledged) SDUs / segments. The PDCP transmitting entity can send the retransmission via the different LCHs / MAC entities (to different gNB / carriers).

[0135] Figure 16 illustrates an example of a UE 1600 in accordance with aspects of the present disclosure. The UE 1600 may include a processor 1602, a memory 1604, a controller 1606, and a transceiver 1608. The processor 1602, the memory 1604, the controller 1606, or the transceiver 1608, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0136] The processor 1602, the memory 1604, the controller 1606, or the transceiver 1608, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0137] The processor 1602 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). Insome implementations, the processor 1602 may be configured to operate the memory 1604. In some other implementations, the memory 1604 may be integrated into the processor 1602. The processor 1602 may be configured to execute computer-readable instructions stored in the memory 1604 to cause the UE 1600 to perform various functions of the present disclosure.

[0138] The memory 1604 may include volatile or non-volatile memory. The memory 1604 may store computer-readable, computer-executable code including instructions when executed by the processor 1602 cause the UE 1600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1604 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0139] In some implementations, the processor 1602 and the memory 1604 coupled with the processor 1602 may be configured to cause the UE 1600 to perform one or more of the functions described herein (e.g., executing, by the processor 1602, instructions stored in the memory 1604). For example, the processor 1602 may support wireless communication at the UE 1600 in accordance with examples as disclosed herein. For example, the UE 1600 may be configured to support one or more means for obtaining, at a first protocol layer, a data packet of an application data flow, wherein the data packet comprises a payload associated with a data unit of an application and metadata including one or more attributes of the data unit; performing an identification operation to identify, from the data packet, the metadata and the data unit; generating, based on the identified metadata, a protocol header comprising information associated with the data unit; generating a protocol data unit “PDU” comprising the protocol header and the payload of the data packet; and outputting the PDU to a second protocol layer for transmission to a receiving entity. For example, the UE 1600 may be configured to support one or more means for obtaining, at a first protocol layer, a protocol data unit “PDU”, wherein the PDU comprises a payload of a data packet associated with a data unit and a protocol header including information associated with thedata unit; performing an identification operation to identify, based on the protocol header, the data unit and metadata comprising one or more attributes of the data unit; and outputting, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

[0140] The controller 1606 may manage input and output signals for the UE 1600. The controller 1606 may also manage peripherals not integrated into the UE 1600. In some implementations, the controller 1606 may utilise an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1606 may be implemented as part of the processor 1602.

[0141] In some implementations, the UE 1600 may include at least one transceiver 1608. In some other implementations, the UE 1600 may have more than one transceiver 1608. The transceiver 1608 may represent a wireless transceiver. The transceiver 1608 may include one or more receiver chains 1610, one or more transmitter chains 1612, or a combination thereof.

[0142] A receiver chain 1610 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1610 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1610 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 1610 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1610 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0143] A transmitter chain 1612 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1612 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1612 may also include at least one poweramplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0144] Figure 17 illustrates an example of a processor 1700 in accordance with aspects of the present disclosure. The processor 1700 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1700 may include a controller 1702 configured to perform various operations in accordance with examples as described herein. The processor 1700 may optionally include at least one memory 1704, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1700 may optionally include one or more arithmetic-logic units (ALUs) 1706. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0145] The processor 1700 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1700) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0146] The controller 1702 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1700 to cause the processor 1700 to support various operations in accordance with examples as described herein. For example, the controller 1702 may operate as a control unit of the processor 1700, generating control signals that manage the operation of various components of the processor 1700. These control signals include enabling or disablingfunctional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0147] The controller 1702 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1704 and determine subsequent instruction(s) to be executed to cause the processor 1700 to support various operations in accordance with examples as described herein. The controller 1702 may be configured to track memory address of instructions associated with the memory 1704. The controller 1702 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1702 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1700 to cause the processor 1700 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1702 may be configured to manage flow of data within the processor 1700. The controller 1702 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1700.

[0148] The memory 1704 may include one or more caches (e.g., memory local to or included in the processor 1700 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1704 may reside within or on a processor chipset (e.g., local to the processor 1700). In some other implementations, the memory 1704 may reside external to the processor chipset (e.g., remote to the processor 1700).

[0149] The memory 1704 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1700, cause the processor 1700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1702 and / or the processor 1700 may be configured to execute computer-readable instructions stored in the memory 1704 to cause the processor 1700 to perform various functions. For example, the processor 1700 and / or the controller 1702 may be coupled with or to the memory 1704, the processor 1700, the controller 1702, and the memory 1704 may be configured to perform various functions described herein. In some examples, theprocessor 1700 may include multiple processors and the memory 1704 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0150] The one or more ALUs 1706 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1706 may reside within or on a processor chipset (e.g., the processor 1700). In some other implementations, the one or more ALUs 1706 may reside external to the processor chipset (e.g., the processor 1700). One or more ALUs 1706 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1706 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1706 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1706 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1706 to handle conditional operations, comparisons, and bitwise operations.

[0151] The processor 1700 may support wireless communication in accordance with examples as disclosed herein. For example, the processor 1700 may be configured to support one or more means for obtaining, at a first protocol layer, a data packet of an application data flow, wherein the data packet comprises a payload associated with a data unit of an application and metadata including one or more attributes of the data unit; performing an identification operation to identify, from the data packet, the metadata and the data unit; generating, based on the identified metadata, a protocol header comprising information associated with the data unit; generating a protocol data unit “PDU” comprising the protocol header and the pay load of the data packet; and outputting the PDU to a second protocol layer for transmission to a receiving entity. For example, the processor 1700 may be configured to support one or more means for obtaining, at a first protocol layer, a protocol data unit “PDU”, wherein the PDU comprises a payload of a data packet associated with a data unit and a protocol header including information associated with thedata unit; performing an identification operation to identify, based on the protocol header, the data unit and metadata comprising one or more attributes of the data unit; and outputting, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

[0152] Figure 18 illustrates an example of a NE 1800 in accordance with aspects of the present disclosure. The NE 1800 may include a processor 1802, a memory 1804, a controller 1806, and a transceiver 1808. The processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0153] The processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0154] The processor 1802 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1802 may be configured to operate the memory 1804. In some other implementations, the memory 1804 may be integrated into the processor 1802. The processor 1802 may be configured to execute computer-readable instructions stored in the memory 1804 to cause the NE 1800 to perform various functions of the present disclosure.

[0155] The memory 1804 may include volatile or non-volatile memory. The memory 1804 may store computer-readable, computer-executable code including instructions when executed by the processor 1802 cause the NE 1800 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1804 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0156] In some implementations, the processor 1802 and the memory 1804 coupled with the processor 1802 may be configured to cause the NE 1800 to perform one or more of the functions described herein (e.g., executing, by the processor 1802, instructions stored in the memory 1804). For example, the processor 1802 may support wireless communication at the NE 1800 in accordance with examples as disclosed herein. For example, the NE 1800 may be configured to support one or more means for obtaining, at a first protocol layer, a data packet of an application data flow, wherein the data packet comprises a payload associated with a data unit of an application and metadata including one or more attributes of the data unit; performing an identification operation to identify, from the data packet, the metadata and the data unit; generating, based on the identified metadata, a protocol header comprising information associated with the data unit; generating a protocol data unit “PDU” comprising the protocol header and the payload of the data packet; and outputting the PDU to a second protocol layer for transmission to a receiving entity. For example, the NE 1800 may be configured to support one or more means for obtaining, at a first protocol layer, a protocol data unit “PDU”, wherein the PDU comprises a payload of a data packet associated with a data unit and a protocol header including information associated with the data unit; performing an identification operation to identify, based on the protocol header, the data unit and metadata comprising one or more attributes of the data unit; and outputting, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

[0157] The controller 1806 may manage input and output signals for the NE 1800. The controller 1806 may also manage peripherals not integrated into the NE 1800. In some implementations, the controller 1806 may utilise an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1806 may be implemented as part of the processor 1802.

[0158] In some implementations, the NE 1800 may include at least one transceiver 1808. In some other implementations, the NE 1800 may have more than one transceiver 1808. The transceiver 1808 may represent a wireless transceiver. The transceiver 1808 may include one or more receiver chains 1810, one or more transmitter chains 1812, or a combination thereof.

[0159] A receiver chain 1810 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1810 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1810 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 1810 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1810 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0160] A transmitter chain 1812 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1812 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1812 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1812 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0161] Figure 19 illustrates a flowchart of a method 1900 in accordance with aspects of the present disclosure. The operations of the method 1900 may be implemented by an apparatus for wireless communication (such as a UE or a NE, as a transmission entity) as described herein. In some implementations, the apparatus may execute a set of instructions to control the function elements of the apparatus to perform the described functions.

[0162] At 1902, the method 1900 may include obtaining, at a first protocol layer, a data packet of an application data flow. The data packet comprises a payload associated with a data unit of an application and metadata including one or more attributes of the data unit. Pay load of one or more data packets, including the payload of the data packet, may define the data unit. For example, the metadata may be prepared by a layer higher than the first protocol layer. For example, the one or more attributes of the data unit may include one or more application-specific attributes. For example, the one or more attributes of the data unit may be associated with a context of the application. For example, the one or more attributes of the data unit may include, e.g., importance of the data unit to the application and / or dependency of the data unit on one or more other data units for the application. For example, the first protocol layer is a Packet Data Convergence Protocol “PDCP” layer with application awareness, and the second protocol layer is a layer below the PDCP layer. For example, the first protocol layer is a layer with application awareness (e.g., AAL disclosed herein) above a Packet Data Convergence Protocol “PDCP” layer, and the second protocol layer is a layer below the first protocol layer (e.g., the PDCP layer). The operations of 1902 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1902 may be performed by a UE as described with reference to Figure 16. In some implementations, aspects of the operations of 1902 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 1902 may be performed by a NE as described with reference to Figure 18.

[0163] At 1904, the method 1900 may include performing an identification operation to identify, from the data packet, the metadata and the data unit. For example, the identification operation may include the identification of the metadata from the data packet, and the identification of the data unit with which the pay load of the data packet is associated based on the identified metadata. For example, the identification of the metadata may be based on one or more identification rules, which may be obtained from a network entity, such as a session management function node “SMF”. The operations of 1904 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1904 may be performed by a UE as described with reference to Figure 16. In some implementations, aspects of the operations of 1904 may be performedby a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 1904 may be performed by a NE as described with reference to Figure 18.

[0164] At 1906, the method 1900 may include generating, based on the identified metadata, a protocol header including information associated with the data unit. For example, the generation of the protocol header may include mapping one or more attributes contained in the metadata to one or more corresponding fields in the protocol header. The mapping can be considered as data formatting procedure. For example, the mapping may be performed based on one or more mapping rules, which may be obtained from a network entity, such as a session management function node “SMF”. For example, the protocol header may include: sequence number of the data unit, size of the data unit, an end PDU of the data unit, sequence number of the PDU, importance of the data unit to the application, type of the data unit, dependency of the data unit on one or more other data units for the application, inter-media component synchronisation threshold, application-layer forward error correction related information, timestamp information, codec related information, burst related information, or any combination thereof. The operations of 1906 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1906 may be performed by a UE as described with reference to Figure 16. In some implementations, aspects of the operations of 1906 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 1906 may be performed by a NE as described with reference to Figure 18.

[0165] At 1908, the method 1900 may include generating a protocol data unit “PDU” including the protocol header and the pay load of the data packet. The operations of 1908 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1908 may be performed by a UE as described with reference to Figure 16. In some implementations, aspects of the operations of 1908 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 1908 may be performed by a NE as described with reference to Figure 18.

[0166] At 1910, the method 1900 may include outputting the PDU to a second protocol layer for transmission to a receiving entity. The operations of 1910 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1910 may be performed by a UE as described with reference to Figure 16. In some implementations, aspects of the operations of 1910 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 1910 may be performed by a NE as described with reference to Figure 18.

[0167] Although not illustrated, the method 1900 may further include assigning a transmission priority to the PDU, and outputting the transmission priority to the second protocol layer. The transmission priority affects a priority for transmitting the PDU to the receiving entity. The transmission priority may be provided to the second protocol layer separately from the PDU. Although not illustrated, the method 1900 may further include discarding PDU based on: importance of the corresponding PDU or the associated data unit, remaining delay associated with the corresponding PDU or the associated data unit, linear or quadratic cost associated with the corresponding PDU or the associated data unit, mean square error associated with the corresponding PDU or the associated data unit, energy consumption-related parameter associated with the corresponding PDU or the associated data unit, dependency information associated with the corresponding PDU or the associated data unit, or any combination thereof. The discarded PDU may not be output to the second protocol layer or otherwise will not be transmitted to the receiving entity.Although not illustrated, the method 1900 may further include, in response to outputting the PDU for transmission, receiving a response from the receiving entity. The response may include a status report that includes an acknowledgement of successful reception of the PDU or the data unit by the receiving entity, a request for re-transmission of the PDU or the data packet, and / or a request for transmission of a (e.g., a specific) data unit. These operations may be performed in accordance with examples as described herein, e.g., by a UE as described with reference to Figure 16, a processor as described with reference to Figure 17, or a NE as described with reference to Figure 18.

[0168] It should be noted that the method 1900 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0169] Figure 20 illustrates a flowchart of a method 2000 in accordance with aspects of the present disclosure. The operations of the method 2000 may be implemented by an apparatus for wireless communication (such as a NE or a UE, as a receiving entity) as described herein. In some implementations, the apparatus may execute a set of instructions to control the function elements of the apparatus to perform the described functions.

[0170] At 2002, the method 2000 may include obtaining, at a first protocol layer, a protocol data unit “PDU”, the PDU includes a payload of a data packet associated with a data unit and a protocol header including information associated with the data unit. The operations of 2002 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2002 may be performed by a NE as described with reference to Figure 18. In some implementations, aspects of the operations of 2002 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 2002 may be performed by a UE as described with reference to Figure 16. For example, the first protocol layer is a Packet Data Convergence Protocol “PDCP” layer with application awareness. For example, the first protocol layer is a layer with application awareness (e.g., AAL disclosed herein) above a Packet Data Convergence Protocol “PDCP” layer.

[0171] At 2004, the method 2000 may include performing an identification operation to identify, based on the protocol header, the data unit and metadata including one or more attributes of the data unit. The operations of 2004 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2004 may be performed by a NE as described with reference to Figure 18. In some implementations, aspects of the operations of 2004 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 2004 may be performed by a UE as described with reference to Figure 16.

[0172] At 2006, the method 2000 may include outputting, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity thatprovides the PDU. For example, the response may include: a status report that includes an acknowledgement of successful reception of the PDU or the data unit, a request for retransmission of the PDU or the data packet, and / or a request for transmission of a data unit. The operations of 2006 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2006 may be performed by a NE as described with reference to Figure 18. In some implementations, aspects of the operations of 2006 may be performed by a processor as described with reference to Figure 17. In some implementations, aspects of the operations of 2006 may be performed by a UE as described with reference to Figure 16.

[0173] Although not illustrated, the method 2000 may further include providing the pay load of the PDU to a second (e.g., upper) protocol layer for processing based on importance and / or delay criticality of the PDU and / or the data unit.

[0174] It should be noted that the method 2000 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0175] The method 1900 and the method 2000 may be complementary. For example, an apparatus operating as a transmission entity may perform method 1900 and an apparatus operating as a receiving entity may perform method 2000.

[0176] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

CLAIMSWhat is claimed is:

1. An apparatus for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to: obtain, at a first protocol layer, a data packet of an application data flow, the data packet comprising a payload associated with a data unit of an application and metadata comprising one or more attributes of the data unit; perform an identification operation to identify, from the data packet, the metadata and the data unit; generate, based on the identified metadata, a protocol header comprising information associated with the data unit; generate a protocol data unit “PDU” comprising the protocol header and the pay load of the data packet; and output the PDU to a second protocol layer for transmission to a receiving entity.

2. The apparatus of claim 1 , wherein the identification operation comprises: identify, from the data packet, the metadata; and identify, based on the identified metadata, the data unit with which the pay load of the data packet is associated.

3. The apparatus of claim 2, wherein the identification of the metadata is based on one or more identification rules obtained from a network entity.

4. The apparatus of claim 3, wherein the network entity comprises a session management function node “SMF”.

5. The apparatus of any one of claims 1 to 4, wherein the generation of the protocol header comprises mapping one or more attributes contained in the metadata to one or more corresponding fields in the protocol header.

6. The apparatus of any one of claims 1 to 5, wherein the one or more attributes of the data unit is associated with a context of the application.

7. The apparatus of any one of claims 1 to 6, wherein the protocol header comprises: sequence number of the data unit; size of the data unit; an end PDU of the data unit; sequence number of the PDU; importance of the data unit to the application; type of the data unit; dependency of the data unit on one or more other data units for the application; or any combination thereof.

8. The apparatus of any one of claims 1 to 7, wherein the at least one processor is further configured to: assign a transmission priority to the PDU, the transmission priority affects a priority for transmitting the PDU to the receiving entity; and output the transmission priority to the second protocol layer.

9. The apparatus of claim any one of claims 1 to 8, wherein the at least one processor is further configured to: discard PDU based on importance of the corresponding PDU or the associated data unit, remaining delay associated with the corresponding PDU or the associated data unit, linear or quadratic cost associated with the corresponding PDU or the associated data unit, mean square error associated with the corresponding PDU or the associated data unit, energy consumption-related parameter associated with the corresponding PDU orthe associated data unit, dependency information associated with the corresponding PDU or the associated data unit, or any combination thereof.

10. The apparatus of any one of claims 1 to 9, wherein the first protocol layer is a Packet Data Convergence Protocol “PDCP” layer, and the second protocol layer is a layer below the PDCP layer.

11. The apparatus of any one of claims 1 to 9, wherein the first protocol layer is a layer above a Packet Data Convergence Protocol “PDCP” layer, and the second protocol layer is a layer below the first protocol layer.

12. The apparatus of any one of claims 1 to 11, wherein at least one processor is further configured to: in response to outputting the PDU for transmission, receive a response from the receiving entity, the response comprises: a status report that includes an acknowledgement of successful reception of the PDU or the data unit by the receiving entity; a request for re-transmission of the PDU or the data packet; and / or a request for transmission of a data unit.

13. The apparatus of any one of claims 1 to 12, wherein the data unit comprises payload of one or more data packets, including the pay load of the data packet14. The apparatus of any one of claims 1 to 13, wherein the apparatus is a user equipment “UE”.

15. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: obtain, at a first protocol layer, a data packet of an application data flow, the data packet comprising a payload associated with a data unit of an application and metadata comprising one or more attributes of the data unit;perform an identification operation to identify, from the data packet, the metadata and the data unit; generate, based on the identified metadata, a protocol header comprising information associated with the data unit; generate a protocol data unit “PDU” comprising the protocol header and the pay load of the data packet; and output the PDU to a second protocol layer for transmission to a receiving entity.

16. A method performed by an apparatus, the method comprising: obtaining, at a first protocol layer, a data packet of an application data flow, the data packet comprising a payload associated with a data unit of an application and metadata comprising one or more attributes of the data unit; performing an identification operation to identify, from the data packet, the metadata and the data unit; generating, based on the identified metadata, a protocol header comprising information associated with the data unit; generating a protocol data unit “PDU” comprising the protocol header and the pay load of the data packet; and outputting the PDU to a second protocol layer for transmission to a receiving entity.

17. An apparatus for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to: obtain, at a first protocol layer, a protocol data unit “PDU”, the PDU comprising a pay load of a data packet associated with a data unit and a protocol header comprising information associated with the data unit;perform an identification operation to identify, based on the protocol header, the data unit and metadata comprising one or more attributes of the data unit; and output, based on the identified data unit and / or the identified metadata, a response for transmission to a transmission entity that provides the PDU.

18. The apparatus of claim 17, wherein the response comprises: a status report that includes an acknowledgement of successful reception of the PDU or the data unit; a request for re-transmission of the PDU or the data packet; and / or a request for transmission of a data unit.

19. The apparatus of claim 17 or 18, wherein the at least one processor is further configured to: provide the pay load of the PDU to a second protocol layer for processing based on importance and / or delay criticality of the PDU and / or the data unit.

20. The apparatus of any one of claims 17 to 19, wherein the apparatus is a network equipment “NE”.

Images