3 OCNWDAF Features

This section explains the OCNWDAF features.

3.1 Machine Learning (ML) Model Evaluation and Selection

Machine Learning (ML) models are programs trained to identify patterns within data sets. Data sets contain historical data and vary based on region, use case, and service provider. ML algorithms analyze and detect patterns within a data set to train ML models. Trained ML models predict analytics based on the input data.

Algorithms are selected based on the data set and use case. Accordingly, different algorithms are effective in distinct scenarios. To obtain accurate predictions, users must retrain the ML models frequently. Users have flexibility in selecting, optimizing, testing, and training ML models.

The OCNWDAF provides a GUI dashboard to select, train, and optimize one or more ML Models for a given analytics category. The user can select among multiple algorithms supported by each analytics category and run experiments to determine the best-suited ML model for each data set. ML models are evaluated by running experiments and metrics are generated. Metrics for each experiment is displayed on the dashboard. User can select the ML model based on these metrics. Multiple algorithms can be selected simultaneously to run experiments.

To access the ML Model Selector page and perform ML model evaluation on the OCNWDAF GUI, see Machine Learning (ML) Model Selector.

3.2 Network Performance Visualization on the OCNWDAF Dashboard

The OCNWDAF provides network performance analytics to the consumer. The analytics information primarily includes resource consumption by gNodeB (gNB) and mobility performance indicators in the Area of Interest (AoI). The users can access the following network performance analytics on the OCNWDAF GUI:

  • All available cells in a selected Tracking Area
  • For each cell, the user can view the following information:
    • GNB Computing, Memory, and Disk Usage
    • Session Success Ratio
    • HO Success Ratio
  • The user can set a threshold value, select a tracking area and a time interval in the GUI. All the available cells in the selected tracking area within the selected time interval and specified threshold value are displayed on the screen.

For more information, see Monitoring page in the OCNWDAF GUI.

3.3 Service Mesh for Intra-NF Communication

OCNWDAF leverages the service mesh support for all internal and external communication. The service mesh integration provides intra-NF communication and allows API gateway coworking with service mesh. The service mesh integration supports the services by deploying a special sidecar proxy in the environment to intercept all network communication between microservices.

Note:

For service mesh integration, the service mesh must be available in the cluster in which OCNWDAF is installed.
For more information about configuring service mesh, see Oracle Communications Networks Data Analytics Function Installation and Fault Recovery Guide.

3.4 Support for Georedundancy

Overview

A network comprises of multiple sites, and each site can be located at different data centres and can be spread across geographic locations. Georedundancy is data replication of one site across multiple sites to efficiently handle failure scenarios and ensure High Availability (HA). A network failure can occur due to reasons such as network outages, software defects, hardware issues, and so on. These failures impact the continuity of network services. Georedundancy is used to mitigate such network failures and ensure service continuity in a network. In a georedundant deployment, when a failure occurs at one site, an alternate site takes ownership of all the subscriptions and activities of the failed site. The alternate site ensures consistent data flow, service continuity, and minimal performance loss.

Georedundant Deployment Architecture

The OCNWDAF supports both 2-site and 3-site georedundant deployments. The following diagram depicts a 3-site georedundant deployment.

Figure 3-1 Georedundant Architecture


Georedundant Architecture

Redundancy agent

Redundancy Agent is the microservice introduced to maintain communication and enable site transfer between the mated sites. It uses a heartbeat mechanism to broadcast the liveness of a site and receives liveness updates from mated sites.

Site transfer is based on the configured priority of the mated sites. The redundancy agent of every site maintains a priority list of the mated sites. The priority list is configured using the Helm chart. A site can access the priority list of other sites using the DB and build the ownership matrix. When a site failure occurs at the primary site, the ownership is transferred to the secondary site. If the secondary site fails, the ownership is transferred to the tertiary site and so on. Identifying and recognizing a failed site is based on a quorum, where a majority of active sites agree on the failed status of the site.

An NF sends a subscription request to the Analytics Subscription Service. The subscription service verifies if the subscription exists and if it is a new subscription, it stores the subscription data and the Site ID. The Redundancy agent accordingly responds with a status to the subscription service. If the status is ACTIVE, the Analytics Subscription Service continues with the subscription request. If the Analytics Subscription Service receives any other status, it responds to the subscription request with an HTTP 5XX response. The subscription service updates and maintains site status based on the response received by the Redundancy agent. If a subscription request is received from a NF when the site is down, the transfer of responsibility to mated site is the addressed by the Redundancy Agents, the request is forwarded to the site which is currently handling all the subscription requests of the site which is down. If a core component failure occurs, the Redundancy Agent intimates the Subscription Service, the Subscription Service caches the data sent by Redundancy Agent, and further this data is referred by Subscription Service while accepting fresh subscriptions. The Analytics Information Service also operates like the Analytics Subscription Service. The Redundancy Agent provides the site liveness data to the Data Collection Service when there is a change in the core component status, the Data Collection Service caches the data sent by Redundancy Agent, and further this data is referred by Data Collection Service while accepting fresh data collection requests.

Prerequisites

  • Each site configures the remote OCNWDAF sites that it shall be georedundant with.
  • The DB replication service must be in good health.
  • Georedundant sites must be time synchronized.
  • Georedundant OCNWDAF sites must be reachable from NFs from all three sites.
  • The NFs register their services and maintain heartbeats with the OCNWDAF. The data is replicated across the georedundant OCNWDAFs, thereby allowing the NFs to seamlessly move between the OCNWDAFs in case of failure.
  • The configurations at each site shall be the same to allow the OCNWDAFs at all sites to handle the subscriber NFs in the same manner.
  • This feature is configured using HELM.

Georedundant Deployment Failure Scenarios

Listed below are possible failure scenarios in georedundant deployments and the respective failure recovery mechanisms to prevent network failures:

Table 3-1 Failure Scenarios

Failure Scenario Failure Recovery
One of the mated OCNWDAF sites is down, and the heartbeat is not exchanged. The Redundancy Agent updates the ownership matrix and transfers site ownership to the active site based on the existing ownership matrix.
The mated OCNWDAF site is up, but the heartbeat exchange is missed. Redundancy Agent marks the unresponsive mated site as UNAVAILABLE and after number of heartbeats missed crosses the configured threshold, the Redundancy Agent marks the site as INACTIVE. Transfer of ownership is then initiated based on the priority list.
Heartbeats are exchanged, but the OCNWDAF site is experiencing a core component failure.

In case of core component failure, the redundancy agent uses the K8s client to identify the failure of core components.

The Redundancy Agent updates the ownership matrix and transfers site ownership to the active site based on the existing ownership matrix.
cnDBTier Primary Replication Channel Failure, cnDBTier Secondary Replication Channel Failure and cnDBTier Both Replication Channel Failure cnDBTier takes appropriate action. For more information, see, Oracle Communications Cloud Native Core cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Note:

Transferring ownership in this case may result some data loss.
Complete cnDBTier Failure or DB Connection Failure with OCNWDAF. Redundancy Agent updates the current status of the OCNWDAF site as unavailable/down, updates the ownership matrix, and sends the heartbeat to mated sites. Redundancy Agent determines the status of the DB and takes appropriate action. For more information on cnDBtier recovery, see, Oracle Communications Cloud Native Core cnDBTier Installation, Upgrade, and Fault Recovery Guide
NF unable to send or communicate with local OCNWDAF. The NF uses the DNS (or SCP Model-D) to obtain the IP of the secondary site which will now be responsible for the current site.

Note:

  • In case of cnDBTier replication channel failures or complete cnDBtier failure, see, Oracle Communications Cloud Native Core cnDBTier Installation, Upgrade, and Fault Recovery Guide

  • When one or more core components of an OCNWDAF instance fails, the OCNWDAF instance marks itself as INACTIVE, and broadcasts this message to other mated sites. The mated sites initiate the ownership transfer process.

Two Site Georedundancy

The following diagram depicts a two site georedundant deployment:

Figure 3-2 Two Site Georedundancy


Two Site Georedundancy

The ownership matrix determines the transfer of ownership when a site failure occurs. The site failure is determined by the site status. The site status can be ACTIVE, INACTIVE, SUSPENDED, DISCOVERY and UNAVAILABLE. The ownership transfer occurs as per the ownership matrix when the site is INACTIVE, SUSPENDED or UNAVAILABLE.

For example, when Site 2 is INACTIVE, based on the ownership matrix Site 1 becomes the owner of all subscriptions owned by Site 2.

Three Site Georedundancy

The following diagram depicts a three site georedundant deployment:

Figure 3-3 Three Site Georedundancy


Three Site Georedundancy

The ownership matrix determines the transfer of ownership when a site failure occurs. The site failure is determined by the site status. The site status can be ACTIVE, INACTIVE, SUSPENDED, DISCOVERY and UNAVAILABLE. The ownership transfer occurs as per the ownership matrix when the site is INACTIVE, SUSPENDED or UNAVAILABLE.

For example, when Site 1 is down, Site 2 takes ownership of the subscriptions at Site 1. If Site 2 is also down Site 3, assumes ownership of subscriptions at Site 1. The transfer of ownership is based on the priority configured in the Ownership Matrix.

Managing Georedundancy

Deploy

To deploy OCNWDAF in a georedundant environment:

  • Install cnDBTier version 22.4.0 or above on each configured site. Ensure the DB Replication Channels between the sites are UP. For information about installing cnDBTier, see "Installing cnDBTier" in Oracle Communications Cloud Native Core cnDBTier Installation, Upgrade, and Fault Recovery Guide.

  • Deploy OCNWDAF over the replicated cnDBTier sites. Ensure the sites have different names. For information about installing and deploying OCNWDAF, see Oracle Communications Cloud Native Core Networks Data Analytics Function Installation Guide and Fault Recovery Guide.
  • Ensure that the redundancy agent details are added to the common gateway routing rules.

Configure Georedundancy

Configure the georedundancy specific parameters in the OCNWDAF instances on the replicated sites. Configure the following parameters in the redundancy agents properties file to enable and configure georedundancy in the deployed sites:

  • Set the GEO_REDUNDANCY_ENABLE parameter to true.
  • Ensure that the following parameters are properly configured (based on number of georedundant sites in the deployment) in the redundancy agents properties file:

    • GEO_RED_AGENT_SITE_SECONDARY_SITEID

    • GEO_RED_AGENT_SITE_SECONDARY_ADDRESS
    • GEO_RED_AGENT_SITE_TERTIARY_SITEID
    • GEO_RED_AGENT_SITE_TERTIARY_ADDRESS
    • GEO_RED_SITE_SELF_PRIORITY
    • GEO_RED_AGENT_SITE_ID
    • GEO_RED_AGENT_SELF_ADDRESS
    • GEO_RED_AGENT_NUMBER_OF_MATED_SITE

    For example:

    GEO_RED_AGENT_NUMBER_OF_MATED_SITE: 2
GEO_RED_AGENT_SITE_SECONDARY_SITEID: OCNWDAF-XX-2
GEO_RED_AGENT_SITE_SECONDARY_ADDRESS: http://ocn-nwdaf-gateway-service:8088
GEO_RED_AGENT_SITE_TERTIARY_SITEID: OCNWDAF-XX-3
GEO_RED_AGENT_SITE_TERTIARY_ADDRESS: http://ocn-nwdaf-gateway-service:8088
  • If the deployment is a two site georedundant deployment the tertiary site is not a part of the georedundant deployment, set a placeholder value. It should not be empty.
  • After OCNWDAF instances are deployed over replicated cnDBTier sites, run the following command: 
    helm install {releasename} {chartlocation} -n
    {namespace}
    For example: 
    helm install grdagent charts -n nwdaf

Configure the following parameters to enable and configure georedundancy in the custom values file for OCNWDAF:

Table 3-2 REDUNDANCY AGENT CONFIGURATION

Parameter Description Default Value
ocnwdaf.cluster.namespace Name space of the deployment

Note:

Change this to the name space of OCNWDAF deployments.

ocn-nwdaf
ocnnwdaf.geored.hooks.database Database information for the hook nwdaf_subscription
ocnnwdaf.geored.hooks.table Table information for the hook nwdaf_subscription
ocnnwdaf.geored.hooks.column1 Column1 information for the hook record_owner
ocnnwdaf.geored.hooks.column2 Column2 information for the hook current_owner
ocnnwdaf.geored.hooks.image Image information for the hook ocnwdaf-docker.dockerhub-phx.oci.oraclecorp.com/nwdaf-cap4c/nwdaf-cap4c-mysql:8.0.30
ocnnwdaf.geored.agent.name Name of the deployment ocn-nwdaf_georedagent
ocnnwdaf.geored.agent.replicas Number of Replicas 1
ocnnwdaf.geored.agent.image.source Image for GRD Agent

Note:

Modify this value if the image is in a different repository.

 occne-repo-host:5000/occne/redagent-ms-dev:1.0.31
ocnnwdaf.geored.agent.image.pullPolicy Image Pull Policy IfNotPresent
ocnnwdaf.geored.agent.resources.limits.cpu CPU Limit 1
ocnnwdaf.geored.agent.resources.limits.memory Memory Limit 1Gi
ocnnwdaf.geored.agent.resources.request.cpu CPU Request 1
ocnnwdaf.geored.agent.resources.request.memory Memory Request 1Gi
ocnnwdaf.geored.agent.service.type Service Type of the Deployment ClusterIP
ocnnwdaf.geored.agent.service.port.containerPort Container Port of the Deployment 9181
ocnnwdaf.geored.agent.service.port.targetPort Target Port of the Deployment 9181
ocnnwdaf.geored.agent.service.port.name Name of the Service Port ocnwdafgeoredagentport
ocnnwdaf.geored.agent.service.prometheusport.containerPort Container Port of the Prometheus 9000
ocnnwdaf.geored.agent.service.prometheusport.targetPort Target Port of the Prometheus 9000
ocnnwdaf.geored.agent.service.prometheusport.name Name of the Prometheus

Note:

Modify the port name based on the promethus on the deployed setup.

 http-cnc-metrics
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SERVER_HTTP2_ENABLED Enable/Disable HTTP2 TRUE
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_HEARTBEAT_INTERVAL_MS Time Interval To check HeartBeat in "ms" 10000
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_HEARTBEAT_THRESHOLD Number of Time Times to check Heart Beat 5
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_CORE_COMP_THRESHOLD Number of Time Times to check Heart Beat toward Core Components provides 5
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SITE_NUMBER Current Site Number 1
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SITE_ID Current Site ID OCNWDAF-XX-1
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_NUMBER_OF_MATED_SITE Number of Mated Sites. It is updated based on GRD Sites in sync. 1
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SELF_ADDRESS Current Agent Address. The resolvable URL of the OCNNWDAF Gateway service. This address should be reachable outside the cluster .  
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_MICROSERVICE_LIVELINESS_MS Check Interval for OCNWDAF Microservice in "ms". 10000
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_OCNWDAF_CORE_COMPONENT_LIST List of OCNWDAF microservices that needs to be verified. ocn-nwdaf-subscription
ocnnwdaf.geored.agent.env.GEO_RED_SITE_SUBSCRIPTION_OWNERSHIP_TRANSFER_URL Subscription API for Ownership Transfer http://ocn-nwdaf-subscription-service-internal:8087/nnwdaf-eventssubscription/v1/subscriptions/updateServingOwner
ocnnwdaf.geored.agent.env.GEO_RED_SITE_DATA_COLLECTION_URL Data Collection API for Ownership Check http://ocn-nwdaf-data-collection-service-internal:8081/ra/notify
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_DBTIER_REPLICATION_STATUS_URL cnDBTier Monitor Service URL for Replication Use the Reachable Monitor Service from Deployed CNDB namespace. For example: http://mysql-cluster-db-monitor-svc.{cndbnamspace}.svc.{domainname}:8080/db-tier/status/replication
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_DBTIER_STATUS_URL cnDBTier Monitor Service URL for Local Use the Reachable Monitor Service from Deployed CNDB namespace. For example: http://mysql-cluster-db-monitor-svc.{cndbnamspace}.svc.{domainname}:8080/db-tier/status/local
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SITE_SECONDARY_SITEID Secondary Site ID OCNWDAF-XX-2
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SITE_SECONDARY_ADDRESS Secondary Site Address

The Resolvable URL of the OCNWDAF Gateway of Secondary Site.

This address should be reachable outside the cluster
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SITE_TERTIARY_SITEID Tertiary Site ID OCNWDAF-XX-3
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_SITE_TERTIARY_ADDRESS Tertiary Site Address

The Resolvable URL of the OCNWDAF Gateway of Tertiary Site.

This address should be reachable outside the cluster
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_DB_URL IP of the Site cnDBTier The Cluster IP/External IP of the CNDB
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_USERNAME Name of the DB User with privileges to GRD DB and Subscription DB. The user should have access to both GRD and Subscription Databases occneuser
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_PASSWORD Password for the DB User password
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_ENABLE Enable/Disable GRD false
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_DB_PORT Port of the DB 3306
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_DB_NAME Name of the GRD Database georedagent
ocnnwdaf.geored.agent.env.GEO_RED_AGENT_CONFIG_SERVER Config Server URL for the Site's OCNWDAF http://nwdaf-cap4c-spring-cloud-config-server:8888

Procedure to Migrate From Two Site Georedundancy to Three Site Georedundancy

To deploy a tertiary site in a two site georedundant environment, update tertiary site parameters in the redundancy agents properties file.

  • Update the parameters GEO_RED_AGENT_SITE_TERTIARY_SITEID, GEO_RED_AGENT_SITE_TERTIARY_ADDRESS, GEO_RED_SITE_SELF_PRIORITY to include the new site in the priority list and the address list for all sites including the existing sites and the new site as well.

  • Update GEO_RED_AGENT_NUMBER_OF_MATED_SITE parameter in the helm chart to increase the number of mated sites to 3 for all sites.

  • Configure and deploy georedundancy service on each site. Run the following command: 
    helm install {releasename} {chartlocation} -n
    {namespace}

Disable Georedundancy

To disable georedundancy set the ENABLE_GEO_REDUNDANCY parameter to false in the redundancy agents properties file.

Remove a OCNWDAF site from a Georedundant Deployment

Prerequisites

Disable replication on the CNDB MySQL Cluster. For more information see the procedure to Gracefully stop geo-replication in the Oracle Communications Cloud Native Core cnDBTier User Guide.

Perform the following steps:

  • Remove the OCNWDAF site from the DNS Service List.
  • Delete the georedundant service from the site and remove the database from sites CNDB database.
  • Remove the site references from other sites and upgrade their Redundancy Agents.

    For example: If Site 3 is being removed, remove the reference of Site 3 from both Site 1 and Site 2 Redundancy Agents and upgrade the services.

3.5 Automated Test Suite Support

OCNWDAF provides Automated Test Suite (ATS) for validating the functionalities. ATS allows you to run OCNWDAF test cases using an automated testing tool, and then compares the actual results with the expected or predicted results. In this process, there is minimal user intervention.

For more information on installing and configuring ATS, see Oracle Communications Network Analytics Suite Automated Test Suite Guide.