MOOSIA: Technology for One-stop Operation

1. Introduction

The flourishing application programming interface (API) economy and the cloud-first movement motivated us to research and develop capabilities for one-stop operation that will enable service providers to combine and operate networks, clouds, and applications provided by multiple operators, in a unified manner. We have also put forward the concept of MOOSIA^TM*1 that is aimed at achieving a world that makes it easier to put exciting ideas into practice, that is, a world that makes it easier than ever to create, provide, and operate services proposed or planned by enterprises or individuals.

In the business-to-business-to-X (B2B2X) model, companies representing the second B (i.e., service providers) can freely and flexibly combine wholesale services such as networks, clouds, and applications, which are provided by first-B companies (i.e., carriers) in order to provide a collaborative service (referred to from here on simply as service unless otherwise specified) to end users (the ‘X’ in B2B2X) as shown in Fig. 1.

Fig. 1. Overview of MOOSIA in B2B2X model.

In this article, we describe (1) zero-touch network operation and closed-loop technology that evolves operations mainly within first-B companies, (2) application of artificial intelligence (AI) technologies to closed loops, (3) the API orchestrator that is the core of service creation by second-B companies, (4) technology for enhancing the API orchestrator, (5) the API framework that functions as a general system for API specifications, and (6) the future evolution of MOOSIA.

2. Zero-touch network operation and closed-loop technology

Current first-B operators such as large-scale network operators are feeling the pressure of a large workload and heavy use of human resources just to keep their networks functioning 24 hours a day, 365 days a year. It is crucial to reduce the operational workload and shift the work done at night and on weekends to daytime, weekday work in order to reduce operating expenses. Networks are currently operated manually, with some minimal help provided by operations support systems. Skilled engineers are required for decision making and network control to implement recovery when failures occur, and therefore, 24/7 emergency response teams are required, further increasing operation expenses.

Zero-touch network operation is aimed at solving this problem by automating network control. Autonomous network operation, along with the control loop that enables it, is important in achieving this goal, as shown at the bottom left of Fig. 1. This loop involves the following sequence of steps: (1) collect and manage information on the operation status of wholesale services, → (2) analyze the collected information and make decisions, → (3) control wholesale services, → return to (1) and repeat. This process is called a closed loop as defined by TM Forum^*2 (TMF), which is a standardization association related to network operations.

Achieving such a closed loop requires unified network resource information between the collection, decision making, and controlling processes. We have proposed network resource management technology for this purpose. This technology is equipped with configuration and management functions based on generic management targets called entities. In addition, this technology provides an external mechanism for prescribing the characteristics of individual units of equipment and communication protocols as a specification, which is separate from the programs making up the operations support system. This technology also features functions for specifying inter-layer relationships together with these specifications to achieve integrated network management [1].

We are applying this network resource management technology to develop a data collection and usage platform that unifies network configuration data based on a uniform model. This platform collects and stores in common a wide range of data such as network configuration data, alarms, and logs from individual pieces of equipment. The platform transfers the data to Network-AI (NTT’s AI for networks). In addition, integrated control within a first-B operator consists of technology that enables unified management of the virtual and non-virtual network. With integrated control, the above network resource management technology is used to manage network resources and enable uniform orchestration of the existing non-virtual network and the virtualized network (i.e., software-defined networking).

3. Application of AI technologies to MOOSIA

To implement a closed loop, an advanced intelligent process consisting of analysis, prediction, and decision-making must be incorporated into the system. Incorporating the AI technologies described in the article “Creating New Value by Leveraging Network-AI Technology in Service Operations” [2] enables MOOSIA to analyze the massive amount of information accumulated in the data collection and usage platform in order to promptly detect risks such as equipment failure and traffic congestion that might affect service quality. Similarly, when building a service for a second-B company or changing its configuration after a service launch, or when carrying out a primary response to an equipment failure or traffic congestion, MOOSIA immediately computes an optimal plan for reconfiguring the service among the huge number of combinations available based on network configuration and resource conditions. This optimal plan guarantees performance while minimizing cost. Then MOOSIA forwards the plan to the integrated control mechanism.

As the first step in applying AI technologies to MOOSIA, we are holding a closed-loop trial applying optimal resource allocation technology that considers future demand in virtual networks [3].

4. API orchestrator

The technologies described above pertain mainly to the evolution of wholesale services within a network operator. The following issues arise when multiple wholesale services of various first-B companies are combined to enable second-B companies to provide new collaborative services in an end-to-end fashion: (1) compatibility between different wholesale services must be taken into account when combining them; (2) the cause of a fault in a collaborative service must be searched out by carrying out troubleshooting that spans multiple wholesale services; and (3) automating the process of combining wholesale services is difficult because the format of a wholesale service API is different among first-B companies [4].

The core function that resolves these issues is the API orchestrator in MOOSIA. For a second-B company that wishes to launch a new collaborative service, the API orchestrator facilitates the use of wholesale services instead of developing the entire service from scratch. This approach can drastically speed up service development by a second-B company. Specifically, it can accelerate the cycle shown at the upper left of Fig. 1 that consists of three phases: combining wholesale services and launching a new service (phase 1), operating the newly provided service as desired (phase 2), and improving the provided service (phase 3). Since the closed loop described earlier is called the 1st loop, we call this cycle the 2nd loop.

The API orchestrator defines the specifications of a publicly available wholesale service as a catalog. It defines the specifications of a collaborative service by creating a federated catalog that combines multiple catalogs of publicly available wholesale services (Fig. 2) [5]. In this catalog-driven manner, the API orchestrator generically executes multiple services.

