Technique for handling multi-modal PDU sets

Abstract

A technique for handling multi-modal PDU sets is described. As to a method (300) aspect of the technique performed by a wireless device, WD (100; 1700; 1991; 1992; 2030), wirelessly connected or connectable to an access network, AN (510), the method (300) comprises or initiates obtaining (306) at the WD (100; 1700; 1991; 1992; 2030) at least one inter-dependency (760) between at least two packet data unit sets, PDU sets (750), wherein the PDU set (750) comprises at least one quality of service, QoS, parameter of the PDU set (750), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510). The method further comprises or initiates sending (310), to the AN (510), a report message (506) indicative of the at least one obtained (306) inter-dependency (760).

Description

[0001]Technique for handling multi-modal PDU sets Technical Field The present disclosure relates to a technique for handling multiple sets of packet data units (PDUs). More specifically, and without limitation, methods and devices are provided for handling multi-modal PDU sets. Background In the rapidly evolving landscape of telecommunications, the fifth generation (5G) of wireless technology has ushered in an era of unprecedented connectivity and innovation. This technological leap promises to support a myriad of services with diverse requirements, ranging from high-speed mobile broadband to mission-critical communications and immersive extended reality (XR) applications. As the boundaries of digital interaction expand, so does the need for more sophisticated mechanisms to manage the Quality of Service (QoS) that ensures user experiences remain seamless and responsive. With the introduction of 5G, the concept of PDU (Protocol Data Unit) sets emerged as a pivotal element in Release 18 specifications of the Third Generation Partnership Project (3GPP). PDU sets are designed to encapsulate units of information generated at the application level, such as video frames or slices, and ensure their transmission within the same QoS flow. This is critical for services such as XR, wherein even minor disruptions or delays can significantly degrade the user experience. The PDU set framework aims to meet the stringent QoS demands of these applications by providing parameters like PDU set Delay Budget (PSDB) and PDU set error rate (PSER), which help to define the acceptable bounds for delay and error rates in data transmission.However, assuming a UE provides or receives multi-modal (e.g., uplink) data fromdifferent data traffic flows such as video and audio with different networkrequirements such as high bandwidth as opposed to low latency, respectively,the RAN may end up in a situation allocating many resources for the video flow,while the audio flow had been discarded, e.g. due to a temporary latency issue,resulting in a silenced video flow, the user experience of which could be evenworse compared to interrupting the entire audio-video service. Summary Accordingly, there is a need for a technique that enables handling multiple PDU sets, particularly for multi-modal services. As to a first method aspect, a method performed by a wireless device (WD)wirelessly connected or connectable to an access network (AN) is provided. Themethod comprises or initiates obtaining, at the WD, at least one inter-dependency between at least two packet data unit sets (PDU sets). The PDU setmay comprise at least one quality of service (QoS) parameter of the PDU set, e.g.,in an uplink towards the AN and / or in a downlink from the AN. Alternatively or in addition, the method comprises or initiates sending, to the AN, a report message indicative of the at least one obtained inter-dependency. At least some embodiments of the method enable the AN (e.g., the networknode serving the WD) to take the reported one or more inter-dependenciesbetween the at least two PDU sets into account when scheduling resources for the PDU sets. For example the at least two PDU sets may be handled in mutual concordance. The handling, i.e., the scheduling, may be performed or triggeredat the AN (e.g., the RAN) or the core network (CN) serving the AN, e.g., in a fifth-generation system (5GS) for optimal wireless (e.g., optical or radio) resourcemanagement (e.g., RRM). For example, embodiments can inform the gNB is notwell informed of the one or more inter-dependencies.The technique may be embodied by a method for the WD (e.g., a UE) to provideinter-dependency information of multi-modal flows.According to an embodiment, the WD (e.g., a UE) reports "multi-modality"information (i.e., the report message), which indicates inter-dependency of multiple application flows (which may be implemented using the at least two PDU sets) to serve the same service. This information (i.e., the report message) mayinclude a recommendation of mapping a group of QoS flow indicators (QFI) (e.g.,corresponding to the at least two PDU sets) to a common data radio bearer (DRB). Alternatively or in addition, the report message may be indicative of a set of DRBindexes (e.g., to identify the inter-dependent PDU sets) and / or a set of applicationflow specific information (such as port numbers and IP addresses) determine the service that uses the at least two PDU sets. The signaling (i.e., the step of sending the report message) may be done by radio resource control (RRC) signaling, e.g., UE assistance information (UAI). Without limitation, for example in a 3GPP implementation, the WD may be a radiodevice, e.g. a user equipment (UE). The AN may be embodied by one or morenetwork nodes (e.g., one or more gNBs). The report message may trigger the scheduling, i.e., replacing or modifying one ormore existing rules for scheduling the at least two PDU sets (e.g., rules forscheduling radio resources, rules for bearer selection and / or rules for mapping theUL or DL bearer to a QoS flow) at the AN (e.g., at the network node serving thewireless device). For example in a 4G or Long Term Evolution (LTE) setting, fortraffic that is unicasted in the UL or DL, the WD may use UL traffic flow templates(TFTs) to select UL bearers of an evolved packet system (EPS). The TFTs may be used to map one or more data flows from the WD to the appropriate one or more bearers based on at least one of: the report message, one or more QoSrequirements, an internet protocol (IP) address of the service (a client applicationor a server application), the direction of the traffic (UL or DL), a protocol, and a port number. The report message may be indicative of the QoS and / or DRB to beused, e.g. instead of the conventional selection according to one or more TFTs atthe AN or CN. As a further example in a 5G or New Radio (NR) setting, the report message may trigger the replacement or modification of existing rules for scheduling of at least one of the at least two PDU sets, such as rules for scheduling radio resources, bearer selection, or mapping the uplink (UL) bearer to a Quality of Service (QoS) flow at the Access and Mobility Management Function (AMF) or the Next Generation NodeB (gNB) serving the WD. For instance, in the case of unicasted UL or DL traffic, the wireless device may utilize UL traffic flow templates (TFTs) to select UL bearers within the 5G system. These TFTs can be applied to map multi-modal data flows from the WD to the appropriate bearers based on factors including the report message, QoS requirements, IP addresses, traffic direction, protocols, and / or port numbers. The report message may provide an indication ofthe QoS or DRB to be used based on and / or instead of using one or more TFTs atthe AN or CN. The report message may trigger or enable the AN (e.g., a network node of the AN) to prioritize and / or manage the (e.g. different) quality of service (QoS) requirements of the at least two PDU sets by using scheduling, admission control, and / or resource allocation. Alternatively or in addition, the report message may trigger or enable the AN (e.g., a network node of the AN) to discard all PDUs of the at least two PDU sets if one of the at least two PDU sets is lost and / or if one PDU (or a certain number of PDUs) of at least one of the inter-dependent at least two PDU sets is (or are) lost. Whenever referring to QoS, a corresponding feature and / or step is also disclosed and implementable by replacing QoS for any measure of user experience, e.g. a Quality of Experience (QoE). The access network (AN) may be a wireless AN, e.g. a radio access network (RAN). Sending the report message may be referred to as reporting. The obtaining of the inter-dependency may be referred to as linking, grouping or measuring of the PDU sets. The at least two PDU sets may be referred to as the different PDU sets. The obtaining and the reporting may relate (e.g., exclusively) to the UL between the WD and the AN, e.g. between the WD and one or more network nodes of the AN. For example, the at least one inter-dependency between the at least two PDU sets may be obtained (e.g., measured) for the UL towards a first network node of the AN. The report message may be sent to a second network node of the AN. The second network node may be different from the first network node (e.g., spatially separate base stations). Alternatively, the obtaining and the reporting may relate to the UL between the WD and the same network node. The QoS measured in the wireless device may also be referred to as the user experience. Alternatively or in addition, when there is an inter-dependency between the at least two PDU sets, the at least two may be also referred as two inter-dependent PDU sets. The at least two inter-dependent PDU sets may serve the same service (e.g., the same application). For example, the same service may generate or receive or process the at least two inter-dependent PDU sets. The quality of the user experience may be dependent to the at least one inter- dependency between the PDU sets. The WD may sent, e.g. may attempt to transmit, the at least two PDU sets and / or the at least one inter-dependency between the at least two PDU sets, to the AN. For example, the at least two PDU sets and / or the at least one inter-dependency between them may be available for sending or transmission at the WD or may have been partially sent or transmitted to the AN. In other words, "towards" may encompass that the WD attempts to send or transmit each of the at least two PDU sets, which are not necessarily received at the AN. Each PDU set may comprise a plurality of PDUs. Alternatively or in addition, each PDU of the PDU set may refer to a data unit of a user plane (UP) PDU layer, e.g. responsible for PDU session establishment. The different PDUs within one or each of the at least two PDU sets may relate to the same data source or data type, e.g. of a multi-modal data stream. The different PDU sets may relate to different types of data within one multi-modal data stream. The multi-modal data stream may comprise multiple types of data according to the at least two inter-dependent PDU sets, e.g. images, text, audio, video, haptic sensors, etc. The obtained and / or reported inter-dependency between the at least two PDU sets (e.g., the measurement or observation or fact that or cause why the at least two PDU sets are inter-dependent) may comprise that the at least two PDU sets have a semantic and / or causal relationship with each other, and / or provide complementary or contradictory information and / or are correlated and / or dependent on one another. For example, a video stream may be considered as a multi-modal data stream that contains both visual and audio data, which are related by temporal synchronization and / or the content of a scene. Another example may be a multi-modal dataset for autonomous driving (e.g., including full- surround observations), which may comprise one or more camera images, one or more Light Detecting and Ranging (LiDAR) point clouds, satellite-based radio navigation system (e.g., GPS) coordinates, and / or vehicle states. These different types of data (e.g., different data streams) may be carried by respectively different PDU sets, which are inter-dependent, e.g. by the spatial alignment and the dynamic environment. At least one of the WD and an application server, which may exchange the PDU sets through the AN, may provide or use an eXtended Reality (XR) service and / or a multi-modal machine learning (ML) model based on the at least two inter- dependent PDU sets. The service of the multi-modal ML model may encompass a training phase of the multi-modal ML model and / or an inference phase of the multi-modal ML model. Alternatively or in addition, the service of the multi-modal ML model may encompass applications of deep multimodal learning and / or any (sub-)combination of computer vision, natural language processing, speech recognition, emotion recognition, human-computer interaction. Alternatively or in addition, the inter-dependency may relate to a handling (e.g., processing or rendering or analyzing) of the at least two PDU sets. The inter- dependency may imply a need for synchronization, coordination, and / or concurrent processing of these heterogeneous data types to ensure seamless communication and / or service delivery. Alternatively or in addition, data in the different PDU sets may be encoded according to different protocol. For example, video may be sent using protocols that support streaming such as Real-Time Transport Protocol (RTP), while sensor data may utilize a more lightweight protocol like MQTT or CoAP. Any one of the examples of the handling of the at least two PDUs may be implemented by edge computing (e.g., at the AN). The different PDU sets may comprise different data types and may originate from different sources. For example, the multi-modal data streams may originate from various sensors and devices, each capturing a different aspect of information. For example, video streams require high bandwidth and low latency to maintain quality, while sensor data might be small-sized packets that are sent at regular intervals or upon certain events. For example, the AN may control network slicing in accordance the reported inter- dependency. With the advent of fifth generation (5G) networks, network slicing allows for the creation of multiple virtual networks on the same physical network infrastructure. Each slice can be tailored to meet the specific needs of different multi-modal data streams, ensuring the right balance of latency, throughput, and reliability. The AN may allocate the at least two PDU sets to the same network slice. In an embodiment, one or each of the at least two PDU sets may correspond to one or more data traffic flows. Alternatively or in addition, each of the at least two PDU sets may correspond to and / or originates from one service. The data traffic flows may be data streams. The service may be an application. The service may comprise a server application (e.g., linked to the WD through the AN) and a client application performed by the WD. The different PDU sets may be associated with different QoS requirements (also: QoS levels), e.g. even though the different PDU sets may serve the same service. Therefore, a user experience (e.g., at the WD) may be is strongly related to performing inter-dependent scheduling (e.g. at the AN, e.g. the network node of the AN) that is controlled by the inter-dependency (e.g., synchronization) and / or not by applying the same QoS level to each of the at least two PDU sets. In an embodiment, the at least two PDU sets may correspond to different data traffic flows or different data types. Alternatively or in addition, the at least two PDU sets may correspond to at least two of: a video flow, an audio flow, one ormore environmental information flows, a pose flow, a gesture flow, and a hapticflow. The one or more data traffic flows may also be referred to as multi-modal (e.g., multi-modal communication) as they are corresponding (e.g., serving) the same service. For example, a video conference may be a multi-modal communication as it comprises at least two data traffic flows, audio flow and video flow, serving video conference.In an embodiment, the at least two PDU sets (e.g., the at least two of the datatraffic flows) may be inter-dependent because of a synchronization requirementbetween the at least two PDU sets (e.g., between the at least two of the datatraffic flows). Alternatively or in addition, the at least two PDU sets, optionally the at least two of the data traffic flows, may be inter-dependent because of a common internet protocol (IP) address and / or port number and / or medium access control (MAC) address synchronization requirement of the at least two PDU sets, optionally of the at least two of the data traffic flows. Alternatively or in addition, the at least two PDU sets, optionally the at least two of the data traffic flows, may be inter-dependent because of a correlation between the at least two PDU sets, optionally between the at least two of the data traffic flows. The inter-dependent data flows may be, for example, two synchronized data flows.For instance, in a video conference the audio flow and the video flow may need tobe synchronized to fulfill quality of user experience. Alternatively or in addition, the inter-dependent PDU sets or data flows may originate from the same host source and / or may be targeted to the same destination host. Alternatively or in addition, the inter-dependent PDU sets or data flows may be correlated across their different data types. The correlation may be measured in terms of a relative entropy or mutual information between the at least two PDU sets, e.g. between the at least two of the data traffic flows. In an embodiment, the report message may be indicative of statistical information of the at least one inter-dependency between the at least two PDU sets. Alternatively or in addition, the report message may include at least one of a minimum, a maximum, an average, a variance, and a probability distribution of a delay of one or each of the at least two PDU sets. The delay may be a relative timing offset between the at least two PDU sets. Alternatively or in addition, the delay may be a deviation from a synchronization between the at least two PDU sets. For example, the synchronization may correspond to a (e.g., equivalence or linear) relation between sequence numbers of the PDUs in the different PDU sets. The delay may correspond to a deviation from the relation in terms of the sequence numbers for available PDUs of the different PDU sets to be sent from the WD towards the AN (e.g., towards the network node). Alternatively or in addition, the synchronization may be measured (e.g., at the WD) based on a timestamp in each of the PDU in the different PDU sets. The delay may correspond to a deviation between the timestamps of PDUs available for UL transmission at WD.In an embodiment, the at least two PDU sets (e.g. the at least two of the datatraffic flows) may be received by an application layer of the WD and / or receivedfrom an application layer, e.g. an application server, through a network node ofthe AN. Alternatively or in addition, the at least two PDU sets, optionally the at least two of the data traffic flows, may be sent from an application layer of the WD and / or sent to an application layer, optionally an application server, through a network node of the AN.In an embodiment, the method may further comprise or initiate determiningwhether the obtained at least one inter-dependency may fulfil a predefined criterion. Alternatively or in addition, the report message may be indicative of whether or not the predefined criterion is fulfilled. Alternatively or in addition, the transmission of the report message may be triggered if the predefined criterion is not fulfilled. A predefined criterion may be defined in a way to fulfill a minimum quality of user experience and / or a QoS level or criterion. For example, the predefined criterion may comprise a maximum delay (e.g., a maximum relative timing offset) and / or theIn an embodiment, the method may further comprise or initiate sending acapability message to the AN. Alternatively or in addition, the capability message may be indicative of a capability of the WD to measure at least one QoS parameter across the at least two the PDU sets, optionally in the uplink towards the AN or in the downlink from the AN. Alternatively or in addition, the capability message may be indicative of a capability of the WD to obtain the at least one inter-dependency between the at least two measured PDU sets. Alternatively or in addition, the capability message may be indicative of a capability of the WD to report a result of the obtainment of the at least one interdependency to the AN. Alternatively or in addition, the capability message may be indicative of a capability of the WD to report a result of the measurement of the at least one QoS parameter across the at least two the PDU sets. Alternatively or in addition, the capability message may be indicative of a physical layer information of the WD. Alternatively or in addition, the capability message may be indicative of a feature set indicator, optionally comprising radio protocol information. The QoS parameter across the at least two the PDU sets may comprise the delay (e.g., the relative timing offset) and / or the mutual information between the at least two the PDU sets. Measuring the QoS parameter across the at least two the PDU sets may be a substep of the obtaining step.In an embodiment, the method may further comprise or initiate receiving aconfiguration message from the AN for the obtaining or the sending. Alternatively or in addition, the configuration message may be indicative of a or the QoS parameter across the at least two PDU sets to be measured or obtained. Alternatively or in addition, the configuration message may be indicative of the predefined criterion, optionally a threshold for the delay. Alternatively or in addition, the configuration message may be indicative of a QoS flow, optionally a QoS flow may identifier (QFI) associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a data radio bearer (DRB) associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of PDU set identifiers of the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a cross-PDU set importance, cross-PSI, associated with the at least two PDU sets and / or indicative of an importance level of the inter-dependency. Alternatively or in addition, the configuration message may be indicative of a set of QoS flow identifiers (QFIs) associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a set of DRB indexes associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of matching information for matching the at least two PDU sets that are inter-dependent and / or a set of application flow specific information associated with all of the at least two PDU sets that are inter- dependent. Alternatively or in addition, the configuration message may be indicative of an obtaining mode for the obtaining of the inter-dependency. Alternatively or in addition, the configuration message may be indicative of a reporting mode for the sending of the report message. Alternatively or in addition, the configuration message may be indicative of an obtainment window for the obtaining of the inter-dependency and / or for measuring the at least one QoS parameters across the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a periodicity for the measuring, the obtaining, and / or the sending of the report message. Alternatively or in addition, the configuration message may be indicative of a deadline for the sending of the report message. The received configuration message from the AN may be based on, or responsive to, the transmitted capability message to the AN. The set of application flow specific information may comprise port numbers, and / or IP addresses. In an embodiment, a (e.g., the aforementioned) obtaining mode for the obtaining of the at least one inter-dependency and / or a (e.g., the aforementioned) reporting mode for the sending of the report message may comprise a periodic obtaining and / or a periodic report message. Alternatively or in addition, the obtaining mode and / or the reporting mode may comprise an aperiodic obtaining and / or an aperiodic report message. Alternatively or in addition, the obtaining mode and / or the reporting mode may comprise an event-triggered obtaining and / or an event- triggered report message. Alternatively or in addition, the obtaining mode and / or the reporting mode may comprise on-demand obtaining and / or an on-demand report message. The event-triggered (e.g., obtaining and / or reporting) mode may encompass fulfilment of the predefined criterion as the triggering event. The predefined criterion may be received from the AN, e.g., indicated in a configuration message. Herein, on-demand may comprise upon request, e.g., upon receiving a request message from the AN (e.g., from the first or second network node). In an embodiment, the predefined criterion may be defined in terms of, or mayinclude a value for a threshold of, the correlation between the at least two PDUsets. Alternatively or in addition, the synchronization between the at least two PDU may set. Alternatively or in addition, the predefined criterion may be defined in terms of, or may include a value for a threshold of, the QoS may parameter across the at least two the PDU sets. Alternatively or in addition, the predefined criterion may be defined in terms of, or includes a value for a threshold of, a PDU set error rate (PSER) or a PDU set delay budget (PSDB) applicable to the combination of the inter-dependent at least two PDU sets. In an embodiment, the report message may use or comprises at least one of RadioResource control (RRC) signaling; UE Assistance Information (UAI); a Packet DataConvergence Protocol (PDCP) control PDU; and a Service Data Adaptation Protocol (SDAP) control PDU. Alternatively or in addition, the sending may comprise sending the report message in a control plane (CP) data unit using an RRC layer, a PDCP layer and / or an SDAP layer. A layer 2 of a protocol stack for the wireless (e.g., radio) communication between the wireless device and the AN (e.g., for fifth generation new radio, 5G NR) may be split in sublayers including at least one of SDAP, PDCP, radio link control (RLC) and medium access control (MAC). In other words sending the report message may use the second layer or the RRC layer (which may be referred to as the third layer or network layer or a "higher" layer) of the protocol stack. In an embodiment, a or the reporting mode may comprise at least one of periodic reporting, an event-triggered reporting, and on-demand reporting. In an embodiment, all PDUs in the PDU set may be transmitted on the same QoS flow. Alternatively or in addition, all PDUs in the PDU set may be transmitted or received with the same QoS level or the same QFI. Alternatively or in addition, PDUs of different ones of the at least two PDU sets may be transmitted or received with different QoS levels or different QFIs. Alternatively or in addition, PDUs of different ones of the at least two PDU sets may be transmitted or received ondifferent DRBs, e.g., prior to the sending of the report message. Alternatively or inaddition, the report message may be indicative of, or includes a request for, mapping the at least two PDU sets to the same DRB. Alternatively or in addition, the report message may be indicative of, or includes a request for, mappingdifferent QoS flows, e.g., different QFIs, of the at least two PDU sets to the sameDRB. Alternatively or in addition, all PDUs of the at least two PDU sets may be transmitted or received on the same DRB, e.g., responsive to the sending of the report message. In an embodiment, the report message may be transmitted to a network node ofthe AN, e.g., to the network node serving the WD.In an embodiment, the method may further comprise or initiate sending to the AN,e.g. to the serving network node, a request message indicative of, or includes a request for, mapping the at least two PDU sets to the same DRB and / or indicative of, or includes a request for, mapping different QoS flows, optionally different QFIs, of the at least two PDU sets to the same DRB. Alternatively or in addition, themethod may further comprise or initiate sending to the AN, e.g. to the servingnetwork node, a confirmation message, optionally an RRC-Reconfiguration- Complete message indicative of adapting a reconfiguration, optionally confirming an adaptation to a changed mapping of the at least two PDU sets to the same DRB and / or mapping different QoS flows, optionally different QFIs, of the at least two PDU sets to the same DRB. The report message and / or the request message and / or the RRC-Reconfiguration- Complete message may be indicative of adapting (or adopting) a reconfiguration, e.g. for scheduling resources in the uplink of the WD. As to a second method aspect, a method performed by a network node of anaccess network (AN) is provided. The method comprises or initiates receiving areport message from a WD wirelessly connected to the AN. The report message may be indicative of at least one inter-dependency between at least two packetdata unit sets (PDU sets) at the WD (e.g., in an uplink towards the AN and / or in adownlink from the AN). Alternatively or in addition, the method comprises orinitiates scheduling resources (e.g., for the uplink or downlink) of the WD based onthe received report message. The second method aspect may further comprise any feature and / or any step disclosed in the context of the first method aspect, or a feature and / or step corresponding thereto, e.g., a receiver counterpart to a transmitter feature or step. When the WD (e.g., a UE) reports the at least one inter-dependency of the at least two PDU sets, the AN (e.g., the gNB) may use this information to optimize network performance or network resources and / or ensure that QoS requirements are met either for each of the at least two PDU sets or all of the at least two PDU sets are discarded. Embodiments can improve scheduling decisions at the AN. For example, with up- to-date inter-dependency, the AN (e.g., the first and / or second network node, preferably a gNB) can make better-informed scheduling decisions, DRB mappings, and / or balance prioritizing traffic of mutually dependent PDU sets that are sensitive to delay or errors and / or can manage congestion more effectively. The method may be performed by a network node of the AN, e.g., the network node serving the WD or the fore-mentioned first and / or second network node. Alternatively or in addition, the method may be performed by a gNodeB (gNB) (e.g., a base station in a 5G network as the AN), which interfaces with the WD (e.g., a user equipment (UE)) and a core network (e.g., a 5G core network, 5GC). By scheduling resources based on the received report message, embodiments of the AN (e.g., gNB) can leverage the PDU sets and their inter-dependency reported by the WD (e.g., UE) to optimize a performance of the AN, and / or ensuring that user experiences are consistent with the QoS profiles defined for various services. This can be critical in 5G ANs, wherein a wide range of services with diverse QoS requirements must be supported simultaneously. The scheduling may comprise configuring the WD with radio resources for the uplink. Alternatively or in addition, the scheduling may comprise setting one or more AN parameters related to the WD and / or the PDU set, e.g. at least one of a data rate, a (e.g., remaining) PDU set delay budget, and the predefined criterion for at least a pair of PDU set (e.g. an inter-dependent PDU set pair). Alternatively or in addition, upon reception of the report message, the AN may use the information to configure enhanced scheduling mechanism, such as a configured grant (CG), discontinuous reception (DRX), and pre-scheduling or semi-persistent scheduling (SPS). The receiving of the report message may comprise analyzing the report. For example, the AN (e.g., the gNB) may process the received one or more report messages to determine the inter-dependency and / or current QoS performance for the at least two PDU sets and / or for each WD (e.g., UE). This may involve analyzing QoS parameters of the at least two PDU sets related to error rate, delay, and throughput according to a service. Herein, the QoS requirement of the at least two PDU sets and the predefined criterion for the at least two PDU sets may be equivalent and / or these terms may be used interchangeably. The QoS requirement for the at least two PDU sets may be, or may be derived from, a service level agreement (SLA) for the service (e.g., application) underlying the at least two PDU sets. Alternatively or in addition, the receiving of the report message may comprise assessing compliance of the at least two PDU sets with their inter-dependency (e.g., as a requirement for user experience assessment and / or as defined by the predefined criterion for the combination of the at least two PDU sets). Herein, a network may comprise the AN, and optionally a core network (CN) serving the AN. In an embodiment, the scheduling of the resources may comprise adjusting a resource allocation of the at least two PDU sets, optionally if the received report message is indicative of one of the at least two PDU sets fulfilling its QoS requirement while another one of the at least two PDU sets does not fulfill its QoS requirement. Alternatively or in addition, the resource allocation for the WD may be adjusted by changing the resource allocation of temporal resources, frequency resources and / or spatial resources of the AN and / or a transmit power control settings. Alternatively or in addition, the scheduling of the resources may comprise configuring one or more functions of the AN, e.g. of the network node, based on the received report message. For example, Hybrid Automatic Repeat Request (HARQ) settings may be reconfigured or a modulation and coding scheme (MCS) may be reconfigured or a retransmission strategy may be reconfigured. Alternatively or in addition, the scheduling of the resources may comprise updating PDU set handling at the AN for the inter-dependent at least two PDU sets. Alternatively or in addition, the scheduling of the resources may comprise adapting to a dynamic traffic one or more patterns. E.g., the AN may use the received report message as dynamic QoS performance information to adapt to changing traffic patterns and / or. A service or an application underlying the at least two PDU sets may use variable bit rates or burst-like traffic. Alternatively or in addition, the scheduling of the resources may comprise sending a feedback to a core network serving the AN. E.g., sending the feedback to the core network may be indicative of a QoS performance of the service based on the combination of the at least two PDU sets and the received report message, preferably to update policies and / or rules for traffic management and / or PDU session establishment.In an embodiment, the method may further comprise or initiate receiving acapability message from the WD. Alternatively or in addition, the method mayfurther comprise or initiate optionally. The capability message may be indicative ofa capability of the WD to measure at least one QoS parameter across the at least two the PDU sets, optionally in the uplink towards the AN or in the downlink from the AN. Alternatively or in addition, the capability message may be indicative of a capability of the WD to obtain the at least one inter-dependency between the at least two measured PDU sets. Alternatively or in addition, the capability message may be indicative of a capability of the WD to report a result of the obtainment of the at least one interdependency to the AN. Alternatively or in addition, the capability message may be indicative of a capability of the WD to report a result of the measurement of the at least one QoS parameter across the at least two the PDU sets. Alternatively or in addition, the capability message may be indicative of a physical layer information of the WD. Alternatively or in addition, the capability message may be indicative of a feature set indicator, optionally comprising radio protocol information. In an embodiment, the method may further comprise or initiating transmitting a configuration message to the WD. Alternatively or in addition, the configuration message may be indicative of a or the QoS parameter across the at least two PDU sets to be measured or obtained. Alternatively or in addition, the configuration message may be indicative of the predefined criterion, optionally a threshold for the delay. Alternatively or in addition, the configuration message may be indicative of a QoS flow, optionally a QoS flow may identifier (QFI) associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a data radio bearer (DRB) associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of PDU set identifiers of the at least two PDU sets. Alternatively or in addition, theconfiguration message may be indicative of a cross-PDU set importance (cross-PSI)associated with the at least two PDU sets and / or indicative of an importance level of the inter-dependency. Alternatively or in addition, the configuration message may be indicative of a set of QoS flow identifiers (QFIs) associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a set of DRB indexes associated with the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of matching information for matching the at least two PDU sets that are inter- dependent and / or a set of application flow specific information associated with all of the at least two PDU sets that are inter-dependent. Alternatively or in addition, the configuration message may be indicative of an obtaining mode for the obtaining of the inter-dependency. Alternatively or in addition, the configuration message may be indicative of a reporting mode for the sending of the report message. Alternatively or in addition, the configuration message may be indicative of an obtainment window for the obtaining of the inter-dependency and / or for measuring the at least one QoS parameters across the at least two PDU sets. Alternatively or in addition, the configuration message may be indicative of a periodicity for the measuring, the obtaining, and / or the sending of the report message. Alternatively or in addition, the configuration message may be indicative of a deadline for the sending of the report message. In an embodiment, the scheduling may comprise changing a mapping of one or more data radio bearers (DRBs) to at least one or two QoS flows or QFIs used by the at least two PDU sets in response to the receiving of the report message. Alternatively or in addition, the scheduling may comprise changing a mapping of at least one or two QoS flows or QFIs used by the at least two PDU sets to one or more data radio bearers (DRBs) in response to the receiving of the report message. In fourth generation (4G) LTE (Long Term Evolution) and fifth generation (5G) NR (New Radio), a Data Radio Bearer (DRB) may be a service provided by the radio protocol architecture to transfer user data between the WD (e.g., a UE) and the AN (e.g., a RAN). The DRB may be responsible for the transfer of user plane data. The DRB may be technically characterized by several parameters that define how data is handled and transmitted over the radio interface. The scheduling may comprise changing at least one of these parameters, e.g. for each or at least one of the inter-dependent at least two PDU sets. For example, the scheduling may comprise changing at least one of these parameters so as to align the parameters for the inter-dependent at least two PDU sets. Each DRB may be associated with a specific QoS profile, which defines the treatment that the data flowing over this bearer will receive. This may include parameters such as priority, packet delay budget, packet error loss rate, and bit rates (GBR, MBR, etc.) of the level of individual PDUs, which can be controlled by the AN as opposed to the reported QoS parameters on the level of the PDU set, which cannot be measured at (e.g., the lower layers) of the AN. The QoS profile may ensure the required level of service for various types of traffic such as voice over IP (VoIP), real-time video, or best-effort data transfer. The DRB may be mapped to a Logical Channel, which is an abstract concept defining the type of information being transferred. For example, a dedicated traffic channel (DTCH) may be used for user plane data transfer. A radio link control (RLC) protocol may be operated for the PDU set in one of three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). Each DRB may be associated with an RLC entity that operates in one of these modes, defining the level of reliability for the data transfer. The scheduling may comprise changing the mode. For example, transparent mode does not provide error correction, unacknowledged mode may provide partial error correction, and acknowledged mode may use an Automatic Repeat Request (ARQ) mechanism for full error correction. The scheduling may comprise changing a configuration of a packet data convergence protocol (PDCP). The PDCP may provide header compression, decompression, and ciphering functionalities to reduce overhead and secure the data. The PDCP configuration for a DRB may define how the data should be processed by the PDCP layer. The scheduling may comprise establishing, modifying, or releasing a radio bearer setup by signaling procedures between the WD (e.g., UE) and the AN. These procedures may define the properties of the one or more DRBs and how data is to be managed over them. The scheduling may comprise changing a security of the PDU set on the one or more DRBs, which may be encrypted and / or integrity-protected to ensure privacy and prevent tampering. The scheduling may comprise mobility handling of the PDU set. The one or more DRBs may be configured to support seamless handovers when the WD (e.g., a UE) moves from one cell to another. This can ensure that all PDUs in the PDU set are continuously transferred despite the mobility of the WD. A Quality of Service flow (QoS flow) in the context of 3GPP specifications, particularly for 5G networks (5G NR), may encompass any concept defined in a service-based architecture of the AN and / or the core network (CN) serving the AN to manage and / or ensure the delivery of all PDUs in the PDU set with the required service quality. Each QoS flow may be identified by a QoS Flow Identifier (QFI). The QFI may be unique for the WD and / or within a PDU session of the WD. The QFI may be used for mapping between the 5G Core (5GC) as the CN and the Radio Access Network (RAN) as the AN. The QFI may be carried in the protocol headers to differentiate between different QoS flows. The scheduling of resources for the PDU set may comprise changing at least one parameter in a set of parameters associated with each QoS flow to define the required treatment by the network. These parameters include QoS Class Identifier (5QI), Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR) for data flows requiring a certain minimum bit rate, Maximum Data Burst Volume (MDBV) for GBR flows, and Non-Dynamic 5QI. The 5QI may be an index defining a scalar QoS characteristics of IP packets transferred in the PDUs of the PDU set, which are reference to the level of guarantee to be provided for packet delivery. The ARP may be used for ensuring resources in congested situations and has a priority level, preemption capability, and preemption vulnerability. The GBR and the non-GBR may be two types of QoS flows. In the GBR, the QoS flow is allocated a certain amount of network resources, while a non-GBR QoS flow shares resources with other flows. The scheduling may comprise changing QoS rules of the level of PDUs. The QoS may be defined by rules that govern how certain types of traffic are treated within the AN or the CN or the network. These rules may be used to determine how packets are forwarded in a QoS flow and / or include QoS rule identifiers, precedence, and segregation and aggregation rules. The scheduling may comprise changing a traffic flow template. For mapping between the user traffic and the QoS flows, one or more traffic flow templates (TFTs) may be used. These templates classify PDUs in the PDU set based on parameters such as source and destination IP addresses, source and destination ports, protocol identifiers, and more. For the PDU set, the AN may apply the changed template to all PDUs in the PDU set. The scheduling may comprise QoS flow level signaling or any signaling procedures for establishing, modifying, or releasing the QoS flows between the WD and the network (e.g., the AN or the CN). For example, the scheduling may comprise protocols and procedures for the QoS flow setup during the establishment of the PDU session. The scheduling of the resources responsive to received report message may comprise a deviation from reflective QoS and / or reflective mapping of DRBs to QFIs. For example, in a first state, the AN may use for the uplink the same QoS treatment and / or mapping as the corresponding downlink flow without explicit signaling from the WD. In a second state, the AN may use for the uplink the a QoS treatment and / or mapping the is different from the corresponding downlink flow based on the received report message. The scheduling may control an operation of the AN to ensure that all PDUs of the PDU set associated with a QoS flow are handled in the network, complying with the predefined criterion (e.g., a QoS requirement of the PDU set). Embodiments, especially in 5G networks, can support diverse services with different QoS requirements for their PDU sets, such as enhanced mobile broadband (eMBB), ultra-reliable and low latency communications (URLLC), and massive machine type communications (mMTC). Embodiments of any one of the first and second method aspects can enhance the management of Quality of Service (QoS) for multi-modal (e.g., uplink) communication in wireless networks. Embodiments of the method enable a wireless device (WD) to obtain (e.g., measure) a relationship (e.g., inter-dependency) between Packet Data Unit (PDU) sets (e.g., in the uplink directiontowards the access network, AN) and subsequently send a report message to theAN indicating the results of this obtaining step (e.g., measurement or observationor packet inspection). At least some of these embodiments can improved QoS management, e.g., by equalizing the QoS for the at least two PDU sets. By measuring QoS parameters,such as delay, jitter, and / or packet loss of the PDU set as a whole and for differentPDU sets related to the same service, the WD can provide valuable feedback to theAN, allowing the AN to adjust scheduling in the broadest technical sense (e.g.,resource allocation and error correction strategies) to meet the QoS requirementsof different data flows, or to discard the inter-dependent PDU sets in the first place. Same or further embodiments can achieve real-time performance monitoring. Theability to obtain (e.g., measure) and report the inter-dependency (e.g., measuredin terms of one or more QoS parameters across the at least two PDU sets), e.g. inreal-time, enables the AN to dynamically monitor the performance of the (e.g.,uplink or downlink) connection. This can be particularly important for applications with multiple streams each requiring stringent QoS levels, such as extended reality (XR) services, wherein even small deviations in QoS can significantly impact user experience. Same or further embodiments can enhance network responsiveness. With timely report messages from the WD, the AN can quickly respond to changing network conditions or service requirements, e.g. implementing adjustments to maintain or improve the QoS for active PDU sets. Same or further embodiments can use AN resource more efficiently or more effectively. The information provided by the WD can assist the AN optimize the use of available radio resources, leading to more efficient network operation and / or higher overall throughput. For example, smaller margins in the resource allocation of the multiple PDU set can be controlled by virtue of the measurement report. Same or further embodiments can address or resolve AN issues preemptively. Byidentifying QoS degradation early in one of the inter-dependent PDU sets, the ANcan proactively take corrective actions before service quality is noticeablyimpacted, thus maintaining high service reliability and user satisfaction andavoiding interruption of the entire service. Same or further embodiments can tailor QoS policies. The AN can use the reported QoS measurements to configure QoS policies (e.g., mapping rules or scheduling rules) for groups of PDU sets (e.g., groups of QoS flows), e.g. ensuring that each type of data traffic receives the appropriate QoS based on its specific characteristics and requirements. Alternatively or in addition, the wireless device may be a remote wireless device that is wirelessly connected to the AN through relay wireless device. For example, in the transmitting step, the report message may be forwarded (e.g., on behalf of the wireless device or as a report message of the relay wireless device itself) to the AN. The AN may be a radio access network (RAN). The RAN may comprise one or more network nodes (e.g., base stations), e.g., performing the second method aspect. Alternatively or in addition, the AN may be a vehicular, ad hoc and / or mesh network comprising two or more radio devices, e.g., acting as remote radio device and / or relay radio device. Any wireless device may be a radio device, e.g. a 3GPP user equipment (UE) or a Wi-Fi station (STA). The wireless device may be a mobile or portable station, a device for machine-type communication (MTC), a device for narrowband Internet of Things (NB-IoT) or a combination thereof. Examples for the UE and the mobile station include a mobile phone, a tablet computer and a self-driving vehicle. Examples for the portable station include a laptop computer and a television set. Examples for the MTC device or the NB-IoT device include robots, sensors and / or actuators, e.g., in manufacturing, automotive communication and home automation. The MTC device or the NB-IoT device may be implemented in a manufacturing plant, household appliances and consumer electronics. Whenever referring to the AN, the AN may be implemented by one or more network nodes (e.g., base stations such as optical or radio base stations). The term network node may encompass any station that is configured to provide wireless access (e.g., radio access) to any of the wireless devices. The base stations may also be or may comprise or may define a cell, a transmission and reception point (TRP), a radio access node or access point (AP). Examples for the network node (e.g., base station) may include a 3G base station or Node B (NB), 4G base station or eNodeB (eNB), a 5G base station or gNodeB (gNB), a Wi-Fi AP, and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave). The AN (e.g., the network node serving the wireless device) may provide a data link from the wireless device to a host computer, e.g. providing a PDU set (e.g., carrying user data) in the DL and / or receiving the PDU set (e.g., carrying user data) from the wireless device in the UL. The AN (e.g., the RAN) may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and / or 3GPP New Radio (NR). Any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, a Radio Resource Control (RRC) layer and / or a Service Data Adaptation Protocol (SDAP) layer of a protocol stack for the wireless (e.g., radio) communication. When referring to the first method aspect performed by the wireless device (e.g., a UE), the steps may be performed by one or more entities of one or more protocol layer at the wireless device. When referring to a second method aspect performed by the AN (e.g., the network node such as a gNB or eNB), the steps may be performed by one or more entities of a protocol layer at the AN. Any one of the method aspects may be performed by a combination of different layers. E.g. the SDAP layer in the user plane may be responsible fordefining the QoS requirements and / or mapping of QFI to DRBs and / or the PDCPlayer or the RRC layer may be responsible for processing (e.g., sending or receiving) the report message. Independently of, or in combination with, any aspect or embodiment disclosed herein, a wireless device (e.g., a UE) may be configured (e.g., by receiving a configuration message at the wireless device from the AN in the first method aspect and / or by sending a configuration message from the AN to the wireless device in the second method aspect) to report (e.g., to send) uplink (UL) inter- dependency information (e.g., in the report message), optionally over the RRC or PDCP or SDAP protocol layers. The report message may be dynamically reported, e.g. either periodically, aperiodic, or upon a request from the AN. Herein, referring to a protocol of a layer may refer to the corresponding layer in the protocol stack or a method performed by said layer. Vice versa, referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method. As to another aspect, a computer program product is provided. The computer program product comprises program code portions for performing any one of the steps of the method aspect disclosed herein when the computer program product is executed by one or more computing devices. The computer program product may be stored on a computer-readable recording medium. The computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and / or the host computer. Alternatively, or in addition, the method may be encoded in a Field-Programmable Gate Array (FPGA) and / or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language.As to a first device aspect, a wireless device according to claim 24 or 26 isprovided. The wireless device comprises processing circuitry (e.g., at least one processor and a memory). Said memory comprises instructions executable by said at least one processor whereby the wireless device is operative to perform any one of the steps of the first method aspect. Alternatively or in addition, the wireless device is configured to perform any one of the steps of the first method aspect.As to a second device aspect, a network node according to claim 28 or 30 isprovided. The network node comprises processing circuitry (e.g., at least one processor and a memory). Said memory comprises instructions executable by said at least one processor whereby the network node is operative to perform any one of the steps of the second method aspect. Alternatively or in addition, the network node is configured to perform any one of the steps of the second method aspect. As to a still further aspect, a communication system including a host computer is provided. The host computer comprises a processing circuitry configured to provide or receive user data, e.g., included in the at least two PDU sets. The host computer may comprise a communication interface configured to receive the PDU set from a cellular network (e.g., the AN and / or the network node serving the wireless device) from the wireless device (e.g., a UE). A processing circuitry of the cellular network is configured to execute any one of the steps of the first and / or second method aspects. Alternatively or in addition, the UE comprises a radio interface and processing circuitry, which is configured to execute any one of the steps of the first and / or second method aspects. The communication system may further include the UE. Alternatively, or in addition, the cellular network may further include one or more base stations configured for radio communication with the UE and / or to provide a data link between the UE and the host computer using the first and / or second method aspects. The processing circuitry of the host computer may be configured to execute a host application, thereby providing the first and / or second data and / or any host computer functionality described herein. Alternatively, or in addition, the processing circuitry of the UE may be configured to execute a client application associated with the host application. Any one of the devices, the UE, the base station, the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa. Particularly, any one of the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspect. Any one of the devices, the transmitting node, the receiving node, the user equipment (UE), the network node, the base station, the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa the method aspect may comprise any step or feature disclosed in the context of the device aspects. Particularly, any one of the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspect, and the devices may comprise a unit or a module performing any of the steps of the method aspect. Brief Description of the Drawings Further details of embodiments of the technique are described with reference to the enclosed drawings, wherein:Fig. 1 shows a schematic block diagram of a device embodiment of a first aspectfor handling multiple PDU sets;Fig. 2 shows a schematic block diagram of a device embodiment of a secondaspect for handling a PDU set;Fig. 3 shows a flowchart for a method embodiment of a first aspect for handlingmultiple PDU sets, which method may be implementable by the device of Fig.1;Fig. 4 shows a flowchart for a method embodiment of a second aspect forhandling multiple PDU sets, which method may be implementable by the device of Fig.2;Fig. 5 schematically illustrates a first example of an access network comprisingfirst embodiments of the devices of Figs. 1 and 2 for performing themethods of Figs.3 and 4, respectively;Fig. 6 schematically illustrates an existing downlink network architecture, whichmay be combined with an uplink network architecture according to any of the embodiments of Figs. 1 to 4;Fig. 7A schematically illustrates a second example of an access network and adownlink network architecture comprising second embodiments of the devices of Figs. 1 and 2 for performing the methods of Figs. 3 and 4,respectively;Fig. 7B schematically illustrates the second example from an aggregated point ofview of the multi-modal data implemented by the at least two PDU sets;Fig. 7C schematically illustrates an example of a dual connectivity of the wirelessdevice, which may carry the at least two PDUs and / or which may be set up or changed responsive to the report message according to an embodiment of the method of Fig. 4;Fig. 8 schematically illustrates states of the wireless device and transitionsbetween those states, which may be used in embodiments of the device of Fig. 1;Figs. 9A and 9B schematically illustrates radio resource control signaling,which may be used for exchanging a capability message, a configuration message, a report message, a request message, and / or a confirmation message according to embodiments of the methods of Figs. 3 and 4;Fig. 10 schematically illustrates a block diagram of protocol sublayers forperforming the method of Fig.3 or 4 according to a third embodiment;Fig. 11 schematically illustrates a block diagram of protocol entities forperforming the method of Fig.3 or 4 according to a fourth embodiment;Fig. 12 schematically illustrates a block diagram of protocol entities forperforming the method of Fig.3 or 4 according to a fifth embodiment;Fig. 13 schematically illustrates a block diagram of protocol sublayers forperforming the method of Fig.3 or 4 according to a sixth embodiment;Fig. 14 schematically illustrates different hierarchical levels of PDU aggregation,which distinguish between PDUs in one PDU set of related data type and different PDU sets that are inter-dependent due to a multi-modal operation;Fig. 15 schematically illustrates data traffic flows for different PDU sets, which arerelated by common services;Fig. 16 schematically illustrates a signaling diagram resulting from devices ofFigs. 1 and 2 performing the method of Fig. 3 or 4 according to a seventhembodiment;Fig. 17 shows a schematic block diagram of a wireless device embodying thedevice of Fig. 1;Fig. 18 shows a schematic block diagram of a network node embodying the deviceof Fig. 2;Fig. 19 schematically illustrates an example telecommunication networkconnected via an intermediate network to a host computer;Fig. 20 shows a generalized block diagram of a host computer communicating viaa base station or radio device functioning as a gateway with a user equipment over a partially wireless connection; and Figs.21 and 22 show flowcharts for methods implemented in a communication system including a host computer, a base station or radio device functioning as a gateway and a user equipment. Detailed Description In the following description, for purposes of explanation and not limitation, specific details are set forth, such as a specific network environment in order to provide a thorough understanding of the technique disclosed herein. It will be apparent to one skilled in the art that the technique may be practiced in other embodiments that depart from these specific details. Moreover, while the following embodiments are primarily described for a New Radio (NR) or 5G implementation, it is readily apparent that the technique described herein may also be implemented for any other radio communication technique, including a Wireless Local Area Network (WLAN) implementation according to the standard family IEEE 802.11, 3GPP LTE (e.g., LTE-Advanced or a related radio access technique such as MulteFire), for Bluetooth according to the Bluetooth Special Interest Group (SIG), particularly Bluetooth Low Energy, Bluetooth Mesh Networking and Bluetooth broadcasting, for Z-Wave according to the Z-Wave Alliance or for ZigBee based on IEEE 802.15.4. Moreover, those skilled in the art will appreciate that the functions, steps, units and modules explained herein may be implemented using software functioning in conjunction with a programmed microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP) or a general purpose computer, e.g., including an Advanced RISC Machine (ARM). It will also be appreciated that, while the following embodiments are primarily described in context with methods and devices, the invention may also be embodied in a computer program product as well as in a system comprising at least one computer processor and memory coupled to the at least one processor, wherein the memory is encoded with one or more programs that may perform the functions and steps or implement the units and modules disclosed herein. Each of the disclosed embodiments may be combined with any other embodiment. Fig.1 schematically illustrates a block diagram of an embodiment of a device for handling multiple PDU sets according to a first aspect of the subject technique. The device is generically referred to by reference sign 100. The device 100 may be capable of handling (e.g., identifying and reporting) related PDU sets, such as a wireless device, e.g. a user equipment (UE) in a telecommunication network. The device 100 for handling PDU sets comprises an Inter-Dependency Obtainment Module 106 and a Report Transmission Module 110. The Inter-Dependency Obtainment Module 106 is responsible for obtaining (e.g., determining or measuring or inspecting) the relation or inter-dependency between different PDUsets (e.g., in an uplink towards an access network or in a downlink), which couldaffect the QoS parameters of a multi-modal use case of the different PDU sets and / or which may involve determining metrics such as correlations, mutual information, synchronization, an inter-PDU set delay offset or multi-PDU sets error rates. For example, the measured QoS parameters may pertain to the multiplePDU sets rather than individual PDU sets.Adjacent to this module 106, the Report Transmission Module 110 facilitatestransmitting a report message indicative of the measurement results to an access network (AN, e.g. a RAN). Specifically, this module 110 oversees creating and dispatching the report message, which may be an RRC control message (e.g., aninformation element, IE, and / or UE assistance information, UAI), a PDCP controlPDU or an SDAP control PDU. The report message may carry information such as the relative importance of the different PDU sets for each other and / or for QoS parameter measurements of the combination of PDU sets. The obtaining and / or reporting may be triggered by certain predefined criteria, like exceeding (e.g. positive or negative) thresholds of the cross-PDU set QoS parameters (e.g., a temporal offset) measured by the module 106. This can enable the AN to control the scheduling to steer the QoS for all related PDU sets within a margin above the QoS requirements of the service underlying the PDU set, or to decide that the service cannot be maintained as a whole by removing all inter- dependent PDU sets. Any of the modules of the device 100 may be implemented by units configured to provide the corresponding functionality. The device 100 may also be referred to as, or may be embodied by, the wireless device (or briefly: UE). The wireless device 100 and the AN may be in direct radio communication, e.g., at least for sending the report message from the wireless device 100 to the AN. The AN may be embodied by the device 200, e.g. a base station or network node. Fig.2 schematically illustrates a block diagram of an embodiment of a device forhandling multiple Packet Data Unit (PDU) sets according to a second aspect of thesubject technique. The device is generically referred to by reference sign 200. Thedevice 200 depicted in Fig. 2 may be a network node designed for handling multi-modal PDU sets. This device can be embodied by a gNB, which is an element within an access network (AN) such as a 5G network responsible for communicating with wireless devices like user equipment (UE), e.g. the device 100.A Report Reception Module 210 of the device 200 is tasked with receiving reportmessages from one or more wireless devices. These report messages indicate an inter-dependency between at least two PDU sets, optionally contain results orconsequences in terms of QoS parameters measured for the combination of PDUsets, e.g. that were conducted by the wireless devices in the uplink towards the AN(e.g., the gNB). By processing this incoming information, the Report Reception Module 210 plays a critical role in ensuring that the AN can assess and respond to the inter-dependency and / or QoS situation observed at the wireless devices as well as the inter-dependency and QoS needs of the services used by the wireless devices.Complementing the Report Reception Module 210 is a Resource SchedulingModule 212. This module 212 takes into account the inter-dependency receivedfrom the one or more wireless devices and schedules resources accordingly for theat least two PDU sets. For example, it uses the report message to allocate the necessary uplink resources to meet or balance the QoS requirements for thedifferent PDU sets constituting one service. It may also be responsible formanaging any necessary adjustments or reconfigurations to the network's uplink scheduling strategies in order to optimize or balance performance and adhere to service level agreements. Any of the modules of the device 200 may be implemented by units configured to provide the corresponding functionality. The device 200 may also be referred to as, or may be embodied by, the AN or a network node of the AN (or briefly: gNB). The network node 200 and the wireless device may be in direct radio communication, e.g., at least for exchanging the report message from the wireless device to the network node 200. The wireless device may be embodied by the device 100.In 3GPP Release 18, the System Architecture and Services working group 2 (SA2)standardized 5G system support of Packet Data Unit (PDU) sets (e.g., as specified partly below). With the introduction of the PDU set, new requirements including PDU set Quality of Service Parameters and PDU set information were introduced to support PDU set handling, e.g. each of which three features are exemplified below. At the same time, the Radio Layer 2 and Radio Layer 3 RRC working group (RAN2) introduced UE features to support PDU set handling in the uplink. RAN2 agreed that a UE can identify PDU sets and related PDU set information for PDU set handling. In a further work item description (WID) for 3GPP Release 19, 3GPP has agreed to continue the study to better support, e.g., eXtended Reality (XR), uplink scheduling potentially introducing further PDU set features. Herein, a PDU set may comprise one or more PDUs carrying the payload of one unit of information generated at the application level, e.g. one or more frames or one or more video slices, etc., e.g. for eXtended Reality (XR) services. All the PDUs of a PDU set are transmitted within the same Quality of Service (QoS) flow. Any embodiment of any aspect may be implemented based on generalinformation provided by the 3GPP TS 23.501, version 18.4.0 or later.For example, PDU set QoS Parameters (as examples of the QoS parameter) are used to support PDU set based QoS handling in the Next Generation RNA (NG- RAN) or 5G System (5GS). At least one PDU set QoS Parameter shall be sent to the NG-RAN to enable PDU set based QoS handling. Any embodiment may use at least one of the following PDU set QoS parameters, e.g. as specified in any of the above-mentioned 3GPP documents: 1. PDU set Delay Budget (PSDB).2. PDU set Error Rate (PSER).3. PDU set Integrated Handling Information (PSIHI).A QoS profile may include the PDU set QoS Parameters described herein. The Policy Control Function (PCF) may determine the one or more PDU set QoS parameters based on information provided by an Application Function (AF) and / or a local configuration. The PDU set QoS parameters are sent to the Session Management Function (SMF) as part of a policy and charging control rule (PCC rule). The Session Management Function (SMF) sends them to the AN (e.g., a Next Generation Radio Access Network, NG-RAN) as part of the QoS profile. If the AN (e.g., NG-RAN) receives PDU set QoS parameters and supports them, it enables the PDU set based QoS handling and applies PDU set QoS Parameters as described herein. Any embodiment of any aspect may use the PDU set error rate as an example of the QoS parameter. The PDU set Error Rate (PSER) defines an upper bound for the rate of PDU sets that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. Packet Data Convergence Protocol (PDCP) in RAN of a 3GPP access). Thus, the PSER defines an upper bound for a rate of non-congestion related PDU set losses. The purpose of the PSER is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in RAN of a 3GPP access).It is noted that in any embodiment (e.g., in accordance with 3GPP Release 18), aPDU set may be considered as successfully delivered only when all PDUs of a PDU set are delivered successfully. Optionally, the PDU set may comprise at least two PDUs. It is further noted that how the AN (e.g., RAN) enforces PSER is up to RAN implementation. A QoS flow may be associated with only one PDU set error rate. PSER is an optional parameter. If the PSER is available, the PSER supersedes the PER. The value of the PDU set error rate is the same in UL and DL. Any embodiment of any aspect may use the PDU set delay budget as an example of the QoS parameter, e.g. including any one of the following features. The PDU set delay budget (PSDB) may define an upper bound for the delay that a PDU set may experience for the transfer between the UE 100 and the N6 termination point at the UPF (e.g., below reference sign 522), i.e. the duration between the reception time of the first PDU (at the N6 termination point for DL or the UE for UL) and the time when all PDUs of a PDU set have been successfully received (at the UE for DL or N6 termination point for UL). The (e.g., same) PSDB may apply to the DL PDU set received by the PDU Session Anchor (PSA) UPF over the N6 interface and / or to the UL PDU set sent by the UE 100. It is noted that to enable support for PSDB, it is required that a maximum inter arrival time between the first received PDU and the last received PDU of a PDU set complies with Service Level Agreement (SLA). This maximum inter arrival time does not exceed PSDB. NG-RAN behavior when the SLA is not fulfilled is out of scope of this specification. A QoS Flow is associated with only one PDU set delay budget. The value of the PDU set delay budget is the same in UL and DL. PSDB is an optional parameter that may be provided by the Policy Control Function (PCF). The provided PSDB can be used by the NG-RAN to support the configuration of scheduling and link layer functions. When the PSDB is available, the PSDB supersedes a packet delay budget (PDB) for the given QoS Flow. An AN PSDB (i.e., the PSDB of the access network, AN) may be derived at NG-RAN by subtracting a CN PDB (i.e. a packet delay budget or a PDU set delay budget of the core network, CN, e.g., as described herein or in clause 5.7.3.4 of afore- mentioned 3GPP document TS 23.501) from the PSDB. Any aspect of any embodiment may include PDU set based handling (or handling of the PDU set as a whole) as a QoS parameter of the PDU set or as a control item of the scheduling based on the report message. A PDU set may be comprised of one or more PDUs carrying an application layer payload such as, e.g. a video frame or video slice. The PDU set based QoS handling by the NG-RAN is determined by PDU set QoS Parameters in the QoS profile of the QoS Flow (specified in clause 5.7.7 of the afore-mentioned 3GPP document TS 23.501) and PDU set information provided by the PSA UPF via N3 / N9 interface (e.g., as described in clause 5.37.5.2 loc. cit.). The PDU set based QoS Handling can be applied for Guaranteed Bit Rate (GBR) and non-GBR QoS Flows. In addition to the PDU related service information, the AF may provide PDU set related assistance information for dynamic Policy and Charging Control (PCC) control. One or more of the following PDU set related assistance information may be provided to the NEF / PCF using the AF session with required QoS procedures (e.g., in clauses 4.15.6.6 and 4.15.6.6a of the 3GPP document TS 23.502, version 18.4.0): -PDU set QoS Parameters as described in clause 5.7.7 of 3GPP documentTS 23.502, version 18.4.0. -Protocol Description: Indicates transport protocol (e.g. RTP, SRTP),transport protocol header extensions (e.g. RTP Header Extension for PDU set marking as defined in 3GPP document TS 26.522, version 0.2.0), payload type and format (e.g. H.264, H.265), and format parameters (e.g. H.264 profile level and packetization mode) used by the service data flow. The PDU set QoS Parameters and / or Protocol Description may be provided by the CN, e.g. by the AF and / or may be used in determining PCC Rules by the PCF as defined in clause 6.1.3.27.4 of 3GPP document TS 23.503, version 18.4.0, and the Protocol Description may be used for identifying the PDU set information by the PSA UPF. When the SMF receives a PCC rule containing one or more PDU set QoS Parameters (PSER, PSDB and PSIHI), the SMF adds these PDU set QoS parameters to the QoS Profile of the QoS Flow as described in clause 6.2.2.4 of the 3GPP document TS 23.503. Alternatively, the SMF may be configured to support PDU set based QoS Handling without receiving PCC rules from a PCF. For the downlink direction, the PSA UPF identifies PDUs that belong to PDU sets and marks them accordingly as described in clause 5.37.5.2. If the UPF receives a PDU that does not belong to a PDU set based on Protocol Description for PDU set identification, then the UPF still maps it to a PDU set and determines the PDU set Information as described in said clause 5.37.5.2. It is noted that, if the PSA UPF receives a PDU that does not belong to a PDU set, then it is assumed that the UPF determines the PDU set importance value based on pre-configuration. Any embodiment of any aspect may use PDU set Information and / or Identification as an example of the QoS parameter, e.g. including any one of the following features. To support PDU set based QoS handling, the PSA UPF identifies PDUs that belong to PDU sets and determines the below PDU set information which it sends to the NG-RAN in the GPRS Tunneling Protocol (GTP-U) header. The PDU set information is used by the NG-RAN for PDU set based QoS handling as described above. The PDU set information comprises:- PDU set sequence number.- Indication of end PDU of the PDU set (i.e., the last PDU in the PDU set).- PDU sequence number within a PDU set.- PDU set size in bytes.- PDU set importance, which identifies the relative importance of a PDU setcompared to other PDU sets within a QoS Flow. The NG-RAN may use the Priority Level (e.g. according to clause 5.7.3.3 of said 3GPP document 23.501) across QoS Flows and PDU set importance within a QoS Flow for PDU set level packet discarding in presence of congestion. It is noted that in addition to considering the PDU set Importance within a QoS Flow, NG-RAN could also consider the relative PDU set Importance across QoS Flows of the same Priority Level when determining which PDU set needs to be discarded, which is up to implementation and configuration of operator. It is further noted that the PDU set Information can be different for different PDU sets within a QoS Flow. The PDU set may have XR traffic characteristics, e.g. as described below. XR applications typically generate traffic flows which are in principle periodic, e.g. video traffic with 30, 60, 90, or 120 fps. However, the traffic arrival moment at the RAN is affected by jitter around the periodicity value, due to processing of the frames at the application (e.g. for compression) and the capabilities of the platform used by the application, as well as transmission through the Core Network. This is modelled in 3GPP document TR 38.838, by assuming that each data frame arriving at the RAN has a random jitter of [-4; +4] ms (optionally [-5; +5] ms) around the main periodicity. The probability of the jitter value within this interval is given by a truncated Gaussian distribution with mean 0 ms and standard deviation 2 ms. XR traffic has strict delay requirements, in terms of packet delay budget (PDB). This is the maximum tolerable delay for a packet to be transmitted from a gNB to a UE. The PDB value depends on the XR traffic type and is overall between 5 ms and 30ms. The XR traffic may comprise the at least two PDU sets 750.Any embodiment of any aspect may relate to reporting QoS performance status information in the report message, e.g., dynamically, using control PDUs sent between RRC and / or SDAP and / or PDCP layers.Below reference to reference signs in figures after Fig. 4 serve for illustration anddo not limit the steps. Fig.3 shows an example flowchart for a method 300 of handling multiple PDU sets, e.g. by a device depicted in Fig.1. The method 300 may begin with an optional step 302 wherein the wireless device 100 transmits a capability message 502 to the access network 510. In the method 300, a wireless device 100 performs a series of steps to handle multiple PDU sets 750 within an access network 510. Initially, the wireless device 100 may send 302 a capability message 502 to the access network 510. This capability message 502 conveys information about the wireless device's 100 ability to process certain QoS parameters and to handle inter-dependencies 760 between the PDU sets 750. Subsequently, the wireless device 100 may optionally receive 304 a configuration message 504 from the access network 510, which provides guidance on how to obtain 306 inter-dependencies 760 among PDU sets 750 and potentially other parameters related to the handling of these PDU sets 750. Based on this configuration, the wireless device 100 obtains 306 the inter-dependency 760 between at least two PDU sets 750, which involves measuring certain QoS parameters pertinent to the multi-modal use case of the PDU sets 750. Optionally, the wireless device 100 may determine 308 whether the obtained inter-dependency 760 fulfills predefined criteria. This determination 308 could be based on thresholds or other conditions specified by the access network 510. Finally, the wireless device 100 sends 310 a report message 506 to the access network 510, indicating the results of the obtained inter-dependency 760 between the PDU sets 750. The report message 506 allows the access network 510 to make informed decisions regarding resource scheduling and prioritization based on the information provided by the wireless device 100. It should be noted that certain steps in the method 300 are optional, as indicated by the dotted boxes. These optional steps may include additional parameters or considerations that enhance the wireless device's 100 ability to accurately report the inter-dependency 760 of PDU sets 750 to the access network 510. The device 100 may comprise modules 1XY for performing the steps 3XY. Figure 4 illustrates the steps of a method 400 according to a second aspect for handling multiple PDU sets by a device, e.g., the device 200. The method 400 encompasses scheduling resources 412 for a wireless device 100 based on a report message 506 received from the wireless device 100. The report message 506 is indicative of an inter-dependency between at least two PDU sets 750. This inter- dependency may be identified either in an uplink towards an access network 510 or in a downlink from the access network 510. Optionally, the network node 200 initiates the method 400 by receiving 402 a capability message from the wireless device 100. The capability message 502 may be indicative of various capabilities of the wireless device 100, such as its ability to measure QoS parameters across PDU sets 750, obtain inter-dependencies 760, report results to the access network 510, and possible features and physical layer information specific to the wireless device 100. Subsequently, the network node 200 may optionally send 404 a configuration message to the wireless device 100. This configuration message 504 can include a range of configuration directives, including but not limited to QoS parameters to be measured, predefined criteria or thresholds, QoS flows 724 or identifiers, DRB indexes, potential mappings between PDU sets 750 and DRBs 714, and possibly certain QoS flow identifiers (QFIs). It may also specify modes for obtaining inter- dependency 760 and for reporting, as well as define obtainment windows, periodicities, and deadlines for sending report messages 506.The received 410 report message 506 enables the network node 200 tounderstand the inter-dependencies 760 between PDU sets 750 as experienced by the wireless device 100. Based on this understanding, the network node 200 schedules resources 412 appropriately. The scheduling of resources 412 by the network node 200 may include a range of actions such as reconfigurations to align with QoS requirements, handling dynamic traffic patterns, or sending feedback to the core network 520 regarding QoS performance. Optionally, the network node 200 can adapt QoS flows 724 or QFIs associated with the PDU sets 750 based on the report message 506, potentially aiming for mapping different QFIs to a single DRB 714. This scheduling step 412 allows for an optimized management of uplink or downlink resource allocation in response to changing traffic demands, keeping in line with the predefined QoS criteria and enhancing overall network performance. The device 200 may comprise modules 2XY for performing the steps 4XY. Hereinbelow, the wireless device 100 is described with reference to an exemplary UE 100 and the network node 200 is described with reference to an exemplary gNB 200 in a 5G setting for illustration. The skilled person will appreciate that this illustration is not limiting, and that the corresponding features and steps can be implemented beyond 5G and / or for an optical data link. Fig.5 schematically illustrates a first example of an access network comprising first embodiments of the devices 100 and 200 for performing corresponding first embodiments of the methods 300 and 400, respectively. Fig.5 depicts a schematic illustration of an example of a telecommunication network 500, emphasizing how it integrates devices for handling Packet Data Unit (PDU) sets. The example features two wireless devices, labeled generically as UE 100, each situated within distinct cells or beams 201 of network nodes, labeled as gNB 200. Each UE 100 operates within the scope of a gNB 200, representing its connection to the broader access network (AN) 510. The illustration captures a moment of communication wherein each UE 100 sends a report message 506 to its respectively serving gNB 200. This exchange of the report message is denoted by directed arrows, symbolizing the sending 310 and receiving 410 of control signaling. The report messages 506 result from the internal processes 300 of the UEs 100 concerning PDU sets, which are transmitted in the uplink, e.g. direction toward the gNB 200. At the network's periphery, the illustration shows a core network (CN) 520, interfaced with the AN 510. While not directly involved with the immediate interactions 310 and 410 between UEs 100 and gNBs 200, the CN 520 may serve as the backbone, interfacing with external networks or services and relaying information into and out of the AN 510. For example, the CN 520 or an applicationserver may signal QoS requirements and / or inter-dependencies of the PDU sets tothe AN 510, while the report message 506 provides the actual observations and / or measurement values of the inter-dependencies and / or QoS parameters at the UE 100. Fig.5 accentuates how individual components within a telecommunicationnetwork — e.g., UEs 100, gNBs 200, and the core network 520 — collaborate tomanage and convey QoS-related information pertaining to PDU sets in a wireless communication environment. Fig.6 schematically illustrates an existing downlink network architecture, which may be combined with an uplink network architecture according to any of the embodiments of the devices 100 and 200 and the methods 300 and 400. Fig.6 presents a schematic overview of an example of the downlink network architecture. The devices 100 and 200 may inherit any feature of the devices 10 and 20, respectively. The UE 10 interfaces with the gNB 20, which serves as a connection point within the access network to manage PDU sessions and QoS flows. A feature of the architecture is the delineation of a PDU session, which encompasses the entirety of the QoS flow and interfaces with an N3 Tunnel connecting to a UPF. The UPF, in turn, provides connectivity to an Application Server (AS) within a Data Network (DN), establishing a comprehensive channel from the user applications to the network infrastructure. Within the UE 10 and the gNB 20, data radio bearers (DRBs) play a crucial role in handling QoS flows, which are mapped to the DRBs. This mapping ensures that the appropriate level of quality is attributed to different types of traffic, as defined by the QoS flow. QoS flows fall into two main categories: those with Guaranteed Bit Rate (e.g., here QFI=4 or QFI=3) and those without (e.g., here Non-GBR, QFI=6), reflecting the diversity of service requirements within the network. The Data Network addresses the service routing by imposing QoS policies for Service Data Flows (SDF), such as SDF1, SDF2, SDF3, and SDF4, each corresponding to specific IP flow characteristics such as flow 1, flow 2, flow 3, flow 4, and flow 5, which are ultimately realized in the user applications. An essential aspect of this communication system 50 is the implementation of QFI Insertion at various stages of the PDU session to precisely steer the data packets according to their predetermined QoS requirements. This fine-grained control, supported by additional network protocols like the Internet Protocol (IP), solidifies the QoS enforcement mechanisms integral to the network performance and the user experience. Concurrently, the option of TFT / SPDF Template filtering at a Data Network (DN), user plane function (UPF), and application server (AS) junction provides a supplementary means to refine and optimize traffic flow management based on complex rules and conditions that govern the passage of data packets through the network. Any concept illustrated or described by Fig.6 for the ability of the network 50 to deliver differential QoS levels in the DL may be applied to the subject technique in the UL and / or controlled by the report message, e.g., ensuring that the diverse service requirements of modern telecommunication networks are met with precision and efficiency in both UL and DL. For example, conventional reflective QoS is an optional feature for the UE 10 that allows the UE 10 to deduce the uplink (UL) mapping between QoS flows and radio bearers from the downlink (DL) mapping, e.g., if QoS Flow Identifier (QFI) X is mapped to DRB Y in the DL, then it is the same in UL. Fig.7A schematically illustrates a second example of an access network (AN) 510 (e.g. a downlink network architecture of the AN 510) comprising second embodiments of the devices 100 and 200 for performing the methods 300 and 400, respectively. Herein, while the first, second, etc. embodiments may be realized independently, the embodiments are combined in a variant of such embodiments. For example, any equal reference signs may relate to identical, equivalent or inter-changeable features and steps.Fig. 7A schematically illustrates an example of an access network (AN) 510 and adownlink network architecture encompassing second embodiments of devices for handling a PDU set 750. In this architecture, the wireless device 100 is capable of handling PDU sets such as those in an uplink towards the AN 510, e.g. a network node 200, which can be a components of broader telecommunication systems that manage various data flows and network efficiencies. The architecture also includes the network node 200 (e.g., a gNB) designed to handle the PDU sets within the access network 510. This network node may manage and / or optimize the flow of PDUs, especially the PDU sets 750, between the wireless device 100 and the core network (CN) 520. The CN 520 is a part of the telecommunication network 500 that provides a multitude of services and connectivity to other networks or services, interfacing with the access network 510 and transmitting data to and from an application server (AS) located in or beyond a data network DN (e.g., the Internet). Central to the efficiency of the system 500, the wireless device 100 employs an Obtainment Module 106 and a Report Transmission Module 110 for the uplink PDU set 750. The PDCP layer 710 of the wireless device 100 is responsible for key functions like header compression, encryption, and ensuring data integrity. As part of the wireless device's features, Radio Bearers 714 facilitate the transfer of data radio bearers from applications within the wireless device 100. The network node 200 leverages a Report Reception Module 210 to handle incoming reports and a PDU Resource Scheduling Module 212 to manageresources optimally for the at least two PDU sets. It utilizes PDCP 710 and / or SDAP720 layers for protocol functionality, which handle tasks such as mapping QoS flows to DRBs and marking QoS flow IDs in data packets, e.g. based on the report message 506. Integral to network operations, the QoS flows 724 are associated with specific quality of service metrics, such as guaranteed bit rates, delays, and priority levels. These flows are critical for ensuring that the network can meet various service level agreements and user expectations for data transmission quality. The PDU set 750 is the focal point of these interactions, being the collection of PDUs that are transmitted as a unit of data at the application level. The entire set of PDUs is transmitted within the same QoS flow 724, ensuring consistent handling across the network. For example, at the network node 200, a mapping function or PDU session 702 works in conjunction with an N3 Tunnel 704 to at least one of these layers 710 and / or 720 to the CN 520. This tunneling facility is a critical part of ensuring secure and reliable data transfer from the AN 510 (e.g., a Radio AN, i.e. RAN) to the CN 520 part of the telecommunication system 500. The interaction between the wireless device 100 and the network node 200 is signified by the exchange of report messages 506, which are crucial for conveying information about the performance and requirements of the PDU set 750. These report messages 506 can be indicators of QoS parameters such as PDU set error rate, delay budget, and / or importance for each respective device's scheduling and handling of data flows. Any feature, e.g. for the network node reaction in the step 412, may be based on or extend, any 3GPP features (e.g., as discussed herein) and / or may involve alternative or additional configurations, features, or communication protocols that can be implemented to enhance or modify the standard data handling procedures of the PDU set 750 in the wireless device 100 and / or the network node 200 within the access network 510. Optionally, the UE 100 may decide the mapping between QoS flows and radio bearers in the UL. The gNB 200 may reflect that mapping in the UL. The report message may comprise instructions to overrule the reflective mapping. Alternatively or in addition, the gNB 200 may change the In a variant of any embodiment, the report message may trigger or change in the PDCP and / or SDAP layer (e.g., by using an PDCP or SDAP control PDU as the report message) the mapping between QFI and DRB. Alternatively or in addition, the PDCP or SDAP may signal to lower layers of the radio protocol stack (e.g., the medium access control layer, MAC layer, or the physical layer, PHY layer) for performing scheduling Another advantage of using SDAP or PDCP control PDUs for the report message is that these PDUs are carried over the same DRB as the user data. This means they receive the same priority as the user data (e.g., the PDUs of the PDU set). In a variant of any embodiment, the report message may be sent using assistance information, e.g. to have the report reach the layer that is most relevant for the mapping or scheduling. When sending the report message using the UE Assistance Information (UAI) message it will be a part of radio resource control (RRC) signaling, which require additional overhead and potential service interruption as it has the highest transmission priority in the UE, which can be avoided using the PDCP and / or the SDAP layer for sending the report message. How the gNB 200 responds in the step 410 to the report message received in the step 406 may up to gNB implementation. For example, the SDAP or PDCP layer in the gNB 200 may simply receive 406 the report message and forward it to the corresponding implemented function, e.g. that does the bookkeeping of the QoS for each UE 100 in the gNB 200. The reported message may be indicative a result of the measurement or a value QoS parameter for the PDU set that triggers a control reaction, e.g. by activating feature X in layer Y or reconfigure DRB mapping. Any one or more steps of the method 300 and / or 400 may be implemented at or using a Service Data Adaptation Protocol (SDAP), e.g. as described below. The objective is to describe the SDAP architecture and the SDAP entity from a functional point of view. The specified functionality only applies to UE 100 with connection to the 5G-CN 520 and UE 100 in NR sidelink (SL) communication. Any embodiment of any aspect may implement at least one of the following features of a structure of the SDAP layer 720. Fig.7B schematically illustrates the second example from an aggregated point of view of the multi-modal data implemented by the at least two PDU sets. Fig.7C schematically illustrates an example of a dual connectivity of the wireless device, which may carry the at least two PDUs and / or which may be set up or changed responsive to the report message according to an embodiment of the method 400.Fig. 8 schematically illustrates a UE state machine and state transitions in NR,which may be used in any embodiment of the device 100. The Radio Resource Control (RRC) protocol specification is detailed in 3GPP TS 38.331. This specification provides RRC procedures, functions, messages, encodings of message, error handling etc. On a high level the RRC protocol is a UE state machine that is configured and controlled by gNB, to control the activation of features and configurations of lower layer protocols in the UE.A UE 100 is either in RRC_CONNECTED state or in RRC_INACTIVE state when anRRC connection has been established. If this is not the case, i.e. no RRC connection is established, the UE is in RRC_IDLE state. The RRC states can further becharacterized as follows:RRC_IDLE: -A UE specific DRX may be configured by upper layers;- UE controlled mobility based on network configuration;- The UE:- Monitors Short Messages transmitted with P-RNTI over DCI (see clause6.5); -Monitors a Paging channel for CN paging using 5G-S-TMSI;- Performs neighbouring cell measurements and cell (re-)selection;- Acquires system information and can send SI request (if configured).RRC_INACTIVE: -A UE specific DRX may be configured by upper layers or by RRC layer;- UE controlled mobility based on network configuration;- The UE stores the UE Inactive AS context;- A RAN-based notification area is configured by RRC layer;- The UE:- Monitors Short Messages transmitted with P-RNTI over DCI (see clause6.5); -Monitors a Paging channel for CN paging using 5G-S-TMSI and RANpaging using P-RNTI; -Performs neighbouring cell measurements and cell (re-)selection;- Performs RAN-based notification area updates periodically and whenmoving outside the configured RAN-based notification area; -Acquires system information and can send SI request (if configured).RRC_CONNECTED: -The UE stores the AS context;- Transfer of unicast data to / from UE;- At lower layers, the UE may be configured with a UE specific DRX;- For UEs supporting CA, use of one or more SCells, aggregated with theSpCell, for increased bandwidth; -For UEs supporting DC, use of one SCG, aggregated with the MCG, forincreased bandwidth; -Network controlled mobility within NR and to / from E-UTRA;- The UE:- Monitors Short Messages transmitted with P-RNTI over DCI (see clause6.5), if configured; -Monitors control channels associated with the shared data channel todetermine if data is scheduled for it;- Provides channel quality and feedback information;- Performs neighboring cell measurements and measurement reporting;- Acquires system information.The UE Assistance Information (UAI) is an RRC message that may be sent any time after the RRC reconfiguration procedure.Fig. 9 shows a signaling diagram, which may be used for implementing theexchange of any one of the messages disclosed herein, optionally as indicated bythe reference signs in Fig. 9. Alternatively or in addition, the report message 506may be sent 3010 using UE Assistance Information (UAI).The purpose of this (UAI) procedure is to inform the network of the UE's delay budget report carrying desired increment / decrement in the connected mode DRX cycle length, or overheating assistance information. A UE 100 capable of providing delay budget report in RRC_CONNECTED may initiate the procedure in several cases, including upon being configured to provide delay budget report and upon change of delay budget preference. A UE capable of providing overheating assistance information in RRC_CONNECTED may initiate the procedure if it was configured to do so, upon detecting internal overheating, or upon detecting that it is no longer experiencing an overheating condition. Note: upon reception of UAI, it is optional for gNB to use the provided assistance information. The UEAssistanceInformation message is used for the indication of UE assistance information to the network.Signaling radio bearer: SRB1RLC-SAP: AM Logical channel: DCCHDirection: UE 100 to Network (e.g., AN 510, particularly network node 200)The following UAI message may be used or modified as the report message 506. UEAssistanceInformation message-- ASN1START-- TAG-UEASSISTANCEINFORMATION-STARTUEAssistanceInformation ::= SEQUENCE { criticalExtensions CHOICE { ueAssistanceInformation UEAssistanceInformation-IEs, criticalExtensionsFuture SEQUENCE {} } } UEAssistanceInformation-IEs ::= SEQUENCE { delayBudgetReport DelayBudgetReport OPTIONAL,lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension UEAssistanceInformation-v1540-IEs OPTIONAL } DelayBudgetReport::= CHOICE { type1 ENUMERATED { msMinus1280, msMinus640, msMinus320, msMinus160,msMinus80, msMinus60, msMinus40, msMinus20, ms0, ms20,ms40, ms60, ms80, ms160, ms320, ms640, ms1280}, ... } UEAssistanceInformation-v1540-IEs ::= SEQUENCE { overheatingAssistance OverheatingAssistance OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL } OverheatingAssistance ::= SEQUENCE { reducedMaxCCs SEQUENCE {reducedCCsDL INTEGER (0..31), reducedCCsUL INTEGER (0..31) } OPTIONAL, reducedMaxBW-FR1 SEQUENCE { reducedBW-FR1-DL ReducedAggregatedBandwidth, reducedBW-FR1-UL ReducedAggregatedBandwidth } OPTIONAL, reducedMaxBW-FR2 SEQUENCE { reducedBW-FR2-DL ReducedAggregatedBandwidth, reducedBW-FR2-UL ReducedAggregatedBandwidth} OPTIONAL, reducedMaxMIMO-LayersFR1 SEQUENCE { reducedMIMO-LayersFR1-DL MIMO-LayersDL, reducedMIMO-LayersFR1-UL MIMO-LayersUL }OPTIONAL,reducedMaxMIMO-LayersFR2 SEQUENCE { reducedMIMO-LayersFR2-DL MIMO-LayersDL, reducedMIMO-LayersFR2-UL MIMO-LayersUL } OPTIONAL } ReducedAggregatedBandwidth ::= ENUMERATED {mhz0, mhz10, mhz20, mhz30, mhz40, mhz50, mhz60, mhz80, mhz100, mhz200, mhz300, mhz400} -- TAG-UEASSISTANCEINFORMATION-STOP-- ASN1STOPAny embodiment of any aspect may use the Service Data Adaptation Protocol (SDAP). The objective is to describe the SDAP architecture and the SDAP entity from a functional point of view. The specified functionality only applies to UE with connection to the 5G-CN and UE in NR sidelink communication. Fig.10 schematically illustrates one possible structure for the SDAP sublayer 720. It should not restrict an implementation of the SDAP sublayer 720. Alternatively or in addition, the SDAP sublayer may be implemented according to the radio interface protocol architecture defined in 3GPP document TS 38.300, version 18.0.0, e.g. Figure 4.2.1-1 therein, which provides an SDAP sublayer structure view. The SDAP sublayer may be configured for DRBs by RRC, e.g. according to 3GPP document TS 38.331, version 18.0.0. The SDAP sublayer 720 maps QoS flows to DRBs. One or more QoS flows may be mapped onto one DRB. One QoS flow is mapped onto only one DRB at a time in the UL. The SDAP sublayer may be configured for Multicast / Broadcast Service (MBS) Radio Bearers (MRBs) by RRC, e.g. according to 3GPP document TS 38.331, version 18.0.0. The SDAP sublayer maps MBS QoS flows to MRBs. One or more MBS QoS flows may be mapped onto one MRB. In NR sidelink communication, the SDAP sublayer maps PC5 QoS flows to SL-DRBs. One or more PC5 QoS flows may be mapped onto one SL-DRB. One PC5 QoS flow is mapped onto only one SL-DRB at a time in the NR sidelink for transmission. Any embodiment of any aspect may implement at least one of the following features of SDAP entities 722. The SDAP entities 722 are located in the SDAP sublayer 720 (also: layer). Several SDAP entities 722 may be defined for a UE 100. There is an SDAP entity 722 configured for each individual PDU session or MBS session for NR Uu. For NR sidelink, an SDAP entity 722 may be configured per Destination Layer-2 ID and cast type in the UE 100. An SDAP entity 722 receives and / or delivers SDAP service data units (SDUs) from and / or to upper layers and / or submits and / or receives SDAP data packet data units (PDUs) to and / or from its peer SDAP entity 722 via lower layers. At the transmitting side, when an SDAP entity 722 receives an SDAP SDU from upper layers, it constructs the corresponding SDAP data PDU and submits it to lower layers. At the receiving side, when an SDAP entity 722 receives an SDAP data PDU from lower layers, it retrieves the corresponding SDAP SDU and delivers it to upper layers. The function of an SDAP entity 722 for the SDAP sublayer 720 may beimplemented according to the functional view of Fig. 11 and / or the SDAP layerfunctional view of Figure 4.2.2-1 in 3GPP document TS 38.300, version 18.0.0. These example should not restrict an implementation of the SDAP sublayer 720. The figure is based on the radio interface protocol architecture defined in 3GPP document TS 38.300, version 18.0.0. Reflective QoS flow to DRB mapping may be performed at the UE 100, e.g. as specified in the clause 5.3.2, if DL SDAP header is configured. Typically, reflective mapping of a QoS flow to an MRB (i.e., Multicast / Broadcast Service Radio Bearer) is not supported. E.g., there may be no SDAP header for MRB. Alternatively or in addition, reflective PC5 QoS flow to SL-DRB mapping is not supported for NR sidelink (SL) communication. Any embodiment of any aspect may implement at least one of the following features and steps of services provided to upper layers. The SDAP sublayer 720 provides its service to the user plane upper layers. An example service provided by the SDAP sublayer 720 to upper layers is transfer of user plane data. Any embodiment of any aspect may implement at least one of the following features and steps of services expected from lower layers. An SDAP entity 722 may expect from lower layers at least one of the following services: -user plane data transfer service;- in-order delivery except when out of order delivery is configured by RRC(e.g., according to 3GPP document TS 38.331, version 18.0.0). Any embodiment of any aspect may implement at least one of the following functional features of the SDAP sublayer: -transfer of user plane data;- mapping between a QoS flow and a DRB for both DL and UL;- mapping between an MBS QoS flow and an MRB for DL;- mapping between a PC5 QoS flow and a SL-DRB for NR sidelinkcommunication; -marking QoS flow ID in both DL and UL packets;- marking PC5 QoS flow ID in unicast of NR sidelink communication packets;and -reflective QoS flow to DRB mapping for the UL SDAP data PDUs.Alternatively or in addition, any step of the methods 300 and / or 400 may be implemented at or using a Packet Data Convergence Protocol (PDCP) layer 710. The PDCP layer 710 may support at least one of the following functions: -transfer of data (user plane or control plane);- maintenance of PDCP SNs;- header compression and decompression using the ROHC protocol;- header compression and decompression using the EHC protocol;- uplink data compression and decompression using the UDC protocol;- ciphering and deciphering;- integrity protection and integrity verification;- timer based SDU discard;- for split bearers and DAPS bearer, routing;- duplication;- reordering and in-order delivery;- out-of-order delivery;- duplicate discarding.Fig. 12 provides a functional view of the PDCP layer 710.The gNB 200 may comprise dedicated logic in the PDCP layer to respond to the QoS report message, e.g. trigger discarding of more or less packets in the PDCP layer 710, as an example of the step 410. The PDCP entities are located in the PDCP sublayer. Several PDCP entities may be defined for a UE. Each PDCP entity is carrying the data of one radio bearer. A PDCP entity is associated either to the control plane or the user plane depending on which radio bearer it is carrying data for.Fig. 13 provides a schematic structural view of the PDCP layer 710.The PDCP entity 712 receiving 410 the report message may control the RLC (or further lower layers) for the changing the scheduling of radio resources, e.g. by scheduling less resources when there is a predefined margin between the measure QoS parameters for the PDU set and the QoS requirements, or by scheduling more resources when the margin falls below a predefined threshold or if the QoS requirement is not fulfilled. The following detailed embodiments may be implemented as describe below or in combination with any of the above embodiments and / or any of the embodiments in the list of embodiments. For brevity, the AN 510 may be referred to as the network. The network 510 (e.g., the gNB 200) provides a configuration (e.g., in the steps 304 and 404) for the UE 100 to measure generic QoS related information (i.e., the QoS parameters), e.g. PSDB, PSER, minimum and / or maximum and / or average PDU set queued time, or PDU set dropping ratio. The configuration may be compound of one or more of the following elements: measured parameter, one or more thresholds for the said parameter, measurement window, measurement periodicity, QFI, DRB. If the network provides the QFI or DRB, it limits the measurements to the PDU sets matching the QFI and / or DRB. The UE 100 reporting in the steps 310 and 410 may be event-based, e.g. when the measured value is above or below the configured threshold, periodic-based e.g. measured value is reported periodically, or on-request e.g. the network requests the UE to report the last measured value or to start a measurement and report it to the network. When more than one option is available, the network may be able to configure the one or more reporting methods the UE 100 should follow. When the UE 100 is configured with multiple parameters to measure and / or multiple QFIs, DRBs, or PSIs are indicated, the following reporting options are possible: A first option includes an event trigger: the report message 506 only contains the measured value which triggered the report in the corresponding DRB, QFI, and / or PSI. The report message 506 may then indicate to which DRB, QFI, and / or PSI corresponds (e.g., fails to meet a predefined criterium). Alternatively, the UE 100 reports 310 the measured value which triggers the report message 506 and the value of the parameter for other DRBs, QFIs, and / or PSIs. Alternatively, the UE 100 may report all measured values for the configured DRBs, QFIs, and / or PSIs. A second option includes a periodic trigger: the UE 100 may report all measured values for the configured QoS parameters, e.g. DRBs, QFIs, and / or PSIs. A third option includes an on-demand reporting: the UE 100 reports 310 the measurements 306 of the one or more requested QoS parameters. The report message 506 may include values for the DRBs, QFIs, and / or PSIs provided in the configuration or in the "on-demand" measurement request sent by the network to the UE 100. If the SDAP or PDCP is used to provide the report, the UE reports the measured parameter value e.g. UL PSER status inside a SDAP / PDCP control PDU. Report may carry measured results for one or multiple QoS flows (QFIs) and / or DRBs and / or PSI levels. Measured results could also be carried in a PDCP Control PDU. In a related embodiment, the UE 100 is configured through RRC to either report periodically with time interval X or a-periodically. In the a-periodical case the PDCP or SDAP layer triggers a UL PSER report when requested by gNB through a SDAP or PDCP control PDU. Additionally, the UE can be configured to either continuously measure the UL PSER status or only start the measurement upon request from an SDAP or PDCP control PDU. Assuming the UE 100 is capable of providing reports through SDAP or PDCP, the gNB may be unaware of this capability. Thus the UE may trigger the sending of a control PDU indicating to gNB that it supports a status report from respective layer. In a different scenario the gNB may probe the UE for this capability. In this case it is the gNB that sends a control PDU to the UE for which the UE may respond with its own control PDU indicating its support or not. In case it does not support status reporting, the UE can also ignore this control PDU. This mechanism will also enable the UE to update its capability dynamically, in case the traffic pattern and / or requirements of the service has changed. Fig.14 schematically illustrates different hierarchical levels of PDU aggregation, which distinguish between PDUs in one PDU set of related data type and different PDU sets that are inter-dependent due to a multi-modal operation. The at least two PDU sets may be inter-dependent because of multi-modality, e.g. because of a multi-modal service as described below. Multi-modality services refer to applications that generates multiple traffic flows on a network. In one non limiting example an XR service may consists of multiple different flows constituting different modalities e.g. a video flow, an audio flow, apose flow or a haptic flow. For an acceptable end user experience, it is of greatimportance that the flows / modalities are synchronized and consumed at right moment by the application. For example, it is typically desirable that video and audio are synchronized during video conferencing. In another example state of the art haptics e.g. haptic gloves or body suit require close synchronization with both audio and video.Fig. 15 schematically illustrates services 1 to 3 causing inter-dependenciesbetween PDU sets used for the multi-modal (e.g., interactive system) input and outputs. The tactile and multi-modal communication service can be applied in multiple fields, e.g. industry, robotics and telepresence, virtual reality, augmented reality, healthcare, road traffic, serious gaming, education, culture and smart grid. These services support applications enabling input from more than one sources and / or output to more than one destination to convey information more effectively. AsFig. 15 illustrates, the input and output can be different modalities including:- Video / Audio media;- Information received by sensors about the environment, e.g. brightness,temperature, humidity, etc.;- Haptic data: can be feelings when touching a surface (e.g., pressure,texture, vibration, temperature), or kinaesthetic senses (e.g. gravity, pull forces, sense of position awareness). For immersive multi-modal VR applications, synchronization between different media components is critical in order to avoid having a negative impact on the user experience (i.e. viewers detecting lack of synchronization), particularly when the synchronization threshold between two or more modalities is less than the latencykey performance indicators (KPI) for the application (e.g., a service). Examplesynchronization thresholds are summarized in below Table.Table: Typical synchronization thresholds for immersive multi-modality VR applications Media components synchronization threshold (note 1)audio-tactile audio delay:tactile delay: 50 ms 25 ms visual-tactile visual delay:tactile delay: 15 ms 50 ms NOTE 1: for each media component, “delay” refers to the case where that media component is delayed compared to the other. Any embodiment may be implemented to achieve the following requirements. The 5G system shall enable an authorized 3rd party to provide one or morepolicies for flows associated with an application. The policy may contain e.g. theset of UEs and data flows, the expected QoS handling and associated triggering events, other coordination information. The 5G system shall support a means to apply 3rd party provided policy(ies) for flows associated with an application. The policy may contain e.g. the set of UEs and data flows, the expected QoS handling and associated triggering events, other coordination information.NOTE: The policy can be used by a 3rd party application for coordination of thetransmission of multiple UEs’ flows (e.g., haptic, audio and video) of a multi-modal communication session. Any embodiment may be implemented to comply with a new work item description (WID) for 3GPP Release 19, which agreed to the following objective for XR enhancements: “Study and if justified, specify aspects related to multi-modality (intra-UE) (with coordination with SA2 / SA4 as needed by LS request). Aim to facilitate efficient and effective support for XR application with Multiple QoS flows with multi-modal inter-dependencies, meeting multi-modal QoS requirements, e.g. synchronization and / or coordination. Efficiency enhancements are expected to be visible in terms of capacity or power consumption. [RAN2].“ The report message may enable the UE 100 to report inter-dependencyinformation between multi-modal flows (i.e., corresponding PDU sets), e.g.through RRC and / or MAC signaling. The following detailed embodiments may be implemented as described or in combination with any of the above-mentioned embodiments or the embodiments in the list of embodiments.A UE 100 may report in the step 310, e.g. using UAI, a recommendation in thereport message 506 to the network that the current QFI-DRB mapping is insufficient i.e., that a new DRB could be established or that existing QFI-DRBmapping needs modification. The UE 100 may report in UAI that a group of QoSFlow Identifiers (QFI) X,Y,Z should be mapped to one or more DRB, and the suggested corresponding mapping between QFIs and DRBs. In another example the UE reports that a single QFI X should be mapped to single DRB A or the set ofsuitable DRBs. The report message 506 may also include QFI-to-DRB mapping alsoincludes a PDU Session ID of which the one or more QFIs are associated with. Besides of the QFI-DRB recommendation outlined above, the UE could also add to the Flow Type being the flow type information about the service type of flow e.g. audio, video, pose, etc. When receiving a status report the gNB may accept or decline the UE recommendation, or provide a new configuration by generating a new control PDU. Such control PDU may be sent and received from either SDAP, PDCP, RLC or MAC layer. Additionally the UE 100 may also indicate in the report message 506 through aSDAP and / or PDCP and / or RLC and / or MAC control PDU that the UE 100 wants torequest a new DRB to be established for a particular PDU Session ID and selected QFIs. A gNB 200 may respond by either sending an RRCreconfiguration or a using a SDAP and / or PDCP and / or RLC and / or MAC control PDU to either accept or decline the request. In another embodiment, instead of the explicit recommendation of the mapping, a UE 100 only reports in the report message 506 the generic inter-dependency of multiple DRBs (e.g., corresponding to the at least two PDU sets) for the same service. The inter-dependency will be a set of indexes of DRBs that are associated for the same service if a DBR is already configured. This information (i.e., the report message 506) can be signaled 310 by UAI since a connection was established already. Alternatively or in addition, when the report message 506 from the UE 100 includes the inter-dependency information, it may also include associated service identify information so that a network 510 or the network node 200 is enabled to determine in the step 412 which one or more DRBs 714 are related with which one or more services.The UE 100 can also report application flow information (in the report message506 or a further report message 506) that are inter-dependent, e.g., that enableidentifying PDU sets that are inter-dependent. One example is that a UE 100reports port numbers or IP addresses, which are marked with same serviceidentity, e.g. which are the same for all packets from the indicated port numbersof IP addresses. This information can be signaled as RRC messages 506 before DRB configuration.The gNB 200 and / or RAN 510 may also provide a configuration 504 for the UE 100to trigger a report of the information outlined above. Such configuration 504 mayinclude rules for measurements in the step 306, thresholds and timers. When ameasurement configured by the network 510 trespasses the configured threshold, the UE 100 may send a report 506 including the QFI-DRB recommendation and the measured results for the parameter which triggered the report, or it may include all measured results for all configured measurements. Further, the UE 100 may report the measurement results for other current QFI-DRB pairs if they are available. Additionally, after a report has been sent the network can configure a prohibition timer that restrict an additional report for as long as the timer is running. In another embodiment, a UE 100 may trigger a report 506 of all above "multi-modality" information when any of existing application flow is terminated or newapplication flow starts, e.g. which may require any update of a DRB configuration(e.g., at the network node 200). It is also possible that a network 510 or network node 200 initiates the UE report 506 by sending a multi-modality information report request. The technique may be applied to uplink (UL), downlink (DL) or direct communications between radio devices, e.g., device-to-device (D2D) communications or sidelink (SL) communications. Each of the transmitting station 100 and receiving station 200 may be a radiodevice or a base station. Herein, any radio device may be a mobile or portablestation and / or any radio device wirelessly connectable to a base station or RAN, orto another radio device. For example, the radio device may be a user equipment(UE), a device for machine-type communication (MTC) or a device for (e.g., narrowband) Internet of Things (IoT). Two or more radio devices may beconfigured to wirelessly connect to each other, e.g., in an ad hoc radio network orvia a 3GPP SL connection. Furthermore, any base station may be a stationproviding radio access, may be part of a radio access network (RAN) and / or may bea node connected to the RAN for controlling the radio access. For example, thebase station may be an access point, for example a Wi-Fi access point. Fig.16 schematically illustrates a signaling diagram resulting from devices 100 and 200 performing the methods 300 and 400 according to a seventh embodiment. The signaling diagram illustrates the interplay between various components during the execution of a method for handling a Packet Data Unit (PDU) set within a telecommunications network. The signaling diagram illustrates the interaction between a wireless device 100 and a network node 200 of an access network AN, along with the core network 520. The process initiates with the wireless device 100 transmitting a capability message 502 to the network node 200 in the step 302 or 402, which indicates the capabilities of the wireless device 100 in obtaining 306 (e.g., measuring) and reporting 310 inter-dependencies (and optionally QoS parameters) for the at least two PDU sets (e.g., in the uplink direction toward the AN 510), e.g., to its serving network node 200 (illustrated as a gNB). Optionally, the network node 200 may configure the wireless device 100 by sending a configuration message 504, which provides specific instructions for QoS measurements of the PDU set, according to the step 404 or 304. The wireless device 100 then proceeds to obtain 306 (e.g., measure) the inter-dependencies at various intervals denoted as a loop and optionally assess the reporting criteria the step 308. Following the obtaining (e.g., measurements), the wireless device 100 reports 310 the result of the obtaining 306 (e.g., measurement) and / or the assessment 308, e.g. according to at least one of the alternatives (labeled "alt") in the box. For example, the wireless device 100 evaluates whether the measured PDU set matches preset criteria, potentially triggering a report. If the determination 308 results in the need to report, the wireless device 100 sends 310 a report message 506 back to the network node 200. The report message 506 may be event-based, periodic, or on-demand, as indicated by the multiple exit points from the sending 310 to the network node 200. The network node 200 is poised to respond by either waiting 410 for periodical QoS measurement reports from the wireless device or by sending a request for QoS measurement to the wireless device, depicted by the vertical flow of communication from and to the network node 200 (e.g., gNB). As the network node 200 receives the report message 506 indicative of the QoS measurement results, it takes suitable action by updating its configuration, scheduling, or general resource allocation for the wireless device 100, e.g., to align DRB and / or the QoS for the at least two PDU sets according to the step 412. Optionally, the measurements 306 at the UE 100 for the entire PDU set may (e.g., partly) be based on lower layer measurements involving indirect QoS parameters such as noise or a signal-to-noise ratio (SNR), or interference or a signal-to- interference-and-noise ratio (SINR).## The below reference to Figs. 13 to 18 is to be read to instead refer to Figs. 17to 22, respectively.Fig. 13 shows a schematic block diagram for an embodiment of the device 100. Thedevice 100 comprises processing circuitry, e.g., one or more processors 1304 for performing the method 300 and memory 1306 coupled to the processors 1304. For example, the memory 1306 may be encoded with instructions that implement at least one of the modules 106 and 110. The one or more processors 1304 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the device 100, such as the memory 1306, wireless device functionality. For example, the one or more processors 1304 may execute instructions stored in the memory 1306. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 100 being configured to perform the action. As schematically illustrated in Fig.13, the device 100 may be embodied by a wireless device 1300, e.g., functioning as a radio device or a transmitting UE. The wireless device 1300 comprises a wireless (e.g., radio) interface 1302 coupled to the device 100 for radio communication with one or more receiving stations, e.g., functioning as a receiving base station or a receiving UE.Fig. 14 shows a schematic block diagram for an embodiment of the device 200. Thedevice 200 comprises processing circuitry, e.g., one or more processors 1404 for performing the method 400 and memory 1406 coupled to the processors 1404. For example, the memory 1406 may be encoded with instructions that implement at least one of the modules 202, 204 and 206. The one or more processors 1404 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the device 200, such as the memory 1406, network node functionality. For example, the one or more processors 1404 may execute instructions stored in the memory 1406. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 200 being configured to perform the action. As schematically illustrated in Fig.14, the device 200 may be embodied by a network node 1400, e.g., functioning as a gNB or a receiving UE. The network node 1400 comprises a wireless (e.g., radio) interface 1402 coupled to the device 200 for radio communication with one or more transmitting stations, e.g., functioning as a transmitting base station or a transmitting UE. With reference to Fig.15, in accordance with an embodiment, a communication system 1500 includes a telecommunication network 1510, such as a 3GPP-type cellular network, which comprises an access network 1511, such as a radio access network, and a core network 1514. The access network 1511 comprises a plurality of base stations 1512a, 1512b, 1512c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1513a, 1513b, 1513c. Each base station 1512a, 1512b, 1512c is connectable to the core network 1514 over a wired or wireless connection 1515. A first user equipment (UE) 1591 located in coverage area 1513c is configured to wirelessly connect to, or be paged by, the corresponding base station 1512c. A second UE 1592 in coverage area 1513a is wirelessly connectable to the corresponding base station 1512a. While a plurality of UEs 1591, 1592 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1512. Any of the base stations 1512 may embody the device 200. Alternatively or in addition, any of the UEs 1591 and 1592 may embody the device 100. The telecommunication network 1510 is itself connected to a host computer 1530, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 1530 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 1521, 1522 between the telecommunication network 1510 and the host computer 1530 may extend directly from the core network 1514 to the host computer 1530 or may go via an optional intermediate network 1520. The intermediate network 1520 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 1520, if any, may be a backbone network or the Internet; in particular, the intermediate network 1520 may comprise two or more sub-networks (not shown). The communication system 1500 of Fig.15 as a whole enables connectivity between one of the connected UEs 1591, 1592 and the host computer 1530. The connectivity may be described as an over-the-top (OTT) connection 1550. The host computer 1530 and the connected UEs 1591, 1592 are configured to communicate data and / or signaling via the OTT connection 1550, using the access network 1511, the core network 1514, any intermediate network 1520 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1550 may be transparent in the sense that the participating communication devices through which the OTT connection 1550 passes are unaware of routing of uplink and downlink communications. For example, a base station 1512 need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1530 to be forwarded (e.g., handed over) to a connected UE 1591. Similarly, the base station 1512 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1591 towards the host computer 1530. By virtue of the method 300 being performed by any one of the UEs 1591 or 1592 and / or the method 400 being performed by any one of the base stations 1512, the performance or range of the OTT connection 1550 can be improved, e.g., in terms of increased throughput and / or reduced latency. More specifically, the host computer 1530 may indicate to the RAN 510 or the radio device 100 (e.g. a relay radio device or a remote radio device), optionally on an application layer, the QoS of the traffic. Example implementations, in accordance with an embodiment of the UE, base station and host computer discussed in the preceding paragraphs, will now be described with reference to Fig.16. In a communication system 1600, a host computer 1610 comprises hardware 1615 including a communication interface 1616 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1600. The host computer 1610 further comprises processing circuitry 1618, which may have storage and / or processing capabilities. In particular, the processing circuitry 1618 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 1610 further comprises software 1611, which is stored in or accessible by the host computer 1610 and executable by the processing circuitry 1618. The software 1611 includes a host application 1612. The host application 1612 may be operable to provide a service to a remote user, such as a UE 1630 connecting via an OTT connection 1650 terminating at the UE 1630 and the host computer 1610. In providing the service to the remote user, the host application 1612 may provide user data, which is transmitted using the OTT connection 1650. The user data may depend on the location of the UE 1630. The user data may comprise auxiliary information or precision advertisements (also: ads) delivered to the UE 1630. The location may be reported by the UE 1630 to the host computer, e.g., using the OTT connection 1650, and / or by the base station 1620, e.g., using a connection 1660. The communication system 1600 further includes a base station 1620 provided in a telecommunication system and comprising hardware 1625 enabling it to communicate with the host computer 1610 and with the UE 1630. The hardware 1625 may include a communication interface 1626 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1600, as well as a radio interface 1627 for setting up and maintaining at least a wireless connection 1670 with a UE 1630 located in a coverage area (not shown in Fig.16) served by the base station 1620. The communication interface 1626 may be configured to facilitate a connection 1660 to the host computer 1610. The connection 1660 may be direct, or it may pass through a core network (not shown in Fig.16) of the telecommunication system and / or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1625 of the base station 1620 further includes processing circuitry 1628, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 1620 further has software 1621 stored internally or accessible via an external connection. The communication system 1600 further includes the UE 1630 already referred to. Its hardware 1635 may include a radio interface 1637 configured to set up and maintain a wireless connection 1670 with a base station serving a coverage area in which the UE 1630 is currently located. The hardware 1635 of the UE 1630 further includes processing circuitry 1638, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 1630 further comprises software 1631, which is stored in or accessible by the UE 1630 and executable by the processing circuitry 1638. The software 1631 includes a client application 1632. The client application 1632 may be operable to provide a service to a human or non-human user via the UE 1630, with the support of the host computer 1610. In the host computer 1610, an executing host application 1612 may communicate with the executing client application 1632 via the OTT connection 1650 terminating at the UE 1630 and the host computer 1610. In providing the service to the user, the client application 1632 may receive request data from the host application 1612 and provide user data in response to the request data. The OTT connection 1650 may transfer both the request data and the user data. The client application 1632 may interact with the user to generate the user data that it provides. It is noted that the host computer 1610, base station 1620 and UE 1630 illustrated in Fig.16 may be identical to the host computer 1530, one of the base stations 1512a, 1512b, 1512c and one of the UEs 1591, 1592 of Fig.15, respectively. This is to say, the inner workings of these entities may be as shown in Fig.16, and, independently, the surrounding network topology may be that of Fig.15. In Fig.16, the OTT connection 1650 has been drawn abstractly to illustrate the communication between the host computer 1610 and the UE 1630 via the base station 1620, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 1630 or from the service provider operating the host computer 1610, or both. While the OTT connection 1650 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). The wireless connection 1670 between the UE 1630 and the base station 1620 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 1630 using the OTT connection 1650, in which the wireless connection 1670 forms the last segment. More precisely, the teachings of these embodiments may reduce the latency and improve the data rate and thereby provide benefits such as better responsiveness and improved QoS. A measurement procedure may be provided for the purpose of monitoring data rate, latency, QoS and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1650 between the host computer 1610 and UE 1630, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection 1650 may be implemented in the software 1611 of the host computer 1610 or in the software 1631 of the UE 1630, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 1611, 1631 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1620, and it may be unknown or imperceptible to the base station 1620. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 1610 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 1611, 1631 causes messages to be transmitted, in particular empty or "dummy" messages, using the OTT connection 1650 while it monitors propagation times, errors etc. Fig.17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs.15 and 16. For simplicity of the present disclosure, only drawingreferences to Fig. 17 will be included in this paragraph. In a first step 1710 of themethod, the host computer provides user data. In an optional substep 1711 of the first step 1710, the host computer provides the user data by executing a host application. In a second step 1720, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1730, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 1740, the UE executes a client application associated with the host application executed by the host computer. Fig.18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described withreference to Figs. 15 and 16. For simplicity of the present disclosure, only drawingreferences to Fig. 18 will be included in this paragraph. In a first step 1810 of themethod, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 1820, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1830, the UE receives the user data carried in the transmission. Without feedback from the UE or knowledge of a relationship between PDU sets, the conventional network cannot or can hardly know the QoS impacts of handling multi-modal PDU sets. As has become apparent from above description, at least some embodiments of the technique enable the gNB to rapidly adapt radio resource management to dynamic application requirements. Reference signs have the technical meaning specified in the context of the respective description or may other have the following meaning. 10 Existing UE20 Existing gNB50 Existing downlink architecture for a telecommunication network100 Wireless device for handling PDU sets, e.g. user equipment (UE)106 PDU Set Measurement Module110 Report Transmission Module200 Network node for handling PDU sets, e.g. gNB201 Cell or beam of the network nodeReport Reception ModulePDU Set Scheduling ModuleFirst method aspect of handling a PDU setSending capability message stepReceiving configuration message stepObtaining inter-dependency stepDetermining criterion stepSending report message stepSecond method aspect of handling a PDU setReceiving capability message stepSending configuration message stepReceiving report message stepScheduling step, e.g. changing DRP-QFI mappingTelecommunication networkCapability messageConfiguration messageReport message,e.g. indicative of PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), or PDU Set Importance (PSI)Access network (AN)Core network (CN), e.g. 5G Core Network (5GC)User plane function (UPF) of the CNPDU SessionN3 TunnelPacket Data Convergence Protocol (PDCP) (sub-)layerPDCP entityData Radio Bearer (DRB)Service Data Adaptation Protocol (SDAP) (sub-)layerSDAP entityQuality of Service (QoS) flow, e.g. QoS flow identifier (QFI)Packet data unit set (PDU set)1300 Wireless device embodiment1304 Computing devices of the wireless device1306 Computer-readable recording medium of the wireless device1400 Network node embodiment1404 Computing devices of the network node1406 Computer-readable recording medium of the wireless device1500 Communication system embodiment, e.g. telecommunication network1510 Cellular or ad hoc radio network as an example of the AN1512 Network node embodiment1530 Host computer1540 Communication interface1591 Wireless device embodiment1592 A wireless device embodiment1600 Communication system embodiment, e.g. telecommunication network1610 Host computer1612 Host application, e.g. receiving the PDU set1616 Communication interface1618 Processing circuitry1620 Network node embodiment1628 Processing circuitry1630 Wireless device embodiment1632 Client application, e.g. generating the PDU set, e.g. extended Reality (XR)1637 Radio interface1638 Processing circuitryMany advantages of the present invention will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction and arrangement of the units and devices without departing from the scope of the invention and / or without sacrificing all of its advantages. Since the invention can be varied in many ways, it will be recognized that the invention should be limited only by the scope of the following claims.

