Why Network-as-a-Service is still at the starting line

Open APIs are ready for the NaaS race to market. Telcos, not so much. We unpack what’s holding them back—and the moves they can make to get competitive.

In the last year, standards bodies have released dozens of open application programming interfaces (APIs) for networks. This is great news for businesses looking to cut costs and developers who can now take advantage of 5G network access and cloud-based edge computing for delivering unique applications.

But what about telecommunications companies? Open APIs were supposed to clear the way, finally, for the long-awaited boom in Network-as-a-Service (NaaS).

Coming up with this strategy, for many telcos, will be the hardest part of network monetization—but it’s time to get moving. With the proliferation of open APIs, telcos now have everything they need to leverage NaaS as a revenue generator.

The key is choosing vertical target markets, mapping out the on-demand connectivity services they’ll offer—and getting competitive.

Behind the bumper crop of open APIs

The buzz around open APIs is well-founded. The interfaces are changing the game for businesses in every industry, and they’re a key factor in the NaaS model’s advance, capping years of investment by telcos to migrate to the cloud and to optimize costs.

Given open APIs’ importance, it’s no wonder standards bodies have worked overtime to develop an array of the network interfaces, many of which are just starting to hit the market. The industry trade group TMForum, for instance, has more than 70 open APIs, most of which focus on the service management of NaaS offerings. The organization is now starting to release NaaS APIs to deliver network capabilities for use in IoT applications or devices. (Full disclosure: I’m one of the leads in the digital ecosystem workgroup for TMForum.)

Other efforts underway include Camara, the open-source project under the guidance of GSMA and the Linux Foundation that’s working to deliver network exposure through NaaS and NWDAF at the network layer. MEF, a non-profit industry forum of network, cloud, and technology providers, is releasing standards that expose Ethernet and SDWAN-type APIs for NaaS.

Why most telcos aren’t yet ready for NaaS

But the reality is that many telcos aren’t yet ready to market and monetize open APIs. Like businesses in most sectors, they’re tackling an array of strategic priorities, and NaaS efforts remain works in progress as telcos struggle to settle on the enterprise vertical markets in which they’ll offer on-demand B2B2X connectivity.

It’s a new and unfamiliar way to sell services, and it requires CSPs to think about exposing their networks in more creative, strategic ways.

What is not in doubt is that the pivot to NaaS offers enormous opportunity—and the market is wide open. A few examples of where NaaS might apply:

• The EMS transporting a patient by ambulance wants to connect to the hospital to address critical care and share data over AR/VR. It needs connectivity with a large amount of bandwidth for a short period.
  
  
• While televising a Sunday ball game from a stadium, a broadcaster requires a connectivity bandwidth boost for the game’s duration to deliver an immersive fan experience.
  
  
• A construction company needs on-demand connectivity to utilize equipment from a remote location to meet safety protocols.
  
  
•  When responding to a disaster, police, fire, and EMTs require multiple NaaS connections from multiple CSPs at varying levels of bandwidth and latency to quickly communicate and gather data.
  

Refine key performance indicators

But buyers for the new services won’t just appear out of thin air. Connecting with B2B2X customers will need solutions with a strategic product market fit. For telcos, that means refining how operators will deliver services and the key performance indicators (KPIs) they’ll enable enterprises to manage.

Self-service remains a big part of NaaS’s value proposition, and mapping the KPIs to customers’ needs is the kind of strategic, tailored service offering that’s new to telcos. The menu of services might include determining the location or timing of bandwidth or scaling of services. It could include changing the bandwidth coverage area.

At its core, NaaS is about flexibility—and therein lies the challenge of this step. Refining KPIs also means reshaping CSP organizations built to support fixed product offerings into modern, agile businesses that let customers choose the network services they need.

When the customer owns the service lifecycle

As every telco knows, it’s hard to overstate the difficulty of reshaping their business models. With NaaS, the customer is in charge: They own the complete service lifecycle: only paying for the network services they use and customizing every aspect of how use them.

Operational hurdles abound for telcos in the transition from fixed to flexible operations. Siloed functions are a major obstacle. So are static configurations, where the hardwired approach to networking—with preconfigured, non-dynamic, and non-autonomous methodologies—hinders efforts to expose and manage network layer functions. And while software-defined networks (SDN) have been around for several years, the operational capabilities to enable service management for on-demand connectivity still lag the virtualized capabilities of scalability, self-healing, and bandwidth management.

Ready-to-use open standards are now here, and they should be all the motivation telcos need to modernize their business operations to support the NaaS model. By driving end-to-end service management of a network layer function, open APIs enable exposure of the network from the production domain to the commerce domain. They also create reusable services that can be easily monetized.

With such strategies in place, telcos will be ready, finally, to reshape their business operations, expose APIs, and start helping themselves, and their customers, to thrive in the Age of NaaS.

To learn more, visit the Communications, Media and Technology section of our website or contact us.