No Matter Where You Go, There You Are…
By Jeff Finkelstein
In this issue, I’m going to put my rules of technology musings aside and focus on how we got to where we are today and what some possible future paths for DOCSIS may be. I believe this to be an important step in defining the future of cable architectures for a variety of reasons, which I will touch on in this article.
There is no secret sauce to focusing on future directions; it is frequently a series of imagining alternatives and finding really, really smart folks to bounce ideas off of before sharing them too widely. You will not be right 100% of the time, but even if you are right three times out of 10 consider it a success.
But first, let’s start with a little history…
In the beginning (circa 1997)
“Those who cannot remember the past are condemned to repeat it.” — GEORGE SANTAYANA
In the beginning there was DOCSIS 1.0 and small integrated CMTSs with or without telco return. And it was good, but not great. This was followed by DOCSIS 1.1 (circa 1999) which added the ability to use quality of service (QoS) on individual flows. Next came DOCSIS 2.0 (circa 2001) which added increased upstream capacity with higher order modulations and wider channel bandwidths.
Next was DOCSIS 3.0 (circa 2005), which is where our story begins. Here we added not only more downstream and upstream capacity with channel bonding, but also in the same timeframe, the first piece of what has become known as distributed access architecture (DAA) was created. The teams produced a series of specifications that began being published in 2005 and included the Edge Resource Manager Interface (ERMI), DOCSIS Timing Interface (DTI), Downstream External PHY Interface (DEPI), Downstream Radio Frequency Interface (DRFI), and was followed by the Edge QAM Provisioning and Management Interface (EQAM-PMI) and the Edge QAM Video Stream Interface (EQAM-VSI). Together, these specifications made up what became known as the Modular Headend Architecture (MHA) or more colloquially Modular CMTS (M-CMTS). It was followed in 2015 by MHAv2 which added the remote PHY (RPHY) and Upstream External PHY Interface (UEPI).
It took many years of work by some incredibly smart and hard-working folks to not only get these specifications written, but also to reconcile the differences so that they all would work together as a cohesive unit with products from different vendors interoperating seamlessly. Putting it into perspective, the thousands of pages that were written to create the MHA specifications for this architecture had no significant previous work on which to be based.
Think about the magnitude of that for a moment. Not only did it require the actual technical work to figure things out in the first place, but it also took a room full of people to reach agreement on the key components such that the pieces would work together as a single unit. I have been involved in writing specs since about 1979 at a number of standards bodies including IEEE and IETF, but each one of those specs was typically a single individual unit that did not have to interoperate at this level of detail with others. It was an incredible experience to sit in the room with the contributors and be involved in the discussions and at times, passionate (but professional) arguments. At the end of day there was a sense of camaraderie with many shared meals and even more adult beverages.
At Cox, we made the decision in the midst of the vendors, operators and CableLabs’ staff writing the M-CMTS specs that we would deploy it for a variety of reasons. The primary reason was the separation of the physical layer, which we believed would allow us to scale it independently from the rest of the CMTS core. For us, it turned out to be quite a good decision as we managed to leverage our investments for over 10 years and provide a quality product to our customers.
With our vendors we have managed to grow capacity in our platform using more QAM signals per port in the edge-QAM modulator, additional processing power in the routing and line card blades, faster uplink capabilities, improved outside plant performance by reducing amplifier cascades, newer cable modems and MTAs, and replacing passives and actives with higher performing components. This has taken us from the early days of DOCSIS 1.0 with a single downstream and upstream per service group, to as many as 48 DOCSIS 3.0 downstreams and six upstreams.
John Chapman of Cisco showed the accompanying figure in his presentation at Cable-Tec Expo 2016 titled “Infinite DOCSIS.” If you have not read his paper, I highly recommend it.
These numbers in the figure are astonishing to consider, but when I looked at them closely and did the math it became apparent that they are true.
Though the original developers did not realize it at the time, one of the key features of DOCSIS is its malleability. Through a multitude of technological means some of the brightest minds in our industry have transformed it from a fairly simple access network solution providing capacity for web surfing to a complex ecosystem that is used for the most important communication services our customers require from their broadband providers.
But wait, there’s more…
As DOCSIS transforms into the next next generation of the spec, we will once again get to build upon solid technologies. The transformation from DOCSIS 3.0 and single carrier QAM technology to DOCSIS 3.1 using OFDM was a significant leap in terms of performance. As great as the leap was from DOCSIS 3.0 to DOCSIS 3.1, full duplex (FDX) DOCSIS was an even more radical change to how we provide capacity. Thanks to echo cancellation and other techniques we will be able to transmit AND receive in the same spectrum simultaneously, effectively doubling our potential capacity.
Going forward with “DOCSIS.next” we have a number of options open to us, only limited by Shannon and our imaginations. For example, a few years ago Dr. Tom Cloonan of Arris proposed extended spectrum DOCSIS (ESD) which would increase the available spectrum from 1.2 GHz to 1.8 GHz and beyond. From past testing, we know that the hardline cable is capable of frequencies up to about 10 GHz, but realistically we may be limited to 3 GHz to 6 GHz. Doug Jones of CableLabs had also proposed an extended reach passive coax (ERPC) idea that by a slight increase in amplifier output we may be able to extend the distance reach of signals.
If we limit ESD to be used for express trunks feeding capacity to remote distributed access devices, we may be able to avoid being forced to pull fiber to those remote devices for quite a long time, assuming that the compound annual growth rate (CAGR) continues its slowing from 49% to 35% or so. The CAGR itself is an intriguing discussion to have with those spending their time analyzing it at CableLabs. Their quarterly report on data growth is fascinating and well worth the time to read.
Another possibility would be to use a different waveform for the 1.2 GHz to 3 GHz band. OFDM has spawned some new ideas in the research community including filter-bank multi carrier (FBMC), universal filtered multi carrier (UFMC), generalized frequency division multiplexing (GFDM), non-orthogonal multiple access (NOMA) and filtered OFDM (f-OFDM). Each of these waveforms offers benefits over pure OFDM and since they would only be used in the “express trunk” region, we would not need to replace customer premises equipment.
While we do not at this time specifically know what “DOCSIS.next” will include, it is very likely that since each prior version of DOCSIS is an order of magnitude more complex than the previous, the next version will continue that trend. The accompanying graphic gives it some context in terms of relative magnitude of complexity for each DOCSIS version. Note that the levels of complexity are my opinion and only relative to the previous version of DOCSIS.
Simply put, DOCSIS 3.1 FDX is 100,000 times more complex than DOCSIS 1.0, DOCSIS.next we can expect to be 1,000,000 times more complex than DOCSIS 1.0. As I said, the relative levels are based on my opinion from having deployed DOCSIS 1.0 to DOCSIS 3.0, with additional input from our engineering and operations teams for DOCSIS 3.1. Beyond that is pure extrapolation based on lessons learned.
Stay tuned to CableLabs and SCTE·ISBE’s Cable-Tec Expo for more information on exciting new potentials for DOCSIS…
Historically, our focus on the access network was around providing more and more capacity. The capacity oriented access network (COAN) was all about how much total bandwidth we could provide to enable the future speeds and feeds needed for residential and business customers. DOCSIS 1.1 did take a slight divergence with PacketCable MultiMedia (PCMM) for QoS, but in general our improvements to DOCSIS have been related to the size of the total pipe.
As our networks have changed from dial-up to fixed wireless, and our customers’ needs have changed from web surfing to social media and video, we must evolve our networks once again. It is not enough to just provide capacity, we need to understand how our customers use the network and what they use it for to provide the services that are most important to them.
I believe the next major network transformation will be to create the service oriented access network architecture (SOANA). In this network we understand what services customers want to use and dynamically adapt it to meet the application needs. We will create the ability for customers to decide how their “pipe” is used with a differentiated service model, then find ways for that information to flow through the Internet such that it is maintained in a trusted and secure transmission.
Now, the concept of a SOANA is hardly new. You may have seen it referred to as service oriented architecture (SOA) or service oriented network architecture (SONA). The idea is that we have the technologies now to extend it not only through the core and metro networks, but to take it through the access network into the customer premises.
An example of technologies that can be used include RESTful interfaces, RabbitMQ, SOAP and Thrift. There are many others, but what they have in common is the capability to enable services that are autonomous, stateless and use open interfaces.
I plan in future articles to spend more time on the concept of transforming the access network from capacity to service based. Until then, keep watching this space for more musings on the incredible, ever-changing DOCSIS protocol…
Jeff Finkelstein
Executive Director of Advanced Technology
Cox Communications
Jeff Finkelstein is the Executive Director of Advanced Technology at Cox Communications in Atlanta, Georgia. He has been a key contributor to the engineering organization at Cox since 2002, and led the team responsible for the deployment of DOCSIS® technologies, from DOCSIS 1.0 to DOCSIS 3.0. He was the initial innovator of advanced technologies including Proactive Network Maintenance, Active Queue Management and DOCSIS 3.1. His current responsibilities include defining the future cable network vision and teaching innovation at Cox.
Jeff has over 43 patents issued or pending. His hobbies include Irish Traditional Music and stand-up comedy.
Shutterstock, Cartoonstock
