Methods and devices for facilitating uplink delivery of interdependent data packets in wireless communication

Abstract

A method carried out in a UE for facilitating uplink transmission of data to a wireless network, wherein the method comprises: obtaining (1500) information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams; preprocessing (1505) uplink transmission of data of the data streams, based on said information.

Description

[0001] METHODS AND DEVICES FOR FACILITATING UPLINK DELIVERY OF

[0002] INTERDEPENDENT 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 uplink delivery of interdependent data packets of different data streams from 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. A gNB comprises one or more Transmission and Reception Point(s) (TRP(s)). 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.

[0008] 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.

[0009] 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 transmitted from the UE in UL or DL, 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 which are involved when running a certain 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). The DRBs are further mapped to logical channels. With the introduction of multi-modality, challenges arise with respect to handling of dependencies between the different modality streams. Summary

[0010] An overall objective is to provide solutions for targeting the aforementioned challenges, with respect to UL communication of data associated with different streams which comprise interdependent data. The proposed solution(s) is / are 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 User Equipment, UE, for facilitating uplink transmission of data to a wireless network, wherein the method comprises: obtaining information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams; preprocessing uplink transmission of data of the data streams, based on said information.

[0012] The proposed solution also refers to UE, comprising logic circuitry configured to carry out the steps outlined herein.

[0013] According to another aspect, the proposed solution relates to a method carried out in a wireless network, the method comprising: receiving an uplink transmission of data from a UE, wherein the uplink transmission of data is preprocessed by the UE based on information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams.

[0014] The proposed solution also refers to a network infrastructure element comprising logic circuitry configured to carry out the mentioned steps.

[0015] Based on the proposed solution, a mechanism is obtained which facilitates management of UL transmission, to take data interdependency into account. Specifically, solutions are provided for managing timely UL transmission of data packets which have a mutual, or relative, delay budget or criterion. This may include interdependent data packets of different QoS flows. Brief description the drawings

[0016] 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 implementing functions of a core network of the wireless network are further shown.

[0017] 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 interdependent 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 interdependent data packets of different data streams to the UE according to various examples.

[0020] Fig. 5 shows a signaling diagram, illustrating various aspects of uplink resource allocation.

[0021] Fig. 6 schematically shows an example of a control element for conveying delay status reporting from a UE.

[0022] Fig. 7A schematically illustrates aspects of logical channel prioritization according to legacy procedures.

[0023] Fig. 7B schematically illustrates aspects of updated logical channel prioritization, associated with buffering and scheduling according to various aspects of the proposed solution.

[0024] Fig. 8 shows an example of the 3GPP QoS architecture.

[0025] Fig. 9 shows an example of a Multi-modal interactive system, with input generating different data streams.

[0026] Fig. 10 schematically shows an example of an updated control element for conveying delay status reporting from a UE, including information associated with interdependent data packets.

[0027] Fig. 11 schematically shows an example of a control element for conveying information associated with interdependent data packets, which may be associated with delay status reporting from a UE.

[0028] Fig. 12 shows: Illustration UE Assistance Information signaling, adapted to handle interdependent data packets. Fig. 13 shows a signaling diagram comprising logical channel prioritization being adapted based on interdependent data packets.

[0029] Fig. 14 schematically illustrates reordering of UL packet transmission based on the interdependent data packet relations.

[0030] Fig. 15 shows a signaling diagram which provides information of various steps and functions of different embodiments of the proposed solution.

[0031] Detailed description

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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. The logic circuitry 210 is in various examples configured to implement an application layer, and to store and execute program code of an application client. The application client may receive or create various types of data within an application and use the radio transceiver 213 to transmit such data in UL to the network 100, via an access node 121.

[0044] The UE 10 may further comprise a user interface (UI) 215. The UI 215 may comprise various one or more output units, such as a display, speakers, a haptic feedback unit such as a vibrator unit, a temperature control unit such as a Peltier element, or other. The UI 215 may further comprise one or more input units, such as a touchscreen (e.g., configured on the display), microphones, and cameras, and sensors 216 which may include haptic or inertial sensors comprising accelerometers and / or gyroscopes, ambient sensors such as temperature sensors and humidity sensors, location sensors such as a GPS receiver, etc. The UI 215 may further comprise connectivity to external UI units, such as visors, cameras, projectors, headphones, speakers, wristbands or other wearables, etc., which may be connected to the UE 10 by wired or wireless connection using e.g., Bluetooth, Wi-fi or other. Such external devices and their connectivity to the UE 10 are as such well known in the art of wireless devices and will not be further described in detail herein. The input units may in various examples be configured for obtaining data used in the application and conveyed in a data stream destined for UL transmission.

[0045] The UE 10 further comprises a power supply 217 (e.g., a battery) that provides energy to the other components of the UE 10.

[0046] Fig. 3 schematically illustrates a network infrastructure component in the form of a radio node, configured to serve as an access node 121 of the wireless network 100 as presented herein, and for carrying out the method steps as outlined. The 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. The access node 121 may be configured to implement a gNB.

[0047] 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.

[0048] The access node 121 may further comprise an antenna 314, which may include an antenna array. The antenna is connected to the transceiver 313.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] The access node 121 may further comprise an interface 316, configured for communication with the core network 110.

[0054] Fig. 4 schematically illustrates a network infrastructure component 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.

[0055] 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 data transmission to at least the UE 10 via the RAN 120, and also for configuring flows for use is in UL and DL communication with the UE 10. 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. 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.

[0056] 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.

[0057] The core 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 transmitting data received in UL communication, as indicated in Fig. 1. The CN node 400 may implement one or more of the core network functions, or the application function, described with reference to Fig. 1.

[0058] Various aspects and key features related to UL data communication from the UE 10 to the access node 121, to which the proposed solutions are related, will now be described with reference to the drawings, which schematically illustrate various steps and functions related to UL data transmission. Specific terms used in this context shall be seen as exemplary. The aspects and features may inter alia be related to XR operation.

[0059] Fig. 5 shows a signaling diagram, which includes various steps and features which are described below. The diagram shows various steps related to the process of resource scheduling of uplink data.

[0060] The QoS flows are configured 505 by the SMF 102 in the core network 110 and signaled 510 to RAN 120 (represented in the drawing by the access node 121) and to the UE 10.

[0061] In the access node 121 the QoS flows are mapped 515 to DRBs based on the QoS parameters (including one or more QoS flows to DRBs mapping rules) in SDAP (Service Data Adaptation Protocol) layer. In RLC (Radio Link Control) layer, DRBs are mapped to logical channels. In MAC, the logical channels are mapped to transport channels. Different logical channels have different priorities based on the QoS parameters.

[0062] The mapping of the logical channels is shared 525 with the UE by RRC (Radio Resource Control) Reconfiguration, which is handled jointly with step 510.

[0063] The UL data scheduling preparation starts when data is received from the application in a logical channel to the MAC layer. The MAC layer in the UE 10 now signals 530 a scheduling resource request (SR) to be able to send a Buffer status report (BSR) and / or a Delay status report (DSR) when needed.

