Since the first document release in 2017, the SMPTE ST 2110 suite of standards for video transport over IP networks has made major inroads in the market for professional video and audio production gear. By removing the highly-compressed, unreliable stigma created by early IP streaming technologies (looking at you, Flash), ST 2110 enabled bit-perfect production systems to be built using widely-available Ethernet networking gear. 

As IP networking infrastructure continues to grow in capacity—while simultaneously lowering the cost per bit—IP systems have become ever-more capable and affordable. Like any major technology refresh, the transition to IP-centric media systems has experienced a few bumps along the way, but overall progress has been steady and new products are filling in the few remaining gaps needed to support every conceivable broadcast application.

When first released in 2017, ST 2110 provided a standard way to transport video over general purpose IP networks. Since it was targeted as a direct replacement for SDI, the focus was on uncompressed video inside a live studio production environment. 

One important difference from SDI is that each signal type is transported in a separate stream of packets, thereby eliminating the need to “embed” audio signals within their associated video signals. Synchronization is provided by distributing a precision (PTP) clock to every media device on the network, thereby allowing each device to align its outputs to a common timing reference point.

Market Impact
Over the past five years, IP media transport generally and ST 2110 specifically have made major inroads within the professional broadcast market. According to John Mailhot, CTO, Networking and Infrastructure for Imagine Communications, the industry has already reached the point where “ST 2110 is a better choice for greenfield studio construction and for applications that require more than 512 video router crosspoints.” 

Alan Wollenstein, director, Engineering Systems for the National Football League, spoke about how critical ST 2110 technology was for the implementation of the NFL Network’s new Los Angeles Facility in Inglewood, Calif. “We have 19 physical and 75 virtual edit bays in our new facility, which stretches over 200 yards from one end to the other. It simply would not have been possible to build this brand-new installation without using ST 2110.” 

New Updates in 2022
ST 2110 is made up of a number of standards, each of which covers one aspect of IP media transport; this makes it so that each of these documents can be updated independently.  Many of the core set of ST 2110 standards were updated in 2022, as shown in Fig. 1. The good news about these updates is that they were done very carefully, so as to avoid breaking equipment and software that were built using the 2017 edition of the standards. Here are a few highlights on the new standards:

ST 2110-10 System Definition: This document focuses on providing better information for control systems.  Two new (recommended) SDP parameters have been added: TSDELAY and TSMODE.  The first of these, TSDELAY, allows a device to indicate the amount of time (in microseconds) that elapses between the sampling or other time indicated by the RTP timestamp for a packet and the time that the first packet containing that timestamp is emitted by that device. 

The second of these, TSMODE, allows a device to indicate whether or not the RTP timestamps present on packets coming into the device are preserved or modified in the output of the device. Used together, these two new parameters allow a broadcast controller to more accurately assess the delays incurred within each step of a workflow, allowing tighter control of end-to-end delays and simplifying overall media synchronization.

ST 2110-20 Uncompressed Video: This adds support for two new video formats.  One addition supports a new Transfer Characteristic (the “TCS” parameter in SDP, which indicates how binary pixel values relate to pixel brightness) to support “Camera Log S3” as defined in SMPTE ST 2115 (and is used in a wide variety of high-end video and digital cinema cameras). The other addition was a new colorimetry type of “ALPHA” which is specifically designated for key signals, while it was clarified the key signals must not declare a TCS value. 

ST 2110-21 Traffic Shaping: This new version clarifies that the virtual receiver buffer  (VRX) constraints do not apply for constant bitrate compressed video signals, and providing a more flexible way of calculating the timing for interlaced video in order to support standard definition video formats (which are still used in many applications around the globe).

ST 2110-22 Compressed Video: This revision clarified that the Virtual Receiver Buffer constraints in the packet timing model do not apply, and cleared up some confusion about how the bitrate of a compressed signal is defined in SDP.

ST 2110-30 Uncompressed Audio: This document is currently undergoing very minor revisions to clarify some wording and to provide clearer descriptions of the audio receiver conformance levels.

ST 2110-40 Ancillary Data: This new revision creates two packet transmission models for ancillary data. LLTM, the Low Latency Transmission Model, requires senders to transmit ancillary data packets within 8 video lines of their specified location. CTM, the Compatible Transmission Model, allows a 1 msec window for transmission. These are signaled with the SDP parameter “TM.” One other minor change was to require senders to transmit packets in increasing order by original line number.”

IPMX
One major way that ST 2110 technology is being expanded to support new applications is in the development of IPMX (Internet Protocol Media eXperience). The goal of this development is to help reduce the cost of ST 2110 technology for applications that may not require its full range of capabilities. 

Another goal is to produce the first truly open, license-free IP video specification for the ProAV market (in contrast with NDI, SDVoE and HDBaseT). IPMX supports HDCP content protection, multi-monitor synchronization, FEC (Forward Error Correction), EDID (Extended Display Identification Data) and a variety of other features that are crucial to supporting this market. 

IPMX specifications are currently being developed by a group within the Video Services Forum (the same source as many of the key concepts behind ST 2110). More info, including downloadable copies of all
the released specification can be found at www.vsf.tv.

