6GSMART-ICC: Building MNS (Minsait NaaS System)

Network-as-a-Service (NaaS) represents a paradigm shift whereby network operators can make telco capabilities from public networks available for external consumption, including monitoring and configuration-related capabilities, through Application Programming Interface (APIs). These APIs pave the way for transforming telco networks into programmable service platforms that 3rd parties can easily access. NaaS enables these 3rd parties to integrate their applications into the network, with open and direct interactions between them, tapping into newly exposed capabilities to provide enhanced user experience and contribute to the digital ecosystem with new services. In 6GSMART-ICC, we have developed a fully functional NaaS system following the guidelines indicated by the GSMA Open Gateway initiative. Specifically, an Exposure Gateway has been implemented with the following architecture: The developed exposure Gateway contains: a publisher portal used by the MNOs to publish APIs exposed to the applications; a developer portal from where application developers subscribe to the use of APIs; an OAth 2.0 authorisation server; an API gateway; an API registry; and a database to store exposed APIs, subscriptions, and credentials.

Exposure Gateway Implementation

The publisher and developer portals have been implemented with the same application, assigning different roles to publishers and developers. All application functionality is exposed through open APIs (OAS). Specifically, three APIs have been exposed:

• naas-publishers.yaml: This API allows the registration/query/modification/deletion of publishers, as well as the registration/query/modification/deletion of APIs to be published.
• naas-develorpers.yaml: This API allows the registration/query/modification/deletion of developers, as well as the registration/query/modification/deletion of API subscriptions by developers.
• naas-catalog.yaml: This API allows querying the APIs that are available to be subscribed to by developers.

The application has three profiles: Publisher, Developer and Administrator. The following figure shows how the developer portal looks like. API Gateway: The Spring Cloud Gateway component has been selected as the API Gateway. It allows the dynamic obtainment of APIs to be exposed with its Discovery Client function. Cloud Gateway allows the use of the OAuth Resource Server functionality, so that exposed APIs are protected and can only be accessed if requests have an access token with the necessary scope to access each API. On the other hand, the Discovery Client function allows the Gateway to consult different registries where APIs can be published. OAuth 2.0 Authorization Server: To implement this component, the Spring Authorization Server functionality has been used directly. Spring Authorization Server is built on top of Spring Security to provide a secure, light-weight, and customizable foundation for building OAuth2 Authorization Server products. This component has been implemented in the same application of the publisher and developer portals. API Registry: Spring Cloud Netflix has been used to implement this component, which allows the generation of both clients to consult the Eureka Netflix service and servers that implement said service.

Transformation Function Implementation

Transformation functions implement the business logic for each API offered by the Exposure Gateway by invoking the operators’ internal APIs. To demonstrate the NaaS system, the Quality on Demand (QoD) transformation function has been used. This transformation function uses the internal ASSessionWithQoS API provided by the 5G core. In our case, Open5gs has been selected as a 5G core implementation. Open5gs does not include the SCEF/NEF component that implements the ASSessionWithQoS API; therefore, an implementation of the SCEF/NEF component has been developed and integrated with the Open5gs PCF. We have used Deutsche Telekom AG’s implementation of the transformation function. This is one of the reference implementations published within the CAMARA project that also uses Spring Boot, so it is relatively easy to verify and modify. It also uses OAuth 2.0 for authentication and supports client credentials flow. Moreover, it uses the internal API of the SCEF/NEF of the Core 5G, and it implements the notifications part of the API. The application has been used with a simple modification to allow it to be registered in the API registry (Eureka Server) used in the project.

Network APIs Implementation (SCEF/NEF)

The CAMARA Quality On-Demand API is implemented through the ASSessionWithQoS API provided by the SCEF/NEF component of Core 5G for mobile network scenarios. Since Open5gs does not have the SCEF/NEF module, it has been necessary to develop this component (using Spring Boot) and implement the ASSessionWithQoS API. Both the “direct” part of the ASSessionWithQoS API, which allows sessions to be managed (create/delete/query), and the notifications part, which allows receiving the end-of-session event from the PCF to inform the transformation function of said event and delete the session from the sessions database, have been implemented. Client Application Implementation In order to evaluate the implementation of the NaaS system, a test application that invokes the Quality On-Demand API has also been developed. This is a simple application developed with Spring Boot on the server side and with static content and javascript on the client side using AJAX to make requests from the Browser. The application has two screens: one of them is used to establish the client credentials data, which is obtained when the developer subscribes to the API. The other is used to invoke the QoS API with a given data flow to improve the QoS.

Validation

The performed validation consists of connecting a user to the 5G network and requesting flows from two different servers. Once the flows are established, one of them will be improved so that the user will obtain a better quality of service for the improved flow. The obtained results are given in the following figure. Once the traffic of one of the flows is prioritized, the traffic is distributed according to the rate reserved for each QoS profile. The flow with an improved profile also has better latency because its packets are treated with higher priority in the queues. Author: Jose Manuel Palacios – Telecommunications Senior Expert, Minsait (an Indra company).