[0064] In step 535 the access node 121 allocates resources to the UE 10 based on the request and sends 540 UL Grant to the UE 10.

[0065] In step 545, the UE selects the most prioritized logical channel (LCH) and sends the data from these LCHs using LCP (Logical Channel Prioritization) functionality in the UE 10, as described inter alia in 5.4.3.1 of 3GPP TS 38.321 (and which will be further discussed below).

[0066] Certain aspects outlined in Fig. 5 are further described below.

[0067] The MAC layer is, amongst other things, responsible for handling scheduling information. This involves configuration from RRC (Radio Resource Control) layer with parameters to be considered when preparing UL transmission. This is inter alia described in TS 38.321. When the UE has prepared a MAC PDU (Protocol Data Unit) for uplink transmission it may initiate the SR 530 to the access node 121 to request resources on a physical uplink shared channel (PUSCH). The operation of SR 530 is controlled by MAC layer. The SR may be transmitted via Uplink Control Information (UCI) on PUSCH. This is inter alia described in TS 38.300. This may include a preceding transmission on a physical uplink control channel (PUCCH) of a request for resources for transmitting the BSR, e.g. using MAC CE (MAC Control Element).

[0068] The access node 121 (gNB) responds 540 with Downlink Control Information (DO) with resource allocation to schedule the UL resources to be used for UL data transmission.

[0069] The BSR procedure is used to provide the serving access node 121 with information about UL data volume in MAC entity, as provided in TS 38.321. MAC entity triggers transmission of a BSR based on certain conditions, like UL data becoming available with a certain priority. In Fig. 5, BSR is illustrated as at least optionally included in step 530. If PUSCH resources are available for new transmission, these are used to transmit the BSR MAC CE, otherwise the UE 10 will have to transmit a SR 530 to request UL resources.

[0070] In Rel-18 XR WI, 3GPP introduced DSR MAC CE for UE to report the delay- critical buffer size information to the access node. The purpose is to only indicate delay- critical buffer status, whereas non-delay critical data can be handled by legacy BSR or refined BSR. In Fig. 5, DSR is illustrated as at least optionally included in step 530. DSR is a procedure used to provide the serving access node 121 with delay status of Logical Channels Groups (LCGs), as provided inter alia in 6.1.3.72 of TS 38.321. The delay status serves to indicate the remaining time for buffered data packets, such as buffered PDCP SDU (Packet Data Convergence Protocol Service Data Unit).

[0071] Fig. 6 shows information fields of the DSR MAC CE, as taken from Figure 6.1.3.72-1 of TS 38.321. The Remaining Time, the BT, and the Buffer Size fields for an LCG shall be reported in two consecutive octets, as shown in the figure. These three fields for different LCGs are included in a DSR MAC CE in ascending order based on the LCGi.

[0072] A term known in the art is Logical Channel Prioritization (LCP). The LCP procedure is used when UL data transmission is to be made, to prioritize the data transmission related to different logical channels. This is e.g., provided in TS 38.321, section 5.4.3.1.

[0073] Fig. 7A schematically illustrates an example according to the general concept of

[0074] LCP. Three logical channels (LCHi, LCH2, LCH3) are shown, with associated priority 1, 2, and 3, respectively. For each LCH, buffered data is indicated, as well as Prioritized Bit Rate (PBR) for the respective LCH. According to legacy operation, the LCP will use available resources (MAC PDU) to transmit data based on the LCH priority and PBR, as shown by way of example in Fig. 7 A.

[0075] Fig. 7B illustrates a proposed enhancement of LCP operation for critical data, as proposed in the 3GPP technical contribution R2-2404266. The illustrated example corresponds to the scenario of Fig. 7 A with regard to the data buffered for the respective LCH. Further, it is suggested that when a new trigger event is detected, e.g. critical data (encircled by a dashed contour) being close to a Packet Delay Budget (PDB) or threshold, the corresponding data is prioritized for transmission. Specifically, this time- critical data is prioritized for transmission with other data previously stored in the same logical channel (LCH2) over other data associated with a different logical channel with higher priority, (i.e., LCHi).

[0076] The concept of QoS flows has already been mentioned above. The 5G QoS model, which is based on QoS Flows will be briefly discussed going forward. 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 in chapter 12 of 3GPP TS 38.300 V18.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. The 5G QoS model supports both QoS Flows that require guaranteed flow bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (non-GBR QoS Flows). At NAS (Non Access Stratum) level (TS 23.501), the QoS flow is thus the finest granularity of QoS differentiation in a PDU session. A QoS flow is identified within a PDU session by a QoS Flow ID (QFI) carried in an encapsulation header over NG-U (User Plane, from the UPF to RAN).

[0077] The QoS architecture in NG-RAN (120), both for NR connected to 5GC and for E-UTRA connected to 5GC, is depicted in the Fig. 8, which depicts figure 12-1 of TS 38.300, and describes in the following:

[0078] For each UE, 5GC establishes one or more PDU Sessions;

[0079] For each UE, the NG-RAN establishes at least one DRB together with the PDU Session and additional DRB(s) for QoS flow(s) of that PDU session can be subsequently configured. In one of the examples, it is up to NG-RAN when to do so; The NG-RAN maps packets belonging to different PDU sessions to different DRBs;

[0080] In RAN the DRBs are mapped to logical channels (LCH) where different logical channels have different priorities based on the QoS parameters.

[0081] NAS level packet filters in the UE and in the 5GC associate UL and DL packets with QoS Flows.

[0082] AS-level mapping rules in the UE and in the NG-RAN associate UL and DL QoS Flows with DRBs.

[0083] NG-RAN and 5GC ensure quality of service (e.g. reliability and target delay) by mapping packets to appropriate QoS Flows and DRBs. Hence there is a 2-step mapping of IP-flows to QoS flows (NAS) and from QoS flows to DRBs (Access Stratum). Then the DRBs are mapped to Logical channels, in RLC.

[0084] At NAS level, a QoS flow is characterized by a QoS profile provided by 5GC to NG-RAN and QoS rule(s) provided by 5GC to the UE. The QoS profile is used by NG- RAN to determine the treatment on the radio interface while the QoS rules dictates the mapping between uplink User Plane traffic and QoS flows to the UE. A QoS flow may either be GBR or Non-GBR depending on its profile. The QoS profile of a QoS flow contains QoS parameters, for instance (TS 23.501):

[0085] For each QoS flow: o A 5G QoS Identifier (5QI); o An Allocation and Retention Priority (ARP).

[0086] In case of a GBR QoS flow only: o Guaranteed Flow Bit Rate (GFBR) for both uplink and downlink; o Maximum Flow Bit Rate (MFBR) for both uplink and downlink; o Maximum Packet Loss Rate for both uplink and downlink; o Delay Critical Resource Type; o Notification Control.

