A method and an apparatus for handling unmarked protocol data units

Abstract

A method for a sending apparatus comprises generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identifying PDU types that are not to be marked with PDU set information; defining an importance value for the identified PDU types; generating a mapping between the importance values and respective identified PDU types; signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and transmitting all the generated PDUs to the network. Embodiments concern also a method for receiving, and apparatuses for implementing the methods.

Description

A METHOD AND AN APPARATUS FOR HANDLING UNMARKEDPROTOCOL DATA UNITSTECHNICAL FIELD

[0001] The present invention relates unmarked protocol data units (PDU).BACKGROUND

[0002] Various Extended Reality and Media (XRM) services may be provided in modern communication networks, such as in 5G / NR (5thGeneration / New Radio) networks. One or more Real-Time Transport Protocol (RTP) streams may be established for delivering the services to an end-user, such as a User Equipment (UE).

[0003] The user data of the services is delivered in protocol data units (PDU), which are organized in PDU sets, defined more precisely in 3GPP TS 23.501. A PDU Set is composed of one or more PDUs carrying one unit of information generated at the application level (e.g. a frame or video slice for XRM Services), which are of same importance requirement at application layer. The actual transmission is performed as data bursts, which may comprise a set of multiple PDUs generated and sent by the application in a short period of time. A Data Burst can be composed by one or multiple PDU Sets.

[0004] The PDU Set marking is typically delivered in a RTP Header Extension (HE) along with an indication of the end of data burst (EDB).

[0005] Nevertheless, a sender entity, such as an application server or another user equipment, may not always mark the PDUs, whereupon their handling by a network becomes laborious.SUMMARY

[0006] Now, an improved method and technical equipment implementing the method have been invented, by which the above problems are alleviated. Various aspects include a method, an apparatus and a non-transitory computer readable medium comprising a computer program, or a signal stored therein, which are characterized by what is stated in the independent claims. Various details of the embodiments are disclosed in the dependent claims and in the corresponding images and description.

[0007] The scope of protection sought for various embodiments of the invention is set out by the independent claims. The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

[0008] According to a first aspect, there is provided a sending apparatus comprising means for generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; means for identifying PDU types that are not to be marked with PDU set information; means for defining an importance value for the identified PDU types; means for generating a mapping between the importance values and respective identified PDU types; means for signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and means for transmitting all the generated PDUs to the network.

[0009] A sending apparatus according to a second aspect comprises at least one processor and at least one memory, said at least one memory stored with computer program code thereon, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identifying PDU types that are not to be marked with PDU set information; defining an importance value for the identified PDU types; generating a mapping between the importance values and respective identified PDU types; signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and transmitting all the generated PDUs to the network.

[0010] A method for a sending apparatus according to a third aspect comprises generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identifying PDU types that are not to be marked with PDU set information; defining an importance value for the identified PDU types; generating a mapping between the importance values and respective identified PDU types; signaling the generated mapping to the network to be used by the network todetermine an importance value to be assigned to a PDU not being marked with the PDU set information; and transmitting all the generated PDUs to the network.

[0011] According to an embodiment, the identified PDU types comprise PDUs carrying specific network protocol data, for example RTP protocol data.

[0012] According to an embodiment, the identified PDU types comprise PDUs carrying non- video media data.

[0013] According to an embodiment, the identified PDU types comprise PDUs carrying non- video coding layer network abstraction layer (NAL) units.

[0014] According to an embodiment, a header extension is generated for a PDU set, said header extension only including the importance value and / or an indication for the end of data burst (EDB).

[0015] According to an embodiment, lower importance value is defined for the identified PDU types with higher importance.

[0016] According to an embodiment, low importance value is defined for a PDU set having a continuous segment of speech between silent intervals.

[0017] According to an embodiment, low importance value is defined for RTP PDU set used in packet loss reconstruction.

[0018] According to an embodiment, low importance value is defined for bitstream carrying rendering parameters for the audio data.

[0019] A receiving apparatus according to a fourth aspect comprises means for receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; means for receiving protocol data units for one or more media streams over a real-time transport protocol (RTP) session; means for determining which of the received PDUs are unmarked with a PDU set information; and means for using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

[0020] A receiving apparatus according a fifth aspect comprises at least one processor and at least one memory, said at least one memory stored with computer program code thereon, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol dataunit (PDU) types; receiving protocol data units for one or more media streams over a realtime transport protocol (RTP) session; determining which of the received PDUs are unmarked with a PDU set information; and using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

[0021] A method for a receiving apparatus according to a sixth aspect comprises receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; receiving protocol data units for one or more media streams over a real-time transport protocol (RTP) session; determining which of the received PDUs are unmarked with a PDU set information; and using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

[0022] Computer readable storage media according to further aspects comprise code for use by an apparatus, which when executed by a processor, causes the apparatus to perform the above methods.BRIEF DESCRIPTION OF THE DRAWINGS

[0023] For a more complete understanding of the example embodiments, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0024] Fig. 1 shows a schematic block diagram of an apparatus according to the embodiments;

[0025] Fig. 2 shows schematically a layout of an apparatus according to an example embodiment;

[0026] Fig. 3 shows a part of an exemplifying radio access network

[0027] Fig. 4 shows a simplified example of a 5G Service-Based architecture;

[0028] Fig. 5 shows a flow chart of a method for a sending apparatus; and

[0029] Fig. 6 shows a flow chart of a method for a receiving apparatus; andDETAILED DESCRIPTON OF SOME EXAMPLE EMBODIMENTS

[0030] The following describes in further detail suitable apparatus and possible mechanisms carrying out handling of unmarked (also referred to as “lonely”) protocol data units. While the following focuses on 5G networks, the embodiments as described beloware by no means limited to be implemented in said networks only, but they are applicable in any type of network.

[0031] In this regard, reference is first made to Figures 1 and 2, where Figure 1 shows a schematic block diagram of an apparatus or electronic device 50 according to an example, which may incorporate the arrangement according to the embodiments. Figure 2 shows a layout of an apparatus according to an example embodiment. The elements of Figures 1 and 2 will be explained next.

[0032] The electronic device 50 may for example be a mobile terminal or user equipment of a wireless communication system. The apparatus 50 may comprise a housing 30 for incorporating and protecting the device. The apparatus 50 further may comprise a display 32 and a keypad 34. Instead of the keypad, the user interface may be implemented as a virtual keyboard or data entry system as part of a touch- sensitive display.

[0033] The apparatus may comprise a microphone 36 or any suitable audio input which may be a digital or analogue signal input. The apparatus 50 may further comprise an audio output device, such as one or more of the following: an earpiece 38, speaker, or an analogue audio or digital audio output connection. The apparatus 50 may also comprise a battery 40 (or the device may be powered by any suitable mobile energy device such as solar cell, fuel cell or clockwork generator). The apparatus may further comprise a camera 42 capable of recording or capturing images and / or video. The apparatus 50 may further comprise an infrared port 41 for short range line of sight communication to other devices. In other embodiments the apparatus 50 may further comprise any suitable short-range communication solution such as for example a Bluetooth wireless connection or a USB / firewire wired connection.

