Method for managing data transmission in a communication network

Abstract

A method for managing the transmission of a multimodal data flow between a transmitter and a receiver of a wireless network, the method at the transmitter comprising: providing, for a first PDU of a f

Description

TECHNICAL FIELD The present disclosure relates to a technique for managing data in a communication network (e.g., a mobile telecommunication network), and in particular to methods and apparatuses for handling multimodal XR data. BACKGROUND Wireless communication systems are deployed to address a wide range of applications, including mobile broadband, massive machine type communications, and Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange different types of data content (e.g., video, voice, messaging...) over a radio access network (RAN) through one or more base stations. Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth generation (4G) Long Term Evolution (LTE) and (more recently) fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi. Among the requirements for 5G NR, there are service requirements related to extended reality (XR). XR applications are defined in 3GPP document RP-2200285 as “various types of augmented, virtual, and mixed environments, where human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end user devices”. Various use cases can be found in 3GPP document TR-26.928. XR applications may involve interactions between a wearable device (e.g., a 3D helmet or augmented reality glasses) and an application server. The wearable device and the application server can be connected through a local Network (e.g., a wireless LAN) or cellular network (e.g., 3GPP 5G cellular network, the application server being connected to a 5G core network component of the network).XR applications (e.g., relating to cloud gaming) can require transferring compressed video data, audio data from the server to the UE and positioning information from the UE to the server. XR applications, such as those relating to virtual reality, can involve transferring compressed video data, audio data and various information from the server to the wearable device. XR applications, such as those relating to augmented reality (AR), may involve transferring compressed video data, audio data and various information exchanged to and from the wearable device and the server. The information exchanged to and from the UE (e.g., wearable device) and the server may be referred to as ‘application data’, and it may comprise one or more images, video data, audio data, and position information etc. The video and audio data are transferred between the UE (e.g., wearable device) and the server using media transport protocols such as RTP (Real Time Protocol, RFC 3550), SRTP (Secured RTP, RFC 3711), HTTP (Hyper Text Transfer Protocol, RFC 2616-7540) orQUIC (RFC 8999, 9000, 9001 and 9002). Video encoding and decoding can be performed according to various formats including MPEG2, H.264, H.265, HEVC, etc. In particular, applications generate data (e.g., application data) in the form of encoded video, audio, or position information etc. The application data is primarily arranged in data packets by the application. For example, an application data packet representing one unit of information may be generated at the application level. According to the 3GPP standard, a set of Protocol Data Units, or Packet Data Units, (PDUs) are necessary to transport an application data packet (i.e., “PDU Set”). Accordingly, the application data comprises one or more application data packets. During downlink, 3GPP PDUs are formatted by the PDU Layer of the core network. In the same way, during uplink, the 3GPP PDUs are formatted by the PDU layer of the UE (e.g., wearable device). Typically, the delimitations of the PDU Sets (e.g., start, stop, and length etc.) are not provided by the application but generated by the core network (respectively the UE) through media transport protocol packet inspection. The detailed procedure is described in 3GPP document S2-2302696. A PDU Set includes one or more PDUs that carry the payload of one unit of information generated at the application level (e.g., a frame or video slice forXRM Services, as used in TR 26.926). In some implementations, all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. For example, one PDU Set may comprise the data of one image or frame from a video stream. In other implementations, the application layer can still recover parts, or all, of the information unit, when some PDUs are missing. The network used to transport the application data can experience perturbation and congestion. It is therefore possible that some PDUs of a PDU Set are missing, or are late, at the receiving side (e.g., at the UE PDU layer during downlink, and at the core network user plane function (UPF) during uplink). Some video decoder implementations require that a complete application data packet (e.g., complete PDU Set) is received on time in order to adequately decode a video. Some other implementations can tolerate late arrival of data packets, or partial delivery of a data packet. For example, these implementations rely on Forward Error Correction (FEC) technology or concealment techniques. According to 3GPP standard document S2-2302696, a PDU Set QoS parameter called PDU Set Delay Budget (PSDB) is defined. The PSDB defines a time budget allocated to the transport of the PDU Set across the 5G network. This QoS parameter, defined by the application, is used by a 5G network to assess if a PDU Set (e.g., application data packet) is delivered on time. Another QoS parameter named PDU Set Integrated Handling Indication (PSIHI) is defined to characterize the decoder’s tolerance to the loss of data, or receiving outdated (e.g., delayed) data. If the PSIHI parameter is set to “true”, then the decoder can only handle (e.g., manage or process) a complete application data packet which is received on time. If the PSIHI parameter is set to “false”, then the decoder can tolerate both incomplete and delayed application data packets. Considering the situation at a particular component of the 5G network, when a PDU Set is sent over the air interface, some information is available regarding the reception status of the PDUs and the elapsed time of the PSDB. For example, when a PDU Set is transferred over the air a Radio Access Network (RAN) node (e.g., a UE or a next gen node (gNB)) can detect that a PDU transmission has failed despite all the retransmissions and error correction mechanisms. In that case, if the PSIHI parameter is set to “true”, then the entire PDU Set is useless to the application. In that case, if one or more PDUs of this ‘useless’ PDU Set are pending transmission over the air interface then the RAN node can consider discarding the remaining transmission of the ‘useless’ PDUs, thus achieving radio network resource saving. The PDU Sets are mapped on QoS flows (SDAP layer), QoS flows are mapped on DRBs (PDCP layer), DRBs are mapped on RLC channels (RLC layer), RLC channels are mapped on logical channels (MAC layer). The MAC layer implements a reliability mechanism called hybrid automatic repeat request (ARQ), which provides a given level of reliability that can be improved by the RLC layer if needed. The RLC layer can be operated in an acknowledge mode, which implements an additional ARQ mechanism that further enhances the reliability of the transmission. In some XR applications, the PDU Set belongs to different modalities (e.g., video, audio, haptic and sensors), which can be mapped to independent QoS flows. However, some applications require that specific dependencies between each modality to be enforced or implemented. More specific requirements are described in 3GPP standard document TS 22.261, clause 6.43. Therefore, there is a need to provide multimodality inter-dependency information to the radio access network (RAN), either UE or gNB, or both, to enforce the multimodal inter-dependency requirements. SUMMARY According to embodiments of the present disclosure, there is provided a method for controlling the transmission of a multimodal data flow (e.g., including multimodal XR data) between a transmitter and a receiver of a wireless network (e.g., a wireless communication network, such as 3GPP), the method comprises identifying and / or indicating, for a first PDU (or PDU Set), the existence of a second PDU (or PDU Set) having a different modality. According to a first embodiment there is provided a method for managing the transmission of a multimodal data flow between a transmitter and a receiver of a wireless network, the method at the transmitter comprising: providing, for a first PDU of a first modality, information indicative of a second PDU of a second modality different to the first modality. XR applications often require that PDU Sets from different modalities are delivered to the application within a constrained time, in certain situations, at the receiving side, if a PDU from a first flow arrives too late compared to the reception time of a PDU from a second flow, then both PDU Sets are obsolete and shall be rejected by the application. According to known transmission techniques, the inter-relationship between two modalities cannot be detected at the transmitting side using timers applied to individual modalities. Accordingly, there is a need fora procedure at the transmitting side that will enable the detection of any inter-dependency requirement violations by PDUs prior to their transmission. The invention according to the present disclosure provides an indication of a difference in PDU modality between two PDUs allowing the transmitter side to discard the PDUs if a violation is detected, and thereby save valuable radio resources. Optional features will now be set out. These are applicable singly or in any combination with any aspect of the disclosure. The information provided by the transmitter may be indicative of a link between first PDU and the second PDU. The information may comprise a synchronization threshold. The synchronization threshold may be indicative of the link, or inter-dependency, between PDUs of different modalities (e.g., the first and second PDUs). For example, the synchronization threshold may define a value beyond which the synchronization of two different PDU modalities is discarded (e.g., by discarding one or more of the ‘synchronized’ PDUs). The method may comprise, upon receiving a PDU from a higher level of the protocol stack (e.g., the application layer), starting a discard timer for triggering a delay-based discarding of the first PDU. An initial value of the discard timer may be the same for each PDU of a PDU Set. The initial discard timer value may be a function of a PDU delay budget of the first PDU,. Alternatively, the initial discard timer value may be a PDU Set delay budget of the PDU Set to which the first PDU budget belongs. The initial discard timer value may be configured to be less than the PDU Set delay budget if a congestion management procedure is activated, and / or if a PDU Set importance value of the PDU Set is below a threshold value. The PDU Set importance value may be indicative of the relative importance of a PDU Set compared to other PDU Sets within a Quality of Service (QoS) flow. The method may comprise, upon receiving the first PDU, starting a multimodal timer for triggering a multimodal discarding of the first PDU. The multimodal timer may be configured based on at least one of: a discard timer for triggering a delay-based discarding of the first PDU; the difference between the arrival time of the first PDU at the transmitter and the arrival time of the second PDU at the transmitter; and a delay requirement value. An initial value of the multimodal timer may be calculated by subtracting the difference between the arrival times of the first and second PDUs from an initial value of the delay-based discard timer for the first PDU, and then adding the predetermined delay requirement value. The multimodal timer may be started in dependence on at least one of: a PDU delay budget of the first PDU; and a delay requirement of a PDU having a different modality. The PDU having a different modality may be linked to the PDU and may not yet have been received (e.g., at the transmitter, or receiver). The smallest delay requirement among a plurality of PDUs of different modalities may be used to configure the multimodal timer. The multimodal timer may be configured according to at least one of the following criteria: if, upon receiving the first PDU, there is no PDU with a different modality which is linked to the first PDU, then the multimodal timer is not started; if, upon receiving the first PDU, a discard timer has already been started for a PDU of a different modality which is linked to the first PDU (e.g., the second PDU), then the initial multimodal timer value may be calculated based on a PDU delay budget of the first PDU, or a PDU Set delay budget of the PDU Set to which the first PDU belongs, and a delay requirement value; if, upon receiving the first PDU, a discard timer has already been started for a PDU Set of a different modality which may be linked to the first PDU, then the initial multimodal timer value for the first PDU may be calculated based on the initial multimodal timer value of the previous PDU Set and a delay requirement value; and if, upon receiving the first PDU, a discard timer has already been started for a plurality of PDU Sets of different modalities which are linked to the first PDU, then the initial multimodal timer value for the first PDU may be calculated based on the initial multimodal timer value of the previous PDU Sets that may be determined to achieve the earliest multimodal discard triggering. The delay requirement value may be determined based on the modality type of a PDU (or PDU Set) which is to be transmitter by the transmitter (e.g., at least one of the first and second PDUs). The delay requirement value may be predetermined by a component of the wireless network (e.g., a core network component, a UE (e.g., the application implemented therein), and / or a base station). A different delay requirement may be configured for each modality, to reflect the different requirements of the associated PDUs. In embodiments, if the delay requirement values of the first and second modalities are different, then the transmitter receives, for each PDU of the first modality, information indicative of the second modality. In this way, the transmitter provides information for the second PDU dynamically, to accommodate the requirements of the different modalities. If the delay requirement values of the first and second modalities are the same (or substantially similar), then the transmitter may receive information indicative of the second modality for only a single PDU of a plurality of PDUs of the first modality. In this way, the information for the second modality provided for the single PDU can also be applied to other (subsequent) PDUs of the same modality, thereby reducing the use of network resources. If the first and second modalities form part of a single PDU session, then each modality may be mapped on a different Quality of Service (Qos) flow. The information indicative of the second PDU may comprise at least one of: an indication of the flow of the second PDU; a sequence number of the second PDU; a delay (e.g., maximum allowable delay) between the reception of the first PDU and the second PDU (e.g., at the transmitter); and a delay (e.g., maximum allowable delay) between the reception of second PDU and the first PDU. In embodiments, each PDU (e.g., for transmitting by the transmitter) may be configured to provide an indication of the flow of the PDU and / or a sequence number of the PDU. The transmitter may receive information from one or more components of the wireless network (e.g., a UE, gNB or component of the core network) indicating a link between PDUs of different modalities (e.g., the information indicative of the second modality PDU as described in the preceding paragraphs). The information indicating a link between PDUs of different modalities may include an identifier for categorizing an incoming PDU to a modality. In this way, the identifier notifies the transmitter that a PDU is due to arrive (i.e., for transmission to the receiver) and enables the transmitter to pre-emptively categorize the incoming PDU, thereby reducing delays in the multimodal discarding procedure. The transmitter may receive information from one or more components of the wireless network which configures a dependency between two modalities at a flow level. The received information may define a maximum allowed delay period from the reception of the second PDU of the second modality to the reception of a further PDU of the second modality (e.g., a third PDU of the second modality). The transmitter may receive information from one or more components of the wireless network which configures a starting point for the dependency between two modalities. The information may include a pair of sequence numbers fora (corresponding) pair of linked PDUs of the first and second modalities. The above-described information received by the transmitter may be received by one or more components of the wireless network, Further, different information may be received from different network components. In embodiments, the transmitter forms part of a UE of the wireless network, the method may comprise: receiving information indicative of the second PDU from an application of the UE; and discarding the first PDU in dependence on the information received from the application (e.g., if the information indicates that the synchronization threshold is exceeded). Further, the transmitter may receive further information indicative of the second modality from a core network component of the wireless network. The transmitter may form part of a base station of the wireless network. The method may comprise receiving information indicative of the second PDU from a core network component of the wireless network. The method may further comprise discarding a PDU (e.g., the first PDU) in dependence on information received from a core network component of the wireless network. Further, the transmitter may receive further information indicative of the second modality from an application of a UE of the wireless network. In embodiments, the transmitter may be configured to transmit information according to the Packet Data Convergence Protocol (PDCP), and / or the Radio Link Control (RLC) sublayers of the wireless network. Throughout the present disclosure the term ‘flow’ is used to refer to a flow of data from one element of the wireless network to another element. In embodiments, the data modality of the first or second PDUs may be one of the following: video, audio, or haptic. Each data modality may be mapped onto a distinct (e.g., separate) data flow. The transmitter may comprise, or may be embedded within, a user equipment or a base station operating within a 3GPP-compliant wireless communication network. According to a second embodiment there is provided a communication network which comprises a transmitter configured to perform the method according to the first embodiment. According to a third embodiment there is provided a computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to the first embodiment. According to a fourth embodiment there is provided a computer-readable medium carrying a computer program according the third embodiment. Any feature in embodiments of the disclosure may be applied to other embodiment embodiments of the disclosure, in any appropriate combination. In particular, method embodiments may be applied to apparatus / device / unit embodiments, and vice versa. It will be understood that features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other embodiments of the disclosure, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any embodiment or example described above and a computer readable storage medium carrying the computer program. The preceding summary is provided for purposes of summarising some examples to provide a basic understanding of embodiments of the subject matter described herein. Accordingly, the above-described features should not be construed to narrow the scope orspirit of the subject matter described herein in any way. Moreover, the above and / or proceeding examples may be combined in any suitable combination to provide further examples, except where such a combination is clearly impermissible or expressly avoided. Other features, embodiments, and advantages of the subject matter described herein will become apparent from the following text and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Different embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram illustrating a first example wireless communication system in which the present disclosure may be implemented according to one or more embodiments; Figure 2 is a schematic diagram of an example configuration of a user equipment (e.g., UE) in which the present disclosure may be implemented according to one or more embodiments; Figure 3 is a schematic diagram of an example configuration of a base station (e.g., gNB) in which the present disclosure may be implemented according to one or more embodiments; Figure 4 is a schematic diagram illustrating the data plane protocol stack of a 5G new radio (NR) system as shown in Figure 1; Figure 5 is a flow chart showing an example of multiple PDU Sets relating to multiple modalities being exchanged between a transmitter and a receiver; Figure 6a is a flow chart illustrating the inter-dependency between two PDU sets in a multimodal application; Figure 6b is a flow chart illustrating a multimodal discard condition at the transmitting side; Figure 7 is a flow chart showing an example of packet level synchronization between different modalities; Figure 8 is a flow chart showing an exchange sequence inside a UE for an uplink application (e.g., UE to core network) in the case of packet level synchronization; Figure 9 is a flow chart showing an exchange sequence between the core network and the gNB for a downlink application (e.g., core network to UE) in the case of packet level synchronization; Figure 10 is a flowchart showing an example of flow level synchronization between multiple modalities; Figure 11 is a flow chart showing an exchange sequence between a UE and the core network for an uplink application (e.g., UE to core network) in the case of flow level synchronization; and Figure 12 is a flow chart showing a exchange sequence between a gNB and the core network for a downlink application (e.g., core network to UE) in the case of flow level synchronization. DETAILED DESCRIPTION Embodiments and embodiments of the present disclosure will now be discussed with reference to the accompanying figures. Further embodiments and embodiments will be apparent to those skilled in the art. Figure 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting extended reality service (XR). Although in the following description, embodiments, and examples of embodiments of the present disclosure will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present disclosure is limited to 5G NR systems and may be used in any wireless communication systems supporting XR or similar service. The system 100 comprises a User Equipment (UE) 101, 151 which may be for instance virtual reality helmets or extended reality wearables like glasses, served by a base station 110 to communicate with a core network, such as the 5G core network 102. The UE may be any wireless device, such as a wireless communication device or apparatus or terminal, loT device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, user device (e.g., smart phone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of wireless communication with one or more core networks via one or more Radio Access Networks. The base station 110 is a network node which provides an access point to the core network for a UE and is part of the Radio Access Network (RAN) composed of the base stations 110, and 111. In NR, base stations are referred to as next-generation Node Bs (gNBs), the RAN is a Next Generation (NG) RAN and the core network is referred to as the 5GC. In the following, the terms RAN node, base station and gNB will be used interchangeably. The base stations 110 and 111 are interconnected by means of the Xn interface (e.g., as specified in the 3GPP document TS 38.423) implemented on the wired or wireless link 130. Each base station is connected to the core network 102 by means of the NG interface (e.g., as specified in the 3GPP document TS 38.413) implemented on the wired or wireless links 140 and 141. Each of these base stations controls one or multiple cells. For instance, the base station 110 controls the cell 120, and the base station 111 controls the cell 121. A cell is a geographical area of a radio network defined by the frequency used in the cell to transmit data. The cell can be uniquely identified by a UE from an identification that is broadcasted over a geographical area. Each base station 110, 111 can serve several UEs 101, 151. Once a UE has established a RRC connection with a base station, the base station, to which the UE is connected, is referred to as the serving base station (or source base station) of the UE and the cell which is controlled by the serving base station, and on which the UE camps, is referred to as the serving cell. The interface between a gNB and a UE is the Uu interface using the protocol sublayers Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), Physical (PHY) in the user plane, and the protocol sublayers Radio Resource Control (RRC), PDCP, RLC, MAC, PHY in the control plane. It is assumed that the UE 101 is receiving and / or sending XR data of one or more multicast XR sessions generated and / or destinated to the XR application server 103. XR data is provided to the base station 111 (which is the base station controlling the cell 121 on which the UE 101 is attached) through the core network 102 (e.g., through the Data Network 160 and the User Plane Function 161) and the transport bearer (also known asa GTP-U tunnel) 106 over the link 141. Then, XR data is transmitted by the base station 111 to the UE 101 through the Data Radio Bearer (DRB) 154. Figure 1 also shows the UE 151 receiving data through DRB 153. A radio bearer is a set of PHY (layer 1) and MAC (layer 2) parameters allowing higher layer data connection between a UE and a gNB. Multiple types of radio bearers are defined in 5G NR: the Signalling Radio Bearer (SRB) for the control plane, the Data Radio Bearer (DRB) allowing point-to-point communication with one UE in the user plane (e.g., unicast), and the Multicast radio bearer (MRB) allowing point-to-point communication and point-to-multipoint communication with multiple UEs (e.g., multicast / broadcast), also in the user plane. Figure 2 is a block schematic diagram of a UE device 205, like the UE 101 or UE 151 in the Figure 1, in which the present disclosure may be implemented according to one or more embodiments of the disclosure. The UE includes components for transmitting and receiving communications, for example including at least one of a UE communication manager 220, an I / O controller 255, a transceiver 235, a set of antennas 245, a storage device (e.g., memory) 225, and a processor (CPU: Central Processing Unit) 215. All these elements may communicate with each other. The memory 225 includes Random Access Memory (RAM), Read Only Memory (ROM), or a combination of both. Alternatively, or additionally, the memory 225 may comprise a mass storage device, such as a disk, ora Solid-State Drive (SSD). Basic Input Output System (BIOS) Instructions may be stored within the memory 225. The processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may relate to transmission and / or interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2). The processor may run an operating system, such as iOS, Windows, Android, etc. The processor 215 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the UE 205. The I / O controller 255 allows these interactions with external peripherals by providing the hardware required and by managing input and output signals. The I / O controller 255 may for example interact with all or part of an image capture device, an image rendering device, an audio capture device, an audio rendering device, ora sensor device able to determine the use position. The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems (e.g., routers) and frequency shifters necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5G NR, etc. The transceiver 235 may comprise a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 215. The PDCP transmitter and the PDCP receiver may be a software only function implemented by the processor 215. The radio communications use the antenna set 245 adapted to the spectrum of the frequency transposed signals, issued from the baseband modems. The antenna set 245 may be limited to one antenna, but preferably it contains several antennas, in orderto provide beamforming capability. The UE communication manager 220 controls the communication establishment of the UE to a radio access network (RAN). It may also be configured to control the control and release of the UE from the RAN. The UE regularly receives from the base station (e.g., gNB) an indication of the slots which are available for communication between the UE and the base station. Accordingly, the UE is able to determine when and at what frequency it should expect to receive incoming data (e.g., from the gNB). Further, the UE can identify when to send outgoing data, and at what frequency. The UE can determine the transmission / reception of data whether the data belongs to the control plane or the data plane. In one example implementation, the UE communication manager 220 implements the Uu interface. Figure 3 is a block schematic diagram of a base station device 305, such as the gNBs 110 and 111 in the Figure 1, in which embodiments of the present disclosure may be implemented. The base station device 305 includes components for transmitting and receiving communications (e.g., to / from the UE). For example, the base station includes at least one of a base station communication manager 320, a core network communication manager 355, a transceiver 335, a set of antennas 345, memory 325, a processor (e.g., CPU) 315, and an inter-station communication manager 365. All these elements may communicate with each other. The base station communication manager 320 is configured to control the communications with a plurality of UEs. It is responsible for the establishment, control, and release of these communications. In an example implementation, the base station communication manager 320 implements the Uu interface. The base station communication manager 320 includes a scheduler that allocates time frequency slots to the different UE communications. Information regarding the schedule of these slots is regularly sent to the involved UEs. The core network communication manager355 manages communications of the base station with the core network. It may provide a standardized NG interface, as defined by the 3GPP standard, to support these communications. The transceiver 335 is configured to provide bi-directional wireless communication with other wireless devices. These devices may be UEs, or even other base stations. The transceiver 335 provides the necessary modems and frequency shifters in order to connect to a large number of UEs simultaneously, using different frequency carriers, in Time Division Duplex (TDD) or in Frequency Division Duplex (FDD). The transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 315. The PDCP transmitter and the PDCP receiver may be a software only functions implemented by the processor 315. The transceiver 335 is connected to the antenna set 345, which may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability. The memory 325 includes RAM, ROM, ora combination of both. Alternatively, or additionally, the memory 225 may comprise a mass storage device, such as a disk, or an SSD. BIOS instructions may be stored within the memory 325 to support an operating system. The inter-station communication manager 365 manages the communications with other base stations. The inter-station communication manager 365 may provide a standardized Xn interface (e.g., as defined by the 3GPP standard), to support these communications. Figure 4 is a block schematic diagram illustrating the data plane protocol stack of a 5G NR systems as represented in Figure 1. The data plane protocol stack is described in detail in 3GPP document TS 23.501. In the downlink direction, an application server 103 connects to the user plane function (UPF) 161 through a data network 160 at the level of PDU layer 402. The PDU layer corresponds to the PDUs carried between the UE and the data network (DN) overthe PDU session. When the PDU session type is IPv4 or IPv6 or IPv4v6, the PDUs correspond to IPv4 packets, IPv6 packets, or both. When the PDU session type is Ethernet, the PDUs correspond to Ethernet frames; etc. At the start of a PDU session (i.e., at a PDU establishment time), the core network provides session QoS parameters to the UPF, gNB and UE. The PDU session QoS parameters includes the XR PDU set QoS parameters (S2-2302696): A. PDU Set delay budget (PSDB); B. PDU Set error rate (PSER); and C. PDU Set integrated handling indication (PSIHI), which is also previously known as a PDU Set integrated indication. In the description relating to Figure 4, unless stated otherwise, a PDU refers to a packet which is handled (e.g., managed or processed) by the PDU layer 402. The other types of PDU are handled by the other layers. Accordingly, the PDUs belonging to one of the other layers (i.e., other than the PDU layer 402) is referred to herein with the prefix corresponding to the respective layer name, e.g., a PDCP PDU, or MAC PDU. When the PDUs arrive at the UPF PDU layer 402, the UPF performs an application packet inspection to determine the PDU Set boundaries. For example, 3GPP document S2-2302696 provides examples on howto identify PDU Sets when inspecting RTP / SRTP header, RTP header extension, H.264 RTP payload, H.265 RTP payload and H.266 RTP payload. PDU Set identification information as described in 3GPP document S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification Information comprises: A. a PDU Set sequence number; B. an indication of the end PDU of the PDU Set; C. a PDU sequence number within a PDU Set; D. a PDU Set size; and E. a PDU Set importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow. During uplink the application is located on the UE. The UE obtains the PDU session QoS parameter from the core network when the PDU session is established (e.g., PDU session establishment procedure is defined in TS 23.502 clause 4.3.2.). When the PDU(s) generated by the application 403 arrive at UE PDU layer 402, the UE performs an application packet inspection to determine the PDU Set boundaries (similarto the procedure described above regarding the UPF). During both downlink and uplink, the application 103 sends and receives data to / from the NG-RAN through a GPRs tunnel (e.g., a GTP-U layer 404, as defined in TS 29.281). During downlink, the UPF detects the PDU Set identification information and obtains from the core network a set of mapping rules (e.g., filtering rules). The filtering rules define how each PDU Set is mapped to a QoS flow. The, or each, QoS flow is identified by an identifier, and the GTP-U PDUs are marked according to the determined QoS flow identifier. At the gNB, the relay layer 406 extracts PDU Set identification information and the QoS flow identifier from the GTP-U PDUs and maps them into the SDAP QoS flow(s). During an XR session, multiple PDU Sets can be mapped to the same QoS flow. Alternatively (or additionally), one or more PDU Sets may be mapped to different QoS flows. In a first alternative arrangement, each SDAP QoS flow can be mapped to a different PDCP Data Radio Bearer (DRB). According to a second alternative arrangement, all of the SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (as described in 3GPP document TR-38.835). During uplink, the UE detects the PDU Set identification information at the PDU layer 402 and obtains from the core network a set of mapping rules (e.g., filtering rules). The mapping rules define how each PDU Set is mapped to the QoS flow(s). The UE maps the XR PDUs to associated SDAP QoS flows according to the mapping rules. During uplink multiple PDU Sets can be mapped to the same, or different, QoS flow(s) in an XR session (e.g., a single XR session). During downlink the application layer 403 generates an application flow towards at least one UE (e.g., a single UE). The application flow may include at least one of a video flow and an audio flow. At the PDU layer 402 the application flow is arranged into one or more PDU Sets. In arrangements where the application flow comprises multiple PDU Sets, a plurality of PDU Sets may be arranged into a group of the same type, or of different types (e.g., based on the contents of the PDU Sets). Then, within the GTP-U layer 404, each PDU Set type is mapped onto the QoS flow(s), so multiple application flows can be multiplexed in a QoS flow (e.g., a single QOS flow). Alternatively, each application flow can be mapped to a different QoS flow. Further alternatively, it is also possible that an application flow is divided into multiple QoS flows. Then the SDAP layer 407 maps the QoS flows into DRBs, each DRB being handled (e.g., managed or processed) by a dedicated PDCP entity. As with the QoS flows, multiple application flows can be multiplexed in a single DRB. Alternatively, each application flow can be mapped to a different DRB. Further alternatively, it is also possible that an application flow (e.g., a single application flow) can be divided into multiple DRBs. During uplink, the application layer 403 generates at least one application flow towards the application server 103. For example, the application layer generates at least one of a video flow, an audio flow, and a sensing flow (e.g., a haptic flow). The application information may also comprise a plurality of at least one of the video, audio and sensing flows. At the PDU layer 402 the application flow is arranged into one or more PDU Sets. For example the application flow information may be divided into multiple PDU Sets (e.g., of the same or different types) and each PDU Set type is mapped on a QoS flow. In this way, multiple application flows can be multiplexed in one QoS flow. Alternatively, the application flow can be mapped to different QoS. In an example arrangement the application flow is divided into multiple QoS flows. Then the SDAP layer407 maps the QoS flows into DRBs. At least one, or each, radio bearer is handled (e.g., managed or processed) by a dedicated PDCP entity. As for the QoS flow, multiple application flows can be multiplexed in one DRB (e.g., a single DRB), or each application flow can be mapped to separate DRBs. Further alternatively, it is possible that an application flow (e.g., a single application flow) is divided into multiple DRBs. Subsequently, at least one, or each, DRB is mapped to at least one RLC channel which in turn is mapped to at least one MAC logical channel (LCH). The RLC protocol layer can operate in three modes: A transparent mode (TM) during which data is transmitted with no header or any protocol implementation; an unacknowledged mode (UM) which implements segmentation and duplication detection; and finally, an acknowledged mode (AM) which implements the same functions as the UM mode but with the addition of a retransmission mechanism (e.g., an automatic repeat request (ARQ)). Figure 5 is a flow chart showing an example of PDU Sets from different modalities being exchanged between a transmitter 520 and a receiver 522. The examples described herein refer to a single flow, which may be indicative of, and / or related to, a single modality. However, it will be understood that the present disclosure may also apply to situations where a plurality of flows / modalities are generated. In the example shown in Figure 5, four PDU Sets 501-504, are transmitted from the transmitter 520 to the receiver 522. PDU Sets 501-502 are part of a first flow 505 (e.g., relating to a first modality) and PDU Sets 503-504 are part of a second flow 506 (e.g., relating to a second modality which is different to the first modality). For example, the first flow 505 is a video modality and the second flow 506 is a haptic modality. The delay budget requirement applies to each individual flow. The delay budget requirement defines the maximum time allowed between the reception of two consecutive PDU Sets of an individual flow. This time is represented by intervals 510 and 517. Any PDU Set that arrives later than the allowed delay budget after the reception of a previous PDU Sets can be considered as outdated. Outdated PDUs can be discarded and not delivered to the application. According to known flow management methods (e.g. pdu-SetDiscard as defined in the PDCP-Config information element in TS38.331), outdated PDU Sets may be transmitted and then lost since they are not used by the application. To save radio resources, timers (e.g. the discardTimer as defined in TS 38.323) have been implemented at the transmitter side for detection of outdated PDU Sets prior to transmission so that they can be discarded at the transmitting side. A runtime congestion management procedure is also applied to PDU Sets of individual flows. According to known flow management methods (e.g. based on the the discardTimerForLowImportance as defined in the PDCP-Config information element in TS38.331), and depending on an activation (e.g. the gNB may send a MAC CE to activate the discard for low importance), the transmitter will manage a second timer (e.g. the discardTimerForLowImportance as defined in TS 38.323) for each low importance PDU Set. Once the timerelapses, PDUs or PDU Sets may be discarded depending on a predetermined configuration (e.g. according to the pdu-SetDiscard defined in the PDCP-Config information element in TS38.331). Some XR applications require that PDU Sets from different modalities are delivered to the application within a constrained time. For example, PDU Set 502 shall be delivered to the application no longer than the time interval 515 after PDU Set 502 has been delivered. For some applications the relationship between two modalities are not symmetrical. For example TS 22.847 defines the max delay from video reception to tactile reception as 15 ms, while the max delay from tactile reception to video reception as 50 ms. Consequently, in certain situations at the receiving side, if a PDU Set from a first flow arrives too late compared to the reception time of a PDU Set from a second flow, then both PDU Sets are obsolete and shall be rejected by the application. The inter-relationship between two modalities cannot be detected at transmitting side using timers applied to individual modalities (discardTimer or discardTimerForLowImportance), there is a need for a procedure at transmitting side that will allow to detect inter-dependency requirement violation by PDU Sets prior to their transmission, allowing the transmitter side to discard them and save valuable radio resources. Figure 6a is a flow chart illustrating the inter-dependency between two PDU sets in a multimodal application. In Figure 6a, the horizontal arrows 624, 625, 626, and 627 illustrate an amount of time separating the PDU Sets 601,602, 603, 604, 605, and 606. Three modalities are represented, namely: a first modality with PDU Sets oftype A601 (e.g., a haptic modality), a second modality with PDU Sets of type B 602, 603 (e.g., a video modality), a third modality with PDU Set oftype C 604, 605 (e.g., an audio modality). The inter-dependency between Modality A and B is expressed at the receiver as: 1. Following the reception of PDU Set B 603, the maximum delay to receive PDU Set A 601 is ba 624. According to TS 22.261 the typical value of ba 624 (e.g., haptic to video delay) is 50 ms; 2. Following the reception of PDU Set A 601, the maximum delay to receive PDU Set B 602 is ab 625. According to TS 22.261 the typical value of ab 605 (e.g., video to haptic delay) is 15 ms; 3. Following the reception of PDU Set C 604, the maximum delay to receive PDU Set A 601 is ca 626. According to TS 22.261 the typical value of ca 606 (e.g., haptic to audio delay) is 25 ms; and 4. Following the reception of PDU Set A 601, the maximum delay to receive PDU Set C 605 is ac 627 (e.g., audio to haptic delay). According to TS 22.261 the typical value of ac 607 is 50 ms Figure 6b is a flow chart illustrating a delay-based multimodal discard method at the transmitting side. The inter-dependency requirements between modalities shall be checked from the transmitting side in order to detect any requirement violation and thus being able to discard the PDU Sets before their transmission and thus save radio resources. As with Figure 6a, the horizontal arrows in Figure 6b represent the flow of time. The multimodal requirements are defined as illustrated in Figure 6a (e.g., which shows the behaviour of the transmitting side at the PDCP level). Firstly, a PDU Set of modality C 604 is received from an upper layer of the protocol stack (e.g., the SDAP layer or application layer). Subsequently, a PDU Set of modality A 601 is received from an upper layer. This is followed later by a PDU Set of modality B 602 which is also received from an upper layer. As each PDU of a PDU Set is delivered by the higher layer, a discard timer is initialised to a configured value and started. The value of the discard timer is the same for all PDUs and is configured by the gNB (e.g., the receiver). Preferably the configured value shall be function of the PDU Set delay budget, alternatively the configured value is a function of the PDU delay budget, yet alternatively for low importance PDU Sets, if congestion management is activated, the configured value shall be less than PDU Set and / or PDU delay budgets. Consequently, the discard timer associated with the first PDU of PDU Set C 604 will elapse at time 610, tiggering a delay-based discarding (for example, time 610 is equal to the time of arrival of PDU Set C at the transmitter plus the PDU Set delay budget PSDB). Similarly, the delay-based discarding of PDU Set A 601 will happen at time 611 and the delay-based discarding of PDU Set B 602 will happen at time 612. When the first PDU of PDU Set A 601 is received at the transmitter, processing of PDU Set C 604 has already been started (e.g., as indicated by diff_ca time 615). PDU Set C 604 will be discarded when the time reaches 610. Consequently, PDU Set A can be delivered to a lower layer no later than ca time value 606 after the last limit of validity of PDU Set C 604 at time 610. To trigger multimodal-based discarding of PDU Set A, a multimodal timer is started when the first PDU of PDU Set A 601 is received at the transmitter. The multimodal timer is initialised at discard timer value (for example PSDB) minus time difference of arrival time of the first PDU of PDU Sets A and C (i.e., diff_ca 615), plus the A to C delay requirement (i.e., ca 606). The multimodal timer of PDU Set A will elapse at time 613. Similarly, when the first PDU of PDU Set B 602 is received at the transmitter, PDU Set A 601 processing has already been started since diff_ab time 616. PDU Set A 601 will be discarded when time reaches 611 as part of delay-based discarding procedure, and also PDU Set A 601 will be discarded when time reaches 613 as part of multimodal-based discarding procedure, and since in this example time 613 will happen before time 611, PDU Set B shall be delivered to lower layer no later than ab 605 after the last limit of validity of PDU Set A 601 at 613. To trigger multimodal-based discarding of PDU Set B, a multimodal timer is started when the first PDU of PDU Set B 602 is received at the transmitter. The multimodal timer is initialised at initial multimodal timer value of PDU Set A 601, minus the difference between the arrival time of the first PDU of PDU Sets B and A (i.e., diff_ab 616), plus the B to A delay requirement (i.e., ab 605). The multimodal timer of PDU Set B will elapse at time 617. Generally, when a PDU of a PDU Set is received from an upper layer at the transmitting side, at least three possibilities of timer setting are implemented: 1. If there is no prior processing of PDUs of a PDU Set that is inter-dependent with the PDU Set to which the received PDU belongs, then following the delay-based timer setting, the multimodal timer is not started; 2. If there is one prior delay-based processing of a PDU Set that is inter-dependent with the PDU Set to which the received PDU belongs, then following the multimodal-based timer setting, the timer is set to a value dependent from the delay budget (PDU or PDU Set) and the inter-dependency requirement value. Optionally, following the delay-based timer setting as well; and 3. If there is at least one prior multimodal-based processing of a PDU Set that is interdependent with the PDU Set to which the received PDU belongs, then following the multimodal-based timer setting, the timer is set to a value dependent from the initial multimodal timer value of the prior PDU Set and the inter-dependency value. Optionally, following the delay-based timer setting as well. If there are multiple prior inter-dependent PDU Set use the initial multimodal timer value that leads to the earlier multimodal discard triggering. Figure 7 is a flow chart showing an example of packet level synchronization between a plurality of modalities (e.g., different modalities). According to this arrangement, if the delay requirement values of the first and second modalities are different, then the transmitter may be configured to dynamically provide information indicative of the inter-dependent PDU Set (e.g., the information may be provided for each PDU Set of the first modality). The passage of time is represented by the axis 701. Two modalities are illustrated, namely video 702 and haptic (or tactile) 703. On the video modality axis 702, video PDU sets 704-708 are represented as they are delivered to the application by the receiver over time. Similarly, on the haptic modality axis 703, haptic PDU sets 709-711 are represented as they are delivered to the application by the receiver during the same time period. Each PDU Set is represented with its sequence number one to five for video PDU Sets and five to seven for haptic PDU Sets. Packet level synchronization thresholds, or packet level inter-dependency requirements, enable the application to designate which PDU Sets are inter-related. In embodiments, the video PDU Sets are periodic (e.g., they are separated by a common time delay, whereas the haptic PDU sets are irregular (e.g., non-periodic). Considering Figure 7, video PDU Set one 704 is related to a haptic PDU Set five 709, video PDU Sets 705, 706 and 708 have no inter-relation requirements, and video PDU Set four 707, is related to haptic PDU set seven 711. For each PDU Set, the delay requirements can be different. For example, the time from haptic PDU Set five to video PDU Set one (i.e., “ba” 714) can be different from the time between haptic PDU Set seven and video PDU Set four (i.e., “ba” 716). For this reason, packet level synchronization shall be signalled dynamically for each PDU Sets. In embodiments, the two modalities 702 and 703 are part of a single PDU session. In which case, each modality may be mapped on a different QoS flow. Figure 8 is a flow chart showing an exchange sequence inside a UE for an uplink application (e.g., UE to core network) in the case of packet level synchronization. The UE 801 is split between the application 802 and the transmitter 803. The application generates PDU Sets of different modalities and inform dynamically the transmitter 803 of the inter-dependencies between PDU Sets of different modalities. Based on the knowledge of the inter-dependency information, the transmitter 803 optimises the transmission of the PDU Sets to the base station (e.g., by way of a discarding optimization or scheduling optimization process). The inter-dependency information is dynamically transmitted by the application 802 for each PDU Set. For a PDU Set that has a dependency to another PDU Set, the inter-dependency information 804, 806 is configured to include at least one of: 1. A flow id which identifies the flow of the dependent PDU Set. For example, Flow_id field of inter-dependency information 804 points to the flow identification of the PDU Set three 808. The Flowjd field of inter-dependency information 806 points to the flow identification of the PDU Set one 807. In embodiments Flow id represents the QFi (e.g., QoS flow index, TS 37.324), in an alternative embodiment, the Flow id represents the MMSid (e.g., Multi-modal service id, TS 23.501). Two inter-dependent PDU Sets may belong to the same Flow id. One PDU Set may depend on multiple PDU Sets, so Interdependency information is provided as a list with as many entries as there are dependent PDU Sets referenced thereto. 2. A sequence number, indicating the PDU Set sequence number of the dependent PDU Set. For example, Sequence_number field of inter-dependency information 804 points to the sequence number of the PDU Set three 808. The Sequence_number field of interdependency information 806 points to the sequence number of the PDU Set one 807. It will be understood that the PDU Sets of different modalities may be sequenced individually (i.e., each PDU Set modality having a separate number sequence) or collectively (i.e., two or more PDU Set modalities sharing the same number sequence); 3. An A2B delay value indicating the delay from the reception of the PDU set to the reception of the dependent PDU Set. For example, A2B field of inter-dependency information 804 indicates the maximum allowed delay from the reception of PDU Set one 807 to the reception of the PDU Set three 808. 4. A B2A delay value, indicating the delay from the reception of the dependent PDU Set to the reception of the PDU Set. For example, B2A field of inter-dependency information 804 indicates the maximum allowed delay from the reception of PDU Set three 808 to the reception of the PDU Set one 807. PDU Sets that have no dependency to another PDU Set are configured with an empty interdependency information field associated with message 805. Figure 9 is a flow chart showing an exchange sequence between the core network and the gNB for a downlink application (e.g., core network to UE) in the case of packet level synchronization. The core network generates PDU Sets of different modalities and inform dynamically the gNB 903 of the inter-dependencies between PDU Sets of different modalities. Based on the knowledge of the inter-dependency information, the gNB 903 optimises the transmission of the PDU Sets to the base station (e.g., by way of a discarding optimization or scheduling optimization process). The inter-dependency information is dynamically transmitted by the core network 902 for each PDU Set. For a PDU Set that has a dependency to another PDU Set, the inter-dependency information 904, 906 includes at least one of: 1. A flow id which identifies the flow of the dependent PDU Set. For example, Flow_id field of inter-dependency information 904 points to the flow identification of the PDU Set three 908. The Flowjd field of inter-dependency information 906 points to the flow identification of the PDU Set one 907. In embodiments Flow id represents the QFi (QoS flow index, TS 37.324), in an alternative embodiment Flow id represents the MMSid (Multi-modal service id, TS 23.501). Two inter-dependent PDU Sets may belong to the same Flow id. One PDU Set may depend on multiple PDU Sets, so Inter-dependency information is a list with as much entries as there are dependent PDU Sets referenced thereto. 2. A sequence number indicating the PDU Set sequence number of the dependent PDU set. For example, Sequence_number field of inter-dependency information 904 points to the sequence number of the PDU Set three 908. The Sequence_number field of interdependency information 806 points to the sequence number of the PDU Set one 907. 3. An A2B delay value, which indicates the delay from the reception of the PDU set to the reception of the dependent PDU Set. For example, A2B field of inter-dependency information 904 indicates the maximum allowed delay from the reception of PDU Set one 907 to the reception of the PDU Set three 908. 4. A B2A delay value, which indicates the delay from the reception of the dependent PDU set to the reception of the PDU Set. For example, B2A field of inter-dependency information 904 indicates the maximum allowed delay from the reception of PDU Set three 908 to the reception of the PDU Set one 907. PDU Sets that have no dependency to another PDU Set are configured with an empty interdependency information field associated with message 905. Each PDU Set, independently from the multi-modality, carries its own flow information (e.g., flow id and the sequence number), although this is not shown in Figure 9 for simplicity. Figure 10 is a flow chart showing an example of flow level synchronization between a plurality of modalities (e.g., different modalities). According to this arrangement, if the delay requirement values of the first and second modalities are the same, then the transmitter may be configured to provide information indicative of the inter-dependent PDU Set in a pre-determined, or regular (e.g., periodic) fashion. The time is represented in the axis 1001, two modalities are illustrated, including video 1002 and haptic (or tactile) 1003. Considering the video modality axis 1002, video PDU sets 1004-1009 are represented as they are delivered to the application by the receiver over time. Similarly, for the haptic modality axis 1003, haptic PDU Sets 1010-1012 are represented as they are delivered to the application by the receiver during the same time period. Each PDU Set is represented with a corresponding sequence number, one to six for the video PDU sets and one to three for the haptic PDU Sets. Flow level synchronization thresholds, or flow level inter-dependency requirements, enables the application to designate which flows are inter-dependent. Consequently, all PDU Sets of the inter dependent flows will be inter-dependent to each other. In the example shown in Figure 10, video flow 1002 is related to haptic flow 1003. Also, the video flow period is half the haptic flow period, so each haptic PDU Set PDU Set depends on two video PDU sets. Haptic PDU Set one 1010 depends on video PDU Sets one and two 1004, 1005, haptic PDU Set two 1011 depends on video PDU Sets three and four 1006, 1007 and so on. For all PDU sets, the delay requirements are the same. For example, the time from the haptic to the video (e.g., “ba” 1014) applies to all PDU Sets of the flow 1006,1011, and 1008,1012. For this reason, flow level synchronization may be signalled semi-statically for each flow (e.g., by using RRC protocol TS 38.331). In embodiments, the two modalities 1002 and 1003 are part of a single PDU session. In which case, each modality may be mapped on a different QoS flow. Figures 11 and 12 each describe an example arrangement in which the transmitter receives additional information from components of the wireless network, the information relating to the modality of the transmissible PDU Sets. Figure 11 is a flow chart showing an exchange sequence between a UE and the core network for an uplink application (e.g., UE to core network) in the case of flow level synchronization. The UE 1101 is split between the application 1102 and the transmitter 1103. The application 1102 generates PDU Sets of different modalities. Both the application 1102 and the core network 1104 can statically configure the inter-dependencies between the modalities generated by the UE in a semi-static manner. Based on the knowledge of the inter-dependency information, the transmitter 1103 optimises the transmission of the PDU Sets to the base station (e.g., via a discarding and / or scheduling optimization process). Firstly, through message 1105 the core network 1104 configures the identification of the modalities. For each modality an identifier is defined which enable the categorization of each incoming PDU Set to a modality. In embodiments each modality is identified by a different QFi (e.g., QoS flow index, TS 37.324). Alternatively, a dedicated modality identifier is used. Message 1105 can also be transmitted from the application 1102 to the transmitter 1103. Secondly, in message 1106 the application 1102 configures the dependency between two modalities at the flow level. Each modality is referred to by its identifier as configured earlier by message 1105. A2B and B2A gives the maximum delay allowed from the reception of one PDU Set of the first modality to the reception of a PDU Set from the second modality. The period defines at which periodicity this dependency is applied. For the example shown in Figure 10, the period is set to half. Message 1106 can also be transmitted from the core network 1104 to the transmitter 1103. Thirdly, with message 1107 the core network 1104 configures the starting point of the dependency. For example, the starting point defines a pair of sequence numbers pointing to the PDU Sets from the first and second flow that are inter-dependent. Starting from these two PDU sets, and knowing the dependency period, the transmitter is able to apply the inter-dependency requirements to all PDU Sets. Message 1107 can also be transmitted from the application 1102 to the transmitter 1103. Throughout the exchange sequence of Figure 12, there is no multimodality or interdependency information attached to each PDU Set 1108-1110. Rather, each PDU set carries its own flow information (e.g., flow id and the sequence number), independently from the multimodality process. This individual flow information is not shown in Figure 11 for simplicity. Together with the configured flow identification 1105, inter-dependency between configured flows 1106 and inter-dependency start indication 1107, knowing each PDU set own flow id and sequence number allows the transmitter 1103 to optimise the transmission of the PDU Sets to the base station (e.g., through a discarding optimization or scheduling optimization process). Figure 12 is a flow chart showing an exchange sequence between a gNB and the core network for a downlink application (e.g., core network to UE) in the case of flow level synchronization. The application 1202 resides in the UE 1201. The core network 1204 generates PDU Sets of different modalities. Both the application 1202 and the core network 1204 can statically configure the inter-dependencies between the modalities generated by the core network in a semistatic manner. Based on the knowledge of the inter-dependency information, the gNB 1203 optimises the transmission of the PDU Sets to the UE (e.g., via a discarding and / or scheduling optimization process). The exchange sequence starts with message 1205, buy which the core network 1204 is able to configure the identification of the different modalities. For each modality an identifier is defined, this identifier allows to categorize each incoming PDU Set to a modality. In embodiments each modality is identified by a different QFi (e.g., QoS flow index, TS 37.324). In an alternative embodiment a dedicated modality identifier is used. Message 1205 can also be transmitted from the application 1202 to the gNB 1203. By way of message 1206, the application 1202 configures the dependency between two modalities at the flow level. Each modality is referred to by its identifier as configured earlier by message 1205. A2B and B2A gives the maximum delay allowed from the reception of one PDU Set of one modality to the reception of a PDU Set from the second modality. Period defines at which periodicity this dependency is applied. For the example shown in Figure 10, the period is set to half. Message 1206 can also be transmitted from the core network 1204 to the gNB 1203. According to message 1207, the core network 1204 configures the starting point of the dependency. For example, the starting point defines a pair of sequence numbers pointing to the PDU Sets from the first and second flows that are inter-dependent. Starting from these two PDU sets, and knowing the dependency period, the transmitter can apply the inter-dependency requirements to all PDU Sets. Message 1207 can also be transmitted from the application 1202 to thegNB 1203. Throughout the exchange sequence of Figure 12, there is no multimodality or interdependency information attached to each of the PDU Sets 1208-1210. Independent from the multimodality process, each PDU set carries its own flow information, such as the flow id and the sequence number (not shown in Figure 12 for simplicity). Based on the flow identification 1205, the inter-dependency between configured flows 1206 and the inter-dependency start indication 1207 (and by knowing the flow id and sequence number of each PDU Set) allows the gNB 1203 to optimise the transmission of the PDU Sets to the base station (e.g., through a discarding and / or scheduling optimization process). According to some examples, MMSID communication is implemented from PCF to AMF, then from AMF to NGRAN as part of PCC rules applied to QoS flows participating to the same multi-modal application. In some examples, MMSID is provided to NGRAN as part of PDU session modification procedure SA2 did not specify how the MMSID can be sent to the UE. However, we think that for uplink applications, the MMSID shall be provided to the UE. In case UE side application layer does not provide the MMSID to the UE and since the network side will have the information anyway, we think that it is possible for the network to send the MMSID to the UE. In such examples, for uplink the NGRAN shall provide the MMSID to the UE Since the MMSID is provided to the NGRAN as part of the PDU session modification procedure, it is possible to consider sending the MMSID to the UE as part of the PDU session modification procedure. QoS flow binding to MMSID is not supposed to be dynamic, it is performed by the AF using the Nnef_AFsessionWithQoS service. Hence, semi static solution may be considered to communicate the MMSID to the UE. According to some examples it is not necessary to provide the MMSID to the UE dynamically. In such examples, as part of PDU session modification procedure, use semi-static signalling to provide the MMSID to the UE. Whilst the present disclosure has been described with reference to examples and embodiments, it is to be understood that the disclosure is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the disclosure, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. Unless otherwise defined herein, scientific and technical terms used in connection with the presently disclosed inventive concept(s) shall have the meanings that are commonly understood by those of ordinary skill in the art, and known techniques and procedures may be performed according to conventional methods well known in the art and as described in various general and more specific references that may be cited and discussed in the present specification. As used in this specification and claim(s), the words “comprising, “having,” “including,” or “containing” (and any forms thereof, such as “comprise” and “comprises,” “have” and “has,” “includes” and “include,” or “contains” and “contain,” respectively) are inclusive or open-ended and do not exclude additional, unrecited elements or method steps. The use of the term “a” or “an” in the claims and / or the specification may mean “one,” as well as “one or more,” “at least one,” and “one or more than one.” As such, the terms “a,” “an,” and “the,” as well as all singular terms, include plural referents unless the context clearly indicates otherwise. Likewise, plural terms shall include the singular unless otherwise required by context. The use of the term “or” in the present disclosure (including the claims) is used to mean an inclusive “and / or” unless explicitly indicated to refer to alternatives only or unless the alternatives are mutually exclusive. Unless otherwise explicitly stated as incompatible, or the physics or otherwise of the embodiments, examples, or claims prevent such a combination, the features of examples disclosed herein, and of the claims, may be integrated together in any suitable arrangement, especially ones where there is a beneficial effect in doing so. This is not limited to only any specified benefit, and instead may arise from an “ex post facto” benefit. This is to say that the combination of features is not limited by the described forms, particularly the form (e.g., numbering) of example(s), embodiment(s), or dependency of claim(s). In the preceding embodiments (i.e., example arrangements), the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. 5 Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fibre optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fibre optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be 10 understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, whilst discs reproduce data optically with lasers. Combinations of the 15 above should also be included within the scope of computer-readable media.

Claims

1. A method for managing the transmission of a multimodal data flow between a transmitter and a receiver of a wireless network, the method at the transmitter comprising:providing, for a first PDU of a first modality, information indicative of a second PDU of a second modality different to the first modality.

2. The method of claim 1, wherein the information is indicative of a link between first PDU and the second PDU.

3. The method of claim 1 or claim 2, wherein the information comprises a synchronization threshold.

4. The method of any one of claims 1 to 3, wherein the method comprises, upon receiving a PDU from a higher level of the protocol stack, starting a discard timer for triggering a delay-based discarding of the first PDU.

5. The method of claim 4, wherein an initial value of the discard timer is the same for each PDU of a PDU Set.

6. The method of claim 4 or claim 5, wherein the initial discard timer value is a function of a PDU delay budget of the first PDU, or a PDU Set delay budget of the PDU Set to which the first PDU budget belongs.

7. The method of claim 6, wherein the initial discard timer value is configured to be less thanthe PDU Set delay budget if a congestion management procedure is activated and / or if a PDU Set importance value of the PDU Set is below a threshold value.

8. The method of any one of claims 1 to 7, wherein the method comprises, upon receiving the first PDU, starting a multimodal timer for triggering a multimodal discarding of the first PDU.

9. The method of claim 8, wherein the multimodal timer is configured based on at least one of:a discard timer for triggering a delay-based discarding of the first PDU;the difference between the arrival times of the first PDU and the second PDU at the transmitter; anda delay requirement value.

10. The method of claim 9, wherein an initial value of the multimodal timer is calculated by subtracting the difference between the arrival times of the first and second PDUs from an initial value of the delay-based discard timer for the first PDU, and then adding the predetermined delay requirement value.

11. The method of any one of claims 8 to 10, wherein the multimodal timer is started based on a PDU delay budget of the first PDU; and the smallest delay requirement among other PDUs of different modalities which are linked to the PDU and not yet received by the transmitter.

12. The method of claim 8 or claim 9, wherein the multimodal timer is configured according to at least one of the following criteria:if, upon receiving the first PDU, there are no PDUs with a different modality which are linked to the first PDU, then the multimodal timer is not started;if, upon receiving the first PDU, a discard timer has already been started for a PDU of a different modality which is linked to the first PDU, then the initial multimodal timer value is calculated based on a PDU delay budget of the first PDU, or a PDU Set delay budget of the PDU Set to which the first PDU belongs, and a delay requirement value;if, upon receiving the first PDU, a discard timer has already been started for a PDU Set of a different modality which is linked to the first PDU, then the initial multimodal timer value for the first PDU is calculated based on the initial multimodal timer value of the previous PDU Set and a delay requirement value; andif, upon receiving the first PDU, a discard timer has already been started for a plurality of PDU Sets of different modalities which are linked to the first PDU, then the initial multimodal timer value for the first PDU is calculated based on the initial multimodal timer value of the previous PDU Sets that is determined to achieve the earliest multimodal discard triggering.

13. The method of any one of claims 8 to 12, wherein the delay requirement value is determined based on the modality type of at least one of the first and second PDUs.

14. The method of claim 13, wherein, if the delay requirement values of the first and second modalities are different, then the transmitter receives, for each PDU of the first modality, information indicative of the second modality.

15. The method of claim 13 or claim 14, wherein, if the delay requirement values of the first and second modalities are the same, then the transmitter receives information indicative of the second modality for only a single PDU of a plurality of PDUs of the first modality.

16. The method of any one of the preceding claims, wherein, if the first and second modalities form part of a single PDU session, then each modality is mapped on a different Quality of Service flow.

17. The method of any one of the preceding claims, wherein the information indicative of the second PDU comprises at least one of:an indication of the flow of the second PDU;a sequence number of the second PDU;a maximum allowable delay between the reception of the first PDU and the second PDU; anda maximum allowable delay between the reception of the second PDU and the first PDU.

18. The method of any one of the preceding claims, wherein each PDU is configured to provide an indication of the flow of the PDU and a sequence number of the PDU.

19. The method of any one of the preceding claims, wherein the transmitter receives information from a component of the wireless network indicating a link between PDUs of different modalities.

20. The method of claim 18, wherein the information indicating a link between PDUs of different modalities includes an identifier for categorizing an incoming PDU to a modality.

21. The method of any one of claims, wherein the transmitter receives information from a component of the wireless network which configures a dependency between two modalities at a flow level.

22. The method of claim 21, wherein the information defines a maximum delay period allowed from the reception of the second PDU of the second modality to the reception of a further PDU of the second modality.

23. The method of claim 21 or claim 22, wherein transmitter receives information from a component of the wireless network which configures a starting point for the dependency between two modalities.

24. The method of claim 23, wherein the information includes a pair of sequence numbers for a pair of linked PDUs of the first and second modalities.

25. The method of any one of the preceding claims, wherein the transmitter forms part of a UE of the wireless network, the method comprises:receiving information indicative of the second PDU from an application of the UE; and discarding the first PDU in dependence on the information received from the application.

26. The method of claim 25, wherein the transmitter receives further information indicative of the second modality from a core network component of the wireless network.

27. The method of any one of claims 1 to 24, wherein the transmitter forms part of a base station of the wireless network, the method comprises:receiving information indicative of the second PDU from a core network component of the wireless network; anddiscarding the first PDU in dependence on the information received from the core network component.

28. The method of claim 27, wherein the transmitter receives further information indicative of the second modality from an application of a UE of the wireless network.

29. The method of any one of the preceding claims, wherein the transmitter is configured to transmit information according to the Packet Data Convergence Protocol (PDCP), and / or the Radio Link Control (RLC) sublayers of the wireless network.

30. A communication network which comprises a transmitter configured to perform the method of any one of claims 1 to 29.

31. A computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to any one of claims 1 to 29.

32. A computer-readable medium carrying a computer program according to claim 31.

Images