( by Vijay Venkatesh Kumar, Wen Shang, Ashoke Sharma, Shrikant Acharya, Diana Zhang)


Network Topology can evolve over time, so there is a need for platforms to be able to receive these updates and take appropriate actions. From a DCAE standpoint, as new xNF gets instantiated, DCAE MS may need to be reconfigured to poll data from new sources. A new DCAE platform components – ONAP Topology Interface (OTI) will listen on external topology updates and determine MS to be reconfigured/instantiated and trigger updates via other DCAE platform components.

High Level Architecture

OTI Architecture

OTI Data Flow via API (Use Case 1) - consists of two components: OTI-event-proc microservice and OTI-handler microservice.  This user case not only can be used for real-time data collection, but also can support load balancing, auto scaling within the Kubernetes Cluster and Geo resiliency cross the regions (future release).  

  • OTI-event-proc can:

-Subscribe topology events ( vendor-based-format or common-format-event) from  DMaaP-MR.

-Parse and process the event based on event-handler-template defined in Policy.

-Look up the xNF associated  data collection tasks defined in policy.

-Generate ‘dcae-collection-event’ that includes xNF instance topology and associated collection tasks. The ‘dcae-collection-event’ will be in VES like standard format.

-POST the ‘dcae-collection-event’ to OTI-Handler via API (US1).  Or publish 'dcae-collection-event' to DMaaP-MR (US 2).

-Store the ‘dcae-collection-event’ into ONAP-PG DB.

  • OTI-handler  can POST/Dispatch the ‘dcae-collection-event’ to a defined Kubernetes Cluster in a DCAE region based on xNF location with low-latency.  A LB in each K8s cluster sends this xNF collection request to a corresponding collector mS ( with Sidecar)  based on the LB algorithm.  Below is the high level diagram. Detail diagrams are in late section.

      OTI Data Flow via DMaaP-MR  (Use Case 2) - a simplified solution that includes OTI-event-process microservice only. 

      OTI processes the topology information and publishes the 'dcae-collection-event' to DMaaP. Collector microservice shall be able to subscribe the event and to perform defined collection based on the 'dcae-collection-event' payload information.

Below diagram shows the details interfaces of OTI-event-process, OTI-Handler, load balances, sidecar, and collector microservices.

µS refers to a data collector microservices, e.g.  snmp-poller, FOI (sftp-file-collector), gRPC_collector (gNMI_client_collector).


  • MS must periodically look for files published under /otidata/process directory every 30 seconds (configurable) for the incoming OTI event update from sidecar.  MS updates the Task.json/OTI_config.json based the event and does the collection based on Task.json.
  • MS should select statefulset (sidecar) checkbox property during onboarding (to indicate to platform it will be deployed as stateful set/OTI solution).
  • MS is updated to call CBS API to retrieve the KV_Config in K8s.


Use Case 2 - DCAE MS (e.g. snmp-polling) shall subscribe 'dcae-collection-event' via DMaaP-MR and use the provided information ( vnf/pnf name, collection ip, collection tasks etc) for data collection.  DCAE MS shall publish the output data into DMaaP-MR.

Targeted Usecase (Frankfurt)

UC1a, UC1b and  UC2a (question) are targeted Use cases for Frankfurt.


Usecase Name



Add xNF_TYPE Configuration

Collection Task & xNF Configuration-driven for automatically data collection


Add xNF instance

Support Real-time Data Collection for New xNF Instance

UC1cDelete VNF instanceSuspend data-collection for deleted xNF instance



Support Collector Resiliency Across Multiple Sites

UC1eLoad balancingSupport Load Balance Across Multiple Sites for polling based collectors
UC2aAdd xNF data Collection via DMaaP-MRSupport Collector Microservice data collection that doesn't have K8s's and Sidecar architecture case.
UC2bDFC Integration

Integration with 5G BulkPM usecase (synthetic FileReady and distributed MR/DR )

  • No labels

1 Comment

  1. One question to this... Assuming that is related to Mutli-site DCAE (and it looks like it is,,,)
    What about DMaaP (-MR, -DR) in such an environment?

    I can imagine, that we`d have at least collectors and analytics hosted in a kind of Mobile Edge Cloud instances. These communicate over DMaaP (MR/DR/Kafka).
    I think, there is little sense of collecting the data in MEC instances, sending these data to centralized DMaaP instances, and getting them back on MEC deployed analytics. Same with Mappers.

    What about DMaaP-MR/DR/Kafka in such regional/distributed Kubernetes clusters?
    (Other than that the general ideal of OTI looks to be good - in bringing the DCAE platform closer to NFs generating large amounts of data.)