Financial | Broadcast | Telecommunication | Process Automation | Defence |Space | Power | Traffic Control | Professional Audio Video | Test & Measurement

Time synchronisation for critical networks

PTP in IP Broadcast

Nikolaus Kerö Daniel Boldt

The All-IP Studio

Essence transport is converging towards IP SMPTE ST 2022-6/7 (SDI over IP) VSF TR-03 (video, audio, metadata) AES67 (audio) SMPTE ST 2110-xx

Conventional sync signals are no viable option any longer R.I.P. Black Burst and Tri-Level Sync …

One single scalable network for video/audio/metadata/control/intercom and SYNC !?

Time Transfer in Broadcasting

SDI Frequency Transfer

Relative Phase Transfer (Black-Burst, Tri-Level-Sync) Absolute phase offset

Absolute Time Transfer

All-IP Asynchronous Medium

Packet based Time Transfer PTP – Precision Time Protocol

Frequency

Phase

Absolute Time

PTP Precision Time Protocol

Accurate (sub-µs) time and frequency transfer

Widely used in every Ethernet based application Telecom, Power, Finance, T&M, Industrial automation, …

Highly generic standard Customizable via PTP profiles

PTP Profiles for the Broadcasting SMPTE ST 2059-1/2, AES67

PTP Basic Principles (I)

Simple, hierarchical time transfer One PTP Grandmaster is selected

Two-way time transfer is established to all PTP Slaves

Clock deviation can be calculated and corrected

Autonomous Master Selection BMCA – Best Master Clock Algorithm

Beware of the Transmission Delays

Master

Slave 1

Slave nSlave 2

MasterTime

SlaveTime

12:00

12:00

T2,S

T1,M

Master

SlaveSlave n

Sync message

Delay Response

Delay Request

T3,S

T4,M

OffsetM,S

𝑇2,𝑆 − 𝑇1,𝑀 = 𝑇2,1𝑇4,𝑀 − 𝑇3,𝑆 = 𝑇4,3

𝑂𝑓𝑓𝑠𝑒𝑡 =𝑇2,1 − 𝑇4,2

2

𝐷𝑒𝑙𝑎𝑦 =𝑇2,1 + 𝑇4,3

2

T4,M

PTP Basic Principles (II)

PTP Master Election Process

Based on Announce Messages (and their timeouts) Messages containing information about clock quality

No Master is present (during start-up or Master failure) All nodes „Announce“ their clock properties All nodes converge and select THE single Best Master

A better Master enters the network (i.e. after upgrade) Discovers it has superior clock parameters and announces itself Takes over as the better Master (current Master backs-off)

PTP Basic Principles (III)

Transmission delay ought to be constant Overprovisioning of network Limits in HW architecture of network devices Can be mitigated by prioritizing PTP traffic

Careful planning of network architecture and load

PTP aware network devices Transparent Clocks Boundary Clocks

BCBC

Slave IISlave III

Master

Slave IV

S1

M3 M4 Mn

M2

BMCA for all ports

Slave I

Listen IIListen III

Listen IV

Listen I

L1

L3 L4 Ln

L2

Master I

Slave IISlave III

Slave IV

L1

M3 M4 Mn

S2

BC 2

PTP Boundary Clock

P2

Switch

P1 Pn

Slave nSlave 2

Sync message

Master

TS memory

PTP End2End Transparent Clock

PTP aware network devices (I)

• Boundary Clock (Active PTP Device)• The local clock is synchronized to the Grandmaster• Every port acts as a PTP node (Ordinary Clock)• Time is re-generated and forwarded to all Slaves

• Transparent Clock (Passive PTP Device)• Residence time is measured for every PTP packet• Timestamps are drawn at ingress and egress.• Difference is added to the „Correction Field“

PTP aware network devices (II)

• Boundary clocks• + Good for hierarchical systems

• + Scale well with the number of devices

• + Can translate between different media

• ─ Cascaded Systems require special attention

• ─ Requires continuous monitoring

• End-to-end transparent clocks• + Simple deployment, minimal monitoring

• + Accuracy independent of network topology

• ─ Scale poorly with the number of devices (master sees all slaves)

SMPTE ST 2059-2 – a PTP Profile

Basic Broadcasting requirements Fast Locking … less than 1µs in 5sec Considerably high message rates Various applications

OB VAN

Large studio environments

Backward compatibility to legacy systems Re-generate Sync Signals

Generate Time labels

SMPTE ST 2059-2 – a PTP Profile