[0034] The apparatus 50 may comprise a controller 56 or processor for controlling the apparatus 50. The controller 56 may be connected to memory 58 which may store both user data and instructions for implementation on the controller 56. The memory may be random access memory (RAM) and / or read only memory (ROM). The memory may store computer-readable, computer-executable software including instructions that, when executed, cause the controller / processor to perform various functions described herein. In some cases, the software may not be directly executable by the processor but may cause a computer (e.g., when compiled and executed) to perform functions described herein. Thecontroller 56 may further be connected to codec circuitry 54 suitable for carrying out coding and decoding of audio and / or video data or assisting in coding and decoding carried out by the controller.

[0035] The apparatus 50 may comprise radio interface circuitry 52 connected to the controller and suitable for generating wireless communication signals for example for communication with a cellular communications network, a wireless communications system or a wireless local area network. The apparatus 50 may further comprise an antenna 44 connected to the radio interface circuitry 52 for transmitting radio frequency signals generated at the radio interface circuitry 52 to other apparatus(es) and for receiving radio frequency signals from other apparatus(es).

[0036] As discussed in the background section, services in a network can be delivered by one or more RTP streams.

[0037] RTP is designed for end-to-end, real-time transport of media and provides facilities for jitter compensation and detection of packet loss and out-of-order delivery. The majority of the RTP implementations are built on top of the User Datagram Protocol (UDP). RTP is used by real-time multimedia applications and services such as voice over IP (Internet Protocol), WebRTC (Web Real-Time Communication) and Multimedia telephony over IP Multimedia Subsystem (IMS).

[0038] RTP is designed to carry different multimedia formats, which permit the transport of new formats without revising the RTP standard. To this end, the information required by a specific application of the protocol is not included in the generic RTP header.

[0039] Use of RTP in a particular application requires a profile and payload format specification. The profile defines the codecs used to encode the payload data and their mapping to payload format codes in the protocol field Payload Type (PT) of the RTP header. Dynamic payload types offer flexibility and extensibility, allowing applications to support a wide range of media formats and codecs without being constrained by the fixed set of standard payload types. Examples of RTP profdes are the “RTP profde for Audio and videoconferences with minimal control (RTP / AVP)” and “Extended RTP Profde for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP / AVPF)”. For a media format (e.g., a specific video coding format), an associated RTP payload format specifies how the media content (audio, video, or other data types) is formatted and representedwithin the RTP packet. Some examples are the RTP payload formats for the video coding standards H.264 / AVC (Advanced Video Coding) and H.265 / HEVC (High Efficiency Video Coding), respectively.

[0040] RTCP is a companion protocol to RTP providing statistics and control information for an RTP session. Its primary role is to provide feedback on the media QoS (Quality of Service) by periodically sending information such as packet loss, packet delay variation, etc. RTCP defines several message types. Those comprises e.g., Sender Reports, Receiver Reports (RR), Source Description (SDES), BYE and application- specific (APP) messages. The protocol is extensible; for example, the Extended Report (XR) packet type is defined, and the RTP / AVPF (Audio- Visual Profile with Feedback) profile defines the format of the low-delay RTCP feedback messages classified into three categories as: transport-layer feedback messages, payload specific feedback messages and application-layer feedback messages.

[0041] The Secure Real-time Transport Protocol (SRTP) is a profile for RTP intended to provide encryption, message authentication and integrity and replay attack protection to the RTP data. While RTP carries both the payload and header in clear text, SRTP encrypts the payload and exposes only the header to the network elements on the path.

[0042] RTP provides a capability to extend the RTP header by defining a header extension format along with rules for its use. The general mechanism for header extension offers the possibility to use a limited number of extensions in each RTP packet. Two variants of the extension format are defined: one-byte and two-byte headers. The one-byte header permits extension data lengths ranging from 1 to 16 bytes, while the two-byte header permits data lengths ranging from 0 to 255 bytes. The actual extensions used in an RTP session are signaled in the session setup using the Session Description Protocol (SDP).

[0043] SDP is a format for describing multimedia communication sessions for the purpose of announcement and negotiation. Its predominant use is in support of streaming media applications. SDP does not deliver any media streams itself but is used between endpoints for negotiation of network metrics, media types, bandwidth requirements and other associated properties. The set of properties and parameters is called a session profile. SDP is extensible for the support of new media types and formats. SDP is widely deployedin the industry and is used for session initialization by various other protocols such as SIP (Session Initiation Protocol) or WebRTC related session negotiation.

[0044] SDP describes a session as a group of fields in a text-based format, one field per line. The form of a field is as follows.<character>=< value> <CR> <LF> where <character> is a single case- sensitive character and <value> is structured text in a format that depends on the character. Values are typically UTF-8 (Unicode Transformation Format - 8 -bit) encoded. Whitespace is not allowed immediately to either side of the equal sign.

[0045] Session descriptions comprises a session description, a timing description, and a media description. Each description may contain multiple timing and media descriptions. Names are only unique within the associated syntactic construct.

[0046] Fields appear in the order shown below; optional fields are marked with an asterisk. v= (protocol version number, currently only 0) o= (originator and session identifier: username, id, version number, network address) s= (session name: mandatory with at least one UTF-8-encoded character) i=* (session title or short information) u=* (URI of description) e=* (zero or more email address with optional name of contacts) p=* (zero or more phone number with optional name of contacts) c=* (connection information — not required if included in all media) b=* (zero or more bandwidth information lines)

[0047] One or more Time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines)

[0048] Zero or more Media descriptions (each one starting by an "m=" line; see below)

[0049] Time description (mandatory) t= (time the session is active)r=* (zero or more repeat times)

[0050] Media description (optional) m= (media name and transport address) i=* (media title or information field) c=* (connection information — optional if included at session level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines — overriding the Session attribute lines)

[0051] Below is an example of a session description. This session is originated by the user "jdoe", at IPv4 address 198.51.100.1. Session’s name is "Call to John Smith" and session information ("SDP Offer #1") is included along with a link for additional information and an email address and phone number to contact the responsible party, Jane Doe.

[0052] The timing information indicates that the session duration is unspecified. Three media descriptions are provided, all using the RTP / AVP. The first is an audio stream on port 49170 using the payload type 0 (defined as PCMU (Pulse Code Modulation)), the second is another audio stream on port 49180 using again the payload type 0, the third is a video stream on port 51372 using the payload type 99 (defined as "dynamic"). Finally, an attribute is included which maps the payload type 99 to format 11263-1998 with a 90 kHz clock rate. RTCP ports of 49171, 49181, 51373 are implied by the defined ports for the media streams. v=0 o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 s=Call to John Smith i=SDP Offer #1 u=http : / / www .j doe .example . com / home .html e=Jane Doe <jane@jdoe.example.com> p=+l 617 555-6011 c=IN IP4 198.51.100.1 t=0 0 m=audio 49170 RTP / AVP 0m=audio 49180 RTP / AVP 0 m=video 51372 RTP / AVP 99 c=IN IP6 2001:db8::2 a=rtpmap:99 11263-1998 / 90000

[0053] SDP uses attributes to extend the core protocol. Attributes can appear within the Session or Media sections and are scoped accordingly as session-level or media-level. New attributes can be added to the standard through registration with IANA (Internet Assigned Numbers Authority). List of all registered attributes can be found from a web site: https: / / www.iana.Org / assignments / sdp-parameters / sdp-parameters.xhtml#sdp-att-field.

