You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »



Analytics as a Service Closer to Edges

Problem Statement:

  • The goal of Analytics as a Service closer to edges is address edge Scalability, Constrained Environment and Service Assurance Requirements.

    • Avoid sending large amount of data to ONAP-Central for training, by letting training happen near the data source (Cloud-regions).
    • ONAP scale-out performance, by distributing some functions out of ONAP-Central such as Analytics
    • Letting inferencing happen closer to the edges/cloud-regions for future closed loop operations, thereby reducing the latency for closed loop.
  • Reference: ONAP-edge-automation-update-arch-use-case-10-23-2018.pdf
  • 5G use case relevance

Architecture Scope:

  • Instantiation of edge and connectivity to ONAP central (out of scope for ONAP)

  • Edge Cloud Registration [Ref. Arch. Impact Details (1)]
    • Automation of registration when scale (>100s)
  • ONAP edge functions or 3rd party edge functions deployed at edge (e.g. Analytics, Closed Loop Control) [Ref. Arch. Impact Details (21 , 22)]
    • Registration of the edge functions to ONAP central (Intent, capabilities, capacity)
      • Intent Example: “Infrastructure Analytics as service for Alerts at Cluster Level and Host Level”
  • Deploy Network Services in an optimal way to the edges using edge/central functions [Ref. Arch. Impact Details (3)]
    • Includes multiple VNFs on multiple edges/core which make a service
    • Cloud region (means one control plane) choice
    • Connect the service to the functions
  • Networking of ONAP Central and edge functions [Ref. Arch. Impact Details (5)]

    Reference: ONAP-edge-automation-update-arch-10-29-2018-followup-11-07-2018.pptx

ONAPARC-280 - Getting issue details... STATUS

ONAPARC-317 - Getting issue details... STATUS

ONAP-based Analytics as a Service Details: (see Distributed_analytics_v3.pptx in Edge Automation through ONAP)


  • What does ONAP-based Analytics Service encompass?
    • Support analytics-as-a-service in the cloud-regions that have K8S site orchestrator.
    • Use same analytics framework to have analytics even in ONAP-Central.
    • Two packages - Standard package and inferencing package.
    • Use existing analytics applications - TCA to prove this framework.
    • As a stretch - Showcase one ML based applications
      • Training application
      • Inferencing application
  • How to Develop?
    • Use PNDA as a base
    • Create/adapt Helm charts
    • Ensure that no HEAT based deployment is necessary.
    • Use components that are needed for normal analytics as well ML based analytics (Apache Spark latest stable release, HDFS, OpenTSDB, Kafka, Avro schema etc..)
    • Use some PNDA  specific packages - Deployment manager as one example.
    • Develop new software components
      • that allow distribution of analytics applications to various analytics instances
      • that allow onboarding new analytics applications and models.
      • that integrates with CLAMP framework (if needed)
  • Impacted ONAP Projects
    • DCAE, CLAMP, A&AI (TBD), Multi-VIM/Cloud (TBD)
  • How to Test?
    • TCA (Changes - Convert this as a spark application) 

    • New Machine learning models for KPI (packet loss) prediction (New use case)


Fine Grained Placement Service (F-GPS)



  • No labels