3GPP is heading north with APIs

• How exactly is 3GPP developing new northbound APIs?
• Operators want to exploit additional communication channels
• History of creating new, rather than adopting existing standards
• Work to run from Release 14 through to Release 16 and beyond

We recently reported on the news that the 3GPP standards group has started work on defining a Northbound Application Programme Interface (API), which provides an interface between an Application Server (either in a mobile operator’s network or external to it and operated by a third party) and the cellular network, controlled by specified functions in the operator’s network. The objective is to help operators provide targeted services to vertical industries through “network slicing” of functions and assets.

It’s a very important area, and there are a lot of issues around this move. Our thanks to Erik Guttman, Chair of the 3GPP TSG SA, for taking time to clarify these issues and provide us with additional details.

Are network technology and architectures sufficiently advanced to support such endeavours? Yes they are, says Erik, but the business implementations have yet to succeed. For example, he correctly cites the fact that VPNs have been supported ever since GPRS was introduced as the precursor to mobile data as we know it today. There are many retail establishments that still rely on GPRS to collect payments from credit cards, but the commission charged by the card issuing companies dwarfs the cost of providing the data connectivity service. In other words, it is not that network technology and architectures are not sufficiently advanced – it is that they are not sufficiently suited to many industry deployment and business models. When you come to add additional services such as device management, monitoring, high latency data delivery, etc, then the situation becomes worse.

But the Northbound API work goes beyond offering communication services to app servers. “The intention is to provide service-specific control, monitoring, authorisation, etc. so that the network’s behaviour and knowledge can be exposed and even controlled by third parties,” says Erik. “In some cases, it is the operation of the network itself that can be parameterized, exposed to and controlled by application servers, that constitutes the service.” All should be revealed in 3GPP Rel-15.

How does this impact on the Open Mobile Alliance (OMA) API programme? The 3GPP stopped work on northbound APIs when it transferred the Open Service Architecture (OSA) API work to the OMA back in 2008.  Since then, the OMA has developed standardised interfaces to the service infrastructure within networks and on devices.

However, whilst there are Net APIs for many services, none exist for “Infrastructure as a Service”. Dozens of APIs exist for content access, person-to-person messaging, device capability control, service customisation and other areas, but not IaaS.

Northbound APIs, it’s not a replacement for the OMA’s APIs. The latter focus primarily between the service access layer and generic network capabilities. The 3GPP is attempting to increase the value that the mobile network operator can offer to service providers through access to its network assets.

We are no longer talking about capabilities such as SMS, MMS, location services or payments, rather the focus has shifted to new APIs that exploit additional communication channels (such as broadcast and  non-IP communications), additional control (such as. broadcasting media or metadata) and monitoring information (such as media delivery information and non-IP data delivery).

3GPP is therefore looking to work with OMA to use or incorporate the existing applicable OMA NetAPI standards. It’s not a formal collaboration, though. The OMA apparently understands that 3GPP will work on northbound interfaces – as requested by GSMA and OneM2M – for IoT purposes and won’t pursue this work in parallel.

Furthermore, the 3GPP’s SA6 group has started a new study to consider if there are framework aspects that should apply to all northbound APIs created by 3GPP. This framework may include aspects from OMA (such as their Open Service Environment or specific parts of their Net APIs), but more work needs to be done on what exactly is needed, what is offered and how to integrate it into the service enablement framework and other interworking functions already in the 3GPP system architecture.

It is worth remembering that 3GPP has not adopted an API standard from another standards development organisation (SDO) in a very long time – if ever – preferring to let other SDOs do the work that appeared to be more suited to their expertise. Yet after several years of waiting, telcos remain without an API for IoT use cases, and their need for one is becoming more important. Just look at the problems still faced by broadcasters, for example. Many standardised features within the 3GPP Release updates still need to be exposed to third parties, especially given the growth in vertical industry engagement, and that’s where northbound APIs come into their own.

Speaking of broadcasters, this month the next Release, Rel-14, should be frozen. It includes specifications for enhanced TV (EnTV), which will provide the initial steps towards greater cellular-broadcast convergence. We’ll have to wait until Rel-15 (the first true 5G release) for the normative API work on IoT and the common API framework. “The decision whether and how OMA Net APIs will be part of the common API framework will be taken by September 2017, or latest in December 2017,” said Erik. Thereafter, Rel-16 should be an expansion of current work plans and strategies, together with increased focus on new vertical markets – such as vehicle, maritime and transport communications.