[0054] A media description may contain any number of "a=" lines (attribute-fields) that are media description specific. Session-level attributes convey additional information that applies to the session as a whole rather than to individual media descriptions.

[0055] Attributes are either properties or values: a=< attribute-name> a=< attribute-name> : <attribute-value>

[0056] Examples of attributes are “rtpmap” and “frntp”. The “rtpmap” attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. Up to one "a=rtpmap:" attribute can be defined for each media format specified. Thus, we might have the following: m=audio 49230 RTP / AVP 96 97 98 a=rtpmap:96 L8 / 8OOO a=rtpmap:97 L16 / 8000 a=rtpmap:98 L16 / 11025 / 2

[0057] In the example above, the media types are "audio / L8" and "audio / L16".

[0058] Parameters added to an "a=rtpmap:" attribute should only be those required for a session directory to make the choice of appropriate media to participate in a session. Codec-specific parameters should be added in other attributes, for example, "frntp".

[0059] "frntp" attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters, semicolon separated, maybe any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format. An example is: a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600

[0060] In the following, examples will be described with reference to an access architecture to which the embodiments may be applied, wherein the radio access architecture is based on Long Term Evolution Advanced (LTE Advanced, LTE-A) or new radio (NR, 5G), without restricting the embodiments to such an architecture, however. A person skilled in the art appreciates that the embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN or E- UTRAN), long term evolution (LTE, the same as E-UTRA), wireless local area network (WLAN or WiFi), worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet protocol multimedia subsystems (IMS) or any combination thereof.

[0061] Figure 3 shows a part of a radio access network according to an example. In particular, Figure 3 depicts examples of simplified system architectures only showing some elements and functional entities, all being logical units, whose implementation may differ from what is shown. The connections shown in Figure 3 are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the system typically comprises also other functions and structures than those shown in Figure 3. The embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties.

[0062] Figure 3 shows user devices 300 and 302 configured to be in a wireless connection on one or more communication channels in a cell with an access node (such as (e / g)NodeB) 304 providing the cell. The physical link from a user device 300, 302 to a (e / g)NodeB 304 is called uplink or reverse link and the physical link from the (e / g)NodeB304 to the user device 300, 302 is called downlink or forward link. It should be appreciated that (e / g)NodeBs or their functionalities may be implemented by using any node, host, server or access point etc. entity suitable for such a usage.

[0063] A communication system may comprise more than one (e / g)NodeB in which case the (e / g)NodeBs may also be configured to communicate with one another over links, wired or wireless, designed for the purpose. These links may be used for signaling purposes. The (e / g)NodeB is a computing device configured to control the radio resources of communication system it is coupled to. The NodeB may also be referred to as a base station, an access point or any other type of interfacing device including a relay station capable of operating in a wireless environment. The (e / g)NodeB includes or is coupled to transceivers. From the transceivers of the (e / g)NodeB, a connection is provided to an antenna unit that establishes bi-directional radio links to user devices. The antenna unit may comprise a plurality of antennas or antenna elements. The (e / g)NodeB is further connected to core network 310 (CN or next generation core NGC). Depending on the system, the counterpart on the CN side can be a serving gateway (S-GW, routing and forwarding user data packets), packet data network gateway (P-GW), for providing connectivity of user devices (UEs) to external packet data networks, or mobile management entity (MME), etc. The CN may comprise network entities or nodes that may be referred to management entities. Examples of the network entities comprise at least an Access and Mobility Management Function (AMF).

[0064] The user device 300, 302 (also called a user equipment (UE), a user terminal, a terminal device, a wireless device, a mobile station (MS) etc.) illustrates one type of an apparatus to which resources on the air interface are allocated and assigned, and thus any feature described herein with a user device may be implemented with a corresponding network apparatus, such as a relay node, an eNB, and an gNB. An example of such a relay node is a layer 3 relay (self-backhauling relay) towards the base station.

[0065] The user device 300, 302 may refer to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (mobile phone), smartphone, personal digital assistant (PDA), handset, device using a wireless modem (alarm or measurement device, etc.), laptop and / or touchscreen computer, tablet, game console, notebook, and multimedia device. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A user device 300, 302 may also be a device having capability to operate in Internet of Things (loT) network which is a scenario in which objects are provided with the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. Accordingly, the user device 300, 302 may be an loT-device. The user device 300, 302 may also utilize cloud. In some applications, a user device 300, 302 may comprise a small portable device with radio parts (such as a watch, earphones or eyeglasses) and the computation is carried out in the cloud. The user device (or in some embodiments a layer 3 relay node) is configured to perform one or more of user equipment functionalities. The user device 300, 302 may also be called a subscriber unit, mobile station, remote terminal, access terminal, user terminal or user equipment (UE) just to mention but a few names or apparatuses.

[0066] The communication system is also able to communicate with other networks, such as a public switched telephone network or the Internet 312, or utilize services provided by them. The communication network may also be able to support the usage of cloud services, for example at least part of core network operations may be carried out as a cloud service (this is depicted by “cloud” 314). The communication system may also comprise a central control entity, or a like, providing facilities for networks of different operators to cooperate for example in spectrum sharing.

[0067] It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be nonexistent. Some other technology advancements probably to be used are Big Data and all-IP, which may change the way networks are being constructed and managed. 5G (or new radio, NR) networks are being designed to support multiple hierarchies, where MEC (Multi-access Edge Computing) servers can be placed between the core and the base station or nodeB (gNB). It should be appreciated that MEC can be applied in 4G networks as well. The gNB is a next generation Node B (or, new Node B) supporting the 5G network (i.e., the NR).

[0068] 5G may also utilize non-terrestrial nodes 306, e.g. access nodes, to enhance or complement the coverage of 5G service, for example by providing backhauling, wireless access to wireless devices, service continuity for machine-to-machine (M2M) communication, service continuity for Internet of Things (loT) devices, service continuity for passengers on board of vehicles, ensuring service availability for critical communications and / or ensuring service availability for future railway / maritime / aeronautical communications. The non-terrestrial nodes 306 may have fixed positions with respect to the Earth surface or the non-terrestrial nodes 306 may be mobile non-terrestrial nodes that may move with respect to the Earth surface. The nonterrestrial nodes 306 may comprise satellites and / or HAPSs. Satellite communication may utilize geostationary earth orbit (GEO) satellite systems, but also low earth orbit (LEO) satellite systems, in particular mega-constellations (systems in which hundreds of (nano)satellites are deployed). Each satellite in the mega-constellation may cover several satellite-enabled network entities that create on-ground cells. The on-ground cells may be created through an on-ground relay node 304 or by a gNB located on-ground or in a satellite.

[0069] A person skilled in the art appreciates that the depicted system is only an example of a part of a radio access system and in practice, the system may comprise a plurality of (e / g)NodeBs, the user device may have an access to a plurality of radio cells and the system may comprise also other apparatuses, such as physical layer relay nodes or other network elements, etc. At least one of the (e / g)NodeBs or may be a Home(e / g)nodeB. Additionally, in a geographical area of a radio communication system a plurality of different kinds of radio cells as well as a plurality of radio cells may be provided. Radio cells may be macro cells (or umbrella cells) which are large cells, usually having a diameter of up to tens of kilometers, or smaller cells such as micro-, femto- or picocells. The (e / g)NodeBs of Figure 3 may provide any kind of these cells. A cellular radio system may be implemented as a multilayer network including several kinds of cells. Typically, in multilayer networks, one access node provides one kind of a cell or cells, and thus a plurality of (e / g)NodeBs are required to provide such a network structure.

