Autonomous Networks and the CSPs’ Ecosystem

My recent report Digital ecosystems: setting new standards for integration describes the standards work being carried out by TM Forum and MEF for ordering end-to-end broadband services. These services often transcend the service boundaries of different communications service providers (CSPs), meaning that services need to be provided by multiple operators.

The standard APIs developed by TM Forum and MEF are applicable to:

  • Enterprise to CSP services and between CSPs
  • Multiple services: IP, carrier Ethernet, SD-WAN/secure access service edge (SASE), and Layer 1 optical services
  • Researching, ordering, and managing the services

These APIs support a robust ecosystem to exchange services in which they provide automated interactions between the different parties, without the need for human involvement. But to meet the stated goal “to reduce ordering and provisioning intervals from the current 30 to 90 days to just 30 to 90 seconds” requires much more than intercompany interfaces. It requires automation of many processes inside the CSP, including CRM, ordering, provisioning, billing and ongoing operations. In the rest of this blog, we focus on the network part of this required functionality.

Autonomous networks will power the digital ecosystem

The automated network operations processes described above are being built into autonomous networksbeing deployed by some CSPs. Fully autonomous networks immediately configure themselves upon receipt of a new or changed request for a service as well as fix (and optimize) themselves immediately if an abnormal condition occurs, without human intervention. In doing so they provide zero-touch, zero-trouble, and zero-wait operations.

Current APIs rely on templates of services or slices (with some parameters) in what is usually called network-as-a-service (NaaS). Here, the customer uses an API that specifies all the ordering information, to a great level of detail. These specification methods use, for example, a standard 5G slice template that specifies the service characteristics desired and the values of those parameters.

Using these templates requires that the customer understands the technical details of the template and how they will be applied. To attack that problem, some CSPs are providing simplified templates offering, for instance, three different types of communications packages to gaming companies, depending upon the quality and latency desired.

The next step in the evolution will attempt to bring simplicity, but with greater flexibility in the services offered, intent-based interfaces.

Intent-based interfaces will be the future

To optimize the use of these automated capabilities and support the NaaS business model will require that the machine-powered API interface to users becomes more like an automated version of the current human-powered interface to enterprise customers. Here the customer describes to the CSP (usually a salesperson, supported by an engineering person) what it needs to accomplish, speaking in their business terms. Then the sales and engineering team do their best to turn that “intent” into a detailed network design that is iterated with the customer until agreement is reached.

Currently, these designs can take several weeks to produce. And there can be several potential problems:

  • The design often does not quite match the requirements, due to inaccuracies in understanding them and in translating them into a detailed design.
  • The customer requirements often change during the extended time period.
  • The customer has a tendency to put in the same request to several CSPs simultaneously, then keep only the order that is delivered first.

With intent-based interfaces, the customer uses an intent-based language that specifies requirements but does not get involved in the detailed design of the network service. Thus, intent-based interfaces require the automation of the design process.

Automating the design process will provide customers with their desired services immediately, obviating the problems described above. Such automated interfaces that support design functions are called intent-based interfaces, as detailed in our report Intent in autonomous networks.

It will be a journey

All these elements are evolving together and will likely take the best part of a decade to become ubiquitous. Current work to move networks to autonomous operations and provide automated, high-level interfaces amongst communications ecosystem partners is evolving and moving forward quickly. As it evolves, it will become the automated communications piece of a much larger ecosystem that will include communications, computing and storage, application platforms, for such things as IoT, blockchain, and quantum encryption systems, and industry-specific applications. These together will provide digital enablement platforms for enterprises in a wide range of industries.

Contact Mark Mortensen at for more information.

Similar Blogs: