WO2025233282A1

WO2025233282A1 - Methods, systems and devices for real-time transport protocol retransmission aware protocol data unit set handling

Info

Publication number: WO2025233282A1
Application number: PCT/EP2025/062224
Authority: WO
Inventors: Serhan GÜL; Saba AHSAN; Gazi Karam ILLAHI; Igor Danilo Diego Curcio
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-05-07
Filing date: 2025-05-05
Publication date: 2025-11-13
Anticipated expiration: 2026-11-07

Abstract

Methods, systems and devices for real-time transport protocol (RTP) retransmission aware protocol data unit set handling during RTP communication are provided A method includes performing PDU set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets and transmitting the RTP packets with at least the header extension to at least one RTP receiving device. The method further includes receiving a retransmission request from the at least one RTP receiving device and transmitting an RTP retransmission packet to the at least one RTP receiving device in response to receiving the retransmission request, the RTP retransmission packet comprising at least RTP retransmission information. The RTP retransmission information includes an RTP header extension, and the RTP header extension may include a retransmission packet flag and one or more PDU set handling parameters such as PSI, PSSN, PSN, PSSize, or NPDS.

Description

METHODS, SYSTEMS AND DEVICES FOR REAL-TIME TRANSPORT PROTOCOL RETRANSMISSION AWARE PROTOCOL DATA UNIT SET HANDLING

TECHNICAL FIELD

[0001] The present disclosure relates generally to Real-time Transport Protocol (RTP), and more particularly relates to methods, systems and devices for RTP retransmission aware protocol data unit (PDU) set handling.

BACKGROUND OF THE DISCLOSURE

[0002] RTP retransmission is a technique employed for media resilience in real-time communication scenarios and can be particularly useful in networks with low roundtrip time (RTT). However, RTP retransmission also poses a risk of increasing network congestion. To avoid network congestion, senders can determine the acceptable bit and packet rate according to a congestion control mechanism. Both the original and retransmitted data needs to be considered while calculating the acceptable bit rate. For example, senders may selectively retransmit only the packets that they deem important and ignore retransmission requests for other packets in order to limit the bit rate. Receivers may also be selective in sending NACK messages and may choose to not send a NACK for each dropped packet they detect.

[0003] Retransmission may be configured and negotiated end-to-end between the sender and receiver. However, the network, such as a 5G network, does not know whether and how RTP retransmission is to be performed.

[0004] Thus, there is a need for methods, systems and devices for RTP retransmission that overcomes the drawbacks of prior art approaches. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background.

SUMMARY

[0005] According an embodiment of the present disclosure, an apparatus for sending real-time transport protocol (RTP) packets during RTP communication is provided. The apparatus includes circuitry for sending the RTP packets to and receiving data from at least one RTP receiving device, at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to perform protocol data unit (PDU) set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets and provide the RTP packets with at least the header extension to the circuitry for sending to the at least one RTP receiving device. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to detect a retransmission request within the data received from the at least one receiving device and provide an RTP retransmission packet to the circuitry for sending to the at least one RTP receiving device when the retransmission request is detected, the RTP retransmission packet comprising at least RTP retransmission information.

[0006] According another embodiment of the present disclosure, an apparatus for receiving RTP packets during RTP communication is provided. The apparatus includes circuitry for receiving RTP packets from and sending data to an RTP sending device, at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to detect one or more unreceived RTP packets during an RTP communication session and provide a retransmission request to the circuitry for sending to the RTP sending device, the retransmission request including information indicating the one or more unreceived RTP packets. When the circuitry thereafter receives an RTP retransmission packet, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to derive at least RTP retransmission information from the RTP retransmission packet received.

[0007] In accordance with an additional embodiment of the present disclosure, a method for RTP communication is provided. The method includes performing protocol data unit (PDU) set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets and transmitting the RTP packets with at least the header extension to at least one RTP receiving device. The method further includes receiving a retransmission request from the at least one RTP receiving device and transmitting an RTP retransmission packet to the at least one RTP receiving device in response to receiving the retransmission request, the RTP retransmission packet comprising at least RTP retransmission information.

[0008] According to another embodiment of the present disclosure, another method for RTP communication is provided. The method includes detecting one or more unreceived RTP packets during an RTP communication session and transmitting a retransmission request to an RTP sending device, wherein the retransmission request includes information indicating the one or more unreceived RTP packets. When thereafter receiving an RTP retransmission packet, the method further includes deriving at least RTP retransmission information from the RTP retransmission packet received. [0009] In accordance with a further embodiment of the present disclosure, a system for RTP communication is provided. The system includes an RTP sending device and at least one RTP receiving device. The RTP sending device includes RTP sending device circuitry for sending RTP packets to and receiving data from the at least one RTP receiving device during an RTP communication session, at least one processor and at least one memory including computer program code. The at least one RTP receiving device includes RTP receiving device circuitry for receiving RTP packets from and sending data to the RTP sending device during the RTP communication session, at least one processor and at least one memory including computer program code. The at least one memory and the computer program code of the RTP sending device are configured to, with the at least one processor, cause the RTP sending device to perform protocol data unit (PDU) set marking for RTP packets during the RTP communication session by at least generating a header extension for the RTP packets and provide the RTP packets with at least the header extension to the RTP sending device circuitry for sending to the at least one RTP receiving device. The at least one memory and the computer program code of the at least one RTP receiving device are configured to, with the at least one processor, cause the at least one RTP receiving device to detect one or more unreceived RTP packets during the RTP communication session and provide a retransmission request to the RTP receiving device circuitry for sending to the RTP sending device, the retransmission request including information indicating the one or more unreceived RTP packets. The at least one memory and the computer program code of the RTP sending device are further configured to, with the at least one processor, cause the RTP sending device to detect the retransmission request within the data received from the at least one receiving device and provide an RTP retransmission packet to the sending device circuitry for sending to the at least one RTP receiving device when the retransmission request is detected, the RTP retransmission packet including at least RTP retransmission information. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to illustrate various embodiments and to explain various principles and advantages in accordance with such embodiments.

[0011] FIG. 1 depicts an illustration of real-time transport protocol (RTP) communication between two devices in a communication network in accordance with the present disclosure.

[0012] FIG. 2 depicts a diagram illustrating a format of a retransmission packet in accordance with the present disclosure.

[0013] FIG. 3 depicts a diagram illustrating a format of retransmission request in accordance with the present disclosure.

[0014] FIG. 4 depicts an example RTP communication session description in accordance with the present disclosure.

[0015] FIG. 5 depicts a diagram illustrating a one-byte RTP header extension format for PDU Set marking in accordance with the present disclosure.

[0016] FIG. 6 depicts a diagram illustrating a two-byte RTP header extension format for PDU Set marking in accordance with the present disclosure.

[0017] FIG. 7 depicts a call flow diagram of signaling PDU Set importance (PSI) threshold in accordance with the present disclosure.

[0018] FIG. 8 depicts a call flow diagram of signaling some additional information by the RTP sending device in accordance with the present disclosure. [0019] FIG. 9 depicts a diagram illustrating a first exemplary format of a compact PDU set RTP header extension in accordance with the present disclosure.

[0020] FIG. 10 depicts a diagram illustrating a second exemplary format of a compact PDU set RTP header extension in accordance with the present disclosure.

[0021] FIG. 11 depicts a diagram illustrating a third exemplary format of a compact PDU set RTP header extension in accordance with the present disclosure.

[0022] FIG. 12 depicts an example SDP description with S SRC -multiplexing in accordance with the present disclosure.

[0023] FIG. 13 depicts SDP description with session-multiplexing in accordance with the present disclosure.

[0024] FIG. 14 depicts a diagram illustrating a format of a full PDU Set RTP header extension in accordance with the present disclosure.

[0025] FIG. 15 depicts a flowchart illustrating an RTP communication session from the point of view of an RTP sending device in accordance with the present disclosure.

[0026] And FIG. 16 depicts a flowchart illustrating depicts a flowchart illustrating an RTP communication session from the point of view of an RTP receiving device in accordance with the present disclosure.

[0027] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity.

DETAILED DESCRIPTION

[0028] The following detailed description is merely exemplary in nature and is not intended to limit the present disclosure or its application and uses. Furthermore, there is no intention to be bound by any theory presented in the preceding background or the following detailed description. It is the intent of the present disclosure to present novel methods, systems and devices for real-time transport protocol (RTP) retransmission aware protocol data unit (PDU) set handling. In accordance with the present disclosure, network-efficient, media-resilient RTP retransmission includes signaling of information prior to and during RTP retransmission to aid a receiver of RTP packets to make improved decisions on whether to request RTP retransmission and to enable the network to increase network awareness of the use of RTP retransmission thereby improving network handling of RTP communication.

