Implementing Autonomous Networks: Three Approaches

There are three main approaches for implementing autonomous network operations driven individually by the automation tool vendors, the network element vendors, and the all-in-one OSS vendors. It is probable that the optimal path for a CSP will involve all three of these, depending on a CSP’s specific needs, desired approach, and automation maturity in the various network domains.

Implementing Autonomous Network (AN) operations is not an easy task. As an industry, we have been automating network operations for almost half a century and are only a small fraction along the way. But CSPs and vendors have been getting more serious about it, willing to invest more money and time as the complexity of the network technology and services have increased (and will increase even faster), and the need to automate operations has become an existential issue.

Observations

I have been talking to telecom vendors and CSPs before and at #MWC22 about how they are moving or plan to move their network operations from their current level of automation (usually between 2 and 3 on the 5-step scale as defined by the TM Forum) toward full autonomy. I have found that there are three main approaches in play:

1. Top-Down Tool Driven, espoused mostly by automation tool vendors
2. Bottom-Up Network Driven, pushed by network element vendors
3. OSS Refresh, recommended by all-in-one OSS vendors

Let’s take a look at each of these, then I’ll speculate on what the optimal mix may be.

Top-Down Tool Driven

Automation tool vendors such as FRINX, HPE, Itential, Sedona (now a part of Cisco), Etiya, Red Hat, and ServiceNow see a set of OSS capabilities that need to be driven by robotic process automation (RPA), workflow systems, and AI-driven analytics, adding them onto the existing operations infrastructure and replacing the human technicians who now interact with the OSSs. They would add these onto the existing EMSs, NMSs, domain controllers, cross-domain orchestrators (if implemented yet), and OSS systems to automate the operations.

Bottom-Up Network Driven

Network element vendors such as Affirmed, Cisco, Huawei (iMaster), Infinera, Juniper, and Ribbon have found that most CSPs want them to provide a domain control system (roughly a next-generation EMS/NMS that provides SDN control and advanced telemetry) optimized for their equipment that is also capable of controlling other vendors’ equipment reasonably well within a network domain where that manufacturer is dominant. These vendors are adding analytics and automation features to their SDN control capabilities to provide as much network operations autonomy as possible.[1] Some of these vendors, most notably Huawei and Juniper (soon to be joined by Sedona as a per of Cisco), also provide cross-domain orchestration for provisioning as well as network and service assurance.

OSS Refresh

Vendors who have all-in-one OSS suites, such as Amdocs (Amdocs Network Service Automation), NEC/Netcracker (Netcracker Digital Platform), and Juniper (Paragon), call for replacing parts or all the OSS infrastructure with their multipurpose offerings. In all cases, these are decomposable suites[2] with the full set of provisioning, assurance, inventory, and design (P-A-I-D) functionality for overall network operations, including slicing.

Speculation

I have seen good examples of implementations of Level 2 and 3 operations autonomy implemented via all three of these approaches. The approach optimal for a particular CSP will probably vary greatly by how sophisticated and up to date a CSP’s current operations are and how much the CSP wants to take part in creating and optimizing the autonomous operations workflows.  The optimal approach will probably vary considerably by CSP, technology domains, and perhaps organizational domains.

NEXT

I will be testing and refining this model with CSPs and vendors and intend to investigate the pros and cons of these approaches for the various domains.

For more information, contact Mark at mmortensen@acgcc.com.