Fig. 2. Overview of API orchestrator.

Here, we describe each function of the API orchestrator in Fig. 2. First, the REST (Representational State Transfer) API sending/receiving section receives TMF-compliant APIs (such as an order for a collaborative service). The catalog/resource management section, meanwhile, manages TMF-compliant catalogs (refer, create, update, and delete). Next, the scenario execution/management section inputs the requested order and executes (create, update, delete, etc.) the associated wholesale services according to a scenario based on the corresponding federated catalog. In addition, the API adapter section absorbs the differences between TMF APIs, to which the API orchestrator conforms, and APIs provided by wholesale services. Then, that section executes the wholesale services.

This kind of architecture provides loose coupling between the API adapter and scenario execution/management section. It is beneficial because we can flexibly add new services or APIs by simply adding new catalogs and API adapters. The lifecycle management section, moreover, manages the lifecycles of assembled resources after building a service, while it also performs monitoring and fault detection. For second-B companies, the above functions and features simplify the combination of multiple wholesale services and the creation/management of collaborative services, thereby achieving phases 1–3 in the 2nd loop shown in Fig. 1.

5. Technologies for enhancing service assurance and fulfillment in MOOSIA

We introduce here two technologies that respectively enhance phases 2 and 3 in the 2nd loop.

The technology for phase 2 measures the end-to-end quality of service. Although the operation APIs of a first-B company’s wholesale services provide monitoring, detection, troubleshooting, or other functions, they are often limited to guaranteeing the service level agreement (SLA) within only a wholesale service. That means functions have not been sufficiently prepared for securing end-to-end quality in a collaborative service provided by a second-B company to end users. This technology therefore deploys a quality-collection agent on the U-plane (user plane), such as on a cloud, to determine/control the quality experienced by an end user on an end-to-end level.

The technology for phase 3 makes recommendations on service configuration. A wholesale service includes many configuration parameters, and therefore, establishing the settings when initially building the service is not a simple task. Consequently, having second-B companies provide answers to some simple questions makes it possible for this technology to present potential network/cloud service configurations and parameter settings. The technology can also predict performance based on configuration information and current operating conditions after the service launch and can also present an optimal reconfiguration and resetting plan whenever performance is out of bounds. This approach helps to guarantee performance, minimize costs, and thereby improve the service overall.

6. API framework

We refer here again to the issue described in section 4 (issue 3), which is the difficulty of automating the process of combining wholesale services due to different formats in the wholesale service APIs among first-B companies. One possible solution to this issue is to provide common API specifications in order to simplify a first-B company’s task of designing the API. Additionally, for a second-B company, we can expect common operations regardless of the service being used thanks to the standardized common API specifications (as prescribed by TMF). For example, the business process involved in ordering a service does not depend on the service being provided, so we consider that API specifications corresponding to that process can be standardized in a service-independent manner.

To establish API specifications for an operation, we have been establishing (1) a target business process, (2) a data model for the data to be used in the process of step (1), and (3) the functions for achieving the process in step (1) using the data of step (2) and a means of deploying those functions in the operation system. In actuality, though, API specifications can be defined as a method of data distribution between the functions established in (3) based on the data model in (2) with respect to the business process in (1). We call a general system for establishing such API specifications an API framework. In addition, we are studying an API framework focusing, for example, on specific API specifications such as an API for checking the resource inventory of first-B companies and on functions for bundling multiple APIs such as to coordinate the authentication functions of a second-B company and a first-B company. In relation to the above, TMF is working to establish operation reference models that include common APIs, so we plan to upstream the results of our studies [6].

7. Future evolution of MOOSIA

In fiscal year 2016, we teamed up with a partner service provider to conduct trials that combined commercial service APIs provided by both an NTT Group company and a non-NTT company. The results of this trial showed that we successfully established catalog-based API orchestrator technology. This API orchestrator is now reaching a practical level of implementation.

Going forward, we will continue to research and develop MOOSIA technologies to enable customers to create new services as needed by combining individual services. We will also enable customers to operate and expand such services with the aim of making it easier to create, operate, and improve services.

References

[1]	S. Horiuchi, K. Akashi, M. Sato, and T. Kotani, “Network Resource Management Technology,” NTT Technical Review, Vol. 15, No. 10, 2017. https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201710ra2.html
[2]	K. Watanabe, Y. Ikeda, Y. Nakano, K. Ishibashi, R. Kawahara, and S. Suzuki, “Creating New Value by Leveraging Network-AI Technology in Service Operations,” NTT Technical Review, Vol. 16, No. 6, 2018. https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201806fa3.html
[3]	M. Kobayashi, R. Matsumura, T. Kimura, T. Tsuchiya, and K. Noritake, “A Study on Effective Resource Allocation Method to Virtual Network with Service Accommodation Degree,” IEICE Technical Report, Vol. 115, No. 404, pp. 29–34, 2016 (in Japanese).
[4]	Y. Soejima, M. Nakajima, and K. Takahashi, “One-stop Operation Technology,” NTT Technical Review, Vol. 14, No. 10, 2016. https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201610fa5.html
[5]	H. Tanaka, N. Tateishi, and A. Yoshida, “Development of Operations for On-demand Design and Provision Based on Service Provider’s Requests,” Business Communication, Vol. 54, No. 5, pp. 10–11, 2017 (in Japanese).
[6]	A. Suzuki, K. Kashibuchi, and T. Nakamura, “Activities toward TM Forum Frameworx 17.0 and TM Forum Live! 2017 Report,” NTT Technical Review, Vol. 16, No. 1, 2018. https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201801gls.html