[0087] NOTE: The Maximum Packet Loss Rate (UL, DL) is only provided for a GBR QoS flow belonging to voice media.

[0088] In case of Non-GBR QoS only: o Reflective QoS Attribute (RQA): the RQA, when included, indicates that some (not necessarily all) traffic carried on this QoS flow is subject to reflective quality of service (RQoS) at NAS; o Additional QoS Flow Information.

[0089] The QoS parameter Notification Control indicates whether notifications are requested from the RAN when the GFBR can no longer (or again) be fulfilled for a QoS Flow. If, for a given GBR QoS Flow, notification control is enabled and the RAN determines that the GFBR cannot be guaranteed, RAN shall send a notification towards SMF and keep the QoS Flow (i.e. while the NG-RAN is not delivering the requested GFBR for this QoS Flow), unless specific conditions at the NG-RAN require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion. When applicable, NG-RAN sends a new notification, informing SMF that the GFBR can be guaranteed again.

[0090] In addition, an Aggregate Maximum Bit Rate is associated to each PDU session (Session- AMBR) and to each UE (UE-AMBR). The Session- AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows for a specific PDU Session and is ensured by the UPF. The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows of a UE and is ensured by the RAN (see clause 10.5.1).

[0091] The 5QI is associated to QoS characteristics giving guidelines for setting node specific parameters for each QoS Flow. Standardized or pre-configured 5G QoS characteristics are derived from the 5QI value and are not explicitly signalled. Signalled QoS characteristics are included as part of the QoS profile. The QoS characteristics consist for instance of (see TS 23.501):

[0092] Priority level;

[0093] Packet Delay Budget;

[0094] Packet Error Rate;

[0095] Averaging window;

[0096] Maximum Data Burst Volume.

[0097] At Access Stratum level, the data radio bearer (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 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, or several QoS Flows belonging to the same PDU session can be multiplexed in the same DRB. In the uplink, the mapping of QoS Flows to DRBs is controlled by mapping rules which are signalled in two different ways:

[0098] Reflective mapping: for each DRB, the UE monitors the QFI(s) of the downlink packets and applies the same mapping in the uplink; that is, for a DRB, the UE maps the uplink packets belonging to the QoS flows(s) corresponding to the QFI(s) and PDU Session observed in the downlink packets for that DRB. To enable this reflective mapping, the NG-RAN marks downlink packets over Uu with QFI.

[0099] Explicit Configuration: QoS flow to DRB mapping rules can be explicitly signalled by RRC.

[0100] The UE always applies the latest update of the mapping rules regardless of whether it is performed via reflecting mapping or explicit configuration.

[0101] When a QoS flow to DRB mapping rule is updated, the UE sends an end marker on the old bearer.

[0102] In the downlink, the QFI is signalled by NG-RAN over Uu for the purpose of RQoS and if neither NG-RAN, nor the NAS (as indicated by the RQA) intend to use reflective mapping for the QoS flow(s) carried in a DRB, no QFI is signalled for that DRB over Uu. In the uplink, NG-RAN can configure the UE to signal QFI over Uu.

[0103] For each PDU session, a default DRB may be configured: if an incoming UL packet matches neither an RRC configured nor a reflective mapping rule, the UE then maps that packet to the default DRB of the PDU session. For non-GBR QoS flows, the 5GC may send to the NG-RAN the Additional QoS Flow Information parameter associated with certain QoS flows to indicate that traffic is likely to appear more often on them compared to other non-GBR QoS flows established on the same PDU session.

[0104] Within each PDU session, it is up to NG-RAN how to map multiple QoS flows to a DRB. The NG-RAN may map a GBR flow and a non-GBR flow, or more than one GBR flow to the same DRB, but mechanisms to optimise these cases are not within the scope of standardization.

[0105] The PDU may be a data unit combining a header and a Service Data Unit in a certain protocol layer.

[0106] PDU Set based Handling is discussed in TS 23.501. A PDU Set is comprised of one or more PDUs carrying an application layer pay load such as a video frame or video slice. All the PDUs of a PDU set may be transmitted within the same QoS Flow. The PDU Set based QoS handling by the NG-RAN is determined by PDU Set QoS Parameters in the QoS profile of the QoS Flow and PDU Set Information provided by the PSA UPF via N3 / N9 interface. PDU Set based Handling can be applied for GBR and non-GBR QoS Flows. The AF should provide PDU Set related assistance information for dynamic PCC control. One or more of the following PDU Set related assistance information may be provided to the NEF / PCF using the AF session with required QoS procedures.

[0107] PDU Set QoS Parameters as described in clause 5.7.7

[0108] Protocol Description: Indicates the transport protocol used by the service data flow (e.g. RTP, SRTP) and information

[0109] PDU Set QoS Parameters are used to support PDU Set based QoS handling in the NG-RAN.

[0110] The following PDU Set QoS Parameters are specified:

[0111] 1. PDU Set Delay Budget (PSDB).

[0112] 2. PDU Set Error Rate (PSER).

[0113] 3. PDU Set Integrated Handling Information (PSIHI).

[0114] At least one of the following shall be sent to the NG-RAN to enable PDU Set based handling: 1) a PSIHI and / or 2) both PSDB and PSER. For a given QoS Flow, the values of PSDB, PSER and PSIHI can be different for UL and DL.

[0115] The QoS Profile may include the PDU Set QoS Parameters described in this clause (see clause 5.7.1.2) for UL and / or DL direction. The PCF determines the PDU Set QoS Parameters based on information provided by AF and / or local configuration. The PDU Set QoS parameters are sent to the SMF as part of PCC rule. The SMF sends them to NG-RAN as part of the QoS Profile.

[0116] If the NG-RAN receives PDU Set QoS Parameters, it enables the PDU Set based QoS handling and applies PDU Set QoS Parameters as described in TS 38.300, TS 38.413 and TS 38.331.

[0117] The proposed solution relates to managing uplink delivery of interdependent data packets of different data streams in a synchronized manner, i.e., so that inter dependent data packets are timely delivered. This may relate to data packets that have a mutual delay budget, which may involve a threshold associated with a maximum relative delay between data packets of different data types or components. This may in some examples be relevant in a multi-modal system, of which an example is shown in Fig. 9 for illustration purposes. Therein, various types of multi-modality input are provided, which may be obtained using the UI 215 of the UE 10, such as by one or more of the sensors 216 included in or connected to the UE 10. As shown in the drawing, different types of multi-modality input may be combined for different services, or applications. The drawing further illustrates multi-modality output.

[0118] For immersive multi-modal applications, such as VR applications, synchronization between different media components is critical in order to avoid having a negative impact on the user experience (i.e. viewers detecting lack of synchronization), particularly when the synchronization threshold between two or more modalities is less than the latency KPI for the application.