[0070] Figure 4 illustrates a simplified example of a 5G Service-Based architecture (SB A) in particular. The user equipment 410 connects the 5G core network (5GC) 430through an access point 420. In 5GC 430 the architecture elements are defined in terms of Network Functions (NFs) rather than by “traditional” network entities, as done in the previous generations of cellular network standards. Through interfaces within a common framework, each NF offers its services to all the other authorized NFs and / or to any “consumers” eligible to utilize these services. This SB A approach offers modularity and reusability as key advantages. Functionalities of the NFs that are mainly relevant to the PDU Set framework are outlined below. The functionalities comprise User Plane Function (UPF), Access and Management Function (AMF), Network Data Analytics Function (NWDAF), Session Management Function (SMF), Policy Control Function (PCF) and Application Function (AF).

[0071] UPF forwards the traffic between the Radio Access Network (RAN) and the Data Network (DN) 440. In addition to IP packet forwarding, the UPF is responsible for policy enforcement, lawful intercept, traffic usage measurement and QoS policing. UPF is also responsible for tunnelling (i.e., encapsulating and decapsulating) packets as they are transmitted to and from base stations over the N3 interface.

[0072] AMF is responsible for connection and mobility management, access authorization and location services. AMF authorizes access when a user equipment 410 first connects to one of the local base stations 420 and then tracks which base station currently serves each user equipment 410.

[0073] NWDAF is used for data collection and analytics for centralized and edge computing resources.

[0074] SMF manages each UE session, including IP address allocation, control aspects of QoS and control aspects of user-plane routing.

[0075] PCF manages the policy rules and controls that the user data traffic does not exceed the negotiated bearer capacities.

[0076] AF exposes the application layer for interaction with 5G NFs and network resources. It allows NF service consumers to subscribe to periodic and / or event-driven notifications. UE application events exposed via AF include Quality of Experience (QoE) metrics, consumption reports and network assistance invocations. AF also provides PDU Set assistance information like the Protocol Description and PDU Set QoS parameters to PCF.

[0077] 5G mobile communications supports a wide range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications (such as (massive) machine-type communications (mMTC), including vehicular safety, different sensors and real-time control. 5G is expected to have multiple radio interfaces, namely below 6GHz, cmWave and mmWave, and also capable of being integrated with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words, 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as below 6GHz - cmWave, below 6GHz - cmWave - mmWave). One of the concepts considered to be used in 5G networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

[0078] The actual user and control data from network to the UEs is transmitted via downlink physical channels, which in 5G include Physical downlink control channel (PDCCH) which carries the necessary downlink control information (DCI), Physical Downlink Shared Channel (PDSCH), which carries the user data and system information for user, and Physical broadcast channel (PBCH), which carries the necessary system information to enable a UE to access the 5G network.

[0079] The user and control data from UE to the network is transmitted via uplink physical channels, which in 5G include Physical Uplink Control Channel (PUCCH), which is used for uplink control information including HARQ (Hybrid Automatic Repeat request) feedback acknowledgments, scheduling request, and downlink channel-state information for link adaptation, Physical Uplink Shared Channel (PUSCH), which is used for uplink data transmission, and Physical Random Access Channel (PRACH), which is used by the UE to request connection setup referred to as random access.

[0080] The user data is transmitted on the channels using Protocol Data Units (PDUs). For transmitting the user data, a logical connection between the user equipment 410 and a data network 440, referred to as a PDU session, needs to be established via a UPF of the5G core network 430. The PDU session may support transmitting user data on different types of services, such as voice, video, and data. The PDU session may comprise one or more Quality of Service (QoS) flows that differentiate traffic according to their QoS requirements. The user equipment 410 initiates the PDU Session Establishment process by sending a request to the 5G core network 430 the request indicating at least the type of the requested service and the type of requested traffic. The purpose of the PDU Session Establishment process in 5G / NR networks corresponds to that of PDN (Packet Data Network) connection procedure in 4G / LTE networks.

[0081] 3GPP SA2 FS_XRM Study resulting in TR 23.700-60 provides a study on the support of XR (Extended Reality) media (XRM) services, inter alia, by enhancing the 3GPP QoS framework to support PDU set granularity, where a PDU set consists of PDUs that have the same QoS requirements. The study outcomes resulted in enhancements of the 5G System architecture described in TS 23.501 to support PDU Set based handling in the Next Generation Radio Access Network (NG-RAN). The motivation behind and a summary of the PDU Set framework is summarized below.

[0082] Although 5G can support the requirements of basic XR applications as of 3GPP Release 17, advancements in different aspects have been found necessary to enable truly immersive experiences. 3GPP has recognized the need for a higher degree of application awareness in the network to enable more efficient resource allocation and scheduling. This requires a more tightly coupled interaction between the application layer and the network (5GC and RAN). One of the innovations to enable such interaction is the PDU Set framework introduced in Release 18.

[0083] A PDU Set is composed of one or more PDUs carrying one unit of information generated at the application level (e.g. a frame or video slice for XRM Services), which are of same importance requirement at application layer. All the PDUs of a PDU Set are transmitted within the same QoS flow of a PDU session. The QoS flow thus defines the transmission characteristics for a particular application or service, specifying parameters such as data rate, packet delay, packet loss, and priority.

[0084] To support PDU Set based QoS handling, the PDU Session Anchor (PSA) User Plane Function (UPF) identifies PDUs that belong to PDU Sets and determines the below PDU Set Information which it sends to the Next Generation Radio Access Network (NG-RAN) in the GPRS Tunnelling Protocol User Plane (GTP-U) header. The PDU Set information is used by the NG-RAN for PDU Set handling as described above. The PDU set information may be signalled in a header extension of an RTP packet (RTP HE). The PDU Set Information comprises:PDU Set Sequence Number.Indication of End PDU of the PDU SetPDU Sequence Number within a PDU SetPDU Set Size in bytes.PDU Set Importance, which identifies the importance of a PDU Set within a QoS Flow.

[0085] The required information for PDU Set handling is sent by the AF to the network. AF sends the Protocol Description and PDU Set QoS Parameters to the PCF which generates a Policy and charging control (PCC) rule containing the PDU Set QoS Parameters. At least one PDU Set QoS Parameter shall be sent to the NG-RAN to enable PDU Set based QoS handling. The following PDU Set QoS Parameters are specified in TS 23.501:PDU Set Delay Budget (PSDB): defines an upper bound for the delay that a PDU Set may experience for the transfer between the UE and the UPF, i.e., the duration between the reception time of the first PDU and the time when all PDUs of a PDU Set have been successfully received. PSDB applies to the downlink PDU Set received by the UPF and to the uplink PDU Set sent by the UE.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) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP). The purpose of the PSER is to allow for appropriate link layer protocol configurations (e.g., RLC and HARQ).PDU Set Integrated Handling Information (PSIHI): indicates whether all PDUs of the PDU Set are required in order to make the PDU Set useful to the application layer on the receiver side.

