Cable DAA Network Readiness

Overcoming cable challenges

Distributed Access Architecture (DAA) is poised to transform the cable industry’s access infrastructure. The technology is well tested in the lab, but far from widely deployed. A DAA operational model that aligns with market drivers, builds cross-functional competencies, and uses proven automation and orchestration tools can overcome scaling challenges and drive efficiencies. By implementing this model and following our tips for transitioning into automation, IT and network leaders can realize the same massive reduction in manual tasks seen in our case study, accelerate DAA deployments, and generate greater business value.

Moving to a Distributed Access Architecture

The move to a Distributed Access Architecture (DAA) has been slow to get off the ground. CableLabs released Remote PHY specifications in 2015 under the Distributed Converged Cable Access Platform (CCAP) Architecture (DCA) rubric. It advances some of the original CCAP goals to reduce space and power requirements and to boost network capacity. But the industry consortium has also been considering other approaches to DAA, such as Remote MACPHY, now known as the Flexible MAC Architecture (FMA). Some operators are waiting for those specifications to mature.

Another reason for the slow roll out of DAA is that similar to the related Modular Headend Architecture (MHA) released back in 2005, the new architecture calls for a Converged Interconnect Network (CIN). Today, that means replacing analog with digital optics to connect CCAP cores with Remote PHY Devices (RPDs) and other elements of the distributed network. Managing this analog-to-digital optical migration requires a separate amount of planning, investment, and time.

Operational challenges are also associated with DAA. Operators who have deployed RPDs have learned a simple truth: staging, activating, and upgrading line cards or a CCAP device can be more complicated when the PHY is located in a node than when it’s contained within the core. This complexity arises from moving multiple components to a remote location. The focus of this paper is on addressing the operational transformation, in particular, the automation that can make your network operationally ready for large-scale DAA deployments involving RPDs.

DAA operational challenges

Operators who have trialed Remote PHY have seen that it works in the lab. However, to succeed in the field, it will need more coordination and integration, including:

• Flexible and scalable tools to automate deployment and operations. Manual processes will be unable to handle a 10-fold increase in the number of nodes, with commensurate impacts on CIN devices, CCAP cores, and service groups.
• Cross-organizational collaboration. DAA impacts more than the DOCSIS team typically associated with cable modem termination system (CMTS) and CCAP technologies. Effective automation tools should foster a unified approach and bridge departments – from engineering to IT to back-office.
• Network visibility and monitoring. Managing the CCAP core, CIN devices, and a large population of RPDs calls for new tools that can help operators visualize and track the new subscriber and network service topology.

These three interrelated requirements depend upon automation tools that can reduce both the number of manual steps and the amount of time associated with DAA operations. Yet for the cable industry, with one notable exception, automation is more often talked about than deployed. It’s often seen as something happening elsewhere.

DAA automation drivers

Cable operators have already begun automating some processes in the high-margin and fast-growing business services market, although not as many as leading telcos that still dominate that market. DAA, however, is well-suited to the application of automation because it’s driven by several broad-based technology categories, including:

Networking software. DAA is essentially a programmable and API-driven network architecture. It’s removed from more rigidly engineered solutions and is similar to the shift away from fixed circuits and toward technologies such as SD-WAN. For a programmable network, a software-based automation engine is a logical next step.

Cloud computing. DAA also aligns with cloud computing, in which case functions can be virtualized and distributed, but also allocated into common pools. This framework also aligns with multi-access edge computing (MEC), which brings low-latency processing closer to the customer. Automation is fundamental to the fast-paced and hands-off model of the cloud.

Modularity. DAA is a modular technology. Instead of requiring an entire process and infrastructure for automating a single service, DAA enables automation that can be repeatable and adaptable for a vast permutation of needs, services, and processes. It makes sense to move away from locked-in use cases.

Automation and orchestration: framework

A conceptual framework for DAA automation and orchestration reflects its modularity across several strata (see Figure 1). On the lower half are domains and service platforms. Each domain controller could come with its own suite of tools for configuration, monitoring, and service assurance. The information passed between domain controllers and service-level platforms is driven by intent-level APIs. The data can be interpreted and acted upon. Domain-level data are more detailed and specific. At the service level, they are more abstract and summarized.

The operations catalog at the top represents workflows associated with services across multiple domains. The scope is concerned with not only configuration, but also upgrades, offloads, pre-checks, post-checks, and more. An intent can be declared at the GUI level, which is linked to pre-existing BSS/OSS, and the workflow renders it into an actual service.

The cross-domain orchestration platform or workflow engine in the middle brings the multiple domains, functions, and workflows together in unison. It contrasts with today’s inefficient and lengthy processes. Associated with activating, configuring, validating, and networking many devices across wide areas, it needs to understand and interpret multi-vendor environments with their own complex device interactions and processes.

Well-defined domain APIs are key to automation, and one way to view orchestration workflows is as state machines that drive API calls. (Note the API Gateway, which is depicted in a vertical column.) These workflows can be co-developed between the development and operation teams.

Figure 1. Cable DAA automation and orchestration framework

Automation and orchestration: solution

Cisco addresses the DAA operational challenge by enabling cross-domain DAA orchestration through a Business Process Automation (BPA) solution that is based on Camunda, which is an advanced, open-source workflow and decision automation engine. Other building blocks are Smart PHY, which automates the provisioning and onboarding of RPDs and Network Service Orchestrator (NSO), the controller that automates the model-driven management of network devices (see Figure 2).

These tools play separate but interdependent roles. BPA is focused on workflow management and cross-domain orchestration. NSO enables the control of devices across domains, which enables operators to automatically and quickly provision new services and alter network configurations across multi-vendor environments. Smart PHY provisions RPDs and redirects them to register on the appropriate CCAP core.