Transport Specific IPv4 or IPv6

Multicast, mixed mode, Unicast

PTP network devices All types aware devices are allowed but not mandatory

PTP message rates Sub-Ranges and default values

Synchronization Metadata TLV Additional information on clocks, Daily jam, frame rates, …

Other Standards and Profiles

SMPTE ST 2059-1 – not quite a PTP Profile Time labels

Alignment points for video sync signals WRT to PTP time

AES67- Audio over IP More than a PTP Profile for audio applications

Lower message rates, differing default values

No synchronisation metadata

AES-R16-2016: AES Standards Report PTP parameters for AES67 and SMPTE ST 2059-2 interoperability

Alignment Points

Every node has the SAME absolute time information

Every video signal is assumed to Start at te beginning of the PTP- EPOCH 1.1.1970 00:00:00.0000 Rational frequency

120Hz, 59.97Hz etc.

Every PTP Node can calculate The point in time of the next rising edge in multiples on ns

Large Broadcast Networks

Large set of endpoints operating either as source, destination or both for a set of services including PTP

Defines the number of required port switches

Built around single switch or spine/leaf architecture

Network redundancy is implied Endpoints connected to both networks

Meet the PTP Adversaries

Large PTP Networks Generally, end nodes process all PTP Messages in software

Multicast causes a high load for all nodes

Multicast processing for all nodes needs to be monitored

e.g. 750 Slaves @ 8 msg/s → 12.000 msg /s for each device!

Solutions Mixed Mode: Upstream messages sent in unicast

Partition PTP network using BCs

Dual networks: Timing redundancy

PTP Slave PTP Slave

PTP Grand Master Passive PTP Master

BC BC BC BC

Grandmaster

Slave 2

AuxiliaryMaster

SpineLeaf Leaf

Out-of-BandMeasurement

PTP Aware Network Setup

Slave 1

PTP Simulator750 Slaves

ExternalSynchronisation Out-of-Band

Measurement

N x 3G SDIM x 3G SDI

BC

750 Slaves, Offset viewed by Slave

-600

-400

-200

0

200

400

600

800

1000

1200

0 100 200 300 400 500 600

ns

s

Offset as seen by Slave 1Offset as seen by Slave 2

-600

-400

-200

0

200

400

600

800

1000

1200

0 100 200 300 400 500 600

ns

s

Offset as seen by Slave 1Offset as seen by Slave 2

Hold over until BC chain has settled

New Master at same BC

750 Slaves, Out-of-Band Data

-600

-500

-400

-300

-200

-100

0

100

200

0 100 200 300 400 500 600

ns

s

Out-of-Band measurement Slave 1Out-of-Band measurement Slave 2

-600

-500

-400

-300

-200

-100

0

100

200

0 100 200 300 400 500 600

ns

s

Out-of-Band measurement Slave 1Out-of-Band measurement Slave 2

Master and Slave connected to same BC

3 BCs betweenMaster and Slave

PartiallycompensatedAsymmetry

750 Slaves, Video Traffic, Offset by Slave

-600

-400

-200

0

200

400

600

800

1000

1200

0 100 200 300 400 500 600

ns

s

Offset as seen by Slave 1Offset as seen by Slave 2

750 Slaves, Video Traffic, Out-of-Band

-300

-200

-100

0

100

200

300

0 100 200 300 400 500 600

ns

s

Out-of-Band measurement Slave 1Out-of-Band measurement Slave 2

2048 Unicast Slaves, Video Traffic

-100

-50

0

50

100

0 100 200 300 400 500 600

ns

s

Offset as seen by the SlaveOut-of-Band Offset measurement

Fault Tolerance in PTP

BMCA addresses only a subset of fault conditions Triggered ONLY by Absence of Announce Messages

Announce rates and timeouts have to be configured identically across all nodes

Absence of PTP event messages remains undetected Errors in PTP devices

Misconfigured network and/or end devices

Sudden changes/deteriorations in the network Path changes

Bandwidth overload

PTP defines ONLY a protocol but NOT a specification of the servo Reaction to network load changes is implementation dependent

Why Monitor a PTP Network?

Querying Slaves via PTP Management messages is insufficient Only current offset as seen by the Slave is reported Asymmetries are not accounted for

Out-of-Band measurement techniques are required 1-PPS Signals

Why Monitor a PTP Network?

All auxiliary Masters are hot stand-by devices PTP State … PASSIVE

