Methods and devices for facilitating timely delivery of data to different devices in a wireless system

Abstract

A method carried out in a radio node for conveying data in a wireless system, wherein the method comprises: receiving (1101) at least a first data packet to be transmitted to a first user equipment, UE, wherein the first data packet has an interrelation with a second data packet to be transmitted to a second UE; transmitting (1112) the first data packet to the first UE; wherein a time indication, associated with delivery time of the data packets in said UEs based on the interrelation, is included as header information in the transmitted first 0 data packet.

Description

[0001] METHODS AND DEVICES FOR FACILITATING TIMELY DELIVERY OF DATA TO DIFFERENT DEVICES IN A WIRELESS SYSTEM

[0002] Technical field

[0003] This disclosure is related to communication in a wireless system, comprising radio nodes and wireless devices. The radio nodes may be configured to wirelessly convey data between wireless devices and a wireless network or directly between wireless devices. Examples of such radio nodes include access nodes of the wireless network and relay nodes. Specifically, solutions are provided for facilitating and managing timely delivery of data packets to different wireless devices.

[0004] Background

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

[0006] 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 communicationmay include communication of data of data streams, received in the CN for delivery to one or more UEs.

[0007] 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, or UEs, (e.g. one or more UEs) required for or involved in the same task or application. NG-RAN and 5GC ensure quality of service (QoS), e.g., reliability, latency and target delay, by mapping packets to appropriate QoS Flows and data radio bearers (DRBs). The DRBs are further mapped to logical channels. Hence and ultimately, the required user experience for XR applications can be achieved.

[0009] In various scenarios, challenges arise with respect to handling transmission of data to different UEs, where relative or absolute time of delivery at the different UEs may be relevant. This is particularly the case when there is an interrelation between such data such that timely delivery of data to two or more UEs in the receiving entity is pertinent.This may, for instance, be the case when the data to different UEs relate to a common task or application, such as in the case of multi-modality. Challenges in securing timely delivery of the interrelated data may at least partly be related to different connectivity or network conditions to the respective UEs, which may include different routes, such passing or hopping through different intermediate nodes.

[0010] Summary

[0011] An overall objective is to provide solutions for targeting the aforementioned challenges. Further challenges and problems may be set out in the detailed description. 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.

[0012] According to a first aspect, the proposed solution relates to a method carried out in a radio node for conveying data in a wireless system, wherein the method comprises:

[0013] receiving at least a first data packet to be transmitted to a first user equipment, UE, wherein the first data packet has an interrelation with a second data packet to be transmitted to a second UE;

[0014] transmitting the first data packet to the first UE;

[0015] wherein a time indication, associated with delivery time of the data packets in said UEs based on the interrelation, is included as header information in the transmitted first data packet.

[0016] The proposed solution also refers to a radio node, such as an access node or a relay node, comprising logic circuitry configured to carry out the outlined steps.

[0017] According to another aspect, the proposed solution relates to a method carried out in a first user equipment, UE, of a wireless system, wherein the method comprises: receiving a first data packet from a radio node;

[0018] obtaining, from header information of the first data packets, a time indication associated with delivery time of the data packet in the first UE based on an interrelation with a second data packet for a second UE;

[0019] delivering payload data of the first data packet to a receiving entity in the UE based on the time indication.The proposed solution also refers to a UE, comprising logic circuitry configured to carry out the mentioned steps.

[0020] According to another aspect, the proposed solution relates to a method carried out in a core network node in a wireless system, wherein the method comprises:

[0021] receiving first data to be transmitted to a first user equipment, UE, and second data to be transmitted to a second UE, wherein the first and second data have an interrelation;

[0022] controlling an access node of the wireless system to transmit a first data packet comprising the first data to the first UE and a second data packet comprising the second data to the second UE, with a time indication as header information in said first and second data packets, wherein the time indication is associated with a delivery time of the data in said UEs based on the interrelation.

[0023] Based on the proposed solution, a mechanism is obtained which enables accomplishment of timely delivery of interrelated data to different UEs, particularly where transmission of the interrelated data takes different data paths with different and possibly uncertain latency to one or more UEs. Specifically, the proposed solution provides a technical contribution which allows for handling of interrelated data to be timely received in UEs for use in, e.g., XR applications, industrial applications, digital twinning applications, etc.

[0024] Brief description the drawings

[0025] Fig. 1 schematically illustrates an implementation of a wireless communication system, in which data transmission of interrelated data is made to a plurality of UEs, typically from a common transmitting entity. The transmitting entity may reside in or connected to a wireless network, or in another UE, and may be an application. The communication of data may further be carried out over a relay node configured to both receive and retransmit data over an air interface.

[0026] Fig. 2 schematically illustrates a radio node in the form of a relay node configured to operate in the wireless system according to various examples.

[0027] Fig. 3 schematically illustrates a UE, which may act as a remote node in conjunction with the relay node, according to various examples.Fig. 4 schematically illustrates a radio node in the form of an access node configured to operate in the wireless system according to various examples.

[0028] Fig. 5 schematically illustrates a core network node configured to operate in the wireless system according to various examples.

[0029] Fig. 6 shows an example of a QoS architecture in 5G in which the proposed solution may be employed.

[0030] Fig. 7 schematically illustrates a scenario in which the proposed solution may be employed.

[0031] Fig. 8 illustrates relay operation according to Layer 2 and Layer 3 configuration, respectively.

[0032] Fig. 9 illustrates protocol stacks for relay operation according to Layer 2 and Layer 3 configuration, respectively.

[0033] Fig. 10 schematically illustrates various plausible connectivity scenarios for transmission of interrelated data to different UEs over different radio nodes, which may include at least one relay, where the proposed solution may be employed.

[0034] Fig. 11 provides a flow chart of various steps which may be included in a method carried out in a radio node, according to the proposed solution.

[0035] Fig. 12 provides a flow chart of various steps which may be included in a method carried out in a UE, according to the proposed solution.

[0036] Fig. 13 provides a flow chart of various steps which may be included in a method carried out in a core network node, according to the proposed solution.

[0037] Fig. 14 shows a signaling diagram in which various aspects and examples of the proposed solution are outlined.

[0038] Detailed description

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

[0040] 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.Fig. 1 illustrates a high-level perspective of operation in a wireless system set out in a wireless network 100 and is useful for context of the proposed solution. The drawing illustrates various entities and functions which cooperate in a wireless system. 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. Fig. 1.

[0041] 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 one must access anything inside the CN via the NEF 104.

[0042] The wireless network 100 further comprises an access network 120, comprising a plurality of radio nodes operating as access nodes (AN), including access node 121, configured for radio communication with wireless devices, which may be mobile. As noted, such wireless devices may be referred to as UEs.

