Enabling seamless OSS/BSS for service exposure business opportunities
- To capitalize on the business opportunities created by service exposure and facilitate the monetization of services, CSPs are beneficial of upgrading their IT systems.
- This requires tight and seamless integration of OSS and BSS to work with partners and enterprises for end-to-end (E2E) service creation and monetization.
Exposing application programming interfaces (APIs) presents a business opportunity for communication service providers (CSPs) who wish to engage their business partners and enterprise customers in the creation and provision of new services. To fully leverage the new capabilities of the network and support industry verticals, APIs are a must for solution integration and interaction.
|
Source: https://www.precedenceresearch.com
To make API exposure a sustainable and scalable business that provides a relevant contribution to the digital economy, there are strong functional requirements at different levels that must be met. These requirements are not only for the APIs themselves, but also for the mechanism of exposure and the business models between API providers and API consumers.
Service exposure landscape
While it’s a highly simplified view, the service exposure landscape can be visualized through a layered architecture approach. The following figure 1 illustrates this layered architecture, in which CSPs expose the capabilities of their connectivity network. Information assets, as well as commercial and operational management services, are exposed either directly to enterprises (the respective enterprise application developers) or by making the APIs available through business partner offering marketplaces or by aggregator functionalities.
This architecture treats the network, including the CSP's IT environment, as a black box, which provides APIs that can be easily integrated with applications. The different domains, be it BSS, OSS, RAN or the core network, expose their native services, sometimes directly but preferably through easy-to-use service APIs that are available in the service exposure layer. These service APIs can then be directly consumed by enterprise applications, supporting scenarios where enterprises interact in a geographically confined environment with one CSP only. More commonly, the service aggregators and API brokers will consume the service APIs and make them available to enterprise application developers and other developer communities. A third model for providing APIs to enterprises is being envisioned, which is based on API federation among CSPs – this GSMA Open Gateway, which was announced at MWC Barcelona 2023, is still in the process of being designed and developed.
Figure 1: Service exposure architecture
In the diagram we can see that the network capability and data management APIs are complemented by commercial and operational management interfaces, supporting the full integration and automation of the network and data service’s complete lifecycle management.
Ericsson’s approach to API exposure
Ericsson’s approach to API exposure enables enterprises to manage their own connectivity needs and build applications that leverage network characteristics and network assets by providing different building blocks in the layered architecture described above. Ericsson's API exposure approach enables enterprises to manage their connectivity needs and build applications that leverage network characteristics and assets by providing different building blocks in the layered architecture described above.
Ericsson achieves this by providing:
- Service API implementations with needed backend support
- Blocks for service exposure including operational management
- Core commerce functionalities for service exposure monetization
- Ericsson’s global network platform (GNP) program that works together with the communication platform Vonage (an Ericsson company) to provide APIs to the digital economy based on CSP API aggregation
Attracting developers with harmonized and standardized service APIs
When examining the service APIs in more detail, it becomes immediately apparent that the exposed APIs must have the appropriate scope, be harmonized as much as possible and preferably be standardized across CSPs. They also need to be easily accessible to attract developers.
In 2022, the Telco Global API alliance was founded, later renamed to CAMARA. CAMARA is a broad industry cooperation consisting of CSPs, ISVs, device manufacturers, and hyper cloud providers, among others. Its purpose is to define the service APIs for an open ecosystem through open-source implementations. CAMARA is working on an abstraction API architecture and harmonizing the capability APIs exposed from CSP networks to developers, either directly or through aggregators.
APIs made available to developers must support E2E use cases. 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 must support a service scope that addresses the most important management and orchestration needs of enterprises. These include:
- Connectivity service management (NW slice 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 cost control and sponsoring
- Services that allow to import external charges
- Support services such as authentication, subscription and eligibility checks, consent handling and more.
All of the services listed above demand a tight and seamless integration of OSS services to BSS services to support the E2E business processes for service and resource management for the full lifecycle from creation, over service in production to retirement. Exposing APIs for management and orchestration to enable automated service and resource management via enterprise management applications is crucial, but it’s not the only demand on OSS and BSS.
Only some of the services listed above are in the scope of CAMARA and its standardization activities today. TM Forum has lately decided to collaborate with CAMARA and engage in driving the definition of simplified APIs which complement the CAMARA scope.
Evolving OSS/BSS with API exposure building blocks
Making APIs available for external consumption is subject to the service exposure layer, as shown on the architecture figure 2. The service exposure layer can be broken down into three layers: the service implementation, the management functions supporting the API exposure and the gateway function on top.
Figure 2: API layer building blocks
The service implementation consists of a processing layer that hosts the business logic and orchestrates adapters. These adapters are responsible for the southbound interfaces towards in-house resources, as well as services provided by partners and suppliers. BSS plays an important role in managing the commercial aspects of these relations.
The processing logic converts the service format to match the requirements on the exposed APIs. The processing range varies from simple filters to more complex translation and aggregation functions for determining what to expose. Finally, there are also orchestration functions to handle services that require coordination across multiple resources, such as transaction handling.
On the top we have the exposure/gateway layer, which is responsible for making the APIs visible and accessible externally. This layer also supports security, monitoring, monetization, privacy requirements and more.
API monetization
CSPs that want to support industrial applications need to have both the technical ability to expose APIs and the administrative ability to support emerging business models (monetization). The latter requires CSPs to evolve their OSS & BSS systems to support automated service and resource management, as well as core commerce systems that enable flexible monetization models for API consumption.
Equally important is the requirement to support all stakeholders in the API value chain, be it consumers, business customers or business partners. This is the prerequisite for API monetization. Consequently, either the existing core commerce systems need to be extended, or a new, slim BSS stack for API monetization that supports different business models compared to traditional CSP business models must be implemented.
All APIs for external consumption must be onboarded onto the service exposure platform and made visible as commercial artefacts in the BSS system, allowing them to be modeled as sellable entities.
API consumers and their applications, the API invokers, must be onboarded onto both the BSS system and exposure platform. The service exposure platform will take care of authenticating and authorizing an API invoker, delivering the API service to the invoker and reporting on the API consumption.
The BSS system will leverage the API consumption report and take care of API monetization.
GSMA’s Open Gateway initiative aims to create a federation of APIs between CSPs, beginning with a subset of Camara APIs. This requires the BSS to manage federation needs, including API routing to the appropriate CSP destination, contract management, revenue sharing, fraud prevention and security.
The example below illustrates a potential business model in which an API aggregator offers APIs to application service providers and, in turn, purchases API access from the CSP. The CSP will charge the API aggregator based on API consumption or based on the "result" generated by the API invocation using different models.
Figure 3: Potential business model for API aggregator
Scale into the digital ecosystem with open, unified easy-to-use APIs
Enabling APIs for the digital economy needs more than API exposure from a single CSP. Developers want APIs to work across as many CSPs as possible while having easy access to APIs without the need to interact with each CSP acting as API provider individually. This brings CSPs business partners, especially Vonage into the picture. Vonage acts as API aggregator securing global, open, unified, and easy-to-use APIs for application service providers (ASP) and enterprises northbound. For the CSPs, Vonage provides a simplified Go-to-Market for the CSP’s API business.
The service APIs on Vonage roadmap began with the exposure of selected network capabilities, such as services to request quality on demand or report device location, but are already expanding to include enhanced security services. These services rely on CSPs' information assets regarding mobile identities and subscriptions, as well as quality evaluation, experience management, and enterprise networking. These information assets and related service exposure capabilities are critical for enterprise applications and must be enabled by CSPs' BSS and OSS systems.
Mobile identity management helps improve security in the private sector, such as for private financial and core commerce transactions, as well as in the changed work economy, where white-collar work is no longer limited to enterprise premises but can be done from anywhere, such as a home office or an airport. The mobile identities and associated data managed by CSPs as highly trusted partners are critical information assets.
Service management APIs like quality monitoring and experience management are further examples highlighting the importance of the CSP’s OSS and BSS systems for service exposure. As classified by Camara, these APIs allow developers to manage and get data about offered services, for example checking service availability or getting hold of performance information.
To make service exposure happen, BSS and OSS are key. BSS and OSS functions are engaged in four different areas:
- Exposing service APIs and service management APIs
- Supporting the API exposure process with API exposure management and orchestration
- Providing core commerce integration for selling API access
- Enabling API monetization and the relationship with enterprises and aggregators.
To delve deeper into this topic, explore our technical report monetizing API exposure for enterprises with evolved BSS.
Read more about:
Explore our OSS/BSS solutions
Explore our OSS/BSS services
core commerce for superior telecom customer experiences
Network Exposure - Enable 5G Innovation
Edge exposure: Service & API exposure at the edge
Ericsson’s global network platform
Vonage - an Ericsson company