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

Abstract

A method carried out in a radio node, such as a relay node, for conveying data in a wireless system, wherein the method comprises: receiving (1205) a first data packet originating from a first user equipment, UE, and a second data packet originating from a second UE; determining (1206) a first time indication associated with the first data packet and a second time indication associated with the second data packet; synchronizing (1209) transmission of said received data packets to a receiving node of the wireless system based on said time indications and an interrelation between 0 the first and second data packets.

Description

[0001] METHODS AND DEVICES FOR FACILITATING TIMELY DELIVERY OF DATA TRANSMITTED FROM 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 from different wireless devices to a receiving node.

[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 remote nodes, (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 from different UEs destined to be received in the same receiving node, wherein the receiving node may reside in the wireless network or in another UE. This is particularlythe case when there is an interrelation between such data such that timely delivery of data from two or more UEs in the receiving node is pertinent. This may, for instance, be the case when the data from different UEs relate to a common task or application, such as in the case of multi-modality. The different transmitting UEs are typically unaware of data obtainment and transmission from other UEs. Moreover, transmission from different UEs may take 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. 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 a first data packet originating from a first user equipment, UE, and a second data packet originating from a second UE;

[0014] determining a first time indication associated with the first data packet and a second time indication associated with the second data packet;

[0015] synchronizing transmission of said received data packets to a receiving node of the wireless system based on said time indications and an interrelation between the first and second data packets.

[0016] The proposed solution also refers to a radio node, comprising logic circuitry configured to carry out the outlined steps. The radio node may be a relay node or a base station of the wireless system.

[0017] According to another aspect, the proposed solution relates to a method carried out in a UE for facilitating conveying of data from the UE in a radio node of a wireless system, wherein the method comprises:

[0018] creating a data packet comprising obtained data as payload and header information comprising a timestamp associated with obtainment of the data or data packet;transmitting the data packet to the radio node for further transmission to a receiving node.

[0019] The proposed solution also refers to a UE, comprising logic circuitry configured to carry out the mentioned steps.

[0020] Based on the proposed solution, interrelated data transmitted from different UEs may be appropriately handled by synchronization of transmission from the radio node to ensure timely delivery in the receiving node. Specifically, the proposed solution provides a technical contribution which allows for handling of interrelated data from different UEs to be timely received in the receiving node for use in, e.g., XR applications, industrial applications, digital twinning applications, etc.

[0021] Brief description the drawings

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

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

[0024] Fig. 3 schematically illustrates a UE, which may act as a remote node in conjunction with the relay node, according to various examples. The UE may be configured to transmit data, and may optionally be configured to act as a receiving node for data.

[0025] Fig. 4 schematically illustrates a radio node in the form of an access node configured to operate in the wireless network according to various examples.

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

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

[0028] Fig. 7 schematically illustrates a scenario in which the proposed solution may be employed.Fig. 8 illustrates relay operation according to Layer 2 and Layer 3 configuration, respectively.

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

[0030] Fig. 10 schematically illustrates transmission of interrelated data from different UEs over at least one relay node to a common receiving unit in a scenario where the proposed solution may be applicable.

[0031] Fig. 11 schematically illustrates aspects associated synchronization of data packets comprising interrelated data from different UEs in a radio node according to various aspects of the proposed solution.

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

[0033] Detailed description

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

[0035] 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 system for the sake of easy understanding, while this shall merely be seen as an example.

[0036] Fig. 1 illustrates a high-level perspective of operation in a wireless system involving 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.

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

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

[0039] 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 UL and optionally also DL communication in connection with a wireless network 100. In this context, to convey data may be understood as to retransmit or relay the received data. Uplink data to the wireless network, e.g., for use by the AF 106, may originate from one or more UEs 20, 21, 22, which may be referred to as remote nodes when operating over the relay node 10. In other scenarios, the relay node 10 may be configured to receive data from one or more UEs 20, 21 and to transmit the received data to a third UE 22, e.g., to an application running in that UE 22. 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.

[0040] It may be noted that any of the relay node 10 and the UEs 20, 21, 22 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 remote nodes 20, 21 may additionally be configured to communicate directly with the access network 120, even though this is not indicated in the drawing.

[0041] The UEs 20, 21, 22 may be devices configured to obtain or generate data associated with a certain context, such as a task or application, and to transmit the datato a receiving entity or node. The data may be obtained by the UE itself, or by a connected sensor, such as a haptic sensor, image sensor, microphone, etc. Obtainment of the data may be caused by or linked to a certain event, action, or reaction which may take place in the real world or in a virtual context, such as in an application. In various scenarios it may be relevant for the receiving node, either in or connected to the wireless network 100 or in another UE, that the obtained and transmitted in a timely manner. This may refer to the need to fulfil certain latency requirements between data obtainment and delivery in the receiving node. Reception in a timely manner may in some examples include properly determining relative or absolute time of obtainment of data received from a plurality of UEs. Such UEs may be different devices configured to obtain and transmit data of various types, such as audio, video, tactile, inertial, etc. By way of example, this may relate to obtainment of data in an XR application.

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

[0043] 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 (remote node) 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 air interface. The transceiver 14 may be or comprise a modem configured to encode, transmit, receive and decode data using radio waves.

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

[0045] 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, logic circuitry 11 configured to execute management function operation (e.g., radio resource management or computing resource management for UEs 20, 21). As indicated in Fig. 1, this may include radio links 141, 142 configured forreceiving for data transmission from UEs 20, 21, wherein a link 140 is configured for at least UL data transmission to the access network 120, e.g., a serving access node 121. In other use cases, a link 143 may be configured for transmission to the UE 22 of data received over radio links 141, 142 from the UEs 20, 21. 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.

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

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

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

[0049] The relay node 10 may be configured to receive data from two or more UEs 20, 21, to schedule or request scheduling of the data for transmission further to the access network 120 or the UE 22, and carry out said transmission on the associated radio link 140 or 143. In some examples, the relay node 10 may be configured to operate inaccordance with the document 3GPP 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 remote nodes 20, 21 may be referred to as PC5 links or reference points as defined in that document. 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 and transmitting the data.

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

[0051] 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 for carrying 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 remote node 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.

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

[0053] 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.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 remote node 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.

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

[0055] The logic circuitry 210 may further include memory storage 212, which may include one or multiple memories and / or one or multiple other types of storage mediums. For example, the memory storage 212 may include a random access memory (RAM), a dynamic random access memory (DRAM), a cache, a read only memory (ROM), a programmable read only memory (PROM), flash memory, and / or some other type of memory. The memory storage 212 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.). The memory storage 212 is configured for holding computer program code, which may be executed by the processing device 211, wherein the logic circuitry 210 is configured to control the UE 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.

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

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

[0058] 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. Theaccess 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 remote nodes 20, 21, 22.

[0059] The access node 121 may comprise a wireless transceiver 313, such as a radio transceiver for communicating with other entities of the radio communication network 100, such as the UE 20. 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.

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

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

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

[0063] 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 theprocessing 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.

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

[0065] The access node 121 may further comprise an interface 316, configured for communication with the core network 110. This may include transmitting or conveying received data to a receiving node, such as the AF 106.

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

[0067] 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 from a radio node in or connected to the RAN 120 for transmission or delivery to e.g., the AF 106. 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.

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

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

[0070] 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 for communication with entities outside the wireless network 100 for transmitting received data, such as the AF 106.

[0071] The context of the proposed solutions is transmission of interrelated data from transmitting UEs, which data is conveyed in a radio node 10, 121, possibly including several relay nodes, on route to a receiving node, which may reside in or connected to the wireless network 100 or in another UE 22. Specifically, this relates to an interrelation between different data packets, or data streams of the data packets, which are received in the radio node 10, 121 from different UEs 20, 21 before being retransmitted towards the receiving node. The interrelation may mean that the data of the interrelated data packets are interdependent. This may be due to the receiving node having a desire or requirement in obtaining information related to relative time of obtainment in the different UEs 20, 21 of the received data, and / or absolute time information related to the obtainment. By way of example, the data from different UEs 20, 21 may be interdependent on account of said data representing an action or reaction captured by the respective UE 20, 21 based on the same causing or triggering event, or relating to a common operation, such as a common scene in an XR game. In this context, it may be desired or required that the time of obtainment of data in the respective UE 20, 21 is ascertained, rather than the time of reception in the receiving node. This may, e.g., be related to a multiplayer scenario in an XR application. Theproposed solution is useful for managing data transmission over the radio node 10, 121, where various factors may cause different amounts of delay from the originating UEs 20, 21 to the receiving node. 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.

[0072] Interrelated data packets may in some examples be of different types, which are associated with each other in an application, such as visual data, audio data, tactile data, or other types. In other examples, the interrelated data packets may be of the same type, optionally even comprising the same data content. The interrelated data packets may relate to a common event or item in an application, such as a certain game sequence.

[0073] The data may from different UEs be transmitted in different data streams. In 5G, communication of data within the wireless system is accomplished in QoS flows.

[0074] Different data streams may thus be mapped to different QoS flows.

[0075] The legacy 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 Data Radio Bearers (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).

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

[0077] 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.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:

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

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

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

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

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

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

[0084] 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.43and 7.11 two kinds of coordination transmission requirements are discussed, for reference:

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

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

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

[0088] 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 over a radio node 10, 121 from different UEs to a common receiving node, such as in the context of multi-modality.

[0089] 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 remote nodes, 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 requirement, or preference, that interrelated data carried in different data flows associated with different multi-modal streams are synchronized.

[0090] 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 transmit 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. Data obtained / generated in therespective UEs within the XR application may be interrelated. This may apply to some rather than all data, or some QoS flows rather than all. The interrelation, e.g., which data packets or which multi-modality flows are interrelated, may be defined on application level. By way of example, Fig. 7 indicates various different UEs (reference numerals mainly indicated for one user 71 for reasons of simplicity), including the following:

[0091] handheld tools 711, which may be configured to generate inertial or accelerometer data based on movement or impact;

[0092] visors 712 (722 for user 72), such as a head-mounted display (HMD) which may include a microphone, which may be configured to capture eye / gaze data and audio data;

[0093] wristbands 713 and ankle bands 714, which may include motion sensor (e.g., an accelerometer) be configured to generate inertial or accelerometer;

[0094] a mat or floorboard 715, which may be configured to sense pressure and generate tactile data.

[0095] The application is configured to provide data streams of different types, or modalities, wherein the data streams include interrelated data packets. The interrelation, or interdependency, between the interrelated data packets may be associated with an expected or required level of experience of the XR application. Notably, proper control of the XR application will benefit from having knowledge and control of when the interrelated data is obtained in the different UEs. This may, e.g., reflect which UE (and, by extension, which user) is faster or reacts faster, or may be used for determining or ensuring that data from different UEs were obtained within a certain allowable or required time period or time gap relative to each other. Additionally, or alternatively, knowledge of when data is obtained in the UEs may be useful for obtaining, in the receiving node, proper alignment of interrelated data associated with the same user, such that timing of, e.g., audio, video, and tactile data, triggered by the same user, can be represented in the application as it was captured.

[0096] As already mentioned, transmission over the relay node 10 from the UEs 20, 21 acting as remote nodes 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.

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

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

[0099] In a relay node 10 configured to implement an L3 Relay, the protocol stack includes all layers in the RAN 120, up to SDAP. 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 remote node 20, 21 are originating in the L3 Relay 10 and terminating in the respective remote node 20, 21.

[0100] 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 remote node 20, 21.

[0101] It may be noted that synchronization between the different data flows may mainly be performed in the MAC (Medium Access Control). Therefore, ordering and / or scheduling of data packets based on interdependency, as outlined herein, is valid for implementation in both L2 and L3 Relays.

[0102] Based on the foregoing, it may be acknowledged that different UEs may obtain and transmit data in data packets of different data streams, or flows, which shall be aligned in time. In an UL example, this may relate to a scenario when two or more different UEs react to the same DL activity from the application. The UL transmissions may in some examples be aligned in one joint multi-modality flow in order to keep the synchronization between these reactions. When these multiple UEs are transmitting simultaneously to the radio node, i.e., the relay node 10 or the access node 121, and they have data UL streams which are interrelated or comprise interrelated data packets, e.g., video, audio and / or haptic data, these streams should be handled as multimodality streams and thereby the streams should be synchronized to ensure immersive user experience.

[0103] Fig. 10 illustrates, by way of example, data flows from at least two UEs 20, 21 comprising interrelated data packets, to be conveyed over a relay node 10 to an application layer as the receiving node, represented by the AF 106. The illustrated UE 22 may in some examples provide yet another interrelated data stream or may in other examples implement the receiving node of the application, such as in a SL scenario. Ascan be noted, there may be more layers, i.e. relay hops, in one of the legs than in the other leg, and latency from the two UEs 20, 21 may be different.

[0104] It will be clear that a challenge exists when the two or more UEs transmit interrelated data, e.g., defined by multimodality interrelation, and the interrelated data shall be kept synchronized. In case the UEs 20 and 22 in Fig. 10 transmit data at the same time, there is a chance that the data will also arrive at the relay node 10 at the same time. However, in case of the UEs 20 and 21 transmit data at the same time, the transmitted data from UE 20 will be received at a later time than data originating from UE 21 because it passes through an extra relay node 10A. The corresponding problem occurs in the access node 121 when two or more UEs are connected over the Uu interface.

[0105] The problem discussed above, to keep synchronization on per packet level (PDU or PDU Set), has not been solved in the legacy system. The legacy relay node has no information about inter QoS flow dependencies, especially not from different sources. The Relay node may know mapping between 5QI and PQI, but it does not have the information on how the different QoS flows are related. Hence, the end-to-end delay requirements for the full multi-modality stream cannot be addressed by the relay node.

[0106] A solution is therefore proposed for overcoming this routing problem by introducing a per packet routing and time / delay information related to the Logical channel handling the multimodality flow, in at least inter UE multi-modality.

[0107] According to one aspect, the proposed solution may be set out in a radio node 10, 121. Examples will predominantly be provided with reference to the radio node being the relay node 10, configured to convey data by wirelessly receiving and retransmitting data. However, it should be noted that the radio node may in alternative embodiments be an access node 121, i.e., a base station of the wireless system, arranged to convey data by wirelessly receiving data and further forwarding the data to the CN 110. The radio node 10 comprises logic circuitry 11, 310 configured to control the radio node to carry out the method as proposed herein.

[0108] Fig. 11 schematically shows an exemplary scenario of data transmission from two UEs 20, 21, wherein the data transmission is conveyed over a radio node 10, 121 by transmitting the received data packets for forwarding to a receiving node which e.g., may be implemented in a further UE 22 or in the AF 106 in or connected to the network 100. For the sake of explanation, reference is made to Fig. 11 at places below. It shouldbe noted that Fig. 11 specifically provides an embodiment in which timestamps are included in the received data packets, whereas alternative embodiments are also discussed below.

[0109] The proposed solution implements a method carried out in the radio node 10, 121 for conveying data in the wireless system. The method comprises receiving at least a first data packet Packet#l:N originating from a first UE 20 and receiving a second data packet Packet#2:M+l originating from a second UE 21. Each data packet may be received in a respective data stream #1 and #2, which may be transmitted in a separate QoS flows.

[0110] The radio node 10, 121 is arranged to determine a first time indication associated with the first data packet and a second time indication associated with the second data packet.

[0111] The radio node 10, 121 is further configured to synchronize transmission of said received data packets to a receiving node of the wireless system based on said time indications and an interrelation between the first and second data packets. The synchronizing may comprise aligning transmission timing of the first and second data packets, based on the interrelation. In this context, synchronizing may include ordering or scheduling transmission to adhere to a mutual delay budget, configured for the interrelated data packets.

[0112] As the data packets are received in the radio node 10, 121 from separate individual UEs 20, 21, each of those UEs has no knowledge or control over the data transmitted from the other UE, and particularly not the timing of any such transmission. The time indication determined in the radio node is thus helpful in the radio node for the synchronization and alignment of the further data transmission.

[0113] The proposed solution is particularly useful for use in relay node 10, e.g., when the UEs 20, 21 are synchronized with the relay node 10 by SL frame structure.

[0114] According to some examples, in order for the relay node 10 to synchronize transmission in UL streams, such as different QoS flows, the time indication may comprise include a timestamp in the received data packets (as shown in Fig. 11), which may be indicative of when the data packet was generated, or when the data comprised as payload in the data packet was generated, such as by an application. The timestamp may be added to the appropriate protocol, e.g. in the SDAP for a L3 Relay, or in SRAP layer in case of L2 Relay, or when it is entered in the UL transmission buffer in MAClayer. The radio node 10 may thus be arranged to determine the time indication by obtaining the timestamps from header information of the respective received data packet, wherein each timestamp is associated with obtainment in the respective UE 20, 21 of the data included as pay load in the data packets.

[0115] The UEs 20, 21 operating as remote UEs are synchronized with the relay node 10 by SL frame structure. The UEs 20, 21 may therefore not have any other knowledge of time, such as within a common time format, used in the network 100. Therefore, the timestamp sent from the UEs will be based on the SL synchronization. Based on synchronization of the relay node 10 with the wireless network 100, the time information provided by the timestamps may nevertheless be used for indicating or determining the interrelation between data packets from the different UEs.

[0116] Some elements of the indication of interrelation between data packets, originating from the two UEs 20, 21, can be introduced in the relay node 10, since this information is not available or known in the UEs 20, 21, e.g. an identification of the data stream or flow in which the interrelated data packets. The interrelation between the data streams is configured from the network 100, and may be defined through multi-modality information, such as a Multi-modal Service ID (MMSID). An indication, such as the MMSID, of the data stream in which the respective UE 20, 21 transmits data may be added to the packet headers by each UE 20, 21. While each UE 20, 21 is aware that of its transmitted data stream has an interrelation to another stream (e.g., as defined by the MMSID), the UEs 20, 21 are however unaware of when the other stream sends packets, so it cannot know specific packet interrelation and related timing. Specifically, it may be noted that not all data packets in a particular QoS flow from the respective UE 20, 21 are necessarily interrelated, the interrelation may relate to data packets in specific data streams, e.g., from the application.

[0117] Where the timestamps are based on local synchronization between the radio node 10 and the transmitting UEs 20, 21, the radio node may be configured to provide updated time indications as header information of the respective received data packet, wherein the updated time indications are provided according to a time format used in a network of the wireless system.

[0118] In SL, there is a mutual, or local, synchronization of time (absolute time or relative time (e.g., frame, subframe, slot level)) between the SL devices, i.e. the remote UEs 20, 21 and the relay node 10, e.g., through the synchronization of the SL airinterface. Thereby, the timestamps on the data packets can be accurate. Where the receiving node, such as an entity implementing an application, is connected in or via the network 100, the timestamp from a transmitting UE 20, 21 needs to be given in or converted to a common time for the network 100 of a format used in a network, such as the SFN (System Frame Number) or UTC. In some examples, this is done in the relay node 10, which may act as a management node as described above, which acts as an access point between a subnetwork of SE devices and the network 100, and which knows both SE synchronization time and a common time. Updating the time indications may thus include translating the time indication of the timestamps given according to the local synchronization, into an updated time indication provided according to the common time format of the network 100 and providing the updated time indications in the headers of the data packets.

[0119] Alternatively, if the timestamp is given in a common time format used in the network 100, such as SFN, synchronization / alignment and optional addition of the interrelation in the packet headers can be handled in the relay node 10 or in the access node 121. It may be noted that the same SFN may be used in neighbor cells, served by different access nodes) so the timestamp may be used between the access nodes as well.

