Cisco Archives – The Broadcast Knowledge

Video: Precision Time Protocol (PTP) Clock Types

Posted on 20th April 2021 by Russell Trafford-Jones

Part II in this Cisco series on PTP, Precision Time Protocol, focuses on Boundary Clocks and Transparent Clocks. Last week we heard how PTP maintains accurate time by calculating the delay between clocks and the grandmaster clock which is the source of time for the network. This video summarises how to distribute that source of time to all your devices and how to choose between the two methods.

Albert Mitchell from Cisco explains that transparent clocks are just that, they transparently let the timing data flow through. All they do is update the timestamps on the outgoing packets to compensate for the extra time getting through the switch. A boundary clock (BC), however, is a source of time of itself but gets its time from the grandmaster like any other clock. Acting in this dual way, it creates the boundary it’s named after. It’s a boundary because it provides time to other end devices on the network, These devices never see the grandmaster, they only see the BC. Likewise, the grandmaster only sees the BC acting like any ordinary clock sending delay requests. This means that the boundary clock can shield the grandmaster from the rest of the devices on the network. A grandmaster with 10 boundary clocks can deliver time to over a thousand endpoints without a problem. Without the boundary clocks, the grandmaster may not be able to handle the two-way conversations necessary with so many clocks.

For broadcast networks, boundary clocks are preferred as they enable easier diagnosis and can reduce the blast radius of problems. Importantly they can span multiple VLANs. Other benefits are that they filter packet delay variation and shields the downstream/following clocks from any transient changes in the grandmasters. The downside of BCs is that they do add small errors to the timing which can add up if multiple BCs are concatenated.

Transparent clocks, on the other hand, don’t help with scalability like BCs and are limited to single VLANs. On the plus side, they require no configuration and provide faster convergence.

Lastly, Albert looks at the Best Master Clock Algorithm (BMCA) which is the method used to determine which grandmaster is providing timing to the whole network. For a deeper dive into the BMCA, have a look at this Arista video on PTP timing. Albert gives a good starting overview of how the algorithm works, the data it needs to operate and advice on settings to make sure you know which clock will win in each instance.

Watch now!
Speakers

Albert Mitichell
Technical Marketing Engineer,
Cisco

Video: Introduction to Precision Time Protocol (PTP)

Posted on 14th April 2021 by Russell Trafford-Jones

As we’ve seen in so many videos, PTP is fundamental to large-scale SMPTE ST 2110 and pro-audio installations. On The Broadcast Knowledge we’ve looked at a large range of talks on PTP on architecture, scaling, and how it fits in to the broadcast industry. Few of these break down PTP into the fundamentals like today’s article about a video from Albert Mitchell from Cisco.

The key to a PTP network is having one grandmaster clock which can provide time for the rest of the network. In this article, the clocks running in the end devices are called ‘ordinary clocks’. Whilst there are ways to avoid using PTP with uncompressed video such as ST 2110, for live, studio-style productions where you will be bringing them together in a video mixer or similar, keeping these videos effectively zero latency is important and frame syncs on every input of the mixer are discouraged. A grandmaster clock can provide the timing the whole network needs to make this work, usually fed by GPS time.

SMPTE’s ST 2110 suite has built itself on the timing mechanism of PTP in form of IEEE-1588. SMPTE ST 2059 standards suite provides a method to accommodate all legacy reference and media signals using IEEE-1588 Precision Time Protocol (PTP), delivered over an IP network.

Albert moves on to how this all works. He keeps it simple explaining that there are two measurements needed to get the timing right. You need to know how long it takes to get a message from the grandmaster to the clock and how long it takes to get a message from the clock to the grandmaster. If the grandmaster sends a message with the time in it, it’s trivial for the ordinary clock to look at the time when the message arrived and work out the time it took. It can do the same; an ordinary clock can put the time into a message and send it to a grandmaster. The grandmaster will look at the current time and reply saying how long the transmission delay was. The ordinary clock averages these two measurements and can use the result and the time from the grandmaster to correct its own clock.

Albert finishes by explaining that if there are other switches between the grandmaster and the ordinary clock, those switches should be expected to identify the ‘residence time’ and add this extra delay of simply going through the switch to the time message. Changes in network delay due to congestion or path changes are the reason this timing calculation happens once a second.

Watch now!
Speakers

Albert Mitchell
Technical MArketing Engineer,
Cisco

Video: Preparing for 5G Video Streaming

Posted on 6th October 2020 by Russell Trafford-Jones

Will streaming really be any better with 5G? What problems won’t 5G solve? Just a couple of the questions in this panel from the Streaming Video Alliance. There are so many aspects of 5G which are improvements, it can be very hard to clearly articulate for a given use case which are the main ones that matter. In this webinar, the use case is clear: streaming to the consumer.

Moderating the session, Dom Robinson kicks off the conversation asking the panellists to dig below the hype and talk about what 5G means for streaming right now. Brian Stevenson is first up explaining that the low-bandwidth 5G option really useful as it allows operators to roll out 5G offerings with the spectrum they already have and, given its low frequency, get a good decent a propagation distance. In the low frequencies, 5G can still give a 20% improvement bandwidth. Whilst this is a good start, he continues, it’s really delivering in the mid-band – where bandwidth is 6x – that we can really start enabling the applications which are discussed in the rest of the talk.

