3GPP 5G Core APIs
OpenAPIs for the Service-Based Architecture (SBA)
Core network as a Service. The fifth generation of mobile networks defined by 3GPP, has not only introduced 5G NR (New Radio), but has also brought in a new core network relying on an open and modular service platform: the Service-Based Architecture (SBA). SBA provides a cloud-native service framework in which mobile core network functionalities (authentication, mobility management, etc.) are supported by Network Functions (NFs), self-contained software applications that can be run on commercial off-the-shelf hardware hosted by cloud infrastructure. Interconnected on a logically shared infrastructure or service bus, NFs offer services accessible to any other authorized NF through APIs (Application Programming Interfaces) named service-based interfaces (SBI). Services exposed by an NF (service producer) to another NF (service consumer) are described using API specifications that identify the set of accessible service data and indicate the authorized operations on these service data. In this service platform, every NF can expose services and consume services provided by other NF. Since NFs are loosely coupled and interfaced with APIs, they can be easily deployed anywhere, on demand, without impact on the existing ones. New services or service instances are published in a centralized repository – the Network Repository Function (NRF) – accessible to all the NFs to discover the services available in the network and retrieve required routing information to interact with the NFs supporting the services.These services can also be made open to third-party applications through a dedicated NF, the Network Exposure Function (NEF). The NEF exposes secured APIs to external or internal applications for a robust but easy access to the core network services and capabilities supported by the NFs.The adoption of the SBA with APIs exposing services has contributed to migrate the mobile core network, traditionally conceived as a walled garden relying on telco-specific point-to-point protocols (e.g., Diameter), to a scalable, resilient and extensible service-oriented environment, more open to third-party developers and vertical industries for the creation of on-demand tailored services.
Design principles and documentation guidelines for 3GPP RESTful APIs. In order to speed up and ease the development of new APIs while ensuring reusability and interworking with existing ones, 3GPP has specified in 3GPP TS 29.501 a set of design principles and documentation guidelines for the specifications of the APIs used over SBIs. This set of recommendations is not restricted to SBIs but is also pertinent for any API defined by 3GPP, including northbound APIs, APIs used for 3rd party exposure, management/orchestration, charging or media streaming. The aim of 3GPP TS 29.501 is to provide an overall consistency at the 3GPP level for the design and description of the different APIs.The main principle for the design of 3GPP API can be simply summarized as follows: API should be designed as RESTful API whenever possible.REST (REpresentational State Transfer) is an architectural style that imposes certain guiding principles (or constraints) to be satisfied by an API to be referred to as RESTful API. In short, the underlying server implementation is hidden by a layer of abstraction: service data are defined as "resource" uniquely identified by URI (Uniform Resource Identifier) and service consumers use HTTP methods to access to only a representation of resources. The representation can be delivered over HTTP using different file formats, JSON being the most popular one.For basic Create, Read, Update, and Delete (CRUD) operations on resource/service data, standard HTTP/2 methods (e.g. GET, POST, PUT, DELETE) are used to operate on resources uniquely identified by URIs.The recommendation for the design of RESTful API is not blindly enforced as a dogma. When the REST model is not applicable (e.g. for non-CRUD operations), service operations can be however implemented as custom operations. Instead of operating on a resource, a POST operation can be used to call a specific function to execute in the NF service provider and the result of the function is provided to the NF service consumer in the response. And of course, depending on the service requirements, it is possible to mix REST-style operations and custom operations in the same API.Along the recommendation for the design of RESTful API, 3GPP TS 29.501 also documents recommended best practices for API designers.
API description exposure through OpenAPI specification. 3GPP selected OpenAPI version 3 (formerly known as Swagger) as the formal language to be used for the definition of APIs in the Service-Based Architecture.As indicated in 3GPP TS 29.501, each API is documented in a 3GPP technical specification (TS) that describes in natural language the API, and this specification also includes a normative Annex containing an OpenAPI description of the API.An OpenAPI description defines a standard, programming language-agnostic interface specification for HTTP APIs, which allows both humans and computers to discover and understand how an API works without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.The OpenAPI document provides an easy description of the API, including:
Storage of OpenAPI specification files in 3GPP Forge. Today, over 200 OpenAPI specifications are stored in the 3GPP Forge. And many more are still to come with the development of new services in the forthcoming releases.OpenAPI descriptions are extracted from the annex of the 3GPP Technical Specifications and made available as stand-alone YAML files, identified by a file name composed of the API name prefixed by the TS number of the specification containing the OpenAPI description. All these files are then stored in a common repository managed by Gitlab on the 3GPP Forge, a web-based collaborative software platform managed by 3GPP for both developing and sharing applications.
Core network as a Service. The fifth generation of mobile networks defined by 3GPP, has not only introduced 5G NR (New Radio), but has also brought in a new core network relying on an open and modular service platform: the Service-Based Architecture (SBA). SBA provides a cloud-native service framework in which mobile core network functionalities (authentication, mobility management, etc.) are supported by Network Functions (NFs), self-contained software applications that can be run on commercial off-the-shelf hardware hosted by cloud infrastructure. Interconnected on a logically shared infrastructure or service bus, NFs offer services accessible to any other authorized NF through APIs (Application Programming Interfaces) named service-based interfaces (SBI). Services exposed by an NF (service producer) to another NF (service consumer) are described using API specifications that identify the set of accessible service data and indicate the authorized operations on these service data. In this service platform, every NF can expose services and consume services provided by other NF. Since NFs are loosely coupled and interfaced with APIs, they can be easily deployed anywhere, on demand, without impact on the existing ones. New services or service instances are published in a centralized repository – the Network Repository Function (NRF) – accessible to all the NFs to discover the services available in the network and retrieve required routing information to interact with the NFs supporting the services.These services can also be made open to third-party applications through a dedicated NF, the Network Exposure Function (NEF). The NEF exposes secured APIs to external or internal applications for a robust but easy access to the core network services and capabilities supported by the NFs.The adoption of the SBA with APIs exposing services has contributed to migrate the mobile core network, traditionally conceived as a walled garden relying on telco-specific point-to-point protocols (e.g., Diameter), to a scalable, resilient and extensible service-oriented environment, more open to third-party developers and vertical industries for the creation of on-demand tailored services.
Design principles and documentation guidelines for 3GPP RESTful APIs. In order to speed up and ease the development of new APIs while ensuring reusability and interworking with existing ones, 3GPP has specified in 3GPP TS 29.501 a set of design principles and documentation guidelines for the specifications of the APIs used over SBIs. This set of recommendations is not restricted to SBIs but is also pertinent for any API defined by 3GPP, including northbound APIs, APIs used for 3rd party exposure, management/orchestration, charging or media streaming. The aim of 3GPP TS 29.501 is to provide an overall consistency at the 3GPP level for the design and description of the different APIs.The main principle for the design of 3GPP API can be simply summarized as follows: API should be designed as RESTful API whenever possible.REST (REpresentational State Transfer) is an architectural style that imposes certain guiding principles (or constraints) to be satisfied by an API to be referred to as RESTful API. In short, the underlying server implementation is hidden by a layer of abstraction: service data are defined as "resource" uniquely identified by URI (Uniform Resource Identifier) and service consumers use HTTP methods to access to only a representation of resources. The representation can be delivered over HTTP using different file formats, JSON being the most popular one.For basic Create, Read, Update, and Delete (CRUD) operations on resource/service data, standard HTTP/2 methods (e.g. GET, POST, PUT, DELETE) are used to operate on resources uniquely identified by URIs.The recommendation for the design of RESTful API is not blindly enforced as a dogma. When the REST model is not applicable (e.g. for non-CRUD operations), service operations can be however implemented as custom operations. Instead of operating on a resource, a POST operation can be used to call a specific function to execute in the NF service provider and the result of the function is provided to the NF service consumer in the response. And of course, depending on the service requirements, it is possible to mix REST-style operations and custom operations in the same API.Along the recommendation for the design of RESTful API, 3GPP TS 29.501 also documents recommended best practices for API designers.
API description exposure through OpenAPI specification. 3GPP selected OpenAPI version 3 (formerly known as Swagger) as the formal language to be used for the definition of APIs in the Service-Based Architecture.As indicated in 3GPP TS 29.501, each API is documented in a 3GPP technical specification (TS) that describes in natural language the API, and this specification also includes a normative Annex containing an OpenAPI description of the API.An OpenAPI description defines a standard, programming language-agnostic interface specification for HTTP APIs, which allows both humans and computers to discover and understand how an API works without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.The OpenAPI document provides an easy description of the API, including:
- available resources and authorized operations on each resource
- operation parameters Input and output for each operation
- authentication methods
- contact information, license, terms of use and other information.
Storage of OpenAPI specification files in 3GPP Forge. Today, over 200 OpenAPI specifications are stored in the 3GPP Forge. And many more are still to come with the development of new services in the forthcoming releases.OpenAPI descriptions are extracted from the annex of the 3GPP Technical Specifications and made available as stand-alone YAML files, identified by a file name composed of the API name prefixed by the TS number of the specification containing the OpenAPI description. All these files are then stored in a common repository managed by Gitlab on the 3GPP Forge, a web-based collaborative software platform managed by 3GPP for both developing and sharing applications.
OpenAPI Specification files Release 18.
Northbound and Application Layer APIs
5G Media Streaming (5GMS) TS 26.512
3GPP SA5 models and MnS OpenAPI definitions
- NRF (NF Repository Function)
- LMF (Location Management Function)
- AMF (Access and Mobility Management Function)
- SMF (Session Management Function)
- MB-SMF (Multicast/Broadcast Session Management Function)
- MBSF (Multicast/Broadcast Service Function)
- MBSTF (Multicast/Broadcast Service Transport Function)
- MB (Multicast/Broadcast) User Services
- UDM (Unified Data Management)
- UDSF (Unstructured Data Storage Function)
- AUSF (Authentication Server Function)
- NSSAAF (Network Slice-Specific and SNPN Authentication and Authorization Function)
- NSSF (Network Slice Selection Function)
- SMSF (SMS Function)
- NEF (Network Exposure Function)
- PCF (Policy Control Function)
- BSF (Binding Support Function)
- NWDAF (Network Data Analytics Function)
- UPF (User Plane Function)
- HSS (Home Subscriber Server)
- GBA BSF (GBA Bootstrapping Server Function)
- SOR-AF (Steering of Roaming Application Function)
- SP-AF (Secured Packet Application Function)
- AF (Application Function)
- CHF (Charging Function)
Northbound and Application Layer APIs
- CAPIF (Common API Framework)
- SCEF (Service Capability Exposure Function)
- NEF (Network Exposure Function)
- VAE (V2X Application Enabler)
- SEAL (Service Enabler Architecture Layer)
- EDGEAPP (Enabling Edge Applications)
- UAS Application Enabler (UAE) Server
- 5GMARCH (Enabling MSGin5G Service)
- PINAPP (Personal IoT Network Application)
5G Media Streaming (5GMS) TS 26.512
- Provisioning (M1)
- Media Session Handling (M5)
- Service Access Information
- Consumption Reporting
- Data Reporting
- Event Exposure
3GPP SA5 models and MnS OpenAPI definitions
- Network Resource Models (NRM)
- Management Services (MnS)
A summary of 5G Core Rel-17 NFs and their services
5G's Web-scale architecture and the OpenAPI paradigm shiftA critical aspect of 3GPP 5G is the shift towards a scale-out, cloud-native architecture for the 5G Core (5GC). This new architectural approach promises to meet the dynamic demands of modern telco networks and services. Key architectural principles. The scale-out architecture in 5G Core is a departure from traditional, centralized network structures. It emphasizes horizontal scaling, where network capacity is increased by connecting multiple hardware or software components, allowing for more flexible and scalable network management. 3GPP's 5G Core adopts a service-based architecture (SBA), where network functions (NFs) are modular and communicate through well-defined interfaces, allowing for more granular control and customization of network capabilities.5GC OpenAPI and its role. 3GPP standardized over 200 publicly available OpenAPIs in 5GC that allow developers to programmatically access 5G network functionalities. These APIs are crucial for enabling third-party innovation, ensuring interoperability between different vendors’ equipment, and facilitating network automation and orchestration. These services can also be made open to third-party applications through a dedicated NF, the Network Exposure Function (NEF). The NEF exposes secured APIs to external or internal applications for a robust but easy access to the core network services and capabilities supported by the NFs. All these files are then stored in a 3GPP public repository managed by Gitlab on the 3GPP Forge (https://lnkd.in/e7FVPJpv), a web-based collaborative software platform managed by 3GPP for both developing and sharing applications.O-RAN SMO & RIC. O-RAN ALLIANCE has developed the SMO and RIC platform to apply automation at scale, thereby simplifying network complexities, improving network performance, and minimizing RAN operational costs. This platform oversees all orchestration, management, and automation aspects of RAN elements and supports various open interfaces like O1, A1, and O2 and associated OpenAPIs that facilitate interaction between management entities and O-RAN managed elements.TMForum TMF 909. TMF 909 is a suite of OpenAPIs by TM Forum aimed at enabling Network as a Service (NaaS) by providing the necessary operations to facilitate interworking between Operational Domains (RAN, Core, etc.) and OSS/BSS applications, or other domains from either a single service provider or from third parties.MEF LSO & NaaS. MEF is known for defining standards for Carrier Ethernet and has been extending its LSO framework to support various NaaS services and associated OpenAPIs.
5G-MAG cross-industry association
5G-MAG Reference tools developer.5g-mag.com
5G CoreNetwork components GitHub Repositories: https://github.com/5G-MAG/Getting-Started/wiki/5G-Core-Network
5G-MAG Reference tools developer.5g-mag.com
- community of developers
- reference implementations
5G CoreNetwork components GitHub Repositories: https://github.com/5G-MAG/Getting-Started/wiki/5G-Core-Network
- 5G Core Service Consumers (rt-5gc-service-consumers)
- UE Data Collection Application Function (rt-5gc-data-collection-application-function)
- 5GC Service consumer libraries & test app
- 5GC Data Collection, Reporting & Event Exposure
