Yoga for DOCSIS

By Jeff Finkelstein

“What is malleable is always superior to that which is immovable. This is the principle of controlling things by going along with them, of mastery through adaptation.”— LAO TZU

At the end of my last column I touched on the concept of how our networks are going through a radical transformation. Since the beginning of Internet services over cable we have considered the network as a capacity-based network. It was all about speed and the amount of bandwidth needed to provide those speeds. To which end, we collect statistics on usage and consumption, model the network constantly, and change the nerd knobs of our models to see what drops out at the end of the run.

It’s All About Perspectives     

Set the Wayback machine to the early 2000s, where increasing the top speed tier by 1 Mbps was considered a massive undertaking. When a product manager had a requirement for a speed increase it triggered weeks to months of analysis, planning, budgeting, engineering and execution exercises. And many, many sleepless nights for everyone as we agonized over how it would impact our networks.

Fast forward to today where we have speeds over coax of up to 1 Gbps. The idea of getting into a speed competition with 1 Gbps versus 1.01 Gbps does not even cross most of our minds. At 1 Gbps and beyond, speed increases for most customers are of little value. The applications of today and the future are not all about speed. They are about services, latency and bandwidth. It is this transformation that is shaping the next 20 years of cable network technology and designs.

Now is the time to set the stage for how our networks must morph to prepare them for the network of the future. Leading people to an uncertain future is not easy. It’s frequently frustrating. For those who have been placed in thought leadership roles, you feel the shared pain of all of us.

However, it is our responsibility to lead the way. I like to do it by telling compelling stories, others do it with statistics, some by building prototypes. In the end, I sum it up as follows:

Our role as transformative leaders is to share a transcendent purpose, pointing the way to a new reality.

Cable plant data consumption has historically run at a 49% compound annual growth rate (CAGR). The latest trends from CableLabs analysis have shown that this has been slowing significantly.  Digging into the hows and whys of this decrease in CAGR is a topic worthy of a column by itself, but it is orthogonal to my point in this article. In this article I want to focus on the tactical steps for the next transformation of the DOCSIS network and why it is the new direction for cable evolution.

Historically, every 12-24 months we are upgrading the capacity available on our outside plants by doing one or more of the following:

 

1. Using higher order modulations (when I started in cable it was 64-QAM downstream and QPSK upstream compared to 4096-QAM downstream and 1024-QAM upstream possible today with DOCSIS 3.1)

 

2. Adding more channels for data services (we went from one downstream and one upstream in 1996 to 32 downstreams and eight upstreams in DOCSIS 3.0, to 192 MHz OFDM blocks downstream and 96 MHz OFDMA blocks in DOCSIS 3.1)
3. Soft splits done by de-combining fiber nodes in the headend to reduce service group sizes (In the early days of cable Internet service group sizes were in the 2,000 to 4,000 HHP range)
4. As a last resort performing hard fiber node splits by pulling fiber deeper into the network and adding more fiber nodes to reduce amplifier cascades and service group sizes (I remember nodes that at one point were a fiber node plus up to 30 actives, where today a fiber node plus five actives is considered large)
   With the availability of distributed access architecture (DAA) technologies (e.g., remote PHY and remote MAC/PHY), this is changing again by adding a fifth step:
5. Pull fiber deeper and replace legacy fiber nodes with DAA devices, which simultaneously improves performance by moving from analog to digital optics, reduces amplifier cascades and service group sizes, plus adds more capacity by moving the top end of the usable spectrum up to 1.2 GHz

Steps 1-4 are our legacy techniques for increasing bandwidth and capacity. Step 5 is new, and many operators are taking the leap into fiber deep architectures as a way to move our networks into the all-digital future. Of all the non-regrettable investments we can make in our outside plant architectures, more fiber is king and spectrum is queen.

Yoga Is About Flexibility

Distributed access architectures have made a profound impact on how we design our future networks. The improvements of digital optical links over analog, along with reduced amplifier cascades and smaller service groups, give us a dramatic increase in performance. There is much discussion around what this means to the headend and converged interconnect network (CIN) design. As we learned with node splits, the amount of MAC processing must increase as we increase the number of service groups by reducing service group sizes.

In a traditional I-CMTS model this means we add new chassis to handle the new service groups. With M-CMTS we added more edge-QAM and MAC processing in the I-CMTS to feed the new service groups. With DAA we need more MAC processing as well, where this is done using I-CCAP as MAC processors.

As part of a new CableLabs working group, we are developing a spec that covers ways of providing the MAC processing needed for DAA. This working group is creating something we call the flexible MAC architecture (FMA), a term coined by Liberty Global. Briefly, FMA describes in standard normative language how the upper network layers talk to the MAC.  The MAC to PHY interface has already been defined as part of the R-PHY specification.