[0029] Real-time Transport Protocol (RTP) (e.g., RFC3550) is designed for end-to- end, real-time transport of media in RTP packets 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). Presently, RTP is used by real-time multimedia applications and services such as voice over IP, WebRTC and Multimedia telephony over IP Multimedia Subsystem (IMS), such as described in the technical specifications (TS) at 3GPP TS 26.114.

[0030] RTP is designed to carry a multitude of multimedia formats which permit the transport of new formats without revising the RTP standard. Accordingly, the information required by a specific application of the protocol may not be included in the generic RTP header.

[0031] 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 a fixed set of standard payload types. Some examples of RTP profiles include “RTP profile for Audio and video conferences with minimal control (RTP/AVP)” [RFC 3551] and “Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)” [RFC 4585],

[0032] 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 represented within the RTP packet. Some examples include the RTP payload formats for the video coding standards H.264/AVC and H.265/HEVC.

[0033] The RTP Control Protocol (RTCP) is a companion protocol to RTP providing statistics and control information for an RTP session. A primary role of RTCP is to provide feedback on media Quality of Service (QoS) by periodically sending information such as packet loss and packet delay variation. RTCP defines several message types. Some examples of message types are specified in RFC 3550 such as Sender Reports, Receiver Reports (RR), Source Description (SDES), BYE and application-specific (APP) messages. The protocol is extensible. For example, RFC 3611 defines an Extended Report (XR) packet type, and the RTP/AVPF profile defines a format of low-delay RTCP feedback messages classified into three categories: transport-layer feedback messages, payload specific feedback messages and application-layer feedback messages.

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

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

[0036] Media resilience techniques play a crucial role in ensuring reliable and high- quality delivery of real-time multimedia streams, even in challenging network conditions. Commonly used approaches include forward error correction (FEC), packet loss concealment (PLC) and selective retransmission.

[0037] FEC is a proactive technique where redundant information is added to the media stream to enable the receiver to recover lost or corrupted packets without the need for retransmissions. FEC can mitigate the impact of packet loss by providing additional parity packets, allowing receivers to reconstruct missing data.

[0038] PLC is particularly useful for audio where the decoder can try to predict what the lost frame sounds like and may conceal even high amounts of packet loss. For video, however, PLC is more complex due to the complexity of video signals and chains of dependencies between the video frames. In scenarios where packet loss cannot be adequately addressed by FEC and PLC, selective retransmission can be used at the expense of increased end-to-end latency.

[0039] The RTP retransmission payload format (i.e., RFC 4588) is designed for use with the RTP/AVPF profile. Retransmission packets carry copies of lost packets along with sequence numbers and timestamps to facilitate accurate reconstruction by a receiving device. The timing and frequency of retransmission packets are typically controlled by a sending device based on network conditions and feedback from the receiving device. This allows a trade-off between reliability and delay — the endpoint may give up on retransmitting after a given buffering time.

[0040] In accordance with the present disclosure, an exemplary system 100 for RTP communication between devices 110, 120 is depicted in FIG. 1. During an RTP communication session, unreceived RTP packets can be retransmitted. RTP retransmission can be selective, meaning that only specific unreceived packets are retransmitted, rather than entire data blocks. This selective approach minimizes the overhead associated with retransmissions, as only the necessary packets are retransmitted. AN RTP communication session via a network 130 occurs when either the first device 110 or the second device 120 is streaming media in RTP packets to at least the other device. For example, if the first device 110 is acting as a sending device, RTP packets are provided from the along a communication path 140a, 140b to the second device 120 as a receiving device. While not shown, there can be multiple receiving devices that receive the RTP packets.

[0041] When the receiving device (e.g., the second device 120) determines that an RTP packet has not been received, the receiving device may send a retransmission request via a communication path 150a, 150b to the sending device to trigger retransmission of the missing RTP packet. Senders are not required to retransmit and exact copy of the lost source packet. For example, the sending device may retransmit the same encoded data at a lower rate to avoid overlading the network. However, the sending device must ensure that the receiving device will still be able to decode the retransmitted payload. The sending device can also determine an acceptable bit and packet rate according to a congestion control mechanism such as the congestion control mechanism defined in the RTP/AVPF profile. Also, TS 26.114 recommends senders to retransmit packet that they deem beneficial for timely recovery. In accordance with the present disclosure, various methods and processes enable network-efficient, media- resilient RTP retransmission such as examples described hereinbelow to aid the receiving device to make improved decisions on whether to request RTP retransmission and/or to increase network awareness of the use of RTP retransmission. For example, an RTP retransmission packet in accordance with the present disclosure may include RTP retransmission information.

[0042] Referring to FIG. 2, a diagram 200 depicts a format of a retransmission packet 205 in accordance with the present disclosure. The retransmission packet includes an RTP header 210 and the RTP packet payload 220. An Original Sequence Number (OSN) 225 (i.e., the sequence number of the source RTP packet), is inserted into the first two octets of the RTP payload 220 as the payload header. The remaining RTP payload 220 is identical to the original RTP packet payload 228 that was not received (i.e., the source RTP packet).

[0043] The receiving device decides whether to request a retransmission or not. For example, the receiving device can decide whether to request retransmission depending on a tolerable application delay, depending on network conditions, and/or depending on a media type of the media being received in the RTP communication session. A retransmission request may be sent in a RTCP NACK feedback message format defined in the RTP/AVPF profile. Before sending a retransmission request, the receiving device should detect that the previous retransmission failed (e.g., based on an RTT estimate). NACKs can be sent in regular compound RTCP packets or early RTCP packets (as per AVPF). The latter allows reacting early to packet loss; however, the receiving device may have to wait for a next RTCP compound packet if a new packet loss occurs after sending the earlier RTCP packet. [0044] Format of an example of a retransmission request 310, such as a NACK message, is shown in a diagram 300 in FIG. 3. The retransmission request 310 includes fields to identify unreceived packet(s). For example, a first field 320 may include a packet ID (PID) field and a second field 330 may include a bitmask of following lost packets (BLP) field. The PID field will include data which refers to the RTP sequence number of the lost packet. The BLP field allows for reporting losses of any of the sixteen RTP packets immediately following the RTP packet indicated by the PID.

[0045] RFC 4588 defines the following MIME types for retransmission data with different media type, such as application/rtx, audio/rtx, video/rtx, text/rtx. The SDP attribute fmtp for a retransmission stream is defined as follows: a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val> (1) where <number> represents a payload type of the retransmission stream, <apt-value> represents an original stream payload type, and <rtx-time-val> represents a time in milliseconds (measured from the time a packet was first sent) that a sender keeps an RTP packet in its buffers available for retransmission. If this parameter is absent, the maximum retransmission time is undefined and but may be negotiated by other means. TS 26.114 recommends that the minimum “rtx-time” value should be RTT and the maximum value should be 400ms.

[0046] According to RFC 4588, the original and retransmission packets may be sent in two separate streams. For example, the two separate streams may be multiplexed by sending the stream in two different sessions (i.e., session-multiplexing). In this case, the original and retransmission streams are sent to different network addresses and/or port numbers. Alternatively, the two separate streams are sent in the same session using different SSRC values (i.e., SSRC -multiplexing) which allows minimizing the port usage since a same port can be used for both streams. [0047] S SRC -multiplexing is the mode generally supported in Multimedia telephony over IP Multimedia Subsystem (MTSI). Clause 7.4.6 of TS 26.114 states: “If support for RTP retransmission payload format has been negotiated, the receivers shall support handling of RTP retransmission packets defined in RFC 4588 sent using SSRC multiplexing. Similarly, senders shall use RTP retransmission packets defined in RFC 4588 for packets it retransmits using SSRC multiplexing.” WebRTC requires the receivers to implement support for RTP retransmissions using SSRC multiplexing and leaves the support of session-multiplexing optional (e.g., RFC8834)

[0048] Session Description Protocol (SDP) is a format for describing multimedia communication sessions for the purpose of announcement and negotiation. A predominant use of SDP 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 and SDP is extensible for the support of new media types and formats. SDP is widely deployed in the industry and may be used for session initialization by various other protocols such as SIP or WebRTC related session negotiation.

[0049] SDP describes a session as a group of fields in a text-based format, one field per line. The form of each field is as follows:

<character>=<value><CR><LF> (2) 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 encoded and whitespace is not allowed immediately to either side of the equal sign.

[0050] Session descriptions consist of three sections: session (e.g., Table 1), timing (e.g., Table 2), and media (e.g., Table 3) descriptions. Each description may contain multiple timing and media descriptions. Names may only be unique within an associated syntactic construct. Optional fields are marked with an asterisk and the fields must appear in the order shown in Tables 1 to 3 below.

Table 1 - Session Description (mandatory)

Table 2 - Time Description (mandatory)

Table 3 - Media Description (optional)

[0051] An example session description 400 from RFC 8866 is presented in FIG. 4. This example session is originated by a user "j doe", at IPv4 address 198.51.100.1. The session name is "Call to John Smith" and the 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 in unspecified. Three media descriptions are provided, all using the RTP Audio/Video Profile (A VP). The first media description is an audio stream on port 49170 using the payload type 0 (defined by RFC 3551 as PCMU), the second media description is another audio stream on port 49180 again using the payload type 0, and the third media description 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 h263-1998 with a 90 kHz clock rate. The RTCP ports of 49171, 49181, 51373 are implied by the defined ports for the media streams.

[0053] SDP uses attributes to extend the core protocol. Attributes can appear within the Session section or the Media section and are scoped accordingly as session-level or media-level. New attributes can be added to the standard through registration with I ANA. A list of all registered attributes can be found at https://www.iana.0rg/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-att-f1eld. [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. Attributes are either properties or values: a=<attribute-name> (3) a=<attribute-name> : <attribute-value> (4)

[0055] Examples of attributes defined in RFC8866 are “rtpmap” and “fmtp”. 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, an example “rtpmap” attribute may appear as shown in Table 4.

Table 4 - Example “rtpmap” Attribute

In the example in Table 4 above, the media types are "audio/L8" and "audio/L16".

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

[0057] A "fmtp" 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 may be one of the formats specified for the media. Format-specific parameters, semicolon separated, may be 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 (5)

[0058] The 5G core network (5GC) relies on a Service-Based Architecture (SBA) framework, where the architecture elements are defined in terms of Network Functions (NFs) rather than by “traditional” network entities, as done in 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 SBA approach offers modularity and reusability as key advantages. Functionalities of the NFs that are mainly relevant to the PDU Set framework utilized by the methods and devices in accordance with the present disclosure includes the User Plane Function (UPF), the Access and Management Function (AMF), the Session Management Function (SMF), the Policy Control Function (PCF), and the Application Function (AF).

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

[0060] The Access and Management Function (AMF) is responsible for connection and mobility management, access authorization and location services. The AMF authorizes access when a UE first connects to one of the local base stations and then tracks which base station currently serves each UE.

[0061] The Session Management Function (SMF) manages each UE session, including IP address allocation, control aspects of QoS and control aspects of user-plane routing.

[0062] The Policy Control Function (PCF) manages the policy rules and controls so that the user data traffic does not exceed the negotiated bearer capacities.

[0063] The Application Function (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. The AF also provides PDU Set assistance information like the Protocol Description and PDU Set QoS parameters to PCF. [0064] Although 5G can support the requirements of basic XR applications as of the 3 GPP 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.

[0065] A PDU Set is defined in 3GPP [TS 23.501] as follows: one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., frame(s), video slice(s) or similar parcels of data for XR Services). All the PDUs of a PDU Set are transmitted within the same QoS flow. A QoS flow is a logical connection between the UE and the data network that defines the transmission characteristics for a particular application or service, specifying parameters such as data rate, packet delay, packet loss, and priority.

[0066] The developed PDU Set framework allows the RAN to perform PDU Set based QoS handling on the PDU Sets identified by the UPF using the PDU Set Information determined by the UPF. The PDU Set Information includes a PDU Set Sequence Number, an indication of End PDU of the PDU Set, a PDU Sequence Number within a PDU Set, a PDU Set Size in bytes, and a PDU Set Importance (which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow). [0067] The required information for PDU Set handling is sent by the AF to the network. The 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. Specified PDU Set QoS Parameters include a PDU Set Delay Budget (PSDB), a PDU Set Error Rate (PSER) and a PDU Set Integrated Handling Information (PSIHI).

[0068] The 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. The PSDB applies to the downlink PDU Set received by the UPF and to the uplink PDU Set sent by the UE.

[0069] The PDU Set Error Rate (PSER) defines an upper bound for the rate of PDU Sets that have been processed by the sender of a link layer protocol (e.g., RLC) 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).

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

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

[0072] 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 the PDU Sets using the PDU Set HE or by other means, such as UPF implementation-specific means. Subsequently, the UPF 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.

[0073] The RAN can use the PDU Set Information in Radio Resource Management (RRM) schemes like scheduling of radio resources or discarding of PDU Sets delayed beyond their delay budget. For example, the RAN can use PSI and PSIHI to discard PDU Sets in case of congestion, both in uplink and downlink. When the 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 power saving features like Discontinuous Reception (DRX) and PDCCH monitoring adaptation schemes.

[0074] In real-time communication scenarios, media delivery networks typically use the SRTP protocol which encrypts the media payload. Hence, the payload is not accessible by an on-path network node like UPF. On the other hand, a SRTP header is typically transmitted in unencrypted form and visible to the network elements. Considering this fact, 3GPP developed an 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 a 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 the HE fields to all PDUs of a PDU Set after successful SDP negotiation. The HE fields comprise the PDU Set Information, an 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 as discussed hereinbelow). [0075] Endpoints that support the PDU Set RTP HE may also support both RTP HE formats (i.e., the one-byte format and the two-byte format) according to RFC 8285. If the PDU Set RTP HE is the only RTP HE used, the endpoints 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 is used, unless the "a=extmap-allow-mixed" is successfully negotiated through SDP offer/answer, as described by RFC 8285.

[0076] Referring to FIG. 5, a diagram 500 illustrates a format of a one-byte PDU Set RTP header extension for PDU Set marking 510 in accordance with the present disclosure. And a diagram 600 in FIG. 6 illustrates a format of a two-byte PDU Set RTP header extension for PDU Set marking 610 in accordance with the present disclosure. The RTP header extensions 510, 610 include similar data fields including one or more PDU set information parameters.

[0077] An End PDU of the PDU Set [E] field 520, 620 is a one-bit field which is set to ‘ 1’ for a last PDU of a PDU Set and set to ‘0’ for other PDUs in the PDU Set. An End of Data Burst [D] field 525, 625 is a one-bit field which is set to ‘ 1’ to indicate a last PDU of a Data Burst. A data burst is defined in 3GPP TS 26.522 as a set of multiple PDUs generated and sent by an application such that there is an idle period between two data bursts. A data burst can be composed of one PDU Set or multiple PDU Sets. A reserved field 530, 630 is a two-bit field reserved for future use. The reserved field is set to ‘0’ by the RTP sending device and is ignored by other entities.

[0078] A PDU Set Importance (PSI) field 540, 640 is a field of four bits which indicates an importance of a PDU Set as compared to other PDU Sets within a same service flow. The four-bit PSI has a value between 0-15 (inclusive). A high PSI value means that the PDU Set has a low importance for the media stream and vice versa. [0079] A PDU Set Sequence Number (PSSN) field 550, 650 is a 10-bit field which indicates a sequence number of the PDU Set to which the current PDU belongs. The PSSN is the same for all PDUs belonging to a given PDU Set. A PDU Sequence Number within a PDU Set (PSN) field 560, 660 is a 6-bit field which indicates a sequence number of the current PDU within the PDU Set.

[0080] A PDU Set Size (PSSize) field 570, 670 is a 24-bit field which indicates a total size of all PDUs belonging to the PDU Set to which the PDU belongs. The size is expressed in bytes and the PSSize field 570, 670 is optional and subject to SDP negotiation.

[0081] A Number of PDUs in the PDU Set (NPDS) field 580, 680 is a 16-bit field which indicates a total number of PDUs belonging to the same PDU Set. The NPDS field 580, 680 is optional and subject to SDP negotiation, however, it is recommended to add the NPDS field 480, 580 when the PSSize field 570, 670 is present. The NPDS is expected to be used for correction of the PSSize calculation at the UPF, in case a NAT46/NAT64 correction has taken place (i.e., in case 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.

[0082] TS 26.522, clause 4.2.6, provides guidelines for PDU Set marking by the application and 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.

[0083] RTP retransmission is a technique employed for media resilience in real-time communication scenarios and may be particularly useful in networks with low roundtrip time (RTT). For example, let D be a time difference between an expected application display time of packet X and an expected reception time of packet X at the application receiver’s side. If the network RTT is < D, the application can afford at least one retransmission of packet X in case X is lost or dropped by the network.

[0084] However, RTP retransmission also poses a risk of increasing network congestion. To avoid network congestion, an RTP sending device can determine an acceptable bit and packet rate according to a congestion control mechanism. Both the original and retransmitted data should be considered when calculating the bit rate. The RTP sending device may selectively retransmit only packets that they deem important and ignore retransmission requests (e.g. RTCP NACK messages) for other packets in order to limit the bitrate. The RTP receiving device may also be selective in sending NACK messages and may choose to not send a NACK for each dropped packet they detect.

[0085] Currently, 5G networks have no awareness of RTP retransmission. Retransmission may be configured and negotiated end-to-end between the RTP sending device and the RTP receiving device; however, the network does not know whether and how RTP retransmission is to be performed. When PDU Set handling is used, this may lead to inefficient operation since it is not obvious whether the application should add the PDU Set RTP HE to the retransmitted PDUs and, if yes, how it should populate the fields of the HE. Also, the PDU Set QoS parameters for the retransmitted stream might need to be configured differently as compared to the original/source stream. Using the same signaling and configuration for the retransmitted PDUs as for the original RTP PDU stream may result in suboptimal performance in terms of network operation and user experience. Additional or modified signaling may be necessary to configure the network favorably for efficient transport. Furthermore, the RTP receiving device can also benefit from such additional signaling since it may send retransmission requests selectively based on the additional signaling. If no additional signaling is used, the network level PDU Set handling and RTP retransmissions may lead to an undesirable state, wherein during congestion events, the network employs PSI-based packet dropping. Consequently, RTP receiving devices NACK the lost packets (by the PSI- based packet dropping policy), and request the sender to retransmit the dropped packets indiscriminately, possibly aggravating the congestion.

[0086] Among the PDU Set RTP HE fields, PDU Set Importance (PSI) may be useful to the receiver for selective sending of retransmission requests/NACKs. Currently, there is no mechanism to indicate to the RTP receiving device a threshold/upper bound for the PSI values used by the sender for the PDUs that are critical for a successful operation of the application, and thus would need to be retransmitted in case they are lost.

[0087] In accordance with the present disclosure, an RTP retransmission packet includes RTP retransmission information which includes an RTP header extension having at least one or more of a retransmission flag and PDU set information parameters such as PSI, PSSN, PSN, PSSize, or NPDS. Referring back to FIG. 1, the system 100 for RTP communication in accordance with the present disclosure includes the first device 110 and the second device 120. During an RTP communication session, the first device 110, acting as an RTP sending device, sends RTP packets to the second device 120, acting as an RTP receiving device via the network 130 on RTP communication channels 140a, 140b. The RTP sending device (i.e., the first device 110) includes at least one processor 112, at least one memory 114 including computer program code, and circuitry 116 at least including RTP sending device circuitry for sending the RTP packets to and receiving data from the RTP receiving device (i.e., the second device 120) during the RTP communication session. Similarly, the RTP receiving device (i.e., the second device 120) includes at least one processor 122, at least one memory 124 including computer program code, and circuitry 126 at least including RTP receiving device circuitry for receiving RTP packets from and sending data to the RTP sending device (i.e., the first device 110) during the RTP communication session.

[0088] In accordance with the present disclosure, the RTP sending device performs PDU Set marking for RTP packets during the RTP communication session for advantageously providing additional information to the RTP receiving device for improved handling of retransmission requests by an RTP header extension for the RTP packets or by other means such as SDP. In response to a retransmission request received from the RTP receiving device via the return RTP communication path 150a. 150b, the RTP sending device sends an RTP retransmission packet to the RTP receiving device, the RTP retransmission packet including at least RTP retransmission information. The RTP retransmission information includes an RTP header extension, the RTP header extension including one or more of a retransmission packet flag and PDU set information parameters such as PSI, PSSN, PSN, PSSize, or NPDS.

[0089] In addition, the RTP sending device provides additional information to the network 130 for efficient handling of retransmission requests when PDU Set handling is used by the network 130. The additional information can be signaled in the RTP header extension or by other means such as control plane signaling (e.g. using the Application Function (AF)).

[0090] For retransmitted PDUs, sending a reduced amount of information in the PDU Set RTP HE can be sufficient for identification of the PDU Sets that these PDUs belong to and can beneficially reduce retransmitted information. In a case of retransmission, since some parts of the PDU Set Information have already been signaled in the HE added to the original PDU, a “compact” RTP HE that contains a reduced amount of information can be added to the retransmitted PDU to save bandwidth without disturbing the network operation. In accordance with the present disclosure, an RTP sending device may, in case of retransmission, add a subset of the PDU Set Information defined in 3GPP TS 23.501 to the PDU Set RTP HE, thereby advantageously using a compact/reduced HE (relative to the PDU Set RTP HE defined in 3GPP TS 26.522). The methods, devices and system in accordance with the present disclosure also describes the behavior of the devices 110, 120 and the network 130 when receiving such additional information.

[0091] While simply described as a device or apparatus, the RTP sending device may be an Application Server, a network media function (e.g. an IMS MF/MRF), a sender UE that sends media to another UE or other 5G network components, or similar media-providing device.

[0092] Referring to FIG. 7, a call flow diagram 700 depicts signaling of PDU Set importance (PSI) threshold in accordance with the present disclosure. Initially, an RTP sending device 710 and an RTP receiving device 720 in accordance with the present disclosure negotiate and establish 730 an RTP communication session via the network 130. The sending device 710 performs PDU Set marking and provides additional information to the network 130 and/or to the RTP receiving device 720. By “PDU Set marking”, it is meant that the sender adds a HE to outgoing RTP packets containing all or part of the PDU Set Information and other fields (e.g., EDB) defined in 3GPP TS 26.522. The system may be designed such that the additional information is provided when the RTP sending device 710 and the RTP receiving device 720 have agreed on the use of RTP retransmission, for example resulting from an SDP negotiation which may be part of the negotiation and establishment of the RTP communication session 730. [0093] In an embodiment, the RTP sending device 710 determines a PSI threshold 740 and signals 745 the PSI threshold to the RTP receiving device 720. The PSI threshold can be sent in a SDP negotiation or by other means. Note that the PSI threshold could be updated by the RTP sending device 710 during a multimedia session, via SDP re-negotiation or other means. Upon detection of a lost or unreceived packet 790, such as by inspection of RTP sequence numbers (SN), the RTP receiving device 720 inspects the PSI values of the incoming and buffered packets with RTP SNs adjacent to the lost packet and to derive the PSI value for the lost or unreceived packet. The RTP receiving device 720 then sends 795 a retransmission request (e.g., an RTCP NACK packet) if the PSI value of the dropped packet is lower than or equal to the signalled PSI threshold.

[0094] The above example embodiment assumes that PDU Set Integrated Handling is not used in the RTP communication session, that is the PDU Set Integrated Handling Indicator (PSIHI) has not been set by the AF. This means that, when a single PDU of a PDU Set is lost, the network may not discard the whole PDU Set. This allows the RTP receiving device 720 to use the information from the other PDUs with RTP SNs adjacent to the lost PDU.

[0095] In another embodiment, the RTP sending device 710 signals 745 a PSI threshold to the RTP receiving device 720 and also signals 750 the PSI value of the next PDU Set in transmission order (“next PSI”) in the PDU Set RTP HE. Upon detection of a lost or unreceived packet 790, the RTP receiving device 720 sends a retransmission request 795 if the “next PSI” value is lower than or equal to the PSI threshold. This embodiment is equally applicable in a case of PDU Set Integrated Handling since it does not require information from other PDUs in the PDU Set. [0096] In another embodiment, the RTP sending device 710 signals 745 a PSI threshold to the RTP receiving device 720 and signals 770 the PSI value of the previous PDU Set in transmission order (“last PSI”) in the PDU Set RTP HE. Upon detection of a lost or unreceived packet 790, the RTP receiving device 720 sends a retransmission request 795, if the “last PSI” value is lower or equal than the PSI threshold. This embodiment is also applicable in a case of PDU Set Integrated Handling since it also does not require information from other PDUs in the PDU Set.

[0097] In another embodiment, the RTP sending device 710 may signal 760, 780 in the PDU set HE a Boolean (e.g., a next PSI flag or a last PSI flag) indicating if the adjacent PDU set in transmission order has a PSI value greater than the threshold for retransmission.

[0098] Table 5 below lists the signal and semantics that can be used to help the RTP receiving device 720 detect a PSI value of a lost PDU set by using the PDU set HE of its adjacent PDU sets. One or more of these signals can be used by the RTP sending device 710.

TABLE 5 - Signals to Detect Lost Packets [0099] In some use cases, the RTP sending device 710 may change the PSI assignment scheme of a media stream on the run due to (estimated) changes in network conditions or in media content. An example: a real-time tiled viewport-dependent stream with guard margins may assign a low PSI (e.g. 5) to the visible FOV at the start of a session and a high PSI (e.g. 15) to the guard margin. If the network is severely congested, the RTP receiving device 720 may be sending several NACKs indicating a whole frame is dropped. In such situations, it may be desirable that tiles of a frame within the visible FOV that are most important visually be given higher priority for transmission by the network. Such important tiles of the frame may, in simple cases, be assumed to be in the center of the frame. Alternatively, tiles of the frame with the most visual saliency or falling within a range of a reported gaze location may be considered visually important. The RTP sending device 710 might try to do PSI assignment according to the importance of tiles in each frame, using a range of PSIs. Consequently, the threshold may change during a session.

[00100] In an embodiment, the PSI values of the media and the PSI threshold for retransmissions may also change during an RTP communication session. Thus, the RTP sending device 710 may send the updated PSI threshold to an RTP receiving device 720 via SDP renegotiation, SIP updates, or any other suitable method such as RTCP APP or RTCP feedback messages.

[00101] In an embodiment, the PSI threshold is signaled as a relative value (delta) from a lowest/highest PSI in the RTP communication session or during a time window. The time window may also be signaled during session negotiation.

[00102] In another embodiment, the RTP sending device 710 determines a PSI threshold and uses the PSI threshold itself (instead of sending it to the RTP receiving device 720) to decide whether to retransmit a packet upon reception of a retransmission request from the RTP receiving device 720. The RTP sending device 710 ignores the retransmission requests from the RTP receiving device 720 for packets with a PSI greater than the PSI threshold. This may lead to cases where the RTP receiving device 720, being unaware of the PSI threshold at the RTP sending device 710, may send requests which do not trigger a retransmission.

[00103] Referring to FIG. 8, a call flow diagram 800 depicts signaling of some additional information by the RTP sending device 710 in accordance with the present disclosure. The system may be designed such that the additional information is provided after the RTP sending device 710 and the RTP receiving device 720 have agreed on the use of RTP retransmission, for example resulting from an SDP negotiation which may be part of a negotiation and establishment of the RTP communication session 730.

[00104] In an embodiment, the RTP sending device 710 indicates 810 to the network 130 that it has successfully negotiated the use of RTP retransmission with the RTP receiving device 720 such that retransmissions may occur during RTP communication sessions. The indication can be included into a PDU Set RTP HE as a boolean flag, where value 1 means retransmissions are enabled and value 0 means retransmissions are not enabled. Alternatively or in addition, the indication can be done via control plane signalling such as in the Protocol Description signalled by the AF.

[00105] In an embodiment, the RTP sending device 710 indicates 820 a time (rtx- time) the RTP sending device 710 keeps an RTP packet in its buffers available for retransmission to the network 130 via control plane signalling such as in the Protocol Description signalled by the AF.

[00106] In an embodiment, the RTP sending device 710 indicates 830 to the network 130 (via AF signalling) different PDU Set QoS parameters for a source/original stream and a retransmission stream. For example, the RTP sending device 710 may indicate a lower value for a PSDB used in the retransmission stream than a PSDB in the source stream such that the network may configure scheduling differently for retransmitted PDU Sets.

[00107] In an embodiment, the RTP sending device 710 signals 840 the PSH4I to the RTP receiving device 720 in the PDU Set RTP HE, via SDP signalling or by other means such as control plane signalling. If the PSIHI is set, the RTP receiving device 720 can infer that it is acceptable to send NACK only for the first lost PDU of a PDU Set (and not for the remaining PDUs of the same PDU Set) since the RTP sending device 710, being aware that integrated handling is used, will know that all packets of the PDU Set have been dropped. Alternatively, separate NACK messages can be sent by the RTP receiving device 720 for the first few PDUs of a PDU Set (considering that NACKs may be lost). In both cases, the RTP sending device 710 will then know to retransmit all other PDUs of the PDU Set in addition to the one(s) for which the NACK was sent.

[00108] In an embodiment in accordance with the present disclosure, an RTP sending device 710 may add a "compact PDU Set RTP HE" to retransmitted packets. The compact HE contains a subset of the information found in the PDU Set HE and is added to the PDUs of the retransmitted stream, whereas the PDU Set HE with the full PDU Set Information is added to the PDUs of the original stream. Reducing the information in the RTP HE provides the benefit that PDU Set identification at the User Plane Function (UPF) can be achieved using a smaller RTP HE thereby advantageously decreasing bandwidth usage between the Application Server and the UPF in downlink or between the RTP sending device 710 and the UPF in uplink. [00109] The following embodiments give examples of different subsets that can be included in a compact PDU Set HE. However, these embodiments are merely examples of specific configurations and are not meant to limit the subset of fields that can be included in the compact PDU Set HE.

[00110] In an embodiment depicted in the one-byte HE format diagram 900 of FIG. 9, a compact HE 910 in accordance with the present disclosure may contain only the PDU Set Importance (PSI) 920 in its data fields.

[00111] In another embodiment depicted in the one-byte HE format diagram 1000 of FIG. 10, the compact HE 1010 may contain both the PDU Set Importance 1020 and the PDU Set Sequence Number (PSSN) 1030 in its data fields. Including both the PSI 1020 and the PSSN 1030 in the compact HE 1010 allows the network 130 to identify the retransmitted PDU as part of the original PDU Set (e.g., since the PSSN data field 1030 indicates that the retransmitted PDU uses the same PSSN as the original PDU set). Associating the retransmitted PDU with the original PDU Set may beneficially help the network 130 in efficient resource allocation and scheduling. For example, the network 130 can check whether the entire PDU Set (including the retransmitted PDU) can be delivered on time by estimating the delivery time for the retransmitted PDU and analysing whether the transmission time for the entire PDU Set is still within the PSDB. [00112] A data burst may contain PDUs from both the original stream and the retransmission stream. In this case, it should be possible for the network 130 to detect the end of a data burst. In an embodiment, the compact HE may contain a PSSN and an End of Data Burst (EDB) indication. In addition to the benefits previously described for the compact HE format diagram 1000, adding the EDB indication to the compact HE allows the network 130 to still be able to detect the end of the data burst while using the compact HE, even if the end of the data burst corresponds to a retransmitted PDU. [00113] In an embodiment depicted in the one-byte HE format diagram 1100 of FIG. 10, the compact HE 1110 comprises a flag 1120 (denoted as “X”) indicating it is a retransmitted packet. Including the retransmitted packet flag 1120 may allow the network 130 to handle retransmitted PDUs differently. For example, in a case where the network 130 receives two PDUs with similar PSI values, the retransmitted PDU may be given priority in terms of, for example, resource allocation or scheduling. In this example, the compact HE 1110 also contains some other fields of the PDU Set HE, namely End Bit (E) 1130, End of Data Burst (D) 1140, PSI 1150 and PSSN 1160 (R indicates a reserved data field). The network 130 may inspect the “X” field 1120 to determine whether the PDU is a retransmitted PDU and handle it accordingly. The “X” flag can also be included as a new field to a (full) PDU Set RTP HE defined in 3GPP TS 26.522.

[00114] In FIG. 12, an example SDP description 1200 with S SRC -multiplexing describes a multimedia session with two video streams transported in the same RTP communication session: a source H.264 video stream (pt=96) and a corresponding retransmission stream (pt=97). The PDU Set RTP HE (including the optional fields PSSsize and NPDS) is added to the source stream, whereas the compact PDU Set RTP HE, denoted by the URN urn:3gpp:pdu-set-marking-compact, is added to the retransmission stream.

[00115] In an embodiment, the RTP sending device 710 indicates to the network 130 (via AF signalling) that retransmitted PDUs will use the same PSSN as that of the original PDU set. This can be the case regardless of whether the compact PDU Set HE or the (full) PDU Set HE defined in 3GPP TS 26.522 is used for retransmitted PDUs.

[00116] Example SDP description with Session-multiplexing [00117] In FIG. 13, an example SDP description 1300 with Session-multiplexing describes a multimedia session with two video streams transported in different RTP sessions, a source H.264 video stream (pt=96) and a corresponding retransmission stream (pt=97). The PDU Set RTP HE defined in 3GPP TS 26.522 (including the optional fields PSSsize and NPDS) is added to the source stream, whereas the compact PDU Set RTP HE, denoted by the URN urn:3gpp:pdu-set-marking-compact, is added to the retransmission stream.

[00118] Alternatively, the PDU Set RTP HE (as defined in TS 26.522) is added to the retransmitted PDU. The optional fields PSSize and NPDS may or may not be present, depending on the SDP negotiation between the RTP sending device 710 and the RTP receiving device 720.

[00119] In an embodiment, the RTP sending device 710 may prefer to send the retransmitted PDU with a relatively higher importance and thus assigns to the retransmitted PDU a PSI lower than that of the original PDU, expecting such assignment to decrease the probability of discard by the network 130. The RTP sending device 710 sets all the other HE fields with the same values as for the original PDU.

[00120] The two optional fields in the PDU Set RTP HE are the PDU Set Size (PSSize) and the Number of PDUs in the PDU Set (NPDS). The PSSize is intended to be used by the RAN for efficient allocation of scheduling resources to a particular PDU Set. Thus, once all or most of the original PDUs in a PDU Set have been transmitted (although some might have been dropped), this information is no longer necessary or of little benefit to the network 130. The NPDS is intended to be used by the UPF to correct the PSSize calculation, in case a NAT64/NAT46 conversion has occurred in the network path affecting the IP header size and thus invalidates the PSSize calculated at the AS. Therefore, the NPDS is similarly not necessary (or of little benefit to the network 130) once all or most of the original PDUs in a PDU Set have been transmitted. [00121] In an embodiment, the RTP sending device 710 includes either one or both optional PDU Set RTP HE fields PSSize and NPDS in the PDU Set HE added to the original PDUs. However, for the retransmitted PDUs, the RTP sending device 710 adds the PDU Set HE without the fields PSSize and/or NPDS.

[00122] In an embodiment, the “X” flag used to indicate a retransmitted PDU (such as the flag 1120, FIG. 11) is added as a new field to the (full) PDU Set RTP HE, where (full) PDU Set RTP HE refers to the PDU Set RTP HE as defined in TS 26.522. The flag is set to ‘ 1 ’ if the HE is added to a retransmitted PDU, otherwise the flag is set to ‘O’. FIG. 14 depicts a diagram 1400 of a full PDU Set RTP HE 1410 showing one way of including the X field 1420 in the PDU Set RTP HE without excluding different ordering of the HE fields by including the X field 1420 in one of the reserved bits.

[00123] Referring to FIG. 15, a flowchart 1500 depicts an RTP communication session from the point of view of the RTP sending device 710. After the RTP sending device 710 and the RTP receiving device 720 agree 1502 to use RTP transmission during an RTP communication session, the RTP sending device 710 performs 1504 PDU set marking for RTP packets during the RTP communication session by generating header extensions for the RTP packets. The RTP sending device 710 then transmits 1506 the RTP packets with the RTP header extension to the RTP receiving device 720.

[00124] If no retransmission request is received 1508 from the RTP receiving device 720, the RTP sending device 710 performs 1504 PDU set marking for additional RTP packets and transmits 1506 the RTP packets to the RTP receiving device 720. When a retransmission request is received 1508 from the RTP receiving device 720, the RTP sending device 710 may transmit 1510 a retransmission packet to the RTP receiving device 720, the RTP retransmission packet including RTP transmission information. It is noted that, as with current RTP retransmission, the RTP sending device 710 in accordance with the present disclosure does not have to respond to every retransmission request. Also in accordance with the present disclosure, the RTP retransmission information includes an RTP header extension which may have at least one or more of a retransmission flag and PDU set information parameters such as PSI, PSSN, PSN, PSSize, or NPDS. Then processing returns for the RTP sending device 710 to perform 1504 PDU set marking for additional RTP packets and transmit 1506 the RTP packets to the RTP receiving device 720.

[00125] Referring to FIG. 16, a flowchart 1600 depicts an RTP communication session from the point of view of the RTP receiving device 720. After the RTP receiving device 720 and the RTP sending device 710 agree 1602 to use RTP retransmission during an RTP communication session, the RTP receiving device 720 receives 1604 RTP packets with RTP header extensions from the RTP sending device 710. The RTP receiving device 720 receives 1604 the RTP packets with RTP header extensions from the RTP sending device 710 until either the RTP packet received is an RTP retransmission packet 1606 or an unreceived RTP packet (or packets) is detected 1608.

[00126] When an unreceived RTP packet is detected 1608, the RTP receiving device 720 may transmit 1610 a retransmission request including information indicating the unreceived RTP packet(s) to the RTP sending device 710, deciding selectively whether to transmit the retransmission request or not. When the RTP retransmission packet is received 1606, the RTP receiving device 720 derives 1612 RTP retransmission information from the RTP retransmission packet and processing returns to receive 1604 the RTP packets with RTP header extensions from the RTP sending device 710.

[00127] Thus, it can be seen that the present embodiments provide methods, systems and devices for RTP retransmission aware protocol data unit (PDU) set handling in accordance with the present disclosure. In accordance with the present disclosure, the RTP sending device 710 performs PDU Set marking for RTP packets during the RTP communication session to advantageously provide additional information to the RTP receiving device for improved handling of retransmission requests by an RTP header extension for the RTP packets or by other means such as SDP. In addition, the RTP sending device 710 provides additional information to the network 130 for efficient handling of retransmission requests when PDU Set handling is used by the network 130. The additional information can be signaled in an RTP header extension or by other means such as control plane signaling (e.g. using the Application Function (AF)).

[00128] 1. An apparatus for real-time transport protocol (RTP) communication comprising:

[00129] circuitry for sending RTP packets to and receiving data from at least one RTP receiving device;

[00130] at least one processor; and

[00131] at least one memory including computer program code,

[00132] wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00133] perform protocol data unit (PDU) set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets; and [00134] provide the RTP packets with at least the header extension to the circuitry for sending to the at least one RTP receiving device,