What the Future Holds
Not everything is perfect in the world of ST 2110. The capabilities of system and broadcast controllers are lagging behind those of video and audio endpoints, at least based on the results of the JT-NM Tested event in Wuppertal, Germany last August. Development of these systems proceeds apace, with particular emphasis on improving IP network security for broadcast devices. 

Most of the key ST 2110 standards have stabilized, and are not expected to change much (if at all) in the coming years.  This is good news for developers and implementers, allowing them to focus on fine-tuning and cost-reducing existing designs, rather than having to implement new features. It is likely that system cost reductions will also continue, as video systems are now more closely aligned with present trends in the much larger IT and datacom industry (including Moore’s Law and other factors). 

John Mailhot noted that “The cost premium for ST 2110 in media endpoints is going away, and the cost of 100 gigabit optics is dropping dramatically.”  Advances in Ethernet switch capabilities will also help significantly; Alan Wollenstein indicated that “The choice of spine and leaf IP network architecture for our facility was key for our application.”

Cloud-based production is much easier to implement with an IP-native technology like ST 2110 as compared to SDI-based systems. As more ST 2110 systems migrate from using uncompressed video to deploying JPEG XS or other compressed formats, the costs of transporting video to and from the cloud will become more attractive, making other benefits of the cloud (including rapid scalability, AI-based functions, pay-as-you go, and more) accessible to a wider market. 

Overall, today’s market and technology trends will continue to make ST 2110-based systems more affordable and flexible throughout the broadcast industry.  Pretty impressive for a six-year-old! 

Displays are essential for many tasks in a video production workflow. They can be deployed at signal sources, in control rooms, in operations centers and at distribution hubs to support a variety of production personnel. To handle commonly-used signal formats such as 4K SDI, SMPTE ST 2110, and NDI, displays need several different types of external conversion boxes. These adapters need to be connected with input and output cables, supplied with power, configured, and mounted somewhere unobtrusive. End users and system integrators alike need a simple, clean remedy for this headache.

The smart new solution for this challenge is the Intel Smart Display Module (SDM) platform and technology. These modules plug directly into compatible displays produced by a variety of big-name manufacturers. Because they draw power from the display, and deliver their signals directly via an internal PCI-E connector, these modules eliminate the need for external power or external mounting enclosures. Each module provides a native connector for a given signal type, including RJ-45 for NDI and 75-ohm BNC for 4K SDI. Apantac has now released a collection of SDM interfaces based on the Intel SDM platform to support a broad range of broadcast and AV applications.

Join Thomas Tang, Founder and CEO of Apantac in this lively Q+A video hosted by Wes Simpson, Founder of LearnIPvideo.com and contributing editor for TV Technology. Hear first-hand how SDM modules are transforming the market for broadcast and AV monitors by eliminating the need to deploy different monitors and standalone extension and connection solutions for each application with the use of Apantac’s. SDM Receivers for 12G UHD, HDBaseT, AV over IP and NDI. Learn about the exciting new potential to deploy monitors that are in 4K today and 8K in the near future. 

About Apantac LLC
Apantac LLC (www.apantac.com) is a leading designer and developer of high quality and cost effective multiviewers, video walls, matrices, extenders, openGear solutions and signal processing equipment. The Apantac product line has been specifically designed to provide users with flexible and innovative technology solutions for the broadcast and ProAV industries.

Apantac was founded in 2008 and is a privately held company with its headquarters located in Portland, Oregon, USA.

For more information about Apantac’s products & services please visit: www.apantac.com.

Welcome to “TV Tech Talk,” a new bi-monthly series of video seminars in which we talk about the latest innovations and developments in the broadcast and pro video technology market with industry leaders and experts. 

In this session, Craig Wilson, product evangelist for Broadcast and Media Enterprise, Avid Technology, provides his insights about working from home and how to deal with professional quality media editing. Several different approaches are discussed, including pure cloud solutions, home workstation solutions and mixed workflows.  The tricky subjects of licenses and security are also discussed.  

Please join Craig and host Wes Simpson as they have a straightforward technical discussion without the product jargon.

This is the fourth installment in a series of articles about the newly-published SMPTE standard covering elementary media flows over managed IP networks. This month, the focus is on audio transport, specifically on uncompressed, studio quality audio for broadcast applications.

UNCOMPRESSED AUDIO

The full title of SMPTE ST 2110-21 is “Professional Media Over Managed IP Networks — PCM Digital Audio.” This standard is closely related to, and heavily based on AES67, which is titled “AES standard for audio applications of networks — High-performance streaming audio-over-IP interoperability.” Although the document titles may not be totally self-explanatory, both standards are all about transmitting raw, uncompressed samples of audio signals directly within RTP/UDP datagrams using an IP network.

To understand how audio signals are packed into these datagrams, it helps to remember that each individual channel of uncompressed digital audio signal is created using a fixed sampling frequency and a fixed number of bits per sample. In the case of ST 2110-30, all senders and receivers are required to support 48 kHz sampling, at a minimum. In broadcast applications, 24 bits (3 bytes) are generally used for every sample. So, for a 48 kHz, 24-bit stereo audio pair, the raw audio data would consume 48,000 x 3 x 2=288,000 bytes/sec which equals 2.304 Mbps without any packet headers.