[0043] The setup shown in Fig. 1 further depicts transmission over a radio node which may be referred to as a relay node 10, which is connected to the access node 121 over an air interface, which may be referred to as Uu using 3GPP terminology. The relay node 10 may be implemented to convey DL and optionally also UL communication in connection with a wireless network 100. In this context, to convey data may be understood as to retransmit, forward, or relay the received data. DL data from the wireless network, e.g., originating from the AF 106, may be transmitted from the network 100 for reception to one or more UEs 20, 21, 22, which may be referred to as UEs when operating over the relay node 10. In other scenarios, the relay node 10 may be configured to receive data from one UE 22, e.g., from an application running in thatUE 22, and to transmit the received data to or more other UEs 20, 21. This may in some examples be carried out using Sidelink (SL) protocols, which have been specified under the 3GPP. In some other examples, it may be carried using new protocols, such as simplified Uu-link or Uu-link like protocols. The relay node 10 is a thus radio node which may be configured to receive and retransmit data wirelessly.

[0044] It may be noted that any of the relay node 10 and the UEs 20, 21 may as such be a respective UE, and may optionally be labelled a Relay UE 10 and Remote UEs 20, 21. It shall also be noted that the UEs 20, 21 may additionally be configured to communicate directly with the access network 120, even though this is not indicated in this drawing.

[0045] The UEs 20, 21 may be devices configured to receive data and optionally to take some form of action based on the received data. Such an action may e.g., be to provide an output based on the received data, such as on a user interface, e.g., tactile, audible, visual, or other type of output. In other examples, the action may be to collect sensor data (i.e., a sensor). In another examples, the action may be to react / operate based on the receive command (i.e., an actuator). In some examples, the UEs 20, 21 may be representing devices with different capabilities, such as a high capability device, e.g., a VR headset, and low / reduced capability device, e.g., an Internet of Things (loT) device performing as sensor device and actuator device. Actual and specific use of the data received in the UEs is not within the scope of the proposed solution, though, and is thus not discussed in detail.

[0046] Fig. 2 schematically illustrates an example of a radio node 10 configured as a relay node 10 for use in the wireless system as presented herein and configured for carrying out various method steps as outlined. Some relevant elements or functions of the relay node 10 are shown in the drawing. The relay node 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, actuator, controller, etc., but these are left out for the sake of simplicity.

[0047] The relay node 10 comprises a radio transceiver 14 for communicating with other entities of the wireless system, such as the access node 121 and / or at least one UE (UE) 20, 21, in one or more frequency bands. The transceiver 14 may thus include a receiver chain (Rx) and a transmitter chain (Tx), for communicating through at least an airinterface. The transceiver 14 may be or comprise a modem configured to encode, transmit, receive and decode data using radio waves.

[0048] The relay node 10 may further comprise an antenna system 15, which may include one or more antennas, antenna ports or antenna arrays. The antenna system 15 is connected to the transceiver 14.

[0049] The relay node 10 further comprises logic circuitry 11 configured to control data and signal communication via the radio transceiver 14 on a radio link over a physical channel. In addition, the logic circuitry 11 may be configured to execute management function operations, such as resource management, scheduling, computing resource management for UEs 20, 21, etc. As indicated in Fig. 1, this may include radio links 141, 142 configured for at least data transmission to respective UEs 20, 21, wherein a link 140 is configured for at least DL reception from the access network 120, e.g., from a serving access node 121. DL data may originate from a transmitting entity, such as an application, in or connected to the network 100. In other use cases, a link 143 may be configured for transmission from the UE 22 of data to be forwarded by the relay node 10 over radio links 141, 142 to the UEs 20, 21. This may, e.g., be related to a SL setup, where the UE 22 implements a transmitting entity, e.g., an application. The logic circuitry is further configured to control the relay node 10 to carry out any of the steps associated with the proposed solution as outlined herein.

[0050] The logic circuitry 11 may include a processing device 12, 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 12 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 12 may be configured to perform one or multiple operations based on an operating system and / or various applications or programs.

[0051] The logic circuitry 11 may further include memory storage 13, which may include one or multiple memories and / or one or multiple other types of storage mediums. For example, the memory storage 13 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 13 may include a hard disk (e.g., a magnetic disk, anoptical disk, a magneto-optic disk, a solid state disk, etc.). The memory storage 13 is configured for holding computer program code, which may be executed by the processing device 12, wherein the logic circuitry 11 is configured to control the relay node 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 11.

[0052] The relay node 10 further comprises a power supply 16 (e.g., a battery) that provides energy to the other components of the relay node 10.

[0053] The relay node 10 may be configured to receive data from the access network 120 or a UE 22, schedule the data for transmission further to one or more UEs 20, 21, and carry out said transmission on the associated radio link 141, 142. In some examples, the relay node 10 may be configured to operate in accordance with the document 3 GPP TS 23.304 V19.1.0 (2024-09), which describes Proximity based Services (ProSe). The relay node 10 may configured as a 5G ProSe UE-to-Network Relay. In this context, the links 141, 142 to the UEs 20, 21, and optionally also link 143 to UE 22, may be referred to as PC5 links or reference points. The mentioned document 3GPP TS 23.304, which is incorporated herein by reference, provides useful information which is sufficient for various examples of configuration of the relay node 10 according to legacy procedures, and for realizing the links 141, 142 and transmitting data to the UEs 20, 21. In some examples, the relay node 10 may be configured to perform management function to manage the operation in handling the connected devices, UEs 20, 21 (e.g., radio resource management or computing resource management for UEs 20, 21).

[0054] The relay node may comprise a scheduler 17, or scheduling function, which as such may be realized or implemented by operation of program code in the logic circuitry 11. The scheduler is operated for determining use of allocated resources for communication using the transceiver 14 over radio, such as with the UEs 20, 21. 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. The scheduler 17 may thus be configured to schedule data which is received from the RAN 120 for transmission to the UEs 20, 21, according to the solutions proposed herein.

[0055] Fig. 3 schematically illustrates an example of a UE 20 for use in the wireless system according to the proposed solution as presented herein and configured forcarrying out various method steps as outlined. It may be noted that the UEs 21, 22 may configured in the same way as the UE node 20. With reference to the specific example of TS 23.304, the UE 20 may be configured as a 5G ProSe Remote UE or a ProSe-enabled UE. Some relevant elements or functions of the UE 20 are shown in the drawing. The UE 20 may however include other features and elements than those shown in the drawing or described herein, such as a casing, a user interface, sensors, actuator, controller, etc., but these are left out for the sake of simplicity.

[0056] The UE 20 comprises a radio transceiver 213 for communicating with other entities of the radio communication network 100, such as the relay node 10 or the access node 121, in one or more frequency bands. The transceiver 213 may thus include a receiver chain (Rx) and optionally a transmitter chain (Tx), for communicating through at least an air interface (e.g., Uu). The transceiver 213 may be or comprise a modem configured to at least receive and decode data using radio waves, optionally also to encode and transmit data.

[0057] The UE 20 may further comprise an antenna system 214, which may include one or more antennas, antenna ports or antenna arrays. The antenna system 214 is connected to the transceiver 213.

[0058] The UE 20 further comprises logic circuitry 210 configured to control data and signal communication via the radio transceiver on a physical channel, at least using the link 140 for transmitting to the relay node 10. As mentioned, the UE may optionally also be configured to communicate with an access node of the RAN 120, such as access node 121. The logic circuitry is further configured to control the UE 20 to carry out any of the steps associated with the proposed solution as outlined herein.

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

[0060] 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 storagemediums. 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 20 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.

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

