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

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