Pipeline Profile: Saifur Rahman

Title: Principal Engineer, Comcast

Broadband Background: Rahman works in national engineering and technical operations for Comcast.

SCTE member since 2004

Your DOCSIS migration methodology article includes a review of the 11-year old spec as well as a hypothetical five-year road map including the latest capabilities. That’s a lot of DOCSIS territory. How did you gain that kind of perspective on this technology?

It helps to have a good background in Ethernet/IP networks and digital communications. DOCSIS uses many standard protocols, and having prior knowledge of these help(s) to quickly understand the nuances of DOCSIS. For example, the upstream is very similar to TDMA cell phone networks. The DOCSIS upstream is much easier to understand with this background knowledge.

For someone new getting into networking and DOCSIS, I would recommend two books that helped me: Computer Networks by Andrew S. Tanenbaum, which provides a solid background in communications and networking and Digital Telephony Over Cable by D.R. Evans, although dated, still provides a good background on DOCSIS and PacketCable.

We’ve heard DOCSIS 3.0 described as a 10-year node. Does that make sense to you?

DOCSIS 3.0 is fundamentally different in that there are no maximums specified for speeds. In prior versions, the maximum speeds were limited to what a single 256-QAM channel could support on the downstream and 64-QAM channel on the upstream. This new version allows vendors to develop channel-bonding technology with as many channels as physics and economics will support. Because of this, the basic version will live on much longer.

At the CableNEXT conference last week, Comcast CTO Tony Werner said the initial deployments of DOCSIS 3.0 downstream channel bonding would be combined with DOCSIS 2.0 upstream capabilities. Do you have a sense of whether the cable industry in general has been taking advantage of DOCSIS 2.0’s feature set? Or has its time now just about come?

Although a large percentage of cable networks today are capable of supporting DOCSIS 2.0, most cable operators still have not enabled all the capacities of DOCSIS 2.0. As the need for upstream speeds becomes more important, DOCSIS 2.0 features will be enabled. One thing to keep in mind is that DOCSIS 3.0 builds on the PHY layer of DOCSIS 2.0, so it makes sense to enable DOCSIS 2.0 as a precursor to enabling channel bonding on the upstream.

It looks like you get through your hypothetical 5-year projection without upstream bonding. Is that another way of saying that current DOCSIS technologies have some "legs" and remain relevant going forward?

See my response to the above. So yes, enabling DOCSIS 2.0 upstreams, which most operators can do today, would be very useful in offering increased upstream speeds and allows an easier transition to DOCSIS 3.0.

Your upstream and downstream capacity calculations involve a range of variables, including homes/passed per node, penetration rates, concurrency and speed per user. Could you briefly review the process? Are there any shortcuts?

The key question when it comes to capacity planning usually comes down to how many users can be supported on one downstream or upstream channel. Most of the variables discussed in the article are to get to two variables. So if you can know these, the calculation boils down to one simple equation that yields this answer. The two variables are: (A) the concurrent usage; and (B) the maximum offered speed. The equation then simply is:

Percentage of users = max channel speed / (concurrent user * max offered speed)

For example, on the downstream if we know we want to offer 1 Mbps max speed and the concurrent usage is 1 percent, the answer is:

38 Mpbs / (1% * 1 Mbps) = 3,800 users

Do you have any lessons on effective collaboration between the high-speed data engineering and marketing teams?

The most recent example would be how we launched Powerboost. Engineering understood that this feature could be useful for our customers, but did not know how to market it. The engineering and marketing teams started working together, first by explaining to our marketing how this technically worked. We then had several discussions on how to explain the value of this feature in non-technical terms that the average user could relate to. We brainstormed several ideas that eventually led to a very successful messaging campaign.