[0062] As indicated above, the UE 20 may further comprise a user interface and / or one or more sensors, for obtaining data to be transmitted.

[0063] Fig. 4 schematically illustrates a radio node in the form of an access node 121 of the wireless network 100, configured to carry out the method steps as outlined. The access node 121 may in some examples be a gNB. 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 wireless devices, such as the relay node 10 and the UEs 20, 21, 22.

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

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

[0066] The access node 121 further comprises logic circuitry 310 configured to control the access node 121 to communicate with the relay node 10 and / or the UEs 20,21,22 via the radio transceiver 313. The logic circuitry 310 may realize a scheduler for scheduling communication of a data set according to the solutions proposed herein, and for configuring at least the relay node 10 to operate according to the scheduling.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.

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

[0068] The access node may comprise 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 determining use of allocated resources for communication using the transceiver 313 over radio, such as with the relay node 10. In the context of scheduling and resource allocation, each resource may be indicative of a unit of time and / or frequency of a radio frame structure, according to the established art.

[0069] The access node 121 may further comprise an interface 316, configured for communication with the core network 110. This may include receiving data from a receiving entity, such as the AF 106, and to wirelessly convey the received data to a receiving entity, such as a UE.Fig. 5 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.

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

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

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

[0073] The CN 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 forcommunication with entities outside the wireless network 100 for receiving data for DL communication, such as an application server or application function AF 106, as indicated in Fig. 1.

[0074] The context of the proposed solutions is DL (or SL) transmission of interrelated data, i.e. different packets of data which are intended to be used in one or more UEs 20, 21 (e.g., for executing an action) in combination or relation with each other. The proposed solution is useful for controlling data transmission over the relay node 10 to at least one intended UE 20, 21. Specifically, the proposed solution is associated with DL transmission of interrelated data packets in different data flows to different UEs. The data flows may be QoS flows. In some examples, each data flow is associated with one data stream from an event, or a task, or an application, such as one data stream of a multi-modality application comprising a plurality of data streams.

[0075] The context proposed solution is thus related to transmission of interrelated data to two or more different UEs, wherein the data may be conveyed using different routes, and pass via different radio nodes, to the respective UE. Each UE may comprise or implement a receiving entity for receiving the data. The receiving entity, residing in the respective UE, may be an upper protocol layer, such as an application or application layer. Specifically, the proposed solution may relate to an interrelation between different data packets, or data streams of the data packets, which are received in a radio node 10, 121 and retransmitted, conveyed, to different UEs 20, 21 for delivery to the respective receiving entity. The interrelation may mean that the data of the interrelated data packets are interdependent. This may be due to the entity transmitting the data, such as an application residing in the AF 106 or in another UE 22, having a desire or requirement with regard to absolute and / or relative time of delivery of the data in the different UEs 20, 21. By way of example, the data from different UEs 20, 21 may be interdependent on account of said data representing an action or triggering event to occur at or near the same time in the different UEs 20, 21, e.g., relating to a common scene in an XR game. This may, e.g., be related to a multiplayer scenario in an XR application. It may alternatively be related to different interrelate data streams for different US 20, 21 associated with the same user, where e.g., the different UEs may configured to provide different types of output, such as video, audio, tactile, etc., which shall be output in synchronization or alignment. The proposed solution is useful for managing data transmission over the radio node 10, 121, where various factors maycause different amounts of delay from the transmitting entity to the receiving entities in the different UEs 20, 21. In various examples, the proposed solution is associated with transmission of interrelated data packets in different data flows. The data flows may be QoS flows. In some examples, each data flow is associated with one data stream from an application, such as one data stream of a multi-modality application comprising a plurality of data streams.

[0076] Data to be transmitted in DL to different UEs 20, 21 may be received in the CN 110 in one or more different data streams. This may, e.g., be the case in XR applications. As noted, this may be referred to as multi-modality. In 5G, communication of data within the wireless network 100 is accomplished in QoS flows. Different received data streams may thus be mapped to different QoS flows.

[0077] QoS flows are, 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 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. There is a 2-step mapping of IP-flows to QoS flows (Non Access Stratum -NAS) and from QoS flows to DRBs (Access Stratum - AS).

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

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

[0080] Fig. 6 schematically illustrates the QoS architecture of 5G, as indicated in Figure 12-1 of TS 38.300 V18.4.0. With reference to legacy procedures and this drawing, the following can be noted: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.

[0081] NG-RAN 120 establishes at least one DRB together with the PDU Session and additional DRB(s) for QoS flow(s)

[0082] The NG-RAN 120 maps packets belonging to different PDU sessions to different DRBs.

[0083] NAS level packet filters in the UE 10 and in the 5GC 110 associate DL (and UL) packets with QoS Flows.

[0084] AS-level mapping rules in the UE 10 and in the NG-RAN 120 associate DL (and UL) QoS Flows with DRBs.

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

[0086] In legacy NR up to Rel-18 including XR, different QoS flows are mapped to different Data Radio Bearers, DRBs, to handle specific QoS requirement. Though with multi-modal traffic flows, there may exist an interrelation or interdependency between the different flows. The interdependency has been described and discussed in the document 3GPP TR 23.700-60 related to XRM study in Rel-18, where various requirements are described and referred to. In 3GPP TS 22.261 V19.7.0, clauses 6.43 and 7.11 two kinds of coordination transmission requirements are discussed, for reference:

[0087] 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).

[0088] 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

[0089] While these are only examples related to muti-modality, at least the first paragraph indicates examples of synchronization requirements associated with interrelated data.

[0090] The solutions outlined herein are proposed for ensuring, or increasing the chances of meeting requirements related to proper delivery and handling of interrelated data conveyed to different UEs 20, 21, such as in the context of multi-modality.

[0091] Fig. 7 schematically illustrates an example of a scenario or use case of the proposed solution. Data transmission over the relay node 10 may be used in indoor XR gaming scenarios with the motivation to improve reliability, reduce latency, and increase data-rates. There can be multiple players that can interact with each other. Each user / player may utilize several devices e.g., for audio, video and haptic. Different devices, acting as separate UEs, may then need to be in sync for a certain user, but there may also be requirements on synchronization between devices for different users / players. This may include a timing requirement, or preference, that data flows associated with different multi-modal streams are delivered with proper intended timing to the respective receiving entities.

[0092] The drawing shows a couple of users 71, 72 who are running an XR application over the wireless network 100. The application may comprise application clients in various UEs 711-715, which are connected with an application server over the wireless network 100 through an application function 106. Specifically, at least some of the UEs 711-715 are connected to receive data over the relay node 10. In this context, the relay node 10 may comprise an access point for connection with the access node 121 over an air interface. The relay node may be a UE of one of the users, such as a handheld device, a game console, an access point, or other. By way of example, the drawing indicates various different UEs (reference numerals mainly indicated for one user 71 for simplicity reasons), including the following:

[0093] handheld tools 711, which may be configured to provide sensory output based on received data;visors 712 (722 for user 72), such as a head-mounted display (HMD) which may include a headset speaker, or be accompanied by a separate loudspeaker, wherein the visor is configured to show images or video and / or provide audio output, by executing received data;

