One of the big advantages of Ethernet links is that they are bi-directional and much less expensive to deploy. This allows a content distributor to use their forward channel for sending the video and audio while the reverse path is used to monitor the receiver site. For most real-time, point-to-point applications (e.g., live telecasts), a transport stream (TS) is sent over a SMPTE 2022 compliant IP connection. The video and audio is encoded in a compression format (MPEG-2 H.264, H.265, JPEG2000 etc.) and packaged into yet another (MPEG-2 TS) format. The TS is then encapsulated over IP/Ethernet for transmission.

Configuring Transmissions Over A WAN

By definition, a wide area network (WAN) connects two locations that are not on the same local area network (LAN). They are often separated by a great distance and may be in different cities, states, or even countries. A WAN is then used to connect multiple LANs together. There are private WANs where the Ethernet lines are reserved for a company or a group of people, and there are public WANs. A public WAN is the Internet as we know it. Private WANs are more like long-distance LANs with data traveling across reserved lines between them.

Transmitting video over WANs is different than transmitting video over LANs because users rarely have control over the complete network; typically they only control the end point that belongs to each of the LANs and the WAN trying to connect them.

When transmitting real-time streams over IP from point to point over a WAN, there is no second chance when following the SMPTE 2022 standard. The data is sent once over the network with no possibility to resend, retry, or even know if the TS reaches the destination. We refer to this as “fire and forget” because we send (“fire”) content over the network and forget about it. The delivery pass can’t be altered. In the past some companies have promoted proprietary ways of resending lost packets over IP for video transmission, but these are at the expense of increased bandwidth and large induced delays. This to date has forced content providers to purchase end-to-end equipment from a single supplier.