[0086] The Session Management Function (SMF) instructs the UPF to perform PDU Set marking and may provide the UPF with the Protocol Description indicating the header(e.g., RTP / SRTP) and payload type (e.g. H.264) used by the service data flow. For each downlink PDU received on N6 for which PDU Set based handling should be performed based on the instruction from the SMF, the PSA UPF applies the rules for PDU Set identification and provides the PDU Set Information to the RAN in the GTP-U header.

[0087] The Protocol Description may include the used transport protocol (e.g., RTP, SRTP), transport protocol header extensions (e.g., PDU Set RTP HE described below), payload type and format (e.g., H.264, H.265) used by the service data flow.

[0088] The Protocol Description indicates the transport protocol used by the service data flow (e.g. RTP, SRTP) and information, e.g. the following:• RTP or SRTP;• RTP or SRTP with RTP Header Extensions, including:• The RTP Header Extension for PDU Set Marking as defined in TS 26.522;• Other RTP Header Extensions;• RTP or SRTP without RTP Header Extensions, but together with RTP Payload Format (e.g. H.264 or H.265);• RTP or SRTP with RTP Header Extensions for PDU Set Marking as defined in TS 26.522, and together with RTP Payload Format (e.g. H.264 or H.265);• RTP or SRTP with other RTP Header Extensions following RFC 8285, and together with RTP Payload Format (e.g. H.264 or H.265).

[0089] Corresponding data type ProtocolDescription is defined in TS 29.571. An example usage of the Protocol Description is given below. In the example, an RTP stream is described, where the payload format is H.265, payload type=96 and the RTP header extension for PDU Set marking is used.

[0090] {"transportProto": "RTP", "rtpHeaderExtlnfo": {"rtpHeaderExtType":"PDU_SET_MARKING", "rtpHeaderExtld": 3], "rtpPayloadlnfoList":[{"rtpPayloadFormat": "H265", "rtpPayloadTypeList":

[0096] }] }

[0091] Having received the PCC rule from the PCF, the SMF determines a QoS profile and sends the Packet Detection Rule (PDR) with Protocol Description to the UPF. After the negotiation of media flows, the Application Server (AS) can add the PDU Set RTP HE to the packets of the corresponding RTP streams. The UPF may identify PDU Sets using the PDU Set HE or by other means (e.g. UPF implementation- specific). Subsequently, theUPF adds the PDU Set Information to the GTP-U header before providing it to the RAN which can then use it together with the PDU Set QoS parameters for QoS handling of PDU Sets.

[0092] The RAN can use the PDU Set Information in Radio Resource Management (RRM) schemes like scheduling of radio resources, discarding of PDU Sets delayed beyond their delay budget, etc. For example, the RAN can use PDU Set Importance (PSI) and PSIHI to discard PDU Sets in case of congestion, both in uplink and downlink. When PSIHI indicates that all PDUs of a PDU Set are needed for successful processing at the application and a PDU of a PDU Set is lost, the RAN can safely discard all remaining PDUs in the PDU Set to save radio resources. Moreover, the End of Data Burst indication provided in the PDU Set RTP HE can be used by the RAN to optimize the power saving features like Discontinuous Reception (DRX) and PDCCH monitoring adaptation schemes.

[0093] PDU Set RTP Header Extension

[0094] In real-time communication scenarios, media delivery networks may use the SRTP protocol which encrypts the media payload. Hence, the payload is not accessible by an on-path network node like UPF. However, the SRTP header may be transmitted in unencrypted form and visible to the network elements. Considering this fact, 3GPP developed a RTP header extension for PDU Set marking) [TS 26.522, clause 4.2] (hereafter referred to as “PDU Set RTP HE”) to facilitate the identification of the PDU Sets at the UPF. For each PDU Set, the application may derive the PDU Set Information from the application data (e.g., Network Abstraction Layer (NAL) units for coded video), populate the HE fields and add it to all PDUs of the PDU Set after successful SDP negotiation. The HE fields comprise all elements of the PDU Set Information, End of Data Burst indication [TS 23.501, clause 5.37.8.3] and other information that are deemed useful for the UPF operation (e.g. NPDS, see below).

[0095] Endpoints that support the PDU Set RTP HE shall support both RTP HE formats (i.e., the one-byte and the two-byte formats) described in RFC 8285. If the PDU Set RTP HE is the only RTP HE used in an RTP stream, the endpoints shall use the one-byte header format. If other two-byte RTP HE elements are used in the same RTP stream, then the two- byte header shall be used, unless the "a=extmap-allow-mixed" is successfully negotiated through SDP offer / answer, as described by RFC 8285.

[0096] One-byte format for the PDU Set RTP HE according to TS 26.522 is shown below.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| OxBE | OxDE | length || ID | len |E | R |D| PSI | PSSN | PSN || PSSize | NPDS |I

[0097] Two-byte format for the PDU Set RTP HE according to TS 26.522 is shown below.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| 0x100 | appbits | length || ID | len |E | R |D| PSI | PSSN| PSN | PSSize || NPDS |

[0098] The semantics of the fields of the PDU Set RTP HE is defined as follows:End PDU of the PDU Set [E]: This field is 1 bit in length, and is a flag that shall be set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.End of Data Burst [D]: The D field is 1 bit in length and indicates the last PDU of a Data Burst. A data burst is defined as a set of multiple PDUs generated and sent by theapplication such that there is an idle period between two data bursts. A Data Burst can be composed of one or multiple PDU Sets.Reserved [R]: The R field is 2 bits in length and reserved for future usage. It shall be set to 0 by the RTP sender and shall be ignored by other entities.PDU Set Importance [PSI]: The PSI field is 4 bits in length and it indicates the importance of this PDU Set compared to other PDU Sets within the same service flow. The field has a value between 0-15 (inclusive). High PSI values mean that the PDU Set has low importance for the media stream and vice versa.PDU Set Sequence Number [PSSN]: The PSSN field is 10 bits in length and encodes the sequence number of the PDU Set to which the current PDU belongs. This sequence number is the same for all PDUs belonging to a given PDU Set.PDU Sequence Number within a PDU Set [PSN]: The PSN field is 6 bits in length and indicates the sequence number of the current PDU within the PDU Set.PDU Set Size [PSSize]: The PSSize is 24 bits in length, and indicates the total size of all PDUs of the PDU Set to which this PDU belongs. The size is expressed in bytes. This field is optional and subject to an SDP signaling offer / answer negotiation, where the Application Server may indicate whether it will be able to provide the size of the PDU Set for that RTP stream. If not enabled, the field should not be present. If enabled, but the Application Server is not able to determine the PDU Set Size for a particular PDU Set, it should set the value to 0 in all PDUs of that PDU Set.Number of PDUs in the PDU Set [NPDS]: The NPDS is 16 bits in length, and indicates total number of PDUs belonging to the same PDU Set. The field is optional and subject to SDP negotiation. It is recommended to add this field when PSSize is present.

[0099] NPDS is expected to be used for the correction of the PSSize calculation at the UPF, in case a NAT46 / NAT64 correction has taken place, i.e., an on-path network element changes the packet type from IPv4 to IPv6, or vice versa, leading to a different IP header size than the one added by the AS.

