Switched broadcast technology has been hitting the news as the next great bandwidth savior for the cable industry. As other service providers attempt to lure subscribers away with claims of a broader array of options and programs, cable operators must respond with equivalent or improved offerings. With the rapid move from analog to digital and broadcast to narrowcast, cable operators know that bandwidth efficiency is critical. Switched broadcast is specifically designed to allow cable operators to offer a broader range of programs within existing hybrid fiber/coax (HFC) channel capacity. Consequently, many cable operators are actively investigating switched broadcast technology to remain on par with or ahead of their competitors. They realize that customer retention is at least as important as obtaining new subscribers. Surfing the switched broadcast way Switched broadcast technology is based on the principle that out of the (typically) 1,000 subscribers in a service group, not all available programs will be watched simultaneously. Depending on the programming mix, studies indicate that between 30 percent and 75 percent of the available programs are viewed at one time in a service group of 1,000 homes passed. Therefore, if we only transmit the currently viewed programs, we’ll save between 25 percent and 70 percent of the bandwidth and capacity over conventional broadcast. This compares with statistical multiplexing with a capacity savings of about 30 percent that is relatively independent of programming mix. As you might suspect, there is some commonality between switched broadcast and video on demand (VOD) because both require interactivity. Like switched broadcast, VOD allows a subscriber to demand a particular program and have it seamlessly delivered to his home. However, VOD is unicast (it is sent only to the requesting subscriber), while switched broadcast is multicast (a single copy of the program is available to many subscribers at once). Although additional processing is required to ensure programs are unwatched before removing them from the switched broadcast pool, the capacity savings makes it an attractive solution. Switched broadcast thus provides a partial answer to the question of advanced digital service availability. Because of the feverish pace at which technology is advancing, the question has become not if, but when, cable operators need additional capacity. Switched broadcast is still a very young technology with more than one possible implementation model. How cable operators implement switched broadcast is closely tied to when they implement it; and today’s technology must be closely weighed against tomorrow’s needs for providing a full range of services on demand. Three models There are three primary switched broadcast deployment models. They vary in cost and complexity, availability, bandwidth and capacity efficiency, flexibility, and ease of migration. Each model has its advantages and disadvantages, but when selecting an approach, you should carefully weigh each of the criteria on the basis of both your current and projected needs. MPEG local switch As shown in Figure 1, broadcast switching is accomplished at the distribution hub or headend. Each distribution hub will have a dedicated switched broadcast session resource manager (SRM) and dedicated quadrature amplitude modulation (QAM) resources to handle channel selection requests from subscribers served by that hub. The edge QAM devices must support a session control interface to be controlled by the session manager in response to channel selection requests. The early trials of switched broadcast have used this model to verify and prove the statistical advantages and gains of switched broadcast. Switched broadcast channels are multicast via the Internet protocol (IP) transport protocol to the distribution hub level and then broadcast within the service group via MPEG to the set-top. The session manager intelligently analyzes subscriber surfing behavior and determines which programs are watched by which service groups on the network. It creates a finite broadcast "pool" of channels that are watched or likely to be watched. These channels are then broadcast to the service group until new channels are added per user request. Through a remote control and the set-top box, the user sends a request for a program to the session manager. If the requested program is already part of the switched broadcast program pool for that service group, the session manager identifies the QAM channel and provides tuning information to the set-top. If the program is not part of the pool, the session manager requests that the program be added and then provides tuning information to the set-top. The entire interaction is transparent to the user. (Note: CableCARD enabled devices cannot signal for switched broadcast channels.) MPEG central switch In the MPEG central switch model (see Figure 2), video is still delivered via MPEG to the set-top, but we can take advantage of the existing VOD architecture at the central headend. We add extensions to the signaling control plane to allow the set-tops to request channels. The switched broadcast signaling requests can be accommodated using the same digital storage media command and control (DSM-CC) protocol as VOD. The VOD SRM can then be extended to support the multicast session management and allow the edge QAM devices to be shared statistically between VOD and switched broadcast sessions. While the central switch model leverages the existing VOD architecture, it also unicasts multiple copies of each switched broadcast channel to the distribution hub. IPTV The software and the hardware necessary for Internet protocol TV (IPTV) are still in their infancy. While H.264 (MPEG-4 Part 10 Advanced Video Coding) and Windows Media 9/VC1 compete for the codec, DOCSIS 3.0 specifications have yet to be finalized by CableLabs. DOCSIS 3.0 promises downstream data rates of 200 Mbps per channel and 100 Mbps per channel upstream. IPTV uses a two-way signaling model in which an IPTV set-top communicates with a PacketCable Multimedia (PCMM) session manager or application manager. (See Figure 3.) The architecture fundamentally supports switching of any content unique to every set-top. That is, every IPTV-enabled set-top could conceivably request any content that can be delivered via the IP network, including unicast VOD and voice or multicast switched broadcast and high speed data. Unlike the first two models, the IPTV model supports IP delivery all the way to the set-top box. While the MPEG-based models require a specialized session manager, IPTV uses a shared session manager for all applications based on PCMM. It uses a shared set of QAM resources for all applications based on DOCSIS 3.0, and switched broadcast channels are multicast to the distribution hub level and then multicast within the service group. Content aggregation is required to allow channels to be sourced to the IP network in the appropriate format. If channels are not available in H.264 format, then conversion to H.264 can be done by the content aggregator. The IPTV set-top will support direct termination of H.264 video encapsulated in a user datagram protocol (UDP) packet stream. The application manager also interacts with the policy server to request quality of service (QoS) resources. The DOCSIS cable modem termination system (CMTS)/scheduler manages access to the DOCSIS environment and enforces the QoS on the access network using DOCSIS service flows. The recordkeeping server collects the event messages for accounting purposes. Weighing the options We evaluated the three models based according to (see Table 1): *Cost/complexity of implementation *Availability or time to market *Data capacity and throughput efficiency *Flexibility *Ease of migration When comparing the three models, cable operators must consider both the short and long-term implications of the chosen method. For example, some predict that by 2008, there may be more than 20 million subscribers worldwide to IPTV services. Future demands for flexibility and capacity could be fulfilled by IPTV. However, the technologies required to implement IPTV are not yet readily available, while the two MPEG models are closer to realization. Thus, each of the evaluation criteria needs careful consideration. Cost and complexity The MPEG local switch model may be the simplest short-term implementation, but it is a dedicated solution for the switched broadcast service. Switched broadcast session managers must be deployed in each hub and managed by a central manager. The MPEG central switch model requires less initial cost, but is more complex because session and QAM management is shared and combined with VOD management. Moreover, the sub-second response time required for channel change requests is significantly faster than currently deployed VOD systems. IPTV requires potentially the highest long-term investment as DOCSIS 3.0 is deployed and new IPTV set-tops are deployed. Since it creates an all-IP network based on PCMM, session management is the most standards-based of the three models. Time to market/availability The two MPEG switch models can be deployed in the near term, especially as existing VOD devices are enhanced to provide switched broadcast capability. Because of its dependence on DOCSIS 3.0 and IP set-top deployment, cable operators will have a longer wait to implement IPTV. Data capacity and throughput efficiency Data capacity and throughput efficiency consists of both transport and HFC efficiency. Existing transport systems can provide many tens of gigabits per second of capacity at a reasonable cost. HFC capacity gains are much more costly to attain and are therefore of greater importance. The MPEG local switch model uses the transport efficiently through the use of multicast, but suffers in HFC efficiency because of the limited compression of MPEG-2. Extensions to allow multiple services to share the HFC bandwidth are possible by implementing a global session resource manager. The MPEG central switch model, using unicast to the hub, has a less efficient use of the transport capacity. HFC efficiency is the same as the local switch model, but capacity is naturally shared with VOD, reducing the probability of blocking. Finally, the IPTV model is approximately twice as efficient as the MPEG local switch model in both transport and HFC bandwidth utilization because of the advanced coding of H.264 and the statistical multiplexing of all services through the DOCSIS 3.0 IP pipe. Flexibility The MPEG local switch model is the least flexible because of limited resource sharing, and the IPTV model is the most flexible because any service can be carried end-to-end transparently across the network. The MPEG central switch model allows the flexibility to integrate switched broadcast and VOD to offer a network personal video recorder (NPVR) service. Ease of migration Cable operators need to account for such factors as the overall migration path and length of the migration. The dedicated resources of the MPEG local model make it an easy transition. Although a software upgrade is required to implement the MPEG central model, once done the cable operator is simply using existing components. The migration to IPTV may prove to be the most challenging, but laying this foundation will help cable operators stay ahead of satellite and telco providers in three to five years. Summary Although there are three distinct deployment models for switched broadcast, the future belongs to the technology that can provide all forms of interactive content seamlessly and on a large scale. Consumers will insist on integrated voice, video, gaming and high-speed data, and for the foreseeable future, IPTV provides the most effective answer. IPTV bridges the video and IP network boundary while hiding the system’s complexity from the user. In the meantime, cable operators can reap significant bandwidth and capacity savings through the efficient deployment of either or both the local and central switch models. While nobody can predict the future, we can fairly accurately decode future trends, and in the authors’ opinions, it all points in the direction of IPTV. Michael Adams is vice president, Video Architecture and Technology, and Majid Chelehmal is digital video architect, both for Terayon Communication Systems. Reach them at email@example.com and firstname.lastname@example.org.