Auxiliary Masters have to be verified prior to engaging them Path to Auxiliary Master could be broken Clock quality could have degraded Loss of external time source

PTP Aware Network Devices need to be monitored as well!

Extended Monitoring

T02 𝑇02 − 𝑇01 = 𝑇21𝑇04 − 𝑇03 = 𝑇43

𝑂𝑓𝑓𝑠𝑒𝑡 =𝑇43 − 𝑇21

2,

𝐷𝑒𝑙𝑎𝑦 =𝑇21 + 𝑇43

2

MonitoringSystem

12:00

T01

T03

Slave

12:00

Master Slave12:00

12:00

Del_Req

Sync

Del_Resp

T04

Sync

Del_Req + TLV

Del_Resp + TLV

GPSGPS

PTP Unaware Network Topology

Grandmaster SlaveAuxilliary Master

40G 40G 40G

1G

1 PPS

1 PPS

1G

SpineLeaf Leaf Leaf

Out-of-Band Measurement

Master to Slave Delay

0

2000

4000

6000

8000

10000

12000

0 200 400 600 800 1000 1200 1400 1600 1800

ns

s

Filtered Offset viewed from the Slave

-100

-50

0

50

100

0 200 400 600 800 1000 1200 1400 1600 1800

ns

s

Offset measured out-of-band

-100

-50

0

50

100

0 200 400 600 800 1000 1200 1400 1600 1800

ns

s

9 Hops /w no PTP Support – 120% load

-2000

-1500

-1000

-500

0

500

1000

1500

0 50 100 150 200 250 300 350

ns

s

"filtered.dat"

Conclusions

PTP scales for any broadcasting application Fast locking, large number of Slaves, …

Sub-µs accuracy can be achieved easily

Time transfer is mission critical! GM redundancy is required and supported

Use PTP aware network devices whenever possible

Continuous monitoring is mandatory

Thank you

Strontium-ion optical clock at NPL UK - 100ns deviation per 100 years

Meinberg Funkuhren GmbH & Co. KG

www.meinbergglobal.com

PTP in IP BroadcastIP Transport Standards, Interoperability and real-world projects

Daniel Boldt

Current Studio Transport Technology: SDI

• SDI = Serial Digital Interface• Professional Studio Infrastructure for uncompressed video & audio• Coax (BNC 75 Ohms) for bitrates between 270MBit (SD) to 12GBit (UHD)

• Pro SDI: • Robust, well-known technology• Easy to understand• Easy to build• Infrastructure is sufficient for existing workflows (until now)

• Contra SDI:• Scalability is limited• Essences are always bound (video, audio, ancillary data altogether)• Extensions are complex (many heavy cables) -> especially for OB Trucks• Physical limits for the bandwidth seem to be reached• Demux/Mux processing everywhere to seperate and recombine streams

Motivation for IP Transport

www.aimsalliance.org

Motivation for IP Transport – Logical Consequence?

Advertisement (Cinegy)

Signage seen at IBC

IP Audio / Video Transport

www.aimsalliance.org

IP Audio / Video Transport

SMPTE ST 2022-1/2/3/4 MPEG2 Transport Stream over IPSMPTE ST 2022-5/6 SDI over IP

Both standards are „Multiplex Standards“.Video, Audio and ancillary data are packed as a common IP stream

A receiver always has to receive the full stream, even if it is interested only in one singleembedded stream.

• IP is actually a multiplex standard -> Why should not every packet be part of a different stream?

• Solution: VSF TR-03 -> now evolved to SMPTE ST 2110:• Every part of a media signal is a seperate IP data stream.

• A receiver only gets the data that he needs. -> Bandwidth efficiency!

IP Audio / Video Transport – TR-03

www.aimsalliance.org

IP Transport – SMPTE ST 2110

SMPTE ST 2110 – 10 System Timing - incl. PTP and how it is used in 2110 (public)

• PTP is sent out to every system as a common time base. • The „Transmitters“ label every packet with an RTP time stamp that represents the

sampling time• The „Receivers“ can now re-arrange these streams correctly with these time stamps

as they have also a locally synchronised clock via PTP• SDP -> Session Description Protocol – Contains information about every stream

SMPTE ST 2110 – 20 Uncompressed Video (public)• Uses IETF RFC 4175• Only the active video lines are sent (no vertical blanking)

-> optimized bandwidth efficiency

IP Transport – SMPTE ST 2110

SMPTE ST 2110 – 21 Traffic Shaping Uncompressed Video

SMPTE ST 2110 – 30 PCM Digital Audio (public)