[00135] wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to

[00136] detect a retransmission request within the data received from the at least one receiving device; and

[00137] provide an RTP retransmission packet to the circuitry for sending to the at least one RTP receiving device when the retransmission request is detected, the RTP retransmission packet comprising at least RTP retransmission information.

[00138] 2. The apparatus in accordance with Claim 1 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

[00139] 3. The apparatus in accordance with either Claim 1 or Claim 2 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to provide the RTP retransmission to the circuitry for sending to the at least one RTP receiving device after the apparatus and the at least one RTP receiving device have agreed to use RTP retransmission.

[00140] 4. The apparatus in accordance with Claim 3 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00141] provide additional transmission information to the circuitry for sending to a network controller handling communication between the apparatus and the at least one RTP receiving device in at least one of a header extension of an RTP packet or in control plane signaling by a network application function (AF).

[00142] 5. The apparatus in accordance with Claim 4 wherein the additional transmission information provided to the circuitry for sending to a network controller comprises one or more of information indicating the apparatus and the at least one RTP receiving device have agreed to use RTP retransmission, information indicating an amount of time which the apparatus maintains an RTP packet for RTP retransmission, one or more PDU set quality of service (QoS) parameters, and information indicating that retransmitted PDUs use the same PSSN as original PDU sets.

[00143] 6. The apparatus in accordance with Claim 3 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00144] determine PSI threshold information based on the apparatus and the at least one RTP receiving device agreeing to use RTP retransmission; and

