  |
 |
Search
|
||||||||||||
 |
Critical Success Factors for Video Distribution A key issue for our customers is whether to centralize or distribute video servers. A centralized model avoids the costs of installing and maintaining servers in cramped remote distribution hubs, potentially reducing ongoing operating expenses. However, centralized servers offer limited scalability because of the additional load that is placed on the IP backbone network. For example, a VoD subscriber will typically need at least 10 times more bandwidth over the IP backbone than a subscriber using data and voice services. In addition, the quality of MPEG-2 encoded video is highly susceptible to delay, jitter, and packet loss. Video on demand bandwidth consumption in the IP network can be minimized by locating on-demand servers as near to the subscribers as possible (i.e., in distribution hubs). However, as the volume of available on-demand content increases, replicating all content at every distribution hub becomes impractical. Therefore, it is likely that most cable operators will converge on an architecture that supports a combination of centralized servers for low-demand content and distributed servers for high-demand content. Distributing video over core and access networks is necessary for the delivery of IP video services. Two main categories of video service exist: On-demand and live/scheduled. An on-demand program is receiver-controlled; each receiver fully controls the streaming session. At any time, the receiver may initiate the program stream, control it via VCR-like functions (or "trick" modes) such as fast forward, rewind or pause and also terminate the program. Live/scheduled programs, on the other hand, are source-controlled and transmitted continuously. A receiver may only tune to such a program to listen to it or watch it, but cannot control it. Note that the content source in a live program is a real-time event that is encoded and transmitted as it is happening. Content source of a scheduled program, on the other hand, is a pre-recorded event stored on videotape, DVD/CD or some other medium. Multiple ways to transmit a video program over an IP network exist. These include unicast, multicast, splitting (or reflected unicast) and edge multicast (or reflected multicast). Unicast: In a unicast transmission, each receiver receives its own stream from the media server. With 1,000. active receivers, for example, the media server 'serves' 1,000 streams. Though unicast allows a receiver to fully control the stream, it quickly becomes unscalable because of the significant demand it places on network and server resources. For live/scheduled programs, unicast is clearly quite inefficient. Multicast: Multicast is an efficient Layer 3 mechanism for delivering a media program to many receivers. Here, the server sends out a single program stream to a multicast group. The multicast-enabled IP network to which this server and the intended group of receivers are connected is responsible for delivering this stream. If the receivers are spatially distributed (in a network sense), then the IP network replicates the stream as necessary to reach all receivers of that multicast group. Multicast is quite efficient for live or scheduled programs because 1) it requires minimal server resources--only one stream per program regardless of the number of receivers; and 2) it requires minimal stream replication in the network, at most one stream per link depending on the receiver distribution. Note that the server continuously transmits each live/scheduled program stream. Receivers join and leave the program asynchronously using the Internet Group Multicast Protocol (IGMPv2, RFC 2236). The IP multicast network is responsible for building an efficient tree to distribute multicast traffic. Edge network devices are responsible for maintaining the group membership of receivers and replicating streams to them. Splitting: The term "splitting" describes an efficient delivery mechanism of live/scheduled programs over a non-multicast network. Splitting allows tree-based distribution of unicast streams to the network
edges. Each receiver connects to an edge server close to it (as determined
by the request routing mechanism). The edge receiver then determines a
path from it to the origin server. Edge multicast: Even with splitting, the edge server fan-out may be a concern when serving to a large community of users. Hence, it is beneficial to convert the edge portion of the non-multicast network to multicast. Streams traverse most of the network as unicast via splitting (as discussed above) or via generic route encapsulation (GRE) tunnels that encapsulate multicast traffic in a unicast tunnel. The last-hop delivery of this stream, from edge to user community, is via multicast. QoS and Streaming: A critical consideration when designing streaming media networks is quality of service (QoS). To deliver a consistent, high-quality user experience, the network must maintain a given stream's specified latency and throughput requirements. On the optical backbone network segment, from head end to hub, QoS is achieved using either differentiated services (diff-serv), resource reservation protocol (RSVP) or a combination of both. Diff-serv classifies IP packets into a few aggregated classes using type of service (ToS) bits or diff-serv code points (DSCP). RSVP may be used to reserve bandwidth on a per-data-flow basis through the core IP network or to dynamically assign DSCP values to each flow. In addition, RSVP signaling is used to initiate, configure and terminate DOCSIS 1.1 service flows between the CMTS and cable modems. |
|
|
Products