Claims

Claims1. A method (300) performed by a wireless device, WD (100; 1700; 1991;1992; 2030), wirelessly connected or connectable to an access network, AN (510), the method (300) comprising or initiating: obtaining (306) at the WD (100; 1700; 1991; 1992; 2030) at least one inter- dependency (760) between at least two packet data unit sets, PDU sets (750), wherein the PDU set (750) comprises at least one quality of service, QoS, parameter of the PDU set (750), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510); and sending (310), to the AN (510), a report message (506) indicative of the at least one obtained (306) inter-dependency (760).

2. The method (300) of claim 1, wherein one or each of the at least two PDUsets (750) corresponds to one or more data traffic flows and / or wherein each of the at least two PDU sets (750) corresponds to and / or originates from one service.

3. The method (300) of claim 1 or 2, wherein the at least two PDU sets (750)correspond to different data traffic flows or different data types; and / or wherein the at least two PDU sets (750) correspond to at least two of avideo flow; an audio flow; one or more environmental information flow; a poseflow; a gesture flow; and a haptic flow.

4. The method (300) of any one of claims 1 to 3, wherein the at least two PDUsets (750), optionally the at least two of the data traffic flows, are inter-dependent (760) because of at least one of: a synchronization requirement between the at least two PDU sets (750), optionally between the at least two of the data traffic flows; a common internet protocol, IP, address and / or port number and / or medium access control, MAC, address synchronization requirement of the at least two PDU sets (750), optionally of the at least two of the data traffic flows; and a correlation between the at least two PDU sets (750), optionally between the at least two of the data traffic flows.

