Timing & Synchronization in AES67 & ST2110: Why PTP is at the Heart of your MoIP System – Andreas Hildebrand — ALC NetworX

Presenters : Andreas Hildebrand - ALC NetworX

Year : 2022

dlp_document_download : # 1Comparison of Clocking & Synchronization in RTP, RAVENNA/AES67 & ST2110, AVB and IPMX:MoIPPavilion @ AES New York 2022Andreas Hildebrand, ALC NetworX"Do we really need PTP?" # 2Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) Andreas Hildebrand, RAVENNA Technology Evangelist•more than 25 years in the professional audio / broadcasting industry•graduate diploma in computer science•R&D, project& productmanagementexperience•memberof AES67 TG andST2110 DGALC NetworX GmbH, Munich/ Germany•established2008•R&D center•developing& promotingRAVENNA•Partnershipswith> 40 manufacturersRAVENNA•IP medianetworkingtechnology•designedtomeetrequirementsof professional audio / broadcastingapplications•open technologyapproach, license-free•fully AES67-and SMPTE ST2110-compliant # 3Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) •Media bit-transparency àno sample rate conversionàstreams need to run on same media clock•Concurrent operation of different sample rates on same network•Determinable (low) end-to-end latency•Time alignment between media streams•Replacement for "house clock" distribution (word clock, black burst etc.) ðClock reassembly from stream data not applicableðDistribution of master clock beats not sufficientðCommon understanding of reference time required ("wall clock")Timing & Synchronization –General RequirementsMedia clock=Sampling rate> asynchronous <> syntonous<> synchronous < # 4Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) •Audio applications have highest time accuracy & precision demands:ðSample accurate alignment of streams (±½ sample)Timing & Synchronization –Accuracy RequirementsTra n s m i tt e rReceiver 1Receiver 2Ɵ < +½ƮƟ < -½ƮƟ < 1ƮSample xSample xSample x # 5Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) •Audio applications have highest time accuracy & precision demands:ðSample accurate alignment of streams (±½ sample)-@ 48 kHz: ±10 µs-@ 96 kHz: ±5 µs-@ 192 kHz: ±2.5 µsð"Distribution" of word clock reference (AES11 calls for ±5% max jitter / wander):Timing & Synchronization –Accuracy RequirementsTra n s m i tt e rReceiver xƟ <= ±0,05*Ʈ # 6Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) •Audio applications have highest time accuracy & precision demands:ðSample accurate alignment of streams (±½ sample)-@ 48 kHz: ±10 µs-@ 96 kHz: ±5 µs-@ 192 kHz: ±2.5 µsð"Distribution" of word clock reference (AES11 calls for ±5% max jitter / wander):-@ 48 kHz: ±1 µs-@ 96 kHz: ±500 ns-@ 192 kHz: ±250 nsTiming & Synchronization –Accuracy Requirements # 7Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) RTP (RFC 3550)Vari ous Cl oc ki ng & Sync hroni zati on Model sRAVENNA/AES67 & SMPTE ST 2110-10AVB / TSN (IEEE 802.1)IPMX # 8RFC 3550Do we really need PTP? –A. Hildebrand (ALC NetworX) •(external or internal) media clock drives sampling•RTP clock is derived from media (sampling) clock-Relation S(offset between media and RTP clock) is established on stream start-up-Smay be random to defeat crypto attacks-This offset will be constant throughout the stream’s lifetime•Received samples will be stored in a (jitter/delay) buffer with configurable delay (1)•Sender’s media clock is recreated through adaptive algorithm observing receive buffer fill level (2)•Samples are played out following recreated media clockGeneric RTP clocking (linear PCM audio) –asynchronous case (no "wall clock") SenderReceiverRTP clockStream dataSMedia dataDAMedia clockMedia data(2)(1)AD # 9RFC 3550Do we really need PTP? –A. Hildebrand (ALC NetworX) Main benefits / drawbacks:+Any input signal (any media clock) can be transported and reasonably-well be resembledoDepending on quality of sender / receiver clock circuitry-No concurrent processing of independent streamsoSRC required-No deterministic latencyoNo alignment between streamsGeneric RTP clocking (linear PCM audio) –asynchronous case (no "wall clock") # 10RFC 3550Do we really need PTP? –A. Hildebrand (ALC NetworX) •(external or internal) media clock drives sampling•RTP clock is derived from media (sampling) clock-Relation S(offset between media and RTP clock) is established on stream start-up-Smay be random to defeat crypto attacks-This offset will be constant throughout the stream’s lifetime•Received samples will be stored in a (jitter/delay) buffer with configurable delay (1)•Sender and receiver media clocks may also be syntonized by external means (i.e., distribution of common reference clock) (3)Generic RTP clocking (linear PCM audio) –syntonouscase (external "house clock") SenderReceiverRTP clockStream dataSMedia dataDAMedia clockMedia data(2)(1)AD(3) Reference clock # 11RFC 3550Do we really need PTP? –A. Hildebrand (ALC NetworX) Main benefits / drawbacks:+All media clocks are following a common reference clockoSame media clock for all streams+concurrent processing of independent streams possibleoNo phase / time alignment-No deterministic latencyGeneric RTP clocking (linear PCM audio) –syntonouscase (external "house clock") # 12RFC 3550Do we really need PTP? –A. Hildebrand (ALC NetworX) 1)With common reference clock ("wall clock")2)Without common reference clock ("wall clock")ðIPMXRTP clocking w/ RTCP* Sender Reports (linear PCM audio)* RTCP –RTP Control Protocol (partofRFC 3550) # 13AES67 (& RAVENNA & SMPTE ST 2110)Do we really need PTP? –A. Hildebrand (ALC NetworX) •All nodes are running local clocks •Local clocks are precisely synchronized to a common wall clock via PTP•Media clocks are generated locally from synchronized local clockAES67 synchronization & media clocks # 14AES67 (& RAVENNA & SMPTE ST 2110)Do we really need PTP? –A. Hildebrand (ALC NetworX) Master ClockSlave Clocks(nodes)Media ClocksPTPAES67 synchronization & media clocks # 15AES67 (& RAVENNA & SMPTE ST 2110)Do we really need PTP? –A. Hildebrand (ALC NetworX) •Relation Sis established on stream start-up•Smay be random to defeat crypto attacks•This offset will be constant throughout the stream’s lifetimeAES67 synchronization & media clocks•The offset (S) will be conveyed via SDP (a=mediaclk:direct=<offset>)SenderReceiverWall clock(PTP Grandmaster)LocalclockLocalclockMedia clockStream clockStream data(copy)(copy)SSDPMedia clockPTPPTP # 16AES67 (& RAVENNA & SMPTE ST 2110)Do we really need PTP? –A. Hildebrand (ALC NetworX) •Relation Sis established on stream start-up•Smay be random to defeat crypto attacks•This offset will be constant throughout the stream’s lifetimeAES67 synchronization & media clocksSMPTE ST 2110•The offset (S) will be conveyed via SDP (a=mediaclk:direct=<offset>)SenderReceiverWall clock(PTP Grandmaster)LocalclockLocalclockMedia clockStream clockStream data(copy)(copy)SSDPMedia clockPTPPTP–must be "0" in ST2110S=0 # 17AES67 (& RAVENNA & SMPTE ST 2110)Do we really need PTP? –A. Hildebrand (ALC NetworX) AES67 synchronization -link offset (latency)RTP timestampof(first) sample (in packet)Desiredplayouttime forsampleRTP offsetSDP (a=mediaclk:direct=<offset>)+- # 18RFC 3550Do we really need PTP? –A. Hildebrand (ALC NetworX) Main benefits / drawbacks:+All media clocks are following a common referenceoAccurate reproduction of reference clock at all local nodesoIdentical / phase-accurate media clocks for all streams+concurrent processing of independent streams+Deterministic latency+Sample-accurate alignment of streams possible-Asynchronous input signals require SRCAES67 synchronization & media clocks # 19Ethernet AVB (& MILAN)Do we really need PTP? –A. Hildebrand (ALC NetworX) AV B t i m e s t a m p i n g & c l o c k r e c o v e r y s y s t e mTalker (sender):•Audio is sampled with an external reference (sample) clock at the talker•Clock edges are time-stamped with AS wall clock time•N samples (as defined by DBC) and 1 referring time stamp w/ desired presentation time (usually sample time + 2 ms) are packetized # 23Ethernet AVB (& MILAN)Do we really need PTP? –A. Hildebrand (ALC NetworX) AV B t i m e s t a m p i n g & c l o c k r e c o v e r y s y s t e mTalker (sender):•Audio is sampled with an external reference (sample) clock at the talker•Clock edges are time-stamped with AS wall clock time•N samples (as defined by DBC) and 1 referring time stamp w/ desired presentation time (usually sample time + 2 ms) are packetized Listener (receiver):•Receiver regenerates media clock from DBC value and subsequent time-stamp values (n clock edges within t2–t1)•De-packetized samples are buffered and played-out at their respective presentation time # 26Ethernet AVB (& MILAN)Do we really need PTP? –A. Hildebrand (ALC NetworX) AV B t i m e s t a m p i n g & c l o c k r e c o v e r y s y s t e mMain benefits / drawbacks:+Variable input clocking+Deterministic latency (presentation time)o(Precise) reassembly of input media clock§Depending on quality of sender / receiver clock circuitry§Frequency-locked, but most likely not phase-locked-No concurrent processing of independent streamsoSystem-wide synchronization requires synchronization of media clocks to a reference streamðDefinition of CRF (clockreferenceformat) in P1722-2016 (usedbyMILAN) # 27IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) •IPMX definesa setofcommon, ubiquitous, open and standards-basedprotocolsforinteroperabilityover IP fortheProAVindustry.•IPMX is based on the proven SMPTE ST 2110 standard, but adapted / enhanced specifically for ProAVneeds:•enhanced / "relaxed" timing requirements•supporting any bitrate with compressed or uncompressed streams•video format-agnostic•HDCP copy protection•network discovery and registration•I/O management•The goal of IPMX is simple deployment, requiring only basic networking equipment (and knowledge?)What is IPMX? # 28IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) •IPMX thrives to support the full range from oprofessional live production systems (aka SMPTE ST 2110), oover large synchronous / syntonousor asynchronous AV systems odown to a 1:1 connection between sender and receiver (i.e., HDMI source + display) •Broadcast: devices locked to "house sync" (synchronous / syntonousoperation with common reference clock)•Non-broadcast / ProAV: asynchronous signal transport (with or without common reference cock)•IPMX supports networks WITHand WITHOUTPTPoIPMX specifies what do in presence of PTPoIPMX specifies how to operate when PTP is not presentoIPMX devices need to support both modes (!)IPMX Clocking & Synchronization # 29IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) Current draft confusing on several aspects: •PTP shall be supported… (in case IPMX devices are to be integrated in broadcast applications)… but is not required (in "simple" applications w/o need for alignment among various senders /receivers)… and thus, needs not to be supported at all… (???)•"A l l I P M X R e c e i v e r s h o u l d r e c o v e r t h e A s y n c s i g n a l t i m i n g a n d p r o d u c e a n o u t p u t s i g n a l t h a t i s f r e q u e n c y l o c ke d to the IPMX Sender."… but mechanism of clock recovery from async stream sources not explicitly described•Ambiguous stream alignment requirements oRefers back to SMPTE ST 2110 "DLO" (aka AES67 "Link Offset")… but works only if common reference clock (aka PTP) is present… or among streams originating from the same sender … (really?)IPMX Clocking & Synchronization # 30IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) IPMX Clocking & SynchronizationIPMX basically defines 3 synchronization & clocking modes:1)SMPTE ST 2110 (synchronous operation)•All input signals are synchronized by common reference clock (aka PTP) # 31IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) IPMX Clocking & SynchronizationIPMX basically defines 3 synchronization & clocking modes:1)SMPTE ST 2110 (synchronous operation)•All input signals are synchronized by common reference clock (aka PTP)2)RFC 3550 asynchronous operation (with common reference clock)•Input signals are asynchronous•Internal clocks are synchronized to common reference clock (aka PTP)•Requires RTCP SR with PTP/RTP timestamp pairsðSimilar to AVB operation # 32IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) RTPIPMX Clocking & SynchronizationPTPRTPtimestampgeneratorRTPdataRTCP SR packetswithRTP/PTPtimestampsRTP packetsRTCP SR packetswithRTP/PTPtimestampsRTP packetsRTCP SR packetswithRTP/PTPtimestampsRTP packetsRTCP SR packetswithRTP/PTPtimestampsRTP packetsRTCP SR packetswithRTP/PTPtimestampsRTP packetsRTCP SR packetswithRTP/PTPtimestampsRTP packetsRTP packetRTCP SR packetRTCP SRRTPOutgoingstreamsPTPPTP # 33IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) IPMX Clocking & SynchronizationIPMX basically defines 3 synchronization & clocking modes:1)SMPTE ST 2110 (synchronous operation)•All input signals are synchronized by common reference clock (aka PTP)2)RFC 3550 asynchronous operation (with common reference clock)•Input signals are asynchronous•Internal clocks are synchronized to common reference clock (aka PTP)•Requires RTCP SR with PTP/RTP timestamp pairs3)RFC 3550 asynchronous (without common reference clock)•Input signals are asynchronous•Internal clocks are free-running•IPMX also requires RTCP with NTP/RTP timestamp pairs, but receivers do not have a reference for the NTP timestamp information (RFC 3550: NTP timestamp field may also be 0)oRelative difference of consecutive NTP timestamps could be used for receiver ’s internal clock adjustment, but very unpreciseðBetter to be treated as RFC 3550 generic asynchronous RTP mode (receiver buffer fill level) # 34IPMXDo we really need PTP? –A. Hildebrand (ALC NetworX) … is actually trying to incorporate all 3 synchronization methods:•RTP generic clockingðfree-running / asynchronous media clock with clock recovery from stream•RAVENNA/AES67 & SMPTE ST 2110-10ðmedia clock derived from common (PTP) reference clock•AVB timestamping & clock recovery systemðfree-running media clock w/ timestamping against common reference clock (RTP/PTP timestamp correlation via RTCP SR)IPMX Clocking & Synchronization # 35Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) Do we really need PTP?PTP enables:•Ver y precise clocking•Synchronous operation of a complete system•Tra n s p o r t o f sy n c h ro n o u s a n d a sy n c h ro n o u s i n p u t s i g n a l s•Perfect alignment of any streams anywhere in the network•But:oMost likely more complex network designWithout PTP:•Less complex network design•But:oNo synchronous operation at all (all streams / devices operate independently from each other)oNo alignment of streams (except for streams originating from the same sender)FUNCTIONALADVANTAGES # 36Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) Do we really need PTP?PTP enables:•Ver y precise clocking•Synchronous operation of a complete system•Tra n s p o r t o f sy n c h ro n o u s a n d a sy n c h ro n o u s i n p u t s i g n a l s•Perfect alignment of any streams anywhere in the network•But:oMost likely more complex network designWithout PTP:•Less complex network design•But:oNo synchronous operation at all (all streams / devices operate independently from each other)oNo alignment of streams (except for streams originating from the same sender)EASEOFUSE # 37Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) Questions? # 38Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) More information…www.ravenna-network.com/resourcesRAVENNA / AES67 / SMPTE ST 2110 Resources:ravenna@alcnetworx.dewww.aimsalliance.org (resources) # 39Do we really need PTP?Do we really need PTP? –A. Hildebrand (ALC NetworX) Contact information:www.ravenna-network.comAndreas HildebrandALC NetworX GmbHravenna@alcnetworx.de12X