[0120] In another example the UEs 20, 21, which may act as remote UEs in a SE subnetwork, do not add timestamp. In such a case, the radio node 10 or 121 is configured to add the time indication as header information of the respective received data packet. This may be based on the radio node being configured to treat the data packets as received in interrelated data streams or QoS flows. In addition to the time indications, the radio node adds the interrelation information, by providing information associated with the interrelation as header information of the interrelated data packets before forwarding (transmitting) the packets, e.g. to the access node 121 or receiving UE 22 where the radio node is the relay node 10, or to CN 110 where the radio node is the access node 121, for delivery to the receiving node or entity. This example is based on that the notion that the data packets still are in a reasonably good synch when they are received from the UEs 20, 21, particularly in case of SL connection between the UEs 2021, and the relay node 10, but do not have the information of the interrelated packets in the header, which can be used in the UL or SL transmissions.

[0121] The radio node is thus arranged to provide information associated with the interrelation (indicated as Interrelation in Fig. 11) as header information in therespective data packets and to forward the data packets, e.g. to the access node 121 or a subsequent relay node in case of subnetwork to subnetwork. The information associated with the interrelation may include Multi-modality information, such as a Multi-modal Service ID (MMSID). In some examples, the information associated with the interrelation may comprise, in each of the interrelated data packets, an indication of a data stream, logical channel, or QoS flow, of the other data packet to which it is interrelated. In some examples, the information associated with the interrelation may comprise a relative latency requirement, such as a mutual delay buffer between the interdependent data packets from the different UEs 20, 21.