[00145] provide the PSI threshold information to the circuitry for sending to the at least one RTP receiving device.

[00146] 7 The apparatus in accordance with Claim 6 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00147] provide one or both of the additional transmission information or the PSI threshold information to the circuitry for sending to the at least one RTP receiving device in at least one of a header extension of an RTP packet or session description protocol (SDP) information. [00148] 8. The apparatus in accordance with Claim 7 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00149] when providing the PSI threshold information to the circuitry for sending to the at least one RTP receiving device in the header extension of the RTP packet, also provide a PSI value of a next PDU set in transmission order information in the header extension of the RTP packet.

[00150] 9. The apparatus in accordance with Claim 7 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00151] when providing the PSI threshold information to the circuitry for sending to the at least one RTP receiving device in the header extension of the RTP packet, also provide a PSI value of a previous PDU Set in transmission order in the header extension of the RTP packet.

[00152] 10. The apparatus in accordance with any of Claims 7 to 9 wherein the PSI threshold information comprises one or more of updated PSI information, one or more PSI assignments within a PSI range, or a relative PSI threshold value.

[00153] 11. An apparatus for real-time transport protocol (RTP) communication comprising:

[00154] circuitry for receiving RTP packets from and sending data to an RTP sending device;

[00155] at least one processor; and

[00156] at least one memory including computer program code,

