Three aspects of network transformation can drive technology and business forward for carriers by enabling a new Network as a Service (NaaS) model.
By Wei Yongfu, Network Architecture Transformation Marketing Dept, Huawei Carrier BG
A new business model for Network as a Service (NaaS) that can drive both technology and business forward grabbed industry-wide attention earlier this year at MWC Barcelona 2023. This new model allows carriers to achieve service growth by exposing their network capabilities through APIs.
Redirecting the spotlight with the Open Gateway Initiative
NaaS is not a new topic, with carriers already having spent years exploring network capability exposure and monetization. Currently, typical NaaS capabilities include SMS and voice calls. Virtual phone numbers generated by a service app that couriers often use during deliveries are an example of how voice calling capabilities are currently monetized. Service providers that support these apps pay carriers each time the API for this capability is invoked.
At MWC Barcelona 2023, GSMA brought NaaS back into the spotlight by launching the Open Gateway initiative with 21 carriers. The MOUs signed to kick off this initiative have made this area one of the most important for technical and business advancement today.
How does this round of network capability exposure differ from the previous one? We can identify three main areas.
What is different?
The network capabilities being exposed now are similar to the ones the industry already knows about in that they all provide new avenues for service growth. However, this new round of exposure is highlighting some new capabilities – digital service roaming. GSMA expects API roaming to enable digital service roaming, similar to how new capabilities made voice roaming a reality three years ago.
What is being exposed?
This round of exposure focuses on 5G and more complex capabilities, such as network slicing (deterministic network assurance), 5G new calling (upgraded SMS and voice capabilities), and private lines/networks (for example, private fixed lines and private 5G networks).
What does this mean for monetization?
GSMA and Linux Foundation jointly launched the CAMARA project to define and code open-source APIs. By developing these new, easy-to-use service APIs for both developers and consumers, CAMARA is able to shield complex technical details while exposing network capabilities in a developer-friendly way. The CAMARA project team will collaborate with industry organizations like TM Forum to define API layers and design NaaS architecture. As part of its efforts to expand the market, CAMARA will also call on industry partners, including cloud service providers, OTT service providers, app service providers, and enterprise customers, to explore new business cases using these new network capabilities.
A three-layer NaaS architecture for carriers
The NaaS architecture carriers use has three layers: the network layer, platform layer, and application layer (Figure 1).
Figure 1: NaaS architecture
The network layer provides broad-sense network capabilities for communication technologies (CT), information technologies (IT), Internet of Things (IoT), and cloud. This layer acts as a technical foundation for network capability exposure and monetization, providing strengths in differentiated capabilities, on-demand self-service model, and intent-based APIs. Differentiated capabilities are irreplaceable network capabilities for OTT services and applications, such as deterministic network assurance and accurate positioning. The on-demand self-service model makes network resources visible and manageable, allows network capabilities to be invoked on-demand, and enables the self-service purchase and provisioning of network services. Intent-based APIs are aggregating function-oriented atomic APIs and highly available easy-to-use network APIs that make integration and service innovation simpler and faster.
The platform layer converts network APIs into developer- and user-oriented service APIs and makes them publicly available through exposed API gateways. The key to this layer lies in standardized service APIs and a complete NaaS platform. The CAMARA project team is focusing on the standardization of open-source service APIs. These APIs will have to be:
- Easy to use while capable of shielding complex network details. For example, quality on demand (QoD) APIs only have three mandatory parameters: source, sink, and QoS profile, while necessary description documents and reference code are provided open source.
- Standardized for use by all carriers, so that docking and integration become easier and network capabilities of multiple carriers can be quickly invoked.
- Globally accessible, which can be achieved with the help of CAMARA. The alliance was established to promote interconnection between global carriers at the NaaS platform layer and enable API roaming.
The NaaS platform interconnects huge amounts of equipment from different suppliers with business support systems (BSSs) and operations support systems (OSSs) on live networks. Carriers will be able to use APIs defined by standards organization, like the 3GPP, ETSI, and TM Forum, to better facilitate interconnection between their network layer and BSS/OSS layer, simplifying platform design and construction.
The application layer deals with API go-to-market and sales channel issues. Ecosystems and service scenarios play a huge role here. Identifying service scenarios and designing corresponding business models, such as backward charging represented by subscription and revenue sharing, are key steps to monetizing network capabilities. This is also an area that the entire industry is exploring. Most industry players have agreed on launching service APIs through multiple channels in different app markets, and providing developer kits so that global cloud service providers, vertical industries, OTT service providers, and app developers can help verify network capabilities, and design and incubate business cases.
The transformations needed for NaaS business success
As 5.5G deployment and commercialization advances, carriers will need enhanced network capabilities to ensure their networks are bigger, more differentiated, and more automated. This will allow them to fully unleash the value of their networks and facilitate their business success with NaaS (Figure 2).
Figure 2: Network transformation for larger scale, differentiation, and automation
Large-scale networks
Abundant network resources are a prerequisite for network capability exposure. Carriers will need networks that deliver more in terms of coverage, performance, and capacity if they want to guarantee deterministic service experiences that meet user requirements.
Differentiated network functions
Third parties will only be willing to pay if carriers can deliver exactly what they need. The differentiated network capabilities they want can come in two forms:
First, irreplaceable capabilities, such as phone number-based voice and SMS capabilities, and 5.5G's accurate positioning capabilities.
Second, complex capabilities beyond connectivity, including "connectivity + perception analysis + flexible scheduling", and "connectivity + cloud". Service examples include 5G new calling (video calls + intelligent translation), end-to-end slicing, dynamic QoS, and the automated provisioning of cloud-network private lines.
End-to-end automation
Finally, networks will have to be automated end-to-end so that APIs can be agilely invoked. A lack of automation in any link in the process would mean NaaS requirements cannot be met. The core requirement for NaaS is the on-demand self-service model, meaning services can be provisioned automatically, service experiences are perceivable and visible, and SLAs are visible. Only level-3 or higher-level autonomous networks are able to meet the on-demand self-service requirements for NaaS. Given the current challenges to carrier networks, such as the coexistence of multiple radio access technologies (RATs) across both legacy and new networks supported by different suppliers, network automation efforts will require clearly defined strategic objectives, top-level design, evolution strategies, and implementation plans.
Huawei's role in network capability monetization
Huawei is currently working on three types of network APIs to support the monetization of network capabilities (Figure 3).
Figure 3: Three types of network APIs
Network APIs can be viewed in three different ways based on the value they deliver:
The first type of API facilitates the creation of new products and offerings. For example, enterprise call centers can use a 5G New Calling API to invoke capabilities like video calling for remote maintenance guidance and remote loss assessment. Carriers can charge enterprises by how many times these APIs are invoked.
The second API type enables better sales for existing products and offerings. For example, an API for accurately identifying potential home broadband customers can apply to package upgrades and value-added services, thereby improving the sales of existing home broadband services.
The third type of API improves O&M efficiency. For example, an API for intelligent diagnosis of wireless network faults can provide raw alarms and event root cause analysis, and eliminate redundant alarms through spatiotemporal correlation analysis, to reduce trouble tickets and improve O&M efficiency.
To realize the full value of the first type of APIs, we will need more collaboration between industry ecosystem partners, such as cloud service providers, vertical industries, OTT service providers, and app developers. They will need to jointly design the APIs and incubate business cases based on actual network capabilities. The second and third types of APIs can be quickly verified and deployed by carriers to create a new business cycle. Huawei is committed to developing plans for all three types of network APIs to help carriers monetize network capabilities and unleash the value of their networks.
