What’s “Evolved” About An “Evolved CCAP”?

By Todd McCrum, Director of Product Management, Cable Access Business Unit, Cisco

If you’re making the rounds at this week’s INTX, you’ve likely gotten wind of our flagship product announcement — the Gig-maker that is the cBR-8, as part of Cisco’s Evolved CCAP solution. Our categorization of it as an “Evolved CCAP” solution may need further defining. The answer requires a bit of background, starting with CCAP itself. It stands for “Converged Cable Access Platform,” where the “converged” part refers to a one-size-fits-all QAM modulation system that works for video, voice and data. Prior to CCAP, modulation was handled individually for video and data/voice products — I still remember the cable system GM who lamented that “every time I turn around, somebody’s sending me a request to buy more QAMs.” CCAP alleviates that concern.

What’s evolved about an evolved CCAP, and in particular, the cBR-8, can be characterized in three ways. First, the original CCAP spec (started about five years ago) covered a total of 64 6-MHz channels. They’re typically divvied up half and half: 32 channels for DOCSIS 3.0/broadband traffic, and 32 for MPEG-delivered, narrowcast video, like VOD. (Note: Not live or linear.) Subsequently, the DOCSIS specification itself evolved to 3.1, which substantially increases available bandwidth for IP-based services. As a result, and in our view, CCAP needed to develop in lockstep.

Evolved CCAP enables 100% convergence of all video types — narrowcast/VOD, sure, but also linear/MPEG, and any managed IP video tiers that might be entering the service mix. Plus enough room for both DOCSIS 3.0 and 3.1-based traffic. The reason I feel confident in saying that the cBR-8 is ahead of the marketplace on this one is that our competitors tend to use an off-the-shelf chassis, which puts a hard architectural limit on how many total serving area groups they can reach. Trying to wring more bandwidth, or reach more serving areas, becomes expensive with forklifts in that scenario.

Which brings me to the second characteristic of an evolved CCAP: The ability to distribute it. The cBR-8 was built from the ground up to support a distributed CCAP architecture, which involves taking the physical QAM modules, and putting them into a node, or an equipment shelf, out in the network. That matters for two reasons. One, removing the PHY modules makes for a pure IP output. That immediately expands IP capacity, and can double the number of serving groups that can be reached. Two: Let’s look one generation out. Once you move the PHY parts out into the network, what’s left in a CCAP core is the data plane, and the control plane. At that point, it becomes entirely plausible to move those components into a data center. In other words, and to use a very-vogue tech term, it virtualizes the CMTS.

The third characteristic of an evolved CCAP like the cBR-8 is the orchestration layer. Specifically, the cBR-8 includes a northbound API interface to an orchestration layer, which can “see” and maneuver across any existing infrastructure. Even if it’s not ours. What? A blended equipment base is the norm for service providers. Which means that any changes, like wanting to add a new feature, would necessarily have to be written, tested, and launched many times over, in order to run on every fielded CMTS or CCAP.

So that’s my dissertation on what’s evolved about Evolved CCAP. Short version, it’s a real game changer, with a solid future focus. Bonus: In market and available now. Come see for yourself — we’re at INTX booth #523.