Flexible Access System Architecture (FASA) White Paper › img › fasa ›...

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.



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



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



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



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



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



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.


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.


Fig. 1.2.






the modularization


onfiguration 1 in Fig. 1.2.


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






the modularization of each function provided on the FASA Platform (


onfiguration 1 in Fig. 1.2.-3.


API: The common

FASA Application: The rep

Application APIs.



iddleware for the FASA Application APIs:



FASA Applications.

communication of FASA Applications and

FASA-White Paper Ver.

4. An example of the conce






of each function provided on the FASA Platform (

is left out of the scope of this document. Specifically this document focuses on


The common term of the

FASA Application: The replaceable software modules



the FASA Application APIs:



. The middleware

of FASA Applications and

White Paper Ver.

8

4. An example of the concept of modularization on the FASA Platform


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




Specifically this document focuses on


term of the APIs used for FASA.

laceable software modules


the FASA Application APIs: In



The middleware also

of FASA Applications and

White Paper Ver. 2.0

Copyright(c) 201

pt of modularization on the FASA Platform


based access network system, system architecture

FASA Applications, and the FASA Application





APIs used for FASA.

laceable software modules implement


In the FASA Platforms, the software that


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








of each function provided on the FASA Platform (configuration 2 in Fig. 1.2.


implemented by using the FASA


the FASA Platforms, the software that


function communication among

provides the means for inter

functions in FASA Platforms

NTT Corp. All Rights Reserved.






onfiguration 2 in Fig. 1.2.

Specifically this document focuses on the PON OLT in

ed by using the FASA





provides the means for inter-function

FASA Platforms






onfiguration 2 in Fig. 1.2.-3)

the PON OLT in

ed by using the FASA





function

FASA Platforms. The



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



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



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”



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.



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.



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



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



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.



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


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


The first NSR-DBA uses the statistical data of traffic to estimate the TDD cycle of the




The second NSR




F

Fig. 3.1.1.1.

DBA for MFH

1 overviews an example of two types of NSR


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


DBA uses the statistical data of traffic to estimate the TDD cycle of the




The second NSR-DBA focuses on t





Fig. 3.1.1.1.-1 Optical

DBA for MFH





ively assigned bandwidth generated with FBA, and the efficiency of the





DBA focuses on the fact that the




Fig. 3.1.1.2.

White Paper Ver.

18

1 Optical-mobile cooperative DBA for MFH


(which offers fixed bandwidth assignment) removes the roundtrip delay of the control signal



assigned bandwidth generated with FBA, and the efficiency of the





he fact that there is similarity




Fig. 3.1.1.2.-1. NSR-DBA for MFH


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








re is similarity in



DBA for MFH

.0


mobile cooperative DBA for MFH

DBA for MFH. Here, NSR









in traffic pattern


period based on the statistical traffic information [7]. This DBA needs an API that enable


DBA for MFH. Here, NSR


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


DBA uses the statistical data of traffic to estimate the TDD cycle of the TDD



pattern if observed using


API that enables the use of


DBA for MFH. Here, NSR-DBA


required for

DBA is


TDD-type



if observed using


s the use of



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.



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.


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


TBD

. Satisfaction



example, a protection

equipment failure. In






rdance with different policies; therefore, in FASA, an API for protection is specified.



hown in Table 4.

below.


F

Fig. 3.1.4.

Satisfaction of Requirements


Satisfaction of Requirements



, a protection function

failure. In addition









hown in Table 4.-1. First of all, the main functions of the access



Fig. 3.1.4.-2. Definitions of the functional parts

Requirements


Requirements



is essential to reduce the interruption time of the

addition, to provide service reliability during software updates on access







The main functions of the access network

1. First of all, the main functions of the access


White Paper Ver.

21

2. Definitions of the functional parts

Specific


Specific



o provide service reliability during software updates on access







network system and the target of the FASA applications are




Copyright(c) 201


to Telecommunications Carrier by

to Telecommunications





necessary to execute the remedial operations without interrupting the service; therefore, a protection





system and the target of the FASA applications are



.0




to Telecommunications


is essential to reduce the interruption time of the service



e service; therefore, a protection






1. First of all, the main functions of the access network system are described




to Telecommunications Carrier


service in case of the









system are described




Carrier by

The requirements of telecommunications carriers include the high access network availability. For

in case of the


network elements as well as migration to new hardware with enhanced processing functions, it is





system are described




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.



Table 4.-1 The Main Functions of Access Network System and the Target of FASA Applications



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



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



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.


TBD


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


TBD


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



MFH, the NSR-DBA for MFH, the SR


FASA application). This document assumes a DBA application with event

The API is, regardless


DBA application

"set_GrantSizeAndStartTime" are commonly used by DBA applications, while

F

Figure 5.0.5



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



DBA for MFH, the SR



The API is, regardless of the FASA Application (the DBA application), a common API set. In


DBA application. For example, "get_AllocationDbaConfig," "set_GrantSize," and

SizeAndStartTime" are commonly used by DBA applications, while


Figure 5.0.5-1 Roughly divided interfaces




DBA for MFH, the SR


FASA application)). The column "Use cases" in the tab



DBA for MFH, the SR-DBA for resi

FASA application), and the SR-DBA for residential


of the FASA Application (the DBA application), a common API set. In


For example, "get_AllocationDbaConfig," "set_GrantSize," and


White Paper Ver.

27

1 Roughly divided interfaces



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




DBA for residential use (the DBA fully implemented as

DBA for residential use (the DBA function partially implemented as







Copyright(c) 201



DBA for residential use (the DBA function fully

DBA for residential use (the DBA function




dential use (the DBA fully implemented as

se (the DBA function partially implemented as






.0



1 shows the API list for each use case of DBA (the optical-mobile cooperative DB





"2," "3a," and "3b" in "Use cases" are used, respectively, for the optical-mobile cooperative DBA for



FASA application). This document assumes a DBA application with event-driven architecture.






mobile cooperative DB



FASA application)). The column "Use cases" in the table shows the


mobile cooperative DBA for



driven architecture.






mobile cooperative DBA



le shows the


mobile cooperative DBA for

dential use (the DBA fully implemented as a


driven architecture.







"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.



Table 5.2.1.-1. The API of the DBA



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



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



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.



- Transforming argument grant_length to GrantSize in the allocation structure.

- Calculating HEC in the allocation structure.


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



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.



- 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.


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,



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



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



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.



Note: In the event of any discrepancy between this translated document and the Japanese original,

the original shall prevail.

Flexible Access System Architecture (FASA) White Paper › img › fasa ›...

Documents

Transcript of Flexible Access System Architecture (FASA) White Paper › img › fasa ›...