WT-477 rev 38 allows an option to deploy the D-OLT (Disaggregated OLT) into the BAA layer:

Source: WT-477 rev 38, Figure 2 - Disaggregated OLT in CloudCO

The list of functions that can be virtualized into the D-OLT is defined in section 4.2:

OB-BAA includes a reference implementation of a PPPoE Intermediate Agent VNF conforming to WT-477.

General architecture

The general architecture of OB-BAA with the PPPoE VNF is depicted in the figure below:

The aggregator component exposes the Minf interface for devices and Network Functions (including vOMCI, vProxy, and WT-477). The OB-BAA core receives the NETCONF requests from the Access SDN M&C and forwards them to the correct entity.

The adapter concept that already exists for devices can be used between the OB-BAA core and the Network Functions to support multiple protocols.

In this release, only the TR-451 MvOLTMF-vOMCI protocol (kafka based) is supported between the OB-BAA core and the Network Functions.

Architecture of the PPPoE VNF

The PPPoE IA runs as standalone container and exposes two interfaces:

As mentioned in the previous section, the NETCONF requests received from the Access SDN M&C are received by the BAA core and converted to JSON and sent over Kafka encoded in GPB (protobuf) to the PPPoE VNF. The PPPoE VNF exposes the YANG data model defined by WT-477 (Straw ballot).

In the southbound, the PPPoE VNF can receive packets directly from the pOLT or via Control relay using a WT-477 compliant Mfc_CPRI interface. The operations performed by the PPPoE VNF are described in WT-477 rev38, section 4.5.2 (PPPoE IA call flow).

The persistence of the PPPoE VNF data is handled by a MongoDB.