PACKETIZATION

An example of how audio samples are placed into packets is shown in Figure 1, where an HD-SDI signal is separated into individual IP packet streams for each media type. Video is encapsulated using ST 2110-20 and ancillary data is done using 2110-40. Two audio groups are shown — one stereo pair and one set of 7.1 surround sound (which is eight channels uncompressed). Each of these signals is packetized into a separate stream, as shown in the two rows that make up the table. By keeping the number of audio channels at eight or below for each of the two packet streams, maximum flexibility in choosing receivers is achieved, since the minimum (Level A) conformance level for an ST 2110-30 receiver is eight channels.

[Read: What SMPTE-2110 Means for Broadcasters]

Four factors control the way that audio samples are packed into the RTP packets that make up a stream, and are listed in the table within Figure 1 for each audio stream. The four factors are:

· Audio sampling rate. Most broadcast applications today use 48 kHz sampling, so all ST 2110-30 senders and receivers are required to support it. Some applications use 96 kHz sampling, and 44.1 kHz can also be found in practice, so the standards recommends that both additional rates should be supported. Other sampling rates are out of scope for the standard.

· Audio sampling depth. Because IP packets are formatted in bytes, the audio data payload must be an integer number of bytes. Therefore, AES67 and ST 2110-30 only allow 16-bit and 24-bit audio sampling.

· Packet time. This parameter indicates the timespan covered by the audio samples contained in each packet. For example, when 48 kHz sampling is used with a packet time of 1 millisecond, there will be 48 audio samples from each audio channel in each packet. Note that longer packet times increase the end-to-end latency of the audio stream (because it takes longer to fill each packet) and shorter times increase the number of packets in a stream.

· Number of channels. Normally, all of the parts of a multichannel audio signal, such as stereo or surround sound, are transported in the same IP packet stream. Thus, a 5.1 surround sound signal would have samples from six different audio channels interleaved within each packet.

A receiver relies on information contained in the SDP (Session Description Protocol from RFC 4566) in order to properly interpret the packet contents. The SDP data, which typically consists of a few lines of text, can be transported in multiple ways from a sender to a receiver. SMPTE ST 2110-30 does not define a specific way to do this. Instead, methods are being developed by the AMWA (Advanced Media Workflow Association) for use by media production facilities.

Along with the four parameters described in the preceding paragraphs, the SDP values defined in ST 2110-30 provide standard order for the individual channels within the IP packets. Two examples of this are shown in the table in Figure 1, including both the symbols that are used in the SDP file (“ST” and “71”) and their associate channel order in the last column in the table. Symbols and channel orders are defined within ST 2110-30 for other audio systems such as matrix stereo, 5.1 surround and 22.2 surround (symbols “LtRt,” “51,” and “222,” respectively).

SMPTE ST 2110-30 also defines a set of six compliance levels for audio receivers, as shown in Figure 2. To achieve compliance at a particularly level, a receiver must be able to accept any quantity of audio channels in a single stream within the range shown in the table for each combination of packet time and sampling rate. Note that only the “–X” receivers are required to support 96 kHz sampling.

COMPATIBILITY & DIFFERENCES WITH AES67

One question that might be asked about AES67 and ST 2110-30 is: “Can they be made to work together?” The answer is: “Absolutely.” Because ST 2110-30 is based on AES67 and includes multiple “normative” (i.e. required) references, it is very easy to achieve interoperability. That being said, there are a few areas of difference.

First of all, ST 2110-30 receivers are not required to support SIP connection management for unicast audio signals. This is likely not an issue, since large audio networks frequently use IP multicasting to allow signals to be sent to multiple destinations simultaneously. This does mean, however, that ST 2110-30 receivers won’t be able to send or receive VoIP (Voice over IP) calls that use SIP for connection setup. Also note that RTCP (RTP Control Protocol) is recommended for use in AES67 but only needs to be “tolerated” in ST 2110-30 devices.

There are some differences with respect to how PTP (Precision Time Protocol, as defined in IEEE-1588) is implemented between the two standards. One important difference is that RTP clock offsets are not permitted in ST 2110-30. This means that AES67 receivers can work fine with ST 2110-30 senders, but that AES67 senders must not use an RTP clock offset when sending signals to ST 2110-30 receivers. There are also some differences in the specific profiles of PTP that are used in the two standards, however, the permitted ranges overlap so the two systems can be set up to work together.

One other slight difference: ST 2110 requires that every device has an option that allows it to be set in a PTP slave-only mode. When this mode is enabled, the device will never attempt to become a PTP master. This is important in large networks in order to prevent chaos when every device becomes available to take over as PTP master when an interruption in the PTP distribution system occurs. This option is not required in AES67, but should be a useful feature in many products.

HARMONIOUS SOUND

SMPTE ST 2110-30 was developed specifically to make audio as compatible as possible with video. By using the widely-accepted AES67 standard as a base, this new standard allows a wide range of existing audio equipment to harmonize with the rest of the 2110 suite.

Other entries in this series:

SMPTE ST 2110-21: Taming the Torrents

SMPTE ST 2110-20: Pass the Pixels, Please

SMPTE ST 2110-10: A Base to Build On

