Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Flexible Access System Architecture (FASA)
White Paper
Ver. 2.0
NTT Access Network Service Systems Laboratories,
NTT Corporation
Mar 31, 2017
FASA-White Paper Ver. 2.0
1 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Revision History
Revision Date Description
1.0 June 29, 2016 Initial Release
2.0 Mar 31, 2017 Update related technologies, APIs, functions
This document is about FASA concept proposed by NTT Access Service Systems Laboratories and
has no commitment of deployment and services in future.
Any description in this document might be changed without notice.
FASA-White Paper Ver. 2.0
2 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Table of Contents
SUMMARY
1. INTRODUCTION
1.1. Purposes of This Document
1.2. Overview of FASA
1.3. Scope of FASA Application API specification in This Document
1.4. Terms, Definitions, and Acronyms
1.5. Reference
2. Reference Architecture
2.1. Logic Model
2.2. Example of System Configuration
3. Use Cases
3.1. Multi-Service Accommodation by DBA Replacement
3.2. Satisfaction of Requirements Specific to Telecommunications Carrier by Replacement of Power
Saving Function
3.3. Satisfaction of Requirements Specific to Telecommunications Carrier by Replacement of
Protection Functions
4. Main Functions of Access Network System and Target of FASA Application
5. API specification
5.1. PON Data Signal Processing Function
5.2. PON Access Control Function
5.2.1 DBA
5.3. L2 Data Signal Processing Function
5.4. Maintenance and Operation Function
5.5. PON Multicast Function
5.6. Power-Saving Control Function
5.7. Frequency/Time-of-Day Synchronization Function
5.8. Protection Function
FASA-White Paper Ver. 2.0
3 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
SUMMARY
Because of the diversification of telecommunications usage, in addition to B2C model
telecommunications services that are directly provided to end users by telecommunications carriers,
B2B2C model telecommunications services are being provided more often to end users by way of
various service providers. Also, NTT announced, in 2014, the "HIKARI Collaboration Model,"1 and
new services are to be provided through co-creation with various business players. Given these
changes in the situation, access network systems also need to be able to cope with various
requirements (e.g. bandwidth, cost, and reliability) from service providers, which correspond to the
"Middle B"s of B2B2C, and end users flexibly and quickly.
Existing access network systems have been developed as network elements specific to each
service, thus access network services are unable to flexibly meet specific requirements. Therefore, it
is difficult for conventional access network elements to meet the diversifying requirements of access
network services quickly. This will become more important due to changes in business models as
well as the increasing variety of telecommunications services. For example, the entire elements must
be redesigned even if just one network function needs to be added or revised.
In order to satisfy the diversifying requirements and in order to provide services flexibly and
quickly, NTT is advocating the NetroSphere Concept2. Based on this concept, we are accelerating
the research and development of technology that can modularize the functions needed to configure a
network and permit their flexible combination as needed. In access networks, NTT has just
announced FASA (Flexible Access System Architecture)3 as a new access system architecture.
FASA is based on the NetroSphere concept and modularizes the functions offered by an access
network element; FASA allows access network systems to be configured through the flexible
combination of modularized functions. The functions, which differ from service to service and/or
among telecommunications carriers, are implemented as replaceable software modules (FASA
Applications). Such software modules run on the platform (FASA Platform) that provides common
interfaces. This configuration enables the functions of access network elements to be added or
replaced flexibly in order to satisfy the diversifying requirements quickly and flexibly.
Fig. 1 shows examples of the configurations with modularization based on FASA.
In configuration 1, FASA Applications, which are the functions to be replaced to satisfy
service-specific requirements or carrier-specific requirements, are modularized as software.
In configuration 2, the functions inside the FASA Platform (other than the FASA Applications) are
also included in the target of software modularization, which realizes access network elements using
more general-purpose hardware.
1 http://www.ntt.co.jp/irdoc/kaijishiryo/pdf/2014/008.pdf 2 http://www.ntt.co.jp/news2015/1502/150219a.html 3 http://www.ntt.co.jp/news2016/1602/160208a.html
FASA-White Paper Ver. 2.0
4 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
This document describes the architecture of FASA and the common interfaces (FASA Application
APIs) used in implementing FASA Applications.
Fig. 1. Examples of the configurations with modularization based on FASA
FASA-White Paper Ver. 2.0
5 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
1. INTRODUCTION
1.1. Purposes of This Document
This document describes the FASA (Flexible Access System Architecture) as a new access system
architecture that is capable of quickly supporting various requirements from telecommunications
carriers and various services and applications—and the FASA Application APIs (Application
Programming Interfaces) common interfaces generalized for implementing FASA Applications.
1.2. Overview of FASA
Fig. 1.2.-1 shows existing and future situations of the access network system.
In the current access network system and network element configuration, each function is
implemented as a system and network elements dedicated to each service; this results in many
restrictions that require redevelopment of the system and/or the whole network element for the
addition and/or replacement of functions. In addition, as for the maintenance and operation, spare
equipment and maintenance skills specific to each network element are required in this situation.
This is why, as shown in this view, it is necessary to enhance the flexibility and the expandability of
the access network element and so permit the quick satisfaction of the requirements and services of
various telecommunications carriers.
Fig. 1.2.-1. Existing and future situations of the access network system
FASA is new access system architecture and its concept to realize the followings:
1. Access network elements are modularized, instead of developing the access network
elements dedicated to specific functions or services.
2. The functions that differ from service to service and/or among telecommunications carriers
are realized by software modules with the common interfaces.
3. The dependency among the software modules is minimized and the replaceable software
modules run on a platform; therefore, while service quality is maintained, necessary
functions are realized flexibly and economically to satisfy the service requirements.
Fig. 1.2.-2 shows a schematic view of modularization based on FASA. As shown in this figure, an
FASA-White Paper Ver. 2.0
6 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
access network element based on FASA consists of FASA Applications and the FASA Platform.
"FASA Applications" realize the functions that differ from service to service and/or among
telecommunications carriers as software modules with the common interfaces (FASA Application
APIs). As FASA Applications are added and/or replaced depending on services, the services with
various requirements can be provided quickly and easily.
The "FASA Platform" is a basic component of the access network element that provides the FASA
Applications with the FASA Application APIs and, in addition, provides the functions that do not
need to be changed with the service or requirement. The FASA Platform realizes each function that
forms the FASA Platform by using hardware or software depending on the processing performance
and other requirements. Fig. 1.2.-3 shows examples of the configurations with modularization based
on FASA.
Fig. 1.2.-2. A schematic view of modularization based on FASA
Fig. 1.2.-3. Examples of configurations with modularization based on FASA
FASA-White Paper Ver. 2.0
7 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
In configuration 1, the FASA Applications over the FASA Application APIs are the targets of
software modularization, while the modularization of each function forming the FASA Platform is
out of the scope. For example, in the case of an NG-PON2 system based on this configuration, the
NG-PON2 protocol, which is standardized by ITU-T, is implemented on the FASA Platform, and the
replacement of NG-PON2 to EPON and other PON protocols is not considered.
In configuration 2, each function that composes the FASA Platform is modularized in addition.
Namely, FASA platform is also included in the scope of software modularization.
The FASA Application APIs are commonly used in both configuration 1 and configuration 2.
Fig. 1.2.-4 shows an example wherein the FASA Platform is divided into general-purpose
hardware and add-on modules. The access network element shown in the figure is composed of three
module categories: "(1) FASA Application," "(2) general-purpose hardware," and "(3) add-on
module." Their combination allows the necessary functions to be provided quickly and easily. "(2)
general-purpose hardware" has general-purpose telecommunications functions for not only access
network elements but also other network elements, which are implemented as general-purpose
modules. By using general-purpose hardware, it is possible to avoid the frequent development of
network elements from scratch with changes in service requirements. In addition, by using
general-purpose modules, it is expected that network element cost will be cut and that the
maintenance operations will be simplified through the commonality of spare equipment and the like.
"(2) general-purpose hardware" is, for example, some hardware that is not a network element
dedicated to the access network system such as general-purpose servers and white box switches. It is
equipped with firmware, OS and other software necessary for the hardware, and the middleware for
the FASA Application APIs to allow the use of "(1) FASA Application." "(3) Add-on module"
implements an optical transceiver and other functions where these are hard to implement as "(1)
FASA Application" or to implement on "(2) general-purpose hardware". It is separated from "(2)
general-purpose hardware." "(3) add-on module" is some hardware other than "(2) general-purpose
hardware" such as an optical transceiver. In the case where a simple optical module is used as "(3)
add-on module" to implement a media converter or in similar cases, "(1) FASA Application" will be
executed by using the OS, the middleware for the FASA Application APIs for "(1) FASA
Application" and other software on "(2) general-purpose hardware." On the other hand, in the case
where the MAC chip of a PON is implemented on "(3) add-on hardware" or in other similar cases,
"(1) FASA Application" will be executed by using the OS, the middleware for the FASA Application
APIs for "(1) FASA Application" and other software on "(3) add-on module." In either case, it is
possible to realize an access network with the optimal transmission capacity and the optimal
transmission technology by replacing add-on modules and corresponding software according to the
service requirements while using the same general-purpose hardware.
1.3. Scope of FASA Application API specification in This Document
This document describes use cases of the FASA
for realizing the use cases, the functions formed as
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
the modularization
is left out of the scope of this document
configuration 1 in Fig. 1.2.
1.4. Terms, Definitions, and Acronyms
Fig. 1.2.
1.3. Scope of FASA Application API specification in This Document
This document describes use cases of the FASA
for realizing the use cases, the functions formed as
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
the modularization
is left out of the scope of this document
onfiguration 1 in Fig. 1.2.
1.4. Terms, Definitions, and Acronyms
FASA-API:
FASA Application: The rep
Application APIs.
FASA Application API: The APIs that connect FASA Applications and the middleware for the
FASA Application APIs.
Middleware for
provides FASA Applications with the FASA Application APIs. The middleware for the
FASA Application APIs provides the means for inter
FASA Applica
communication
F
Fig. 1.2.-4. An example of the conce
1.3. Scope of FASA Application API specification in This Document
This document describes use cases of the FASA
for realizing the use cases, the functions formed as
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
the modularization of each function provided on the FASA Platform (
is left out of the scope of this document
onfiguration 1 in Fig. 1.2.-3.
1.4. Terms, Definitions, and Acronyms
API: The common
FASA Application: The rep
Application APIs.
FASA Application API: The APIs that connect FASA Applications and the middleware for the
FASA Application APIs.
iddleware for the FASA Application APIs:
provides FASA Applications with the FASA Application APIs. The middleware for the
FASA Application APIs provides the means for inter
FASA Applications.
communication of FASA Applications and
FASA-White Paper Ver.
4. An example of the conce
1.3. Scope of FASA Application API specification in This Document
This document describes use cases of the FASA
for realizing the use cases, the functions formed as
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
of each function provided on the FASA Platform (
is left out of the scope of this document. Specifically this document focuses on
1.4. Terms, Definitions, and Acronyms
The common term of the
FASA Application: The replaceable software modules
FASA Application API: The APIs that connect FASA Applications and the middleware for the
FASA Application APIs.
the FASA Application APIs:
provides FASA Applications with the FASA Application APIs. The middleware for the
FASA Application APIs provides the means for inter
. The middleware
of FASA Applications and
White Paper Ver.
8
4. An example of the concept of modularization on the FASA Platform
1.3. Scope of FASA Application API specification in This Document
This document describes use cases of the FASA-based access network system, system architecture
for realizing the use cases, the functions formed as FASA Applications, and the FASA Application
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
of each function provided on the FASA Platform (
Specifically this document focuses on
1.4. Terms, Definitions, and Acronyms
term of the APIs used for FASA.
laceable software modules
FASA Application API: The APIs that connect FASA Applications and the middleware for the
the FASA Application APIs: In
provides FASA Applications with the FASA Application APIs. The middleware for the
FASA Application APIs provides the means for inter
The middleware also
of FASA Applications and
White Paper Ver. 2.0
Copyright(c) 201
pt of modularization on the FASA Platform
1.3. Scope of FASA Application API specification in This Document
based access network system, system architecture
FASA Applications, and the FASA Application
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
of each function provided on the FASA Platform (
Specifically this document focuses on
APIs used for FASA.
laceable software modules implement
FASA Application API: The APIs that connect FASA Applications and the middleware for the
In the FASA Platforms, the software that
provides FASA Applications with the FASA Application APIs. The middleware for the
FASA Application APIs provides the means for inter-function communication among
also provides the means for inter
of FASA Applications and other functions in
.0
Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
pt of modularization on the FASA Platform
1.3. Scope of FASA Application API specification in This Document
based access network system, system architecture
FASA Applications, and the FASA Application
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
of each function provided on the FASA Platform (configuration 2 in Fig. 1.2.
Specifically this document focuses on
implemented by using the FASA
FASA Application API: The APIs that connect FASA Applications and the middleware for the
the FASA Platforms, the software that
provides FASA Applications with the FASA Application APIs. The middleware for the
function communication among
provides the means for inter
functions in FASA Platforms
NTT Corp. All Rights Reserved.
pt of modularization on the FASA Platform
based access network system, system architecture
FASA Applications, and the FASA Application
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
onfiguration 2 in Fig. 1.2.
Specifically this document focuses on the PON OLT in
ed by using the FASA
FASA Application API: The APIs that connect FASA Applications and the middleware for the
the FASA Platforms, the software that
provides FASA Applications with the FASA Application APIs. The middleware for the
function communication among
provides the means for inter-function
FASA Platforms
NTT Corp. All Rights Reserved.
based access network system, system architecture
FASA Applications, and the FASA Application
APIs. Currently, as for the access network system, because the MAC chip of the PON and other
dedicated hardware may be necessary from the point of view of processing performance and the like,
onfiguration 2 in Fig. 1.2.-3)
the PON OLT in
ed by using the FASA
FASA Application API: The APIs that connect FASA Applications and the middleware for the
the FASA Platforms, the software that
provides FASA Applications with the FASA Application APIs. The middleware for the
function communication among
function
FASA Platforms. The
FASA-White Paper Ver. 2.0
9 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
middleware absorbs any differences among the FASA Platforms.
FASA Platform: A basic component of an access network element that provides FASA
Applications with the FASA Application APIs. The component also provides functions that
do not depend on the service or requirement because of standardization or the like.
Add-on module: The module that implements a function that is difficult to implement on
general-purpose hardware by separating it from general-purpose hardware.
Software module: The module that forms a necessary function in a replaceable unit.
General-purpose hardware: The hardware whose usage is not limited to the access network
service, e.g. a general-purpose server and white box switch.
ACK: ACKnowledgement
ACPI: Advanced Configuration and Power Interface
API: Application Programming Interface
ASIC: Application Specific Integrated Circuit
B2B: Business-to-Business
B2B2C: Business to Business to Consumer
BBU: Base Band Unit
BWMap: BandWidth Map
CLI: Command Line Interface
CT: Channel Termination
DBA: Dynamic Bandwidth Assignment
DWA: Dynamic Wavelength Assignment
DWBA: Dynamic Wavelength and Bandwidth Assignment
EPON: Ethernet Passive Optical Network
FASA: Flexible Access System Architecture
FBA: Fixed Bandwidth Assignment
FEC: Forward Error Correction
FTTH: Fiber to the Home
GEM: G-PON Encapsulation Method
G-PON: Gigabit-capable Passive Optical Network
GTC: G-PON Transmission Convergence
IEEE: The Institute of Electrical and Electronics Engineers
IF: Interface
IPv6: Internet Protocol Version 6
ITU-T: International Telecommunication Union Telecommunication Standardization Sector
L2: Layer 2
FASA-White Paper Ver. 2.0
10 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
L3: Layer 3
LTE: Long Term Evolution
MAC: Media Access Control
MFH: Mobile Front Haul
MLD: Multicast Listener Discovery
NBI: Northbound Interface
NE-OpS: Network Element-Operation System
NG-PON2: Next Generation Passive Optical Network 2
NSR: Non-Status Reporting
OAM: Operation Administration and Maintenance
ODN: Optical Distribution Network
OLT: Optical Line Terminal
OMCI: ONU Management and Control Interface
ONU: Optical Network Unit
OS: Operating system
OSS: Operators Management System
OSU: Optical Subscriber Unit
PHY: Physical Layer
PLOAM: Physical Layer OAM
PON: Passive Optical Network
PS: Power Save
PTP: Precision Time Protocol
QoS: Quality of Service
RRH: Remote Radio Head
SBI: South Bound Interface
SD: State Diagram
SDK: Software Development Kit
SFC: Super Frame Counter
SNI: Service Node Interface
SNMP: Simple Network Management Protocol
SP conversion: Serial-to-Parallel conversion
SR: Status Reporting
SyncE: Synchronous Ethernet
TBD: To Be Determined
TC: Transmission Convergence
TDD: Time Division Duplex
FASA-White Paper Ver. 2.0
11 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
TDM: Time Division Multiplexing
ToD: Time of Day
TRx: Transceiver
UE: User Equipment
UNI: User Network Interface
VLAN: Virtual LAN (Local Area Network)
XGEM: XG-PON Encapsulation Method
XGTC: XG-PON Transmission Convergence
XG-PON: 10 Gigabit Capable Passive Optical Network
WDM: Wavelength Division Multiplexing
WDM/TDM-PON: Wavelength Division Multiplexing and Time Division Multiplexing
Passive Optical Network
1.5. Reference
[1] ITU-T G.989 series
[2] IEEE std.802.3TM, 2015
[3] IEEE std.1904.1, 2013
[4] ITU-T G.supplement 51
[5] T. Tashiro, et al., “A Novel DBA Scheme for TDM-PON based Mobile Fronthaul,” OFC2014,
paper Tu3F.3, Mar. 2014.
[6] D. Hisano, et. al., “Efficient Accommodation of Mobile Fronthaul and Secondary Services in
a TDM-PON System with Wireless TDD Frame Monitor, “IEEE ICC 2016, paper ONS1.1,
May 2016.
[7] T. Kobayashi, et al., “Bandwidth allocation scheme based on Simple Statistical Traffic
Analysis for TDM-PON based Mobile Fronthaul,” OFC 2016, paper W3C.7.
[8] “AT&T Vision Alignment Challenge Technology Survey,” AT&T Domain 2.0 Vision White
Paper, November 13, 2013.
[9] http://opencord.org/
[10] http://onosproject.org/
[11] https://wiki.opencord.org/display/CORD/VOLTHA:+vOLT+Hardware+Abstraction
[12] Broadband Forum WT-385 “Yang models for management of PON”.
[13] IEEE P802.3.2 “Standard for Ethernet YANG Data Model Definitions”
FASA-White Paper Ver. 2.0
12 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
2. Reference Architecture
2.1. Logic Model
Fig. 2.1.-1 shows the logic model; the example is that of the OLT. The controller and external
equipment are not included in the OLT, but are shown merely to illustrate the communications with
the FASA Application APIs. The logic model is composed of the FASA Applications and the FASA
Platform that provides the FASA Applications with the FASA Application APIs. The FASA Platform
includes the middleware for FASA Application APIs.
The middleware for the FASA Application APIs absorbs the differences among vendors and types
of hardware and software forming the FASA Platform. The FASA Application API set that is not
dependent on a vendor or service type is specified on the middleware for the FASA Application APIs,
and the FASA Applications are replaced to provide the functions necessary for each service or for
each telecommunications carrier. Communications among the FASA Applications and
communications between FASA applications and the controller or the like are executed by way of
the middleware for the FASA Application APIs.
The FASA Application API set is the group of common APIs used by the FASA Applications, and
APIs necessary for each FASA Application are selected as needed from the API set.
The controller is the operation system to manage the OLT such as NE-OpS, and control signals
from the controller are used for the communications with the SBI application by way of the FASA
Application APIs. The control signals for the communications with the SBI application are
terminated at the application for maintenance and operation by way of the FASA Application APIs.
The external equipment is, for example, the BBU of a mobile system or some other OLT; this is
external equipment that communicates with the FASA Applications by way of the FASA Application
APIs. In this figure, the external equipment (BBU) is communicating with a DBA application.
In this figure, communication with functions in the FASA Platform below the middleware for the
FASA Application APIs, communication among the applications, and the communication between
the maintenance and operation application and other applications are shown with red, green, and
orange arrows, respectively.
FASA-White Paper Ver. 2.0
13 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Fig. 2.1.-1. The logic model of FASA
2.2. Example of System Configuration
Fig. 2.2.-1 takes NG-PON2 OLT as an example and shows an example of the configuration of an
access network element based on FASA. The figure shows an example where the FASA Platform is
composed of two or more sets of hardware (NG-PON2 box, white box switch). The NG-PON2 box
and the white box switch are connected using a standard protocol such as Ethernet. The addition
and/or replacement of functions is performed by adding and/or replacing FASA Applications on the
FASA Application APIs of the FASA Platform. The middleware for the FASA Application APIs is
the software that absorbs the difference in the hardware and the software arising from the differences
among vendors and/or service types.
FASA-White Paper Ver. 2.0
14 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Fig. 2.2.-1. An example of the configuration of an access network element based on FASA
(NG-PON2 OLT)
2.3 Related technologies
On the other hand, CORD (Central Office Re-architected as a Datacenter) proposed by AT&T is a
close concept with FASA. Recently, Netconf / YANG has attracted attention as a method of
controlling network equipment. Standard of the YANG data model in the optical access systems is
being discussed in Broadband Forum WT-385, 394.
Below subsections describes these related technologies such as CORD, and describes the relation
with FASA.
2.3.1 CORD
CORD is a project in Domain 2.0 concept [8] proposed AT&T. Target of CORD is to reduce
OPEX / CAPEX and lead time to service start by using SDN and NFV technologies [9].
2.3.2 ONOS
CORD has OCP (Open Compute Project) hardware such as white-box layer 2 switch and
controllers. ONOS (Open Network Operating System) works as this controller. ONOS has been
FASA-White Paper Ver. 2.0
15 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
developed as open source software at ON. Lab founded by telecom carriers. ONOS configures
controls and monitors network equipment by Openflow protocol and Netconf / YANG [10].
Network applications in ONOS can be easily updated or modified since ONOS has OSGi (Apache
karaf) platform.
2.3.3 vOLT-HA
vOLT-HA (Virtual OLT Hardware Abstraction) is a part of CORD project and has been developed
as an open source software [11]. vOLT-HA abstracts difference among several vendor’s OLTs or
several PON protocols from ONOS.
vOLT-HA works at a position between ONOS as a controller and OLT as a network node.
Openflow or Netconf agent in vOLT-HA receives commands and configurations from ONOS, and
transmits them to each OLTs. vOLT-HA has common interface to OLTs and plug-in for each
vendor’s OLT. By this architecture, vendor differences can be abstracted from ONOS and vOLT-HA
core.
2.3.4 Netconf / YANG
Netconf is a protocol to configure network equipment. YANG is data model in Netconf. Standard
of YANG model in optical access systems has been discussed in Broadband forum and IEEE [12]
[13]. As this standardization progresses, command and configurations from EMS / controller can be
common in different vendor’s network equipment.
2.3.5 Relationship with FASA
It is possible that FASA use the open and standard technologies described above. Especially,
vOLT-HA locates close to hardware and is to make interface to OLTs common. It is expected that
FASA can use many parts of vOLT-HA. However, since vOLT-HA is still under development, it is
necessary to watch future developments.
3. Use Cases
As use cases of FASA, the multi-service accommodation and the satisfaction of the requirements
specific to a telecommunications carrier by a FASA Application replacement are shown.
The first example considers a PON system where FASA Applications are replaced to support
FASA-White Paper Ver. 2.0
16 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
diverse services with extremely different requirements such as mobile, residential, and business.
Section 3.1 describes a DBA use case, which is a typical example of the above-mentioned.
The latter example considers the provision of access network elements equipped with a desired
function by replacing FASA Applications as necessary to support functions whose usage is specific
to different telecommunications carriers; not all combinations are implemented in advance. Sections
3.2 and 3.3 describe the use cases of power-saving and protection, which are typical of the
above-mentioned example. Fig. 3.-1 shows a schematic view of the satisfaction of the requirements
specific to telecommunications carrier s by FASA Application replacement.
Fig. 3.-1. Satisfaction of the requirements specific to telecommunications carrier by FASA
Application replacement
3.1. Multi-Service Accommodation by DBA Replacement
It is expected that the current PON system, mainly dedicated to FTTH, will be effectively used for
multi-service accommodation for users such as mobile, residential, and business. However, the
requirements for each service are extremely different. In particular, the maximum delay tolerance
with respect to the data signal of the mobile front haul (MFH) is specified more strictly than, for
example, conventional Internet access services. Therefore, DBA, which assigns the upstream
bandwidth of the PON, needs to follow strict delay specifications. In addition, as for the application
of the PON to MFH, it is easily assumed that the requirements will change as a result of the
advances in the technology such as the fifth generation (5G) mobile communications, of advances in
the standards, and so forth, so that system development must follow such changes in a timely manner.
FASA replaces FASA Applications to provide the DBA suitable for each service in a timely manner.
FASA-White Paper Ver. 2.0
17 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Section 3.1 provides a comprehensive analysis of DBA use cases, and specifies the APIs involved
with the addition and/or replacement of future services.
3.1.1. DBA for MFH
DBA is the process that assigns the upstream bandwidth of each ONU (assigned time slot), and can
be classified into SR-DBA, which dynamically assigns the bandwidth to each ONU based on the
report (the request for bandwidth assignment) from the ONU, and NSR-DBA, which does not use a
report from the ONU. SR-DBA can perform assignment with high bandwidth efficiency according to
the report from the ONU. However, the control signal exchange, which makes a round trip between
the OLT and the ONU, takes time. Therefore, it is difficult to satisfy MFH requirements.
Consequently, the optical-mobile cooperative DBA, which acquires the information necessary for
assigning bandwidth from external equipment, and the NSR-DBA, which assigns bandwidth based
on traffic forecasts, have been proposed [5-7].
3.1.1.1. Optical-Mobile Cooperative DBA for MFH
Fig. 3.1.1.1.-1 shows the configuration and sequence of the optical-mobile cooperative DBA for
MFH. In the optical-mobile cooperative DBA for MFH, the OLT cooperates with the BBU to assign
bandwidth while satisfying the delay required for MFH. In particular, instead of using the report
from the ONU based on the upstream packet arriving from RRH, the optical-mobile cooperative
DBA uses the wireless resource information equivalent to the upstream transmission control
information generated by BBU for each UE. The upstream bandwidth assignment (the upstream
bandwidth and the timing of each ONU) is calculated by the DBA application or the external
equipment according to the wireless resource information [5]. This operation eliminates the waiting
time at the ONU, which ranges from the arrival time of the upstream signal from UE to the launch
time of the signal from ONU to a PON section, and thus reduces the delay. In the case of this DBA,
the API must enable linkage with the external equipment.
3.1.1.2. NSR
Fig. 3.1.1.2.
(which offers fixed bandwidth assignment)
generated by SR
MFH
used to r
whole system is enhanced through the shared use with residential systems.
The first NSR
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
estimating the TDD cycle.
The second NSR
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs
statistical traffic data gathered over long periods.
3.1.1.2. NSR-DBA for MFH
Fig. 3.1.1.2.-1 overviews an example of two types of NSR
(which offers fixed bandwidth assignment)
generated by SR-DBA and achieves the bandwidth assignment that satisfies the delay
MFH. In particular, based on the statistical data of the traffic and the traffic pattern, NSR
used to reduce the
whole system is enhanced through the shared use with residential systems.
The first NSR-DBA uses the statistical data of traffic to estimate the TDD cycle of the
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
estimating the TDD cycle.
The second NSR
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs
statistical traffic data gathered over long periods.
F
Fig. 3.1.1.1.
DBA for MFH
1 overviews an example of two types of NSR
(which offers fixed bandwidth assignment)
DBA and achieves the bandwidth assignment that satisfies the delay
. In particular, based on the statistical data of the traffic and the traffic pattern, NSR
educe the excessively
whole system is enhanced through the shared use with residential systems.
DBA uses the statistical data of traffic to estimate the TDD cycle of the
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
estimating the TDD cycle.
The second NSR-DBA focuses on t
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs
statistical traffic data gathered over long periods.
FASA-White Paper Ver.
Fig. 3.1.1.1.-1 Optical
DBA for MFH
1 overviews an example of two types of NSR
(which offers fixed bandwidth assignment)
DBA and achieves the bandwidth assignment that satisfies the delay
. In particular, based on the statistical data of the traffic and the traffic pattern, NSR
ively assigned bandwidth generated with FBA, and the efficiency of the
whole system is enhanced through the shared use with residential systems.
DBA uses the statistical data of traffic to estimate the TDD cycle of the
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
DBA focuses on the fact that the
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs
statistical traffic data gathered over long periods.
Fig. 3.1.1.2.
White Paper Ver.
18
1 Optical-mobile cooperative DBA for MFH
1 overviews an example of two types of NSR
(which offers fixed bandwidth assignment) removes the roundtrip delay of the control signal
DBA and achieves the bandwidth assignment that satisfies the delay
. In particular, based on the statistical data of the traffic and the traffic pattern, NSR
assigned bandwidth generated with FBA, and the efficiency of the
whole system is enhanced through the shared use with residential systems.
DBA uses the statistical data of traffic to estimate the TDD cycle of the
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
he fact that there is similarity
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs
statistical traffic data gathered over long periods.
Fig. 3.1.1.2.-1. NSR-DBA for MFH
White Paper Ver. 2.0
Copyright(c) 201
mobile cooperative DBA for MFH
1 overviews an example of two types of NSR-DBA for MFH. Here, NSR
removes the roundtrip delay of the control signal
DBA and achieves the bandwidth assignment that satisfies the delay
. In particular, based on the statistical data of the traffic and the traffic pattern, NSR
assigned bandwidth generated with FBA, and the efficiency of the
whole system is enhanced through the shared use with residential systems.
DBA uses the statistical data of traffic to estimate the TDD cycle of the
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
re is similarity in
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs
DBA for MFH
.0
Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
mobile cooperative DBA for MFH
DBA for MFH. Here, NSR
removes the roundtrip delay of the control signal
DBA and achieves the bandwidth assignment that satisfies the delay
. In particular, based on the statistical data of the traffic and the traffic pattern, NSR
assigned bandwidth generated with FBA, and the efficiency of the
whole system is enhanced through the shared use with residential systems.
DBA uses the statistical data of traffic to estimate the TDD cycle of the
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
in traffic pattern
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
period based on the statistical traffic information [7]. This DBA needs an API that enable
NTT Corp. All Rights Reserved.
DBA for MFH. Here, NSR
removes the roundtrip delay of the control signal
DBA and achieves the bandwidth assignment that satisfies the delay requir
. In particular, based on the statistical data of the traffic and the traffic pattern, NSR-DBA is
assigned bandwidth generated with FBA, and the efficiency of the
DBA uses the statistical data of traffic to estimate the TDD cycle of the TDD
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
pattern if observed using
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
API that enables the use of
NTT Corp. All Rights Reserved.
DBA for MFH. Here, NSR-DBA
removes the roundtrip delay of the control signal
required for
DBA is
assigned bandwidth generated with FBA, and the efficiency of the
TDD-type
mobile system and executes bandwidth assignment according to the TDD cycle [6]. This DBA needs
an API that enables the use of the statistical traffic information with sufficient sampling speed for
if observed using
time spans from one day to one week, and estimates the necessary bandwidth for the next traffic
s the use of
FASA-White Paper Ver. 2.0
19 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
3.1.2. SR-DBA for Residential Use
Fig. 3.1.2.-1 shows the configuration and sequence of SR-DBA for residential use. In this
SR-DBA, based on the request information collected from each ONU, dynamic bandwidth
assignment is executed for each ONU. Therefore, this DBA needs an API that collects the request
information from each ONU.
Fig. 3.1.2.-1. SR-DBA for Residential Use
3.1.3. DBA for Business Use
TBD
3.1.4. API of DBA and Functional Block
Based on what is described above, Fig. 3.1.4.-1 shows a schematic view of the API of DBA and the
functional block for realizing each of the use cases. In addition, Fig. 3.1.4.-2 shows the definition of
each functional block (the policy determination part, the assignment calculation part, the cooperative
control part, the traffic monitor, the report processing part, the grant processing part) in Fig. 3.1.4.-1.
FASA-White Paper Ver. 2.0
20 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Fig. 3.1.4.-1. A schematic view of the API of DBA and the functional blocks
Use Cases 1 and 2 in Fig. 3.1.4.-1 show the location of the API with configuration for the case
wherein the entire DBA (the policy determination part and the assignment calculation part) is
implemented as a FASA Application in order to flexibly implement DBA with functions such as
linkage to external equipment. The SR-DBA for residential use in Use Case 3 of Fig. 3.1.4.-1 shows
the location of the API with configuration for the case of "(b) Implementing a Partial DBA Function
as Software" where a part of only the DBA (the policy determination part) is implemented together
with the MAC chip etc. of the conventional OLT in addition to "(a) Implementing the Whole DBA
Function into Software" where the whole DBA is implemented as a FASA Application.
In order to handle the above-mentioned use cases, the FASA Platform needs to have a cooperative
control function and a traffic monitor function, in addition to report processing function and grant
processing function, which are specified in the PON standard. FASA Platform also needs to have
APIs for collecting the cooperative information, the traffic amount information, the requests, and the
parameters for policy determination, and assigned amount, the transmission start time, and the
parameters for bandwidth calculation.
3.2.
Replacement of Power Saving Function
TBD
3.3.
Replacement of Protection Functions
The requirements of telecommunications carriers include the high access network availability.
example
equip
network elements as well as migration to new hardware with enhanced processing functions
necessary to execute the remedial operations without interrupting th
function is critical.
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
accordance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
The main functions of the access
shown in Table 4.
below.
The PON data signal processing function is a group of functions that process the data signals for
3.2. Satisfaction
Replacement of Power Saving Function
TBD
. Satisfaction
Replacement of Protection Functions
The requirements of telecommunications carriers include the high access network availability.
example, a protection
equipment failure. In
network elements as well as migration to new hardware with enhanced processing functions
necessary to execute the remedial operations without interrupting th
function is critical.
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
The main functions of the access
hown in Table 4.
below.
The PON data signal processing function is a group of functions that process the data signals for
F
Fig. 3.1.4.
Satisfaction of Requirements
Replacement of Power Saving Function
Satisfaction of Requirements
Replacement of Protection Functions
The requirements of telecommunications carriers include the high access network availability.
, a protection function
failure. In addition
network elements as well as migration to new hardware with enhanced processing functions
necessary to execute the remedial operations without interrupting th
function is critical.
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
The main functions of the access
hown in Table 4.-1. First of all, the main functions of the access
The PON data signal processing function is a group of functions that process the data signals for
FASA-White Paper Ver.
Fig. 3.1.4.-2. Definitions of the functional parts
Requirements
Replacement of Power Saving Function
Requirements
Replacement of Protection Functions
The requirements of telecommunications carriers include the high access network availability.
is essential to reduce the interruption time of the
addition, to provide service reliability during software updates on access
network elements as well as migration to new hardware with enhanced processing functions
necessary to execute the remedial operations without interrupting th
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
The main functions of the access network
1. First of all, the main functions of the access
The PON data signal processing function is a group of functions that process the data signals for
White Paper Ver.
21
2. Definitions of the functional parts
Specific
Replacement of Power Saving Function
Specific
The requirements of telecommunications carriers include the high access network availability.
is essential to reduce the interruption time of the
o provide service reliability during software updates on access
network elements as well as migration to new hardware with enhanced processing functions
necessary to execute the remedial operations without interrupting th
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
network system and the target of the FASA applications are
1. First of all, the main functions of the access
The PON data signal processing function is a group of functions that process the data signals for
White Paper Ver. 2.0
Copyright(c) 201
2. Definitions of the functional parts
to Telecommunications Carrier by
to Telecommunications
The requirements of telecommunications carriers include the high access network availability.
is essential to reduce the interruption time of the
o provide service reliability during software updates on access
network elements as well as migration to new hardware with enhanced processing functions
necessary to execute the remedial operations without interrupting the service; therefore, a protection
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
system and the target of the FASA applications are
1. First of all, the main functions of the access
The PON data signal processing function is a group of functions that process the data signals for
.0
Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
2. Definitions of the functional parts
to Telecommunications Carrier by
to Telecommunications
The requirements of telecommunications carriers include the high access network availability.
is essential to reduce the interruption time of the service
o provide service reliability during software updates on access
network elements as well as migration to new hardware with enhanced processing functions
e service; therefore, a protection
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
system and the target of the FASA applications are
1. First of all, the main functions of the access network system are described
The PON data signal processing function is a group of functions that process the data signals for
NTT Corp. All Rights Reserved.
to Telecommunications Carrier by
to Telecommunications Carrier
The requirements of telecommunications carriers include the high access network availability.
service in case of the
o provide service reliability during software updates on access
network elements as well as migration to new hardware with enhanced processing functions
e service; therefore, a protection
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
rdance with different policies; therefore, in FASA, an API for protection is specified.
4. Main Functions of Access Network System and Target of FASA Application
system and the target of the FASA applications are
system are described
The PON data signal processing function is a group of functions that process the data signals for
NTT Corp. All Rights Reserved.
to Telecommunications Carrier by
Carrier by
The requirements of telecommunications carriers include the high access network availability. For
in case of the
o provide service reliability during software updates on access
network elements as well as migration to new hardware with enhanced processing functions, it is
e service; therefore, a protection
As the access network elements and the network configurations connected to them differ among
telecommunications carriers, it is assumed that some protection should be performed differently or in
system and the target of the FASA applications are
system are described
The PON data signal processing function is a group of functions that process the data signals for
FASA-White Paper Ver. 2.0
22 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
incoming/outgoing transmissions with the ONU, and so includes functions for the PON frame
composition/decomposition and FEC.
The PON access control function is a group of control functions for controlling the
incoming/outgoing transmission of the data signals described above, and so includes dynamic
bandwidth assignment, registration and authentication of the ONU.
The L2 data signal processing function is a group of functions that forward and process the data
signals between the PON-side port and the SNI-side port, and so includes learning the MAC address,
VLAN control, QoS control, and traffic monitoring.
The maintenance and operation function is a group of functions for smoothly maintaining and
operating the service with the help of the access network element, and so includes functions to
configure the settings of the ONU and OLT (the OSU and switch), software updates, management of
the access network elements and services, monitoring function for confirming the normality of
functions inside the network element, and testing function for investigating the scope and/or the
cause of failure. In addition, the maintenance and operation function provides a mechanism to
cooperate with the maintenance and operation system which realizes management of multiple access
network elements, thus realizes smooth maintenance and operation even from a remote site.
The PON multicast function is a group of functions that forwards the multicast stream received
from the SNI-side port to appropriate users, and so includes the identification and distribution of
multicast streams and a function to prepare the filter setting of the ONU.
The power-saving control function is a group of functions for reducing the power consumption of
the ONU and OLT, which, in addition to the power-saving functions specified by standards, includes
a function that minimizes the influence over the service by cooperating with the traffic monitor
while acquiring the maximum efficiency in terms of power-saving.
The frequency/Time-of-Day synchronization function is a group of functions for providing the
equipment under the ONU with accurate frequency synchronization and time-of-day synchronization.
They include a function to synchronize the ONU’s own real-time clock with the master device and a
function that uses the PON frame to notify the time-of-day information to the ONU.
The protection function is a group of functions for continuing a service by switching and/or taking
over from the working system to the backup system upon the detection of a failure (assumes
redundant configuration). The redundancy is provided by deploying two or more devices. This
function group includes a function that detects switching trigger and/or executes the switching
process. In addition, when a failure is detected or when manual switching is performed, the
protection function does not stop the complete service but lets the service continue in restricted
operation.
FASA-White Paper Ver. 2.0
23 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Table 4.-1 The Main Functions of Access Network System and the Target of FASA Applications
FASA-White Paper Ver. 2.0
24 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
The next part describes the concepts and examples that examine whether each function should be
implemented as a FASA Application or should be implemented in the FASA Platform.
Among the functions shown in Table 4.-1, those that depend on the service and those that need
modifications to satisfy a specific requirement of a telecommunications carrier should be
implemented as FASA Applications. On the other hand, the functions that are unlikely to be
modified for some reasons, e.g. because they are standard-specific, should be implemented on the
FASA Platform.
In Table 4.-1, for example, it is shown that the PON data signal processing function is
implemented in the FASA Platform. In order to conform an access network element to the ITU-T
G.989 series that support 40 Gbit/s rate, it is necessary to follow the standard in implementing the
basic PON data signal processing functions such as PON frame composition/decomposition, frame
encryption, and forward error correction (FEC). In addition, as these basic functions are common
regardless of the service, they should be implemented in the FASA Platform.
As another example, Table 4.-1 shows the case where the DBA function included in the PON
access control function is implemented as a FASA Application in order to satisfy service-specific
requirements. As described in Section 3, there are some cases where low delay is essential and other
cases where bandwidth must be efficiently assigned to the users depending on the service to provide.
In order to satisfy the requirements that differ from service to service, it is preferable to separate, as
FASA Applications, the procedure and the policy for bandwidth assignment from standard processes
(conversion to BWmap format etc. as specified in the standard).
Furthermore, even if the service is for residential use, it is reasonable, for example, that the
policy of coping with heavy users may depend on the telecommunications carrier, which means
different fairness policies. Specifically, one telecommunications carrier might impose some
particular fairness restraint on one PON branch; while another telecommunications carrier performs
rough fairness control in at the aggregation switch level. Thus, they have their own QoS
requirements to be satisfied.
As described above, FASA aims to fulfil different requirements by replacing FASA Applications;
therefore, a means for replacing FASA Applications is required. On the other hand, how to realize
the replacement depends on the telecommunications carrier and/or the operation. For example, when
the file transfer protocol adopted by an existing maintenance and operation system of a
telecommunications carrier is TFTP (Trivial File Transfer Protocol), TFTP is to be equipped; on the
other hand, when SFTP (SSH File Transfer Protocol) is used from outside of the maintenance and
operation system for service upgrade, SFTP is to be equipped. Moreover, it is assumed that a
discussion on standards with respect to these interfaces among access network elements and
controllers should be advanced, which means that some consideration should be taken also as the
FASA-White Paper Ver. 2.0
25 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
additions to and changes of the interfaces to follow the development of such standards. This is why
the functions that require customization in accordance with other systems connected to the access
network elements and with its operation are also to be implemented, in Table 4.-1, as FASA
Applications.
Further, FASA is assumed to provide protection by not only fully duplicating the FASA Platform
but also duplicating only a part of the FASA Platform. Examples include, the case where the FASA
Platform is equipped with an optical switch to provide PON protection, the case where two or more
wavelengths are used in one PON branch to realize wavelength protection, the case where only the
switch is duplicated, and the case where the above-mentioned cases are combined; more cases can be
conceived. By implementing the protection function as a FASA Application, it becomes possible to
choose preferable redundant configurations and, furthermore, it becomes possible easily to prepare
various redundant configurations by reusing applicable portions.
5. API specification
The API is, regardless of what is implemented as a FASA Application, a common API set. In other
words, the developer selects which ones to use from the common API set when implementing a
FASA Application. Although the scenarios described in this section are mainly concerned with PON
systems based on ITU-T recommendations, the scope of API includes access network systems
compliant with other PON standards such as those of IEEE.
Please note that following descriptions are not finalized. They might be updated according to
progress of future study.
5.0.1 Concept of FASA API
From the viewpoint of FASA applications to the lower processing units, interface between them
can be roughly divided into three types. The first one is to configure, control and monitor to OLT
itself. The second one is to send and receive messages between ONUs. The other is an interface type
that does not apply to either.
5.0.2 Configure, control and monitor API
A function of FASA applications is to receive messages of configuration and control from
controller or EMS via Netconf / YANG and to command the lower processing unit based on the
received message contents. In addition, FASA applications get and notify state of OLT itself to
controller or EMS.
In this operation, FASA applications forward received message based on YANG data model. This
function is almost equal to one of vOLT-HA function. This configure, control and monitor API is
FASA-White Paper Ver. 2.0
26 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
mostly equal to interface to OLT in vOLT-HA. Therefore, there is a good possibility that FASA can
utilize vOLT-HA interfaces. In addition, when YANG data model in optical access systems is
properly standardized, common and standard interfaces to configure, control and monitor may be
able to be available easily.
5.0.3 Communication API
To configure, control, command and monitor an ONU, FASA applications build a message to the
ONU and order the lower processing unit to send it. On the other hand, FASA applications read
messages the lower processing unit received and stored. ONU communication interfaces can be
summarized to order to send a message and to read message, although there are several protocols to
communicate between OLT and ONU such as extended OAM and OMCI. Therefore there is also a
good possibility that FASA can utilize vOLT-HA interfaces for ONU communication.
5.0.4 Other API
Exceptionally, when a FASA application need to cooperates with not OLT device, interface
between them is necessary.
5.0.5 Time-critical functions
Above described, interfaces for the lower processing unit are roughly divided several types,
although FASA applications may be many types. Furthermore, vOLT-HA interface or interface based
on standard data model in the future can be available for FASA applications.
However, the above expectation is only for slow process. FASA application for time-critical
functions needs other more interfaces. Such functions are not so many, but DBA function that needs
fast message exchange with ONU and ONU sleep control function can be considered that kind.
These functions have their algorithm in internal process. For FASA applications that have original
DBA algorithm or original sleep control algorithm, vOLT-HA interface and interface based on
standardized data model are not enough. Dedicated interfaces are necessary. Below section 5.2.1 will
describe them.
5.1. PON Data Signal Processing Function
TBD
5.2. PON Access Control Function
5.2.1. DBA
Table 5.2.1.
for MFH, the NSR
implemented as
partially implemented as
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical
MFH, the NSR
FASA application), and the SR
a FASA application). This document assumes a DBA application with event
The API is, regardless
other words, the developer selects which ones to use from the common API set in order to implement
DBA application
"set_Grant
5.1. PON Data Signal Processing Function
TBD
5.2. PON Access Control Function
5.2.1. DBA
Table 5.2.1.-1 shows the API list for each use case of DBA (the optical
for MFH, the NSR
implemented as a
partially implemented as
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical
MFH, the NSR-DBA for MFH, the SR
FASA application), and the SR
FASA application). This document assumes a DBA application with event
The API is, regardless
other words, the developer selects which ones to use from the common API set in order to implement
DBA application
"set_GrantSizeAndStartTime" are commonly used by DBA applications, while
F
Figure 5.0.5
5.1. PON Data Signal Processing Function
5.2. PON Access Control Function
1 shows the API list for each use case of DBA (the optical
for MFH, the NSR-DBA for MFH, the SR
a FASA application), and the SR
partially implemented as a FASA application)). The column "Use cases" in the tab
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical
DBA for MFH, the SR
FASA application), and the SR
FASA application). This document assumes a DBA application with event
The API is, regardless of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
DBA application. For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
FASA-White Paper Ver.
Figure 5.0.5-1 Roughly divided interfaces
5.1. PON Data Signal Processing Function
5.2. PON Access Control Function
1 shows the API list for each use case of DBA (the optical
DBA for MFH, the SR
FASA application), and the SR
FASA application)). The column "Use cases" in the tab
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical
DBA for MFH, the SR-DBA for resi
FASA application), and the SR-DBA for residential
FASA application). This document assumes a DBA application with event
of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
White Paper Ver.
27
1 Roughly divided interfaces
5.1. PON Data Signal Processing Function
1 shows the API list for each use case of DBA (the optical
DBA for MFH, the SR-DBA for residential use (the DBA function fully
FASA application), and the SR-DBA for residential use (the DBA function
FASA application)). The column "Use cases" in the tab
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical
DBA for residential use (the DBA fully implemented as
DBA for residential use (the DBA function partially implemented as
FASA application). This document assumes a DBA application with event
of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
White Paper Ver. 2.0
Copyright(c) 201
1 Roughly divided interfaces
1 shows the API list for each use case of DBA (the optical
DBA for residential use (the DBA function fully
DBA for residential use (the DBA function
FASA application)). The column "Use cases" in the tab
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical
dential use (the DBA fully implemented as
se (the DBA function partially implemented as
FASA application). This document assumes a DBA application with event
of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
.0
Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
1 Roughly divided interfaces
1 shows the API list for each use case of DBA (the optical-mobile cooperative DB
DBA for residential use (the DBA function fully
DBA for residential use (the DBA function
FASA application)). The column "Use cases" in the tab
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical-mobile cooperative DBA for
dential use (the DBA fully implemented as
se (the DBA function partially implemented as
FASA application). This document assumes a DBA application with event-driven architecture.
of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
NTT Corp. All Rights Reserved.
mobile cooperative DB
DBA for residential use (the DBA function fully
DBA for residential use (the DBA function
FASA application)). The column "Use cases" in the table shows the
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
mobile cooperative DBA for
dential use (the DBA fully implemented as
se (the DBA function partially implemented as
driven architecture.
of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
NTT Corp. All Rights Reserved.
mobile cooperative DBA
DBA for residential use (the DBA function fully
DBA for residential use (the DBA function
le shows the
correspondence between use cases and their APIs. The APIs with a check in each column from "1,"
mobile cooperative DBA for
dential use (the DBA fully implemented as a
se (the DBA function partially implemented as
driven architecture.
of the FASA Application (the DBA application), a common API set. In
other words, the developer selects which ones to use from the common API set in order to implement
For example, "get_AllocationDbaConfig," "set_GrantSize," and
SizeAndStartTime" are commonly used by DBA applications, while
FASA-White Paper Ver. 2.0
28 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
"get_CooperationConfig," "get_DataSize," "get_Traffic," "get_AllocUnitTraffic," and
"get_CalcConfig" are used by a specific DBA application only. The API
"get_AllocationDbaConfig," which is commonly used, acquires, from the reply data, the information
necessary for each DBA application. The API "set_GrantSizeAndStartTime" is used to control the
transmission start time of ONU via the FASA Application. On the other hand, when the API
"set_GrantSize" without the start time parameter is used, the FASA platform determines the
transmission start time.
In the table, "allocation unit" represents the logical path selected to assign the bandwidth with the
DBA. Allocation index represents the indices of the allocation target. Config index are the indices of
the setting parameters. Monitoring index are the indices of the measurement target of the traffic
monitor. Parameters for policy determination are the parameters used in the calculations of the
policy determination part. Parameters for assignment calculation are the parameters used in the
calculations in the bandwidth calculation part. In the table, the items tagged <Details to be
determined>, the correspondence between an index and a setting parameter, the contents of a
parameter for policy determination, and the contents of a parameter for assignment calculation are
items to be examined in the future.
FASA-White Paper Ver. 2.0
29 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Table 5.2.1.-1. The API of the DBA
FASA-White Paper Ver. 2.0
30 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
5.2.1.1. Optical-mobile Cooperative DBA for MFH
In Table 5.2.1.-1, the API checked for Use Case 1 is an example of the API of the optical-mobile
cooperative DBA for MFH. For example, the API "get_CooperationConfig" acquires the operation
cycle and the operation mode of the cooperative control part, the name of the cooperative control
system, version, and so forth. The API "get_DataSize" is called every time bandwidth assignment is
triggered. This API can acquire either the data size of a specified allocation index individually or
those of a specific range of allocation indices at a time.
5.2.1.2. NSR-DBA for MFH
In Table 5.2.1.-1, the API checked for Use Case 2 is an example of the API used by the NSR-DBA
for MFH. For example, "get_Traffic" and "get_AllocUnitTraffic" are called in every bandwidth
assignment cycle. The API "get_Traffic" measures the traffic flows of multiple OLTs’, OSUs’, or
CTs’ while "get_AllocUnitTraffic" measures the traffic flows in terms of allocation unit. For
example, "get_AllocUnitTraffic" measures all traffic flows or specific traffic flows identified by the
designated allocation indices.
5.2.1.3. SR-DBA for Residential (DBA Function Fully Embodied as a FASA
Application)
In Table 5.2.1-1, the API checked for Use Case 3a is an example of the API used by the SR-DBA
for residential use (the DBA function fully implemented as a FASA application). For example,
"get_ReportSize" is called every time bandwidth assignment is triggered. The API "get_ReportSize"
acquires either the reported value of a specified allocation index individually or those of the
specified range of allocation indices at a time.
5.2.1.4. SR-DBA for Residential (DBA Function Partially Embodied as a FASA
Application)
In Table 5.2.1.-1, the API checked for Use Case 3b is an example of the API used by the SR-DBA
for residential use (the DBA function partially implemented as a FASA application). In the API
"get_CalcConfig," the parameter "Config information” represents, for example, the maximum
bandwidth, or the assured bandwidth of the allocation unit. In the API
"get_ParameterForPolicyMaking", the parameter for policy determination is, for example, the
history of the requests or assigned amounts.
5.2.1.5 DBA algorithm and messaging
The FASA can have alternative API models. FASA applications as API upper side have a calculation
function of DBA algorithm, and FASA middleware as API lower side have function of
FASA-White Paper Ver. 2.0
31 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
building/sending and receiving messages between ONUs. This model is effective for running
original DBA algorithm in an OLT.
Such OLT needs two internal interfaces. One is sending all information of granting upstream traffic
from API upper side to lower side. The other is notifying all information of requesting upstream
traffic from API lower side to upper side.
One of suitable information is the format not requiring calculation in opposite side. It means sending
and notifying raw value of messages.
5.2.1.5.1 Grant configuration API
Format:
fasa_api_set_grant_config( UINT64 sfc, UINT8 ch, int n_of_configs, grant_config_t
grant_config[]);
Arguments:
UINT64 sfc; /* Superframe counter value. Ignored in IEEE802.3 */
UINT8 ch; /* Downstream wavelength channel. If necessary. */
int n_of_configs; /* Number of grants in this API. */
grant_config_t grant_config[]; /* Grant */
typedef struct{ /* IEEE802.3 ITU-T G.989.3 */
UINT16 id; /* LLID Alloc-ID */
UINT8 flags; /* Flags Flags/FWI/Burst Profile */
UINT32 grant_start_time; /* Grant Start Time Start Time */
UINT16 grant_length; /* Grant Length GrantSize */
}grant_config_t;
Description:
Through this API, DBA function in API upper side directly notifies grant value to building message
function in API lower side. API lower side builds grant messages based on received grant value, and
sends the messages to connected ONUs.
< IEEE 802.3 >
As IEEE 802.3 Ethernet PON, OLT sends GATE message to ONU to grant of ONU upstream
transmission. Destination ONU is identified by LLID value stored in preamble of the sent GATE
message. Time when the ONU starts to transmit is notified by grant_start_time field. Amount of
granted transmission is notified by grant_length field. GATE message has several types of grant such
FASA-White Paper Ver. 2.0
32 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
as discovery GATE and forcing REPORT message transmission. One GATE message can carry up to
four grants. DBA function as FASA application in API upper side expects following works for the
lower processing unit.
- Ignoring argument sfc value and argument ch value.
- One argument grant_config value corresponds to one grant (a pair of grant_start_time and
grant_length). Argument n_of_configs means number of grants.
- Transforming argument id to LLID in GATE message.
- Transforming lowest bit of argument flags to discovery flag and second bit to force report.
- Transforming argument grant_start_time to Grant Start Time.
- Transforming argument grant_length to Grant Length.
- When single id (LLID) has several grant_config, make a GATE message carry as much grant as
possible. Calculating number of grants and force report value in the GATE message.
- The lower processing unit immediately sends constructed GATE message, after receiving this
API and parsing arguments.
It is assumed that DBA function in API upper side knows following information by other processes:
current MPCP local time, ONU identification, numbering LLID, RTT of ONUs, link status and so on.
Also, it is assumed that DBA function API upper side is notified DBA configurations of every ONU
/ LLID.
< ITU-T G.989.3 >
As ITU-T G.989.3, sending BWmap to ONUs grants upstream traffic. A BWmap field has one or
several allocation structures. An allocation structure filed has a grant. A grant has StartTime filed and
GrantSize field. DBA function in API upper side expects following works for API lower side.
- Building BWmap in downstream PHY frame which has equal super frame counter to argument
sfc value.
- Sending built BWmap to downstream DWLCH_ID channel indicated argument ch value. This
argument is valid only for TWDM.
- Parsing argument as following: an element of grant_config array means an allocation structure.
Argument n_of_configs means number of allocation structure in the BWmap.
- Transforming argument id to Alloc-ID in the allocation structure.
- Transforming argument flags to PLOAMu, DBRu, FWI and Burst Profile in Flags field in the
allocation structure.
- Transforming argument grant_start_time to StartTime in the allocation structure.
FASA-White Paper Ver. 2.0
33 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
- Transforming argument grant_length to GrantSize in the allocation structure.
- Calculating HEC in the allocation structure.
It is assumed that DBA function in API upper side knows following information by other processes:
current value of super frame counter, ONU identification, numbering Alloc-ID, RTT of ONUs, link
status and so on. Also, it is assumed that DBA function API upper side is notified DBA
configurations of every Alloc-ID.
5.2.1.5.2 Request information API
Format:
fasa_api_get_onu_request( UINT64 sfc, UINT8 ch, int n_of_configs, request_config_t
request_config[]);
Arguments:
UINT64 sfc; /* Superframe counter value. Ignored in IEEE802.3. */
UINT8 ch; /* Upstream wavelength channel. If necessary.*/
int n_of_requests; /* Number of requests in this API */
request_config_t request_config[]; /* Request */
typedef struct{ /* IEEE802.3 ITU-T G.989.3 */
UINT16 id; /* LLID ONU-ID */
UINT8 flags; /* QSet/Qreport number Ind */
UINT32 request; /* queue report BufOcc */
}request_config_t;
Description:
Through this API, DBA function in API upper side directly reads requests from receiving and storing
message function in API lower side. API lower side receives and stores request messages from
ONUs. This API forms polling function style, not callback function at current version.
< IEEE 802.3 >
As IEEE802.3 Ethernet PON, ONU requests upstream transmitting to the OLT by sending
REPORT message. Source ONU is identified by LLID in preamble of REPORT message.
A REPORT message has one or more Queue Set that consists of a set of Report bitmap and Queue
Report. Number of queue sets field in REPORT message means number of Queue Set in the
FASA-White Paper Ver. 2.0
34 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
message.
Value in Queue Report field means amount of ONU requests transmitting. One Queue Set can
carry up to eight types of Queue Reports. REPORT message can notify only Queue Report types that
holds request value. Report bitmap value shows which type of Queue Report holds request.
The lower processing unit that receives order via this API return information related upstream
request and DBA function as FASA application in API upper side expects following works for the
lower processing unit.
- Storing received request information from ONUs: LLID, Queue Set number, Queue Report
number and queue report value they indicate.
- Returning these three types of information as argument request_config.
- Setting LLID value to argument id.
- Setting Queue Report number 0 to 7 to lower bits of argument flags.
- Setting Queue Set number upper bits of argument flags.
- Setting Queue Report value above indicate to argument request.
- Return these information via this API. Delete or overwrite them by new information after
returning.
- Setting value of MPCP local time which is most recently received REPORT message to
argument sfc.
It is assumed that DBA function as FASA application knows following information by other
processes: current value of MPCP local time, ONU identification, numbering LLID, RTT of ONUs,
link status and so on. Also, it is assumed that DBA function API upper side is notified DBA
configurations of every ONU / LLID.
< ITU-T G.989.3 >
As ITU-T G.989.3, ONUs notify BufOcc in DBRu field as request of upstream traffic to connected
OLT. Sender ONUs are identified by ONU-ID value in FS header. Also, ONUs notify waiting
upstream PLOAM message by PLOAM queue status bit in Ind filed in FS header. DBA function in
API upper side expects following works for API lower side.
- Storing received request information from ONUs: ONU-ID, BufOcc and PLOAM queue status.
- Returning these three types of information as argument request_config.
- Setting ONU-ID value to argument id.
- Setting PLOAM queue status bit to argument flags.
- Setting BufOcc value to argument request.
FASA-White Paper Ver. 2.0
35 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
- Storing BufOcc value in order of receiving if a upstream burst has several allocations.
- Setting value of super frame counter which is most recently received BufOcc to argument sfc.
It is assumed that DBA function in API upper side knows following information by other processes:
current value of super frame counter, ONU identification, numbering Alloc-ID, RTT of ONUs, link
status and so on. Also, it is assumed that DBA function API upper side is notified DBA
configurations of every Alloc-ID.
5.3. L2 Data Signal Processing Function
Layer 2 data signal processing function transports upstream and downstream traffic to proper port.
Therefore, FASA applications receive order from EMS or controller via Netconf / YANG or
Openflow. Based on this order, FASA applications configure transport settings, monitor statistics and
order ONU transport settings. The first two are processes of transporting configurations based on
YANG model to the lower processing unit. The last one is a process to build message to ONU and
order the lower processing unit to transmit the message.
TBD
5.4. Maintenance and Operation Function
Functions of maintenance and operation to an OLT can be roughly divided to below two. They are
configuration and order of OLT, monitor OLT and ONU state. The first one is that FASA
applications receive order from EMS or controller via Netconf and transport them to the lower
processing unit based on YANG model. The second one is that FASA applications read OLT and
ONU state based on YANG model or OAM / OMCI message from the lower processing unit and
transport them to EMS or controller via Netconf.
TBD
5.5. PON Multicast Function
As mainly used for video streaming service, PON multicast function has several ways. This
section describes overviews of the ways, work of FASA application and the lower processing unit,
flow of message.
TBD
5.5.1 Overview of PON multicast
Multicast is a method to broadcast same information to one or more destinations. In general,
FASA-White Paper Ver. 2.0
36 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
multicast stream forwarding destination is dynamically controlled based on join request and leave
request from multicast device to the multicast group. Messages of join request, leave request and
control are generally IGMPv3 protocol for IPv4 and MLDv2 protocol for IPv6.
Making multicast function work properly in TDM-PON system, it is necessary some technique,
since physical downstream direction is broadcast and logical one is unicast in TDM-PON.
There are three methods PON multicast. The first one is multicasting by upper network node. The
second one is ONU snooping. The last one is OLT proxy. Below subsection describes them.
5.5.2 Multicasting by upper network node
In method of multicasting by upper network node, ONUs and OLT are configured as transport
upstream IGMP / MLD message transparently. When an upper network node that connected to the
OLT receives join request message forward multicast stream to the device that sent join request
message. If this node receives several join requests for one multicast group from different devices
via one OLT, this node forwards the multicast stream to each device. It means this nodes sends
multiple same stream to each device via the OLT as individual unicast.
When multiple devices connected to same ONU request to join a same multicast group, mechanism
is different depending multicast function ONU or lower device has. When they have multicast
routing function, the function forward multicast stream to a second device that sent join request for
same multicast group first device joined without transport the request to the OLT. On the other hand,
when they have no multicast routing function, the upper network node forward the multicast stream
to each devices.
5.5.3 ONU Snooping
ONU snooping is a method of PON multicast. An ONU snoops contents of IGMP or MLD message
device sent as join request or leave request.
In this method, the OLT is configured to forward multicast stream to all ONUs. ONU controls
own downstream filter based on contents of ONU snooped IGMP / MLD message. When the
contents means join request, the ONU open the filter to forward multicast stream to the device.
When the contents means leave request, the ONU close the filter to discard multicast stream. The
ONU filter can be various types such as IP address, MAC address, VLAN tag or other identification
as long as it is predetermined.
Above this, controlling ONU filter dynamically makes PON multicast possible.
FASA application receives configuration or service order to enable / disable ONU snooping
function from EMS or controller. Then, a FASA application orders the lower processing unit to
FASA-White Paper Ver. 2.0
37 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
transmit ONU control message in extended OAM or OMCI via API. The lower processing sends
ordered message to the ONU for controlling snooping function.
5.5.4 OLT proxy
One of PON multicast method is OLT proxy. In this method, OLT aggregates IGMP / MLD
messages the OLT receives to forward them as proxy and controls ONU downstream filter.
When the OLT receives IGMP / MLD message, the OLT forwards it to the upper network node as
proxy if necessary. Multicast streams are configured that all ONU can receive in advance. When the
OLT receives join request from a device connected to an ONU, the OLT order the ONU to open a
downstream filter of the multicast group the device requested to join. When the OLT revives leave
request, the OLT order the ONU to close the filter. Above them makes PON multicast possible.
OLT can control ONU filter and forwarding message to the upper network node for more effective
streaming.
FASA application configure forwarding table of OLT that FASA application itself receives
upstream IGMP / MLD message and can forward it to the upper network node. The FASA
application receives this configuration order from EMS or controller via Netconf / YANG or
Openflow protocol. Configuration of multicast downstream is also from EMS or controller.
When the FASA application receives IGMP / MLD message, the FASA application order the
lower processing unit to send a message of opening filter or closing filter to the ONU via the API.
5.6. Power-Saving Control Function
Power-Saving control function is to save ONU power consumption by controlling ONU power
suppling to ONU internal function blocks. FASA application receives configuration of power saving
or service order from EMS or controller and order the lower processing unit to send extended OAM /
OMCI message based on contents of the configuration or the service order. FASA application
receives indication of status change by PLOAM from the lower processing unit.
On the other hand, it may be necessary to have function of direct control to ONU power saving. In
this case, FASA application needs to build message to ONU and order the lower processing unit to
send it with real-time processing. It also needs to read message with real-time processing.
TBD
FASA-White Paper Ver. 2.0
38 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
5.7. Frequency/Time-of-Day Synchronization Function
Frequency / Time-of-Day synchronization function is to distribute accurate base clock signal and
time information signal that are input to OLT and output from ONU. FASA application configures
ONU function of signal output by building message and ordering the lower processing unit to send it
via API.
TBD
5.8. Protection Function
TBD
5.9 Function of cooperating with external equipment
A function such as low latency DBA for mobile service described above that cooperates with
external equipment, may be necessary. For such function, FASA application needs to receive
messages from the external equipment.
FASA application receives and parses the message without the lower processing unit parsing,
since such receiving function depends on implementation, connecting architecture and message
format. It can be considered that implemented general OS has enough function. However, if
necessary in future study, original FASA application API needs to be defined.
6 Summary
This document shows FASA concept, architecture, logic model and interfaces between functions.
FASA-White Paper Ver. 2.0
39 Copyright(c) 2016-2017 NTT Corp. All Rights Reserved.
Note: In the event of any discrepancy between this translated document and the Japanese original,
the original shall prevail.