Monetizing API exposure for enterprises with evolved BSS

Ericsson CTO Erik Ekudden’s view on monetizing APIs

There is growing interest among large enterprises in managing their own connectivity needs and building applications that leverage network characteristics and assets. The availability of properly scoped and easily accessible application programming interfaces (APIs) will be essential to support these efforts.

This article provides a comprehensive overview of the technology aspects related to the exposure of network services through APIs, and then goes on to address the critical question of service monetization. Our experts’ innovative approach tackles the commercial aspects of the whole life cycle of a service API, from the moment it is made available for consumption to the billing and settlement processes.

The ability to expose application programming interfaces opens up the opportunity for communication service providers to strengthen their role in the enterprise ecosystem by enabling new use cases, applications and programmable networks that deliver greater flexibility and automation. Evolved business support systems are essential to commercialize these offerings and support new business models.

Regardless of whether an enterprise uses a private (on-premises) or public network, emerging use cases in the enterprise ecosystem require that it has the ability to automate the management of connectivity and connected devices. The only way to achieve this automation is through the exposure of application programming interfaces (APIs).

Enterprise use cases increasingly have specific requirements that demand tailored connectivity solutions and flexible, efficient self-service capabilities. In their work to meet these requirements, enterprise application developers prefer to develop applications generically across platforms. Depending on the service or application they are creating – which could be a gaming app, a boost application or an enterprise management application, for example – their service API exposure needs can vary greatly. As a result, the services that need to be exposed range from network capabilities and network information to management and orchestration.

Enterprises expect applications in the communication service provider (CSP) domain to be able to capitalize on unique CSP capabilities to optimize the user experience. To build applications that are tailored to meet these needs, enterprise application developers require easy access to network information, influence over network behavior and the ability to manage and orchestrate enterprise connectivity demands simply and efficiently. The network services that are exposed today are not sufficient in this respect, as they require detailed telecom industry knowledge that is cumbersome to access and differs from one CSP to another. This is a major challenge that CSPs must overcome to meet enterprise use case requirements.

Meeting enterprise requirements

The speed of growth in the service exposure business will depend on how quickly CSPs can meet the key requirements. First and foremost, service APIs must be easy to use, access and consume. To attract developers, the service APIs need to hide telco complexity and should be harmonized as much as possible across CSPs. Second, the service exposure platform must support a variety of channels for API exposure, including direct exposure, communication platforms, marketplaces of platform providers and service aggregators. Finally, the services must have the right scope and be able to address specific enterprise needs.

To engage successfully in the service exposure business, CSPs will need enhanced business support systems (BSS) and operations support systems (OSS) functionality to support the customer and partner management APIs, as well as a range of different business and monetization models. BSS functions play a particularly critical role in the service exposure domain because they are necessary to implement the management and orchestration services that will be exposed to developers.

Beyond that, they are also critical for service enablement and exposure monetization. Both the BSS and OSS need to be addressable through APIs from different exposure channels (multi-country, multi-CSP and so on) depending on the use case. They also need to have the flexibility to support the exposure business models.

To scale effectively, service APIs must fulfill the requirements of simplification and standardization. Developers of any type of application need standardization and harmonization across CSPs, along with the ability to reach other CSPs through a single technical and commercial interface. They benefit from global tools and software development kits (SDKs) that can be reused across CSP APIs. These APIs need to act the same way across all CSPs without the need for CSP-specific information, while at the same time allowing inter-CSP API communication to reach customers of other CSPs or to address multi-country enterprise services.

Before they can go into production in the enterprise ecosystem, service APIs must go through a three-step process: API development, API setup in the CSP network and, finally, customer onboarding, which is when the customer can use the service API from within its own application. At this point, the service APIs can be reached both by applications on devices and by those on the server side. They can be used by both enterprise and consumer applications, made available on marketplaces, or consumed by API aggregators that form new services on top of the CSP’s APIs. A CSP’s BSS and OSS stack must support all of these different types of API consumers.

Exposing network service through application programming interfaces – technology aspects

By transforming their connectivity network into a platform for flexible service creation and innovation, CSPs can deliver significant value for enterprises that stretches far beyond connectivity alone. As ease of use is such a critical factor for enterprises and developers, there is much to gain from presenting the network to them as a black box that provides APIs that can easily be integrated with applications, managed by either their IT or operational technology (OT) organizations. Figure 1 visualizes our approach.

Different APIs enable different use cases, but rather than being specific to a particular vertical use case, many of them will address the needs of the case in terms of service management, connectivity, application management and so on. In addition, all APIs must comply with the same architecture standards when it comes to design, deployment, granting access and allowing for monetization.

For this model to work, the CSP’s service exposure architecture must be integrated with BSS that can manage the ecosystem partners and support various business models for monetization.

