Implementing video on demand

Video on demand, in at least some of its potential service models, is perhaps the most challenging of all network applications. Streaming real-time video poses major challenges in controlling packet loss and delay/jitter, and video on demand (VoD) creates potentially large swings in bandwidth requirements that can affect not only the performance of video customers but also the performance of metro network applications overall. The process should be undertaken in three steps:

1. Consider the service model, meaning the nature of the content, the format of the video, and the appliance(s) to which the video will be delivered.

2. Consider the delivery model, meaning the characteristics of the customer access network and the metro connection network.

3. Consider the management and support model, meaning the way in which video will be ordered, supported and billed.

Video on demand service models can be characterised by the type of device on which the video will be viewed and, for some, also by the degree to which the video can be buffered on delivery prior to viewing. The options here are:

1. Small-screen video, designed to be viewed on a mobile phone, game console, or other portable device. This form of video generally requires lower resolution even for standard-definition material and is not normally used for high-definition, owing to restrictions in viewing. It is therefore likely to consume less bandwidth. In addition, users are more likely to tolerate viewing glitches with this type of material. However, buffering is probably not available here.

2. Computer video, delivered to a laptop or desktop computer or to a "media centre" computer. This form of video requires higher resolution -- as high, in fact, as TV viewing -- but the computer system can normally buffer the material to accommodate variations in network performance. Users of computer video may even want to store the material locally for multiple viewing.

3. TV viewing, where the video material is delivered to a "set-top box" and fed to a television screen for viewing. Users of this type of video have the least tolerance for video problems, and this form of video demands the highest possible quality. In addition, it is often impossible to buffer this material, and so any variations in network performance are likely to create a customer complaint.

The delivery network is divided into two parts, the actual customer broadband connection portion and the portion that delivers video to the customer broadband point of presence or gateway. The broadband connection to the customer sets the limit on bandwidth available for VoD. Not only must the bandwidth be sufficient to handle the video (4-5 Mbps for standard-definition, full-screen video and 8-10 Mbps for high-definition) but it must also be sufficient to ensure that access congestion does not create a problem with delay or packet loss. Most for-pay VoD services and probably all pay-per-view VoD services will need some form of access bandwidth management to ensure that multiple video users or other broadband applications do not have an impact on performance. There is no point managing network performance deeper in the network just to lose all the benefits at the access point.

Video on demand consumes so much bandwidth and generates so much potential variation in network load that most operators will design VoD networks separate from other applications. In the metro network, for example, it is a best practice to use separate wavelengths or tunnels for VoD and to reserve capacity for these independent of other applications. Since some VoD use is influenced by mass market trends (release of a new film, a special TV episode, a concert, etc.), it may be advisable to support reconfigurability of bandwidth to accommodate sudden surges in use or synchronisation in viewing. This is particularly true where VoD feeds support live events.

The management and support model for video on demand is very possibly the most important and most neglected of all the issues in VoD. Network operators have confronted steadily rising customer-care costs, and today a single customer-support incident can cost so much that it will take years of profitable relationship with the customer just to break even. In fact, where VoD is offered by a third party or by a separate organisation (particularly if that organisation is structurally separated for regulatory reasons), it is critical that the responsibility for customer care be established clearly, not only among the provider organisations involved but also with the customer base.

Customer care in VoD can be classified as follows:

1. Network-preemptive, where network monitoring and remediation of problems work to ensure that failures or congestion do not affect service. This is a very important category because preventing customer complaints is normally far cheaper than responding to them.

2. Service-preemptive, where explicit knowledge of a given customer's state of VoD service can be obtained from the customer premises equipment, the content server, or from the network. This type of care can be targeted, as is network-level care, at preventing problems by anticipating congestion and so on, or it can be targeted at opening a customer dialog through the viewing channel to interdict any customer call. For example, a network congestion event that is known to cause packet loss can be assumed to affect service and might result in a brief note that "We're sorry for the interruption, but the problem has been corrected." This kind of message is rarely appropriate for network-preemptive care because not all customers are likely to have been affected.

3. Reactive, where the goal is to respond to a problem that is being reported by the customer.

Reactive care will have two primary goals: to induce the customer to seek online support rather than to involve a customer service representative, and to reduce the time to resolve the problem by providing customer support personnel with enough information to quickly diagnose the problem and offer remediation to the customer.

Video on demand is the most challenging of all network applications because of its bandwidth requirements and QoS requirements. Unless careful design and implementation practices are followed, the profit on these services can be quickly eroded, along with the credibility of the service provider.

About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specialising 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.