The primary goal of the FMA working group is to define a standards-based flexible architecture that allows vendors and operators to place the MAC where it makes most sense for their network.

Let me use a real-world example to explain. Many of us are going to begin our DAA deployments using a remote PHY deployment model. We are going to do one or more of the following:

1. Replace existing analog fiber nodes with a remote PHY node, replacing the analog optoelectronics with digital to get better SNR (RxMER) performance
2. Rebuild the plant from N+X (possibly to N+1), replacing the existing fiber node and adding new nodes that are remote PHY
3. Pull enough fiber to convert our N+X to N+0 (passive coax)

Option 1 allows us to reuse our existing I-CCAP. Options 2 and 3 requires more MAC processing. With the FMA, we have a number of options available to us:

1. Add more I-CCAP chassis to handle the new MAC processing requirements
2. Use R-MAC/PHY, placing the MAC processing in the remote MAC device (RMD)
3. Use RPDs for the physical layer and add a remote MAC core (RMC) to place the MAC processing in the field closer to the RPD
4. Use a virtual MAC virtual machine or container to do the MAC processing in the cloud or possibly in a COTS X86 servers in the headend or even in the OSP

While this is not rocket surgery, it is a complex change from how we have traditionally done things. A picture is worth a thousand words, but an interface is worth a thousand pictures…

While it looks like a lot of boxes and lines, it is conceptually fairly simple. Starting on the left, the blue box is what we use today encompassing provisioning, DHCP, IPDR, TOD, monitoring, etc.

Moving to the right, the MAC manager is new software that takes the upper network requests and translates them to a management plane protocol for configuring the MAC using YANG models, the SDN controller sets up the flows for traversing the network using something like OpenFlow, the DOCSIS controller manages the DOCSIS control plane interfaces using YANG models, and the policy controller provides the PCMM interfaces. The grey boxes are legacy video and timing subsystems.

The right contains the new physical network functions (PNF) and virtual network functions (VNF), plus describes how they interface into the new architecture. Starting from the top, the RMD has previously been covered in a CableLabs technical report (see CM-TR-R-MACPHY-W04), but the new additions are the interfaces for the control and management plane as described in the paragraph above. The RMC moves the MAC functions out of the RMD and places them in a standalone unit, e.g., in a clamshell (fiber node like housing), while using RPDs for the physical layer. The pCore is a physical device (e.g., legacy I-CCAP chassis) that handles the MAC processing. A vCore is a virtual MAC core that can run in COTS X86 or possibly in a field deployable X86 processor running in a clamshell.

What we in the working group are looking to do is define how these pieces fit together. Where standards exist, e.g., DEPI, UEPI, GCP, DTI, we use them. Where they don’t exist, e.g., YANG models for MAC management and DOCSIS control plane messaging, we create them. Together, they create a flexible MAC architecture, which allows operators and vendors to place the MAC and PHY processing in the most efficient manner based on our current and future network designs.

SOS (Shiny Object Syndrome) Redux

You may be saying to yourself, “Not another spec!” If you are thinking that, I don’t blame you. We are still writing engineering change requests to recent specs (RPD, DOCSIS 3.1 and DOCSIS 3.1 full duplex), while writing new specs for low latency DOCSIS and mobile backhaul. Yet, here we are starting another spec effort to define a new distributed access architecture. Not just another spec effort, but one that will impact every layer of the access network.

Every once in a while, a new technology, an old problem, and a big idea turn into an innovation.—DEAN KAMEN

This does not mean we abandon those technologies that are currently being deployed. FMA is designed to build on them and wrap them in new models which allow our network to morph into the technology of the future. It is being designed such that we can leverage our current and near-term RPD or RMD deployments.

Writing specs takes time and much effort. Anyone who has been involved in writing CableLabs or other specs knows this too well. But as with every previous spec, we need to continue our current deployments until such time that the next generation of technologies is ready.

What we are doing in the FMA working group is define the future technologies such that they leverage the previous generations. Those of us in the WG believe that by using DOCSIS 3.1, DOCSIS 3.1 full duplex and FMA, we can continue the impressive growth potential for DOCSIS for another 20-30 years.

I am amazed at how the flexible, yoga-like abilities of DOCSIS allow us to continuously improve it with incremental evolutionary changes that leverage past efforts. Thanks to the continuing work by CableLabs, vendors and operators, the useful life of the cable plant still has a long, long way to go.

---

Jeff Finkelstein
Executive Director of Advanced Technology
Cox Communications

Jeff.Finkelstein@cox.com

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.

---

Vincent van Gogh, Oil on Canvas. Arles, France: August, 1888.

 Image provided by author, Public Domain

 Chart provided by author

 DILBERT © 2012 Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.