[0094] wristbands 713 and ankle bands 714, which may include motion sensor (e.g., an accelerometer) be configured to provide sensory output based on received data. Additionally, or alternatively, it may comprise an actuator (e.g., vibrator) to provide sensation to the user, by executing on received data;

[0095] a mat or floorboard 715, which may be configured to sense pressure and / or provide sensory output based on received data.

[0096] Sensory data may, by way of example, comprise tactile feedback, heat, vibration or other. The application is thus configured to provide data streams of different types, or modalities, wherein the data streams include interrelated data packets. The interdependency, i.e., the interrelation, between the interrelated data packets may be associated with an expected level of experience of the XR application. This may be defined by a timing requirement. By way of example, output based on different types of data streams of the application, such as audio, video, tactile, using different UEs 711-715, may be required or preferred to be aligned, to take place within a certain time frame determined by the timing requirement. Additionally, or alternatively, output based on the same type of data of the application may be required or preferred to be aligned, to take place within a certain time frame, using corresponding UEs for the two users 71, 72 (e.g., on both users’ visors).

[0097] As already mentioned, transmission over the relay node 10 to the UE(s) 20, 21 may in some examples be based on ProSe. It may be noted that this may be accomplished on different layers of the 5G protocol stack.

[0098] Fig. 8 schematically illustrates different QoS flow configurations used dependent on whether a Layer 2 (L2) Relay functionality or Layer 3 (L3) functionality is employed, according to legacy procedures, as outlined in the aforementioned document 3GPP TS 23.304.

[0099] Fig. 9 further shows the differences of how the relay functionality works in L2 and L3 according to legacy procedures.

[0100] In a relay node 10 configured to implement an L3 Relay, the protocol stack includes all layers in the RAN 120, up to SDAP (Service Data Adaptation Protocol).Thereafter the PDU session is terminating in the L3 Relay and thereby also the QoS flow is terminating there. Thus, new QoS flows to the respective UE 20, 21 are originating in the L3 Relay 10 and terminating in the respective UE 20, 21.

[0101] In a relay node 10 configured to implement an L2 Relay, the protocol stack includes up to RLC (Radio Link Control) where an additional layer, the SRAP (Sidelink Relay Adaptation Protocol), is added on the top. In this case the PDU session as well as the QoS flow are terminating in the respective UE 20, 21.

[0102] It may be noted that synchronization between the different data flows in the DL, as proposed herein, is mainly performed in the MAC (Medium Access Control) layer where the scheduling to the UEs 20, 21 is performed. Therefore, ordering or scheduling of data packets based on interrelation is valid for implementation in both L2 and L3 Relays.

[0103] Based on the foregoing, it may be acknowledged that challenges arise when data is sent to two or more UEs 20, 21, in particular when they are connected via different radio nodes, such as different relay nodes and / or access nodes 121, 122, but shall be aligned in time in the receiving entities of the UEs 20,21. With reference to the context of multi-modality, the problem arises where two data packets are interrelated shall be delivered to different UEs 20, 21 at the same time, which could be referred to as an inter-UE multi-modality problem.

[0104] Fig. 10 illustrates, by way of example, a number of different connectivity scenarios in which the aforementioned challenges and problems arise, and in which the proposed solution may be employed. The drawing is simplified and may additionally comprise the features shown and discussed with reference to Fig. 1. The drawing illustrates the AF 106 and the CN 110 of the network 100, and additionally two access nodes 121 and 122 of the RAN 120. A number of relay nodes are further illustrated, as well as a number of UEs, connected to one of the access nodes or one of the relay nodes.

[0105] While the drawing of Fig. 10 and the description below primarily indicates a DL context, it shall be noted that the proposed solution shall not be seen as limited thereto. Rather, both UEs and relay nodes may be configured according to various aspects of the proposed solution also based on SL, or other device-to-device protocol.

[0106] Where UEs are connected to each other by device-to-device connectivity, such as to or via relay node, a subnetwork may be formed. A subnetwork is a special purposenetwork that can support localized and high-performance connectivity within an entity. They are typically short range (below 10 meters), typically low-power, cells, meant at offering very localized connectivity by offloading larger networks of demanding services. In practice, the range can be extended (more than 10 meters). The short range is designed so that the system can be operated to achieve high data rates, low latency, and / or high reliability. They may comprise one or more High Capability (HC) devices and / or Low Capability (LC) devices with integrated edge processing capabilities (in case of HCs) and a potentially large number of cost-effective very constrained devices with limited form factor, such as sensors / actuators, called subnetwork element (SNE)s. They can operate as stand-alone subnetworks in case the connection with the network 100 (such as a 6G umbrella network with a 6G access node) drops or is intermittent. The network 100 can take care of efficiently orchestrating the subnetwork operations when connection is available. Non-standalone subnetworks always depend on the umbrella 6G network. For context, further and related description can be found in ”6G SHort range extreme communication IN Entities”, 6G-SHINE_D2.2 Refined definition of scenarios use cases and service requirements for in-X subnetworks _vl.O Dissemination Level: PU Project: 101095738 - 6G-SHINE-HORIZON-JU-SNS-2022.

[0107] Problems or challenges may arise when using subnetworks connected to an access node, where different UEs (also referred to as Remote devices or Remote UEs) shall receive the data coming from an application function (AF) simultaneously, meaning at the same time or within an allowed maximum delivery time according to a timing requirement. It could be that different video streams need to be synchronized together with audio and actuators to ensure an immersive experience. Furthermore, it could be that the same (real or virtual) event or activity happens simultaneously in a game played by different users in different locations. In such scenarios, it may be that:

[0108] 1. The players are connected within the same subnetwork 1010 (the same room), such as UEs 20 and 21.

[0109] 2. The players are connected in different subnetworks 1010, 1020 but the same access nodes 121 (e.g., different room), such as UEs 20 and 22.

[0110] 3. The players are connected in different subnetworks 1010, 1030 over different access nodes 121, 122 or different RANs (e.g., different building / city), such as UEs 20 and 24.The challenges addressed in this document are most relevant for cases 2 and 3. When data is sent from the application, represented by AF 106 in the drawing, the application may inform the PCF 105 in the core network 110 that different data streams supplied by the application are interrelated, e.g., in a multi-modality session. According to legacy procedures, the PCF 105 then adjusts QoS requirement according to multimodality synchronization requirement. In this case, when the data path is split from the access node 121 over one or more different relays to the receiving UEs, or maybe even split to different access nodes 121, 122 from the UPF 103, the time between when the data path is split until the respective UEs receive the data is uncertain. This may partly be due to different network conditions which may lead to varying load, e.g., to the different subnetworks of the network, as well as available data rates to or between UEs, possible multi hop relaying (as indicated for UE 25), etc.

[0111] Data transmission may be latency sensitive, such as in an XR application. A mechanism is therefore proposed for radio nodes, such as the access nodes or relay nodes, to be able to distribute and route data packets, which may belong to a multimodality set of QoS flows, intended for different UEs connected through different radio nodes. The packets (e.g., PDUs) which have a time-related dependency may thus be delivered to the different UEs in a synchronized, or aligned, manner to fulfil a timing requirement. The problem as stated above is that the data packets may go through different relay nodes and possibly different number of relay nodes in case of multi hop before the packets are delivered. Thereby the synchronization between the delivery is lost. A similar situation is when the data is sent through different access nodes from the UPF 103 and one or more access node experiences congestion. Therefore, synchronization between the interrelated data packets is not guaranteed and the time between delivery of data packets to different UEs may be large.

