Skip navigation
Like what you’re reading?

Why are APIs needed on the edge?

Available in English 简体中文 繁體中文
Exposure through application programming interfaces (APIs) is becoming increasingly important for communication service providers (CSPs) to enable new services, increase their relevance in the edge computing ecosystem and become more attractive partners. Discover why the industry needs edge exposure and how CSPs can support simple and developer-friendly APIs.

Solution Marketing Manager at Digital Services

application programming interfaces (APIs)

Solution Marketing Manager at Digital Services

Solution Marketing Manager at Digital Services


Exposed capabilities and data, such as device location, user equipment information and quality of service (QoS) functions are being used to improve existing use cases, for example in terms of performance, and develop new use cases for both consumers and enterprises. Other key drivers include the need to implement new business models or to simplify the application developers’ interaction with the telecom network by hiding inherent complexity inside them.


What is the difference between network exposure and service exposure?

In the telecommunications world, you will run into the terms network exposure and service exposure. Network exposure is strictly based on de-jure standards, often defined by industry organizations such as TM Forum or 3GPP and exposed through network APIs. However, these APIs are often difficult for application developers to use as they require deep telecom knowledge and are hard to benefit from directly in applications. Therefore, several network APIs can be combined into service APIs, tailored for various use cases on a higher abstraction level, easier to use and understand for developers. Unlike network APIs, service APIs are de-facto standard based. They are often the result of co-creation between various players in the ecosystem and are designed to realize new use cases across industries that see the value of using 5G as part of their business processes.

CSPs can expose functions and data, in three dimensions:

  1. Towards user equipment, or device vendors (OEMs),
  2. Enterprises directly or
  3. Towards application developers via CSP or HCP (Hyperscale Cloud Provider) edge infrastructure.
Ericsson Edge Exposure Server


User equipment exposure allows the device to trigger request for network capability rather than from the application.

Exposure towards enterprises is needed for applications to invoke network capabilities for industrial internet of things (IoT) APIs, connected drone APIs and many other types of services that could be targeting both internal and external use.

Edge exposure makes it possible for HCPs or other CSPs to use network capabilities to provide tailored enterprise applications. But why does this exposure have to happen on the edge – why not from the central locations using network exposure function (NEF), as standardized by 3GPP?


Edge exposure

Exposing capabilities from the edge is about improving efficiency in use case performance and ease of use. Below are some examples of important network capabilities that can be achieved through edge exposure.


Edge application discovery

Edge application discovery means that the device application can connect to the optimal edge location residing the application. It may not always be the closest location that is the most optimal one, but with edge application discovery the traffic from the device will be routed to the best choice. For example, by using an edge application discovery service API, this type of service can be implemented where developers can extend their cloud environments to include edge zones and leverage APIs to simplify connectivity. In addition, traffic can reach application servers running in HCP edge platforms without leaving the CSP network providing security and efficiency.


Quality of service (QoS)

The NEF QoS API can be enriched further to benefit edge applications requiring QoS, for example to:

  • Apply QoS for a group of devices instead of a single device per application.
  • Apply QoS for future sessions in addition to current session.
  • Make it easier for developers to interact with the telecom network.

Using an edge service API for example, a drone management application on the edge can request QoS for multiple drones served through that edge site at the same time. Another advantage is that the edge service API can dynamically modify the QoS data session according to business needs e.g.  in the drone use cases and critical operations like commands to the air regulator or for the live video streaming.



The 3GPP NEF API for location event is part of a complex MONTE API that includes several events as part of the same API. This means that it will provide more information than the application needs. By using a lighter and more flexible edge service IP, where different events based on application needs are available results in a faster location response through locally cached location information. The edge service API is also easier for developers to use since it is dedicated API for device location.



Security is always a key concern for the industry. Using an edge service API makes it possible for the edge application to communicate with the edge exposure server, which is within the edge data network maintaining security requirements. A clear benefit here is that communication via the internet is avoided. For some HCPs, this is an important capability as they don’t allow external systems outside of the edge data network to access the application because of security reasons.


Harmonized service APIs

To make life easier for developers and increase the uptake of use cases for CSPs, harmonization of service APIs is important. Without harmonized service APIs, developers must take different service API implementations for CSPs into consideration when they develop applications. They would also need deeper telecom knowledge to design the application, limiting the number of available developers in the ecosystem. Using harmonized service APIs, developers can make their application available for multiple CSPs without major implementation changes. Telecom complexity is reduced, and less system integration is needed.


Ericsson Cloud Core Exposure Server introducing edge exposure server

Ericsson is introducing an edge exposure server as part of the existing offering Ericsson Cloud Core Exposure Server. Ericsson Cloud Core Exposure Server is a cloud native core network exposure function in Ericsson’s dual-mode 5G Core offering. It is based on a full set of standard APIs for both 4G and 5G networks (catered to by 3GPP SCEF and NEF standards) empowered by extra capabilities for API gateway, management and security. With the introduction of Ericsson Edge Exposure Server, we are now evolving exposure to the edge enabling CSPs to address more edge opportunities and simplifying for developers to design new services.

Edge site


Ericsson Edge Exposure Server is using 3GPP as a base with proprietary enrichment APIs to enable edge applications to register and de-register, let the device discover the right edge node to connect to and let the applications get access to network capability information, which is instrumental for delivering high performance applications.

Ericsson Edge Exposure Server also provides simplified and feature enrichments APIs for edge applications such as user equipment information API, network QoS API and location API. And to reduce complexity for developers and needed system integration when deploying new services, harmonized service APIs addition to standard APIs are provided. Overall, the offering makes CSPs better equipped to provide services beyond connectivity, shorten lead times and become more relevant in the edge computing ecosystem.

Read more about edge exposure.

The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.