API Management (3scale): The service provider use case

As part of digital transformation, and in anticipation of the 5G evolution, service providers have found it necessary to redesign portions of the network’s layers and components, using cloudification and containerization. 

This approach enables the introduction of new technologies and operation modes to the network — such as microservices, automation, artificial intelligence/machine learning (AI/ML), horizontal, open architectures, and more. However, the delivery of new and expanded capability to customers needs to be integrated with legacy systems, and with a perspective of looking forward.  

Apps that provide demonstrated value to existing and future technology investments rely on application programming interfaces (APIs), which enable a standard method for platform-wide integration, without having to rebuild it every time something new is introduced. Even with the use of API standards, implementing and managing API integrations can be challenging, even when used in open architecture deployments.

The role of open architectures — benefits and considerations

The objective of open architectures is to enable multiple vendors to coexist within one network, from the data center to the edge, enabling service providers to establish an ecosystem for APIs on top of their 5G network. This facilitates data aggregation from modern sources, such as IoT devices, connected cars, radio access networks (RAN), private networks, consumers, MEC, etc.

However, using an open architecture can lead to management and supervision complexity as each vendor may retain its own set of management tools, which can even differ between products and versions. Due to this potential for limitless combinations, the industry sees the need for an end-to-end API management solution at scale consisting of distinct components, including a gateway to handle the API data streams and a manager to authenticate, authorize, manage, monitor and even monetize the API calls and endpoints over the network, all with greater security functionality.

Prior to 5G implementation, there wasn’t an existing standard API gateway in the telco network which could be used by third-party applications or external functions, leaving the operator to process each API separately.

API management in 5G architecture

As part of 5G Service Based Architecture (SBA), 3GPP defines an HTTP-based API bus (SBI- Service Based Interface), for application functions (AF) API communications, the location where multifunction and multivendor APIs coexist. It also specifies a Network Exposure Function (NEF), serving the purpose of exposing some of the APIs back to the network.

5G SBA diagram  (credit: Cisco)

The NEF’s role is to securely expose the AF’s network services and capabilities using HTTP API towards the network (application function northbound interface), to be utilized by third-party applications and developers. NEF exposes such functionalities as monitoring capability, provisioning capability, application influence, or Policy/Charging capability.

However, the NEF requirement is specified in terms of the APIs it exposes (3GPP TS 23.502 4.15.2), providing a predefined set of APIs exposed to external functions.

Over time, (TS 23.222), 3GPP specified a requirement for a common API framework (CAPIF).

CAPIF is divided into main three types of operations: 

1. CAPIF core

2. API invokers

3. API exposure (exposing publishing and management functions)

A. CAPIF core function

The CAPIF core function consists of the following capabilities:

• Authorization and authentication of the API invoker

• Onboarding / offboarding of API invoker

• Publishing, storing and supporting the discovery of service APIs information

• Policy-based access control for service APIs 

• Monitoring the API service queries

• Log store, log audit and log query service for service API log invocations

• Charging based on the logs of the service API invocations

• Inter-CAPIF core functions communications

B. API invoker

The API invoker is typically provided by an application provider, and it can reside within or outside of a trust domain.

It supports the following capabilities:

• Maintain identity information for authentication

• Mutual authentication with CAPIF

• Obtaining the authorization prior to accessing the service API

• Discovering service APIs information and invoking the service APIs

C. API exposing function

The communication point of the service API and the API invoker consists of the following capabilities associated with authentication and validation (based on identity data from the CAPIF core function) :

• API publishing function — publishes the service API information of the API provider to the CAPIF core function

• API management function — enables the API provider (an AF) to perform administration of the service APIs, and consists of the following capabilities:

  • Auditing of service API logs (from CAPIF core)

  • Monitoring CAPIF events and service API status

  • Providing API provider policies to the CAPIF core function

  • Onboarding / offboarding of API invoker

  • API provider domain information registration on CAPIF core

• API Provider Domain — consists of the API management function, API exposing function, and API publishing function, and serves AF’s API within the same domain 

The standard differentiates the API communications between the invokers and CAPIF components (core and API management), and internal communication between the CAPIF components, which is beyond the scope of this document.

A high-level basic architecture of CAPIF

There can be multiple co-located CAPIF core functions and API provider domains within one network trust domain.

Red Hat’s proposed solution for API management at scale while preserving the flexibility of an open architecture

Red Hat API management is based on the 3scale enterprise API management product. 

It is a modular API infrastructure solution that provides authentication, governance, security, analytics, automated documentation, developer portals and monetization for API services.

Red Hat integration stack (including Red Hat 3scale) 

3scale can be installed on Red Hat OpenShift as an operator, or by using a YAML template. 

It can run on podman, docker, on-prem, or on public clouds (managed / non-managed service).

Red Hat provides a managed OpenShift API management service for developers (based on 3scale) for Red Hat OpenShift Service on AWS (ROSA) and OpenShift Dedicated (OSD).

Architecture

As a modular solution, 3scale provides a high level of freedom to customers to decide which underlying components to use (databases, ActiveDocs, branded developer portals and more).

3scale high-level architecture (by component)

API manager — In charge of security and authentication, access control, API lifecycle management, version control, documentation, monitoring, provisioning, alerting, metering and billing, policy and developer/admin portal policies.

The API manager uses several databases in order to store and manage API requests and data:

• System-mysql / system-postgres / Oracle — storage of all data managed via Admin/Dev Portal, CMS 

• system-redis / redis cluster — temporary storage for background jobs for API Manager

• backend-redis / redis cluster — statistics storage, temporary job storage

• zync-database — securely syncs (one way) 3scale with IDPs (Identity Provider system)

API gateway — basically an NGINX web server, responsible for enforcing the API policies that are defined in the API manager. It consults the API Manager on incoming calls and enforces the policies, either returning an error or proxying the API call to the customer’s API backend.

API gateways are configured using the API Manager admin portal.

Closing remarks and more information

In order to achieve a 5G ecosystem for APIs using CAPIF, adding new functionalities and revenue streams using 5G networks, API management solutions should be embedded into the 5G architecture, or at least have well-defined interfaces with the current architecture.

Currently, we don’t yet see movement in the market from using only NEF to an API-rich ecosystem using CAPIF, and this transition will require API management product vendors to partner with 5G solution vendors, including feature and performance integrations and adjustments.

As described, Red Hat provides API Management by 3scale, on top of Red Hat OpenShift or on a stand-alone basis.

Explore a full overview of Red Hat’s API management solution portfolio from a development and implementation perspective, and learn about Red Hat’s 3scale API Management products.

Additionally, we invite 5G vendors to collaborate with Red Hat via the Red Hat Telco ecosystem.