[0100] TS 26.522, clause 4.2.6 provides guidelines for PDU Set marking by the application, for the derivation of PDU Set Importance and PDU Set Size. The guidelines describe the steps that an RTP sender can follow in determining the PSI and PSSize. In the same context, it has been agreed that the PSA (PDU Session Anchor) UPF marks, in thedownlink, each N6-unmarked PDU (also referred to as “lonely PDU”) with PDU Set Information into a PDU Set. If the PSA UPF receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification, then the PSA UPF still maps it to a PDU Set and determines the PDU Set Information. Consequently, the RAN applies the PDU Set QoS parameters also to the lonely PDUs. For example, the RAN applies the PDU Set Delay Budget (PSDB), which is assumed to be larger than the PDB, to a lonely PDU. This may translate to an unnecessarily long delay budget for lonely PDUs and may impact the scheduling of lonely PDUs, in case UPF assigns single PDUs into their own PDU Sets. They may get a lower scheduling priority due to the long delay budget, which may lead to late delivery of PDUs carrying certain protocol data or media types.

[0101] Currently, the PDU Set RTP HE can only be used for marking RTP packets. There is no existing mechanism to mark PDUs carrying different protocol data such as RTCP, STUN (Session Traversal Utilities for NAT), TURN (Traversal Using Relays around NAT), etc. Also, the sender may prefer not to mark RTP PDUs carrying certain media types due to overhead. For example, for audio and haptics, packet sizes are small such that the overhead of the PDU Set RTP HE may be considered by the sender to be too large relative to the actual payload. In both cases, this means that PDUs of such protocols will be assigned to a PDU Set by the UPF based on pre-configuration.

[0102] When such unmarked / lonely PDUs exist, the UPF is required to obtain the PDU Set Information by implementation- specific means and pass it to the RAN for PDU Set based handling. The UPF may be able to obtain some elements of the PDU Set Information (e.g. PSSN, PSN, End PDU) reliably based on the UPF implementation. However, this is not possible for PSI since the UPF has no way of assessing the importance of media content if the media stream is encrypted since it cannot inspect the media content. Even if the stream is unencrypted, the UPF has to parse the RTP payload and derive the PSI from the NAL unit header, which is computationally burdensome considering that the UPF operates under high load, processing data from several senders in parallel under tight latency constraints.

[0103] Currently, it is specified in TS 23.501 V18.5.0 that the UPF determines the PSI based on pre-configuration. However, this may not provide favourable results since the importance of different types of lonely PDUs (e.g. RTCP messages, audio, haptics) maydepend on the specific requirements of the application, and thus require applicationspecific configuration.

[0104] Additionally, it may not be possible for the UPF to detect the End of Data Burst (EDB) in a reliable manner, in case marked and unmarked / lonely PDUs are transmitted in a single transport flow (e.g. video PDUs are marked and audio PDUs are unmarked). If a data burst ends with a lonely PDU, the network would not receive any EDB marking from the sender, which would leave the detection of the end of burst entirely to the UPF.

[0105] The present embodiments provide a solution to improve the handling of lonely PDUs, i.e., PDUs that have not been marked by the sender (e.g. AS or UE) with the PDU Set Information before sending to the network.

[0106] Thus, the solution relates to a sender that based on application data and / or preference creates a mapping between a set of importance values, such as PSI values of 3GPP, and different types of PDUs. Such PDUs may comprise PDUs carrying specific network protocol data, such as non-RTP protocol data, and / or PDUs carrying non-video media such as audio or haptics data and / or PDUs carrying non-video coding layer network abstraction layer (NAL) units. The sender transmits the mapping to the network via control plane signaling. When PDU Set marking is not possible or not preferred by the application, the network can use this mapping to assign PSI to the lonely PDU Sets. This has the benefit that the network does not have to rely on UPF configuration to assign PSI and can make a more reliable decision based on the metadata provided by the application. Hence, the presented solution leads to improved PDU Set handling in the network.

[0107] The solution also relates to a modified version of a RTP header extension (HE) that is compact when compared to the PDU Set RTP HE defined in TS 26.522. The RTP HE according to present embodiments may complement the previous example or may be considered as a separate embodiment. The modified RTP HE contains fewer data fields than the PDU Set RTP HE defined in TS 26.522 and consumes less bandwidth. For simplicity the HE according to present embodiments are referred to as “compact HE”. The compact HE can be applied to PDUs carrying data of non-video media types (e.g. audio, haptics) which would likely be lonely / unmarked, if the sender chose to only mark the RTP PDUs that contain video data. The sender may decide to do so, if the sender considers the overhead of the original / full PDU Set HE (8 bytes including the optional fields) too largerelative to the actual payload for the relevant use cases (e.g. audio call, uplink transmission of haptics data). The compact HE solution achieves reduction of the bandwidth overhead caused by the original PDU Set RTP HE while ensuring that the critical elements of the PDU Set Information are conveyed to the network, particularly those that would be challenging or impossible to acquire by the network in a reliable manner. Hence, the solution enables effective PDU Set handling in the network with reduced bandwidth usage.

[0108] These two viewpoints relating to the present embodiments are discussed next in more detailed manner with examples.

[0109] As the first point, the sender is configured to define session-specific PSI values for all or some of the network protocols and media types carried by the PDUs in the session. The network protocols for which the PSI values are defined, are the ones that cannot be marked with the PDU Set information. These include non-RTP protocols, such as RTCP, STUN, TURN, etc. The media types that are not marked, and for which the PSI values are defined, may include non-video media types, such as audio and haptics.

[0110] For mapping the PSI values to different PDUs, the sender may associate the RTCP protocol with PSI=x, the STUN protocol with PSI=y and audio PDUs with PSI=z, where x, y, z are values between a PSI value range of 0-15. The lower PSI value the protocol / media type has been associated with, the higher importance it has. Such a mapping can be presented and / or stored in a data structure or in a table format. The sender is configured to send the mapping (PSI-to-protocol and / or PSI-to-media type) to the network via control plane signaling. For example, the AF may signal this information to the network as part of the PDU Set assistance information.

[0111] According to an embodiment, the selection of the PSI values can be performed as follows: assigning lower PSI values to the protocols that are critical for session establishment (e.g. STUN, TURN, DTES) relative to the other protocols used for other types of control signaling (e.g. RTCP).

[0112] According to an embodiment, the sender may map different RTCP message types to different PSI values based on their importance for the media session. E.g., RTCP sender / receiver reports may be mapped to PS 1=1 while RTCP XR (Extended Report) messages (if used) to PSI=15, in case RTP / AVPF profile is used that allows usage of RTCP XR messages. The sender may further differentiate between the PSI values assignedto different RTCP XR messages. The sender can signal, for example, the RTCP Control Packet Type (PT) (e.g., SR=200, RR=201, SDES=202 etc., as defined by IANA) of an RTCP packet and an associated PSI value to be used for such packets.

[0113] According to an embodiment, the sender may signal further information to distinguish different types of RTCP Control Packets. Examples relating to these may be the following:A sender signals for sender / receiver reports (PTs 200 and 201) a reception report count (RC) value and an associated PSI value. The PSI value can be defined for a specific RC or for a range of RC values.A sender signals for RTCP feedback messages (PTs 205 and 206 for Generic and Payload specific feedback respectively), a subtype (FMT value defined by IANA for RTPFB and PSFB) and an associated PSI value.

[0114] If concatenated RTCP reports are sent, the UPF can inspect all RTCP packets in the concatenated report and assign the lowest PSI to the first PDU. Alternatively, the sender can include the RTCP packet with the lowest PSI first in a concatenated packet and the UPF can check the PT and e.g., RC, subtype, etc. to determine the PSI for the PDU. If both operations are allowed by the network, then the sender can signal if it will always include the RTCP packet with lowest PSI first in a concatenated packet.

