Feature Articles: Initiatives for the Widespread Adoption of NetroSphere

Vol. 14, No. 10, pp. 12–17, Oct. 2016. https://doi.org/10.53829/ntr201610fa2

NetroSpherePIT: Demonstrations to Accelerate the Adoption of NetroSphere

Takenori Okutani, Akio Kawabata, Tadashi Kotani,
Takashi Yamada, and Masato Maruyama


We constructed a demonstration experiment environment called NetroSpherePIT in order to materialize and visualize the NetroSphere concept, and we commenced demonstration experiments with various technologies required for its implementation. In this article, we explain one of the NetroSpherePIT demonstration experiments and the technical issues that were revealed in the experiment.

Keywords: NetroSphere, demonstration experiment, collaboration


1. Introduction

NTT Network Service Systems Laboratories built a demonstration environment called NetroSpherePIT (hereinafter referred to as PIT) to realize the NetroSphere concept and commenced experiments [1, 2]. The name PIT was selected as a starting point for releasing new technologies and services into the field. This will be done by NTT in collaboration with a broad range of partners such as vendors, carriers, and academics both domestically and internationally who participate in the demonstration experiments. In PIT, products will not only be tested as a single item but will also be verified from the viewpoint of total service using a series of products. PIT will also function as a venue for collaboration among partner companies. Our objectives are to visualize the NetroSphere concept and to create an environment in which network operators and partner companies can experience the usability of NetroSphere. PIT will also be applied as infrastructure for research and development (R&D) and will be used actively as a venue to accumulate technology.

In this article, we introduce PIT and the use scenarios for verifying the NetroSphere concept, which was exhibited at the NTT R&D Forum held in February 2016.

2. Summary of NetroSpherePIT

PIT consists of key components that realize the NetroSphere concept. These include Multi-Service Fabric (MSF), Flexible Access System Architecture (FASA), MAGONIA, Integrated Control, operator cooperative functions, network security, and Atelier N. The overall structure of PIT is shown in Fig. 1. With PIT, all communication applications are achieved using software and mounted on MAGONIA, which is the application platform. The MSF transfer/switching platform, which is shared by various services, connects network functions in different locations. Furthermore, the access network is made from a virtual optical line terminal (OLT), which conforms to the FASA concept in which the access system function is implemented by software on general-purpose hardware. PIT is thus realized by using general-purpose hardware and a uniform architecture and platform.

Fig. 1. Structure diagram of NetroSpherePIT.

Each communication application and MSF, MAGONIA, and the virtual OLT can be uniformly managed and operated by a MOOS (management, orchestration, and operation system), which has an orchestrator function. The function deployment model is shown in Fig. 2. This model uses the NFV (network functions virtualization) architecture as the base and is configured so as to achieve efficient management of networks and server resources. Also, the application programming interface (API) for collaborating operators is extended. We plan to further develop this model taking into consideration the implementation of products available on the market.

Fig. 2. Function deployment model.

To confirm the validity and feasibility of the NetroSphere concept, we checked the following four operations, which are the basic network functions of each component:

(1) Network slice function to provide multiple network services on an identical infrastructure network

(2) Technology enabling the use of various network functions on the general-purpose server via software

(3) Technology that controls the network slice and network functions in a consolidated manner on general-purpose servers

(4) API function that enables collaborating operators to control various network functions

In addition, we extracted the following three high level requirements to verify the effectiveness of visualization on the NetroSphere concept. From these we created a scenario, where NetroSphere operates as one system, and then verified its performance.

2.1 Hardware that is general-purpose and modularized, works regardless of location, and can be pooled

Various communication services (e.g., EPC (evolved packet core), Internet service provider (ISP) access, virtual private network (VPN) service) provided by the NTT Group are delivered on identical infrastructures. A backup resource can be shared and will operate regardless of location. The specific details are as follows:

(1) Each service function will be provided on identical hardware on MSF and MAGONIA.

