RTP Header Extensions for In-Band Delay Measurement
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing technologies face challenges in accurately measuring end-to-end transportation delay and processing delay of data packets, particularly in extended reality (XR) applications where packets traverse diverse networks, leading to variability in delay measurements.
Innovation Solution
The use of Real-Time Transport Protocol (RTP) header extensions for determining delay measurements, where binding information associates two RTP header extensions with timestamps to calculate delays, is proposed. This method involves transmitting and receiving SDP messages with binding information, and determining delays based on the timestamps included in the RTP packets.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If packets traverse diverse networks (5G, Wi-Fi, Internet), then network coverage and connectivity are improved, but delay measurement accuracy deteriorates due to variable network conditions
Solution Approach 1:
The patent introduces RTP header extensions as intermediary structures that carry timestamp information across diverse networks. These extensions act as mediators between different network types (5G, Wi-Fi, Internet), enabling consistent delay measurement by embedding timing data in the packet headers themselves, regardless of the underlying network infrastructure.
Solution Approach 2:
The patent implements preliminary timestamping at the source device before packets enter the network. By recording the send time in RTP header extensions advance, the system establishes a reference point that remains valid throughout packet transmission across multiple networks, eliminating the need for complex synchronization at each network node.
2Measurement precision
If RTP header extensions are used for delay measurement, then measurement accuracy is improved, but protocol complexity increases
Solution Approach 1:
The patent makes RTP header extensions multi-functional by using them for both existing RTP purposes (synchronization, timing) and the additional function of carrying delay measurement timestamps. This universal approach allows the same header extension structure to serve multiple purposes without requiring separate dedicated fields, thereby minimizing the increase in protocol complexity.
Solution Approach 2:
The patent merges the delay measurement function with the existing RTP header extension mechanism. Instead of creating a separate measurement protocol, the invention combines timestamp embedding, binding information exchange, and delay calculation into the existing RTP framework, thereby reducing overall system complexity while maintaining measurement accuracy.
3Reliability
If binding information is exchanged via SDP messages, then delay measurement reliability is improved, but setup time increases
Solution Approach 1:
The patent performs binding information exchange during the initial SDP negotiation phase of RTP session setup. By establishing the relationship between timestamps in different RTP header extensions at this preliminary stage, the system ensures that delay measurement can proceed reliably without additional setup time during actual data transmission.
Solution Approach 2:
The patent implements a feedback mechanism where binding information about timestamp relationships is exchanged and confirmed during SDP negotiation. This feedback loop ensures that both endpoints agree on the timing relationships before data transmission begins, establishing reliable delay measurement foundations without requiring ongoing setup adjustments.
Data Source
AI summary
An example method includes sending or receiving a session description protocol (SDP) message that includes binding information that associates a first RTP header extension and a second RTP header extension for an RTP session, wherein the binding information is indicative of a first timestamp in the first RTP header extension, and the first timestamp in the second RTP header extension, both being indicative of a time at which a first RTP packet including the first RTP header extension is transmitted. The method includes transmitting, by a first device, the first RTP packet and receiving, by the first device, a second RTP packet, the second RTP packet including the second RTP header extension including the first timestamp, a second timestamp, and a third timestamp. The method includes determining, based on at least one of the first timestamp, the second timestamp, or the third timestamp, a delay.