How NaaS deployment is shaping up

To date, communications service providers’ (CSPs’) implementations of network-as-a-service (NaaS) have focused on increasing efficiency and agility in business and operations while improving business customers’ service experience. Key goals have been reducing network and support system complexity and giving customers more control over their services. But so far, CSPs have mainly used internally developed and/or proprietary APIs in their NaaS implementations, which limits their ability to partner.

What is NaaS? NaaS is defined most simply as a framework for building network services that decouples the customer’s service intent – along with the operational and business support systems (OSS/BSS) used to create and manage their service – from the network resources needed to fulfill that intent. The decoupling happens through an abstraction layer that hides networking details and complexity, which is central to simplifying the whole service lifecycle. So, if an enterprise requests a service of certain bandwidth with specific characteristics between specific locations, the CSP’s OSS/BSS and network systems and elements autonomously figure out how to “make it so”, whether it requires one component or 100 to create an end to end service. At least that’s the promise; few current implementations meet this high bar.

Benefits of NaaS Even if CSPs haven’t realized the vision of real-time, autonomous service creation based on the customer’s intent, today’s NaaS implementations provide clear benefits to them and their customers. Customers reap the benefits of more choice and better simplicity, integration, control and delivery. Beth Cohen, SDN Product Strategist at Verizon, calls these NaaS benefits “smoothing over the seams” between the components required to create end-to-end services. Customers pick what they need from an intuitive, graphical portal, finalize the order, and then – if all goes well – get the benefit of a fully automated fulfillment and activation process. The customer can monitor the basic performance stats of the live service, and if their needs change they can make some service adjustments (for example, IP address, policy or bandwidth). Once they confirm the change and agree to any price changes, their service will adjust accordingly.

Beyond the paramount benefit of happier customers, CSPs reap efficiency and agility benefits of better operational performance through looser coupling of the network to support systems. This decoupling results in less customization, fewer truck rolls and so on. And even if in our example all does not go well, any fallout can be handled as a manual exception rather than the rule.

Telstra leads the way on NaaS Telstra is generally acknowledged as the first CSP to implement NaaS, starting at least as far back as 2017, when it lamented that there was no standard way to expose network services. The operator was instrumental in the development of TM Forum’s Network as a Service (NaaS) Requirements released in October 2018 and the NaaS Open API Component Suite released in 2019. NaaS is defined most simply as a framework for building network services that decouples the customer’s service intent from the network resources and support systems needed to fulfill that intent. Telstra formally launched its NaaS platform in November 2018 and is using NaaS to provide services to enterprise customers, TM Forum’s Open Digital Architecture and Open APIs along with the MEF 3.0 Lifecycle Service Orchestration (LSO) reference architecture and APIs have been essential to the exposure standardization process that has made NaaS viable. In a recent TM Forum Benchmark report, What is connectivity-as-a-service?, Telstra’s Mark Sanders, Principal Network Cloud, noted that his company has “a strong NaaS program and are well along, continuing to enhance our composition capabilities and [employ] Open APIs. We have come a long way, but it is a never-ending process trying to work out the optimal domain boundaries and now incorporate slicing.” Telstra is pushing its NaaS implementation forward, ultimately into CaaS.

Early examples focus on SD-WAN

Looking at the market more broadly, it’s hard to pinpoint the number of CSPs that have implemented NaaS, in part because not everyone hews to the same definition. Virtually all Tier 1 CSPs with a sizeable enterprise services business (or serious aspirations to build one) have NaaS-supported B2B offerings; they have to in order to compete. With the deployment of standalone 5G networks, CSPs’ aspirations extend further to B2B2X services that will require more expansive partnerships and broader external exposure of network capabilities. Research and interviews with four representative CSPs that have implemented a NaaS framework (Orange Business Services, TELUS, Verizon and Vodafone), indicate that for the most part implementations focus on service offerings such as software-defined wide area network (SD-WAN) services with security and related value-adds delivered in the cloud (a combination often referred to as “SASE”, or secure access service edge, as coined by Gartner). The offers are presented on a GUI-based portal and comprise a curated, pre-certified set of service options from which customers choose based on what they are trying to accomplish. When the customer buys the service, it gets a measure of control over configurations and other changes, as well as tools to support some level of monitoring and observability. Although enterprises often push for more control in RFPs, one CSP noted that in practice many customers don’t have the expertise or resources to actually take control. They lean instead on their CSP’s expertise and the proverbial “one throat to choke” proposition inherent in the managed services relationship.

Orange aims for cloud connectivity