[Want more information like this? Subscribe to our newsletter and get it delivered right to your inbox.]

This is the third installment in a series of articles about the newly-published SMPTE standard covering elementary media flows over managed IP networks. This month, the focus is again on video transport, specifically the rules that help ensure that high-bitrate video streams are well-behaved and won’t overwhelm the IP networks used to transport them nor overflow receiver buffers.

KEEPING STREAMS FROM OVERFLOWING

The full title of SMPTE ST 2110-21 is “Professional Media Over Managed IP Networks: Traffic Shaping and Delivery Timing for Video.” Both of these terms refer to the same basic topic: how are the packets transmitted over the network, from the perspective of both the sender and the receiver? In other words, how should packet flows be sent into the network “pipes” so as to not cause flooding (of packets)? Answering these questions is crucial for properly provisioning network connections to support as many signals as possible without causing packet congestion, which could lead to packet loss.

To really understand the potential issue, it helps to deal with some actual numbers. Consider a 1080p signal with a 50Hz (European) frame rate that has a bandwidth of 3 Gbps on an SDI cable. At 50 Hz, a new frame of video is created every 20 milliseconds. Using constant-size packets, each with 480 pixels, would result in 4320 packets for each video frame. Using 10-bit sampling, 480 pixels would require 1200 bytes of data, plus 90 bytes of overhead, for a total of 1290 bytes per packet.

One way that this video signal could be transmitted would be using evenly spaced packets. In this case, 4320 packets sent every 20 milliseconds would mean that one packet is sent every 4.63 microseconds. On a 10 Gbps link, each 1290-byte packet would require (1290*8=10,320) bit-times to transmit, or 1.032 microseconds, followed by a gap of roughly 3.6 microseconds.

Another way that this video signal could be sent would be sending all of the pixels within a frame all at once. (This could hypothetically be the case for a device that was, say, generating graphics.) In this case, the sender would generate a burst of packets lasting 4320*10,230 bit times, or 4.419 milliseconds. This burst of packets would be followed by a gap of (20-4.419) 15.581 milliseconds until the next video frame was ready to transmit.

[SMPTE ST 2110-10: A Base to Build On]

So which of these packet transmission schemes is better? Well, both of the above streams have the same long-term average bit rate, of just about 2.23 Gbps. However, the first stream with evenly spaced packets will be much easier for signal receivers, switches and other network devices to handle. Why? Because the second stream will fully occupy a 10 Gbps data circuit for a significant period of time, forcing any lower-priority data that might need to be transmitted over that link to be placed in a buffer to wait for the link to become free. If higher-priority data came along during the data burst, then video packets would need to be buffered instead. Since network devices typically have a limited amount of buffer space that needs to be shared by multiple physical data channels, any signal that places heavy demands on buffers can cause problems, such as lost or deleted packets when buffers are filled up.

This issue becomes even more of a problem when multiple senders are all trying to transmit bursts of data at the same time, as would frequently occur in applications where several video sources are locked to a common clock. Therefore, to prevent network problems and to make it easier to design signal receivers, it makes sense to set some limits on the size and duration of packet bursts. These limits are often called “traffic shaping” and/or “delivery timing” in networking jargon.

TYPE N, NL AND W VIDEO SOURCES

The ST 2110-21 standard defines three types of senders: N (for Narrow), NL (for Narrow Linear) and W (for Wide). These types define limits for the amount of packet delay variation (i.e. the burstiness) that a sender is allowed to exhibit in its output stream.

Type NL is the easiest to understand, and corresponds to a stream where all the packets for a video signal are evenly spaced across the duration of each video frame (i.e. a stream that is like the first example given in the preceding section). The SDP (Session Description Protocol) for this type of stream must include a parameter “TP=2110TPNL.”

[SMPTE ST 2110-20: Pass the Pixels, Please]

Type N is similar to Type NL, except that the sender doesn’t send packets during the time that would correspond to the VBI (Vertical Blanking Interval) or VANC (Vertical Ancillary data space) of the corresponding traditional SDI video signal. Thus, a Type N sender would be able to send packets in a stream that would have a noticeable gap that occurs during each video frame period. For example, in a 720p signal running at 50 frames per second, and a VANC equal in duration to 30 lines of video, the sender would deliver packets for (720/750*20 milliseconds) 19.2 milliseconds out of every 20 milliseconds, and have a 0.8 millisecond gap when no packets are sent. Note that this would be the behavior that would be the easiest to implement if an incoming SDI signal was simply converted to ST2110 packets whenever active video samples arrive. The SDP for this type of stream must include a parameter “TP=2110TPN.”

Type W senders are allowed to have a significantly greater burstiness. This category was included in the ST 2110-21 standard to accommodate software-based senders, such as a graphics generator. For Type W flows, senders can have at least quadruple the amount of burstiness as a Type N or a Type NL, and in many cases much more. While this looser tolerance should make things better for a sender (particularly one that is implemented on a virtual machine), it does have consequences for receivers, which require a corresponding increase in the size of their input buffers. This can be costly, both in terms of the raw amount of memory that is required as well as in terms of delay for an incoming signal. Type W streams will also tend to consume larger amounts of buffer space within network switches and other devices; applications with significant quantities of Type W senders will need to be implemented using network devices that have sufficiently large internal memories. The SDP for this type of stream must include a parameter “TP=2110TPW.”

