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:

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:

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:

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:

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

These Appendix articles contain additional information you may find useful: