1. Oracle Communications Networks Data Analytics Function Solution Guide
  2. OCNWDAF Architecture

2 OCNWDAF Architecture

This chapter describes the Oracle Communications Network Data Analytics Function (OCNWDAF) architecture.

2.1 Oracle Communications Networks Data Analytics Function Architecture

The figure below depicts a high-level functional architecture of the OCNWDAF. The product comprises of a 3GPP gateway at the front end and an analytics platform at the backend. The 3GPP Front End (FE) is called the OCNWDAF FE, and the backend analytics platform is called the Converged Analytics Platform for Communication (CAP4C). All the Network Functions (NFs) offered by Oracle are developed based on a Cloud Native architecture. They operate in a container based Cloud Native Environment (CNE), and the OCNWDAF is no exception.

Figure 2-1 OCNWDAF Architecture


OCNWDAF Architecture

OCNWDAF Front End

  • Collects data from 5G NFs
  • Provides the data to backend CAP4C
  • Collects the processed analytics information from CAP4C
  • Provides the analytics information to the consumer NFs and AFs

Converged Analytics Platform for Communication (CAP4C)

  • Processes data from the Front End (FE)
  • Examines streaming data in real time to enable thresholding and other uses
  • Implements OCNWDAF analytics information (Statistical, Predictive, and Abnormal Behavior)
  • Automates machine learning models
  • Provides visualization and reports

OCNWDAF Detailed Design

The OCNWDAF detailed design is depicted in the diagram below:

Figure 2-2 OCNWDAF Design


OCNWDAF Design

The OCNWDAF current architecture is aligned with 3GPP Release 16 but supports some common features in Release 17 such as Slice Load Level Analytics.

OCNWDAF Front End

The Front End (FE) interacts with 5G NFs to gather information. The OCNWDAF interacts with 5G NFs through the Service Based Architecture (SBA) or Service Based Interface (SBI) as defined in 3GPP TS 23.288 and TS 29.520.

Described below are the specialized OC-NWDAF microservices:

Note:

Some common services are also described below. The common services can be used by other 5G NFs along with OCNWDAF.

Ingress Gateway

The common Ingress gateway is refined to benefit from standard functionality such as ingress connection management, TLS1.2, and OAuth2.0

Egress Gateway

The common Egress gateway is refined to benefit from standard functionality such as egress connection management, including indirect communication, TLS1.2 and OAuth2.0, retry and reroute.

Scheduler

Offers scheduling services for timed events such as periodic consumer report notifications.

Model Manager

Tracks the consumer analytics requests, timeframe and data items required within the training data set to the respective ML models. Sends requests of models to be trained to the CAP4C and tracks the ML models that CAP4C builds.

Analytics Subscription Service

Enables service consumers to subscribe or unsubscribe to different analytics from the OCNWDAF. It handles all the subscription requests from the consumers and updates or cancels the subscription requests from the consumers. The network analytics subscription service sends analytics information notifications to the NFs, AFs, and OAM when the subscribed event occurs in the network.

Analytics Information Service

This service enables consumers to request and obtain different analytics information from the OCNWDAF based on the 3GPP defined AnalyticsInfo API. This service is based on the REST API request-response model. The network analytics information service handles the request for analytics based on the AnalyticsID. The service responds to the request and provides the analytics information if the requested analytics are available.

Data Collection Service

For 3GPP 5G sources, the Data Collection service enables the OCNWDAF to retrieve data from various sources (for example, NFs such as AMF and SMF), this data is used for computation of network analytics. The Data Collection Service ensures the OCNWDAF efficiently obtains the appropriate data with the proper granularity.

The Data Collection Controller and Data Collector microservices together form the Data Collection Service of the OCNWDAF. Data is collected to generate predictive and descriptive analytics based on analyticsID. The OCNWDAF subscribes to (or cancels subscription) a Event ID (or set of Event IDs) by invoking the Nnf_EventExposure_Subscribe (or Nnf_EventExposure_Unsubscribe) service operation. If OCNWDAF subscribes to a Event ID (or set of EventIDs), the NFs notify the OCNWDAF by invoking Nnf_EventExposure_Notify service operation. For example, the NFs can notify the OCNWDAF with a event report.

  • Data Collection Control Service: This service interacts with producer NFs to manage their subscriptions. This service also monitors and updates the consumers subscription information.

  • Data Collector Service: This service receives data from the producer NFs and streams data to the CAP4C Analytics Engine.

Converged Analytics Platform for Communication (CAP4C)

The Analytics Engine (CAP4C) is the core of OCNWDAF, which supports data collection through the Front End (FE) module. The data collected is processed with the help of ML models. Predictive or descriptive data analysis is performed and data is transmitted through real-time stream processing.

Listed below are the OCNWDAF specific microservices (along with the common microservices):

  • Ingress and Egress Gateways: In the OCNWDAF FE.
  • DBTier MySQL database: Is used for general configuration, storage of microservice data (including dynamic state data) and ML models. Some specialized reports are also generated using the DBTier.
  • Time-Series database: This database stores all the time-series data used for statistical reports and ML model datasets. Supports data roll-up (such as 1 up to 5 minute samples, 5 up to 15-minute samples, 15 minutes up to an hour sample and so on), allowing the storage of much older data in an efficient manner. Allows for fast and efficient data culling.
  • Kafka: Is the internal messaging structure. It exports special measurements and events to external consumers. It also imports measurements and events from operator sources such as a messaging bus and data lake.
  • Stream Processors: Cleans, merges, and splits data as required and examines data in windows to detect threshold crossings or perform complex calculations.
  • Model Controller: Receives model generation or execution requests from the OCNWDAF FE. The Model Controller manages and directs work to the Executor pool.
  • Model Executor: Is a variable pool of resources that trains or executes models.
  • OCNWDAF Portal: Performs the following functions:
    • Manages the OCNWDAF dashboards
    • Accepts operator input for configuration
    • Observes the time-series DB to change the display according to the change in the DB
    • Provides visualization of analytics information

2.2 OCNWDAF Architecture Principles

The OCNWDAF is built using Cloud Native principles. The OCNWDAF is deployed as Cloud Native Core Network Function (NF), similar to other 5G NFs. The OCNWDAF follows best practices for both the industry and customers. For example:

  • OCNWDAF is based on the microservice architecture. The Front End (FE) and Converged Analytics Platform for Communication (CAP4C) are built using a set of microservices.
  • The microservices are designed to perform one specific task or job.
  • The microservices interact through standard interfaces (HTTP or messaging through Kafka).
  • The microservices can be scaled up or down according to Kubernetes programmed rules.
  • No root or elevated access is required.

Modular, Flexible, and Scalable Architecture

The flexibility of an analytics solution depends on the following factors:

  • Flexibility in data collection or ingestion
  • Ability to support diversified use cases
  • Availability of analytics feed to the consumer (on demand, periodic, so on)

The OCNWDAF supports the above mentioned characteristics beyond what is defined in 3GPP Technical Specification for Data Analytics NFs.

  • To support diversified use cases (for example, other than those defined by 3GPP), OCNWDAFs concept of separation of CAP4C from the FE provides the flexibility to support any use case category. The flexibility in creating ML models, training or retraining, model validation and benchmarking, and automated deployment make OCNWDAF the best breed.
  • OCNWDAF provides the analytics report (on demand or periodic) to the consumers in different ways. For example, in the case of 3GPP network elements, the analytics report is provided through 3GPP defined (TS 23.288, TS 29.520) SBI interface.
  • The OCNWDAF is evolving along the lines of 3GPP specifications and customer use case requirements. OCNWDAF is developed as an open and flexible analytics platform to meet customers' future use case requirements.
  • The entire OCNWDAF functionality is modular and independent. Interactions between these entities are enabled through REST APIs, the streaming framework, the time-series database, or the DBTier. Direct messaging through REST (where synchronous communication is necessary) or messaging through Kafka (when the communication is asynchronous). Configuration data, dynamic data, and time-based data is stored by one entity and can be accessed by another for usage or display.