[0112] Various aspects of the proposed solution for targeting the identified challenges are set out below. Reference will be made to the entities depicted in Fig. 10. Meanwhile, further reference is made to the following flowcharts.

[0113] Fig. 11 provides a flow chart of various method steps which may be carried out in a radio node, according to the proposed solution as outlined below.

[0114] Fig. 12 provides a chart of various method steps which may be carried out in a UE, according to the proposed solution as outlined below.Fig. 13 provides a chart of various method steps which may be carried out in a core network node, according to the proposed solution as outlined below.

[0115] According to one aspect, a method is provided which is carried out in a radio node, such as a relay node 10 or an access node 121, for conveying data in a wireless system. The method comprises receiving 1101 at least a first data packet to be transmitted to a first UE, e.g., UE 20, and optionally also receiving 1102 a second data packet to be transmitted to a second UE, such as UE 22, wherein the first data packet and the second data packet have an interrelation. In examples where the radio node is an access node, the data packet(s) is / are received from the core network 110, although the payload of the data packet(s) may originate from an application. In examples where the radio node is a relay node, the data packet(s) may be received from an access node, or from a further upstream relay node, or from a UE, e.g. UE 23 of Fig. 10, acting as a de vice-to -device transmitter (e.g., in SL), where the UE 23 may transmit two different data streams / QoS flows with a multi-modality relation intended for two different UEs 22, 25 via one relay node 10A, or multiple relay nodes 10A and 10B. Further alternative scenarios include that the data packets are received from another relay node in a subnetwork-to- subnetwork scenario. It may further be noted that interrelation may exist between more than two data streams, and packets within those data streams. The proposed solution may thus be implemented also for interrelation between data streams and packets transmitted to more than two different UEs, while the description will predominantly be provided with reference to transmission to and delivery in two UEs for the sake of simplicity.

[0116] The interrelation may comprise that the first and second data packets are associated with different data streams, and / or QoS flows, of a common task or application, such as in a multi-modality session.

[0117] An indication of the interrelation may be included as header information in the first and second data packets. The indication of interrelation may comprise an identification of multi-modality between a first stream associated with the first data packet and a second stream associated with the second data packet, e.g., a common Multi-modal Service ID (MMSID). The indication of interrelation may be included in the received data packets and may thus be determined 1103 from the respective packet headers in the radio node. In other examples, which may include embodiments where the radio node implements an access node, the indication of interrelation may bedetermined 1103 in the radio node from other configuration, such as from the CN 110, and be provided into the data packets by the radio node.

[0118] The indication of the interrelation of each of interrelated data packets may comprise an identification of the other interrelated data packet, with which the interrelation exists, and / or an indication of the QoS flow of the data packet with which the interrelation exists. In other words, the header of the first data packet may comprise information identifying the second data packet and / or the QoS flow of the second data packet, and vice versa.

[0119] The method carried out in the radio node further comprises transmitting 1112 the first data packet to the first UE. In examples where the radio node also received the second data packet, the method further comprises transmitting 1113 the second data packet to the second UE. In this context, the first and second UEs are end nodes for the data packets in the wireless system, where the data of the data packets may be moved to an upper protocol layer, such as an application layer. Different data paths are used for wireless transmission to the different UEs, and those different data paths may include different and / or unknown relay nodes between the radio node and the respective first and second UEs. For embodiments where the radio node receives and transmits also the second data packet, the data paths split in that radio node. In such embodiments, the radio node may be an access node (e.g. 121) or a relay node (e.g., 10A). For embodiments where the first data packet is received 1101 and transmitted 1112 but not the second data packet, the data paths split upstream of that radio node. In such embodiments the radio node may be a relay node (e.g., 10A).

[0120] According to the method, a time indication, associated with delivery time of the data packets in said UEs based on the interrelation, is included as header information in the transmitted first and second data packets.

[0121] The radio node may thus be configured to determine 1104 the time indication. As will be explained, this may involve obtaining 1105 the time indication from the headers of the received data packet or packets. Alternatively, or additionally, this may include controlling or configuring 1106 the time indication, such as providing or setting the time indication of the data packet headers or adjusting 1108 the time indication of the received data packets before transmitting 1112, 1113.

[0122] The time indication may refer to an intended delivery time of the data packets, such as a time of delivery of payload data of the data packets to an upper protocol layer,such as an application layer, in the first and second UEs, respectively. The time indication may further comprise or indicate a time period, representing an allowable length of time within which the data packet, e.g., its payload, shall be delivered. The time period may indicate or be based on an allowable mutual delay between delivery of the first and second data packets at the respective UE. The time period may thus be dependent on or given by the interrelation, such as dependent on the type of data as exemplified with reference to immersive multi-modality VR applications above. The time indication may be the same in the interrelated first and second data packets, and may e.g., apply for a PDU or a PDU Set, for the respective UEs.

[0123] By means of the time indication, the radio node, or any relay node between the radio node and the end node UEs, is enabled to control further retransmission towards the respective target UEs, e.g. by optionally delaying 1111 further transmission towards the end node UEs, e.g., by buffering the data packets, such that the first and second data packets are both delivered according to the time indication. In some examples, buffering / delaying of data is configured to be performed in the last relay node before the end node UE of that data path.

[0124] According to one aspect, indicated in Fig. 12, the proposed solution may thus be implemented as a method carried out in a first UE of a wireless system, which is one end node of data transmission in the wireless system. The method comprises receiving 1201 a first data packet from a radio node. The radio node may be a relay node (such as relay node 10C for the UE 26) or an access node (such as access node 122 for UE 24).

[0125] The method carried out in the first UE further comprises obtaining 1202, from header information of the first data packet, a time indication associated with delivery time of the data packet in the first UE based on an interrelation with a second data packet for a second UE. Said time indication may be configured in accordance with any of the examples outlined in the foregoing.

[0126] The method carried out in the first UE further comprises delivering 1204 pay load data of the first data packet to a receiving entity or function in the UE based on the time indication. The receiving entity may refer to an upper protocol layer, such as an application layer.

[0127] Based on the time indication, the UE is enabled to control the delivery of data, so as to obtain delivery of the data in the first UE in synchronization with delivery of the interrelated second data packet in the second UE.In some examples, the end node UEs are configured to delay delivery of the received data packets to upper layer, if needed, e.g., by buffering 1203, for instance in a modem part of the UE. Buffering / delaying in a data path or leg may be needed to obtain synchronization / alignment of delivery in both UEs in case the data packets are received / available ahead of time in any of the UEs.

[0128] The mechanism according to the proposed solution thus serves to ensure that the end (last) node UEs are receiving the data in a synchronous way such that delivery of the data to or in the UEs is obtained according to the delivery time, which may represent an expected or intended delivery time. The time indication, providing the delivery time, may comprise a timestamp and / or an Absolute expected Time of Delivery (ATD). The time indication, such as ATD, may be added to the headers of the data packet so that the UEs and / or any intermediate relay nodes knows when it shall be delivered to the end node UE or to an upper layer, e.g., application layer, in the end node UE. The time indication may in some examples be provided in SRAP or SDAP level, which may be dependent on where the delivery time is added to the header. Various examples include providing the delivery time as header information in a CN node, e.g., UPF 103, or in a radio node implementing an access node.

