Network Programmability – a Step Beyond Pre-provisioning

The “turbo button”  

A few decades ago – long before virtualization, cloud and workloads were even a thing – many telecom operators played with the concept of a “turbo button.” In short, the concept was to allow customers (business and residential) to instantaneously get more capacity (move their connectivity to “turbo” mode) by going into a dedicated website, authenticating, and pressing some kind of “turbo button.”  

There would be an extra fee, of course, but the main value around this idea was to circumvent the cumbersome and labor-intensive provisioning process. The button would serve as a bypass supported by operations support systems / business support systems (OSSs/BSSs) that would allow immediate changes in network and service configuration. 

For the most part, this concept did not really fly as it had several obstacles on its path. Such obstacles included: non-flexible OSSs/BSSs; the need to quickly provision across multiple network layers, domains, and vendors; the physical limitation of the access segment; and the actual reception of such a feature by potential customers. 

The hyperscaler approach to provisioning 

Time passed, and we entered the “cloud era” led by hyperscaler AWS. In this era, the concept of talking to a sales rep in order to get a new service seems a bit archaic. When a customer looks to provision, change, upgrade or reserve compute or storage capacity, they do it online, easily and instantaneously. 

This major change created a significant “cultural” shift for customers of IT and communication services. This level of simplicity and automation is now expected from any provider of digital, cloud, over-the-top (OTT) or telecom services. 

De-bottlenecking the access barrier  

Some of the old barriers that hindered creating such a service environment have since been removed. Notably, the access barrier is much more flexible now. Residential and business access services changed from TDM-based copper infrastructure to IP/Ethernet-based fiber (or high-capacity coax); as a result, physical upgrade or installation is usually not required for providing a timely add-on capacity. Other barriers, on the other hand, remain in place. 

Pre-provisioning and more 

There are, however, workarounds for some of the remaining barriers such as an instant-provisioning process. One of those workarounds is pre-provisioning. Since it is very complex to provision multiple network domains and vendors to accommodate a new service, such provisioning can be done in advance. Pre-provisioning actually creates another service architecture, across the entire network, which is ready to be activated when required. This means customers can “toggle” between a few service profiles that were pre-provisioned in the network. 

But this is, still, very limiting. First, there is limited granularity that can be offered with this method. Second, there’s an overhead one needs to pay in order to pre-provision every possible customer/service combination, even though some of those combinations will never be used. 

The network programmability cookbook 

The way to make pre-provisioning similarly to how cloud providers do it is to move to network programmability. Yet network programmability is easier said than done. 

To enable network programmability, you need to build your network with cloud architecture. And there are a few mandatory steps in order to get there: 

1. Software-centric network: In order to program the network, you need it to be as software-centric as possible. This calls for a move towards a disaggregated architecture, in which hardware is COTS and harmonized, and the main dynamic element in the network is its software. A required step forward from software-centric network architecture is cloud-native, i.e., utilizing container and microservices for maximum flexibility in network and services architecture. 
2. De-siloed network: On top of the network being software-centric and cloud-native, it needs to be converged. Not only in terms of layers (i.e., optical-IP convergence) but also in terms of different services and access methods being served by a unified network architecture. This allows a simpler provisioning process, end to end. 
3. Autonomous-ready network: Heavy automation, including the use of AI tools, makes the network “almost autonomous” and enables minimum manual intervention with the provisioning process. 

By following these steps, after decades of waiting we can finally have a fully functional “turbo button”…