(2) Various supplier devices will be used and can therefore be automatically embedded into the network, regardless of who performs the maintenance or of the use of other devices.

(3) A backup resource located in a broad area for a limited period/limited area can be used.

2.2 Delivering one-stop service from service operator

Various network functions are provided by an integrated interface, which enables one-stop service.

(1) The service from the access network to the VPN and to the cloud is controlled on the GUI (graphical user interface) of the service operator using an interface defined by common specifications within the group.

(2) A solution service is provided by linking applications provided by the system integrator and network functions (from the API).

Network functions for various operational tasks will be controlled in an integrated manner and will be automated.

(3) Total network security is provided through the collection/analysis of attacks, determination of countermeasures, and control of each network function.

(4) When devices are added or are damaged, the setting/control of related devices is autonomously controlled, and the standard architecture is always autonomously maintained.

2.3 New increase in network value for future network services

With NetroSphere, we will expand NTT’s business coverage by providing network functions that meet new network requirements for the Internet of Things (IoT) and the 5G (fifth-generation) mobile communication network.

(1) Virtual network functions such as a low delay application, vCPE (virtual customer premises equipment), and virtual base band unit (BBU)*1 will be provided.

(2) A network middle entity that provides new added value to machine-to-machine (M2M) and IoT will be provided.

*1 BBU: Digital signal processing section that is part of the wireless base station.

3. Items validated for NetroSpherePIT

We created three scenarios and evaluated the system operation in each scenario in order to meet the high level requirements mentioned in subsections 2.1–2.3. We explain the scenarios here.

3.1 Achieving common architecture for communication carriers

This use scenario is for communication device vendors and communication carriers where the NTT Group provides communication services on an identical infrastructure, which is intended to improve the efficiency of various operations. For this scenario, we loaded a tunnel function that is accessed by ISPs, as a communication application operating on a general-purpose server. This enables the application functions to be regenerated across locations when a failure occurs, and to be controlled together with the changes in network paths. We can thus provide a highly reliable service efficiently. To deal with sudden increases in demand, we created a communication application remotely on a general-purpose server deployed as backup. By embedding such schemes, we can handle the situation in a flexible manner without a large capital investment, even if there are unclear demands such as IoT/M2M or various service requirements.

Going through these use scenarios clarified that we needed to implement different functions according to each network function and in order to automatically embed functions in the network without affecting maintenance personnel or other connected devices. We will study efficient ways of achieving this and will also investigate the fully automated maintenance and operation.

3.2 Providing one-stop operation

This use scenario is for middle B operators (the second B in the B2B2X (business-to-business-to-X) business model). With this scenario, middle B operators use the API provided by the network realized by NetroSphere and link/interlock NTT networks to operator services to achieve one-stop operation. It is also intended to achieve monitoring/control in a similar way to that of the network built by the operator itself. When middle B operators deliver application services on the cloud, or their own network service together with NTT’s VPN as a package, the middle B operators create VPN functions by using TMF (TeleManagement Forum)’s standard API, thus enabling real-time monitoring of network status such as failures. Embedding such a scheme in the network makes it possible to achieve efficient operation among operators. We can expect to see an expansion of middle B business and a further expansion of network usage resulting from this.

In this use scenario, the service identification (ID) that is managed by the network orchestrator and the server orchestrator, both of which provide a service catalogue*2, as well as the ID that is allocated to the network function, which is a component of those orchestrators (such as the VLAN (virtual LAN)-ID of the switch), are currently assigned in a fixed format and are locally managed. We found that it is necessary to investigate the management format of the ID (local/distributed) and the allocation format to ensure the reliability of the whole system and to improve operational efficiency. The challenge will be to implement/promote this format to orchestration vendors.

3.3 Creating service together with service operators

This is a use scenario for service operators that is aimed at simplifying the development of new services by combining the communication service provided by the network and the application provided by the service operator. In this scenario, we created a developer portal that enables functions and applications provided by NetroSphere to be seen in a unified manner. We also developed a trial application using APIs for service operators, which has been released via Atelier N.

