The key software elements in the OLT are:   OpenNetworkLinux as base operating system ONLP drivers and API to access board hardware (SFP/XFP, PSU/fAN status/control, timing, etc) Redfish to provide REST API access to ONLP devices Broadcom PON solution software stack (BAL, Maple SDK, Qumran SDK) Board Support: ONIE boot/SW installer, HW diag utilities BAL application containing gRPC server/client facing vOLTHA adapter The key functions of asfvolt16 vOLTHA adapter: Mapping vOLTHA IAdapterInterface/IAdapterAgent to appropriate BAL calls Define protobufs required to map BAL object properties and indications (including alarms and statistics related to KPIs) Define gRPC calls to access BAL api in OLT Monitor OLT health via Redfish data model and raise environment/equipment alarms, OLT reboot, OLT software update/activation, etc.

Comments:   Primary OLT control is intended via BAL API BAL may not provide all PON functionality required Ad-hoc Maple access “fudged” mechanism may be required if BAL is not enough New PON Management interface in voltha adapter will determine what is needed Is BRCM OMCI stack needed in ASFvOLT16 or is send/receive_proxied_message enough? Board HW config/monitor and equipment/environment alarms is outside of BAL domain. Use Redfish for this. Could be lower priority work decoupled from BAL Broadcom in-OLT components should be available for development and diagnostic use E.g., bcm_user_appl, bcm_cli, bcm_sdn_agent voltha_bal_driver can coexist with running BRCM debug CLI How will asfvolt16 adapter discover and bind to the OLTs? VOL-284 defines IP address/OLT assignment