What happens if some (or all) packets don’t arrive at the desired destination? A single Ethernet packet can carry up to seven MPEG-2 TS packets. If a packet is lost in the transmission, it will affect the output stream and could affect the picture. (It's difficult to say for sure what the impact of the lost packet will be, as it depends on the actual packet lost.)

For example, if the lost Ethernet packet only contains information pertaining to a corner of the picture—affecting only one or two pixels—the result might be a barely noticeable artifact on the decoded picture. If, on the other hand, the missing packet pertains to the start of the audio frame, it could result in a very loud pop. Another issue is that the loss of packets over a WAN is unpredictable and none of the network equipment is aware of the content that is being transmitted.

Most IT experts will tell you that it’s rare to find a dropped packet due to a few altered bits within, because most Ethernet switches perform a cyclic redundancy check (CRC) on packets. If a packet’s CRC calculation doesn’t match the expected CRC, the switch will discard that packet and it will be missing down the link. So, you either successfully transmit an entire packet or you don't.

Equipment At The Edge

One of the few things operators have control over when sending video over a WAN is the edge equipment, or physical gear connecting the LANs to the WAN. This equipment is critical because it is typically exposed to the WAN network. Therefore, it is important to choose equipment that is secure, separating your WAN from your LAN while still allowing remote access for configuration and monitoring. This is to ensure that hackers cannot use the video connection to enter your LAN.

On the transmission side, the safest way to isolate the LAN from the WAN is to use an ASI-to-IP converter. ASI is a unidirectional BNC, so there is a bi-directional connection connecting the LAN video network to the WAN. In terms of features, it is important to send the IP video on the WAN without jitter. Jitter and network delay can wreak havoc on the WAN (in terms of the viewer experience), so it is important to start the transmission with a near perfect signal. To protect the packets during transmission, it’s advisable to use transmission equipment that supports SMPTE 2022 forward error correction (FEC) signal generation.

Not all locations are equal. Some big cities have great network connectivity, making it easy to acquire bandwidth. However, if network traffic is very high, the WAN may have more trouble forwarding the video data without errors than it would in a more rural environment, where bandwidth may be limited but traffic is light.

On the receive side, the same rules apply when converting back to ASI to ensure the isolation of the networks and complete security. The receiver needs to be able to detect and fix errors using the FEC information and also allow for jitter correction. Ideally, the receiver delay can be adjusted to enable enough delay for FEC calculation and jitter management, but not too much that it becomes unusable in a real-time environment.

ISPs Can Limit Flexibility

Your Internet Service Provider (ISP)’s main job is to connect local customers to the Internet. Most traffic on the Internet doesn’t require critical traffic timing and rarely follows the “fire and forget” rule. As a result, very few ISPs are ready to carry real-time UDP traffic with zero dropped packets unless they have over-designed their facility and traffic is light—compared to capacity. ISPs will change, upgrade, and maintain routers without any warning, which risks taking your wireless circuit down. It is advisable to discuss your real-time needs with your ISP prior to sending critical data.

Foreign Sources

In the SDI video world, we are used to being able to follow the wire—from the source, to the video router, to the processor and on to the desired destination. Most of the time video signals travel one at a time over a single cable in one direction. The method for troubleshooting this signal path is well managed and understood. When transporting video over IP, however, we are potentially dealing with multiple signals on the same wire, bi-directional traffic, and unrelated traffic on the same wire. That can negatively affect the quality of your signal.

In addition, when traveling on a WAN, the engineer has to be aware of unknown equipment and paths, which can make troubleshooting very difficult and challenging, when problems occur. Some routers might be obsolete, not performing properly, or not configured as needed. Remember, the quality and speed of the WAN will only be as good as the weakest link in the chain.

The Value of Private Networks

In theory, private networks should be better than the Internet, and therefore the best and most cost-effective way to send video. Private networks are more secure than the Internet but performance wise they maybe worse for video, due to VLAN, shared devices virtually or overlaid protocol slowing down the video connection. However, very few networks today are truly private with dedicated equipment. Many “private” networks share switches and equipment within the company or within the ISP with other providers or traffic.

Indeed, most private networks are virtual private networks, which can provide a false sense of security. And unless they are designed for video, many types of firewalls, virtual LANs (VLAN), virtual private networks (VPN), and corporate network policies can introduce opportunities for unwanted access that make these private networks less reliable than the Internet. In addition, the cost of a private network is typically much higher than the Internet so cost versus capability needs to be looked at carefully.

Bandwidth Requirements

Having access to enough bandwidth is always the key to a successful WAN transmission. But what does having enough bandwidth mean? First we have to consider the bitrate of the stream being sent. Then we have to add about 4 percent for IP encapsulation. Depending on the FEC needed, there is another 25 to 35 percent premium on the bandwidth for error correction. Finally, the link is rarely constant, so allocating another 25 percent of headroom is a good idea. Therefore, if you have a 20-Mbps signal to deliver, you will need a minimum 35 Mbps link. The good news is that most cable modem and DSL lines can be scaled from 35 Mbps to 50Mbps without too much problem.

Unicast Transmission

Unicast transmission is designed for point-to-point delivery, whereas multicast transmission is designed for point-to-multipoint delivery. Sending a TV signal to two or three regional cable companies would be called a multicast. However, most WANs cannot handle multicast transmission. This is certainly the case for the Internet, where unicast is the only possible transmission. With a unicast transmission architecture, if you need to send your transport stream to multiple locations, you will need to initiate multiple unicast transmissions, each using the same amount of bandwidth. Typically, this is not very practical.

In private networks, multicast transmission is possible, but the network needs to be multicast-aware. If any switch is not capable of handling multicast traffic, it will treat the traffic like a broadcast and send it to every port, creating havoc on the network. That’s why all multicast networks have to be purposely designed for handling audio and video data traffic. If multicast is not an option and you need to send your traffic to multiple locations, using a content delivery network (CDN) may be a good option.

CDNs are used to rapidly and cost-effectively deliver a variety of content to numerous end points, whether they are Web browsers, mobile devices, set-top boxes, gaming consoles or business customers’ desktop PCs. A CDN can take your unicast transmission and “duplicate” the content, delivering it to as many points as you need without having to consume your local bandwidth. CDNs are mostly used for consumer applications, but can also be applicable for business-to-business, real-time video delivery.

Avoiding Dropped Packets (Steady And Burst)

Dropped packets are the enemy when transmitting video over IP. As there is no chance of retransmission in UDP/RTP, any dropped packets and the data associated with them are lost forever, unless you are using error correction technology. Dropped packets can come from two main sources: A discarded packet due to a bit error or a lost packet due to a buffer overflow.

If a bit in an Ethernet packet is modified due to signal noise, for example, the next network device the packet encounters will most likely discard that entire packet. Each network device performs a CRC calculation on the packet upon arrival, and if the CRC calculation doesn’t match the expected value, the packet will be discarded. This type of packet loss typically results in a steady packet loss rate (one packet lost once in a while). Bad cable, too long of a cable run, or faulty equipment will all create this kind of bit error.

Most network devices have small input buffers, making overflow during a traffic burst a reality. If a switch is busy with multiple tasks or is over-subscribed, it could take too long for the input data to be routed, overflowing the input buffer and resulting in dropped packets. Typically several packets are lost at once, resulting in a burst of lost packets. Note that some higher-end networks can configure the size of their input buffer, allowing the user to increase the input buffer and minimize the chance for overflowing and dropped packets.

Forward error correction is designed to recreate lost packets. It can handle steady packet loss easily, but for burst packet loss, 20 packets is the limit of what the software can recover. Beyond this, FEC cannot completely correct a faulty stream.

Addressing Network Jitter

By definition, transmission over IP will create jitter or bursts in the transport stream data. Each Ethernet packet typically carries seven MPEG-2 transport packets, so the transmission of MPEG-2 packets will be sent by bursts of seven MPEG-2 packets at a time, even if there is no network jitter. A delay in processing input in network equipment will create network jitter, where Ethernet packets are not spread equally in time anymore, which creates traffic bursts. Jitter is not really a huge problem by itself if the network and edge device can handle it. As the input buffers of network devices are typically fairly small, however, a network traffic burst can result in overflowing and dropped packets.

On the receiving end, edge devices need to be able to absorb traffic bursts to avoid overflow as well as underflow. Because typical transport interfaces like ASI often feature constant bitrates with equally spread packets, the output of edge devices must be capable of having enough packets in their buffers to avoid underflow. Otherwise, it will create a disruption of the output signal. Compared to network equipment, most edge devices have large input buffers, but they need to offer configurable delay in order to avoid underflow. Underflow happens more often when a low-bitrate stream is being transmitted, because there is much more time between incoming packets.

Redundancy Is Critical

In a broadcast system, high availability is a big part of the system design, so redundancy is quite often a major consideration. Making a system redundant over a WAN is quite difficult. As transmission is point-to-point (unicast), traffic often needs to be sent twice to ensure redundancy. As most problems occur with the signal path and network equipment, it is important to have diversity in providers, equipment, and identified paths for true redundancy. If two ISPs connect to the same network trunk, the customer may get a false sense of redundancy. It is important to discuss network paths with your ISPs. For example, it is most practical to handle the switching of the path outside of the WAN at the ASI level.

It should be noted that the SMPTE 2022-7 standard offers a way to create some redundancy by sending the same Ethernet packets to two different destinations/paths simultaneously and creating a packet-per-packet redundancy at the receiving end that can protect TS data. Most engineers will use a completely different way of protecting their WAN network path, such as microwave or satellite links.

So, it’s clear that Ethernet links offer a variety of advantages that can't be ignored. Deploying them takes careful consideration, innovative system design work, and time/money, but the benefits of IP infrastructures to broadcasters and content providers alike are well worth it in the end. Expect to see an increased use of WANs for content delivery. To gain network scalability and signal flexibility, it just makes practical and financial sense.