[0129] In some examples, the time indication may be given as SFN (System Frame Number) format which gives a 10s range (1024 frames, each 10ms). In other examples, the time indication may be provided according to the UTC (Coordinated Universal Time) format describing the absolute time.

[0130] According to some examples, the relay node or UE receiving the data packet may be configured to wait (delay / buffer) 1111, 1203 until the delivery time, e.g., ATD, is close to expiry until it is delivered to reduce the time difference between delivery of the interrelated first and second data packets. This mechanism operates similar to a jitter buffer and serves to adjust for difference in time to transmit the interrelated data packet to its end node UEs, to promote the synchronization between the delivery of interrelated data packets.

[0131] Buffering 1111 of received interrelated data packets serves to promote aligned time of reception in the first and second UEs based on the time indication. By way of example, buffering 1111 in the relay node of a subnetwork before transmitting the data packet to the target UE, may be carried out if one packet arrives ahead of the delivery time associated with the time indication, or if two packets destined for different UEs arereceived in the relay node at different times. The relay node may then be configured to buffer the earliest received, first, data packet to wait for the second packet to arrive. In an example where both the interrelated first and second data packets arrive, at or near the same time, to the relay node, and there is congestion in the data path to one of the UEs, such as on a sidelink, the relay node may be configured to buffer and wait in order to transmit to both UE1 and UE2 at same time.

[0132] buffering (1111) at least said first data packet to promote aligned time of reception in the first and second UEs based on said time indication

[0133] In some examples, the delivery time, such as the ATD, may be decided by the UPF 103 or the SMF 102, or by the access node through which the data packet is transmitted, or by any intermediate relay node, based on the knowledge of the data paths to the first and second UEs. The delivery time, e.g., ATD, may be set so that it just about complies with the QoS requirements. The delivery time may e.g., be set so that the QoS requirements, such as max Packet Delay Time requirement, for each stream are met, while at the same time minimizing the packet delivery times between the streams for packets that are interrelated, i.e., timely interdependent.

[0134] Referring to Fig. 11 associated with the radio node, controlling 1106 the time indication may in some examples include obtaining or determining knowledge or estimation of packet delay in and / or between each radio node between the end node UE and the transmitting access node of that data path. The delivery time may thus be controlled 1105, or configured, based on such determined packet delay.

[0135] In some examples, the method carried out in the radio node comprises determining 1107 a first delay of the data path to the first UE and a second delay of the data path to the second UE, i.e., determining a DL delay from the radio node to the UE or the next node (possibly another relay node), wherein the delivery time is configured 1108, i.e., set or adjusted based on, the largest delay of those data paths to avoid undue buffering in any of the data paths.

[0136] As indicated, at least one of the radio nodes included in one or both data paths to the different UEs, such as an access node or a relay node, may be arranged to control 1106 the delivery time of the time indication, e.g. to set or reconfigure the delivery time associated with the time indication. For this purpose, the radio node may be configured to obtain an estimation of the packet delay. This may include receiving 1107 a report from at least one of the first and second UEs or a relay node between the radio node andthe first and second UEs, indicative of the packet delay from the radio node. This report may thus be indicative of measured or estimated packet delay. The radio node is thereby enabled to configure 1108 the time indication for the first and second UEs based on said packet delay, such as to set the delivery time or adjust the delivery time based on the reported packet delay. Alternatively, configuring 1108 the time indication may comprise transmitting configuration information in uplink to a node responsible for setting or adjusting the delivery time. Said responsible node may be in the CN 110, an access node, or any radio node between the CN 110 and the end node UEs where the data paths split.

[0137] From the point of view of a relay node arranged downstream of an access node in one or both of the data paths, the proposed solution may thus include determining 1109 a packet delay from an upstream radio node from which at least the first at least data packet was transmitted, and transmitting 1110 a report indicative of the packet delay to the upstream radio node for control of the time indication.

[0138] Turning to Fig. 12, which shows a flow chart associated with operation of the end node UE, the proposed solution may thus include determining 1205 a packet delay from the radio node to the first UE, and transmitting 1206 a report indicative of the detected packet delay to the radio node for control of the time indication.

[0139] Control of the time indication may thus comprise setting or adjusting the associated delivery time.

[0140] Based on this delay report the node that decides the delivery time, e.g., the ATD, is enabled to make a good estimate of when it is possible to deliver the data to all UEs set to receive the interrelated data packets. Based on the controlled delivery time, all packets can be delivered from the different relays in the data paths while still enabling synchronization to each other in terms of delivery to the end node (remote) UEs. The reported packet delay, such as an indication of time, can be based on assistance information from the remote UEs, such as statistical information (e.g., mean, standard deviation) of packet delay. With this measurement an improved estimate of the delivery time can be performed. The delay report may be an RRC measurement report sent to the access node of the related data path, similar to UE Information reporting.

[0141] According to one aspect of the proposed solution, the interrelation is conveyed to the CN 110 from the application layer. In the CN 110, a CN node 400, such as the UPF 103, may be configured to implement a method. This is schematically indicated in theflow chart of Fig. 13. The CN node 400 may further comprise or operate under control of the SMF 102, as indicated.

[0142] The method may comprise receiving 1301 first data to be transmitted to a first user UE and second data to be transmitted to a second UE, wherein the first and second data have an interrelation. The CN node 400 may receive the data from an application, via AF 106, wherein the interrelation is indicated by the application and determined or detected 1302 by the CN node 400. This may include determining an indication of the first and second data packets being delivered in different data streams of a common multi-modality session.

[0143] The method carried out in the CN node 400 may further comprise controlling 1304 an access node of the wireless system to transmit a first data packet comprising the first data to the first UE and a second data packet comprising the second data to the second UE, with a time indication as header information in said first and second data packets, wherein the time indication is associated with a delivery time of the data in said UEs based on the interrelation.

[0144] As noted, the time delivery time, such as the ATD, may in some examples be determined or decided 1303 by the UPF 103 or the SMF 102. In other examples, the step of controlling the access node comprises configuring the access node to determine or decide the delivery time. This may, as such, be carried out based on obtained delay reports as described. Further aspects and examples of the delivery time, and the interrelation, have already been outlined in the foregoing.

[0145] The CN node 400 further sends 1305 or provides the received interrelated data to the access node, for wireless transmission in interrelated data packets to the first and second UEs, e.g., in different QoS flows.