[0119] In legacy NR up to Rel-18 including XR, different QoS flows are mapped to different Radio Bearers to handle specific QoS requirement. With multi-modal traffic flows, though, there may exist an interdependency between the different flows (or modalities). The interdependency 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 to. In 3GPP TS 22.261 V19.7.0, clauses 6.43 and 7.11 various kinds of coordination transmission requirements are discussed. Table 6.43.1-1 of that document indicates:

[0120] The delay difference between two flows should be less than some values e.g., for immersive multi-modality VR applications, the synchronization threshold for audio- tactile is less than 50ms (if the audio data is delayed compared to the tactile) or less than 25ms (if the tactile is delayed compared to the audio). 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).

[0121] While these are only examples related to muti-modality, they at least indicate requirements associated with interdependent data.

[0122] Based on the foregoing, the solutions outlined herein are related to the context of UL transmission of data, and particularly to delivery of interdependent data in UL, such as in the context of multi-modality. Reference will be made to the drawings.

[0123] From the aspect of the UE 10, the proposed solution comprises a method for facilitating UL transmission of data to a wireless network 100. The method comprises: obtaining information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams; and preprocessing uplink transmission of data of the data streams, based on said information.

[0124] From the aspect of the network 100, the proposed solution is related to a method carried out in a network infrastructure equipment, such an access node 121, wherein the method comprises: receiving an uplink transmission of data from a UE 10, wherein the uplink transmission of data is preprocessed by the UE 10 based on information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams.

[0125] In some examples, the information may be defined by higher layer protocol (e.g. RRC protocol and / or higher). The higher layer protocol and / or the data streams may be associated with an application. In this context, the information may be defined by the application. In other examples, the information may be obtained from the network 100, such as if the mutual delay criterion is static for the type of data streams, or for a certain application, or type of application, which provides data in different data streams, or if the information is related to other time-critical data.

[0126] The proposed solution provides that the UE is configured so as to manage UL data transmission while considering interdependent data, e.g., such that a mutual (or relative) delay criterion between different data packets can be fulfilled. This may involve scheduling UL transmission of such interdependent data packets within a time period which does not exceed a predetermined time threshold of the mutual delay criterion. The information may thus be indicative of a mutual delay budget of the interdependent data packets.

[0127] In some examples, said information is indicative of multi-modality of an application. The interdependent data packets may be different PDUs, or optionally different PDU Sets. Specifically, at least two of the PDUs (or PDU Sets) may be respectively associated with different QoS flows, and / or with different logical channels (LCHs). However, it shall be noted that other examples of the proposed solution are equally applicable to handling of interdependent data packets associated with the same QoS flow or the same LCH.

[0128] In some examples of the proposed solution, preprocessing by the UE 10 means, or comprises, transmitting an uplink report to the network 100 regarding the interdependency. In some embodiments, the uplink report is contained or conveyed in one or more MAC CE(s) associated with a buffer status report (BSR) or a Delay Status Report (DSR).

[0129] Fig. 10 schematically illustrates an example, in which the MAC CE of the uplink report 1000 is comprised in or transmitted with the DSR. This example may comprise a modified version of existing DSR MAC CE, as described with reference to Fig. 6, where the UE 10 further includes one or more elements of information related to interdependent data to be transmitted in UL. The uplink report 1000 may be transmitted to a serving access node 121, which may take the conveyed information into account when allocating resources for the UL transmission. The UE 10 may, in response, receive resource allocation for the data transmission from the access node 121, based on the uplink report 1000. However, MAC in the UE 10 determines the transmission order and builds the associated MAC PDU and Transport block.

[0130] In Fig. 10, the uplink report 1000 is shown to comprise both the DSR and information 1010 regarding the interdependency, which may be contained in one or more data fields of the uplink report 1000. In the drawing, the information 1010 regarding the interdependency is labelled flow mapping 1010, by way of example. Various aspects and example of the flow mapping 1010 is described below.

[0131] In some examples, the flow mapping 1010 is indicative of QoS flow mapping of the interdependent data packets. The flow mapping may provide information of, or a pointer to, data packets due to be transmitted and which are interdependent, such as at least two PDUs, and to the QoS to which they are associated, which may be different or the same QoS flows.

[0132] In some examples, the flow mapping 1010 is indicative of LCH mapping of the interdependent data packets. The LCH mapping may provide information of, or a pointer to, data packets due to be transmitted which are interdependent, such as at least two PDUs, and to the LCH to which they are associated, which may be different or the same LCHs.

[0133] In some examples, the flow mapping 1010 is indicative of the mutual delay budget of the interdependent data packets. The mutual delay budget be expressed as a measure of time, which provides an allowed or preferred relative time of UL transmission of the interdependent data packets. The mutual delay budget may specifically refer to individual interdependent data packets. In some examples, the flow mapping 1010 is indicative of a time indicator associated with allowable buffer time of the interdependent data packets, which may be based on the mutual delay budget. The time indicator is in some examples a timestamp or a measure of remaining time before UL transmission, corresponding or similar to PDCP discard timer.

[0134] In some examples, the flow mapping 1010 comprises an indicator of the delay budget, such as packet delay budget (PDB) for the interdependent data packets which are interdependent.

[0135] In some examples, the flow mapping 1010 comprises at least one Multi-Modality Service ID, MMSID, associated with the interdependent data packets. In other examples, the MMSID is communicated in higher layer protocols. In some examples, the MMSID may subsequently be mapped (in the network 100) to, e.g., mutual (relative) delay and / or PDB of different data streams, wherein that information need not be provided in the flow mapping 1010 of the uplink report.

[0136] In some examples, the flow mapping 1010 is indicative of component type information of the interdependent data packets. This may include type, character, or origin (such as multi-modality input, as exemplified with reference to Fig. 9) of one or more data streams to which the interdependent data packets are associated. By way of example, component type information may comprise an indication of component type combination (of multi-modality input, for instance), e.g., video-tactile, audio-tactile, etc., which may have predefined associated relative delay time. In some examples, such a component type may subsequently be mapped (in the network 100) to, e.g., mutual (relative) delay and / or PDB of different data streams, wherein that information need not be provided in the flow mapping 1010 of the uplink report.

[0137] Fig. 11 schematically illustrates another example, in which the MAC CE of the uplink report 1100 provides a different configuration of the information, which may be associated with the DSR. In this example, the uplink report 1100 can be seen as a new MAC CE, which may be referred to as Multimodality status report (MMSR). This new MAC CE may convey information on interdependent data packets, e.g., PDUs, which may further be indicative of their respective associated QoS flows. Like legacy configuration, as described with reference to Fig. 6, this MAC CE may also comprise information in a plurality of octets. In some examples, this uplink report 1100 may be transmitted together with, or associated with, a legacy type DSR. Specifically, this new MAC CE is in some examples only related to convey information associated with data packet interdependency. When the uplink report 1100 is constructed, it may be reported to the serving access node 121, as in legacy signaling according to TS 38.321. The uplink report may be triggered, in the UE 10, when configured inter PDU time thresholds (which may be obtained as configuration from the network 100) for multimodality are reached.