[0122] The radio node, i.e., the relay node 10 or access node 121, is configured with the multi-modality relation between the data streams of the first and second data packets. The configuration may be determined in the CN 110, e.g. in negotiation with the AF 106 to which the data streams are associated, and the configuration may control the radio node to attach the information associated with the interrelation in the packet headers together with the existing QoS parameters given by the PQI / 5QI including time budget.

[0123] The time indication, in combination with the knowledge in the radio node that the received data streams from the different UEs 20, 21 are interrelated, or comprise interrelated data packets, allows for the radio node to synchronize, e.g., align, timing of forwarding of the interrelated data packets upon conveying data. The addition of the information of interrelation upon forwarding the data packets from the radio node may assist any further nodes between the radio node and the receiving entity that ordering, in the radio node, of the transmission based on said first and second timestamps was carried out to promote timely delivery of the interrelated data packets.

[0124] When this information associated with the interrelation is available in the data stream the interrelated packets can be handled together in UL from the Relay node as proposed in applicant’s prior application SE2450968-9, the contents of which are hereby incorporated by reference.

[0125] In Fig. 11 an example is provided, wherein the radio node configures the order in which it will execute transmission based on said first and second timestamps, on account of the interrelation. As stream# 1 and stream#2 may be conveyed in QoS flows with different QoS priority, the radio node may here be configured (as opposed to legacy procedures), to order transmission in accordance with the time stamps, ratherthan first emptying a transmit buffer of the highest QoS flow or maintaining the order of reception including other packets not related to the multimodal QoS flows. In the drawing, transmission from the radio node is indicated as one stream or flow, but it should be understood that it may still provide transmission of data packets (e.g., PDU or PDU Set) originating from the different UEs 20, 21 in different QoS flows. Based on configuration of the radio node that stream# 1 and stream#2 are interrelated, the radio node may thus order its transmission such that synchronization, or alignment, of transmission is obtained between the data packets based on the obtained time stamps from the received data packets. This may include ordering the transmission such that the interrelated data packets having the same time stamp have aligned transmission timing, e.g., in simultaneously or in succession. The timestamps in the respective UEs 20, 21 define how the data packets are related. In this example Packet#l:N (Nth packet from UE 20) has the same timestamp as Packet#2:M+l from UE21. Thereby, these packets should be synchronized before forwarding them, as indicated in Fig. 11.

