Standards: Part 12 - ST2110 Part 10 - System Level Timing & Control

How ST 2110 Part 10 describes transport, timing, error-protection and service descriptions relating to the individual essence streams delivered over the IP network using SDP, RTP, FEC & PTP.


This article is part of our growing series on Standards.
There is an overview of all 26 articles in Part 1 -  An Introduction To Standards.


ST 2110 is built on a foundation provided by the systems layer described in Part 10. That describes how streams are announced and discovered by receivers and how they are synchronized precisely when each essence stream is delivered separately. Latency is reduced by pre-empting packet losses with redundant error correcting information in the transport streams instead of using the slower TCP transport.

Part 10 describes these core parts of the system architecture:

  • Session Description Protocol (SDP).
  • Real Time transport Protocol (RTP) streams.
  • Forward Error Correction (FEC) techniques.
  • Precision Time Protocol (PTP).

The AMWA NMOS specifications augment ST 2110 with application level protocols and metadata which are integral to deploying your ST 2110 installation. They are all relevant and freely available to download. NMOS and other useful standards are described in the appendices.

Session Description Protocol (SDP)

The Session Description Protocol (SDP) announces streams and services that are vended by server-nodes in your network. A client-node discovers these and can access them as a live-feed source using the details contained in the SDP message.

Refer to Section 8 and Annex B of the ST 2110-10 standard for details of how SDP is used in the ST 2110 environment. This is based on RFC documents published by the IETF. Those documents have been revised several times and the most recent version replaces all of the earlier revisions even if ST 2110 does not track the changes:

Document Version Description
RFC 2327 1998 Original Session Description Protocol description. Obsoleted by RFC 4566.
RFC 3266 2002 Support for IPv6 added to SDP. Obsoleted by RFC 4566.
RFC 4566 2006 Revised SDP specification which replaces RFC 2327. Obsoleted by RFC 8866.
RFC 8866 2021 The most recent draft specification of the Session Description Protocol (SDP). This describes multimedia communication sessions for announcement and invitation to access streaming services. This is a proposed improved version that obsoletes all prior specifications.

 

The Session Description Protocol (SDP) announces available streams as they are deployed using a well-known multicast IP address which is reserved for that purpose. All nodes on the sub-net will see those announcements and can act on them to acquire the details of the remote stream if they qualify for the invitation.

The SDP message is carried as a payload in a Session Announcement Protocol (SAP) packet. These are retransmitted periodically so that latecomers can also receive them. Here is an example SDP payload taken from Annex B of the ST 2110-10 standard:

Despite it appearing complex, this is a simple format to construct. Some of the data items will already have been defined as configuration settings and will be the same for all sessions. Others are unique to this announcement.

Real Time Transport Protocol (RTP) Streams

ST-2110 is built on Real Time transport Protocol (RTP) streams. These were originally described in RFC documents and have been revised and extended many times since they were first introduced. RTP is extensible. Alter the behavior to suit your needs. The streams are all locked to a common timing reference defined by the Precision Time Protocol (PTP) and time-stamped with markers at the beginning of each video frame.

ST 2110 is based on the RTP protocol as originally defined by the IETF in RFC 3550 with the further caveat that it should conform to the profile defined in RFC 3551. These RFC documents are easy to find and download to read and understand the fine detail.

These RFCs have been continually revised and updated but ST 2110-41 mandates that ST 2110 shall continue to be based on the RFC 3550 definition of RTP. Future revisions to ST 2110 might take later enhancements to RTP into account but there is no indication of that happening yet:

Document Version Description
RFC 3550 2003 RTP: A Transport Protocol for Real-Time Applications. The base specification used by ST 2110.
RFC 3551 2003 An RTP Profile for Audio and Video Conferences with Minimal Control. Also mandated by ST 2110.
RFC 5506 2009 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP).
RFC 5761 2010 Multiplexing RTP Data and Control Packets on a Single Port.
RFC 6051 2010 Rapid Synchronization of RTP Flows.
RFC 6184 2011 RTP Payload Format for H.264 (AVC) Video.
RFC 6190 2011 RTP Payload Format for Scalable Video Coding (SVC).
RFC 7007 2013 Update to Remove DVI4 from the Recommended Codecs listed in RFC 3551.
RFC 7022 2013 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs).
RFC 7160 2014 Support for Multiple Clock Rates in an RTP Session.
RFC 7164 2014 RTP and Leap Seconds.
RFC 7656 2015 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources.
RFC 7798 2016 RTP Payload Format for High Efficiency Video Coding (HEVC).
RFC 8035 2016 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing.
RFC 8083 2017 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions.
RFC 8108 2017 Sending Multiple RTP Streams in a Single RTP Session.
RFC 8858 2021 Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP).
RFC 8860 2021 Sending Multiple Types of Media in a Single RTP Session.

 

Forward Error Correction (FEC)

The RTP streams are delivered using UDP transports. These have low latency but can suffer from packet loss and sequence order scrambling. Buffering and retransmission solves that when you use TCP transports, but that introduces significant latency.

ST 2110 anticipates the potential packet loss by adding redundant data to facilitate the reconstruction of missing packets. This technique is called Forward Error Correction (FEC). It does add a small latency overhead because the entire FEC stream needs to be received and processed to potentially recover lost media packets.