• Uses AES67 with very few limitiations or restrictions

SMPTE ST 2110 – 31 AES3 Digital Audio

SMPTE ST 2110 – 40 Ancillary Data

SMPTE ST 2110 – 50 Compatibility to ST 2022-6 (Video only, TR-04)

AIMS

AIMS, the Alliance for IP Media Solutions (AIMS), is a non-profit trade alliance that promotes theopen standards that broadcast and media companies use to move from legacy SDI systems to a virtualized IP based future — quickly and profitably.

AIMS is also a big sponsor of the IP Showcase Events at IBC and NAB which are the main tradeshows of the broadcasting industry.

As AIMS fosters the adoption of open standards in the broadcasting industry, they automaticallypush the use of PTP in this field.

http://www.aimsalliance.org

The way to SMPTE ST 2110

www.aimsalliance.org

Joint Task Force of Networked Media Roadmap

SMPTE Interop Tests und ShowcasesInteroperability Events for SMPTE ST 2059 and ST 2110

Goals:- Verification of the PTP Profile SMPTE ST 2059-2, ensure interoperability between vendors→ PTP implementation correct?→ Performance specification fulfilled?→ Test of baseband signals (black burst) -> aligned with PTP?

2015, November: 1st Interop: SMPTE ST 2059 PTP Tests2016, Juni: 2nd Interop: 2059 PTP Tests2016, August: 3rd Interop: IBC Showcase planning, TR-03, incl. JT-NM, AES2016, September: IBC Amsterdam: IP Interoperability Zone2017, Februar: 4th Interop: VSF, SMPTE 21102017, März: 5th Interop: 2059 PTP Tests incl. Timecode2017, April: NAB Pre-Staging (JT-NM, AES, AIMS), SMPTE ST 2110, Preparation IP Showcase2017, April: NAB Las Vegas: IP Showcase -> SMPTE ST 2110 Final Draft2017, August: IBC Pre-Staging (JT-NM), Preparation IP Showcase2017, September: IBC Amsterdam: IP Showcase -> SMPTE ST 2110, Playout, Live Production

2018: IP Showcase preparations for NAB

SMPTE Interop Tests at FOX, Houston

IBC IP Interoperability Zone 2016, Amsterdam

NAB IP Showcase 2017, Las Vegas

NAB IP Showcase 2017, Las Vegas

https://youtu.be/9t8J3ABJm7s

IBC IP Showcase 2017, Amsterdam

• Largest IP Showcase until today• More than 50 companies contributing• Dedicated sections for Live Production,

Connection Management and Playout

PTP in IP Broadcast studios

SMPTE defined a standard ST 2059 for „Genlock over IP“

Source: Sony

SMPTE ST 2059-1 Relationship to baseband timing signals

SMPTE ST 2059-1 defines alignment points (events) to re-generate a black-burst or tri-level sync signal. SMPTE uses uneven media frequencies (non-integer)

-> both sources need to be combined

PTP synchronised clock

Hybrid Timing Infrastructure

PTP Can Coexist with Legacy References in Same FacilityGPS

PTP

Network Fabric (cloud of switches)Centralized Equipment

Facility Equipment

PTP Slave

PTP Slave1

Legacy Master 1 BlackBurst

DARS

TimecodePTP Slave2

Legacy Master 2

Autochangeover

PTP

Grandmaster 1

Grandmaster 2

`` `

``

``

``

`

BlackBurst

DARSTimecode

Facility Equipment

Legacy Slave

© Paul Briscoe

Project BCE Luxemburg (RTL City)

The RTL group is Europe‘s largestbroadcaster

The „RTL City“ project was launched 2013 to consolidate all of RTL‘s operations at itsnew headquarters in Luxemburg. Seven new buildings have been build witha total cost of 105 Million Euros

BCE is the in-house system integrator for the RTL Headquarters in Luxemburg

Project BCE Luxemburg (RTL City)

Requirements: • Support all RTL activities as a minimum of 10 years and adapt to new workflows• All-IP production environment if possible• SMPTE 2022-6/-7 plus AES67 with upgrade option to TR-03 / SMPTE 2110

-> requires PTP Timing• Future proof, scalable, flexible and vendor neutral -> Usage of open standards

• November 2014: Concept / Planning• July 2015: Proof Of Concept• September 2015: Proof of Interoperability• December 2015: Final decision of technologies and products, Pilot phase• Early 2017: On Air with Phase 1

Project BCE Luxemburg (RTL City)