[0126] Fig. 12 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 21 indicates as remote nodes 20, 21 in the drawing. The application is connected to receive data in (and optionally also transmit to) an application server, connected through an application function 106 to the network 100. The network 100 wirelessly receives data from the UEs 20, 21 in the RAN 120 (e.g., in access node 121), connected via the relay node 10. The description provided with reference to Fig. 12 shall only be regarded as one detailed example useful for understanding the proposed solution.

[0127] Step 1201 indicates that UEs 20 and 21, and relay node 10, are registered and configured and the subnetwork (SN) comprising at least these devices is setup and configured. This may involve ProSe configuration according to legacy procedures. This configuration may define what devices, e.g., UEs 20, 21, 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 operated by relay node 10 (e.g., a subnetwork to support gaming, a subnetwork to support sensornetwork, etc.). This will give an indication of what kind of traffic may be operated in the subnetwork.

[0128] A subnetwork is a special purpose network that can support localized and high-performance connectivity within an entity. The concept of entity stands here for specific use case unit with limited operational radius, where one of more subnetworks can be installed for a set of coherent and correlated operations. As mentioned above, entities can be robots, production modules, vehicles, but even classrooms for consumer type of applications. A subnetwork may feature any of the following characteristics:

[0129] • Short range (below 10 meters) low power cells, meant at offering very localized connectivity by offloading larger networks of demanding services.