[0115] The PSI value can be assigned based on the RTP profile in use. For example, in case of the AVP profile, the regular SR and RR reports may be of high importance since there is no other mechanism for RTCP reporting. Also, the same channel may be used to convey RTCP APP feedback messages for rate adaptation in case of MTSI unidirectional audio delivery. The RTCP APP packets carry codec mode requests in case of rate adaptation or format change requests within MTSI.

[0116] In the previous embodiment, if the sender and receiver have negotiated the use of the RTP / AVPF profile successfully, the sender also takes into account the RTCP mode of operation while determining the PSI values for different RTCP message types. E.g., RTCP packets sent using the Early RTCP mode or Immediate Feedback mode (as defined in RFC 4585) may be assigned a lower PSI than those sent using the regular RTCP mode, in case they are considered more important for the media session by the sender. The same applies to RTCP NACK, PEI, SEI, and RPSI messages.

[0117] According to an embodiment, the PSI mapping between the different RTCP message types and / or RTCP messages using different mode of operation (e.g., early or immediate feedback versus regular feedback) is carried using RTCP APP packets.

[0118] According to an embodiment, an APP packet of custom type PDU set marking may be concatenated as the first packet for each RTCP message to carry the PDU set information in-band. The APP packet contains PDU set information including one or more of the fields defined in TS 26.522 for the PDU Set RTP HE. For RTCP Feedback messages, an RTCP Application Feedback (AFB) is used in the same way. The following embodiments are defined:- A PDU Set number that the RTCP packet belongs to such that i) the PDUs in that PDU Set are one or more RTCP packets or ii) the PDUs in the PDU Set are RTCP and RTP packets.- A PDU number that defines the order of the RTCP packet within the PDU Set in send order.- A PSI value in reference to other PDU sets in the QoS flow.

[0119] The UPF can check the RTCP APP / AFB packet of PDU Set marking type at the start of each RTCP packet to determine the PDU Set Information of the other RTCP packets being carried. The RTCP packet size should be within Maximum Transmission Unit (MTU) size to ensure no fragmentation.

[0120] As mentioned above, the unmarked PDUs might belong to audio or haptics streams, although those are carried over RTP and can in principle be marked using the PDU Set RTP HE. The reason for such PDUs being unmarked / lonely is different than the one described above for PDUs of non-RTP protocols (e.g. RTCP messages) since in this case the sender prefers not to mark the PDUs of non-video media types e.g. due to the large overhead of the PDU Set RTP HE defined in TS 26.522.

[0121] Apart from non-video PDUs, even some PDUs in video RTP streams may be unmarked. For example, the sender may prefer not to mark non-video coding layer (non- VCE) NAE units like parameters sets and supplemental enhancement information (SEI) messages. TS 26.522 recommends that these are handled together with the associated VCE NAE units as part of the same PDU Set by the network.

[0122] As the second point, the sender is configured to add a compact PDU Set HE to RTP PDUs carrying audio or haptics that are carried in low-bandwidth streams or to RTP PDUs carrying non-VCL video PDUs.

[0123] According to an embodiment, the compact HE may include one or more of the fields on the PDU Set HE defined in TS 26.522.

[0124] In particular, the compact HE includes only the PSI value for that PDU Set.

[0125] Alternatively, the compact HE includes PSI and an indication for the EDB. This could be used e.g., in case of multiplexed audio and video streams such that the sender can indicate the end of burst even if it corresponds to an audio or haptics packet.

[0126] According to an embodiment, the sender does not add any HE to the lonely PDUs but adds an EDB counter (e.g., in an optional HE field EDBCnt) to the PDU Set HE that is added to the video PDU Sets. This counter indicates the PDUs left until the end of burst (counting from the current PDU) and is set to a non-zero value only when the sender has detected that the end of burst has occurred in one of the unmarked streams. In this case, the sender sets EDB=1 and EDBCnt=x, where x is the difference between the packet number (in transmission order) of the current PDU and the lonely PDU in the unmarked stream that corresponds to the last PDU in the burst.

[0127] According to an embodiment, the sender marks the PDU Sets that start with non- VCL NAL units that are important for the bitstream with a lower PSI compared to scenarios where no non-VCL NAL units directly precede a VCL NAL unit. For example, if a NAL unit carrying a keyframe is preceded by parameters sets (e.g. SPS, PPS), the associated PDU Set is assigned a lower PSI than the PDU Sets that carry keyframes without preceding parameter sets.

[0128] According to an embodiment, the AF may set the PSDB based on the frame rate. A lower PSDB needs to be set when frame rates are higher.

[0129] The present embodiments are further discussed in view of audio.

[0130] In the traditional 3GPP speech codecs, e.g. Adaptive Multi-Rate - Wideband (AMR-WB), an RTP packet / PDU carries a single audio / speech frame. So, a speech frame can be a PDU Set comprising one PDU. In newer generation of 3GPP speech codecs Enhanced Voice Services (EVS) and Immersive Voice and Audio Services (IVAS), there can be multiple audio frames in one RTP packet. In case multiple audio frames are packedinto a single RTP packet / PDU, the RTP packet size may be greater than the MTU size. In this case there may be IP fragmentation.

[0131] Among all the speech frames, there can be some speech frames that are more important than others.

[0132] For example, frames with talkspurt are more important than others. A talkspurt is a continuous segment of speech between silent intervals. The RTP header marker bit (M) is set to 1 in the EVS RTP payload format [3GPP TS 26.445] and the IV AS RTP payload format [3GPP TS 26.253] if the first frame -block carried in the packet contains a speech frame which is the first in a talkspurt. In an embodiment, such talkspurt information can be used to determine the more important PDU Sets.

[0133] Also, different frames may be important for reconstruction or speech prediction in case of packet loss, for example, when machine learning based packet loss concealment (PLC) is implemented by the receiver UE. So, it can be useful to assign high importance (i.e., low PSI value) to the RTP packets that are important for packet loss reconstruction. Different encoders can choose different frames depending on their prediction model. In an embodiment, a range of PSI values is assigned to PDU Sets based on their importance for PLC. For example, PDU Sets that are more important for PLC may be assigned values from the lower end of the range.

[0134] In addition, in bitstreams coded using IVAS, there may be additional non-audio bitstream data which can be described as PI (Processing Information) data. This data can be of high importance because it defines the rendering parameters of the audio data (e.g., acoustic environment, audio source directivity), this data is important for the user experience, required for longer time than a frame duration and is non-trivial size of 40 bytes (but not required repeatedly). Such data is to be assigned with lower PSI values.

[0135] According to an embodiment, PSI is set considering all or some of the factors described above, i.e. the importance for PLC, presence of a talkspurt and importance for rendering (PI data).

[0136] When the receiver, such as an UPF, in a network receives signaling concerning the mapping between importance values and PDU types, the receiver is able to determine which of received PDUs are unmarked. Such PDUs are assigned the PSI values determined from the mapping.