[00157] wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: [00158] detect one or more unreceived RTP packets during an RTP communication session; and

[00159] provide a retransmission request to the circuitry for sending to the RTP sending device, wherein the retransmission request includes information indicating the one or more unreceived RTP packets,

[00160] wherein when the circuitry thereafter receives an RTP retransmission packet, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to derive at least RTP retransmission information from the RTP retransmission packet received.

[00161] 12. The apparatus in accordance with Claim 11 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

[00162] 13. The apparatus in accordance with either Claim 11 or Claim 12 wherein the at least one memory and the computer program code are configured to, with the at least one processor, to cause the apparatus to provide the retransmission request to the circuitry for sending to the RTP sending device after the apparatus and the RTP sending device have agreed to use RTP retransmission.

[00163] 14. The apparatus in accordance with Claim 13 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00164] after detecting the one or more unreceived RTP packets during the RTP communication session, determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to PSI values of one or more received RTP packets.

[00165] 15. The apparatus in accordance with Claim 14 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00166] derive PSI threshold information from the information in the RTP packets received from the RTP sending device by the circuitry; and

[00167] determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to the PSI threshold information and the PSI values of one or more received RTP packets.

[00168] 16. The apparatus in accordance with Claim 15 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00169] derive next PDU set in transmission order information from an RTP header extension received from the RTP sending device by the circuitry; and

[00170] determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to the PSI threshold information and the next PDU set in transmission order information.

[00171] 17. The apparatus in accordance with Claim 15 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to:

[00172] derive previous PDU set in transmission order information from an RTP header extension received from the RTP sending device by the circuitry; and [00173] determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to the PSI threshold information and the previous PDU set in transmission order information.

[00174] 18. A method for real-time transport protocol (RTP) communication comprising:

[00175] performing protocol data unit (PDU) set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets;

[00176] transmitting the RTP packets with at least the header extension to at least one RTP receiving device;

[00177] receiving a retransmission request from the at least one RTP receiving device; and

[00178] transmitting an RTP retransmission packet to the at least one RTP receiving device in response to receiving the retransmission request, the RTP retransmission packet comprising at least RTP retransmission information.

[00179] 19. The method in accordance with Claim 18 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

[00180] 20. The method in accordance with either Claim 18 or Claim 19 further comprising an RTP sending device and the at least one RTP receiving device agreeing to use RTP retransmission before transmitting the RTP retransmission packet to the at least one RTP receiving device. [00181] 21. The method in accordance with Claim 20 further comprising providing additional transmission information to a network controller handling communication between the RTP sending device and the at least one RTP receiving device in at least one of a header extension of an RTP packet or in control plane signaling by a network application function (AF).

[00182] 22. The method in accordance with Claim 21 wherein providing the additional transmission information to the network controller comprises providing one or more of information indicating the sending device and the at least one RTP receiving device have agreed to use RTP retransmission, information indicating an amount of time which the apparatus maintains an RTP packet for RTP retransmission, one or more PDU set quality of service (QoS) parameters, and information indicating that retransmitted PDUs use the same PSSN as original PDU sets.

[00183] 23. The method in accordance with Claim 20 further comprising:

[00184] determining PSI threshold information based on the apparatus and the at least one RTP receiving device agreeing to use RTP retransmission; and

[00185] transmitting the PSI threshold information to the at least one RTP receiving device.

[00186] 24. The method in accordance with Claim 23 further comprising transmitting one or both of the additional transmission information or the PSI threshold information to the at least one RTP receiving device in at least one of a header extension of an RTP packet or session description protocol (SDP) information.

[00187] 25. The method in accordance with Claim 24 further comprising, when transmitting the PSI threshold information to the at least one RTP receiving device in the header extension of the RTP packet, also transmitting a PSI value of a next PDU set in transmission order information in the header extension of the RTP packet. [00188] 26. The method in accordance with Claim 24 further comprising, when transmitting the PSI threshold information to the at least one RTP receiving device in the header extension of the RTP packet, also transmitting a PSI value of a previous PDU Set in transmission order in the header extension of the RTP packet.

[00189] 27. The method in accordance with any of Claims 24 to 26 wherein the PSI threshold information comprises one or more of updated PSI information, one or more PSI assignments within a PSI range, or a relative PSI threshold value.

[00190] 28. A method for real-time transport protocol (RTP) communication comprising:

[00191] detecting one or more unreceived RTP packets during an RTP communication session;

[00192] transmitting a retransmission request to an RTP sending device, wherein the retransmission request includes information indicating the one or more unreceived RTP packets; and

[00193] when thereafter receiving an RTP retransmission packet, deriving at least RTP retransmission information from the RTP retransmission packet received.

[00194] 29. The method in accordance with Claim 28 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

[00195] 30. The method in accordance with either Claim 28 or Claim 29 wherein transmitting the retransmission request to the RTP sending device by a receiving device comprises the receiving device and the sending device agreeing to use RTP retransmission before transmitting the retransmission request to the RTP sending device.

[00196] 31. The method in accordance with Claim 30 wherein detecting the one or more unreceived RTP packets during the RTP communication session comprises determining whether to transmit the retransmission request to the RTP sending device in response to PSI values of one or more received RTP packets.

[00197] 32. The method in accordance with Claim 31 further comprising deriving PSI threshold information from the information in the RTP packets received from the RTP sending device,

[00198] wherein detecting the one or more unreceived RTP packets during the RTP communication session comprises determining whether to transmit the retransmission request to the RTP sending device in response to the PSI threshold information and the PSI values of one or more received RTP packets.

[00199] 33. The method in accordance with Claim 32 further comprising deriving next PDU set in transmission order information from an RTP packet header extension received from the RTP sending device,

[00200] wherein detecting the one or more unreceived RTP packets during the RTP communication session comprises determining whether to transmit the retransmission request to the RTP sending device in response to the PSI threshold information and the next PDU set in transmission order information.

[00201] 34. The method in accordance with Claim 32 further comprising deriving previous PDU set in transmission order information from an RTP packet header extension received from the RTP sending device by the circuitry,

[00202] wherein detecting the one or more unreceived RTP packets during the RTP communication session comprises determining whether to transmit the retransmission request to the RTP sending device in response to the PSI threshold information and the previous PDU set in transmission order information.

[00203] 35. A system for real-time transport protocol (RTP) communication comprising:

[00204] an RTP sending device; and

[00205] at least one RTP receiving device,

[00206] wherein the RTP sending device comprises:

[00207] RTP sending device circuitry for sending RTP packets to and receiving data from the at least one RTP receiving device during an RTP communication session; [00208] at least one processor; and

[00209] at least one memory including computer program code,

[00210] wherein the at least one memory and the computer program code of the RTP sending device are configured to, with the at least one processor, cause the RTP sending device to:

[00211] perform protocol data unit (PDU) set marking for RTP packets during the RTP communication session by at least generating a header extension for the RTP packets; and

[00212] provide the RTP packets with at least the header extension to the RTP sending device circuitry for sending to the at least one RTP receiving device, and

[00213] wherein the at least one RTP receiving device comprises:

[00214] RTP receiving device circuitry for receiving RTP packets from and sending data to the RTP sending device during the RTP communication session;

[00215] at least one processor; and

[00216] at least one memory including computer program code, [00217] wherein the at least one memory and the computer program code of the at least one RTP receiving device are configured to, with the at least one processor, cause the at least one RTP receiving device to:

[00218] detect one or more unreceived RTP packets during the RTP communication session; and

[00219] provide a retransmission request to the RTP receiving device circuitry for sending to the RTP sending device, wherein the retransmission request includes information indicating the one or more unreceived RTP packets, and

[00220] wherein the at least one memory and the computer program code of the RTP sending device are further configured to, with the at least one processor, cause the RTP sending device to:

[00221] detect the retransmission request within the data received from the at least one receiving device; and

[00222] provide an RTP retransmission packet to the sending device circuitry for sending to the at least one RTP receiving device when the retransmission request is detected, the RTP retransmission packet comprising at least RTP retransmission information.

[00223] 36. The system in accordance with Claim 35 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