[0146] Fig. 14 comprises a signaling diagram, showing aspects of various examples of the proposed solution. The example relates to a multi-modality (MM) application being executed, involving two wireless devices operating as UEs 20 and 22 indicated as remote nodes 20, 22 in the drawing. These UEs 20, 22 are arranged in different subnetworks with respective relay nodes. With reference to Fig. 10 for illustration, UE 20 is connected in subnetwork 1010, connectable to the network 100 over relay node 10, whereas UE 22 is connected in subnetwork 1020, connectable to the network 100 over relay node 10A.The application is connected to transmit data from an application server, connected through an application function 106 to the network 100. A CN node 400 in the CN 110 obtains interrelated data from the application and controls the RAN 120 (e.g., access node 121) to wirelessly transmit data interrelated data packets to the UEs 20, 22. The description provided with reference to Fig. 14 shall only be regarded as one detailed example useful for understanding the proposed solution.

[0147] 1401 indicates that UEs 20 and 22, and relay nodes 10, 10A, are registered and configured and the respective subnetworks (SN) 1010, 1020 is setup and configured. This may involve ProSe configuration according to legacy procedures. This configuration may define what devices belong to a certain group, and may include a group ID. By way of example, 3GPP has defined a Layer-2 Group ID defining a group for the application layer. The subnetwork configuration may further indicate radio settings such as frequency, bandwidth Tx Power etc. Additionally, the configuration according to legacy procedures may have new information elements. The configuration may also prescribe expected operation of the subnetwork 1010, 1020 operated by the respective relay node 10, 10A (e.g., a subnetwork to support gaming, a subnetwork to support sensor network, etc.). This will give an indication of what kind of traffic may be operated in the subnetwork. The relay nodes 10, 10A, and optionally also the UEs 20, 22, may further be configured to support multi-modality. This may include configuring the relay nodes to operate in accordance with any of the aspects of the described methods, such as to use time indication for handling data interrelated data packets, including configuring / adjusting delivery time, delaying data in the respective node, and reporting packet delay.

[0148] It may in this context be noted that in the case a subnetwork 1010, 1020 using AF 106 in or connected to the CN 110, there is likely at least one relay node. In case of subnetwork-to- subnetwork interaction, as in this example, there is generally at least one relay node per subnetwork. Moreover, in each subnetwork the relay nodes 10, 10A may be configured with further overall management functionality to moderate the different subnetwork interactions and prioritizations, etc. Configuration obtained in the relay nodes 10, 10A in step 1401 may thus be determined and provided to the UEs 20, 22 of the respective subnetworks by the associated relay node.Step 1402 indicates that data streams containing multimodality data are configured from AF 106 to the CN 110. Specifically, this may include configuration of different QoS flows usable for carrying interrelated data packets.

[0149] 1403 indicates data provided from the AF 106 to the network 100 for wireless transmission to the respective UEs 20, 22. The drawing schematically indicates two streams represented by full (to UE 20) and dashed (to UE 22) DL arrows, associated with different QoS flows and comprising data packets, e.g., PDUs holding the interrelated data obtained from the AF 106. An indication of interrelation may be provided as header information in the respective interrelated data packet, such as the first data packet, which may identify the data packet (e.g., the second data packet) with which the interrelation exists, which may include an indication of the data stream, and / or the QoS flow, PDU Set information, or other, associated with the second data packet.

[0150] 1404 indicates the step of adding a time indication, such as delivery time (e.g., ATD) attached in the header of each data packet in the access node of the RAN 120. In this example, both relays 10, 10A are connected to the same access node 121. The time indication may be based on estimated or measured packet delay to the UEs 20, 22, as described, and configured QoS Delay Budget requirement.

[0151] The data packets are received in the respective relay nodes 10, 10A. Based on the delivery time of the determined 1104 time indication and the determined 1103 existence of interrelation with another (second) data packet (e.g., another data stream or QoS flow), the packets may be buffered either in the respective relay node as indicated by 1405 and 1406, or in the modem (e.g., the transceiver 213) in the end node UEs 2022 as indicated by 1407 and 1408, before the conveyed data is delivered to the application in the respective UE 20, 22 at the configured delivery time (e.g., ATD).

[0152] 1409 further indicates packet delay reporting from the UEs 20, 22, and optionally also separately from the relay nodes 10, 10A, to the node responsible for configuring or setting the time indication, i.e., the common access node 121 in the RAN 120 in this example.

[0153] 1410 indicates configuration, e.g., adjustment, of the time indication, which may be based at least partly on the received packet delay report(s) of step 1409, and additionally on e.g., detected network load. This corresponds to step 1108 of Fig. 11.Based on what is outlined herein, the proposed solution thus provides a new procedure for handling of interrelated data transmitted to different UEs, such that delivery of the interrelated data may be synchronized or aligned in the different UEs based on time indication provided with the data packets. The proposed solution may broadly be identified as including the definition of delivery time, e.g., ATD, for multimodality data packets, enabling delivery the interrelated data packets simultaneously to several UEs at different locations and with different connectivity. In some examples, the delivery time is calculated based on latency to the respective UE, such as the UE which has the longest latency, represented by estimated or measured, and reported, packet delay to the respective UE) of the targeted UEs and on the QoS Packet Delay budget requirement. In some examples, the latency is estimated based on an RRC measurement report 1409 of packet delay. The estimated latency can be used to update the delivery time.

[0154] The proposed solution includes mechanisms according to any of the features disclosed herein and may comprise any of the features set out in the items below.

[0155] Item 1. A method carried out in a radio node for conveying data in a wireless system, wherein the method comprises:

[0156] receiving (1101) at least a first data packet to be transmitted to a first user equipment, UE, wherein the first data packet has an interrelation with a second data packet to be transmitted to a second UE;

[0157] transmitting (1112) the first data packet to the first UE;

[0158] wherein a time indication, associated with delivery time of the data packets in said UEs based on the interrelation, is included as header information in the transmitted first data packet.

[0159] Item 2. The method of item 1, further comprising:

[0160] receiving (1102) the second data packet and transmitting the second data packet to the second UE, wherein the time indication is included as header information in the transmitted second data packet.

[0161] Item 3. The method of item 1 or 2, comprising:

[0162] controlling (1106) the time indication in the radio node.

[0163] Item 4. The method of item 3, wherein controlling comprises:receiving (1107), from at least one of the first and second UEs, a report indicative of a packet delay from the radio node, wherein the radio node is enabled to control the time indication for the first and second UEs based on said packet delay.

[0164] Item 5. The method of item 2 and 4, wherein controlling comprises: determining (1107) a first packet delay of a first data path to the first UE and a second packet delay of a second data path to the second UE;

[0165] configuring (1108) the delivery time based on the largest delay of said data paths. Item 6. The method of item 3, wherein controlling comprises:

[0166] determining (1109) a packet delay from an upstream radio node from which at least the first at least data packet was transmitted;

[0167] transmitting (1110) a report indicative of the packet delay to the upstream radio node for control of the time indication.

[0168] Item 7. The method of any preceding item, comprising:

[0169] buffering (1111) at least said first data packet to promote aligned time of reception in the first and second UEs based on said time indication.

[0170] Item 8. The method of any preceding item, wherein the radio node is a base station of the wireless system.

[0171] Item 9. The method of any of items 1-7, wherein the radio node is a relay node. Item 10. The method of any preceding item, wherein an indication of the interrelation is included as header information in said first and second data packets.

[0172] Item 11. The method of item 10, wherein the indication of interrelation comprises an identification of multi-modality between a first stream associated with the first data packet and a second stream associated with the second data packet.