[0137] Figure 5 illustrates a method for a sending apparatus according to an embodiment. The method generally comprises steps for generating 410 protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identifying 520 PDU types that are not to be marked with PDU set information (such PDU types includes PDU types that cannot be marked and also PDU types that are decided not to be marked); defining 530 an importance value for the identified PDU types; generating 540 a mapping between the importance values and respective identified PDU types; signaling 550 the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and transmitting 560 all the generated PDUs to the network. Each of the steps can be implemented by a respective module of a computer system.

[0138] Figure 6 illustrates a method for a receiving apparatus according to an embodiment. The method generally comprises steps for receiving 610 signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; receiving 620 protocol data units for one or more media streams over a real-time transport protocol (RTP) session; determining 630 which of the received PDUs are unmarked with a PDU set information; and using 640 the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs. Each of the steps can be implemented by a respective module of a computer system.

[0139] The method of Figure 5 is implemented by a sending apparatus comprising means for means for generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; means for identifying PDU types that are not to be marked with PDU set information; means for defining an importance value for the identified PDU types; means for generating a mapping between the importance values and respective identified PDU types; means for signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and means for transmitting all the generated PDUs to the network. The means discussed here may comprises at least one processor and at least one memory, said at least one memory stored with computer program code thereon, the at least one memory and thecomputer program code configured to, with the at least one processor, cause the apparatus at least to perform the method steps.

[0140] According to an embodiment, the identified PDU types comprise PDUs carrying specific network protocol data, such as non-RTP data.

[0141] According to an embodiment, the identified PDU types comprise PDUs carrying non- video media data.

[0142] According to an embodiment, the identified PDU types comprise PDUs carrying non- video coding layer network abstraction layer (NAL) units.

[0143] According to an embodiment, a header extension is generated for a PDU set, said header extension only including the importance value and / or an indication for the end of data burst (EDB).

[0144] According to an embodiment, lower importance value is defined for the identified PDU types with higher importance.

[0145] According to an embodiment, low importance value is defined for a PDU having a continuous segment of speech between silent intervals.

[0146] According to an embodiment, low importance value is defined for RTP PDUs used in packet loss reconstruction.

[0147] According to an embodiment, low importance value is defined for bitstream carrying rendering parameters for the audio data.

[0148] The method of Figure 6 is implemented by a receiving apparatus comprising means for receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; means for receiving protocol data units for one or more media streams over a real-time transport protocol (RTP) session; means for determining which of the received PDUs are unmarked with a PDU set information; and means for using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs. The means discussed here may comprise at least one processor and at least one memory, said at least one memory stored with computer program code thereon, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method steps.

[0149] Any of the sending or receiving apparatus may comprise e.g., the functional units disclosed in any of the Figures 1- 3 for implementing the embodiments.

[0150] A further aspect relates to a computer program product, stored on a non- transitory memory medium, comprising computer program code, which when executed by at least one processor, causes an apparatus at least to perform: generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identifying PDU types that are not to be marked with PDU Set information; defining an importance value for the identified PDU types; generating a mapping between the importance values and respective identified PDU types; signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU Set information; and transmitting all the generated PDUs to the network.

[0151] A yet further aspect relates to a computer program product, stored on a non- transitory memory medium, comprising computer program code, which when executed by at least one processor, causes an apparatus at least to perform: receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; receiving protocol data units for one or more media streams over a realtime transport protocol (RTP) session; determining which of the received PDUs are unmarked with a PDU Set information; and using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

[0152] In general, the various embodiments of the invention may be implemented in hardware or special purpose circuits or any combination thereof. While various aspects of the invention may be illustrated and described as block diagrams or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0153] Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting alogic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0154] Programs, such as those provided by Synopsys, Inc. of Mountain View, California and Cadence Design, of San Jose, California automatically route conductors and locate components on a semiconductor chip using well established rules of design as well as libraries of pre stored design modules. Once the design for a semiconductor circuit has been completed, the resultant design, in a standardized electronic format (e.g., Opus, GDSII, or the like) may be transmitted to a semiconductor fabrication facility or "fab" for fabrication.

[0155] The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of the exemplary embodiment of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended examples. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention.

Claims

WE CLAIM:

1. A sending apparatus comprising: means for generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; means for identifying PDU types that are not to be marked with PDU set information; means for defining an importance value for the identified PDU types; means for generating a mapping between the importance values and respective identified PDU types; means for signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and means for transmitting all the generated PDUs to the network.

2. The apparatus according to claim 1, wherein the identified PDU types comprise PDUs carrying specific network protocol data.

3. The apparatus according to claim 2, wherein the specific network protocol data is non-RTP protocol data.

4. The apparatus according to claim 1, wherein the identified PDU types comprise PDUs carrying non- video media data.

5. The apparatus according to claim 1, wherein the identified PDU types comprise PDUs carrying non- video coding layer network abstraction layer (NAL) units.

6. The apparatus according to any of the claim 2 to 5, further comprising means for generating a header extension for a PDU set, said header extension only including the importance value and / or an indication for the end of a data burst (EDB).

7. The apparatus according to any of the preceding claims 1 to 6, wherein the means for defining the importance value comprises defining lower importance value for the identified PDU types with higher importance.

8. The apparatus according to claim 7, comprising means for defining low importance value for a PDU set having a continuous segment of speech between silent intervals.

9. The apparatus according to claim 7, comprising means for defining low importance value for RTP PDU set used in packet loss reconstruction.

10. The apparatus according to claim 6, comprising means for defining low importance value for bitstream carrying rendering parameters for the audio data.

11. A receiving apparatus, comprising means for receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; means for receiving protocol data units for one or more media streams over a realtime transport protocol (RTP) session; means for determining which of the received PDUs are unmarked with a PDU set information; and means for using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

12. A method for a sending apparatus comprising: generating protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identifying PDU types that are not to be marked with PDU set information; defining an importance value for the identified PDU types; generating a mapping between the importance values and respective identified PDU types;signaling the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and transmitting all the generated PDUs to the network.

13. The method according to claim 11, wherein the identified PDU types comprise PDUs carrying specific network protocol data or PDUs carrying non- video media data or PDUs carrying non-video coding layer network abstraction layer (NAL) units.

14. The method according to claim 13, further comprising generating a header extension for a PDU set, said header extension only including the importance value and / or an indication for the end of data burst (EDB).

15. A method for receiving apparatus, comprising receiving signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; receiving protocol data units for one or more media streams over a real-time transport protocol (RTP) session; determining which of the received PDUs are unmarked with a PDU set information; and using the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

16. A sending apparatus comprising at least one processor and at least one memory, said at least one memory stored with computer program code thereon, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: generate protocol data units (PDUs) for one or more media streams to be transmitted to a receiver in a real-time transport protocol (RTP) session; identify PDU types that are not to be marked with PDU set information; define an importance value for the identified PDU types;generate a mapping between the importance values and respective identified PDU types; signal the generated mapping to the network to be used by the network to determine an importance value to be assigned to a PDU not being marked with the PDU set information; and transmit all the generated PDUs to the network.

17. A receiving apparatus comprising at least one processor and at least one memory, said at least one memory stored with computer program code thereon, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: receive signaling from a sender, said signaling relating to a mapping between importance values and protocol data unit (PDU) types; receive protocol data units for one or more media streams over a real-time transport protocol (RTP) session; determine which of the received PDUs are unmarked with a PDU set information; and use the mapping to determine an importance value corresponding to the PDU type of unmarked PDUs.

Images