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 – to learn more, subscribe to this service.
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