Orange Business Services’ original NaaS vision was to build and orchestrate a complete end-to-end network using its NextGenHubs (points of presence enabled by software-defined networking – SDN), using a single automation and API environment to control everything. The company has had to temper this vision because realistically, it needs to use vendor-specific domain controllers to communicate with network functions and elements. It also needs to develop middleware between these APIs and its customers to allow some measure of self-service control. The need for middleware doesn’t defeat the promise of NaaS, but it does introduce the sort of customization that limits the promise. A key focus for Orange Business Services today is using NaaS to make cloud connectivity seamless. This is a priority that has taken on more urgency as the Covid-19 pandemic has forced customers’ employees to work from home. The company’s “tomorrow goal” is to further componentize its service catalog to enable a “bring your own” element for customers and partners. However, this extension requires major rethinking about how to manage such multi-party services end to end to meet service level agreements.

TELUS eyes nearly $1 billion in new revenue

TELUS notes that it was the first CSP to launch managed SD-WAN service, and it has been using NaaS principles since then to expand the set of service options and price points that enterprises can choose from to meet their needs. Flexibility and choice have driven customers' interest in NaaS-supported offerings. TELUS is also advancing the idea of software-based services in anticipation of more complex services to come, spurred by standalone 5G. The company is expanding its enterprise service marketplace to what CTO Ibrahim Gedeon calls a “service delivery framework on steroids”: The customer can pick whatever cloud, collaboration tools, mobility minutes, and other services that it needs and that fits its budget, and TELUS will make it happen. It’s very much a bundling strategy underpinned by NaaS. TELUS believes its expanded NaaS-based offerings, including rural and smart city security services, retail analytics services and network slicing services, will enable it to unlock on the order of C$1 billion ($800 million) in new revenue over the coming five years. TELUS uses APIs to integrate its and partner products into solutions, and the onboarding process can typically be done in days rather than months. TELUS is expanding its enterprise service marketplace to what CTO Ibrahim Gedeon calls a 'service delivery framework on steroids'.

Verizon seeks to woo developers

Verizon has created an access-agnostic network platform that ties the elements of connectivity and applications together through a common orchestration and API layer. Through this platform, the company supports an array of SDN-based services as well as some edge-based services such as VNS Application Edge. VNS Application Edge is a NaaS-based service whereby Verizon manages the edge resources (compute, storage, networking) and provides an orchestrator that the customer can use to manage their application(s) centrally. Verizon does not manage the customer’s applications. Verizon is starting to create a broader digital ecosystem that draws in third parties to develop specialized solutions and applications for vertical markets, and to woo developers. Its targeted future state for enterprise networking is to allow secure connection from anywhere to any app in the cloud. Security and connectivity become service “features” not individual products. The network platform provides centralized configuration and unified self-service for enterprises, while supporting an on-demand, as-a-service model. This vision extends beyond NaaS to connectivity-as-a-service (CaaS). Vodafone simplifies service creation Vodafone Group’s current NaaS focus is on simplifying its operating companies’ business interactions with the network by offering northbound APIs that teams working within the business units can use to create new products and services. A group-level team does all network exposure API development work, as prioritized by the combination of demand and complexity. Vodafone has recently hired Joanna Wood, an ex-Google head of telco strategy, to spearhead its API marketplace efforts, which are related to but not explicitly in support of NaaS monetization. Vodafone notes that developers will be a key constituency to work with to create scale and repeatability as it expands its marketplace strategy.

Limitations of today’s NaaS implementations

Two important notes on the practical limitations of the commercial NaaS state of the art: None of the four CSPs we interviewed claim to yet be using standard TM Forum Open APIs or MEF APIs in a significant way as part of their NaaS implementations. They are still very much relying on internally developed, proprietary APIs or (southbound) APIs proprietary to the vendors’ domain controllers, despite championing NaaS proofs of concept with TM Forum and MEF. NaaS network-capability exposure is largely an internal affair. The CSPs are not yet exposing network functionality (or their internal network APIs) to third parties – at least not widely. Some do publish and expose APIs to allow the relaying of trouble ticket information to customers’ own workflow systems , or GSMA service delivery APIs between carriers to enable customer refunds and the like. CSPs are not yet exposing network functionality (or their internal network APIs) to third parties – at least not widely. In short, there is strong momentum for NaaS as an internally focused “inside out” framework for service delivery, one that is useful and prized for exposing the capabilities of programmable networks and allowing more agile operations while hiding network complexity from customers. The typical NaaS ecosystem is tightly controlled by the CSP, with little or no interplay between its partners and customers. Implementations of more fully open, intent-based NaaS platforms on which vertical market specialists, systems integrators or other partners are free to develop solutions, have remained a step too far for most CSPs, but this is a goal. TELUS notes that it considers its APIs and related systems to be its “crown jewels”: The company very much believes in the TM Forum Open APIs and ODA as goals and a roadmap but wants to control what enters its gateway and touches its network. TELUS does not expose the APIs externally because it views the stakes, as too high in terms of network outages or cyberattacks. The network is too complex, and the enabling technologies (such as NFV and network slicing) are too new to provide the level of standardization (and the concomitant ubiquity, consistency and uniformity) that would allow the company to move beyond a curation approach. None of the CSPs interviewed were specific about how long they expect it to take to realize the vision for NaaS, where marketplaces are truly open, but we believe it will be several years.