Video delivery, content network, IPTV, triple play -- these are just a few of the terms used today for video over broadband data networks. This concept of video networks is an increasing challenge, and like most network challenges, this one is influenced by technology, business and regulatory factors.
Video poses three major challenges to network planners and operators. First, video is bandwidth hungry as an application. A video file is huge in comparison with almost any other type of information carried over a network. Second, streaming video requires real-time consistent network performance. Most broadband applications are highly tolerant of variations in delay and packet loss, but video is often totally corrupted by even a small variation in delay, and any significant packet loss can destroy the viewing experience. Finally, video is perceived by the user to be a continuous long-term experience, and if any significant portion goes badly, complaints and demands for refunds will result. Unlike a lost call or a bad connection in voice, which users repair simply by redialing, a video connection is a commitment on both parties, and any failure is almost certain to create negative customer reaction.
These factors influence all video networks, but the degree of impact depends on the video model. There are three broadband video service models. Broadcast video models replicate the behavior of a cable system, offering a customer multi-channel viewing. Video on demand (VoD) models allow the customer to stream video in real time, but the video and the viewing time are selected by the customer. The "store for play" model (download model) allows the customer to load the video onto a local disk for viewing.
All video networks start with the same customer, so the first step in understanding video network design is to understand where the networks stop -- what the content source will be. General practice today is to cache content in each major metro area, and this is most likely to be done for the broadcast or streaming VoD models. Local caching eliminates the performance variability that is introduced by Internet transport or core peering relationships, and most video programming popular enough to be profitable will probably be consumed enough in a metro area to justify the cost of local storage. This means that most video networks will be metro networks.
From the content source(s), video networks must distribute video outward, but not so much to "customers" as to "customer gateways." All broadband networks, whoever deploys them, have a natural process of access aggregation that collects many customers to a single service point. In telephony, this would be called a "central" or "serving" office. In effect, a video network is a set of star connections between content sources and these customer gateway points. This means that all video networks can be viewed as two-zone structures: metro delivery to the gateway points and then delivery to the customers on the access network. These two topics must be considered separately.
Broadcast channels are distributed via satellite. In some cases, operators may partner with direct broadcast satellite (DBS) providers for broadcast material, in which case this material is not carried on the video network. Where the operator will actually carry broadcast, the network requirement depends on which approach is used for broadcast channel delivery to the customer. That will generally depend on the media used for the customer access network.
Where the customer is attached via very high-capacity media (CATV cable, PON-FTTH), the operator may elect to feed broadcast channels using what is often called "linear RF," meaning simply broadcasting the channel material in standard cable format. In this case, the broadcast material is not really carried by the video network at all. Where copper loop wiring is used (DSL), the capacity is not sufficient to carry even the minimum number of broadcast channels in a typical basic package, and a form of channel mapping must be used. With this approach, the customer's access connection is divided into "slots" into which channels can be mapped on demand. The capacity of the access connection will determine how many slots can be allocated (about 4 Mbps per standard definition slot and about 8.5 for high-definition). The customer, when tuning, selects a channel that serving-office equipment then maps to a channel slot.
Channel mapping creates a significant new set of requirements in the video network because the broadcast channels must be distributed to the gateway points in data format and then packaged onto the appropriate DSL connections. Most current systems use the IP multicast protocol and its associated registration protocol (IGMP) for this purpose. Special handling is needed to ensure that the customer's screen does not pixelate when channels are changed, a common problem if the switch occurs between compressed video "key frames."
Clearly a broadcast strategy that doesn't involve data-formatted video at all presents the least difficulty to network designers, but since most channels will probably be used by someone in a given gateway point, the video load to each gateway point can in fact be treated as constant by designers. Thus, broadcast video metro distribution is a fairly simple application -- simply size the pipes between the gateway points and content hosts correctly.
Video on demand has completely different metro requirements. A typical community of 8,000 users at a gateway point might have 300 broadcast channels, generating about a 1.2 Gbps load in standard definition if data-packet video is used. If that same community watches an hour of streaming VoD, the data load could be five to eight times that, depending on how likely it is that the streaming periods of users overlap. All of this variable load must be carried between the gateway points and the content servers. This means that video networks that expect to offer VoD should be designed for VoD loads. Video on demand is definitely a metro fiber and DWDM application for most operators.
Most users expect broadcast video to be real-time, but VoD can be buffered to ride out network variables like delay and delay jitter. Packet loss is difficult to tolerate in video networks, however, so where VoD buffering is available, it is common to trade delay against packet loss in the design. It is also common to oversupply network capacity to avoid congestion in the first place.
Video networks are distribution networks, not communications networks. Most are designed to prevent user traffic from riding on the video resources, and so peer connections are not only not needed but actively discouraged. This means that the topology of networks designed for video is more likely to be a star than a mesh, and that redundancy is provided by simple mechanisms like multi-homing.
About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM and the IPsphere Forum, and the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies.
