HTML5 - The Catalyst for Network as a Service?

In this guest post. Aepona’s Michael Crossey asks whether HTML5 provides an opportunity for Telcos to drive demand for ‘Network as a Service’ (NaaS), providing access to telco assets and capabilities via APIs, and help them address the OTT threat?

The recent Telco 2.0 report, “Technology Disruptions: What does HTML5 mean for Telcos”, described both the opportunities and challenges that this emerging technology presents for Mobile and Fixed-Line network operators. In this article, Aepona presents another dimension to the potential impact of HTML5 on Telcos, namely the opportunity for them leverage the trend towards HTML5-based applications and services as a demand driver for their “Network as a Service” (NaaS) offerings. This will allow them to extract value from OTT applications, rather than being relegated to the role of “dumb bit-pipe” provider.

NaaS is a manifestation of the 2-sided business model described by Telco 2.0, in which the Telco’s network, contextual, informational and commercial assets are exposed as APIs to organizations such as enterprises, ISVs, content providers and application developers. These APIs are then used to create additional functionality within those organizations’ applications and services, which in turn enables them to differentiate their offerings, improve productivity and customer service, open new payment channels, and ultimately expand their addressable market.

HTML5 is the latest evolution of the HTML standards, which have formed the basis of the Web since its original incarnation. HTML5 contains several major advances from previous versions of HTML, including rich interactivity features, inherent video support, the ability to work offline, and, increasingly, access to the underlying capabilities of mobile devices, such as the microphone, address book, camera, GPS and the multiple sensors now appearing on a wide range of smartphones and tablets.

These capabilities mean that HTML5 is now paving the way for a new generation of web-based applications that are independent from the device operating system, and not tied to a vendor or ecosystem-specific distribution channel. From the end-user perspective, HTML5-based applications can be designed to behave in the same way as native, OS-specific apps: users will generally not be aware that the application is essentially running within a browser. Moreover, HTML5-based applications can run on a wide range of devices, from smartphones to tablets, from desktop PCs to laptops, and from TVs to in-vehicle systems.

The HTML5-related opportunities for network operators outlined in the Telco 2.0 report were largely centred on the fact that HTML5 has the potential to decrease the dominance of the “Over the Top” (OTT) players, such as Google and Apple, by reducing the dependence of the Mobile Apps market on closed or OS-specific application platforms and ecosystems such as Apple iOS and Google Android. This applies to the app development environment as well as the distribution systems, both of which are currently controlled by the OTT players. The report also identifies opportunities for operators to leverage HTML5 opportunities in non-PC or smartphone markets, in areas such as IPTV, multi-screen services and in-car systems where they can potentially assert more control of the ecosystem, given the typically close integration of these services with the operators’ core networks.

However, Aepona believes the HTML5 related opportunities for network operators extend beyond the areas outlined above, particularly in the context of Network as a Service.

Unlike native OS application development, HTML5 (like previous versions of HTML) is fundamentally based on a client-server programming paradigm. In its simplest manifestation, an HTML client (for example, a desktop web browser) acts only as the presentation layer for the application or service: the application/service itself runs on a web server, which services multiple clients. Although HTML5 introduces additional functionality to the client-side, allowing applications to run locally on the device without a network connection, the optimal user experience will always be provided by the combination of client-side and server-side functionality. There are multiple reasons for this, including the ability for computing resource-intensive processes to be offloaded from the device to the server, the reduced need for large amounts of data to be transferred to and from the device (hence minimizing data charges for the user), and more streamlined security (for example, web servers are generally more trusted than native device apps when making payment requests).

This client-server paradigm of HTML5 lends itself extremely well to Network as a Service, since NaaS is itself based on the model of applications/services “calling” network API services on-demand, using the same types of HTTP requests and responses that are used between the client-side and server-side of HTML5-based apps. These network API services are exposed via a dedicated server, which is either deployed within an individual operator’s network or in a centralized, cross-network API service such as the GSM Association’s OneAPI service. It is therefore a very natural, low-friction step for HTML5 developers to enrich their applications/services with network features, by simply extending the server-side of their application to call the relevant network API services as required.

This contrasts with the native app model: many native applications are designed to run locally on the device without a server-side, meaning that those apps would have to be fundamentally re-designed to incorporate the additional features offered by NaaS. Even then, calling network APIs directly from a native device application introduces additional security requirements on the back-end, especially for services such as Payment, since a local native app is not trusted in the same way as a server. Furthermore, designing a native app to call network API services directly potentially increases mobile data usage, compared with the HTLM5 server-side being used to handle network API requests.

As mentioned earlier, another developing feature of HTML5 is its ability to access device capabilities, such as accelerometers, GPS functions, cameras and so on. This will eventually allow HTML5-based applications to be endowed with the same level of functionality as native applications, for all but the most demanding of apps (such as high-end, graphics-intensive games).

However, the commercial potential for HTML5 applications will be maximized by combining device-side capabilities with network-side services provided by the Telco, rather than relying solely on the device side.

Take location-based services as an example. Device-side location capability based on GPS is limited in that it requires line-of -sight to operate, is power-hungry, can only provide the location of that device, and requires an app to be running on the device (i.e. it needs active user participation). Network-derived location, on the other hand, can locate any device whether GPS-enabled or not, and can operate without user intervention or needing an app to be running. Moreover, the developer can “write once” on the server-side to call the network APIs, versus having to write towards different handset and OS implementations.

Of course there are many other network-side features and capabilities that can be built into HTML5 applications which complement device capabilities to provide the optimal user experience: examples include rich user context (data connection type, roaming status, zonal presence), customer profile information (identity, tariff/data plan, age/gender), advanced communications capabilities (multi-party/multi-media conferencing, instant messaging, network Quality of Service control) and of course Payments (for in-application billing and subscription services).

Therefore, augmenting device-based GPS capabilities with NaaS-based services will provide a much broader addressable market for HTML5 applications whilst enhancing the utility of the app and a differentiated user experience. As described earlier, the HTML5 client-server programming model makes this extremely easy for developers, as they do not have to fundamentally alter the design of their applications enrich them with NaaS features: they can simply extend the server-side of their application to make the required API calls to the NaaS service.

Today, Telcos are rightly seeing the emergence of HTML5 as the pre-eminent platform for future mobile application development as an opportunity to regain some of the ground they have lost to the OTT players over the past 5 years, primarily for the reasons outlined in the Telco 2.0 report. However, the combination of factors outlined above means there is another, perhaps even more significant, opportunity presented by HTML5 - namely, that HTML5 can become a significant demand driver for Network as a Service, providing the catalyst for a huge variety of cross-platform business and consumer app developers to embed the Telco’s core network capabilities within their applications, and allowing the operators to finally realize the full potential of the “2-sided business model” vision put forward by Telco 2.0.