Figure 2 provides a comprehensive overview of all the CSP IT and network functions that are engaged in service exposure and monetization, in alignment with TM Forum’s Open Digital Architecture (ODA). The figure combines the functions for exposing, realizing and monetizing service APIs in one architecture and emphasizes that the functions available in the IT domain and the network play multiple roles.

The service exposure platform must support the automated life-cycle management of services. The service monetization architecture combines the service exposure domain with the business domain. It enables awareness of the API invokers (the applications that call the APIs and the parties operating the applications) and API usage in the core commerce systems as well as monitoring and assuring service operations.

Service implementation consists of service APIs that are logically placed in the engagement layer of the ODA and interact southbound with the functions from the IT domain and the network. The southbound interaction utilizes the standardized APIs (from TM Forum’s ODA and the 3GPP (the 3rd Generation Partnership Project), for example) and proprietary APIs that are exposed from the various functions through the internal exposure layer.

Service exposure

An efficient and scalable service exposure architecture requires a service exposure platform that provides gateway functionality as well as a set of centralized supporting functions responsible for authentication and authorization of API invokers, API management and some functions for developers (such as API catalogs). The service exposure platform belongs to the engagement and exposure domain. It also serves as the provider domain for the new service APIs. It is therefore desirable if the service exposure platform can also provide mechanisms and tools for service creation.

All APIs made available on the service exposure platform (described in an API/technical catalog) need to be modeled as commercial offerings in the commercial product catalog to allow them to be sold and/or to grant access of them to future API consumers. The API invokers are applications, which are operated by parties acting as API customers. The API customers must therefore be onboarded, and all parties that may be engaged in service monetization have to be made known in the CSP’s BSS. The service monetization architecture must support a variety of business models depending on the use case, the service API in question, the chain of intermediatory actors and the business rationale behind the service exposure.

APIs are used by various stakeholders that are served by the BSS and OSS. These include the initial application developer who develops the application that invokes APIs to the network and the partner onboarding developer who enables the onboarding of the partner and the partner applications to the CSP's core commerce system and the network. The developer of the customer onboarding functions is another important stakeholder, with responsibility for ensuring that the CSP’s customers’ applications can connect to the service APIs as a subscription or connectivity management service, for example. When the application is in service, the exposure function is responsible for monitoring key performance indicators (KPIs) and providing this information to the application developer, the party operating the application and the service provider operating the service APIs.

Each role in the ecosystem has BSS and OSS needs. For example, the application developer needs to have a relationship with a CSP, a service aggregator or a developer community that includes access to a developer portal and the ability to download the proper documentation, SDK and tools, as well as access to testing and other CSP-based development tools. The partner needs to have a commercial and operational relationship with the CSP based on functionality, volume or any other measurement, to facilitate application usage by its customers. The customer needs to be able to sign up for the service (either an end-service or the API as a service), connect to it and be charged for it. When all the different roles are connected and set up, it is essential that the CSP monitors API exposure and ensures compliance with the agreed access KPIs as well as recording all transactions related to monetization, logging and security.

Service monetization

Several functions in the BSS/OSS domain are responsible for managing the commercial aspects of service exposure, covering a variety of business processes in the areas of product and service design, party management and core commerce, as shown in the middle of Figure 2. Together, these functions enable the onboarding of the service APIs as commercial assets into the product and service catalog. They also manage the parties engaged in API exposure and consumption, register the applications operated by customers or partners as API invokers and bill for the API invocations (or alternatively, for the assets that the API invocations create and life-cycle manage).

The service and resource management functions are responsible for orchestrating the exposed services and for monitoring service operation, which includes providing information about service behavior to Service Level Agreement (SLA) management. The core commerce functions integrated into the service exposure domain are service monetization responsibilities and must support various business models.

Figure 3 illustrates two different use cases that demonstrate the need for maximal flexibility regarding business models and monetization approaches.

In the upper use case, the operator of a booking application wants to improve app responsiveness for small data packages. The operator engages the services of an aggregator to trigger a Quality of Service (QoS) boost API that a CSP provides. The aggregator has API contracts with multiple CSPs and can therefore offer the QoS boost service across several (or all) of them. In this scenario, the CSP only has a business relationship with the aggregator. The API invocation will be monetized based on this relationship alone.

The lower use case in Figure 3 has a slightly more complicated setup. In this case, the sales partner of one or multiple CSPs operates a portal where consumers can buy subscriptions from CSPs. The sales partner interacts with the CSPs directly or through an aggregator. In this scenario, the CSPs must be able to support different monetization models so that, for example, both the sales partner and the aggregator can receive compensation for new subscriptions. It may also be the case that the aggregator or sales partner pays a fee to the CSP to make the subscription management service available and scalable.

Successful service monetization will require a high degree of flexibility in terms of supporting different business models related to API consumption. To illustrate this point in a slightly different way, Figure 4 provides three examples of how a CSP can monetize service APIs through different kinds of relationships – that is, with the enterprise operating the application, with the application service provider or with an API aggregator. Another possibility is that application service providers and API aggregators may not pay for API access at all, but rather act as catalyzers of new enterprise and consumer business for CSPs. In this scenario, they would likely strive for a business model in which they receive compensation for facilitating subscriptions or add-on sales.