There are two different levels of protection offered by FEC based on a row and column arrangement that organizes the packets into a two-dimensional grid:

  • Level A - Column only protection.
  • Level B - Column and row protection.

The following standards are relevant to understanding FEC and how it fits into the RTP context:

Document Org Version Description
ST 2022-5 SMPTE 2013 Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks.
ST 2022-6 SMPTE 2012 Transport of High Bit Rate Media Signals over IP Networks.
ST 2022-7 SMPTE 2019 Seamless Protection Switching of RTP Datagrams briefly mentions FEC.

 


Sometimes the word 'Datagram' is used. In the context of ST 2110 and IP, this is interchangeable with the term 'Packet'.


Read ST 2022 Part 5 for a detailed explanation of how FEC works.

FEC Protection - Level A

Level A protection is a one-dimensional arrangement with a sequence of media packets aggregated to create a single FEC packet. The length of this sequence is defined by your configuration settings. The media packets are transmitted to a designated IP port at the client node. The FEC data is transmitted separately to a separate but nearby port. This technique is resilient to the loss of a single packet.

FEC Protection - Level B

Level B protection works on a two-dimensional grid of media packets with a FEC packet separately created for each column and row. The FEC is calculated for a column in the same way as Level A. The columns are stacked in rows based on the configured column length. If the column length is set to 100 packets then every 100th packet will start a new column.

There are a variety of different ways to arrange these columns. ST 2022 Part 5 discusses the advantages of offsetting the columns.

FEC Stream Arrangement

The FEC packets are transmitted separately to the media in their own RTP stream. This allows them to use an RFC 3550 compliant packet header without alterations to add FEC protection. The column and row FEC streams are transmitted separately so that they can have their own sequence numbers.

RFC 3550 mandates that a media stream is delivered to an evenly numbered port (N) at the destination IP address. The supporting column based FEC packets for a Level A connection will be sent to port number N+2 at the same address. For a level B connection, the column packets will be sent to the same relative port (N+2) and the row FEC packets will be sent to port number N+4. Therefore, each incoming stream can potentially require 3 evenly numbered IP ports to be allocated at the receiving client.

The receiver processes the media stream to check the packet sequence numbers and reconstruct any missing packets by combining the incoming media and FEC packets on the associated streams.

There is more information on FEC in these appendices:

Standards: Appendix R - The XOR Process Used In FEC Calculations

Standards: Appendix S - Forward Error Correction Ranges & Limits

Precision Time Protocol (PTP)

ST 2110 relies on the IEEE Precision Time Protocol (PTP) to synchronize timing and control signals. Part 10 describes the interaction between RTP streaming and PTP timing synchronization.

Clients synchronize to a reference clock by exchanging messages and measuring the propagation time for the round trip. The observed journey duration indicates an offset from the reference time. The local clock is adjusted to take that transmission latency into account. These assumptions determine the reliability of the local clock:

  • The transmission time is constant over any period of time.
  • The transmission time is the same in both directions.
  • Both endpoints can accurately determine the message departure and arrival times.

These standards are relevant to PTP in the context of an ST 2110 system:

Document Org Version Description
IEEE 1588 IEEE 2002 PTP version 1 using IPv4 transports.
IEEE 1588 IEEE 2008 PTP version 2, which is not backwards compatible with version 1. This version introduces profile support and includes IPv6 transport as well.
IEEE 1588 IEEE 2018 Sometimes informally described as PTP version 2.1, this improves the 2008 version to provide backwards compatibility.
IEEE 802.1AS IEEE 2020 Adapted from PTP for Audio Bridging applications in local area networks. This includes Wi-Fi and Bluetooth applications.
TR-1001 JT-NM 2020 v1.1 System Environment and Device Behaviors For SMPTE ST 2110 Media Nodes in Engineered Networks. This specification enables simplified network configuration, registration and connection management for media nodes. It illustrates how the Precision Time Protocol is used in an ST 2110 installation.

 

Conclusion

It is important to read ST 2110 Part 10 before the rest of the standard. The background information in the supporting documents from other sources will also help you understand how the systems layer works.

Beware that ST 2110 sometimes mandates earlier versions of external standards. Nevertheless, it is still important to be conversant with the latest versions in case ST 2110 is revised to accommodate them.

There is more information on standards relating to discovery and control within ST 2110 in these two appendices:

Standards: Appendix P - Other Relevant Standards For Discovery & Control

Standards: Appendix Q - AMWA NMOS Standards

Part of a series supported by

You might also like...

The Resolution Revolution

We can now capture video in much higher resolutions than we can transmit, distribute and display. But should we?

Microphones: Part 3 - Human Auditory System

To get the best out of a microphone it is important to understand how it differs from the human ear.

HDR Picture Fundamentals: Camera Technology

Understanding the terminology and technical theory of camera sensors & lenses is a key element of specifying systems to meet the consumer desire for High Dynamic Range.

IP Security For Broadcasters: Part 2 - The Problem To Be Solved

By assuming that IP must be made secure, we run the risk of missing a more fundamental question that is often overlooked: why is IP so insecure?

Standards: Part 22 - Inside AIFF Files

Compared with other popular standards in use, AIFF is ancient. The core functionality was stabilized over 30 years ago and remains unchanged.