[0130] • Integrate the support of services with diverse requirements, including extreme requirements in terms of latency, reliability or data rates, i.e., below 0.1 ms latencies or communication cycle, nine-nines reliability (defined as packet error rate), or multi-Gbps rates

[0131] • May comprise one or more relay node with integrated edge processing capabilities and a potentially large number of cost-effective and potentially computationally constrained devices with limited form factor, such as sensors / actuators.

[0132] • Can operate stand-alone, in case the connection with an umbrella network, 100, e.g. a 6G network, drops or is intermittent. The umbrella network can take care of efficiently orchestrating the subnetwork operations when connection is available.

[0133] In the context of step 1201, the relay node 10 may further be configured to support multi-modality. In the case the subnetwork is using AF 106 in or connected to the CN 110, there is at least one relay node, and in the simplest form only one subnetwork with one relay node. In case of subnetwork-to-subnetwork interaction, there is at least one relay node per subnetwork, and potentially at least one of the relay nodes may implement further overall management functionality to moderate the different subnetwork interactions and prioritizations etc. Each subnetwork may nevertheless comprise more than one relay node.

[0134] Step 1202 indicates that data streams containing multimodality (MM) data are configured from AF 106 to the CN 110. This may include information or configurationindicating interrelation between those two data streams, for use in the CN 110 to configure QoS flows for conveying the different data streams.

