Feature Articles: Initiatives for the Widespread Adoption of NetroSphere
New Access System Architecture (FASA)—Enabling Provision of Services Flexibly and Promptly
Flexible Access System Architecture (FASA) is a new access system architecture that satisfies various requirements from service providers and end users and enables prompt provision of services. NTT Access Network Service Systems Laboratories materialized this architecture, created a list of functions to be modularized, and investigated common API (application programming interface) specifications using use cases and dynamic bandwidth assignment as an example. A white paper was created as a reference. This article introduces some of the main elements of the white paper.
Keywords: FASA, access network element, modularization
As the diversification of telecommunications usage, in addition to the B2C (business-to-consumer) telecommunications services that are directly provided to end users by telecommunications carriers, B2B2C (business-to-business-to-consumer) telecommunications services are on the increase, where telecommunications services are provided to the end user via various service providers. NTT announced the Hikari Collaboration Model in 2014 . Since then, we have been providing new services through co-creation with various business players. Access network systems must be capable of quickly coping with such changes in these situations. However, conventional access network elements have been developed so that they are specific to each service, which has made it difficult to quickly satisfy requirements that are becoming more and more diverse due to changes in the business models of telecommunications services. Because of this, it was necessary to redevelop the entire access network element.
NTT proposed the NetroSphere concept  in order to satisfy the increase in diverse requirements and provide services promptly. To implement this concept, we are currently carrying out research and development (R&D) of technology that enables us to modularize the functions of the access network elements and also enables these functions to be combined. On February 8, 2016, we announced our new access system architecture called Flexible Access System Architecture (FASA), which is based on the NetroSphere concept . In addition to announcing the concept of FASA, we also explained that a draft plan for common application programming interfaces (APIs) for implementing FASA would be released, and we stated our intention to call for partners to collaborate in defining the FASA specifications. Since this press release, NTT Access Network Service Systems Laboratories has been investigating the FASA concept, a list of functions to be modularized, use cases, and common API specifications using dynamic bandwidth assignment (DBA)*1 as an example. On May 31, 2016, we unveiled the white paper as a reference and also called for collaborative partners to work on the FASA specifications .
2. Summary of white paper
Here, we briefly describe the main sections of the white paper.
2.1 Concept of FASA
Conventional access network elements are developed specifically for individual services. Therefore, when functions are added or replaced, it is necessary to redevelop the entire access network elements. In addition, spare equipment and maintenance skills specific to each access network element are required for maintenance and operation. For that reason, access network elements need to be more flexible and expandable in order to be able to promptly satisfy requirements from various telecommunications carriers and services.
In consideration of these requirements, we are positioning FASA as a new access system architecture and concept with the following characteristics:
(1) Functions in access network elements are modularized, thus avoiding the development of equipment specific to a service or a service provider.
(2) The functions that differ from service to service and/or among service providers are realized by software modules*2 with common interfaces.
(3) The dependency among software modules is minimized, and the replaceable software modules run on a platform.
By achieving the above items, we can provide functions quickly and economically that are tailored to the service, while still maintaining service quality.
2.2 Structure of access network element based on FASA and target of investigation
The FASA applications abstract the functions, which vary according to the services or service providers, and are implemented as a software module using common input/output interfaces (FASA application APIs*5). Because the input/output interfaces are commonalized, it is easy to add or replace functions and enables quick provision of various services.
The FASA platform is a basic component of the access network element, which provides FASA application APIs to the FASA applications and also provides functions that do not need to be changed for each service because those functions are standardized.
The white paper lists the FASA application APIs, which are common interfaces that link the FASA applications and the FASA platform. These FASA application APIs can be commonly used and do not depend on the access transmission system, for example, P2P (point-to-point) or passive optical network (PON), or on standards such as Ethernet PON or NG-PON2 (Next Generation PON2).
2.3 Functions to be implemented by FASA applications
In the white paper, we organized the main functions of the access network element and extracted the functions to be implemented by the FASA applications (Table 1). Of the functions indicated in the table, we classified those that should be implemented by the FASA applications that need to be replaced or extended to satisfy requirements unique to the service or service provider. Some functions that do not need to be replaced or extended because they are specified in the standardization are classified as functions to be implemented on the FASA platform.
For example, a function to satisfy service requirements in DBA is a function that should be part of the FASA applications. An example of a requirement that differs with each service or service provider is a policy that indicates which communication quality (low delay or high bandwidth efficiency) is to be given preference. The policy for bandwidth assignment differs according to the service or service provider; hence, this should be implemented as a FASA application. DBA is a process to adaptively assign bandwidth (the time slot in which the data signal can be transmitted) in the upstream direction from optical network units (ONUs) to an optical line terminal (OLT) to each ONU. This can be classified into status reporting (SR)-DBA, which assigns bandwidth based on reports from the ONUs, and non-status reporting (NSR)-DBA, which assigns bandwidth without the reports. With SR-DBA, it is possible to assign bandwidth with high bandwidth efficiency based on ONU reporting; hence, it is often used for fiber-to-the-home (FTTH). However, the round trip for control signals traveling between the ONU and the OLT takes time. Hence, when low delay is preferred, such as in mobile fronthaul (MFH), another method is chosen.
A function for DBA frame processing conforming to the given standards in the DBA function should be implemented on the FASA platform. To achieve an access network element of the 40-Gbit/s class, which conforms to the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) G.989 series, basic processing functions such as frame processing need to be implemented according to the standard. Such basic functions are common, regardless of the service or service provider, and should therefore be implemented on the FASA platform.
2.4 Example of FASA application API: DBA
In the white paper, we listed possible FASA use cases by using DBA as an example application. We organized APIs and the functional blocks to obtain necessary functions to realize each use case and then compiled the common API set so that they could cover all of the use cases.
The assumption in the white paper is that use cases such as multi-service (e.g., MFH, FTTH) are provided by PON. For example, the maximum delay tolerance specified for the data signals of MFH is stricter than for FTTH. With FASA, even if the access network element was developed for FTTH aiming for high bandwidth efficiency, by replacing FASA applications of DBA, it is possible to satisfy the strict delay specifications of MFH. To add and replace FASA applications according to the requirements from the service or service provider, it is necessary to have an API set that covers all the assumed use cases of the services and service providers.
For the DBA to meet MFH requirements, we can use optical-mobile cooperative DBA  that assigns bandwidth by obtaining necessary information for bandwidth assignment from external equipment, or NSR-DBA that assigns bandwidth based on statistical traffic data and traffic patterns.
The APIs and functional blocks of DBA in these use cases are shown in Fig. 2. The functional blocks consist of policy determination, assignment calculation, cooperative control, traffic monitoring, report processing, and grant processing.
In the SR-DBA for FTTH, the whole DBA will be implemented as a FASA application (fully software). In addition, we also assume an implementation where part of the DBA (policy determination) is to be implemented as a FASA application (partially software), which has a similar structure to the conventional PON.
To handle these use cases, we stipulated FASA application APIs for traffic information, request information, assigned amount, transmission start time, parameters for assignment calculation, parameters for policy determination, and cooperative information.
3. Future development
On May 31, 2016, we released the white paper on the FASA home page, and we posted the white paper and called for partners in the TOPICS section on the NTT Group website. We released the English version of the white paper on June 29, 2016 .
In the future, we will collaborate with partners to clarify specifications for access network elements such as the architecture, carrier requirements, use cases, and APIs. We plan to demonstrate a proof of concept and complete the API set by February 2017 (Fig. 3).