[00224] 37. The system in accordance with either Claim 35 or Claim 36 wherein, when the at least one RTP receiving device circuitry thereafter receives the RTP retransmission packet, the at least one memory and the computer program code of the at least one RTP receiving device are configured to, with the at least one processor, to cause the at least one RTP receiving device to derive at least the RTP retransmission information from the RTP retransmission packet received.

[00225] 38. The system in accordance with any of Claims 35 to 37 further comprising a network controller handling communication between the RTP sending device and the at least one RTP receiving device during the RTP communication session,

[00226] wherein the at least one memory and the computer program code of the RTP sending device are configured to, with the at least one processor, cause the RTP sending device to:

[00227] provide additional transmission information to the RTP sending circuitry for sending to the network controller in at least one of a header extension of an RTP packet or in control plane signaling by a network application function (AF),

[00228] wherein the additional transmission information provided to the RTP sending circuitry for sending to the network controller comprises one or more of information indicating the RTP sending device and the at least one RTP receiving device have agreed to use RTP retransmission, information indicating an amount of time which the RTP sending device maintains an RTP packet for RTP retransmission, one or more PDU set quality of service (QoS) parameters, and information indicating that retransmitted PDUs use the same PSSN as original PDU sets.

[00229] 39. An apparatus for real-time transport protocol (RTP) communication comprising:

[00230] means for sending RTP packets to and receiving data from at least one RTP receiving device; [00231] means for performing protocol data unit (PDU) set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets and providing the RTP packets with at least the header extension to the means for sending RTP packets to the at least one receiving device for sending thereto; [00232] means for detecting a retransmission request within the data received from the at least one receiving device; and

[00233] means for providing an RTP retransmission packet to the circuitry for sending to the at least one RTP receiving device when the retransmission request is detected, the RTP retransmission packet comprising at least RTP retransmission information.

[00234] 40. An apparatus for real-time transport protocol (RTP) communication comprising:

[00235] means for receiving RTP packets from and sending data to an RTP sending device;

[00236] means for detecting one or more unreceived RTP packets during an RTP communication session and providing a retransmission request to the means for sending data to the RTP sending device for sending thereto, wherein the retransmission request includes information indicating the one or more unreceived RTP packets; and

[00237] means for deriving at least RTP retransmission information from the RTP retransmission packet received.

[00238] While exemplary embodiments have been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should further be appreciated that the exemplary embodiments are only examples, and are not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing exemplary embodiments, it being understood that various changes may be made in the function and arrangement of steps and method of operation described in the exemplary embodiments without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

CLAIMS What is claimed is:

1. An apparatus for real-time transport protocol (RTP) communication comprising: circuitry for sending RTP packets to and receiving data from at least one RTP receiving device; at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: perform protocol data unit (PDU) set marking for RTP packets during an RTP communication session by at least generating a header extension for the RTP packets; and provide the RTP packets with at least the header extension to the circuitry for sending to the at least one RTP receiving device, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to detect a retransmission request within the data received from the at least one receiving device; and provide an RTP retransmission packet to the circuitry for sending to the at least one RTP receiving device when the retransmission request is detected, the RTP retransmission packet comprising at least RTP retransmission information.

2. The apparatus in accordance with Claim 1 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

3. The apparatus in accordance with either Claim 1 or Claim 2 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to provide the RTP retransmission to the circuitry for sending to the at least one RTP receiving device after the apparatus and the at least one RTP receiving device have agreed to use RTP retransmission.

4. The apparatus in accordance with Claim 3 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: provide additional transmission information to the circuitry for sending to a network controller handling communication between the apparatus and the at least one RTP receiving device in at least one of a header extension of an RTP packet or in control plane signaling by a network application function (AF).

5. The apparatus in accordance with Claim 4 wherein the additional transmission information provided to the circuitry for sending to a network controller comprises one or more of information indicating the apparatus and the at least one RTP receiving device have agreed to use RTP retransmission, information indicating an amount of time which the apparatus maintains an RTP packet for RTP retransmission, one or more PDU set quality of service (QoS) parameters, and information indicating that retransmitted PDUs use the same PSSN as original PDU sets.

6. The apparatus in accordance with Claim 3 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: determine PSI threshold information based on the apparatus and the at least one RTP receiving device agreeing to use RTP retransmission; and provide the PSI threshold information to the circuitry for sending to the at least one RTP receiving device.

7. The apparatus in accordance with Claim 6 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: provide one or both of the additional transmission information or the PSI threshold information to the circuitry for sending to the at least one RTP receiving device in at least one of a header extension of an RTP packet or session description protocol (SDP) information.

8. The apparatus in accordance with Claim 7 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: when providing the PSI threshold information to the circuitry for sending to the at least one RTP receiving device in the header extension of the RTP packet, also provide a PSI value of a next PDU set in transmission order information in the header extension of the RTP packet.

9. The apparatus in accordance with Claim 7 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: when providing the PSI threshold information to the circuitry for sending to the at least one RTP receiving device in the header extension of the RTP packet, also provide a PSI value of a previous PDU Set in transmission order in the header extension of the RTP packet.

10. The apparatus in accordance with any of Claims 7 to 9 wherein the PSI threshold information comprises one or more of updated PSI information, one or more PSI assignments within a PSI range, or a relative PSI threshold value.

11. An apparatus for real-time transport protocol (RTP) communication comprising: circuitry for receiving RTP packets from and sending data to an RTP sending device; at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: detect one or more unreceived RTP packets during an RTP communication session; and provide a retransmission request to the circuitry for sending to the RTP sending device, wherein the retransmission request includes information indicating the one or more unreceived RTP packets, wherein when the circuitry thereafter receives an RTP retransmission packet, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to derive at least RTP retransmission information from the RTP retransmission packet received.

12. The apparatus in accordance with Claim 11 wherein the RTP retransmission information comprises an RTP header extension, the RTP header extension comprising one or more of a PDU set importance (PSI), a PDU set sequence number (PSSN), a PDU sequence number (PSN), a PDU set size (PSSize), a number of PDUs in the PDU set (NPDS), an end of data burst (EDB) indication, a retransmission packet flag, and/or an end bit (EB).

13. The apparatus in accordance with either Claim 11 or Claim 12 wherein the at least one memory and the computer program code are configured to, with the at least one processor, to cause the apparatus to provide the retransmission request to the circuitry for sending to the RTP sending device after the apparatus and the RTP sending device have agreed to use RTP retransmission.

14. The apparatus in accordance with Claim 13 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: after detecting the one or more unreceived RTP packets during the RTP communication session, determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to PSI values of one or more received RTP packets.

15. The apparatus in accordance with Claim 14 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: derive PSI threshold information from the information in the RTP packets received from the RTP sending device by the circuitry; and determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to the PSI threshold information and the PSI values of one or more received RTP packets.

16. The apparatus in accordance with Claim 15 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: derive next PDU set in transmission order information from an RTP header extension received from the RTP sending device by the circuitry; and determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to the PSI threshold information and the next PDU set in transmission order information.

17. The apparatus in accordance with Claim 15 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to: derive previous PDU set in transmission order information from an RTP header extension received from the RTP sending device by the circuitry; and determine whether to provide the retransmission request to the circuitry for sending to the RTP sending device in response to the PSI threshold information and the previous PDU set in transmission order information.

18. A method for real-time transport protocol (RTP) communication comprising: performing protocol data unit (PDU) set marking for RTP packets during an

RTP communication session by at least generating a header extension for the RTP packets; transmitting the RTP packets with at least the header extension to at least one RTP receiving device; receiving a retransmission request from the at least one RTP receiving device; and transmitting an RTP retransmission packet to the at least one RTP receiving device in response to receiving the retransmission request, the RTP retransmission packet comprising at least RTP retransmission information.

19. The method in accordance with Claim 18 further comprising providing additional transmission information to a network controller handling communication between the RTP sending device and the at least one RTP receiving device in at least one of a header extension of an RTP packet or in control plane signaling by a network application function (AF), the additional information comprising one or more of information indicating the sending device and the at least one RTP receiving device have agreed to use RTP retransmission, information indicating an amount of time which the apparatus maintains an RTP packet for RTP retransmission, one or more PDU set quality of service (QoS) parameters, and information indicating that retransmitted PDUs use the same PSSN as original PDU sets.

20. A method for real-time transport protocol (RTP) communication comprising: detecting one or more unreceived RTP packets during an RTP communication session; transmitting a retransmission request to an RTP sending device, wherein the retransmission request includes information indicating the one or more unreceived RTP packets; and when thereafter receiving an RTP retransmission packet, deriving at least RTP retransmission information from the RTP retransmission packet received.