[0135] Step 1203 indicates that the data streams are configured to the UEs 20, 21 and started. This may include setting up QoS flows and configuring the transmitting UEs 20, 21 to introduce timestamps (if applicable) and for the relay node 10 to synchronize transmission of data packets received from the UEs 20, 21 based on determined time indications associated with the data packets and an interrelation between the data packets of the two streams.

[0136] Step 1204 indicates creating, in the UEs 20, 21, of at least one data packet comprising obtained data as payload and header information comprising a timestamp associated with obtainment of the data. This step may include obtaining data in the respective UE, e.g. from a sensor or an application layer, and including that data in one or more data packets, e.g., a PDU. As noted, to set and include the timestamp associated with obtainment of the data, is optional.

[0137] Step 1205 indicates that two data streams (i.e., multi-modality (MM) streams) are sent, one from each UE 20, 21 and received in the relay node 10, where the data packets have (may have) timestamps usable for generating the synchronization between the data packets. The UEs 20, 21 thus transmit the data packets to the relay node 10 for further transmission to a receiving node (AF 106 in the shown example).

[0138] Step 1206 indicates that, in the relay node 10, the respective time indications of the received data packets are determined, either by obtaining the timestamps from the received data packets or alternatively by setting time of reception of the data packet in the transceiver 14 of the relay node 10.

