The End-to-End Orchestration (E2e) of Services is achieved when the lifecycle events of network services are managed at the infrastructure level and managed across multiple domains. This customer requires lifecycle orchestration of services across multiple vendor specific OSS/BSS systems.
The Challenge
One of our Communication Service Provider (CSP) customers required E2E Orchestration of Network services across different technology domains, including integration with their external Business system. Since each OSS/BSS system is implemented with its own set of interfaces, there are significant challenges when integrating multiple systems with a common orchestration platform. For this reason, a common API layer is required to handle such patterns.
The Aptira Solution
The key components of the Orchestration platform being developed include:
- Network Functions Virtualisation Orchestrator (NFVO)
- The NFVO is responsible for handling the resource orchestration of Network service modelling using TOSCA across Network Functions Virtualisation Infrastructure (NFVI) domains. NFVO has the visibility of all the South bound components and manages the lifecycle of services at the infrastructure level. I.e. at Virtual IP Multimedia System (VIM) and Software Defined Networking (SDN). However, it doesn’t have information across technology domains. In this customer’s platform, the NFVO is implemented using Cloudify.
- Service Orchestrator (SO)
- The SO handles the E2E orchestration of network services across different technology domains such as Wireline, Radio, Evolved Packet Core, Access Networks by integrating with Product ordering systems, OSS/BSS from different vendors that support different interfaces such as REST, SOAP or any proprietary interfaces. In this customer’s platform the SO is implemented using Cloudify.
The SO and NFVO communicate with each other extensively, but they also must integrate with multiple external systems. By convention, interfaces with OSS/BSS and other service-level systems are called North Bound Interfaces or NBI. Similarly, interfaces with network-level resource management systems such as network elements, WAN SDN controllers and the like are called South bound Interfaces or SI.
Another of the customers’ requirements is that access to some limited parts of system functionality must be available to third parties. They wanted to expose public API’s via an API Portal and allow trusted / qualified third parties to access API documentation and Sandpit environments.
This all leads to a significant number of API’s that are implemented in any orchestration platform. To seamlessly integrate orchestration platform with external systems and expose public API’s in a controlled manner, a common API management layer is required.
An API Management layer mediates between multiple integrated systems that communicate via application calls. Aptira determined that Google Cloud’s Apigee API Platform was the right product to meet these requirements.
Apigee is used as an API gateway in the orchestration platform. In addition to its standard set of features such as API rate limiting, Security handling and API analytics, it comes with rich set of language constructs to create very specialized API transforms to mediate between the API’s of different systems. The NBI in this solution implements standard TM Forum Open APIs. The core of the API layer is implemented using Apigee.
To demonstrate an end-to-end orchestration use case, we simulated an environment where Apigee is integrated with Cloudify (as NFVO) by defining business workflows in Apigee that translate the TMF API calls from North bound systems to NFVI domain specific orchestration API calls. For instance, orchestration of Firewall Service and a core telco vIMS service was demonstrated using a single TMF Service Order and Activation API.
The following APIs were implemented:
- TMF 641 Service Activation and Ordering
- TMF 633 Service Catalog
- TMF 664 Resource Function Activation and Configuration
The Southbound Interfaces of the Service Orchestrator are represented by the Orchestration layer at the NFVi domain (i.e. NFVO) and at the Transport domain (i.e. WAN SDN controller). In order to demonstrate an end-to-end orchestration use case that involves the Transport domain, we setup a WAN topology using asset of OVS switches, integrating Cloudify in the SO layer with a WAN SDN Controller.
The Ordering systems adds details including service level details, SLAs and waypoints in the TMF 641 request to setup a WAN service such as VPN or MPLS service. Apigee, using the workflow mechanism described above, translates the API request to the Orchestration request to the Cloudify in SO layer by adding the required parameters to instantiate a VPN service.
The Result
The result is an API framework that can be extended to develop other complex business use cases so that it not only orchestrates services at the infrastructure level but also makes integration with systems such as product ordering systems seamless.
The Apigee API platform was able to handle both generic API management tasks but also was able to implement deeply specialized telco requirements. This ultimately helps the customer to roll out services faster, meeting their business objectives and allowing them to rapidly adapt to changes in the future.
OTHER APIGEE CASE STUDIES
- Apigee Case Study 1: Apigee Service Orchestration and Integration
- Apigee Case Study 2: Apigee: On Prem Vs SaaS
- Apigee Case Study 3: Apigee Central Logging
- Apigee Case Study 4: Implementing TMF API’s in Apigee
- Apigee Case Study 5: Apigee Generic API Translation