[0138] The uplink report 1100 includes one or more elements of information related to interdependent data to be transmitted in UL. As noted, the uplink report 1100 may be transmitted to a serving access node 121, which may take the conveyed information into account when allocating resources for the UL transmission. The UE 10 may, in response, receive resource allocation for the data transmission from the access node 121, based on the uplink report 1100. However, MAC in the UE 10 determines the transmission order and builds the associated MAC PDU and Transport block.

[0139] In some examples, the uplink report 1100 is indicative of data packets, such as PDUs, which are interdependent with at least one other data packet, in the sense that there is a mutual or relative delivery time criterion associated with the interdependent data packets.

[0140] An information field 1101 may be included to provide an ID or a pointer to data packets due to be transmitted and which are interdependent, such as at least two PDUs.

[0141] An information field 1102 may be included to provide an indicator of the delay budget, such as PDB, for the respective interdependent data packets which are interdependent.

[0142] An information field 1103 may be included to provide a time indicator associated with allowable buffer time of the interdependent data packets. The time indicator is in some examples a timestamp or a measure of remaining time before UL transmission, corresponding or similar to PDCP discard timer.

[0143] An information field 1104 may be included to provide flow mapping information associated with the interdependent data packets.

[0144] In some examples, the flow mapping 1104 may comprise an indication of the interdependency between specific data packets, such as PDUs, indicated in the uplink report 1100. By way of example, the drawing shows information associated with interdependency between data packets 1 and 2, and between data packets 2 and n. In some examples, the flow mapping 1104 may comprise an indication of the mutual (relative) delay budget between the interdependent data packets.

[0145] In some examples, the flow mapping 1104 may comprise an indication of the QoS to which the interdependent data packets are associated, which may be different or the same QoS flows.

[0146] In some examples, the flow mapping 1104 is indicative of LCH mapping of the interdependent data packets. The LCH mapping may provide information of, or a pointer to, data packets due to be transmitted which are interdependent, such as at least two PDUs, and to the LCH to which they are associated, which may be different or the same LCHs.

[0147] With reference to the examples of Figs 10 and 11, The UE 10 may be configured with criteria for multi-modality, such as threshold values for mutual delay budget, to trigger DSR via RRC configuration. The RRC configuration may be signaled from the access node (e.g., gNB) 121 to the UE 10 by RRC dedicated signaling. Alternatively, or additionally, the RRC configuration may be signaled from the access node (e.g., gNB) 121 to the UE 10 by RRC common signaling (e.g. MIB, SIB1 SIB2 and / or other SIBs). The criteria for multi-modality (e.g. one or more threshold values for mutual delay budget) may be included in at least one of RRC IES (Information Elements). The at least one of RRC IEs may be at least one of: MAC-CellGroupConfig, RadioBearerConfig, LogicalChannelConfig, SDAP-config, PDCP-config, or RLC-config. When the UE 10 is in Connected mode, it can trigger DSR based on the configured criteria. If resources for the uplink report 1000 or 1100 (including the associated DSR) are not available, the UE 10 sends Scheduling Request (SR) to request resources for this purpose.

[0148] For UL transmission of data, the serving access node (e.g., gNB) 121 may be configured to allocate the resources, and based on the uplink report 1000 or 1100 the access node 121 may obtain knowledge of interdependent data packets due to be transmitted. The access node 121 is thereby enabled to allocate resources to at least provide means so that those data packets can be delivered according to given time constraints to the application (possibly for transmission to another user device) as interdependent packets. It is, however, the UE 10 which schedules what is to be sent, so the UE 10 needs to identify the packets when they are prioritized and sent to the access node 121. As noted, the information on which data packets are interdependent may be obtained in the UE 10 from the application itself, such as from header information of the data packets, or be determined based on control information obtained from the network 100.

[0149] In some examples, the uplink report 1000 or 1100 may further comprise any of:

[0150] - one or more QoS requirements such as one or more synchronization thresholds,

[0151] - one or more media component type information (e.g. video-tactile, audio- tactile).

[0152] Additionally, or alternatively, the uplink report 1000 or 1100 may contain one or more PDU Set QoS Parameters which are at least one of:

[0153] PDU Set Delay Budget (PSDB),

[0154] PDU Set Error Rate (PSER), or

[0155] PDU Set Integrated Handling Information (PSIHI).

[0156] Here, the PSDB can be PSDB for Interdependency PDU Set Delay Budget which can be also denoted as IQPSDB.

[0157] The PSER can be PSER associated with Interdependency QoS Flows. The PSIHI can be PSIHI associated with Interdependency QoS Flows.

[0158] Fig. 12 shows another example of the proposed solution, based on using UE Assistance Information (UAI). Here, UAI is used for conveying an uplink report 1225 by the UE 10 to the network 100, specifically the access node 121, wherein the uplink report 1225 is indicative of packet interdependency, e.g. for multi modal traffic flows. The uplink report 1225 may be sent prior to uplink data transmission (e.g., preconfigured) or during the data transmission.

[0159] The network 100, such as the access node 121, configures (labelled IQoS config in the drawing) the UE 10 by a message 1205, such by RRC Reconfiguration.

[0160] The UE thereby stores 1210 configuration information, which sets configuration related to uplink reporting associated with data packet interdependency. The UE 10 may acknowledge the configuration, e.g., by sending an RRC Reconfiguration complete message 1215. This way, the UE 10 is configured to report interdependency by UAI, according to the configuration information.

[0161] The configuration information may identify a request for the UE 10 to send the uplink report indicative of interdependency in the UAI message 1225, and criteria regarding how and when to send the UAI. The configuration information may determine content and manner of reporting, related to interdependency, i.e., what to include in the UAI uplink report 1225, which may comprise any of the information elements outlined with reference to Figs 10 and 11. By way of example, the configuration information may prescribe uplink reporting 1225 with flow mapping comprising any of the following:

[0162] Information of data packets due to be transmitted and which are interdependent, such as at least two PDUs. In one embodiment, assuming there are more than two data packets that are interdependent, the packet interdependency information can be all relative to one reference packet. QoS flow mapping of the interdependent data packets.

[0163] LCH mapping of the interdependent data packets. Mutual delay budget of the interdependent data packets. A time indicator associated with allowable buffer time of the interdependent data packets, which may be based on the mutual delay budget.

[0164] A delay budget, such as packet delay budget (PDB) for the interdependent data packets which are interdependent.

[0165] MMSID associated with the interdependent data packets.

[0166] Component type information of the interdependent data packets. QoS requirements such as one or more synchronization thresholds. PDU Set QoS Parameters which are at least one of PSDB, PSER, PSIHI.

[0167] The UAI uplink report 1225 may be transmitted occasionally, such as when a Multi-modality (MM) data session (e.g., an application) comprising a plurality of data streams starts. The transmission 1225 may be triggered 1220 by the MM session start. In this context, the UAI 1225 is typically not sent before every request for UL grant.