We will use all of these use scenarios to extract issues in order to improve usability when service operators make use of various network functions, and we will create collaborative services with the service operators.

*2 Service catalogue: Devices and configuration to provide network service in the orchestrator.

4. Future development

We constructed PIT using key components that materialize the NetroSphere concept such as MSF, FASA, MAGONIA, Integrated Control, operator cooperative functions, network security, and Atelier N. In the future, we will conduct experiments on PIT for new services and functions with operating companies of NTT as well as service operators, and we will make use of PIT as a venue to clarify the effects and issues of NetroSphere toward its commercialization. We will work out the specifications of individual products together with the Asia Pacific (APAC) carriers and work to spread the use of the products. To achieve this, we plan to actively use PIT to conduct experiments together with APAC carriers.

At the same time, we will actively connect the network with each NTT operating company and research institution, and use this as an R&D network. By continuing these endeavors in the PIT environment, we hope to deliver technology that is useful for NTT business and that contributes to the development of the industry.


[1] K. Ono, H. Yoshioka, M. Kaneko, S. Kondoh, M. Miyasaka, Y. Soejima, T. Moriya, K. Kanishima, A. Masuda, J. Koga, T. Tsuchiya, N. Yamashita, K. Tsuchikawa, and T. Yamada, “Implementing the NetroSphere Concept at NTT,” NTT Technical Review, Vol. 13, No. 10, 2015.
[2] “Special issue: Acceleration of NetroSphere—Latest Movement in Strategy for Its Propagation and Expansion,” BUSINESS COMMUNICATION, Vol. 53, No. 3, pp.10–23, 2016 (in Japanese)./td>
Takenori Okutani
Senior Research Engineer, Supervisor, Network Systems Planning & Innovation Project, NTT Network Service Systems Laboratories.
He received a B.E in basic science from the University of Tokyo in 1991. Since joining NTT in 1991, he has contributed to the development of network service systems including the Next Generation Network. His current research interests include achieving a NetroSphere concept that is a novel network architecture.
Akio Kawabata
Executive Manager, NTT Network Service Systems Laboratories.
He received a B.E. and M.E. from the University of Electro-Communications, Tokyo, in 1991 and 1993. In 1993, he joined NTT Communication Switching Laboratories. He has been developing switching systems and researching network design and switching system architecture. He served as a senior manager of the R&D Department at NTT EAST from 2011 to 2014.
Tadashi Kotani
Senior Research Engineer, Supervisor, Access Network Operation Project, NTT Access Network Service Systems Laboratories.
He received a B.S and M.E. in mechanical engineering from the University of Electro-Communications, Tokyo, in 1992 and 1994. Since joining NTT in 1994, he has mainly been engaged in R&D of a network operation support system in the access network and the wide area Ethernet network. He is a member of the Institute of Electronics, Information and Communication Engineers (IEICE).
Takashi Yamada
Senior Research Engineer, Access Network Operation Project, NTT Access Network Service Systems Laboratories.
He received his B.E., M.E., and Ph.D. in electrical engineering from Hokkaido University in 1997, 1999, and 2003. He joined NTT Access Network Service Systems Laboratories in 2003, where he worked on the research of energy efficient optical access network systems. During 2013–2016, he was engaged in R&D planning at the NTT Information Network Laboratory Group. He has been with NTT Access Network Service Systems Laboratories since 2016. His current research interests are time division multiplexing and time-wavelength division multiplexing passive optical network systems/technologies and their virtualization. He is a member of IEICE.
Masato Maruyama
Senior Research Engineer, Network Strategy Project, NTT Network Technology Laboratories.
He received a B.E. and M.E. in electronics engineering from the University of Electro-Communications, Tokyo, in 2001 and 2003. He joined NTT Energy and Environment Systems Laboratories in 2003, where he researched the stability of direct current power supply systems and optimization of air conditioning for telecom equipment rooms. He has been with NTT Network Technology Laboratories since 2015. His current research interests include network architecture of future networks.