Service implementation

To meet the requirements of the enterprise ecosystem, service implementation must:

• Comply with open API standards
• Hide telco complexity by focusing on a use case and exposing specialized REST (representational state transfer) resources
• Orchestrate native telco functions southbound
• Comply to cloud-native standards that are micro-service based, modular and configurable to allow adaptation to different customer and market needs
• Use a development toolset that makes it possible to build services that can be natively integrated into the service exposure platform
• Support stateful and stateless services
• Provide duplicate detection for requests
• Support synchronous and asynchronous communication patterns towards the API invoker
• Have the ability to scale from handling low-traffic, high-value operations (such as a customer onboarding or refill request) to handling high-volume traffic (such as event streaming).

Exposed services must also seamlessly integrate with supporting functions such as access control, consent management, reporting, monetization and so on that service exposure platforms provide.

The list of service APIs that expose CSP network capabilities will expand over time as the need for new management and orchestration services continues to grow. The BSS/OSS domains in particular must support a service scope that addresses the most important management and orchestration needs of enterprises. These include:

• Connectivity service management and device connectivity management
• Edge application hosting, onboarding and registration
• Connectivity service quality monitoring and predictions
• Customer experience quality monitoring and predictions
• Services related to customer management supporting business-to-consumer, business-to-business and business-to-business-to-anything (B2B2X) models
• Services related to partner management
• Services related to carrier billing, cost control and sponsoring
• Advanced services for exposing network insights.

The network service for connectivity service management is intended to be used by enterprises and partners (on behalf of their enterprise customers) to browse for available offerings for connectivity services by indicating their traffic needs as a filter mechanism. They can then order a suitable connectivity service offering, personalize it with some limited parameters and read up on the installed base. The available connectivity service offerings will be based on preconfigured service templates with limited options for parametrization.

The service for connectivity service management needs to work together with a peer service for device connectivity management that will onboard device subscriptions onto the connectivity service sold to an enterprise. After onboarding, the devices will be able to send their traffic on the new connectivity service. Onboarding will occur as the result of the sale of an access offering that refers to the target connectivity service.

Edge capabilities that optimize latency, security and reliability make it possible to bring services closer to the consumer. BSS and OSS need to support both CSP-owned and edge locations, so that services can be placed at the optimal location, connected to the customer, monitored and charged throughout the service life cycle. The CSP needs to expose capabilities for the application developer to upload their application or request infrastructure as a service with the requested SLA, to monitor resources and to influence their behavior if needed.

The importance of quality monitoring the delivered connectivity services and associated device connectivity sold to enterprises cannot be overstated. This information must be exposed to the customers to allow for service-quality verification as well as life-cycle management. Service-quality predictions are needed for service planning, including runtime distribution of applications.

With regard to services related to customer management, in the example of private networks, party management and resource management are involved in the B2B2X processes. These enterprises must be given the rights to life-cycle-manage their own subscribers. Enterprises that are using a private network also need to have the management of resources such as SIM/eSIM/iSIM cards delegated to them.

Services related to partner management, cost control and sponsoring are also important to consider. Partner management services make it easy to establish partnerships and manage partner offerings, which will enrich the CSP’s portfolio. Sponsoring scenarios are popular for venues, sports sites, campus sites and company premises. A cost control service makes it possible to sponsor the connectivity of a user under certain conditions, such as when the user purchases goods, agrees to receive advertisements or participates in surveys. Carrier billing enables the use of a mobile pre- or post-paid wallet as a new payment mechanism.

Advanced services for exposing network insights can also add significant value for an enterprise. Radio coverage maps and user density maps are good examples of these kinds of services.

Conclusion

Service exposure represents a significant business opportunity for communication service providers (CSPs) to generate value beyond connectivity in the digital ecosystem. The first step toward success in this space is to make it as easy as possible for enterprise application developers to access and consume service application programming interfaces (APIs). The second step is of equal importance: CSPs’ service exposure solutions must address the need for monetization across the whole ecosystem. Different stakeholders will be engaged in making the APIs available to the ecosystem, depending on the specific use case involved. In light of this, CSPs must provide flexible support for business models ranging from direct business relationships between the CSP and the API consumer to indirect ones facilitated by aggregators and service platforms.

Ericsson is committed to bringing together the perspectives of stakeholders across the value chain to ensure the delivery of market-leading solutions in this area. It is already clear that service exposure platforms will need to be integrated into the service API monetization architecture and support automation of the different business processes related to API invoker registration, API consumption and API monetization. The approach to service monetization that we have presented in this article addresses the commercial aspects of the whole life cycle of a service API, from the moment it is made available for consumption to the billing and settlement processes.