Fig. 1

Click on the Image to Enlarge

Fig. 1 shows a comparison of the three different sender types. Each of the three types is shown with a simplified representation of the packet flows along with a moving average of the bit rate. Note that for type NL, the moving average bit rate is flat, showing that these flows are the best behaved. Type N shows an increase in average bit rate during active video and a decline during the VANC. For Type W, the average rate shows even larger flow rate surges and drops.

Receivers are also categorized in ST 2110-21, but this information is not required to be transmitted with SDP. A Type N receiver should be able to correctly receive a flow originating from either a Type N or a Type NL sender(but not a Type W), provided that the receiver is locked to the same clock as the sender and that sender is aligned to the SMPTE ST 2059-1 Epoch. A Type W receiver should be able to receive a stream from an N, NL or W sender, provided the receiver is locked to the same clock as the sender. A Type A (for Asynchronous) receiver should be capable of receiving a stream from any type of sender, regardless of clock source or signal phase.

PRACTICAL CONSIDERATIONS

For time-sensitive flows within a media facility, such as a live broadcast, Type N or NL senders will tend to dominate, because they are the easiest to multiplex together and require the least amount of buffering in the network and at receivers, and therefore introduce the smallest amount of end-to-end delay. If Type W senders are present in a network, receivers will also need to be Type W to be able to receive these flows. For non-frame-accurate applications, such as monitors and multiviewers, or when synchronization between senders and receivers is not present, Type A receivers can be used to accommodate any type of ST 2110 uncompressed video flow.

Wes Simpson is the president of Telecom Product Consulting. He can be reached via TV Technology.

The verdict is in: 5G wireless systems will be all things to all people, allowing incredibly high bandwidths and ultra-low power radios to be used anywhere, all at a fraction of the cost of today’s devices. Industry journals are filled with reports of successful deployments, and consumers are getting ready for the next generation of smartphones to transport them to a future of connectivity nirvana.

Does this sound too good to be true? Well it is, at least from where the wireless industry stands in 2017. Because the final standards have yet to be ratified, there are lots of interesting trials and experiments underway to move towards a common standard that will be required before handset manufacturers and mobile system operators are able to begin mass deployments. But, as things start to come into focus, it is readily apparent that 5G will transform wireless networking as we know it.

WHAT IS 5G?
Each of the past generations of wireless networking has been named in a series, starting with 1G, which were the first cellphones that used analog channels to provide voice communications. 2G introduced digital radios and text messaging; one popular version was named “GSM.” 3G increased the data channel capacities to at least 200 Kbps, with enhancements that reached into the Megabit range. 4G and 4GLTE are the most advanced standards in use today, and provide all of the features and functions that modern smartphones utilize for delivering streaming video, multimedia messages and millions of voice connections.