5. The method (300) of any one of claims 1 to 4, wherein the report message(506) is indicative of statistical information of the at least one inter-dependency (760) between the at least two PDU sets (750), optionally including at least one of a minimum, a maximum, an average, a variance, and a probability distribution of a delay of one or each of the at least two PDU sets (750).

6. The method (300) of any one of claims 1 to 5, wherein the at least two PDUsets (750), optionally the at least two of the data traffic flows, are received by an application layer of the WD (100; 1700; 1991; 1992; 2030) and / or received from an application layer, optionally an application server, through a network node (200; 1800; 1912; 2020) of the AN (510); and / or wherein the at least two PDU sets (750), optionally the at least two of the data traffic flows, are sent from an application layer of the WD (100; 1700; 1991; 1992; 2030) and / or sent to an application layer, optionally an application server, through a network node (200; 1800; 1912; 2020) of the AN (510).

7. The method (300) of any one of claims 1 to 6, further comprising orinitiating: determining (308) whether the obtained (306) at least one inter- dependency (760) fulfils a predefined criterion, optionally wherein the report message (506) is indicative of whether or not the predefined criterion is fulfilled and / or wherein the transmission (310) of the report message (506) is triggered if the predefined criterion is not fulfilled.

8. The method (300) of any one of claims 1 to 7, further comprising orinitiating: sending (302) a capability message (502) the to the AN (510), optionally wherein the capability message (502) is indicative of at least one of: a capability of the WD (100; 1700; 1991; 1992; 2030) to measure at least one QoS parameter across the at least two the PDU sets (750), optionally in the uplink towards the AN (510) or in the downlink from the AN (510); a capability of the WD (100; 1700; 1991; 1992; 2030) to obtain (306) the at least one inter-dependency (760) between the at least two measured PDU sets (750); a capability of the WD (100; 1700; 1991; 1992; 2030) to report (310) a result of the obtainment (306) of the at least one interdependency (760) to the AN (510);a capability of the WD (100; 1700; 1991; 1992; 2030) to report (310) a result of the measurement of the at least one QoS parameter across the at least two the PDU sets (750); a physical layer information of the WD (100; 1700; 1991; 1992; 2030); and a feature set indicator, optionally comprising radio protocol information.

9. The method (300) of any one of claims 1 to 8, further comprising orinitiating: receiving (304) a configuration message (504) from the AN (510) for the obtaining (306) or the sending (310), optionally the configuration message (504) being indicative of at least one of: a or the QoS parameter across the at least two PDU sets (750) to be measured or obtained (306); the predefined criterion, optionally a threshold for the delay; a QoS flow (724), optionally a QoS flow identifier, QFI, associated with the at least two PDU sets (750); a data radio bearer, DRB (714), associated with the at least two PDU sets (750); PDU set identifiers of the at least two PDU sets (750); a cross-PDU set importance, cross-PSI, associated with the at least two PDU sets (750) and / or indicative of an importance level of the inter-dependency; a set of QoS flow identifiers, QFIs, associated with the at least two PDU sets (750); a set of DRB indexes associated with the at least two PDU sets (750); matching information for matching the at least two PDU sets (750) that are inter- dependent and / or a set of application flow specific information associated with all of the at least two PDU sets (750) that are inter-dependent; an obtaining mode for the obtaining (306) of the inter-dependency; a reporting mode for the sending (310) of the report message (506); an obtainment window for the obtaining (306) of the inter-dependency and / or for measuring the at least one QoS parameters across the at least two PDU sets; a periodicity for the measuring, the obtaining (306), and / or the sending of the report message; and a deadline for the sending (310) of the report message (506).

10. The method (300) of any one of claims 1 to 9, wherein a or the obtainingmode for the obtaining (306) of the at least one inter-dependency and / or a or the reporting mode for the sending (310) of the report message (506) comprises at least one of: a periodic obtaining (306) and / or a periodic report message (506), an aperiodic obtaining (306) and / or an aperiodic report message (506), an event-triggered obtaining (306) and / or an event-triggered report message (506), and on-demand obtaining (306) and / or an on-demand report message (506).

11. The method (300) of any one of claims 1 to 10, wherein the predefinedcriterion is defined in terms of, or includes a value for a threshold of, -the correlation between the at least two PDU sets (750) or- the synchronization between the at least two PDU sets (750) or- the QoS parameter across the at least two PDU sets (750); and / orwherein the predefined criterion is defined in terms of, or includes a value for a threshold of, a PDU set (750) error rate, PSER, or a PDU set (750) delay budget, PSDB, applicable to the combination of the inter-dependent at least two PDU sets.

12. The method (300) of any one of claims 1 to 11, wherein the report message(506) uses or comprises at least one of Radio Resource control, RRC, signaling; UE Assistance Information, UAI; a Packet Data Convergence Protocol, PDCP, control PDU; and a Service Data Adaptation Protocol, SDAP, control PDU; and / or wherein the sending (310) comprises sending the report message (506) in a control plane, CP, data unit using an RRC layer, a PDCP layer and / or an SDAP layer.