[0168] The packet interdependency information is part of the UAI (UE Assistance Information) 1225 and it can be carried out in RRC message. Additionally, the packet interdependency information may be included in DelayBudgetReport IE defined in the UE Assistance Information. In this case, in addition to the "typel" which is already defined in the 3GPP standard, new type IE (e.g. "type2") may be defined to indicate the packet interdependency information. In one embodiment, assuming there are multiple packets, the packet interdependency information can be all relative to one reference packet. The packet interdependency for multi modal traffic flows can also be preconfigured and resulting in various pattern. In one example, one pattern representing the packet interdependency with a strict time-sensitive dependency (e.g., within a few milliseconds). Hence, those packets shall be transmitted very close to each other. In another example, one pattern representing the packet interdependency with less strict time- sensitive dependency (e.g., within 10s milliseconds).. Alternatively, instead of carrying the information in RRC message as described above, the indication of the transmission of packets with packet interdependency can be indicated by the UE either by MAC CE or UCL.

[0169] The access node 121 (e.g., gNB) receives the information in UAI 1225 and allocates the resource accordingly. The UE 10 may be explicitly informed whether the access node 121 uses the information (or not). The explicit information from access node 121can be done by MAC CE or DO. This information will make the UE explicitly aware that the allocated uplink resource is following / confirming the information provided in UAI 1225.

[0170] Further examples of the proposed solution, based on managing LCP, will now be described with reference to Figs 13 and 14. In this context, preprocessing uplink transmission of data of the data streams, based on information of interdependency, comprises configuring transmission order of the interdependent data packets from one or more logical channels based on the mutual delay criterion.

[0171] The LCP will with this solution use the information of interdependency, as obtained from the application layer, as part of deciding the priority for the related data blocks.

[0172] In some examples, The CN 110 (such as SMF 102 implemented by core network node 400) may decide 1300 which UL QoS flows are configured to have multi-modal relations. This may be related to a specific application, wherein the CN 110 obtains information from the application layer. The CN 110 may further configure 1305 the RAN 120, including the access node 121, to obtain management of QoS flows and multi-modal dependencies for LCP, e.g., using a PDU Session Resource Modify Request.

[0173] The LCP may be configured by RRC transmission 1310 from the access node 121 and acknowledgement by the UE 10, to support multi-modality using the interdependency information provided from the application layer. This RRC configuration of the logical channels, e.g., LogicalChannelConfig, may contain which logical channels are related by multi-modality and potentially the mutual delay budget for the related interdependent data packets if the budget is static (e.g., interdependency between packets in certain specific flows, such as between audio and video in a particular application), otherwise that is received for each related packet from the application in the UE 10, such as in a PDU header. In one example, there is one or more multimodal parameters for LCP, as part of the configuration of the MAC parameters. This includes the interdependency information of the packets for multi-modal transmission. This information would facilitate the UE 10 in configuring the transmission so that the LCP supports management of interdependent data packets.

[0174] Configuring of transmission order is carried out in step 1320. Based on the configuration 1310, when data shall be transmitted 1325 from the UE 10, resource allocation as well as the LCP can enhance the allocation for the data blocks that are related through multi-modality and which can be sent simultaneously, based on the one of the data blocks which is most urgent based on e.g. the PDCP discard timer. The configuration 1310 received from the network 100 may thus allow (enable) the UE to configure transmission based on the information of interdependency.

[0175] Fig. 14 further shows various steps that may be included in an example of the preprocessing step 1320, comprising configuring transmission order. Data transmission for certain applications, e.g., XR applications, is latency sensitive. According to an aspect of the proposed solution, a mechanism is provided such that data packets (PDUs) which have a relative time dependency, such as a mutual delay criterion, can be delivered in a synchronized manner, even if they belong to different logical channels or are conveyed over different QoS flows. Specifically, configuring transmission order of the interdependent data packets from one or more logical channels may be based on the mutual delay criterion, which e.g., may be obtained from a header field of the respective data packets (e.g., PDUs).

[0176] The drawing of Fig. 14 illustrates, in the top part, an example of three logical channels LCH#1, LCH#2, and LCH#3. In the respective LCH, each data packet (e.g., PDU) is indicated by P for Packet or PDU, followed by LCH number (#), and a queue / sequence number in the LCH after colon. By way of example, these three logical channels may include data packets of different data streams associated with the same application.

