For Telcos, NaaS are seen as a “second chance” to recover the value they lost to the “over the top player”. But disruption is not simple, and it must overcome several challenges to be monetized.
The traditional network architectures were separated from IT domains. In particular, software was proprietary and ran on machines supplied by equipment manufacturers (Nokia, Ericsson, Alcatel, Cisco, etc.,). It provides functions like core mobile network or components, call control, Radio Access Networks (RANs), routers, firewalls, etc. Virtualization, which allows virtual machines to run on commoditized hardware, has been imposed in IT and has also impacted telecommunication software, and for 5G stand-alone it is a standard.
5G architecture and Network Exposure Function (NEF)
Within the 5G architecture, the Network Exposure Function (NEF) is the layer that exposes the 5G functions to third party via Application Programming Interfaces (API). Downstream, NEF interacts in real time with many of 5G core functions, for example PCF (Policy Control Function) for provision of dynamic policy enforcement, NWDAF (Network Data Analytics Function) providing network analytics to assist an external application to make efficient decisions and SMF (Session Management Function) influencing the traffic by steering a connection to an Edge Server.
In concrete terms the 5G can be connected to an external application for
- Adapting the quality of service on demand. This can give priority to some devices/applications : real-time robots, media/event streaming, emergency services, specific XR...
- providing real-time information for advanced security and analytics. It can guarantee for example the integrity of connected objects.
- Enforce specific network routing in giving access to resources. This can optimise the routing of some application to get some computing resources to reduce time or to decrease costs.
This capability is called “Network as a Service” (NaaS). For Telcos, NaaS are seen as a “second chance” to recover the value they lost to the “over the top player”. But disruption is not simple, and it must overcome several challenges to be monetized. Poor adoption can be a consequence of different factors including prohibitive pricing, lack of cross-carrier compatibility, complex go-to-market. Let’s review these challenges.
#1 Challenge : NaaS customers are not the usual telco customers
The customer of NaaS is not the end user (with the SIM and the Terminal) but an Application Service Provider which offers to the end user a service which integrates the Naas function.
Third party developers can be in theory entrepreneurs looking to “call” a NaaS API from a mobile app following the example of google map (the most popular API). But according to the nature of the NaaS, it will more likely structured application service providers: an E-agriculture software willing to enhance capabilities of their connected sensors, a Business Video OTT1 (like Zoom) looking to enhance the efficiency of corporate communications, etc…. The operator may not necessarily know or understand how the NaaS service is used, or how it is included within the value chain. This is a real challenge to market promote it and to price it. A feature may be extremely valuable in one use case while being of less value in another.
#2 Challenge : customer base is fragmented across telcos
Assuming an application targets a given geography (for example a country) an application service provider will look to serve all users. Operators have to forget about using these NaaS as market differentiators on their own customer base. A telco- specific solution which is not compatible with another telco will be seen as a reduced market for the application service provider. Operators should move away from this by developing together tools that abstract away complexities for designing, building, deploying and publishing APIs. This leads to the adoption of cross-operators standards, but these initiatives have a poor tack-record in term of speed-to-market.
#3 Challenge : who does run the ecosystem ?
Operators cannot offer the NEF (Network Exposure Function) directly to third parties, and will need to create another layer to define specific services for them. Third parties will not have access to the NEF API, but only to the operator-defined API. It is unlikely that all operators will independently offer the same APIs to third parties. This could lead ultimately to a complete fragmentation of the ecosystem (there are over 750 mobile operators worldwide !) that would discourage service adoption. There is therefore a contest around this upper layer and its standardization. It can be more efficient to give the task to design this upper layer to a telco-independent actor that would be more customer focus, and above all carrier neutral. As a paradox hyperscalers ((AWS, Microsoft Azure, Google Cloud,…), [BHKAS1] [EDS2] which were supposed to lose some value back to telcos, position themselves as go-between to federate the operators.
#4 Challenge : to sell operators must adopt a business use case approach rather than a feature approach
The focus of developers is likely on the application they are building. Developers using NaaS may specialize in specific use cases, driven by technical challenges or the intended industry or sector of the application, such as industrial, agriculture, or transportation. If marketplaces for software become prevalent, their success will likely be determined by business considerations rather than technical factors. For example, the success of companies like Twilio in the CPaaS (Communications Platform as a Service) market can be attributed to their ability to offer a range of services for customer relationship management in one place, making it easier for developers to access the necessary API's. Telcos are unlikely the best to animate the marketplaces of their NaaS.
#5 Challenge : they are “good enough” alternatives
Most of the NaaS have an equivalent in OTT mode. Applications have overcome network weaknesses by developing a range of strategies, without waiting for operators to deploy remedies. So when the solution arrives, it's too late, the ecosystem has adapted, even if it's sometimes at the cost of performance compromises.
To give an historical equivalent, let’s remember that in the course of the year 2000 there was many debates between whether ATM was better or not than IP to carry voice/video traffic. Even though ATM/Telco tend to be optimal, Internet/OTT networks demonstrated since their capabilities to carry professional communications. Internet being simple, plastic[BHKAS3] [EDS4] , cheap and universal, it proved to be “good enough”, though not to be the best[BMPS5] .
A closer example is SD-WAN (Software Defined Wide Area network), which is an overlay layer above (internet) networks. SD-WAN has an end-to-end view of the application and a privilege connexion to the public cloud. This can be done by corporate networks based on MPLS, but on a less universal manner.[BHKAS6] [EDS7]
The competition for NaaS APIs is not against other NaaS APIs, but rather against OTT (over-the-top) alternatives. There is no hidden plan for hyperscalers/ OTT against telcos, and they can even be facilitators of NaaS. For telcos, to secure this opportunity, they must relinquish certain privileges such as direct customer access, exclusivity on features, control of final usage. This requires re-evaluating their value within the entire chain and potentially reassess opportunities on a case-by-case basis.[BHKAS8] Customer demand for 5G SA specific features such as reduced latency, hybrid mobile networks, real-time trusted analytics will ultimately determine NaaS take off, and subsequent operators copernician revolution.
1OTT : Over The Top refers to solutions that allow the transport of data and/or cloud applications without being dependent on a particular network infrastructure and to any terminal.