13. The method (300) of any one of claims 1 to 12, wherein a or the reportingmode comprises at least one of periodic reporting, an event-triggered reporting, and on-demand reporting.

14. The method (300) of any one of claims 1 to 13, wherein all PDUs in the PDUset (750) are transmitted on the same QoS flow; and / or wherein all PDUs in the PDU set (750) are transmitted or received with the same QoS level or the same QFI (724); and / or wherein PDUs of different ones of the at least two PDU sets (750) are transmitted or received with different QoS levels or different QFIs (724); and / orwherein PDUs of different ones of the at least two PDU sets (750) are transmitted or received on different DRBs (714), optionally prior to the sending (310) of the report message (506); and / or wherein the report message (506) is indicative of, or includes a request for, mapping the at least two PDU sets (750) to the same DRB (714); and / or wherein the report message (506) is indicative of, or includes a request for, mapping different QoS flows, optionally different QFIs, of the at least two PDU sets (750) to the same DRB (714); and / or wherein all PDUs of the at least two PDU sets (750) are transmitted or received on the same DRB (714), optionally responsive to the sending (310) of the report message (506).

15. The method (300) of any one of claims 1 to 14, wherein the report message(506) is transmitted (310) to a network node (200; 1700; 1812; 1920) of the AN (510), optionally to the network node (200; 1800; 1912; 2020) serving the WD (100).