Decision was made to use of standards that rely on seperate streams for Audio and Video.-> SMPTE ST 2022-6 + AES67 as additional audio streams,

VSF TR-03, SMPTE 2110 (upgrade)

This architecture requires PTP synchronisation

• Large number of PTP Slaves (> 2300 in last phase)• Redundant network switch architecture (SMPTE ST 2022-7) with multiple vendors

(Juniper, Arista)• No boundary clock usage considered due to switch vendors roadmap time scales

-> End to End PTP approach requires powerful PTP Grandmaster port.2300 clients cause 18400 Delay Requests per second with default SMPTE profilesettings

Project BCE Luxemburg (RTL City) – System Timing

PTP ST 2059-2 „BC“

© SAM, Phil Myers

PTP Hybrid Mode:

>2300 PTP Slaves viaTransparent ClocksRedundant ST 2022-7 network

PTP over WAN

Challenges when using PTP over WAN connections:

• Unpredictable Packet Delay Variation Jitter that affects Slave accuracy and stability(„Dynamic Time error“ - dTE)

• Unknown Asymmetry for Receive and Transmit path (Constant Time Error - cTE)• Network Path Re-arragements can lead to asymmetry changes (Offset Steps)

• Solution:• PTP Gateway Clock at remote site that filters the PTP signal• High-Quality oscillator necessary to bridge holdover and statisitic measurement periods• Advanced adaptive filter mechanisms in Slave clock• Asymmetry Step detection mechanism• Automatic PTP Bias Offset calibration to reference source (e.g. GPS)

• Gateway clock („Edge Grandmaster“) provides „clean“ PTP Master signal to local PTP clientsat remote site

PTP over WAN – Accuracy GM output

Measurement Setup:LANTIME M3000, GPS synced, PTP GM, PPS out as ReferenceCalnex Paragon-X as Measurement Unit

Graph:M3000 PTP output vs. M3000 PPS reference

PTP over WAN – Accuracy PTP Slave after TC

Measurement Setup:

LANTIME M3000, GPS sync, PTP GM, PPS outOregano syn1588 GBit Switch as Transparent ClockLANTIME M1000, PTP Slave input, PPS out

Graph:M1000 PPS output vs. M3000 PPS reference output

PTP over WAN with Edge Grandmaster solution

PTP over WAN – Accuracy after 10 HOPs (no PTP support)

Simulated congestednetwork over 10 Hops

Packet delay variation> 100 µs (Master->Slave)> 60 µs (Slave ->Master)Resulting Asymmetry:approx. 8 µs

Calnex Paragon-X used asImpairment generator

PTP over WAN – Accuracy after 10 HOPs (no PTP support)

Simulated congestednetwork over 10 Hops

Packet delay variation> 100 µs (Master->Slave)> 60 µs (Slave ->Master)Resulting Asymmetry:approx. 8 µs

PTP connection with64 Syncs/s and 64 DelayReq/s

GPS antennadisconnected fromPTP Slave after 2 hoursContinue with PTP only

Maximum phase error:< 300 ns within 3 days

GPS disconnected

WDR - DVB-T2 Synchronisation with backup over WAN

WDR: DVB-T2 Transmitter Synchronisation with PTP backup

WAN

PTP Master PTP Slave

DVB-T2 Transmitter Location (Langenberg)

Central PTP Grandmaster (Cologne)GPS GPS

Priority 1: GPSPriority 2: PTP

PTP Profile:ITU-T. G.8275.2 8x 1-PPS Out / 8x 10 MHz OUT

- Local PTP Master- Word Clock / DARS- NTP Server- 1-PPS / 10 MHz- Black Burst

WDR - Remote Studio Synchronisation

Synchronisation of distributed remote radio studios for AES67/RAVENNA Audio equipmentSeparated Frequency, Phase and Time-of Day references

WAN

- Remote PTP Master (TOD,Phase)- 2.048 kHz Out

Remote Studio (Düsseldorf)„PTP Gateway“

Sync Master (Cologne)GPS

Priority 1: 2048 kHz INPriority 2: PTP IN„Hybrid Clock“

PTP Profile: ITU-T G.8275.22.048 kHZ via NetInsight NIMBRAor: PTP only via Dark Fibre

- Local PTP Out-> AES67 Media Profile- Word Clock / DARS Out

- Local PTP Master- Word Clock / DARS- NTP Server- 1-PPS / 10 MHz- Black Burst

Life is all about having a good time.

www.meinbergglobal.com