DOCSIS 3.0 Upstream Still Skinny

This week we've been looking at why cable companies are kicking the tires on fiber-based passive optical networks, even though they have a heavy investment in hybrid fiber coax (HFC) networks. Today, we'll look at the DOCSIS architecture and its skinny upstream data path, and how this decreases the longevity of the DOCSIS architecture. 

I'm going to condense a whole lot of history and summarize a lot of detail in only a couple paragraphs, so if I leave out some details you are looking for, please comment on this post and I'll circle back to try to get answers in future posts.

When looking at the DOCSIS architecture as defined by CableLabs, it is important to remember that DOCSIS was rooted in the history of broadcast television networks.  Cable networks were originally designed for one thing: distributed television signals in one direction - from the headend (imagine it as a bunch of electronic gear sitting beside a big satellite dish picking up a bunch of television signals) downstream to your house.  Originally, the main reason to have a return (upstream) path at all was to allow network elements to report errors and anomolies back to a network management system, so not a lot of bandwidth was necessary for the upstream direction. 

Since the cable networks were designed to distribute TV signals, they were designed just like over-the-air broadcast television signals, using radio frequency spectrum in 6 MHz channel sizes.  A typical HFC plant is designed around 870 MHz of radio frequency spectrum, with 800 MHz of the spectrum allocated for downstream TV channels.  The bottom of the spectrum is used for upstream capacity, but a lot of the bottom part of the spectrum is allocated for the DOCSIS operating system, and some of the rest is poor quality spectrum and unusable for data services.  In the end, only about 20 MHz is used for the upstream data channel in a DOCSIS 2.0 deployment.   That amounts to about 80 Mbps of upstream bandwidth to be shared across 250 customers per node, or about 320 Kbps per customer.  If there are 500 customers on your node, then your upstream bandwidth is about 160 Kbps.

That's not a lot of bandwidth in the upstream direction, so you can understand why cable companies are very concerned about applications like BitTorrent that use tons of upstream capacity.  These kinds of peer-to-peer applications work much better when there is a bunch of upstream capacity available.  On an upstream-constrained cable network, peer-to-peer applications have the potential to suck up all of the already-limited upstream capacity. 

DOCSIS 3.0 was supposed to help with this problem by allowing multiple channels to be "bonded", so that bandwidth can be multiplied.  However, in an effort to accelerate DOCSIS 3.0 certification efforts, the cable industry deferred upstream channel bonding certification til 2009, so that they could provide downstream channel bonded services earlier in 2008.  What that means is that in 2008 the top downstream speed may be able to hit 160 Mbps under ideal conditions, but the upstream speeds are still stuck at DOCSIS 2.0 speeds. 

Also, while DOCSIS 3.0 grabs headlines with numbers like 160 Mbps  or 100 Mbps downstream, it is likely that this capacity will be shared across multiple customers, just like today's cable Internet services, so a cable customer may not really be able to buy a service as fast as 160 Mbps downstream. 

So, in 2008 at least, while a Verizon FiOS customer is enjoying a 5 Mbps upstream connection, a cable customer is likely to be stuck with a 360 Kbps upstream connection, even on DOCSIS 3.0.  It won't be til sometime in 2009 that the cable customer really starts to see upstream speeds on par with Verizon FiOS.

As time goes on, even with DOCSIS 3.0, the upstream direction is likely to remain the bottleneck in cable Internet services, and it will remain a serious disadvantage for cable Internet service providers until they finally break the tie with HFC architecture.   

Most analysts agree that someday, cable operators will need to upgrade to passive optical networks on a broad basis.  But when?  That's the subject of tomorrow's post.