Methods and devices for facilitating synchronized delivery of dependent data packets in wireless communication
By using headers with inter-dependency information and scheduling mechanisms, the method synchronizes delivery of inter-dependent data packets, addressing the challenges of high data rate and low latency in wireless communication, particularly for XR applications.
Patent Information
- Application Number
- PCT/EP2025/067517
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-08-07
- Filing Date
- 2025-06-23
- Publication Date
- 2026-02-12
AI Technical Summary
Existing wireless communication technologies struggle to efficiently manage and synchronize the delivery of inter-dependent data packets across different data streams, particularly in scenarios requiring high data rates and low latency, such as Extended Reality (XR) applications, where visual and audio data need to be synchronized.
A method involving a wireless network and a user equipment (UE) that utilizes headers with inter-dependency information fields to compile and schedule data units, ensuring synchronized delivery of inter-dependent data packets by incorporating mutual delay budgets and temporary sequence numbers to maintain timing requirements.
Ensures synchronized delivery of inter-dependent data packets, meeting latency and reliability requirements by aligning transmission and reception of data units based on inter-dependency information, thereby enhancing the handling of multi-modal data streams.
Smart Images

Figure EP2025067517_12022026_PF_FP_ABST
Abstract
Description
[0001] METHODS AND DEVICES FOR FACILITATING SYNCHRONIZED DELIVERY
[0002] OF DEPENDENT DATA PACKETS IN WIRELESS COMMUNICATION
[0003] Technical field
[0004] This disclosure is related to wireless communication between a wireless network and a wireless device. Specifically, solutions are provided for facilitating and managing synchronized delivery of inter-dependent data packets of different data streams to the wireless device.
[0005] Background
[0006] Various protocols and technical requirements for wireless communication have been standardized under supervision of inter alia the 3rd Generation Partnership Project (3GPP). Improvement and further development are continuously carried out, and new or amended functions and features are thus implemented in successive releases of the technical specifications providing the framework for wireless communication.
[0007] Wireless communication may in various scenarios be carried out between a wireless network and a wireless device. The wireless network typically comprises an access network, also referred to as RAN (Radio Access Network), including a plurality of access nodes, which historically have been referred to as base stations. In a 5G radio access network the RAN may be referred to as NG-RAN (Next Generation RAN), and the base station may be referred to as a gNB. Each access node may be configured to serve one or more cells of a cellular wireless network. The RAN is in turn connected to a core network (CN) of the wireless network, referred to as 5GC for 5G. A variety of different types of wireless devices may be configured to communicate with the access network, and such wireless devices are generally referred to as User Equipment (UE). Communication which involves transmission from the UE and reception in the wireless network is generally referred to as Uplink (UL) communication, whereas communication which involves transmission from the wireless network and reception in the UE is generally referred to as Downlink (DL) communication. DL communication may include communication of data of data streams, received in the CN for delivery to one or more UEs. While wireless network specifications were originally developed to support voice traffic, communication of data between the UE and the wireless network is nowadays the dominating use case. 5G NR (New Radio) was introduced to support different types of service categories, including eMBB (Enhanced Mobile Broadband) for high data rates, URLLC (Ultra Reliable Low Latency Communications) for low latency and / or high reliability, and mMTC (Massive Machine-Type Communications) for a high number of low-complexity devices. As capacity increases, new types of data transfer and new purposes for data communication continue to emerge. For example, Extended Reality (XR) refers to various types of augmented, virtual, and mixed environments, where human-to-machine and human-to -human communications may be performed with the assistance of handheld and wearable end user devices (UEs). XR covers several applications, such as Virtual Reality (VR), Augmented Reality (AR), and Cloud Gaming (CG), in which the main characteristics are requiring relatively high data rates and low latency. There are also some other applications with multiple data streams requiring different characteristics that are relevant, like factory automation, remote machine operation, UAV operation, or just to differentiate between video and audio.
[0008] These types of operation are typically sensitive to latency and may require high data rate. New aspects are studied including support for so-called multi-modality. Multimodal Data may refer to data destined for the same receiving device / UE, e.g., video and audio which needs to be synchronized, which comes from the same application but in different streams since it has different QoS requirements. In other aspects, multi-modal data may refer to input data from different kinds of devices / sensors or the output data to different kinds of destinations (e.g. one or more UEs) required for the same task or application. NG-RAN and 5GC ensure quality of service (QoS), e.g., reliability and target delay, by mapping packets to appropriate QoS Flows and data radio bearers (DRBs). With the introduction of multi-modality, challenges arise with respect to handling of dependencies between the different modality streams.
[0009] Summary
[0010] An overall objective is to provide solutions for targeting the aforementioned challenges, with respect to DL communication of data streams comprising interdependent data. The proposed solution is defined by the terms of the independent claims, while further advantageous embodiments are set out in the dependent claims and in the detailed description.
[0011] According to a first aspect, the proposed solution relates to a method carried out in a wireless network for processing data for downlink transmission to a UE, wherein the method comprises: obtaining a first data packet associated with a first data stream; compiling a data unit comprising the first data packet and a header, wherein the header comprises an information field for indicating inter-dependency between the first data packet and a second data packet associated with a second data stream.
[0012] The proposed solution also refers to a core network node of a wireless network, comprising logic circuitry configured to carry out the outlined steps.
[0013] According to another aspect, the proposed solution relates to a method performed by a UE, wherein the method comprises: receiving data units from a wireless network, wherein each data unit comprises a data packet and a header; processing the data packets in an order based on information comprised in the respective header, including an information field for indicating inter-dependency between data packets associated with different data streams.
[0014] The proposed solution also refers to a UE configured to receive downlink data from a wireless network, comprising logic circuitry configured to carry out the mentioned steps.
[0015] Based on the proposed solution, a mechanism is obtained which facilitates scheduling DL transmission and handling at reception in the UE of inter-dependent data.
[0016] Brief description the drawings
[0017] Fig. 1 schematically illustrates an implementation of a wireless communication system, in which at least downlink data communication to a UE may be carried out by radio communication. Various entities of a core network of the wireless network are further shown. Fig. 2 schematically illustrates a UE configured to operate with the wireless network according to various examples.
[0018] Fig. 3 schematically illustrates an access node configured to operate in the wireless network for facilitating and managing synchronized delivery of inter-dependent data packets of different data streams to the UE according to various examples.
[0019] Fig. 4 schematically illustrates a core network node configured to operate in the wireless network for facilitating and managing synchronized delivery of inter-dependent data packets of different data streams to the UE according to various examples.
[0020] Fig. 5 shows an example of a QoS architecture in 5G in which the proposed solution may be employed.
[0021] Fig. 6 schematically illustrates configuration and use of header information comprising information on inter-dependency between data units according to various examples of the proposed solution.
[0022] Fig. 7 schematically illustrates aspects associated with buffering and scheduling according to various aspects of the proposed solution.
[0023] Detailed description
[0024] In the following description, for the purposes of explanation and not limitation, details are set forth herein related to various examples. However, it will be apparent to those skilled in the art that the present invention may be practiced in other examples that depart from these specific details. In some instances, detailed descriptions of well- known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail. The functions of the various elements including functional blocks, including but not limited to those labeled or described as “computer”, “processor” or “controller”, may be provided through the use of hardware such as circuit hardware and / or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and / or computer-implemented and are thus machine-implemented. In terms of hardware implementation, the functional blocks may include or encompass, without limitation, digital signal processor (DSP) hardware, reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC), and (where appropriate) state machines capable of performing such functions. In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer and processor and controller may be employed interchangeably herein. When provided by a computer or processor or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, use of the term “processor” or “controller” shall also be construed to refer to other hardware capable of performing such functions and / or executing software, such as the example hardware recited above.
[0025] Before presenting aspects and examples of the proposed solution, context and devices for use of the proposed solution will be briefly described with reference to the drawings. The drawings are to be regarded as being schematic representations and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof. The description and drawings are predominantly provided in the context of a 5G network for the sake of easy understanding, while this shall merely be seen as an example.
[0026] Fig. 1 illustrates a high-level perspective of operation of a UE 10 in a wireless system, configured to communicate with a wireless communication network 100, denoted wireless network 100 for short herein. Fig. 1 is useful for context of the proposed solution and illustrates various entities and functions which cooperate in wireless system.
[0027] The wireless network 100 may be a radio communication network 100, configured to operate under the provisions of 5G as specified by 3GPP, according to various examples, or further generations. The wireless network 100 may comprise a core network (CN) 110, connectable to an external network 130 such as the Internet. The core network may comprise a plurality of core network nodes, which realize logical functions. For the example of a 5G system, as illustrated, this may, inter alia, include the Access and Mobility Management Function (AMF) 101, a Session Management Function (SMF) 102, a User Plane Function (UPF) 103, a Network Exposure Function (NEF) 104, a Policy Control Function (PCF) 105, all of which are legacy functions of the 5G system (5GS). One or more Application Functions (AF) 106 may be deployed inside or outside of the 5G system i.e., as an application running on an application server (AS) 107 connected to the external network e.g., the Internet, which application server provides data for communication in the wireless system. Operators may deploy the AF 106 as trusted or non-trusted. A trusted AF 106 may have access to all interface with the CN 110 while an un-trusted must access anything inside the CN via the NEF 104.
[0028] The wireless network 100 further comprises an access network 120, comprising a plurality of access nodes (AN) including access node 121, configured for radio communication with wireless devices including the UE 10.
[0029] Fig. 2 schematically illustrates an example of the UE 10 for use in a wireless network 100 as presented herein and configured for carrying out various method steps as outlined. Some relevant elements or functions of the UE 10 are shown in the drawing. The UE 10 may however include other features and elements than those shown in the drawing or described herein, such as a casing, a user interface, sensors, etc., but these are left out for the sake of simplicity.
[0030] The UE 10 comprises a radio transceiver 213, also referred to herein as modem 213, for communicating with other entities of the radio communication network 100, such as the access node 121, in one or more frequency bands. The transceiver 213 may thus include a receiver chain (Rx) and a transmitter chain (Tx), for communicating through at least an air interface, referred to as Uu in 3GPP. The transceiver 213 may be or comprise a modem configured to encode, transmit, receive and decode data using radio waves.
[0031] The UE 10 may further comprise an antenna system 214, which may include one or more antennas, antenna ports or antenna arrays. In various examples the UE 10 is configured to operate with a single beam, wherein the antenna system 214 is configured to provide an isotropic gain to transmit radio signals. In other examples, the antenna system 214 may comprise a plurality of antennas for operation of different beams in transmission and / or reception. The antenna system 214 is connected to the transceiver 213.
[0032] The UE 10 further comprises logic circuitry 210 configured to control data and signal communication via the radio transceiver on a physical channel 140 to a serving access node 121 of the wireless network 100. The logic circuitry is further configured to control the UE to carry out any of the steps associated with the proposed solution as outlined herein.
[0033] The logic circuitry 210 may include a processing device 211, including one or multiple processors, microprocessors, data processors, co-processors, and / or some other type of component that interprets and / or executes instructions and / or data. The processing device 211 may be implemented as hardware (e.g., a microprocessor, etc.) or a combination of hardware and software (e.g., a system-on-chip (SoC), an applicationspecific integrated circuit (ASIC), etc.). The processing device 211 may be configured to perform one or multiple operations based on an operating system and / or various applications or programs.
[0034] The logic circuitry 210 may further include memory storage 212, which may include one or multiple memories and / or one or multiple other types of storage mediums. For example, the memory storage 212 may include a random access memory (RAM), a dynamic random access memory (DRAM), a cache, a read only memory (ROM), a programmable read only memory (PROM), flash memory, and / or some other type of memory. The memory storage 212 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.). The memory storage 212 is configured for holding computer program code, which may be executed by the processing device 211, wherein the logic circuitry 210 is configured to control the UE 10 to carry out any of the method steps as provided herein. Software defined by said computer program code may include an application or a program that provides a function and / or a process. The software may include device firmware, an operating system (OS), or a variety of applications that may execute in the logic circuitry 210.
[0035] The UE 10 further comprises a power supply 215 (e.g., a battery) that provides energy to the other components of the UE 10.
[0036] Fig. 3 schematically illustrates a radio node in the form of an access node 121 of the wireless network 100 as presented herein, and for carrying out the method steps as outlined. An access node 121 may have one or more transmission and reception point(s) TRP(s). In various examples, the access node 121 is a radio base station for operation in the radio communication network 100, to serve one or more radio UEs, such as the UE 10.
[0037] The access node 121 may comprise a wireless transceiver 313, such as a radio transceiver for communicating with other entities of the radio communication network 100, such as the terminal 10. The transceiver 313 may thus include a radio receiver and transmitter for communicating through at least an air interface. The transceiver may comprise a radio modem.
[0038] The access node 121 may further comprise, or be connected to, an antenna 314, which may include an antenna array. The antenna is connected to the transceiver 313.
[0039] The access node 121 further comprises logic circuitry 310 configured to control the access node 121 to communicate with the UE 10 via the radio transceiver 313 on the physical channel 140. The logic circuitry 310 may realize a scheduler for scheduling communication of a data set according to the solutions proposed herein, and for configuring the UE to operate according to the scheduling, based on a related QoS.
[0040] The logic circuitry 310 may include a processing device 311, including one or multiple processors, microprocessors, data processors, co-processors, and / or some other type of component that interprets and / or executes instructions and / or data. Processing device 311 may be implemented as hardware (e.g., a microprocessor, etc.) or a combination of hardware and software (e.g., a system-on-chip (SoC), an applicationspecific integrated circuit (ASIC), etc.). The processing device 311 may be configured to perform one or multiple operations based on an operating system and / or various applications or programs.
[0041] The logic circuitry 310 may further include memory storage 312, which may include one or multiple memories and / or one or multiple other types of storage mediums. For example, memory storage 312 may include a random access memory (RAM), a dynamic random access memory (DRAM), a cache, a read only memory (ROM), a programmable read only memory (PROM), flash memory, and / or some other type of memory. Memory storage 312 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.). The memory storage 312 is configured for holding computer program code, which may be executed by the processing device 311, wherein the logic 310 is configured to control the access node 121 to carry out any of the method steps as provided herein. Software defined by said computer program code may include an application or a program that provides a function and / or a process. The software may include device firmware, an operating system (OS), or a variety of applications that may execute in the logic 310.
[0042] The access node comprises a scheduler 315, or scheduling function, which as such may be realized by operation of program code in the logic circuitry 310. The scheduler is operated for allocating resources for communication using the transceiver 313 over radio, such as with the UE 10. Each resource may in this context be indicative of a unit of time and / or frequency of a radio frame structure, according to the established art.
[0043] The access node 121 may further comprise an interface 316, configured for communication with the core network 110.
[0044] Fig. 4 schematically illustrates a network node in the form of a core network (CN) node 400 of the wireless network 100 as presented herein, and for carrying out the method steps as outlined.
[0045] The CN node 400 comprises logic circuitry 111, as is also indicated in Fig. 1. The logic circuitry 111 is configured to control the CN node 400 to, inter alia, manage data received in or originating from the CN 110 for DL transmission to at least the UE 10 via the RAN 120. The logic circuitry may implement one or more of the mentioned CN functions, such as the AMF 101, the SMF 102, the UPF 103, the NEF 104, and the PCF 105.
[0046] The logic circuitry 111 may include a processing device 112, including one or multiple processors, microprocessors, data processors, co-processors, and / or some other type of component that interprets and / or executes instructions and / or data. Processing device 112 may be implemented as hardware (e.g., a microprocessor, etc.) or a combination of hardware and software (e.g., a system-on-chip (SoC), an applicationspecific integrated circuit (ASIC), etc.). The processing device 112 may be configured to perform one or multiple operations based on an operating system and / or various applications or programs.
[0047] The logic circuitry 111 may further include memory storage 113, which may include one or multiple memories and / or one or multiple other types of storage mediums. For example, memory storage 113 may include a random access memory (RAM), a dynamic random access memory (DRAM), a cache, a read only memory (ROM), a programmable read only memory (PROM), flash memory, and / or some other type of memory. Memory storage 113 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.). The memory storage 113 is configured for holding computer program code, which may be executed by the processing device 112, wherein the logic 111 is configured to control the network node 400 to carry out any of the method steps as provided herein. Software defined by said computer program code may include an application or a program that provides a function and / or a process. The software may include device firmware, an operating system (OS), or a variety of applications that may execute in the logic 111.
[0048] The network node 400 further comprises one or more interfaces 114, such as an interface configured for communication with further functions within the CN 110 (as listed), an interface for communication with the RAN 120, and an interface for communication with entities outside the wireless network 100 for receiving data for DL communication, as indicated in Fig. 1.
[0049] Various aspects of the proposed solution will now be described. The context of the proposed solutions is DL transmission of inter-dependent data, i.e. different packets of data which are intended to be used in the UE (e.g., executed or presented) in combination with each other. Typically, this may refer to different types of data which are associated with each other, such as visual data, audio data, tactile data, or other, which relates to a common event or item. Such different types of data may be received in the CN 110 in different data streams or data flows. This may, e.g., be the case in XR applications. This may be referred to as multi-modality, where multi-modal data comprises more than one single-modal data, and there is strong dependency among each single-modal data, single-modal data can be seen as one type of data.
[0050] In 5G, communication of data is accomplished in QoS flows. This, inter alia, discussed in chapter 5.7 of 3GPP TS 23.501 V18.5.0, which relates to system architecture for the 5G System (5GS), and also in chapter 12 of 3GPP TS 38.300 VI 8.2.0 relating to NR and NG-RAN. With reference to legacy procedures as set out in those documents, NG-RAN and 5GC ensure quality of service, e.g., reliability and target delay, by mapping packets to appropriate QoS Flows and DRBs. There is a 2-step mapping of IP-flows to QoS flows (Non Access Stratum - NAS) and from QoS flows to DRBs (Access Stratum).
[0051] 5QI (5G QoS Identifier) is associated to QoS characteristics giving guidelines for setting node specific parameters for each QoS Flow, e.g., Priority level, Packet Delay Budget (including Core Network Packet Delay Budget), Packet Error Rate, Averaging window, Maximum Data Burst Volume. This implies that each packet in a QoS flow is treated according to the same QoS requirements. The network decides which 5QIs are mapped to each QoS flow.
[0052] At Access Stratum level, the DRB defines the packet treatment on the radio interface (Uu). A DRB serves packets with the same packet forwarding treatment. The QoS flow to DRB mapping by NG-RAN is based on QoS Flow ID (QFI) and the associated QoS profiles (i.e. QoS parameters and QoS characteristics). Separate DRBs may be established for QoS flows requiring different packet forwarding treatment.
[0053] Fig. 5 schematically illustrates the QoS architecture of 5G, as indicated in figure 12-1 of TS 38.300. With reference to legacy procedures and this drawing, the following can be noted:
[0054] For each UE, 5GC establishes one or more PDU Sessions, where PDU stands for Packet Data Unit. PDU Session Establishment is the process of establishing a data path between the UE 10 and the 5G core network 110. A PDU session is a logical connection between the UE and a data network, such as the internet or a private network.
[0055] NG-RAN 120 establishes at least one DRB together with the PDU Session and additional DRB(s) for QoS flow(s)
[0056] The NG-RAN 120 maps packets belonging to different PDU sessions to different DRBs.
[0057] NAS level packet filters in the UE 10 and in the 5GC 110 associate DL (and UL) packets with QoS Flows.
[0058] AS-level mapping rules in the UE 10 and in the NG-RAN 120 associate DL (and UL) QoS Flows with DRBs.
[0059] In the CN 110, the UPF 103 is transporting the different media streams and maps packets to QoS flows that are received in the access node (gNB) 121, whereas the PCF 105 handles QoS policies and sets up the configuration on the usage of the QoS flows, including the QoS of the different streams carrying each mode in a multi-modality connection. The SDAP (Service Data Adaptation Protocol) layer, as described in 3GPP TS 37.324 V18.0.0, is performing the actual mapping between QoS flow and DRB. The MAC layer, as described in 3GPP TS 38.321 V18.2.0, is amongst other things responsible for building a transport block to be transmitted by the PHY layer by assembling packets “RLC SDU” for one or more radio bearers that are available in L2 transmit buffers. In the access node (gNB) 121, prioritization is done based on QoS parameters and the data is scheduled to be transmitted based on the prioritization.
[0060] In legacy NR up to Rel-18 including XR, different QoS flows are mapped to different Radio Bearers to handle specific QoS requirement. Though with multi-modal traffic flows, there may exist an inter-dependency between the different flows. The inter dependency has been described and discussed in SA2, see 23.700-60 related to XRM study in Rel-18, where requirements from SAI, are described and referred too. In 3GPP TS 22.261 V19.7.0, clauses 6.43 and 7.11 two kinds of coordination transmission requirements are discussed, for reference:
[0061] 1) The delay difference between two flows should be less than some values e.g., for immersive multi-modality VR applications, the synchronization threshold for visual- tactile is less than 15ms (if the visual data is delayed compared to the tactile) or less than 50ms (if the tactile is delayed compared to the visual).
[0062] 2) The typical delay requirement for specific flow, e.g., for immersive multimodal VR UL, the max allowed end-to-end latency for haptic data is 5ms
[0063] While these are only examples related to muti-modality, at least the first paragraph indicates requirements associated with inter-dependent data.
[0064] Based on the foregoing, the solutions outlined herein are proposed for ensuring, or increasing the chances of meeting requirements related to, proper delivery and handling of inter-dependent data, such as in the context of multi-modality.
[0065] Fig. 6 schematically illustrates various aspects of the proposed solution, including various method steps. An application 600, e.g., managed by the AF 106, provides a plurality of data streams, which are obtained 6001 in the CN node 400. At least some of the data packets, e.g., IP packets, obtained in the data streams are inter-dependent. This may entail that the inter-dependent data from two or more data streams shall be handled or used, e.g. processed, executed or presented (visual, audio, tactile, or other), in correlation which each other in the UE 10 or its connected devices (visor, wristband, etc.). This may include that they are intended to be used within a certain time offset or limit. The data of the different data streams may nevertheless subsequently be conveyed in DL to the UE 10 using different QoS flows, potentially on different DRBs or on the same DRB (as in Fig. 5). Information of the inter-dependency may be provided in the respective data packets from the application 600, or separately as overhead information from the application 600. The information of the inter-dependency may include, in or for a certain data packet, at least an indicator of one or more other inter-dependent packet(s). In some examples, the PCF 105 may identify a multi-modality ID, identifying inter-dependent data streams, from the IP packets of such multi-modal data streams. Further details on the information of the inter-dependency will be outlined further below.
[0066] According to one aspect, based on the object of improving handling of interdependent data from different data streams, the CN node 400 is configured to compile 6002 received data 640 for DL transmission into data units 610, which further comprise a header 620. Specifically, the header 620 is configured to comprise an information field 630 indicating inter-dependency. Where the data unit 610 comprises a first data packet of a first data stream, which is inter-dependent with a second data packet associated with a second data stream, the information field 630 of the data unit 610 may be populated with inter-dependency information indicative of the second data packet, which has been or will be compiled in another data unit. Corresponding, mirrored, information of inter-dependency is preferably populated in the information field 630 of the data unit carrying the second data packet.
[0067] The CN node 400 may e.g., implement the UPF 103. In addition to the input of data from the application 600, the CN node 400 may take input from the PCF 105 regarding QoS information for the DL transmission. GTP-U is as such a legacy protocol between the CN 110 (the UPF 103) to the RAN 120 (SDAP). In some examples, the information field 630 is configured as GTP-U header extension.
[0068] According to a related aspect, the proposed solution provides a method carried out on SDAP level, as indicated in the lower part of Fig. 6. This may be carried out by the logic circuitry 310 in the access node 121, implementing SDAP functionality (or SDAP for short). The access node 121 obtains 6003 a first data packet 610 associated with a first data stream, e.g., using GTP-U protocol from the CN node 400 implementing UPF 103. In the access node, SDAP further compiles a data unit comprising the first data packet and a header 660. In some non-limiting examples, the SDAP may receive information related to inter-dependency of data from the information field 630 of the GTP-U header 620 and add it into the information field 670 of the SDAP header 660. In turn, SDAP distributes the data streams to the associated QoS flows for DL transmission. As will be described in further detail with reference to Fig. 7, the scheduler 315 in the access node 121 may further be configured to schedule 6005 data for DL transmission to the UE 10 based on the information of inter-dependency.
[0069] The access node 121 may further transmit 6006, to the UE 10, an indication of the mutual delay budget between the inter-dependent first data packet and second data packet. The mutual delay budget may be indicated in an information field of the header, such as the inter-dependency information field 670, or as separate information.
[0070] The header(s) 620, 660 may comprise any legacy features for GTP-U and SDAP, respectively. In addition, the headers 620, 660 of the data unit may comprise, in the respective information field 630, 670, one or more of the following information elements:
[0071] A Packet Delay Budget (PDB) of the data 640 carried in the data unit, or of a PDU set.
[0072] A binary indicator, indicative of whether or not the data unit 610, 650 comprises inter-dependent data.
[0073] A pointer or identifier, indicative of one or more other (second) data units comprising data which is inter-dependent with data of the first data unit. This may comprise a sequence number of the associated data stream or QoS flow of the inter-dependent data packet or unit. Where this is included, the binary indicator may be dispensed with.
[0074] A pointer or identifier, indicative of an associated logical pipeline between the wireless network and the UE, to which logical pipeline the inter-dependent (other / second) data is mapped. The logical pipeline may be a QoS flow, wherein a QoS ID may be included.
[0075] An indication of a mutual delay budget between the data carried in the data unit and the data of the inter-dependent data unit. This may be an indication of time in a certain unit.
[0076] A time indicator associated with allowable buffer time of the first data packet based on the mutual delay budget. o In one example, where the second (inter-dependent) data packet is already buffered or transmitted, the time indicator may be a time stamp indicative of the transmission time of the second data packet. Where said time stamp indicates that the first data packet cannot be transmitted while maintaining the mutual delay budget, a decision may be taken (e.g., by the access node 121) to cancel transmission the first data packet. o In one example, the time indicator comprises the PDB of the first data, which is configured to set a timer for the second, inter-dependent data, in the access node 121 upon buffering or transmission of the first data. o The time indicator could be similar to legacy PDCP (Packet Data Convergence Protocol) discard timer for UL.
[0077] Fig. 7 schematically illustrates an aspect of the proposed solution, wherein the scheduler 315 in various examples may be configured to schedule DL data transmission based on the information related to inter-dependency (or multi-modality). Data transmission for, e.g., XR application is latency sensitive. According to an aspect of the proposed solution, a mechanism is provided such that data packets (PDUs) which have time dependency can be delivered in a synchronized manner, even if they are conveyed over different QoS flows. Specifically, scheduling may take the information of interdependency from the associated field 670 of the SDAP header 660 into consideration.
[0078] The drawing of Fig. 7 illustrates, in the top part, an example of three multi-modal data streams being received in the wireless network 100 for DL transmission to the UE 10, which streams may be associated with different QoS flows: QoS #1, QoS #2, and QoS #3, where these numbers represent different QoS priority levels. By way of example, these three streams may include different types of data for the same application. In the respective QoS flow, each data unit (650) is indicated by P for Packet or PDU, followed by QoS number (#), and a queue / sequence number in the QoS flow after colon.
[0079] Specifically, certain data units (P#l:2, P#2:4, P#3:3) in the different QoS flows are inter-dependent. The inter-dependent data units are indicated with double line borders, and the mutual delay budget (Inter PDB) is further indicated in the drawing. According to what has been outlined above, the Inter PDB may be provided in header information in the respective inter-dependent data unit, such as in the field 670 of the SDAP header 660 of the data unit 650 with reference to Fig. 6. It may be noted that two or more data units of the same QoS flow may also be inter-dependent and be treated in the same way as inter-dependent data units as described herein. According to an aspect of the proposed solution, a mixed QoS flow may be created by SDAP in the access node 121, for handling by the scheduler 315. Ordering of data units in the mixed QoS flow may be based on legacy information, such as PDB of the respective data unit, and additionally based on the inter-dependency information field 670 in the header 660. The inter-dependency information field 670 may thereby further provide a pointer to inter-dependent data unit(s) and their associated logical pipeline (QoS flow) as well as the related mutual delay budget (inter PDB), and possibly a time indicator associated with allowable buffer time based on the mutual delay budget (e.g., time stamp). According to one example, the inter-dependent data units are placed in a new transmission buffer, according to their new transmission order.
[0080] At the bottom of Fig. 7, transmission order of certain data units from the different QoS flows is indicated. The data units (e.g. PDUs) are not only transmitted in an order based on priority from the QoS flow that they belong to, but also based on their relation to the other data units to which they have a multi-modality relation (inter-dependency). This way, transmission of inter-dependent data units may be aligned to ensure that timing requirements of the mutual delay buffer may be met. The scheduler 315 would start with the QoS flow with highest priority, e.g., QoS #1, and check which PDUs (data units) have inter QoS flow dependency. Then the scheduler 315 would order those packets in the mixed QoS flow 700 so that MAC (Medium Access Control) entity will deliver them together, either in the same transport block, TB, or in TBs enough close in time to handle the mutual delay buffer (inter PDB). The scheduler 315 may thus be configured to schedule data transmission, from the mixed QoS flow 700 and at least one pipeline- specific transmit buffer 701, 702, 703, to the UE 10, based on information indicative of inter-dependency information, which may be obtained from the interdependency information field 670.
[0081] The UE 10 needs to be configured, e.g., by the access node 121, to handle the transmitted order of the packets based on the mixed QoS flow, instead of the order of packets defined be the individual QoS streams and replace the packets in the correct order to receive units in the UE, such as individual processing entities for handling different types of data configured in the logic circuitry 210. Alternatively, the data units in the receiving units are re-ordered based on the reception order rather than the sequence number in the respective QoS flow. In this context, the re-ordering function in RLC (Radio Link Control) may be confused if supporting in-sequence delivery based on the individual QoS streams. According to one aspect, a solution for targeting this problem is for RLC to add a temporary sequence number (TSN) that is valid for the mixed QoS flow, so that the receiver can place the packets for the corresponding QoS flows in the receive units. In this context, each data unit may thus comprise a sequence number SN related to a sequence order in the associated logical pipeline (QoS flow), wherein the logic circuitry 210 in the access node 121 further adds a temporary sequence number (TSN) to the data units related to a sequence order in the mixed QoS flow 700. The temporary sequence number may be included as RLC header information in the data units. Furthermore, the reordering information (e.g. the TSN) needs to be propagated to SDAP and Application functions.
[0082] Based on what is outlined herein, the proposed solution provides a new procedure for handling each data unit (e.g., PDU) that is inter-dependent with another data unit jointly with its interdependent data unit(s).
[0083] According to some aspects, information may be included in the inter-dependency information field 670, or as separate configuration of the receiving UE 10, whether there is any restriction in case not all the related inter-related data units can be jointly transmitted, i.e., if the newly mutual delay budget (inter PDB) cannot be fulfilled for any of the packets or just for some of the packets. According to some examples, one of the following rules may apply:
[0084] A) keep the inter delay requirements (inter PDB) but delay the whole transmission, so at least the PDU with lowest PDB is delayed.
[0085] B) transmit any of the PDUs as soon as possible trying to minimize the inter PDU delay time.
[0086] C) Discard all of the packets that are inter-dependent if the inter PDB between any of them cannot be met.
[0087] Referring to the foregoing, the access node 121 needs to extract the mutual delay budget (inter PDB) from each PDU set belonging to different QoS flows and create and order them on transmit order, e.g. considering the mixed QoS flow 700 or otherwise fetching data units in the reordered sequence from respective QoS flows. The access node 121 may obtain the information on mutual buffer delay (inter PDB) in the GTP-U header from the UPF 103. The access node 121 is also responsible for configuring the UE 10 to be able to receive the transmitted packets and place them back in correct QoS flow and PDU set, e.g. using temporary sequence numbers in combination with original sequence numbers, as explained.
[0088] From the aspect of the UE 10, the proposed solution relates to a method performed by the UE 10, wherein the method comprises: receiving data units from a wireless network, wherein each data unit comprises a data packet and a header; processing the data packets in an order based on information comprised in the respective header, including an information field 670 for indicating inter-dependency between data packets associated with different data streams.
[0089] In some examples, each data unit comprises a sequence number related to a sequence order in an associated logical pipeline, e.g., QoS flow, 701, 702, 703, and wherein the processing of the data packets is performed in an order based on a temporary sequence number of the data units related to a sequence order of buffering of the mixed QoS flow 700 in the access node 121, which may be handled in a mixed common transmit buffer .
[0090] The UE 10 thus receives the packets transmitted from the access node 121 and will map them back to initial QoS flow but deliver the packets to upper layer without reordering them back. This way, the data of the inter-dependent data units can be used (presented / processed) in the UE while maintaining the mutual delay budget. This means that it is the transmit side that do the prioritization and re-ordering to align multimodality streams. This alignment can be done either on PDU / Packet level or in PDU set level, where all PDUs of a PDU set that have multimodal interdependency are reordered.
[0091] The UE 10 may indicate to upper layers that packets have been re-ordered.
[0092] Various details and examples of the proposed solution have been outlined in the foregoing. The proposed solution is further defined by the following claims.
Claims
CLAIMS1. A method carried out in a wireless network for processing data for downlink transmission to a User Equipment, UE, wherein the method comprises: obtaining a first data packet associated with a first data stream; compiling a data unit comprising the first data packet and a header, wherein the header comprises an information field for indicating inter-dependency between the first data packet and a second data packet associated with a second data stream.
2. The method of claim 1, wherein the information field of the header is configured to indicate a mutual delay budget between the inter-dependent first data packet and second data packet. The header may, in certain examples, be a GTP-U header extension or an SDAP header.
3. The method of claim 2, wherein said header comprises a time indicator associated with allowable buffer time of the first data packet based on the mutual delay budget.
4. The method of any preceding claim, comprising: transmitting the data unit to the UE.
5. The method of any preceding claim, wherein said header comprises an indicator of delay budget for the first data packet.
6. The method of any preceding claim, wherein the header of the first data unit comprises an indication of an associated logical pipeline between the wireless network and the UE, to which logical pipeline the second data packet is mapped.
7. The method of claim 6, wherein the logical pipeline is a QoS, Quality of Service, flow.
8. The method of claim 6 or 7, comprising:creating a mixed logical pipeline (700) comprising inter-dependent data units from one or more different logical pipelines, based on the information indicative of inter-dependency .
9. The method of claim 8 and claim 2 or 3, wherein the data units are ordered in the mixed logical pipeline based on their mutual delay budget.
10. The method of claim 8 or 9, wherein each data unit comprises a sequence number related to a sequence order in the associated logical pipeline, the method further comprising: adding a temporary sequence number to the data units related to a sequence order in the mixed logical pipeline.
11. The method of claim 10, wherein the temporary sequence number is included as Radio Link Control, RLC, header information in the data units.
12. The method of any of claims 8-11, further comprising: scheduling data transmission, from at least the mixed logical pipeline and optionally also from at least one pipeline- specific transmit buffer, to the UE based on the information indicative of inter-dependency.
13. A network node (121, 400) of a wireless network (100), comprising logic circuitry (111, 310) configured to carry out the steps of any of claims 1-7.
14. The network node (400) of claim 13, configured to implement a User Plane Function, UPF, in a core network (110) of the wireless network.
15. The network node (121) of claim 13, configured as a radio access node (121) in the wireless network (100), comprising logic circuitry (310) configured to carry out the steps of any of claims 1-12.
16. A method performed by a User Equipment, UE, wherein the method comprises:receiving data units from a wireless network, wherein each data unit comprises a data packet and a header; processing the data packets in an order based on information comprised in the respective header, including an information field for indicating inter-dependency between data packets associated with different data streams.
17. The method of claim 16, wherein each data unit comprises a sequence number related to a sequence order in an associated logical pipeline, and wherein the processing of the data packets is performed in an order based on a temporary sequence number of the data units related to a sequence order of a mixed logical pipeline comprising interdependent data units from one or more different logical pipelines.
18. A User Equipment, UE, configured to receive downlink data from a wireless network, comprising logic circuitry configured to carry out the steps of claim 16 or 17.
Citation Information
Patent Citations
Flow correlation and HTTP media classification
WO2023133364A2