16. The method (300) of any one of claims 1 to 15, further comprising orinitiating: sending to the AN (510), optionally to the serving network node (200), a request message indicative of, or includes a request for, mapping the at least two PDU sets (750) to the same DRB (714) and / or indicative of, or includes a request for, mapping different QoS flows, optionally different QFIs, of the at least two PDU sets (750) to the same DRB (714); and / or sending (312) to the AN (510), optionally to the serving network node (200), a confirmation message (508), optionally an RRC-Reconfiguration-Complete message indicative of adapting a reconfiguration, optionally confirming an adaptation to a changed mapping of the at least two PDU sets (750) to the same DRB (714) and / or mapping different QoS flows, optionally different QFIs, of the at least two PDU sets (750) to the same DRB (714).

17. A method (400) performed by a network node (200; 1700; 1812; 1920) of anaccess network, AN (510), the method (400) comprising or initiating: receiving (410) a report message (506) from a WD (100; 1700; 1991; 1992; 2030) wirelessly connected to the AN (510), wherein the report message (506) is indicative of at least one inter-dependency (760) between at least two packet dataunit sets, PDU sets (750), at the WD (100; 1700; 1991; 1992; 2030), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510); and scheduling (412) resources, optionally for the uplink or downlink, of the WD (100; 1700; 1991; 1992; 2030) based on the received (410) report message (506).