[0177] Specifically, certain data packets (P#l:2, P#2:4, P#3:3) in the different logical channels are interdependent. The interdependent data packets are indicated with double line borders, and the mutual delay budget (also referred to as 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 interdependent data packets / PDUs. It may be noted that two or more data packets of the same LCH may also be interdependent and be treated in the same way as interdependent data packets as described herein.

[0178] According to some aspects of the proposed solution, configuring transmission order of the interdependent data packets from one or more logical channels based on the mutual delay criterion is illustrated in the middle part of Fig. 14. This illustrates arranging transmission timing of the interdependent data packets based on the most urgent one of the interdependent data packets. Herein, the transmission order of the interdependent data packets is configured to adhere to the mutual delay budget (Inter PDB).

[0179] At the bottom of Fig. 14, transmission order of UL data transmission is indicated for a number of data packets, including the interdependent data packets, based on the changed transmission order 1400 of the interdependent data packets. While the first data packet (P#l:l) of the first (most prioritized) LCH#1 is first indicated, the second data packet (P#l:2) of the first LCH#1 is interdependent with further data packets P#2:4 and P#3:3. Hence, transmission of the second data packet P#l:2 is carried out together with its interdependent data packets, according to the changed transmission order 1400. Subsequent data transmission may follow legacy configuration of transmission order, which means that the next data packet may be P#l:3.

[0180] Contrary to the solution provided in Fig. 7B, the proposed solution thus provides for changed order of transmission of interdependent data packets associated with different logical channels.

[0181] Fig. 15 schematically illustrates various steps and signals according to different examples and embodiments, in a common signaling diagram. Herein, the UE 10 is indicated to the left, whereas the network 100, which includes one or more network infrastructure components, such as at least the access node 121, is indicated to the right. Further network infrastructure components may include components implementing one or more core network functions or an application function, as outlined above.

[0182] In step 1500, the UE 10 obtains information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams, which may be associated with a certain application, such as a multi-modality application (e.g., an XR application). As outlined, this may involve obtaining (1210, 1310) certain configuration from the network 100, such as thresholds, configuration of QoS flows and / or LCHs, static configuration of mutual delay budget based on application or component type, etc. This may alternatively, or additionally, involve obtaining information from an application layer, such as identification of interdependent data streams and / or data packets, mutual delay budget, and other elements of information referred to as information of flow mapping, which may include identification of QoS flows and / or LCHs of interdependent data packets.

[0183] In step 1505, the UE preprocesses uplink transmission of data of the data streams, based on said information.

[0184] In some examples, the preprocessing 1505 comprises transmitting 1510 an uplink report to the network regarding the interdependency. The uplink report may, inter alia, be indicative of QoS flow mapping of the interdependent data packets.

[0185] In some examples, this uplink report 1511 may be transmitted as UAI, as described with reference to 1225.

[0186] In some examples, this uplink report 1512 may be conveyed in a separate MAC CE, and in some examples the uplink report 1512 is associated with a BSR or a DSR, as described with reference to the flow mapping of 1010 or 1104.

[0187] In some examples, the UE transmits a Scheduling Request (SR) to request resources, either with the uplink report 1512 or separately, based on buffered data.

[0188] In some examples, the SR is transmitted first, for example via uplink control channel (PUCCH) and then followed by BSR and DSR in MAC CE. Even further, the UE transmits the UAI.

[0189] The access node 121 may allocate resources 1515, based on the uplink report and / or the scheduling request, and transmit an uplink grant 1520 to the UE 10. This may involve an identification of allocated resources for use by the UE 10 to schedule uplink transmission.

[0190] In step 1525, the UE 10 may carry out resource scheduling 1520 for uplink transmission of data.

[0191] In some examples, the preprocessing 1505 involves the resource scheduling 1525, which may involve configuring transmission order 1400 of the interdependent data packets from one or more logical channels based on the mutual delay criterion. Configuring transmission order may comprises arranging transmission timing of the interdependent data packets based on the most urgent one of said interdependent data packets, which may be carried out by logical channel prioritization in the UE 10.

[0192] In step 1530, the UE 10 transmits data in the uplink, also described with reference to 1325, based on the preprocessing 1505. This may involve using resources allocated 1515 by the access node 121.

[0193] In step 1535, the data packets received from the UE 10 may be processed in the wireless network 100. This may comprise conveying the data packets from the access network 121 to core network 110, for transmission to an intended recipient. In some examples, the processing may involve sorting received interdependent packets which have been configured with a changed transmission order 1400 by the UE 10. This may be carried out by the access node 121 or by another network infrastructure component of the wireless network 100.

[0194] Various details and examples of the proposed solution have been outlined in the foregoing, and the proposed solution may further be defined by the following items.

[0195] Item 1. A method carried out in a User Equipment, UE, for facilitating uplink transmission of data to a wireless network, wherein the method comprises: obtaining (1500) information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams; preprocessing (1505) uplink transmission of data of the data streams, based on said information.

[0196] Item 2. The method of item 1, wherein said different data streams are associated with an application.

[0197] Item 3. The method of item 2, wherein said information is indicative of multimodality of the application.

[0198] Item 4. The method of item 2 or 3, wherein the information is obtained from the application or from the wireless network.

[0199] Item 5. The method of any preceding item, wherein the interdependent data packets are different Protocol Data Units, PDUs, or PDU Sets.

[0200] Item 6. The method of item 5, wherein at least two of the PDUs or PDU Sets are respectively associated with different QoS flows.

[0201] Item 7. The method of item 5, wherein at least two of the PDUs or PDU Sets are respectively associated with different logical channels. Item 8. The method of any preceding item, wherein said information is indicative of a mutual delay budget of the interdependent data packets.

[0202] Item 9. The method of item 8, wherein the information is indicative of a delay budget for the data interdependent packets.

[0203] Item 10. The method of item 8 or 9, wherein the preprocessing comprises: transmitting (1510) an uplink report to the network regarding the interdependency .

[0204] Item 11. The method of item 10, further comprising: receiving (1520) resource allocation for data transmission, based on the uplink report.

[0205] Item 12. The method of item 10 or 11, wherein the uplink report is indicative of Quality of Service, QoS, flow mapping of the interdependent data packets.

[0206] Item 13. The method of any of items 10-12, wherein the uplink report is indicative of the mutual delay budget of the interdependent data packets.

[0207] Item 14. The method of any of items 10-13, wherein the uplink report comprises a time indicator associated with allowable buffer time of the interdependent data packets, based on the mutual delay budget.

[0208] Item 15. The method of any of items 10-14, wherein the uplink report comprises an indicator of the delay budget for the interdependent data packets.

[0209] Item 16. The method of any of items 10-15, wherein the uplink report comprises one or more Multi-Modality Service ID, MMSID, associated with the interdependent data packets.

[0210] Item 17. The method of any of items 10-16, wherein the uplink report is indicative of component type information of the interdependent data packets.

[0211] Item 18. The method of any of items 10-17, wherein the uplink report (1512) is contained in one or more Control Element of Media Access Control, MAC CE, associated with a buffer status report, BSR or a Delay Status Report, DSR.

[0212] Item 19. The method of item 18, wherein the MAC CE comprising the uplink report is comprised in the DSR.

[0213] Item 20. The method of item 18, further comprising: triggering the DSR, after transmission of the MAC CE comprising the uplink report, based on a threshold for multi-modality associated with the application. Item 21. The method of any of items 10-17, wherein the uplink report (1511) is transmitted as UE Assistance Information, UAL

[0214] Item 22. The method of item 21, wherein the uplink report is transmitted in a Radio Resource Control, RRC, message.

[0215] Item 23. The method of item 21 or 22, wherein delay budget of a plurality of interdependent data packets is indicated, in the uplink report, relative to one reference packet.

[0216] Item 24. The method of one of items 21 or 23, wherein the uplink report is indicative of a preconfigured interdependency for multi-modal traffic flows.

[0217] Item 25. The method of any of items 21-24, further comprising: receiving configuration from the network, indicative of an instruction associated with the transmission of the uplink report using UAL

[0218] Item 26. The method of any of items 1-9, wherein the preprocessing comprises: configuring (1525) transmission order of the interdependent data packets from one or more logical channels based on the mutual delay criterion.

[0219] Item 27. The method of item 26, wherein configuring transmission order comprises arranging transmission timing of the interdependent data packets based on the most urgent one of said interdependent data packets.

[0220] Item 28. The method of item 26 or 27, wherein configuring the transmission order is carried out by logical channel prioritization in the UE.

[0221] Item 29. The method of any of items 26-28, further comprising: receiving, from the network, configuration to allow the UE to configure transmission based on the information of interdependency.

[0222] Item 30. The method of item 29, wherein the configuration is indicative of the logical channels which are related by multimodality.

[0223] Item 31. The method of item 29, wherein the configuration allows the UE to configure transmission based on the information of interdependency from the application.

[0224] Item 32. The method of item 29, wherein the configuration comprises the information of interdependency.

[0225] Item 33. The method of any preceding item, further comprising: transmitting (1530) the interdependent data packets based on the preprocessing.

[0226] Item 34. A method carried out in a wireless network, the method comprising: receiving (1530) an uplink transmission of data from a User Equipment, UE, wherein the uplink transmission of data is preprocessed (1505) by the UE based on information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams.

[0227] Item 35. The method of item 34, wherein said different data streams are associated with an application.

[0228] Item 36. The method of item 35, wherein said information is indicative of multimodality of the application.

[0229] Item 37. The method of item 35 or 36, wherein the mutual delay criterion is associated with data packets of different data streams of the application.

[0230] Item 38. The method of any of items 34-37, wherein the interdependent data packets are different Protocol Data Units, PDUs, or PDU Sets.

[0231] Item 39. The method of item 38, wherein at least two of the PDUs or PDU Sets are respectively associated with different QoS flows.

[0232] Item 40. The method of item 38, wherein at least two of the PDUs or PDU Sets are respectively associated with different logical channels.

[0233] Item 41. The method of any of items 34-40, comprising: receiving (1510), from the UE, an uplink report configured by the preprocessing to indicate the interdependency.

[0234] Item 42. The method of item 41, further comprising: transmitting (1520) resource allocation for the UL data transmission, based on the uplink report.

[0235] Item 43. The method of item 41 or 42, wherein the uplink report is indicative of QoS flow mapping of the interdependent data packets.

[0236] Item 44. The method of any of items 41-43, wherein the uplink report is contained in one or more Control Element of Media Access Control, MAC CE, associated with a buffer status report, BSR or a Delay Status Report, DSR.

[0237] Item 45. The method of any of items 34-40, further comprising: processing (1535) the received data packets based on a transmission order configured by the UE, wherein the transmission order is associated with the interdependent data packets from one or more logical channels based on the mutual delay criterion.

Claims

CLAIMS1. A method carried out in a User Equipment, UE, for facilitating uplink transmission of data to a wireless network, wherein the method comprises: obtaining (1500) information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams; preprocessing (1505) uplink transmission of data of the data streams, based on said information.

2. The method of claim 1, wherein said different data streams are associated with an application.

3. The method of claim 2, wherein said information is indicative of multimodality of the application.

4. The method of claim 2 or 3, wherein the information is obtained from the application or from the wireless network.

5. The method of any preceding claim, wherein the interdependent data packets are different Protocol Data Units, PDUs, or PDU Sets.

6. The method of claim 5, wherein at least two of the PDUs or PDU Sets are respectively associated with different QoS flows.

7. The method of claim 5, wherein at least two of the PDUs or PDU Sets are respectively associated with different logical channels.

8. The method of any preceding claim, wherein said information is indicative of a mutual delay budget of the interdependent data packets.

9. The method of claim 8, wherein the information is indicative of a delay budget for the data interdependent packets.

10. The method of claim 8 or 9, wherein the preprocessing comprises: transmitting (1510) an uplink report to the network regarding the interdependency .

11. The method of claim 10, further comprising: receiving (1520) resource allocation for data transmission, based on the uplink report.

12. The method of claim 10 or 11, wherein the uplink report is indicative of Quality of Service, QoS, flow mapping of the interdependent data packets.

13. The method of any of claims 10-12, wherein the uplink report is indicative of the mutual delay budget of the interdependent data packets.

14. The method of any of claims 10-13, wherein the uplink report comprises a time indicator associated with allowable buffer time of the interdependent data packets, based on the mutual delay budget.

15. The method of any of claims 10-14, wherein the uplink report comprises an indicator of the delay budget for the interdependent data packets.

16. The method of any of claims 10-15, wherein the uplink report comprises one or more Multi-Modality Service ID, MMSID, associated with the interdependent data packets.

17. The method of any of claims 10-16, wherein the uplink report is indicative of component type information of the interdependent data packets.

18. The method of any of claims 10-17, wherein the uplink report (1512) is contained in one or more Control Element of Media Access Control, MAC CE, associated with a buffer status report, BSR or a Delay Status Report, DSR.

19. The method of claim 18, wherein the MAC CE comprising the uplink report is comprised in the DSR.

20. The method of claim 18, further comprising: triggering the DSR, after transmission of the MAC CE comprising the uplink report, based on a threshold for multi-modality associated with the application.

21. The method of any of claims 10-17, wherein the uplink report (1511) is transmitted as UE Assistance Information, UAL22. The method of claim 21, wherein the uplink report is transmitted in a Radio Resource Control, RRC, message.

23. The method of claim 21 or 22, wherein delay budget of a plurality of interdependent data packets is indicated, in the uplink report, relative to one reference packet.

24. The method of one of claims 21 or 23, wherein the uplink report is indicative of a preconfigured interdependency for multi-modal traffic flows.

25. The method of any of claims 21-24, further comprising: receiving configuration from the network, indicative of an instruction associated with the transmission of the uplink report using UAL26. The method of any of claims 1-9, wherein the preprocessing comprises: configuring (1525) transmission order of the interdependent data packets from one or more logical channels based on the mutual delay criterion.

27. The method of claim 26, wherein configuring transmission order comprises arranging transmission timing of the interdependent data packets based on the most urgent one of said interdependent data packets.

28. The method of claim 26 or 27, wherein configuring the transmission order is carried out by logical channel prioritization in the UE.

29. The method of any of claims 26-28, further comprising: receiving, from the network, configuration to allow the UE to configure transmission based on the information of interdependency.

30. The method of claim 29, wherein the configuration is indicative of the logical channels which are related by multimodality.

31. The method of claim 29, wherein the configuration allows the UE to configure transmission based on the information of interdependency from the application.

32. The method of claim 29, wherein the configuration comprises the information of interdependency.

33. The method of any preceding claim, further comprising: transmitting (1530) the interdependent data packets based on the preprocessing.

34. A method carried out in a wireless network, the method comprising: receiving (1530) an uplink transmission of data from a User Equipment, UE, wherein the uplink transmission of data is preprocessed (1505) by the UE based on information of interdependency, wherein said information is indicative of a mutual delay criterion between interdependent data packets of different data streams.

35. The method of claim 34, wherein said different data streams are associated with an application.

36. The method of claim 35, wherein said information is indicative of multimodality of the application.

37. The method of claim 35 or 36, wherein the mutual delay criterion is associated with data packets of different data streams of the application.

38. The method of any of claims 34-37, wherein the interdependent data packets are different Protocol Data Units, PDUs, or PDU Sets.

39. The method of claim 38, wherein at least two of the PDUs or PDU Sets are respectively associated with different QoS flows.

40. The method of claim 38, wherein at least two of the PDUs or PDU Sets are respectively associated with different logical channels.

41. The method of any of claims 34-40, comprising: receiving (1510), from the UE, an uplink report configured by the preprocessing to indicate the interdependency.

42. The method of claim 41, further comprising: transmitting (1520) resource allocation for the UL data transmission, based on the uplink report.

43. The method of claim 41 or 42, wherein the uplink report is indicative of QoS flow mapping of the interdependent data packets.

44. The method of any of claims 41-43, wherein the uplink report is contained in one or more Control Element of Media Access Control, MAC CE, associated with a buffer status report, BSR or a Delay Status Report, DSR.

45. The method of any of claims 34-40, further comprising: processing (1535) the received data packets based on a transmission order configured by the UE, wherein the transmission order is associated with the interdependent data packets from one or more logical channels based on the mutual delay criterion.

Images