The ITU (International Telecommunication Union) is set to ratify a set of minimum requirements (called ITU-R M.IMT-2020 for 5G systems during their November 2017 meeting. These requirements include:

20 Gbps peak downlink rate to a single mobile station, in a perfect environment with all available resources utilized;

10 Gbps peak uplink rate, also under ideal conditions;

100 Mbps user experienced downlink rate, which is the worst data rate that users who are within range of the network should encounter ninety-five percent of the time. This is roughly a hundred times what many current mobile networks are designed to deliver;

50 Mbps user experienced uplink rate, which will be important for wireless cameras and other applications;

4 msec one-way latency across the radio link for enhanced mobile device users, which will help improve throughput for streaming video and file uploads/downloads, and

Up to 1 million simultaneous connections per square kilometer, which means that supporting a dense collection of wireless, low power Internet of Things (IoT) devices will actually be feasible.

One of the ways that 5G will attain all of these impressive performance numbers is by using radios that are capable of delivering 30 bits per second per Hz peak spectral efficiency downlink and 15 bps/Hz uplink, which requires advanced modulation schemes and antennas to be coupled with powerful digital signal processing. Improvements in base station density (number of base stations per unit area) and use of millimeter-wave (30-300 GHz) signals will also be necessary to achieve some of 5G’s performance targets.

IMPACT ON BROADCASTERS
The advances brought by 5G technology are already being experienced by a few lucky users who are involved in early trials of fixed broadband connections based on millimeter-wave radio technologies. These signals, which require high-gain antennas working over direct line-of-sight links, are not able to pass through objects and can experience significant fading due to rain. In spite of these limitations, 5G fixed wireless technology could make it easier (and less expensive) for carriers to provide high-bandwidth connections to broadcasters who have facilities in so-called “digital deserts” and bring more competition into the local loop market as early as 2018 in some cities.

Broadcasters are increasingly using portable cameras with wireless backhaul for news, sports and remote event coverage, and the advances brought by 5G technology should have a major impact on performance. Unfortunately, broadcasters’ ability to use these systems will be delayed until carriers are able to deploy base stations that support these technologies in the areas where broadcasters will want to use them. Mass deployment will have to wait for industry standards to be finalized.

Speaking of standards, work is underway in several different committees to define exactly which technologies will be selected to implement 5G’s lofty performance goals. Of course, these decisions will need to balance the needs of users and carriers, patent holders and manufacturers, and result in a system that can be economically implemented using technologies that are going to be available within the next year or two. To help accelerate the standards process, the 3GPP (Third Generation Partnership Project) agreed earlier this year to release 5G NSA (Non-Stand Alone) specifications in March 2018. NSA incorporates the advanced radio technologies of 5G but utilizes 4G LTE infrastructure, a step that is intended to allow commercial services to launch as early as the end of 2018. Full 5G specifications (called 5G SA or Stand Alone) would follow in late 2018 and include the core network improvements needed to fully support IoT devices, enhanced routing protocols, and other advances.

Once the full set of standards is complete, there is still a lot of work that needs to be completed before 5G becomes a reality. Chip designs will need to be finalized, handset manufacturers will need to produce devices, and service providers will need to deploy base stations, most likely beginning in major city centers. The “2020” included in the title of the ITU’s report named above is not only part of the document number, but also the calendar year when true 5G is likely to become commercially available.

Wes Simpson is the president of Telecom Product Consulting. He can be reached via TV Technology.

Figuring out the amount of bandwidth a video signal requires on an IP network isn’t terribly hard, but it does require some familiarity with the underlying technologies and packet formats. Getting the correct answer is important for tasks such as estimating the number of videos that can be carried over a given network connection or for calculating the costs of a long-haul connection to carry signals between two facilities.

In this column, we’ll look at how much bandwidth will be consumed for a 1080p59.94 video signal when it is transported over two popular formats for uncompressed IP video transport that are available today.

The first format is SMPTE ST 2022-6, which was originally designed for moving uncompressed signals over a long-haul network, including all of the embedded audio and any other signals contained in the HANC and VANC spaces. This format is still popular today because it is very easy to take an SDI signal source (SD, HD or 3G), convert it into ST 2022-6 for transport over an IP connection, and get back exactly the same SDI signal at the destination without changing a single bit. It has been widely implemented by a number of equipment suppliers, and interoperability has been proven at several industry events, including VidTrans, which is hosted by the VSF (Video Services Forum).

The other format is newer, but it allows transportation of each type of media essence (video, audio, etc.) as a separate IP packet stream. This approach eliminates the need to embed and de-embed audio and other signals into SDI streams for transport and, as shown in the following calculations, reduces the amount of IP network bandwidth needed for video transport. The VSF TR-03 recommendation is based on RFC 4175, which takes groups of pixels and directly maps them into RTP packets. This recommendation is expected to evolve soon into SMPTE ST 2110-20, which will use a similar packet format.

PACKET PAYLOADS

The first step in calculating signal bandwidth is to figure out how much media essence can be transported in each packet. For ST 2022-6, this step is easy—each packet carries a fixed payload of 1376 bytes. For VSF TR-03, several alternatives are possible, so to simplify calculations, each video line consisting of 1,920 pixels will be divided into four equal parts of 480 pixels each. With 4:2:2 sampling, each pair of pixels requires four 10-bit samples (two luma and two chroma), which equates to 40 bits or 5 bytes. Thus, 480 pixels will occupy (480/2)*5=1200 bytes.

PACKET HEADERS AND OVERHEAD

As shown in the calculations in Fig. 1, at each layer as packets move through the protocol stack, new headers are added. For ST 2022-6, a High Bitrate Media Header is added. For TR-03 (and soon ST 2110-20) an 8-byte payload header is used. Then, the 12-byte RTP header and 8-byte UDP header are applied, followed by an IPv4 header of 20 bytes. At the Ethernet layer, the standard Ethernet header of 14 bytes is often extended by a 4-byte VLAN label, and the required 4-byte Frame Check Sequence is appended to the packet, for a total of 22 bytes of overhead. When transmitted over a standard path, each Ethernet frame is preceded by an 8-byte preamble and followed by an inter-frame gap equal in duration to 12 bytes, for a total overhead equal to 20 bytes in duration.

PACKET RATE CALCULATIONS

Once the size of each packet is known, the other factor needed to calculate a signal’s bandwidth is the number of packets per second. This needs to be calculated using the original signal rates. 

For ST 2022-6, since the entire 1080p59.94 payload is transported, this calculation must be based on the full video frame. With 2,200 samples per line, 1,125 lines per frame, and 20 bits per sample (in 4:2:2 10-bit sampling), the total number of bytes per frame is 6,187,500. With 1376 bytes per packet, this translates to 4,497 packets per video frame. At 59.94 frames per second, the total packet rate is 269,550 packets per second.

For TR-03/ST 2110-20, only the active video area is transported. Since each packet carries one-quarter of a video line, one full video frame will require 4x1080 = 4320 packets. At 59.94 frames per second, the stream will consume 258,941 packets per second.

To get the total bit rate, all that remains is to multiply the packet rate by the size of the packet in bits. As the bottom row of Fig. 1 shows, the bandwidth of a 2022-6 signal is about 200 Mbps higher than the nominal 2.97 Gbps required by a 1080p video, whereas the TR-03/ST 2110-20 is almost 300 Mbps less than the raw SDI.

WHAT ABOUT AUDIO?

The only other high-bandwidth signals that are commonly found in a modern production facility are audio signals. In ST 2022-6, the audio signals are carried inside the SDI payload, so there is no extra bandwidth required for audio (provided the number of audio channels is less than what the SDI can carry).

In TR-03/SMPTE ST 2110, more bandwidth will need to be allocated for audio, although, with a 48 KHz, 24-bit stereo signal occupying less than 3 Mbps, audio streams are generally not a major burden on a gigabit-class network.

A NOTE OF CAUTION

The actual amount of bandwidth allocated (i.e. the CIR or Committed Information Rate) in any network connection that carries an IP video signal needs to be greater than the raw bit rate calculated in this article. In particular, due in part to the bursty nature of video (blocks of pixels with gaps where the VANC would be), additional bandwidth should be provisioned through each network hop above and beyond the amounts calculated in this article. Since the recommended amount of added bandwidth is currently being studied by the SMPTE committee, this will have to be the subject of a future column.

Wes Simpson is active in standards development and technology training. Please visittelecompro.tvfor more information.

Editor’s note: The headline on Wes’s contribution originally said a new “standard” had been approved. TV Technology regrets the error.
ORANGE, CONN.—On Oct. 21, the Video Services Forum published TR-03 “Transport of Uncompressed Elementary Stream Media over IP” to define an interoperable way to format and identify media streams for IP network transport. This recommendation was developed specifically to address the need within modern media production facilities to have an efficient, flexible method to transport uncompressed signals of various types.

Previously approved standards, such as SMPTE 2022-6, require video signals to be first formatted into SDI (Serial Digital Interface) streams before they are placed into IP packets. Related audio and metadata signals are commonly embedded in the horizontal and vertical ancillary spaces (HANC and VANC) that are present within the SDI signal. This is somewhat inefficient, due to the need to de-embed the individual signals from the SDI stream before they can be processed, and then possibly re-embed them before being passed along to the next step in the processing workflow.

DIFFERENT APPROACHES
With TR-03, each media type is transported individually as elementary streams. In the case of audio signals, the raw audio samples are placed directly into RTP/IP packets using AES67. For video, pixels from the active picture area are placed directly into RTP/IP packets in accordance with IETF RFC 4175. Metadata is handled using another IETF-proposed standard “draft-ietf-payload-rtp-ancillary-02.”

Chuck Meyer, chief technology officer, production for Grass Valley, noted the significance of the new standard. “TR-03 is very much about essence, and really separating out the media types be it video, audio, metadata and timing events,” he said. It’s just so important to keep those separate.”

Fig. 1 shows the different approaches used by 2022-6 and TR-03. Fig. 1 shows the different approaches used by 2022-6 and TR-03. Part A shows audio and metadata being embedded into an SDI stream that is then packetized using 2022-6 and sent through an IP network. Part B shows audio, video and metadata each being packetized into separate IP streams in accordance with TR-03. The crucial difference between these two approaches is illustrated in the steps needed to perform an audio processing function (such as loudness adjustment). In the 2022-6 process, the entire video stream must first be de-packetized and then the audio signal must be de-embedded from the SDI stream. When processing is completed, the audio must be re-embedded in the SDI before the SDI signal can once again be packetized. Contrast this with the TR-03 process shown in Part B of Fig. 1, where only the packets containing audio samples are required to be depacketized, before they are processed, and then repacketized back into an IP stream. Not only does this process remove the need for audio embedding and de-embedding, it also greatly reduces the volume of packet traffic that needs to be routed to the audio processor. As an added benefit of TR-03, note that only the active video pixels of TR-03 need to be packetized, thereby reducing the amount of network traffic generated by uncompressed video.

TIMING AND IDENTIFICATION
Two important elements that underpin TR-03 are timing and identification. Timing is handled by distributing a common clock to every node on the network using IEEE 1588 Precision Time Protocol, and by referencing all of the media clocks to the SMPTE Epoch defined in 2059-1. Streams are identified, and, more importantly, associated with each other using SDP (Session Description Protocol; IETF RFC 4566 and The SDP Grouping Framework; IETF RFC 5888). Using these capabilities, audio and video streams can be identified as belonging to the same lip sync group and be referenced to a common clock so that they can be sent as separate IP packet streams through a network and then synchronized at the streams’ destination. Going back to Part B in Fig. 1, once the video, audio and data streams are synchronized at their source using a common clock, the streams can take different paths, with different amounts of delay, yet still be able to be realigned to a common clock at the output. An SDP file is created to indicate that the video, audio and data signals shown in Part B in Fig. 1 are part of the same lip sync group; the information in this file tells the receiving device where to find the streams and how to synchronize them.

When asked why a new standard is needed at this time, John Mailhot, CTO networking and infrastructure for Imagine Communications said “IP is a new infrastructure for the industry. 2022 has a place for interconnection between facilities and between rooms. The SVIP group was formed to address needs in the production studio. TR-03 has the flexibility that is a paramount need for this application.

“TR-03 can deliver the promise of IP networks,” he said. “It creates an extensible way to organize video, audio and metadata that can deliver all these media types in a media-agnostic fashion.”

There already appears to be a great deal of interest in this new TR, at least according to Meyer. “People noticed my name on the list of contributors to TR-03 and are calling me out of the blue—this never happened to me before. They are saying ‘Hey Chuck this is a really a cool thing. I think I’m seeing how this could really help me with my 4K transitions. Can you give me more technical details?’”

A copy of the TR-03 Draft Recommendation can be downloaded at www.videoservicesforum.org/technical_recommendations.shtml.

Wes Simpson is a member of the SVIP team that developed TR-03 within the VSF, along with representatives from dozens of other companies within the media industry.

NEW YORK—As broadcasters increasingly move toward IP-based systems within their facilities and for wide area network connections, the ability to prioritize some packets over others is becoming more desirable.

One popular method for doing this is called Differentiated Services or “DiffServ,” which uses a data field within the IPv4 (and IPv6) packet header. Several standards have been produced that take advantage of this functionality for video and audio applications, including the AES67 standard for high-performance IP audio streaming interoperability that was published in 2013.

Already, many systems can implement DiffServ, but effective network management may require some thought about which flows to prioritize and how to treat different forms of traffic. Since there are no hard and fast rules about which packet streams have to be given priority over other streams, only guidelines, broadcasters need to make an informed decision about how to configure their priority schemes to suit their particular needs.

Fig. 1: Comparison of ToS and DiffServ fields

LABELING THE PACKETS
In the original version of the IPv4 specification (IETF RFC 791), eight bits of the packet header were reserved for a function called “Type of Service” or ToS. Packets with a higher value in the first three bits of this field (see Fig. 1) were given precedence over other packets, allowing them to be given seven different levels of priority for congested resources such as a limited-capacity data path between two routers. The remaining five bits were originally designated for three flags that could be used to give more information about the flow, and the last two bits were reserved for future use in the original standard. Note that a fourth flag bit was added in the later RFC 1349 in place of one of the reserved bits.

DiffServ was defined in RFC 2474, which was published in 1998, and has been modified slightly since then. In place of the three-bit priority field and three one-bit flags defined in RFC 791, DiffServ uses six bits for defining up to 64 possible Differentiated Services Code Points, or DSCPs. Each of the codes can be used to define a specific priority level for a group of packet flows within the network.

All packets that are labeled with a given code point are given the same priority and treated the same by nodes in the network. This so-called “coarse-grained” mechanism provides a straightforward means to prioritize packets at each hop along a network, thereby creating a prioritized end-to-end system.

GIVING PRIORITY
DiffServ behavior within a network is based on classifying and labeling packets into groups (also known as Behavior Aggregates or “BA”), which can be treated as equals when they are sent between nodes along a network path. For each connection between a pair of network nodes, Per Hop Behaviors (PHB) are configured for each of the different BAs (priority groups). Different amounts of bandwidth, different queue sizes, different ways to deal with oversub-scription and other packet processing functions can be specified for each PHB.

Several different PHBs have been defined in the DiffServ standard:

The Default Forwarding (DF) or “Best Effort” code point is used for packets that do not require any specific level of priority, and are given a DSCP of 000000, which is a decimal value of 0. These packets will be given the lowest available priority.

Expedited Forwarding (EF) as defined in RFC 3246 code point should be reserved for packet streams that require very high performance, with low levels of loss, jitter and latency, along with assured bandwidth. In normal enterprise networks, this code point might be used for Voice over IP (VoIP), to minimize the latency and jitter of these signals that might occupy only a small fraction of the overall network bandwidth. However, in media facility networks, since most of the network bandwidth will be occupied by video and audio signals, AES67 recommends using the EF code point only for IEEE-1588 Precision Timing Protocol (PTP) messages. EF packets are given a DSCP of 101110, which is a decimal value of 46.

Fig. 2: DiffServ code points for assured forwarding

Assured Forwarding (AF) as defined in RFC 2597 provides a dozen different code points for assigning priority levels to various BAs. There are four classes (1 through 4), each of which has three drop precedence levels (Low (1), Medium (2) and High (3), where High Precedence packets are more likely to be dropped), and are shown in Fig. 2. Each of the four classes should be given a defined amount of buffer space and output interface bandwidth for each network hop. For audio packets, AES67 recommends using the AF41 DSCP of 100010, which is a decimal value of 34. This is the highest class of forwarding with the lowest probability of having packets dropped within AF.

Class Selectors(CS) of 1 through 7 are also defined in RFC 2474; these simply use the first three bits of the DSCP field to contain the binary values 1 through 7, with the remaining three bits in the DSCP set to 000.

This ability to configure how each hop through the network handles the different priority levels provides one of the largest benefits of DiffServ. This technology removes the need for endpoint devices to issue reservation requests for paths with specific amounts of bandwidth through a network and eliminates complex management systems and databases at each network node to track the priorities and bandwidth requirements of thousands of streams that pass through them.

The result is a priority mechanism that can scale up to cover a large, distributed network without requiring centralized control or complex communications between network nodes.

If you are wondering about the last two bits of the Differentiated Services field, those have now been designated for Explicit Congestion Notification, which will have to be a subject for a future column.

Wes Simpson wishes that all of his Internet traffic could be given the highest priority. He can be reached atwes.simpson@gmail.com.