[0139] Step 1207 indicates providing time indication as header information in the received data packets, in the optional and alternative steps of providing updated time indications of a common time format of the network as header information if obtained timestamps are based on local synchronization, e.g., SL, or providing time indication based on time of receiving the data packets if no time stamp is received.

[0140] Step 1208 indicates providing information associated with the interrelation as header information of the first data packet and of the second data packet. Such information may comprise an identification of multi-modality, such as MMSID. In some examples, the provided information may further comprise, in each data packet having an interrelation, an identification of the other data packet with which theinterrelation exists. In some examples, the identification is indicative of a Quality of service, QoS, flow of said other data packet with which the interrelation exists. In some examples, the provided information is indicative of allowed latency between interrelated data packets.

[0141] Step 1209 indicates that, in the relay node 10, the received data packets are synchronized, i.e., aligned, based on time indication, i.e., the timestamps received in the data packets or alternatively time of reception of the data packet in the transceiver 14 of the relay node 10. The synchronization may involve ordering of the transmission from the relay node 10 based on the timestamps, e.g. by scheduling.

[0142] Step 1210 indicates that the data packets are transmitted for reception in the receiving node (AF 106 in this example) according to the synchronization.

[0143] Based on what is outlined herein, the proposed solution thus provides a new procedure for handling of interrelated data transmitted from different UEs, such that the interrelated data may be synchronized in a radio node, such as in a relay node 10. Based on the proposed solution, inter packet dependencies, i.e., interrelation between individual data packets of separate data streams and QoS flows, may be identified and used in the radio node, such as the relay node 10. The radio node is configured 1203 to handle the packet synchronization between the data streams from two or more UEs 20, 21 which sends interrelated data e.g., in a multi-modality session, to an application function 106 in the network 100 or to another device 22. The radio node determines timing information (time indication) added by the UEs 20, 21, or set by the radio node, to each data packet of interrelated data streams of flows. The radio node may add interrelation information of the related packets or streams in the multiple streams from UEs 20, 21. From the perspective of UEs 20, 21, each UE may be configured to add timestamps for each data packet. These timestamps may be added in MAC, SRAP (layer 2) or SDAP (layer 3) or any other potentially applicable protocol. The proposed solution may comprise any combination of the items listed below.

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

[0145] receiving (1205) a first data packet originating from a first user equipment, UE, and a second data packet originating from a second UE;

[0146] determining (1206) a first time indication associated with the first data packet and a second time indication associated with the second data packet;synchronizing (1209) transmission of said received data packets to a receiving node of the wireless system based on said time indications and an interrelation between the first and second data packets.

[0147] Item 2. The method of item 1, wherein determining the time indication comprises obtaining timestamps from header information of the respective received data packet, each timestamp being associated with obtainment in the respective UE of data included as pay load in the data packets.

[0148] Item 3. The method of item 2, comprising:

[0149] providing (1207), upon said timestamps being based on local synchronization between the radio node and the UEs, updated time indications as header information of the respective received data packet, wherein the updated time indications are provided according to a time format used in a network of the wireless system.

[0150] Item 4. The method of item 3, wherein the timestamps are based on Sidelink synchronization.

[0151] Item 5. The method of item 1, wherein the time indication is indicative of a time of reception the respective data packet in the radio node.

[0152] Item 6. The method of item 5, comprising:

[0153] adding (1207) the time indication as header information of the respective data packet.

[0154] Item 7. The method of any preceding item, wherein the radio node is a relay node. Item 8. The method of item 7, wherein the receiving node is a third UE.

[0155] Item 9. The method of any of items 1-7, wherein the radio node is a base station of the wireless system.

[0156] Item 10. The method of item 8 or 9, wherein the receiving node is a network node of the wireless system.