Humberto la Roche from Cisco says that in his opinion, the focus needs to be on low-latency. Latency at the network level is reduced when working in the millimetre wavelengths, reducing around 10x. This is important even for video on demand. He points out, though that delay happens within the IP network fabric as well as in the 5G protocol itself and the wavelength it’s working on. Adding buffers into the network drives down the cost of that infrastructure so it’s important to look at ways of delivering the overall latency needed at a reasonable cost. We also hear from Sanjay Mishra who explains that some telcos are already deploying millimetre wavelengths and focussing on advancing edge compute in high-density areas as their differentiator.

The panel discusses the current technical challenges for operators. Thierry Fautier draws from his experience of watching sports in the US on his mobile devices. The US has a zero-rating policy, he explains, where a mobile operator waives all data charges when you use a certain service, but only delivers the video at SD resolution at 1.5 Mbps. Whilst the benefits to this are obvious, it means that as people buy new, often larger phones, with better screens, they expect to reap the benefits. At SD, Thierry says, you can’t see the ball in Tennis, so there 5G will offer the over-the-air network bandwidth needed to allow the telcos to offer HD as part of these deals.

Preparing for 5G Video Streaming from Streaming Video Alliance on Vimeo.

The panel discusses the problems seen so far in delivering MBMS – multicast for mobile networks. MBMS has been deployed sporadically around the world in current LTE networks (using eMBMS) but has faced a typical chicken and egg problem. Given that both cell towers and mobile devices need to support the technology, it hasn’t been worth the upgrade cost for the telcos given that eMBMS is not yet supported by many chipsets including Apple’s. Thierry says there is hope for a 5G version of MBMS since Apple is now part of the 3GPP.

CMAF had a similar chicken and egg situation when it was finalised, there was hesitance in using it because Apple didn’t support it. Now with iOS 14 supporting HLS in CMAF, there is much more interest in deploying such services. This is just as well, cautions Thierry, as all the talk of reduced latency in 5G or in the network itself won’t solve the main problem with streaming latency which exists at the application layer. If services don’t abandon HLS/DASH and move to LL-HLS and LL-DASH/CMAF then the improvements in latency lower down the stack will only convey minimal benefits to the viewer.

Sanjay discusses the problem of coverage and penetration which will forever be a problem. “All cell towers are not created equal.” The challenge will remain as to how far and wide coverage will be there.

The panel finishes looking at what’s to come and suggests more ‘federations’ of companies working together, both commercially and technically, to deliver video to users in better ways. Thierry sums up the near future as providing higher quality experiences, making in-stadia experiences great and enabling immersive video.

Watch now!
Speakers

	Brian Stevenson SME, Streaming Video Alliance
	Humberto La Roche Principal Engineer, Cisco
	Sanjay Mishra Associate Fellow, Verizon
	Thierry Fautier President-Chair at Ultra HD Forum VP Video Strategy Harmonic at Harmonic
	Moderator: Dom Robinson Co-Founder, Director, and Creative Firestarter id3as

Video: Case Study – ST 2110 4K OB Van for AMV

Posted on 9th September 2020 by Russell Trafford-Jones

Systems based on SMPTE ST 2110 continue to come online throughout the year and, as they do, it’s worth seeing the choices they made to make it happen. We recently featured a project building two OB truck and how they worked around COVID 19 to deliver them. Today we’re looking at an OB truck based on Grass Valley and Cisco equipment.

Anup Mehta and Rahul Parameswaran from Cisco join the VSF’s Wes Simpson to explain their approach to getting ST 2110 working to deliver a scalable truck for All Mobile Video. This brief was to deliver a truck based on NMOS control, maximal COTS equipment, flexible networking with scalable PTP and security.

Thinking back to yesterday’s talk on Network Architecture we recognise the ‘hub and spoke’ architecture in use which makes a lot of sense in OB trucks. Using monolithic routers is initially tempting for OB trucks, but there is a need for a lot of 1G and 10G ports which tends to use up high-bandwidth ports on core routers quickly. Therefore moving to a monolithic architecture with multiple, directly connected, access switches makes them most sense. As Gerard Philips commented, this is a specialised form of the more general ‘spine-leaf’ architecture which is typically deployed in larger systems.

One argument against using IGMP/PIM routing in larger installations is that those protocols have no understanding of the wider picture. They don’t take a system-wide view like a SDN controller would. If IGMP is a paper roadmap, SDN is satnav with up to date road metrics, full knowledge of width/weight restrictions and live traffic alerts. To address this, Cisco created their own technology Non-Blocking Multicast (NBM) which takes in to account the bandwidth of the streams and works closely with Cisco’s DCNM (Data Centre Network Manager). These Cisco technologies allow more insight into the system as a whole, thus make better decisions.

Anup and Rahul continue to explain how the implementation of PTP was scaled by offloading the processing to line cards than relying on the main CPU of the unit before explaining how the DCNM, not only supporting the NBM feature, also supports GV Orbit. This is the configuration and system management unit from GV. From a security perspective, the network, by default, denies access to any connections into the port plus it has the ability to enforce bandwidth limits to stop accidental flooding or similar.

Watch now!
Speakers

	Anup Mehta Product Manager, Cisco
	Rahul Parameswaran Senior Technical Product Manager, Cisco

Subscribe to get daily updates