One-stop Operation Technology

1. Introduction

In business-to-business-to-X (B2B2X) business models, middle B operators (service operators) provide services for end users by freely and flexibly combining a wide variety of services such as infrastructure services and associated applications supplied by first B operators (network and cloud operators). Although first B operator services are not limited to wholesale services, in this article we refer to them as wholesale services in order to distinguish them from middle B operator services.

In order for first B operators to get middle B operators to use the wholesale services, operations concerning service orders, setting changes, and information notification when failures occur have come to be offered not through manual operations but through the use of application programming interfaces (APIs) as operation functions. Providing these operation functions as a service is called operation as a service (OaaS) [1]. Using OaaS APIs supplied by first B operators, middle B operators can apply for network and cloud services and achieve information sharing on malfunctions faster and easier than before.

However, in the B2B2X model, middle B operators need to determine the wholesale services (such as network and cloud services) they want to combine from multiple wholesale services, apply for the wholesale services after ensuring inter-service consistency, and diagnose failures over the entire wholesale service. This means that the operation becomes very complex (Fig. 1(a)). Accordingly, if first B operators can consolidate multiple wholesale services and supply them as unified operation and maintenance mechanisms to middle B operators, middle B operators’ operation costs can be reduced, and the prospect arises of further expanding the B2B2X model and creating more services (Fig. 1(b)). The mechanism that enables unified operation and maintenance is our one-stop operation technology.

Fig. 1. One-stop operation.

The core technologies of one-stop operations are: 1) fulfillment technologies for service catalogues that abstract and federate each wholesale service supplied by first B operators, and 2) cooperative functions that enable unified operation and maintenance using each wholesale service’s OaaS APIs.

2. Configuration technologies for service catalogues

Unifying the service order eases the complexity of middle B operator operations, but greater efficiencies can be achieved by preparing combinations of often-used wholesale services and basic scenarios as service catalogues and providing consolidated services. Naturally, it is necessary to customize them for middle B operators since the basic scenario alone does not fully meet the middle B operators’ needs. However, using the service catalogue as a template is more effective than investigating desired wholesale services from scratch.

Simply determining combinations of wholesale services will not bring down the operational costs of elements such as orders. They must be supplied with a specific order flow including the order procedure for multiple wholesale services, the means of obtaining parameters when there are dependent relationships among services, and the method of reflecting these parameters in the services. In order to offer a prefixed scenario of a wholesale service, the order flow specialized for that wholesale service should be created using OaaS APIs supplied by the first B operators. However, preparing all of the combined scenarios is impractical and, as mentioned previously, in real business situations, individual customizations may be necessary, and some wholesale services may need to be replaced with other wholesale services in the same category. Accordingly, it is important to have functions that link well among wholesale services and that unify operations based on the circumstances.

3. Cooperative functions

Cooperative functions maintain general-purpose service catalogues and operation flows, and they manage services by combining these catalogues and flows with individual parameters designated with each order by middle B operators. When middle B operators order services, first B operators replace the dedicated wholesale service part within the operation flow with the actual wholesale service in response to the designated parameters and use that wholesale service’s OaaS APIs for application processing. Once all the wholesale service orders and construction work have been completed, the cooperative functions notify the middle B operators of the completion of the service order. The status of the order can be obtained from the cooperative functions, or individual notification requests can be made using the order options.

It is also necessary to respond to failures, reports from end users, and other matters after the start of services. Middle B operators check the health of wholesale services in parallel with the health of their own in-house facilities. While it is possible to use the OaaS APIs of the targeted wholesale service directly in order to obtain failure information, it is also possible to use OaaS APIs supplied by cooperative functions. Cooperative functions automatically gather failure information by using the OaaS APIs of the targeted wholesale service because the cooperative functions have information on the wholesale services and their interrelationships. Moreover, if cooperative functions not only consolidate the gathered failure information but also inform middle B operators of suspected failure areas, middle B operators can support end users in a timely manner.

4. Future development

At the NetroSpherePIT event [2] in 2016, we demonstrated functions that build services that overarch networks and clouds among multiple operators as use cases that provide VoD (video on demand) services from middle B operators using networks supplied by multiple first B operators, and clouds supplied by other first B operators. In this demo, networks supplied by multiple first B operators are combined with cooperative functions to construct redundant networks. Moreover, we demonstrated operational functions triggered by the detection of video degradation to estimate suspected failure areas and automatically switched networks to restore services. In the future, we aim to expand the targeted operational domain based on issues extracted from verification results, formulate general-purpose service catalogues and operation flow specifications, proceed with verifications in a commercial environment, and enhance the technologies for cooperative functions.

References

	Yuji Soejima Senior Research Engineer, Operation Innovation Project, NTT Network Service Systems Laboratories. He received his B.E. and M.E. in engineering from Kyushu University, Fukuoka, in 2001 and 2003. He joined NTT Information Sharing Platform Laboratories in 2003. He joined NTT Network Service Systems Laboratories in 2014. His research interests include network management systems, network security, and future operation technologies. He is a member of the Institute of Electronics, Information and Communication Engineers (IEICE).
	Motomu Nakajima Research Engineer, Operation Innovation Project, NTT Network Service Systems Laboratories. He received his B.E. and M.E. in computer science from Waseda University, Tokyo, in 2003 and 2005. He joined NTT Network Service Systems Laboratories in 2005. His research interests include network management systems and future network operation technologies. He is a member of IEICE.
	Kensuke Takahashi Engineer, Operation Innovation Project, NTT Network Service Systems Laboratories. He received a B.E. and M.E. in computer science and engineering from Waseda University, Tokyo, in 2008 and 2010. He joined NTT Network Service Systems Laboratories in 2010 and has been researching congestion control for telecom networks, end-to-end operation system architecture for future networks including virtualized networks, and one-stop operation system architecture for the B2B2X business model. He is a member of IEICE.