Experimentation of end-to-end telco services through a Service Portal operating on an ONAP orchestrator

The infrastructure used by network operators to deliver services to users at the edge of the network is evolving towards a Cloud-native one. As a consequence, end-to-end services are implemented as chains of PNFs and VNFs and an automated process is required to manage their lifecycle. The Open Network Automation Platform (ONAP) project is one of the available alternatives allowing to manage this kind of services, providing service design, creation, KPI monitoring and control loop capabilities. In order to help Communication Service Providers (CSPs) to manage the described infrastructure and all the business operations related to it, the TM Forum organization has standardized a suite of REST based APIs in its Open API program. In particular, service providers' business operations have been split into different categories, each one referring to a different layer of their infrastructure. The Open API program defines a set of REST API specifications to standardize the functionalities to be implemented at each layer and the communication among them. This thesis work focuses on three layers: Resource, Service and Product. Resources, also called Resource Facing Services (RFS) represent the category of services internal to the service provider, which are needed to support a Service at higher layer, i.e. a Customer Facing Service (CFS). Therefore, a CFS represents the commercial view of a service exposed to customers. The ONAP platform is placed at Resource layer, which is also the lowest one. In particular, it is responsible for managing resources located in different Cloud Central Offices (Cloud-COs) and communicates with applications at Service layer through its External APIs component, also called ONAP NBI. ONAP External APIs implementation is based on TM Forum’s REST specifications and allow applications at Service layer to trigger actions on resources (i.e., creation, deletion or modification) by interacting with ONAP in a standard way. This component has been studied, tested and evaluated. For what concerns the Service layer, Service Order Management (SOM) applications can be placed here. An example is Service Resolver developed by Orange, an open source project which has been tested and improved. Service Resolver exposes a set of REST APIs based on TM Forum’s standard. It accepts requests from BSS applications and maps them into requests to be sent to ONAP External APIs component in order to trigger the instantiation process of the resources needed to support the required service. Finally, BSS applications refer to the Product layer and are responsible for mapping customer requests into requests to be sent to SOM applications. The work performed at this layer regards the implementation of a BSS application called Service Portal, composed by a GUI from which customers can order the desired product and a backend component sending requests to Service Resolver, allowing it to instantiate the service which corresponds to the product purchased by the customer. The chain of functionalities implemented in the three described layers realises the steps required by service providers to instantiate end-to-end services according to customers requests. In conclusion, the purpose of this thesis is to provide a complete analysis of this process with details on how it has to be implemented at each layer, thanks to the contribution given to Service Resolver project and the development of Service Portal.