[0173] Item 12. The method of item 10 or 11, wherein the indication of the interrelation of each of said data packets comprises an identification of the other data packet with which the interrelation exists.

[0174] Item 13. The method of item 12, wherein said identification is indicative of a Quality of service, QoS, flow of said other data packet with which the interrelation exists.

[0175] Item 14. The method of any preceding item, wherein the time indication is indicative of a time of delivery of payload data of the data packets to an upper protocol layer in the first and second UEs.

[0176] Item 15. A radio node (10), comprising:a transceiver (14);

[0177] logic circuitry (11), configured to control the radio node to carry out any of the steps according to items 1-14.

[0178] Item 16. A method carried out in a first user equipment, UE, of a wireless system, wherein the method comprises:

[0179] receiving (1201) a first data packet from a radio node;

[0180] obtaining (1202), from header information of the first data packets, a time indication associated with delivery time of the data packet in the first UE based on an interrelation with a second data packet for a second UE;

[0181] delivering (1204) pay load data of the first data packet to a receiving entity in the UE based on the time indication.

[0182] Item 17. The method of item 16, comprising:

[0183] buffering (1203) the first data packet to deliver the payload data according to the time indication.

[0184] Item 18. The method of item 16 or 17, comprising:

[0185] determining (1205) a packet delay from the radio node to the first UE; transmitting (1206) a report indicative of the detected packet delay to the radio node for control of the time indication.

[0186] Item 19. The method of any of items 16-18, wherein an indication of the interrelation is included as header information in said first data packet.

[0187] Item 20. The method of item 19, wherein the indication of interrelation comprises an identification of multi-modality between a first stream associated with the first data packet and a second stream associated with the second data packet.

[0188] Item 21. The method of any of items 16-20, wherein the time indication is indicative of a time of delivery of payload data of the data packets to an upper layer in the first UE.

[0189] Item 22. A user equipment, UE, (20), comprising:

[0190] a transceiver (213);

[0191] logic circuitry (210), configured to control the UE to carry out any of the steps according to items 16-21.

[0192] Item 23. A method carried out in a core network node in a wireless system, wherein the method comprises:receiving (1301) first data to be transmitted to a first user equipment, UE, and second data to be transmitted to a second UE, wherein the first and second data have an interrelation;

[0193] controlling (1304) an access node of the wireless system to transmit a first data packet comprising the first data to the first UE and a second data packet comprising the second data to the second UE, with a time indication as header information in said first and second data packets, wherein the time indication is associated with a delivery time of the data in said UEs based on the interrelation.

[0194] Item 24. The method of item 23, wherein an indication of the interrelation is included as header information in said first and second data packets.

[0195] Item 25. The method of item 24, wherein the indication of interrelation comprises an identification of multi-modality between a first stream associated with the first data and a second stream associated with the second data.

[0196] Item 26. The method of item 24 or 25, wherein the indication of the interrelation of each of said data packets comprises an identification of the other data packet with which the interrelation exists.

[0197] Item 27. The method of item 26, wherein said identification is indicative of a Quality of service, QoS, flow of said other data packet with which the interrelation exists.

[0198] Item 28. The method of any of items 23-27, wherein the time indication is indicative of a time of delivery of payload data of the data packets to an application layer in the first and second UEs.

[0199] Item 29. A core network (400) node of a wireless system, comprising:

[0200] an interface (114) for receiving data and for sending data to an access network for wireless transmission;

[0201] logic circuitry (111), configured to control the core network node to carry out any of the steps according to items 23-28.

Claims

36CLAIMS1. A method carried out in a radio node for conveying data in a wireless system, wherein the method comprises:receiving (1101) at least a first data packet to be transmitted to a first user equipment, UE, wherein the first data packet has an interrelation with a second data packet to be transmitted to a second UE;transmitting (1112) the first data packet to the first UE;wherein a time indication, associated with delivery time of the data packets in said UEs based on the interrelation, is included as header information in the transmitted first data packet.

2. The method of claim 1, further comprising:receiving (1102) the second data packet and transmitting the second data packet to the second UE, wherein the time indication is included as header information in the transmitted second data packet.

3. The method of claim 1, comprising:controlling (1106) the time indication in the radio node.

4. The method of claim 3, wherein controlling comprises:receiving (1107), from at least one of the first and second UEs, a report indicative of a packet delay from the radio node, wherein the radio node is enabled to control the time indication for the first and second UEs based on said packet delay.

5. The method of claim 3, wherein controlling comprises:determining (1107) a first packet delay of a first data path to the first UE and a second packet delay of a second data path to the second UE;configuring (1108) the delivery time based on the largest delay of said data paths.

6. The method of claim 3, wherein controlling comprises:determining (1109) a packet delay from an upstream radio node from which at least the first at least data packet was transmitted;37transmitting (1110) a report indicative of the packet delay to the upstream radio node for control of the time indication.

7. The method of claim 1, comprising:buffering (1111) at least said first data packet to promote aligned time of reception in the first and second UEs based on said time indication.

8. The method of claim 1, wherein the radio node is a base station of the wireless system or a relay node.

9. The method of claim 1, wherein an indication of the interrelation is included as header information in said first and second data packets.

10. The method of claim 9, wherein the indication of interrelation comprises an identification of multi-modality between a first stream associated with the first data packet and a second stream associated with the second data packet.

11. The method of claim 9, wherein the indication of the interrelation of each of said data packets comprises an identification of the other data packet with which the interrelation exists.

12. The method of claim 11, wherein said identification is indicative of a Quality of service, QoS, flow of said other data packet with which the interrelation exists.

13. The method of claim 1, wherein the time indication is indicative of a time of delivery of payload data of the data packets to an upper protocol layer in the first and second UEs.

14. A method carried out in a first user equipment, UE, of a wireless system, wherein the method comprises:receiving (1201) a first data packet from a radio node;obtaining (1202), from header information of the first data packets, a time indication associated with delivery time of the data packet in the first UE based on an interrelation with a second data packet for a second UE;delivering (1204) pay load data of the first data packet to a receiving entity in the UE based on the time indication.

15. The method of claim 14, comprising:buffering (1203) the first data packet to deliver the payload data according to the time indication.

16. The method of claim 14, comprising:determining (1205) a packet delay from the radio node to the first UE; transmitting (1206) a report indicative of the detected packet delay to the radio node for control of the time indication.

17. The method of claim 14, wherein an indication of the interrelation is included as header information in said first data packet.

18. The method of claim 17, wherein the indication of interrelation comprises an identification of multi-modality between a first stream associated with the first data packet and a second stream associated with the second data packet.

19. The method of claim 14, wherein the time indication is indicative of a time of delivery of payload data of the data packets to an upper layer in the first UE.

20. A method carried out in a core network node in a wireless system, wherein the method comprises:receiving (1301) first data to be transmitted to a first user equipment, UE, and second data to be transmitted to a second UE, wherein the first and second data have an interrelation;controlling (1304) an access node of the wireless system to transmit a first data packet comprising the first data to the first UE and a second data packet comprising the second data to the second UE, with a time indication as header information in said firstand second data packets, wherein the time indication is associated with a delivery time of the data in said UEs based on the interrelation.

Images