Probably the most popular format for long-distance terrestrial video transport in the United States today is the 270 Mbps video circuit. Most local and long-distance carriers offer some sort of 270 service, and a number of companies offer switching services that connect local to long-haul services. Amazingly, much of this bandwidth gets wasted, particularly for transporting DVB/ASI and other compressed services. The time is coming when carriers and broadcasters who operate their own networks must recognize that they need to be more efficient with their video traffic, particularly if they are going to keep price levels down for these services.
VIDEO ON THE MOVE
Fig. 1: Inefficient bandwidth utilization for two common telecom bit rates.
Now don't get me wrong: I have gone on the record several times in praise of uncompressed video transport, and I am a big believer in uncompressed HD transport in the local loop. I will always think that uncompressed transport is the best way to move video, because it offers great signal quality, eliminates the expense and operational headaches of compression and decompression systems, and is truly universal, since virtually all video equipment can handle either uncompressed SD or HD video. I also believe that uncompressed 270 is the best way to transport analog video, because it helps eliminate the back-to-back D-to-A and A-to-D converters that are still used in some analog TV-1 networks, and allows direct interface to all kinds of digital equipment.
No, what I'm talking about when discussing bandwidth wasting is the way that many users deploy 270 circuits: as a way to transport compressed SD and HD content. Here's how a typical scenario works. At the video source, content is compressed with some form of encoder, such as MPEG-2, MPEG-4, JPEG or possibly something proprietary. Then, the compressed stream is wrapped inside an MPEG-2 transport stream, and formed into a DVB/ASI signal, which always operates at 270 Mbps, regardless of the compressed bit-rate of the payload. This signal is then delivered to a transport network, which duly takes that 270 Mbps stream and delivers it intact to the destination. Once there, the compressed stream is extracted from the DVB/ASI transport stream and decompressed back to the original video signal.
There are three major sources of waste in this scenario:
- The absolute maximum amount of bandwidth that can be occupied inside a DVB/ASI payload is 213 Mbps, due to the way that transport streams are encoded into the DVB/ASI stream. This effectively trims 21 percent off of the 270 Mbps capacity.
- Many popular DVB/ASI multiplexers have a limit on the total amount of bandwidth that can be delivered via an aggregate output port. This can range from 100–180 Mbps out of the theoretical 213 Mbps. This trims another 12 to 42 percent off of the 270 Mbps total of the circuit.
- 270 Mbps services don't fit cleanly into the popular bit rates used in telecom networks. There is always some bandwidth left over after the maximum number of 270 signals is multiplexed. With OC-12 and OC-48 about 10 percent of the bandwidth is stranded; with a gigabit Ethernet, about 18 percent is stranded.
LOOKING AT TELCO CIRCUITS
Consider the situation of a common telephone company circuit called an OC-12, for Optical Carrier level 12, which is the same as an STM-4 signal used in other parts of the world. An OC-12/STM-4 circuit operates at the fixed bandwidth of 622.08 Mbps. Of course, not all of this bandwidth can be used for transport, since some is consumed by the framing overhead of the SONET (Synchronous Optical Network) or SDH (Synchronous Digital Hierarchy) framing, which amounts to 20.736 Mbps, leaving available payload of 601.344 Mbps. In this bandwidth, two 270 Mbps signals can be multiplexed, which can each carry, at most, 213 Mbps of traffic each. If typical DVB/ASI multiplexers are used that offer 180 Mbps of output each, then the circuit will have a capacity of 360 Mbps out of a total of 622.08 Mbps, or an effective utilization of the available capacity of 360/601, or 60 percent.
A similar calculation can be performed for an OC-48 (STM-16) circuit, which has a total bandwidth of 2488.32 Mbps and SONET/SDH overhead of 82.944 Mbps, for a net usable bandwidth of 2405.376 Mbps. In this bandwidth, up to eight 270 Mbps signals can be accommodated, with 245 Mbps left over. Again, using 180 Mbps multiplexers, the total usable bandwidth for eight DVB/ASI signals is 1440 Mbps, for an efficiency of 1440/2405 or 60 percent. Fig. 1 shows how bandwidth is utilized for both of these popular telecom rates.
THE SATELLITE LIMIT
Many times for important live broadcasts, terrestrial 270 Mbps circuits are used as primary or backup circuits in conjunction with satellite services. Broadcasters use this configuration to help minimize the chance that a single point of failure would cause the broadcast to fail. Newer DVB-S2 satellite links can offer bandwidths in the 60–80 Mbps range, which could be used for one or more compressed SD or HD services. For terrestrial links, these signals are typically carried on DVB/ASI channel at 270 Mbps. Taking the actual useful system bandwidth into consideration, this means that a 622 Mbps OC-12 signal might only be carrying useful payload of 120–160 Mbps, for a system utilization of only 20 to 25 percent.
Efficient transport of DVB/ASI signals requires the removal of unnecessary information from the 270 Mbps source signal, and then finding an effective way to transport the actual information over a telecom network. A leading candidate is Ethernet, although it is necessary to take the overheads associated with both Ethernet frame headers and IP packet headers into account when calculating system capacity.
To provide a valid comparison, start again with an OC-12/STM-4 operating at 622.08 Mbps. SONET/SDH framing of 20.736 Mbps always needs to be deducted, leaving available bandwidth of 601.344 Mbps of bandwidth. Beyond that, Ethernet/IP overheads on telecom circuits break down into three categories:
Packet mapping, which is the process of taking Ethernet frames and placing them into the SONET/SDH framing structure so that they can be recovered at the signal destination. GFP (Generic Framing Procedure) is often used in this situation to indicate the position of each Ethernet frame. This requires about 18 Mbps of bandwidth in an OC-12/STM4 signal, leaving about 584 Mbps of available bandwidth. Note that traditional data can be directly inserted into this payload; the next two sets of overhead are only required for video traffic.
Ethernet/IP video encapsulation, which is the process of breaking the source signal into logical segments that are small enough to fit into a packet and adding the headers required to form proper Ethernet/IP packets. By using 1440 bytes of data, adding 60 bytes of IP headers and 42 bytes of Ethernet framing, the overhead works out to roughly 6.7 percent of the total available bandwidth. Applying this to the 584 Mbps remaining bandwidth, about 38 Mbps will be consumed, leaving 546 Mbps bandwidth available.
Forward Error Correction is used on many Ethernet/IP networks. The amount of FEC used depends on the error correction technology (XOR packets, Reed-Solomon, etc.) and the amount of protection desired. The amount of overhead can vary between 2 and 15 percent. For this example, 7 percent of the 546 Mbps is used for FEC, for a total of 39 Mbps. This leaves a total of 507 Mbps of available bandwidth, which is much greater than the 360 Mbps calculated earlier.
CONCLUSION
The common practice of using 270 Mbps signal paths for compressed video data is very inefficient. By removing the unnecessary overhead present in the 270 Mbps signal, and substituting Ethernet/IP headers, network bandwidth can be used much more efficiently. As carriers and broadcasters become more comfortable with this technology, perhaps some of the bandwidth waste will start to disappear from long-haul networks. Thanks to Dave Herfert for suggesting this article topic.
Wes Simpson is a consultant and author of Video Over IP, second edition, now available from Focal Press. Please feel free to contact him at wes.simpson@gmail.com.
