Video over DOCSIS
Why are cable operators considering Internet protocol (IP) video and IPTV as ways to supplement their current digital video delivery? The simple answer is more content sources and more device destinations, as illustrated in Figure 1.
In a world of more Internet-based sources destined for more subscriber IPTV playback devices, IPTV will play a significant role in the delivery of video on demand (VOD). Just how much VOD is delivered as IPTV will determine how much additional downstream DOCSIS bandwidth is needed for IPTV.
Consider a hypothetical 5-7 year "endgame" scenario where each video subscriber can download "what I want when I want" (WIWWIW). Assume a fiber node of 750 homes passed has 75 percent video subscriber penetration, and during the busiest video viewing hour, 50 percent of the video subscribers require an average of 10 Mbps VOD content. The total VOD content required to be delivered to that single fiber node during the busy hour is thus 750 * 0.75 * 0.50 * 10 Mbps = 2.8 Gbps, or 73 carriers of 6 MHz at 256-QAM (quadrature amplitude modulation). What fraction of this "endgame VOD" bandwidth is IPTV over DOCSIS and what fraction is traditional digital video to digital set-top boxes is anybody’s guess.
Note that VOD bandwidth swamps high-speed data bandwidth. In 2006, most cable operator deployments provided only 20 Mbps of high-speed data per 750-household fiber node. A reasonable endgame scenario for high-speed data would provide 100 Mbps channel bonded service to 50 percent of households passed with a 0.25 percent concurrency, for a total high-speed data fiber node throughput requirement of 750 * 0.5 * 0.0025 * 100 Mbps = 94 Mbps. Thus, under reasonable hypothetical endgame scenarios, VOD is expected to require 26 times the bandwidth of high-speed data.
A key goal of the DOCSIS modular cable modem termination system (M-CMTS) architecture was to define a common edge QAM architecture that could support a cost-effective transition from digital VOD delivery to IPTV VOD delivery over DOCSIS. A straightforward strategy of using M-CMTS to provide IPTV VOD would call for deploying M-CMTS edge QAMs for digital VOD first and adding M-CMTS core capacity as needed to transition the digital VOD to IPTV-VOD. As we have seen, though, the M-CMTS core capacity used for IPTV-VOD will quickly exceed the CMTS capacity used for high-speed data. A straightforward implementation of M-CMTS for IPTV, therefore, will require many times the cost of M-CMTS core capacity as that currently used for high-speed data.
This article revisits a simple alternative for IPTV support with M-CMTS: Tunnel IPTV directly to the edge QAM, bypassing the M-CMTS core altogether. This technique is called the DOCSIS IPTV bypass architecture (DIBA).
Understanding DIBA DIBA refers to any of a number of techniques whereby downstream IPTV traffic is directly tunneled from an IPTV source to a downstream edge QAM, "bypassing" a DOCSIS M-CMTS core. Bypassing the high-cost components of the CMTS core enables the delivery of high-bandwidth entertainment video over DOCSIS to the home for a price-per-program that matches the cost for conventional video over MPEG-2 delivery to set-top boxes.
IPTV is by definition an IP packet with video content from an IP source to an IP destination address. In traditional IPTV, an IPTV server sends an IP packet to the destination address of a subscriber playback device, which we call generically an "IP set-top box." With the M-CMTS architecture forwarding, the IPTV packet is routed through the M-CMTS core, as depicted in Figure 2a. In a conventional M-CMTS architecture without DIBA, therefore, the IPTV content is forced to make two transits through the converged interconnect network (CIN) switch that connects regional networks with the core CMTS. First, the video travels to the M-CMTS core, then "hairpins" back through the CIN on a DOCSIS external physical interface (DEPI) pseudo-wire to the DEPI edge QAM. If and when IPTV becomes a significant fraction of overall bandwidth delivered to a fiber node, this hairpin forwarding of IPTV content will require significant expenditures for M-CMTS core and CIN switching bandwidth.
Figure 2b illustrates DIBA approach. Rather than pass through the M-CMTS’s core, the high-bandwidth video/IP content is tunneled from the IPTV server, through the cable operator’s CIN directly to the DIBA edge QAMs. The IPTV emerges from the DIBA edge QAM with full DOCSIS framing, suitable for forwarding through a DOCSIS cable modem to home IP devices. This architecture is designed to deliver high-bandwidth entertainment video/IP/DOCSIS to the home for a price-per-QAM that matches that of the most advanced, cost-reduced MPEG-2 edge QAMs. Economy DIBA accomplishes the goals of the M-CMTS without the unnecessary expense of the M-CMTS. Operators can deploy independently scalable numbers of downstream channels without changing the media access control (MAC) domain or the number of upstream DOCSIS channels. These downstream channels are available for VOD/IP and switched digital video (SDV)/IP. They can also reduce the cost to deliver video over DOCSIS service to be competitive with today’s MPEG VOD.
Figure 2b also shows an integrated CMTS deployed with DIBA. Here the DOCSIS channel from the CMTS is fully functional, containing timestamps and is called "synchronized." The DOCSIS channel from the edge QAM, which is carrying the IPTV, lacks the synch timestamps and is called non-synchronized. Figure 2b depicts an important additional economy for IPTV: the ability to use non-synchronized downstream channels to DOCSIS 3.0 cable modems. This permits IPTV to be delivered with edge QAMs that are not synchronized to the DOCSIS master clock with the DOCSIS timing interface (DTI). Thus, the installed base of edge QAMs can be used to deliver IPTV. DOCSIS 3.0 cable modems require DOCSIS master clock synchronization on only their primary downstream channel, which can be supplied by an integrated CMTS or a single DTI-timed M-CMTS edge QAM.
DIBA avoids the expense of the DOCSIS MAC domain technology for the video/IP traffic by using both synchronized and unsynchronized DOCSIS downstream channels. The synchronized channels pass through the integrated CMTS or the CMTS core and provide the many DOCSIS MAC functions, including:
• Conveying the DOCSIS timestamps
• Managing ranging to provide the proper time-base to the cable modem
• Instructing the cable modems when to transmit upstream
• Delivering other MAC layer messages for cable modem registration, maintenance, etc.
In contrast, the unsynchronized DOCSIS channels are generated by the edge QAMs (including installed MPEG edge QAMs) for the bypass traffic and omit these functions. With an integrated CMTS and no timestamps in the un-synchronized channels, the DTI, which is required in the M-CMTS architecture, is not necessary in DIBA.
In DIBA, a DOCSIS 3.0 cable modem requires only one synchronized channel from the existing integrated CMTS to provide timing, control the upstream transmissions, and provide the other MAC functions. The DOCSIS 3.0 cable modem will receive video/IP on additional un-synchronized, inexpensive, DIBA-generated channels, which can even be bonded. Encapsulation Figure 3 shows a hypothetical cable operator IPTV network, showing both the backbone network and the DOCSIS network, including customer premises equipment (CPE). Included are an IP Multimedia Subsystem (IMS) core and session initiation protocol (SIP) server, so as to enable IPTV session mobility, handoff, etc. On the access network side of the last-hop router are shown the standard components: PacketCable Multimedia (PCMM) and policy server, CMTS, and edge resource manager (ERM). Also shown is a DIBA application manager, which is new. The DOCSIS subnet on the CPE side of the CMTS is also shown. Since digital video is distributed via IP to the edge QAMs, these are also shown. Shown in red is the path for DIBA-based IP video. There are two distinguishing features to this path. First, instead of traveling from the last-hop router to the CMTS, the packets bypass the CMTS and instead go to the DIBA encapsulator/edge QAM. Secondly, the IP-video path actually goes "off" the IP network. The edge QAM is performing DOCSIS encapsulation, but only for the special case of highly repetitive packets of certain IP-video flows. This is economical to do since DOCSIS is based on the ITU-T J.83, MPEG-2 transport stream physical layer that is used by digital video. To the cable modem, this downstream QAM is indistinguishable from a non-primary DOCSIS downstream channel. The CMTS has instructed the modem to treat this QAM carrier as such. So DIBA is leveraging the digital video origins of the DOCSIS physical layer.
Figure 4 shows the interactions of the same components in the setup of a unicast IP-video flow over DIBA. In this case, there is video session mobility, so the IPTV client uses SIP to contact the IPTV server, via the proxy-call session control function (P-CSCF). In this case, there is a DIBA application manager between the P-CSCF and the PCMM components. Control plane Most of the standard control plane functions of PCMM and M-CMTS are retained. The setup of a quality of service (QoS)-enabled unicast IPTV session are as follows.
1. IPTV client requests IP video. For the SIP-based unicast, the request goes to the P-CSCF, which forwards the request to the IP video server. The P-CSCF obtains the IP address and port of the video server. The P-CSCF forwards the service request to the DIBA application manager, including the QoS requirements, the 5-tuple for the flow (source and destination IP addresses, source and destination ports, the IP protocol). The DIBA application manager forwards this information to the PCMM manager. This is a COPS message requesting a PCMM gate spec object with a new IPTV session ID. The policy server forwards the request to the CMTS.
2. CMTS requests downstream channel from ERM for new IPTV service flow.
3. CMTS checks authorization of modem for desired class of service and if QoS can be supported, then creates new service flow and directs modem to perform dynamic service add (DSA).
4. CMTS directs modem to perform dynamic bonding change (DBC), adds the new channel to receive channel set to receive the IPTV flow, adds the DSID, which is necessary for multicast DSID-based forwarding (MDF) by the modem.
5. The CMTS sets up an L2TP tunnel to the edge QAM that had been selected for the IPTV flow. This will enable the CMTS to generate the necessary MAC domain descriptors (MDDs). However, the MDDs could also be generated by the encapsulation engine. Additional requirements The following additional operations are required to setup a DIBA session for IPTV.
1. PCMM gate set message containing new IPTV session ID signals to the CMTS that this is a DIBA bypass video flow.
2. The CMTS instructs the modem to join/receive certain non-primary downstream DOCSIS channels (form the edge QAM). But the CMTS does not actually generate these channels itself.
3. CMTS makes available certain additional fields necessary for DIBA encapsulation. These fields are obtained by the DIBA application manager and configured in the edge QAM/encapsulation engine: (A) CMTS MAC address; (B) CPE MAC address; (C) DSID for MDF; (D) frame control field of the MAC header for the type and format of the data PDU; (E) MAC_PARM field of the MAC header.
4. CMTS makes available certain fields for identification of the IPTV and IP-video packets to be bypassed. This information might be used by a bypass application manager to configure the last-hop router to identify these packets by: (A) source and destination IP addresses; (B) source and destination port numbers; (C) IP protocol type.
5. The last-hop router would typically send all IP packets with destination addresses on the cable CPE subnet to the CMTS for forwarding over DOCSIS. However, in this cast the last-hop router will inspect the packets based on the 5-tuple listed previously. Those packets matching video flows will be sent to an encapsulation engine, bypassing the CMTS. The DIBA application manager will configure the forwarding policy in the last hop router by using the existing MIBs: (A) the packets could be sent over a different interface, such as a generic routing encapsulation (GRE) layer 3 tunnel from the last-hop router to the encapsulation engine; (B) the packets could be sent over a label-switched-path from the last-hop router to the encapsulation engine.
6. As mentioned previously, instead of relying on the CMTS to generate the MDDs, it is possible for the CMTS to provide the fields for the MDDs so that the encapsulation engine can generate the MDDs. Cost savings Cable operators will be able to economically supply IPTV capacity of gigabits per fiber node by bypassing the M-CMTS core and tunneling IPTV directly to the M-CMTS edge QAM. DIBA is designed to allow operators to avoid the cost of additional M-CMTS core capacity for IPTV.
DIBA is proposed as a work item for CableLabs after DOCSIS 3.0 draft specifications. If it is approved, CableLabs would standardize:
• Data plane operation from IPTV server to DIBA PSP/MPT converter, DIBA distributor, and DEPI/MPEQ edge QAMs
• NGOD session manager control signaling to IPTV server
• CMTS control signaling to DIBA distributor and PSP converter functions in CIN
• CMTS control signaling to edge QAM
DIBA is intended to remove the boundaries of delivering video using an M-CMTS, and to allow cable operators to leverage service velocity by efficiently delivering IPTV services that bypass the M-CMTS core.
Michael Cookish is director of product management for Motorola’s Home and Network Mobility Solutions. Reach him at [email protected].