18. The method (400) of claim 17, wherein the scheduling (412) of theresources comprises at least one of: adjusting a resource allocation of the at least two PDU sets (750), optionally if the received (410) report message (506) is indicative of one of the at least two PDU sets (750) fulfilling its QoS requirement while another one of the at least two PDU sets (750) does not fulfill its QoS requirement, and / or wherein the resource allocation for the WD (100; 1700; 1991; 1992; 2030) is adjusted by changing the resource allocation of temporal resources, frequency resources and / or spatial resources of the AN (510) and / or a transmit power control settings; configuring one or more functions of the AN (510), optionally of the network node (200), based on the received (410) report message (506), optionally Hybrid Automatic Repeat Request (HARQ) settings are reconfigured or a modulation and coding scheme, MCS, is reconfigured or a retransmission strategy is reconfigured; updating PDU set handling at the AN (510) for the inter-dependent at least two PDU sets; adapting to a dynamic traffic pattern, optionally wherein the AN (510) uses the received (410) report message (506) as dynamic QoS performance information to adapt to changing traffic patterns and / or wherein a service or an application underlying the at least two PDU sets uses variable bit rates or burst-like traffic; and sending a feedback to a core network (520) serving the AN (510), optionally wherein sending the feedback to the core network (520) is indicative of a QoS performance of the service based on the combination of the at least two PDU sets and the received (410) report message (506), preferably to update policies and / or rules for traffic management and / or PDU session establishment.

19. The method (400) of claim 17 or 18, further comprising or initiating:receiving (402) a capability message (502) from the WD (100; 1700; 1991; 1992; 2030), optionally wherein the capability message (502) is indicative of at least one of:a capability of the WD (100; 1700; 1991; 1992; 2030) to measure at least one QoS parameter across the at least two the PDU sets (750), optionally in the uplink towards the AN (510) or in the downlink from the AN (510); a capability of the WD (100; 1700; 1991; 1992; 2030) to obtain (306) the at least one inter-dependency (760) between the at least two measured PDU sets (750); a capability of the WD (100; 1700; 1991; 1992; 2030) to report (310) a result of the obtainment (306) of the at least one interdependency (760) to the AN (510); a capability of the WD (100; 1700; 1991; 1992; 2030) to report (310) a result of the measurement of the at least one QoS parameter across the at least two the PDU sets (750); a physical layer information of the WD (100; 1700; 1991; 1992; 2030); and a feature set indicator, optionally comprising radio protocol information.

20. The method (400) of any one of claims 17 to 19, further comprising orinitiating: transmitting (404) a configuration message (504) to the WD (100; 1700; 1991; 1992; 2030), optionally the configuration message (504) being indicative of at least one of: a or the QoS parameter across the at least two PDU sets (750) to be measured or obtained (306); the predefined criterion, optionally a threshold for the delay; a QoS flow (724), optionally a QoS flow identifier, QFI, associated with the at least two PDU sets (750); a data radio bearer, DRB (714), associated with the at least two PDU sets (750); PDU set identifiers of the at least two PDU sets (750); a cross-PDU set importance, cross-PSI, associated with the at least two PDU sets (750) and / or indicative of an importance level of the inter-dependency; a set of QoS flow identifiers, QFIs, associated with the at least two PDU sets (750); a set of DRB indexes associated with the at least two PDU sets (750); matching information for matching the at least two PDU sets (750) that are inter-dependent and / or a set of application flow specific information associated with all of the at least two PDU sets (750) that are inter-dependent; an obtaining mode for the obtaining (306) of the inter-dependency; a reporting mode for the sending (310) of the report message (506);an obtainment window for the obtaining (306) of the inter-dependency and / or for measuring the at least one QoS parameters across the at least two PDU sets; a periodicity for the measuring, the obtaining (306), and / or the sending of the report message; and a deadline for the sending (310) of the report message (506).

21. The method (400) of any one of claims 17 to 20, wherein the scheduling(412) comprises: changing a mapping of one or more data radio bearers, DRBs (714), to at least one or two QoS flows or QFIs (724) used by the at least two PDU sets (750) in response to the receiving (410) of the report message (506); and / or changing a mapping of at least one or two QoS flows or QFIs (724) used by the at least two PDU sets (750) to one or more data radio bearers, DRBs (714), in response to the receiving (410) of the report message (506).

22. The method (400) of any one of claims 17 to 21, further comprising thesteps or features of any one of claims 2 to 16 or any step corresponding thereto.

23. A computer program product comprising program code portions forperforming the steps of any one of the claims 1 to 16 or 17 to 22 when the computer program product is executed on one or more computing devices (1304; 1404), optionally stored on a computer-readable recording medium (1306; 1406).

24. A wireless device, WD (100; 1300; 1591; 1592; 1630), wirelessly connectedor connectable to an access network, AN (510), the WD (100; 1300; 1591; 1592; 1630) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the WD (100; 1300; 1591; 1592; 1630) is operable to: obtain at the WD (100; 1700; 1991; 1992; 2030) at least one inter- dependency (760) between at least two packet data unit sets, PDU sets (750), wherein the PDU set (750) comprises at least one quality of service, QoS, parameter of the PDU set (750), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510); and send, to the AN (510), a report message (506) indicative of the at least one obtained inter-dependency (760).

25. The WD (100; 1300; 1591; 1592; 1630) of claim 24, further comprising thefeatures or being operable to perform the steps of any one of claims 2 to 16.

26. A wireless device, WD (100; 1300; 1591; 1592; 1630), wirelessly connectedor connectable to an access network, AN (510), the WD (100; 1300; 1591; 1592; 1630) being configured to: obtain at the WD (100; 1700; 1991; 1992; 2030) at least one inter- dependency (760) between at least two packet data unit sets, PDU sets (750), wherein the PDU set (750) comprises at least one quality of service, QoS, parameter of the PDU set (750), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510); and send, to the AN (510), a report message (506) indicative of the at least one obtained inter-dependency (760).

27. The WD (100; 1300; 1591; 1592; 1630) of claim 26, further comprising thefeatures or being configured to perform the steps of any one of claims 2 to 16.

28. A network node (200; 1400; 1512; 1620) of an access network, AN (510), thenetwork node (200; 1400; 1512; 1620) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node (200; 1400; 1512; 1620) is operable to: receive a report message (506) from a WD (100; 1700; 1991; 1992; 2030) wirelessly connected to the AN (510), wherein the report message (506) is indicative of at least one inter-dependency (760) between at least two packet data unit sets, PDU sets (750), at the WD (100; 1700; 1991; 1992; 2030), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510); and schedule resources, optionally for the uplink or downlink, of the WD (100; 1700; 1991; 1992; 2030) based on the received report message (506).

29. The network node (200; 1400; 1512; 1620) of claim 28, further operable toperform any one of the steps of any one of claims 18 to 22.

30. A network node (200; 1400; 1512; 1620) of an access network, AN (510), thenetwork node (200; 1400; 1512; 1620) being configured to: receive a report message (506) from a WD (100; 1700; 1991; 1992; 2030) wirelessly connected to the AN (510), wherein the report message (506) is indicative of at least one inter-dependency (760) between at least two packet dataunit sets, PDU sets (750), at the WD (100; 1700; 1991; 1992; 2030), optionally in an uplink towards the AN (510) and / or in a downlink from the AN (510); and schedule resources, optionally for the uplink or downlink, of the WD (100; 1700; 1991; 1992; 2030) based on the received report message (506).

31. The network node (200; 1400; 1512; 1620) of claim 30, further configuredto perform the steps of any one of claim 18 to 22.

32. A communication system (1500; 1600) including a host computer (1530;1610) comprising: processing circuitry (1618) configured to provide user data; and a communication interface (1616) configured to forward user data to a cellular or ad hoc radio network (510; 1510) for transmission to a user equipment, UE (100; 1300; 1591; 1592; 1630), wherein the UE (100; 1300; 1591; 1592; 1630) comprises a radio interface (1302; 1637) and processing circuitry (1304; 1638), the processing circuitry (1304; 1638) of the UE (100; 1300; 1591; 1592; 1630) being configured to execute the steps of any one of claims 1 to 16.

33. The communication system (1500; 1600) of claim 32, further including theUE (100; 1300; 1591; 1592; 1630).

34. The communication system (1500; 1600) of claim 32 or 33, wherein theradio network (510; 1510) further comprises a base station (200; 1400; 1512; 1620), or a radio device (100; 1300; 1591; 1592; 1630) functioning as a gateway, which is configured to communicate with the UE (100; 1300; 1591; 1592; 1630).

35. The communication system (1500; 1600) of claim 34, wherein the basestation (200; 1400; 1512; 1620), or the radio device (100; 1300; 1591; 1592; 1630) functioning as a gateway, comprises processing circuitry (1404; 1628), which is configured to execute the steps of any one of claims 17 to 22.

36. The communication system (1500; 1600) of any one of claims 32 to 35,wherein: the processing circuitry (1618) of the host computer (1330; 1410) is configured to execute a host application (1612), thereby providing the user data; andthe processing circuitry (1304; 1638) of the UE (100; 1300; 1591; 1592; 1630) is configured to execute a client application (1632) associated with the host application (1612).

Images