[0157] Item 11. The method of any preceding item, wherein the first and second data packets are received in different multi-modality streams of an application.

[0158] Item 12. The method of any preceding item, wherein synchronizing comprises ordering the transmission from the radio node based on said first and second timestamps.

[0159] Item 13. The method of any preceding item, comprising:

[0160] providing (1208) information associated with the interrelation as header information of the first data packet and of the second data packet.Item 14. The method of item 13, wherein the information indicative of the interrelation comprises an identification of multi-modality.

[0161] Item 15. The method of item 13 or 14, wherein the provided information of each of said data packets comprises an identification of the other data packet with which the interrelation exists.

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

[0163] Item 17. The method of any of items 13-16, wherein the provided information of each of said data packets is indicative of allowed latency between said data packets based on the interrelation.

[0164] Item 18. A radio node (10), comprising:

[0165] a transceiver (14);

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

[0167] Item 19. A method carried out in a user equipment, UE, for facilitating conveying of data from the UE in a radio node of a wireless system, wherein the method comprises:

[0168] creating (1204) a data packet comprising obtained data as pay load and header information comprising a timestamp associated with obtainment of the data;

[0169] transmitting (1205) the data packet to the radio node for further transmission to a receiving node.

[0170] Item 20. The method of item 19, comprising:

[0171] providing said timestamp based on local synchronization between the UE and the radio node, wherein the data packet is transmitted to the radio node for transmission in the wireless system.

[0172] Item 21. The method of item 20, wherein said timestamp is based on Sidelink synchronization.

[0173] Item 22. The method of any of items 19-21, comprising:

[0174] obtaining (1203) configuration of at least one multi-modality stream for transmitting the data packet including the timestamp.

[0175] Item 23. The method of any of items 19-22, wherein the data is obtained from a multi-modality application running on the UE.Item 24. A user equipment, UE, (20), comprising:

[0176] a transceiver (213);

[0177] logic circuitry (210), configured to control the UE to carry out any of the steps according to items 19-23.

Claims

32CLAIMS1. A method carried out in a radio node for conveying data in a wireless system, wherein the method comprises:receiving (1205) a first data packet originating from a first user equipment, UE, and a second data packet originating from a second UE;determining (1206) a first time indication associated with the first data packet and a second time indication associated with the second data packet;synchronizing (1209) transmission of said received data packets to a receiving node of the wireless system based on said time indications and an interrelation between the first and second data packets.

2. The method of claim 1, wherein determining the time indication comprises obtaining timestamps from header information of the respective received data packet, each timestamp being associated with obtainment in the respective UE of data included as pay load in the data packets.

3. The method of claim 2, comprising:providing (1207), upon said timestamps being based on local synchronization between the radio node and the UEs, updated time indications as header information of the respective received data packet, wherein the updated time indications are provided according to a time format used in a network of the wireless system.

4. The method of claim 3, wherein the timestamps are based on Sidelink synchronization.

5. The method of claim 1, wherein the time indication is indicative of a time of reception the respective data packet in the radio node.

6. The method of claim 5, comprising:adding (1207) the time indication as header information of the respective data packet.

337. The method of claim 1, wherein the radio node is a relay node.

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

9. The method of claim 1, wherein the first and second data packets are received in different multi-modality streams of an application.

10. The method of claim 1, wherein synchronizing comprises ordering the transmission from the radio node based on said first and second timestamps.

11. The method of claim 1, comprising:providing (1208) information associated with the interrelation as header information of the first data packet and of the second data packet.

12. The method of claim 11, wherein the information indicative of the interrelation comprises an identification of multi-modality.

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

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

15. The method of claims 11, wherein the provided information of each of said data packets is indicative of allowed latency between said data packets based on the interrelation.

16. A method carried out in a user equipment, UE, for facilitating conveying of data from the UE in a radio node of a wireless system, wherein the method comprises:creating (1204) a data packet comprising obtained data as pay load and header information comprising a timestamp associated with obtainment of the data;transmitting (1205) the data packet to the radio node for further transmission to a receiving node.

17. The method of claim 16, comprising:providing said timestamp based on local synchronization between the UE and the radio node, wherein the data packet is transmitted to the radio node for transmission in the wireless system.

18. The method of claim 17, wherein said timestamp is based on Sidelink synchronization.

19. The method of claim 16, comprising:obtaining (1203) configuration of at least one multi-modality stream for transmitting the data packet including the timestamp.

20. The method of claim 16, wherein the data is obtained from a multi-modality application running on the UE.

Images