In addition to being committed to open source and multi-domain orchestration, the broader automation solution is committed to the tenets of flexibility and agility. The ability to reuse, extend, build-your-own, and or co-develop additional solutions based on a defined architectural framework (containers, APIs first, microservices, and common integration), changes the economics of service deployments and device lifecycle management. The initial DAA automation solution offers the following functionality:

• Automated RPD onboarding and activation. Onboard RPDs using GUI or a REST API call from a third-party application.
• Automated CIN onboarding and activation. Onboard existing CIN devices or using zero-touch provisioning (ZTP).
• Automated CCAP onboarding and activation. Onboard new CBR-8 and configure for day 0/1.
• OS upgrade. Upgrade CIN devices or cBR-8.
• Device configuration changes. Deploy configuration changes across devices with pre-check and post-check capabilities.

Figure 2. DAA automation deployment architecture

Case study: 90-percent reduction in manual steps

A large North American operator, as part of their network transformation initiative around DAA, foresaw the need for automation and redesigning business processes to achieve their business and operational goals. The following requirements were behind their need for automation:

• Roll out new network device types.
• Collaborate between orgs to achieve an E2E process.
• Simplify operations across the board.
• Scale up 10X over the next five years.
• Standardize across geographical regions.
• Accommodate multi-vendor networks.
• Remove swivel-chair and inaccurate data systems.

Cisco provided automation and DAA subject matter experts to guide and create the automation vision, strategy, and execution plan for 12 months and beyond. As part of its advisory services, Cisco experts worked with an internal cross-functional team to build a target operating model for requirements, design, team interlock, and system integration design. Cisco matched its automation platform with use cases for device lifecycle management, embraced a co-development framework, and supported the customer’s need to extend and build their own applications. For fast deployment of use cases, Cisco employed DevOps and agile delivery methodology.

The solution has automated use cases across the full DAA footprint, including:

• CCAP core, CIN, RPD turn-up for new or existing devices.
• OS upgrade for devices.
• Golden config generation and compliance.
• Pre-checks and post-checks for device health monitoring.

The solution has reduced manual effort by more than 90 percent in the use cases, while reducing the time factor by 85 percent. In the particular case of an OS upgrade, the number of manual steps were reduced from 57 to 4, and even those steps could have been further collapsed (see Figure 3). Other benefits have included increases in standardization and network rollout speed and declines in operator errors, cost-per-network change, and network outages. Additional overall benefits include enriching inventory with real-time network data and integration with multiple platforms, such as inventory and ticketing.

Figure 3. Device upgrade reduced from 57 steps to 4

How to transition to automation

If you’re ready to try automating DAA, given the huge scope of work involved and a general lack of familiarity with automation systems, a sound transition strategy is crucial. Careful definition of workflows is another part of an effective transition.

After assembling an in-house team of stakeholders, the first step in a transition is to choose a good use case, which ideally is an optimal and repeatable process. Then, define the process using your existing tools, such as text documents, spreadsheets, and flowcharts. Capture the process in a high-level BPA workflow, where everything is working the way it’s intended. Note that not every step needs to be automated. You can leave some manual activities in the flow chart.

When moving into operations, identify your APIs. Replace manual steps with API calls. However, to build trust, make sure that the output can be reviewed and approved before the automation suite moves forward. Building a high level of trust in your underlying automation suite is important for establishing a firm foundation. To add robustness, work in sub-flows where some part of the workflow is blocked or broken. A good automation system works well because it has conditions for remediating breaks and blockages.

To keep your workflows healthy, identify key modules and resources that can be shared. Some pre-checks and post-checks can be the same across different types of workflows. Be mindful of their duration. If a workflow runs for too long, processes and conditions in the state of the system could change while the workflow is executing. Dependencies also may need to be completed in sequence and coordinated across systems.

Finally, always have a good audit in place. And keep in mind that the workflow is only as good as the process it automates. Inspect the workflow executions and identify critical points of failure and bottlenecks to get a real data-driven picture of operational pain points. Continue to improve processes, and then apply them to your workflow.

Business value

The global and long-term opportunity for automating manual tasks and orchestrating cross-domain services is tremendous. Service providers that are beginning their automation journeys are looking at this move as transformational. Our estimates are that up to 70 percent of existing operations can be automated, which can lead to a vastly reduced number of manual tasks, improved time to complete network configurations, improved time to onboard customers, and reduced downtimes and errors.

The results to date are clear. At an aggregate level, we have seen software-based automation across mobile, cable, telco, and data center service providers deliver an average 50-60 percent improvement in operating expenses (OpEx), with the impact felt in reduced costs for change requests, new adds, disconnects, incidents, and maintenance operation protocol (MOP) as shown in Figure 4.

Based on data from case studies conducted by Cisco across multiple service providers, automation improved operations efficiency in terms of hours by 71 percent. Reduced OpEx was most pronounced in the categories of configuration validation, service provisioning, and network configuration. These areas are some of the same ones that are applicable to DAA.

The results from the case study in the cable industry discussed earlier, in which automation drove even higher reductions in DAA-related manual tasks and time, are auspicious. It’s important to note, however, that the benefits of automation are not found in silos and proprietary or single-vendor solutions. For automation to be effective, it needs to be able to handle multi-vendor environments, adapt to evolving software requirements, and coordinate activity in all directions, even across departmental divides.

The Cisco advantage clear. We have expertise in DOCSIS, CMTS, CCAP, and DAA itself and the automation toolkits, controllers, and advisory services needed to enable workflow management across a multi-vendor network of RPDs and other DAA devices. The distributed architecture delivers its own benefits and is key to other industry initiatives, such as full-duplex DOCSIS, but deploying and operating DAA at scale is impossible with existing operational models.

Figure 4. Impact of automation on service provider OpEx