Installing OCNWDAF

2 Installing OCNWDAF

This chapter provides information about installing Oracle Communications Networks Data Analytics Function (OCNWDAF) in a cloud native environment.

2.1 Prerequisites

Before you begin with the procedure for installing OCNWDAF, ensure that the following requirements are met:

Caution:

User, computer and applications, and character encoding settings may cause an issue when copy-pasting commands or any content from PDF. PDF reader version also affects the copy-pasting functionality. It is recommended to verify the pasted content especially when hyphens or any special characters are part of copied content.

2.1.1 Software Requirements

This section describes the software requirements for installing OCNWDAF:

Oracle Communications Cloud Native Environment Specification

Oracle Communications Network Data Analytics Function (OCNWDAF) 23.3.0 can be installed on Oracle Cloud Infrastructure (OCI), Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) 1.9.x,1.10.x,22.4.x, 23.1.x, and 23.2.x releases.

Verify the CNE version with the following command:

echo $OCCNE_VERSION

Note:

From CNE 1.8.x and later, the container platform is Podman instead of docker. For more information about Podman installation, see Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) Installation, Upgrade, and Fault Recovery Guide.

Mandatory Software

The following software items must be installed before starting the OCNWDAF installation:

Table 2-1 Mandatory Software

Software	Version
Kubernetes	1.20.7, 1.21.7, 1.22.5, 1.23.x, 1.24.x
HELM	3.1.2, 3.5.0, 3.6.3, 3.8.0
Podman	2.2.1, 3.2.3, 3.3.1
cnDBTier	23.2.0, 23.2.1, 22.4.1
CNC Console	23.3.0, 23.2.0, 23.2.1

To verify the current Helm and Kubernetes version installed on CNE, use the following commands:

To check Kubernetes version, run the following command:
```
kubectl version
```
To check the Helm version, run the following command:
```
helm3 version
```

Additional Software

Depending on your requirement, you may have to install additional software while deploying OCNWDAF. The list of additional software items, along with the supported versions and usage, is given in the following table:

Table 2-2 Additional Software

Software	App Version	Required For
elasticsearch	7.9.3	Logging
elastic-client	0.3.6	Metric Server
elastic-curator	5.5.4	Logging
elastic-exporter	1.1.0	Logging
elastic-master	7.9.3	Logging
logs	3.1.0	Logging
kibana	7.9.3	Logging
grafana	9.1.7	KPIs
prometheus	2.39.1	Metrics
prometheus-kube-state-metrics	1.9.7	Metrics
prometheus-node-exporter	1.0.1	Metrics
metalLb	0.12.1	External IP
metrics-server	0.3.6	Metrics
tracer	1.21.0	Tracing

To verify the installed software items, run the following command:

helm3 ls -A

If you need any services related to the above software items, and if the respective software is unavailable in CNE, then install that software before proceeding further.

2.1.2 Environment Setup Requirements

This section provides information about environment setup requirements for installing OCNWDAF.

Network Access

The Kubernetes cluster hosts must have network access to the following repositories:

Local docker image repository: It contains the OCNWDAF docker images. To check if the Kubernetes cluster hosts can access the local docker image repository, pull any image with an image-tag, using the following command:
```
docker pull <docker-repo>/<image-name>:<image-tag>
```
where:

docker-repo is the IP address or host name of the docker image repository.

image-name is the docker image name.

image-tag is the tag assigned to the docker image used for the OCNWDAF pod.
Local helm repository : It contains the OCNWDAF Helm charts. To check if the Kubernetes cluster hosts can access the local Helm repository, run the following command:
```
helm repo update
```

Client Machine Requirements

This section describes the requirements for client machine, that is, the machine used by the user to run deployment commands.

The client machine must meet the following requirements:

Network access to the helm repository and docker image repository.
Helm repository configured on the client.
Network access to the Kubernetes cluster.
Required environment settings to run the kubectl and docker commands. The environment must have privileges to create a namespace in the Kubernetes cluster.
Helm client installed so that the helm install command deploys the software in the Kubernetes cluster.

cnDBTier Requirements

OCNWDAF supports cnDBTier in a virtual CNE (vCNE) environment. cnDBTier must be up and active in case of containerized CNE. For more information about installation procedure, see the Oracle Communications Cloud Native Core cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Note:

If the environment has cnDBTier 23.2.0 installation, follow the instruction below:

If cnDBTier 23.2.0 release is installed, set the ndb_allow_copying_alter_table parameter to 'ON' in the cnDBTier custom values dbtier_23.2.0_custom_values_23.2.0.yaml file and perform cnDBTier upgrade before install, upgrade, or any fault recovery procedure is performed for OCNWDAF. Set the parameter to its default value, 'OFF' once the activity is completed and perform the cnDBTier upgrade to apply the parameter changes.
To perform cnDBTier upgrade, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

2.1.3 Resource Requirements

This section lists the resource requirements to install and run OCNWDAF.

OCNWDAF Services

The following table lists the resource requirement for OCNWDAF services:

Table 2-3 Core Microservices Resource Requirements

Microservice Name	POD Replica		CPU/POD		Memory/POD (in GB)		Ephemeral Storage
	Min	Max	Min	Max	Min	Max	Min (Mi)	Max (GB)
ocn-nwdaf-analytics-info-service	1	2	1	2	1	2	78.1	1
nwdaf-ingress-gateway	1	2	1	2	1	2	78.1	1
nwdaf-cap4c-spring-cloud-config-server	1	1	2	2	1	1	78.1	1
nwdaf-egress-gateway	1	2	1	2	1	2	78.1	1
ocn-nwdaf-data-collection-service	2	4	2	4	2	4	78.1	1
ocn-nwdaf-data-collection-controller	2	1	2	2	1	1	78.1	1
ocn-nwdaf-subscription-service	1	2	1	2	1	2	78.1	1
ocn-nwdaf-mtlf-service	1	2	1	2	1	2	78.1	1
cap4c-configuration-manager-service	1	2	1	2	1	2	78.1	1
ocn-nwdaf-cap4c-model-controller	1	2	4	8	1	2	78.1	1
ocn-nwdaf-cap4c-model-executor	2	4	2	4	1	2	78.1	1
ocn-nwdaf-cap4c-stream-analytics	2	4	4	8	1	2	78.1	1
ocn-nwdaf-cap4c-portal	1	2	2	4	1	2	78.1	1
ocn-nwdaf-cap4c-portal-service	1	2	2	4	1	2	78.1	1
ocn-nwdaf-cap4c-scheduler-service	1	2	1	2	1	2	78.1	1
cap4c-stream-transformer	1	2	1	2	1	2	78.1	1
cap4c-api-gateway	1	2	1	2	1	2	78.1	1
ocn-nwdaf-cap4c-kafka-ingestor	2	4	1	2	1	2	78.1	1
ocn-nwdaf-cap4c-reporting-service	1	2	1	2	1	2	78.1	1
ocn-nwdaf-geo-redundacy-agent	1	1	1	1	1	2	78.1	1
Total	25	45	32	59	21	40

Resource Requirements for Helm Test

This section provides the details on resource requirement to install and run OCNWDAF Helm Test.

Helm Test Job

This job runs on demand when Helm test command is run. It runs the Helm test and stops after completion. These are short lived jobs, which gets terminated after the work is completed. Hence, they are not part of active deployment resource, but considered only during Helm test procedures.

Table 2-4 Helm Test Requirement

Container Type	CPU Request and Limit Per Container	Memory Request and Limit Per Container
Helm Test	Request- 1 CPU, Limit- 2 CPU	Request- 1 GB, Limit- 2 GB

Below is an example of the configurations that should be included under the global section of the oc-nwdaf-custom-values.yaml file.

global:
  testJobResources:
    limits:
      cpu: 2
      memory: 2Gi
      ephemeral-storage: 2Gi
    requests:
      cpu: 1
      memory: 1Gi
      ephemeral-storage: 200Mi

2.2 Installation Sequence

This section describes preinstallation, installation, and postinstallation tasks for OCNWDAF.

You are recommended to follow the steps in the given sequence for preparing and installing OCNWDAF.

2.2.1 Preinstallation Tasks

Before installing OCNWDAF, perform the tasks described in this section.

Note:

The kubectl commands might vary based on the platform used for deploying CNC Policy. Users are recommended to replace kubectl with environment-specific command line tool to configure kubernetes resources through kube-api server. The instructions provided in this document are as per the CNE’s version of kube-api server.

2.2.1.1 Downloading the OCNWDAF package

This section provides information about how to download OCNWDAF package.

To download the OCNWDAF package from My Oracle Support:

Log in to My Oracle Support using the appropriate credentials.
Click Patches & Updates to locate the patch.
In the Patch Search console, select the Product or Family (Advanced) option.
Enter Oracle Communications Cloud Native Core Network Data Analytics Function in the Product field. Select the product from the Product drop-down
From the Release drop-down, select "Oracle Communications Cloud Native Core Network Data Analytics Function <release_number>" Where, <release_number> indicates the required release number of OCNWDAF.
Click Search.
The Patch Advanced Search Results displays a list of releases.
Select the required patch from the list. The Patch Details window appears.
Click Download. The File Download window appears.
Click the <p********_<release_number>_Tekelec>.zip file.
Extract the release package zip file.
Package is named as follows:

nwdaf-pkg-<marketing-release-number>.zip

For example: nwdaf-pkg-23.3.0.0.zip

To download the package from the edelivery portal, perform the following steps:

Login to the edelivery portal with your credentials. The following screen appears:

Figure 2-1 edelivery portal
Select the Download Package option, from All Categories drop down list.
Enter Oracle Communications Cloud Native Core Network Data Analytics Data Function in the search bar.
List of release packages available for download are displayed on the screen. Select the release package you want to download, the package automatically gets downloaded.

Untar the Package ZIP File

Run the following command to untar or unzip the OCNWDAF package zip file to the specific repository:

tar -xvf nwdaf-pkg-<marketing-release-number>.tgz

unzip  nwdaf-pkg-<marketing-release-number>.zip

After the package and its content is extracted, the following directory structure is displayed:

# Root
- images
    - tar of images
    - sha 256 of images
- troubleshooting/
    - nfDataCapture.sh
- installer/
    - ocn-nwdaf-helmChart/
        - helmChart/
            - templates
            - charts
            - values.yaml
            - charts.yaml
            - nwdaf-pre-installer.tar.gz
        - simulator-helmChart/
            - templates
            - charts
            - values.yaml
            - charts.yaml
    - nwdaf-ats/
        - ocn-ats-nwdaf-tool
            - ngnix
            - templates
        - ocnwdaf_tests
            - data
            - features
    - scripts/
      - gen_certs.sh
      - readme.txt

Note:

The readme.txt file under the scripts folder is for the gen_certs.sh script.

2.2.1.2 Pushing the Images to Customer Docker Registry

The OCNWDAF deployment package includes ready-to-use docker images (inside the images tar file) and Helm charts to help orchestrate containers in Kubernetes. The communication between service pods of OCNWDAF are preconfigured in the Helm charts.

Table 2-5 Docker Images for OCNWDAF

Service Name	Docker Image Name	Image Tag
NWDAF Analytics Info Service	ocn-nwdaf-analytics	23.3.0.0.0
NWDAF MTLF Service	ocn-nwdaf-mtlf-service	23.3.0.0.0
NWDAF Subscription Service	ocn-nwdaf-subscription-service	23.3.0.0.0
AMF NF Simulator Service	ocn-amf-simulator-service	23.3.0.0.0
SMF NF Simulator Service	ocn-smf-simulator-service	23.3.0.0.0
NRF NF Simulator Service	ocn-nrf-simulator-service	23.3.0.0.0
OAM Simulator Service	ocn-oam-simulator-service	23.3.0.0.0
Mesa Simulator Service (Data Generator)	mesa-simulator	23.3.0.0.0
cap4c ML model controller	cap4c-model-controller	23.3.0.0.0
cap4c ML model executor	cap4c-model-executor	23.3.0.0.0
cap4c stream analytics	cap4c-stream-analytics	23.3.0.0.0
kafka to mysql serializer	cap4c-kafka-ingestor	23.3.0.0.0
Reporting service	nwdaf-cap4c-reporting-service	23.3.0.0.0
kafka	nwdaf-cap4c-kafka	3.4.0
nwdaf-cap4c-scheduler	nwdaf-cap4c-scheduler-service	23.3.0.0.0
nwdaf-cap4c-spring-cloud-config-server	nwdaf-cap4c-spring-cloud-config-server	23.3.0.0.0
nwdaf-portal	nwdaf-portal	23.3.0.0.0
nwdaf-portal-service	nwdaf-portal-service	23.3.0.0.0
redis	nwdaf-cap4c-redis	7.0.4
zookeeper	nwdaf-cap4c-zookeper	3.8.0
nwdaf-cap4c-initial-setup-script	nwdaf-cap4c-initial-setup-script	23.2.0
ocats-nwdaf	ocats-nwdaf	23.3.0.0.0
ocats-nwdaf-notify	ocats-nwdaf-notify	23.3.0.0.0
ocats-nwdaf-notify-nginx	ocats-nwdaf-notify-nginx	23.3.0.0.0
Helm Test	nf-test	22.2.0
geo redundancy agent	ocn-nwdaf-geo-redundacy-agent	23.1.0.0.0
nwdaf-egress-gateway	ocingress_gateway	23.1.3
nwdaf-ingress-gateway	ocegress_gateway	23.1.3
nrf client configuration server	oc-config-server	22.4.0
nrf client app info	oc-app-info	22.4.0
nrf client perf info	oc-perf-info	22.4.0
nrf client	nrf-client	22.4.0
NWDAF Data Collection Controller	ocn-nwdaf-data-collection-controller	23.3.0.0.0
cap4c-configuration-manager-service	cap4c-configuration-manager-service	23.3.0.0.0
cap4c-stream-transformer	cap4c-stream-transformer	23.3.0.0.0
nwdaf-cap4c-nginx	nwdaf-cap4c-nginx	1.20
cap4c-api-gateway	cap4c-api-gateway	23.3.0.0.0
nwdaf-cap4c-java	nwdaf-cap4c-java	17.0
ocnwdaf-pre-install-hook-image	ocnwdaf-pre-install-hook-image	1.1.3
nwdaf-cap4c-mysql	nwdaf-cap4c-mysql	8.0.30

To push the images to customer docker registry, perform the following steps:

Verify the package content, checksums of tarballs in the Readme.txt file.
If the images of the above services are already present in the artifact, then proceed with the Preinstallation Tasks tasks.
(Optional) If the images of the above services are not present in the artifact, then the user has to run the following commands to manually load, tag, and push the images. Run the following command:
```
docker load --input <image_file_name.tar>
```
Example:
```
docker load --input images
```
Note:
If you face issues in loading the images, verify if format of images is correct. For example:
The format is cap4c-api-gateway-23.3.0.0.1.tar and not cap4c-api-gateway:23.3.0.0.1.tar

Run the following command to change the format:
```
mv <source image name> <destination image name>
```
For example:
```
mv cap4c-api-gateway:23.3.0.0.1.tar cap4c-api-gateway-23.3.0.0.1.tar
```
Push the Docker images to the docker repository, run the following command:
```
docker tag <image-name>:<image-tag> <docker-repo>/<image-name>:<image-tag>
```
```
docker push <docker_repo>/<image_name>:<image-tag>
```
Note:
It is recommended to configure the docker certificate before running the push command to access customer registry through HTTPs, otherwise, docker push command may fail.
Verify if the image is loaded correctly by running the following command:
```
docker images
```
(Optional) Push the Helm charts to the Helm repository. Run the following command:
```
helm cm-push --force <chart name>.tgz <Helm repo>
```

Untar the Preinstaller

(Optional) To extract the nwdaf-pre-installer.tar.gz file outside the /helmchart directory, run the following command:

tar xzC <path to extract> -f nwdaf-pre-installer.tar.gz

Verify the file structure of the extracted file:

- etc/
    - nwdaf-cap4c-spring-cloud-config-prod-properties/
    - kafka-topics.txt
- scripts/
    - util/
        - kubernetes-util.sh
        - helm-util.sh
        - generic-util.sh
    - prepare-dependencies.sh

2.2.1.3 Verifying and Creating OCNWDAF Namespace

This section explains how to verify or create a new namespace in the system.

To verify if the required namespace already exists in the system, run the following command:

$ kubectl get namespaces

In the output of the above command, check if the required namespace is available. If the namespace is not available, create the namespace using the following command:

$ kubectl create namespace <required namespace>

Example:

$ kubectl create namespace oc-nwdaf

Naming Convention for Namespaces

While choosing the name of the namespace where you wish to deploy OCNWDAF, make sure the namespace:

starts and ends with an alphanumeric character
contains 63 characters or less
contains only alphanumeric characters or '-'

Note:

It is recommended to avoid using prefix kube- when creating namespace as this prefix is reserved for Kubernetes system namespaces.

To export the installation namespace name as environment variable, run the following command:

export K8_NAMESPACE="<namespace>"

2.2.2 Installation Tasks

This section explains how to install OCNWDAF.

Note:

Before installing OCNWDAF, you must complete Prerequisites and Preinstallation Tasks.

2.2.2.1 Update OCNWDAF Preinstaller Files

Note:

This is an optional procedure.

To update the preinstaller file, perform the following steps:

Make the required changes in config files present in the extracted nwdaf-pre-installer directory and create a fresh tar file by running the following command:
```
tar -zcvf nwdaf-pre-installer.tar.gz nwdaf-pre-installer/
```
Replace the existing tar file in the /helmChart directory with the new tar file.

2.2.2.2 Setup Encrypted Credentials

To set up encrypted credentials, perform the following steps:

To update the secret values (username and password), replace the existing values with updated values after encoding the values using Base64 encoding method. Listed below are the secrets files:
- ocnwdaf-hooks-secret.yaml under /helmchart/templates/ directory
- simulators-hooks-secret.yaml under /simulator-helmChart/templates/ directory
To read the secret values, decode the present values using Base64 decoding method.

2.2.2.3 Configure Database Flag

Note:

This is an optional step. Perform this step based on customer requirement.

Update the dbConfigStatus flag in values.yaml file under /helmchart with any of the following values (the default value is alldb):

alldb: This is the default value of the flag. Set this flag to create a fresh database by removing the existing database. If this flag is present, proceed with the installation of the services.
nodb: This flag disables the dbCreation hooks for the installation of the Helm chart. Set this flag to install the services if the database is present without deleting any data.
nwdafdb: This flag is used to create or reinstall the database only for OCNWDAF services. Set this flag to run the dbCreation hook only for OCNWDAF services (standard installation is followed for the remaining services).
cap4cdb: This flag is used to create or reinstall the database only for CAP4C services. Set this flag to run the dbCreation hook only for CAP4C services (standard installation is followed for the remaining services).

Note:

If there is a requirement to install only OCNWDAF or only CAP4C services, set the dbConfigStatus flag to create the required DB and the charts that are not needed can be set to 'enabled: false' in the "values. yaml" under "/helm chart".

For example, if a user wants to install CAP4C services only with its database, then set the dbConfigStatus flag to 'cap4cdb', and set the value of all the OCNWDAF FE services that are not required to 'enabled: false' and proceed with the installation procedure.

2.2.2.4 Configuring Service Mesh

Note:

This configuration step is optional and only applies when a service mesh is available.

OCNWDAF leverages the Platform Service Mesh (for example, Aspen Service Mesh (ASM)) for all the internal and external TLS communication by deploying a special sidecar proxy in each pod to intercept all the network communications. The service mesh integration provides inter-NF communication and allows API gateway to cowork with the service mesh. The service mesh integration supports the services by deploying a special sidecar proxy in each pod to intercept all the network communications between microservices. A service mesh provides the following services:

Service discovery
Routing and traffic configuration
Encryption and authentication/authorization
Metrics and monitoring

Note:

To configure OCNWDAF to support a service mesh, the service mesh must be available in the cluster in which OCNWDAF is installed.

Enable or Disable Service Mesh

To enable or disable service mesh support, update the Istio sidecar section in the values.yaml file.

For example:

##########################

#ISTIO SIDECAR INJECTION #

##########################

istio:

   ## NOTE:  The label of the namespace will take precedence over the injection field that is set here. If mesh is to be disabled, make sure the namespace has no istio-injection label or set to disabled if present

   injection: false
   readinessCheck: &readinessCheck false

For more information, see Global Parameters.

Update the following NRF client parameters:

istioSidecarQuitUrl
istioSidecarReadyUrl
serviceMeshCheck

For more information, see NRF Client Parameters.

Update the following Ingress Gateway Parameters in the values.yaml file:

serviceMeshCheck

Table 2-6 Ingress Gateway Parameter

Parameter Description Detail

serviceMeshCheck

Parameter	Description	Detail
serviceMeshCheck	This is a mandatory parameter. This flag must be set to `true` if a Service Mesh is present in the environment where OCNWDAF is deployed. If this parameter is set to `true` load balancing is handled by the Service Mesh.	Range: True or False Default value: False Applicable to: OCNWDAF

This is a mandatory parameter. This flag must be set to true if a Service Mesh is present in the environment where OCNWDAF is deployed. If this parameter is set to true load balancing is handled by the Service Mesh.

Range: True or False

Default value: False

Applicable to: OCNWDAF

Update the following Egress Gateway parameters in the values.yaml file:

serviceMeshCheck

Table 2-7 Egress Gateway Parameter

Parameter Description Detail

serviceMeshCheck

Parameter	Description	Detail
serviceMeshCheck	This is a mandatory parameter. This flag must be set to `true` if a Service Mesh is present in the environment where OCNWDAF is deployed. If this parameter is set to `true` load balancing is handled by the Service Mesh.	Range: True or False Default value: False Applicable to: OCNWDAF

Range: True or False

Default value: False

Applicable to: OCNWDAF

After Service Mesh is enabled and deployed, the proxy containers run along with the OCNWDAF application pods.

Note:

The gateways and other services inside the Service Mesh are not accessible from outside the Service Mesh. In order to use OCNWDAF with a Service Mesh, ensure that the dependencies (such as, cnDBTier or analytics consumers) are deployed within the Service Mesh.

2.2.2.5 Configuring Routing Rules in Ingress Gateway

The routing rules are configured in the Ingress Gateway values.yaml file. Once the routing rules are configured, the Ingress Gateway reroutes the incoming traffic to the microservices based on the configured routing rules.

Ingress Gateway values.yaml file:

- id: prodcon
    uri: http://10.123.158.150:31457
    path: /relinquishOwnerShip
    order: 1
    #Below field is used to provide an option to enable/disable route level xfccHeaderValidation, it will override global configuration for xfccHeaderValidation.enabled
    metadata:
      # requestTimeout is used to set timeout at route level. Value should be in milliseconds.
      requestTimeout: 4000
      requiredTime: 3000
      xfccHeaderValidation:
        validationEnabled: false
      oauthValidator:
        enabled: false
      svcName: "prodcon-1"
      configurableErrorCodes:
        enabled: false
        errorScenarios:
          - exceptionType: "NOT_FOUND_EXCEPTION"
            errorProfileName: "ERR_NOT_FOUND"
          - exceptionType: "UNKNOWN_HOST_EXCEPTION"
            errorProfileName: "ERR_UNKNOWN_HOST"
          - exceptionType: "CONNECT_EXCEPTION"
            errorProfileName: "ERR_400"
          - exceptionType: "XFCC_HEADER_NOT_PRESENT_OR_EMPTY"
            errorProfileName: "ERR_1300"
          - exceptionType: "GLOBAL_RATELIMIT"
            errorProfileName: "ERR_RATE_LIMIT"
     
      # Server header configuration if defined at Route level(irrespective of being enabled/disabled) will take precedence over the Global conf. Uncomment only if needed at Route level.
      #serverHeaderDetails:
      #  enabled: false
      #  errorCodeSeriesId: E2  # If not defined here, value at Global level will be used as fallback. Value need to be one among "errorCodeSeriesList" resource defined later.
    filters:
      controlledShutdownFilter:
        applicableShutdownStates:
          - "PARTIAL_SHUTDOWN"
          - "COMPLETE_SHUTDOWN"
        unsupportedOperations:
          - "GET"
          - "PUT"
 
      #Below are Request Custom Headers
      customReqHeaderEntryFilter:
        headers:
          - methods:
              - ALL
            headersList:
              - headerName: x-entry-headeReq-1
                defaultVal: script:shm-02,x-exit-new-req
                source: incomingReq
                sourceHeader: x-entry-current-user
              - headerName: x-entry-current-user
                defaultVal: 123
                source: incomingReq
                sourceHeader: test
      customReqHeaderExitFilter:
        headers:
          - methods:
              - ALL
            headersList:
              - headerName: x-exit-headeReq-1
                defaultVal: abc
                source: incomingReq
                sourceHeader: x-exit-current-user
              - headerName: x-exit-current-user
                defaultVal: 123
                source: incomingReq
                sourceHeader: sbi-timer-feature
          - methods:
              - GET
              - POST
            headersList:
              - headerName: x-exit-headeReq-3
                defaultVal: abc
                source: incomingReq
                sourceHeader: x-exit-new-req
                override: false
              - headerName: x-exit-headeReq-4
                defaultVal: 123
                source: incomingReq
                sourceHeader: x-exit-headeReq-1
                override: false
          - methods:
              - DELETE
              - GET
            headersList:
              - headerName: x-exit-headerReq-5
                defaultVal: abc
                source: incomingReq
                sourceHeader: x-exit-headerReq-new
                override: false
              - headerName: x-exit-headerReq-6
                defaultVal: 123
                source: incomingReq
                sourceHeader: x-exit-headerReq-temp
                override: false
      # Below are Response Custom Headers
      customResHeaderEntryFilter:
        headers:
          - methods:
              - ALL
            headersList:
              - headerName: x-entry-headerRes-1
                defaultVal: abc
                source: incomingReq
                sourceHeader: x-entry-headeReq-1
                override: false
              - headerName: sbi-timer-feature-Res
                defaultVal: 123
                source: incomingReq
                sourceHeader: x-exit-new-req
      customResHeaderExitFilter:
        headers:
          - methods:
              - ALL
            headersList:
              - headerName: x-exit-headerRes-1
                defaultVal: abc
                source: incomingReq
                sourceHeader: x-exit-headerReq-1
                override: false
              - headerName: sbi-timer-feature
                defaultVal: 123
                source: incomingRes
                sourceHeader: x-exit-headerRes-1
          - methods:
              - GET
              - PUT
            headersList:
              - headerName: x-exit-headeRes-3
                defaultVal: abc
                source: incomingRes
                sourceHeader: x-exit-SourceRes-a
                override: true
              - headerName: x-exit-headeRes-4
                defaultVal: 123
                source: incomingReq
                sourceHeader: x-exit-SourceRes-b
                override: false
          - methods:
              - DELETE
            headersList:
              - headerName: x-exit-headeRes-5
                defaultVal: abc
                source: incomingRes
                sourceHeader: ""
                override: false
              - headerName: x-exit-headeRes-6
                defaultVal: 123
                source: incomingRes
                sourceHeader: ""
                override: false
    #Below field is used for blacklisting(removing) a request header at route level.
    removeRequestHeader:
      - name: myheader1
      - name: myheader3
    #Below field is used for blacklisting(removing) a response header at route level.
    removeResponseHeader:
      - name: myresponseheader1
      - name: myresponseheader3

The following Ingress Gateway routesConfig parameters are updated:

id: prodcon
uri: http://10.123.158.150:31457
path: /relinquishOwnerShip

For more information on the customizable Ingress Gateway parameters, see Ingress Gateway Parameters.

Note:

It is recommended to retain the default values of other routesConfig parameters.

2.2.2.6 Install Ingress and Egress Gateways

Run the following command to install the configured Helm charts of both the Ingress and Egress Gateways:

helm install <chart-name> <chart-path> -n <namespace>

After a successful installation, both the Ingress and Egress Gateway pods must be running in your namespace.

Sample output:

Figure 2-2 Sample Output

2.2.2.7 Installing OCNWDAF Package

To install the OCNWDAF package, perform the following steps:

Update the values in the <replace here> tag in the values.yaml file under the <release directory>/ocn-nwdaf-helmChart/helmChart/ directory according to the setup.

...
     cluster:
        name: &clusterName '<replace here>'
        namespace: &nameSpace '<replace here>'
        dbConfig:
            MYSQL_HOST: &mySQLHost '<replace here>'
            MYSQL_PORT: &mySQLPort '<replace here>'
            MYSQL_ENGINE: &mySQLEngine '<replace here>'
            CNDBTIER_NAMESPACE: &cndbNameSpace '<replace here>'
            CNDBTIER_SQL_POD_NAME: &cndbSQLPodName '<replace here>'
     image:
        registry: &imageRegistry '<replace here>'
        gateway:
            registry: '<replace here>'
        initContainer:
            imagePullPolicy: *imagePullPolicy IfNotPresent
 ...

Update the <replace here> tag under the "KAFKA_BROKERS" variable under "NWDAF CONFIGURATION VARIABLES" section with the proper kafka broker. Note: Replace respective OCNWDAF namespaces and cluster names if example values are to be used.
Set the Subcharts flag in the centralized values.yaml file under the <release directory>/ocn-nwdaf-helmChart/helmChart/ directory. The allowed values are true or false. The services with the flag set to "false" are not deployed.
Optionally, update any other parameter in centralized or subchart values.yaml files.
For example, Prometheus monitoring details or hooks environment variables in the centralized values.yaml under the ocn-nwdaf-helmChart/helmChart directory. Any microservice specific values like image name or tag, environment variables in microservices subchart values.yaml file.

The following list is the default variables used to configure OCNWDAF, these variables are present in the centralized values.yaml files and in the secrets:
- MYSQL_HOST
- MYSQL_PORT
- KAFKA_BROKERS
- REDIS_HOST
- REDIS_PORT
- CAP4C_KAFKA_INGESTOR_DB
- CAP4C_KAFKA_INGESTOR_DB_USER
- CAP4C_KAFKA_INGESTOR_DB_PASSWORD
- CAP4C_MODEL_CONTROLLER_DB
- CAP4C_MODEL_CONTROLLER_DB_USER
- CAP4C_MODEL_CONTROLLER_DB_PASSWORD
- CAP4C_MODEL_EXECUTOR_DB_USER
- CAP4C_MODEL_EXECUTOR_DB_PASSWORD
- CAP4C_STREAM_ANALYTICS_DB
- NWDAF_CAP4C_REPORTING_SERVICE_USER
- NWDAF_CAP4C_REPORTING_SERVICE_PASSWORD
- NWDAF_CAP4C_SCHEDULER_SERVICE_DB
- NWDAF_CAP4C_SCHEDULER_SERVICE_DB_USER
- NWDAF_CAP4C_SCHEDULER_SERVICE_DB_PASSWORD
- NWDAF_CONFIGURATION_HOST
- NWDAF_USER
- NWDAF_DB_PASSWORD

Install OCNWDAF, run the following Helm installation command:

helm install <installation name> <path to the chart directory> -n $K8_NAMESPACE --timeout <timeout>m

For example:

helm install nwdaf helmChart/ -n ocnwdaf-ns --timeout 30m

Note:

The parameter --timeout is optional. It is recommended to use this parameter to avoid any installation failure due to slow internet or CPU speeds. Use appropriate value for this parameter depending on the speed of image pull from the nodes of the setup. The recommended timeout value is 30 minutes.

Mandatory Installation Instruction

Note:

Some services are release name dependent, use "nwdaf" for <installation name> in the Helm install command.

For example:

[cloud-user@occne224-cluster-bastion-1 ]$ helm install nwdaf helmChart/ -n nwdaf-test --timeout 30m

Sample output after installation is complete:

[cloud-user@occne224-cluster-bastion-1 ]$ helm install nwdaf helmChart/ -n $K8_NAMESPACE --timeout 30m
W0404 04:44:48.456730 3847781 warnings.go:70] autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavain v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
W0404 04:44:48.459573 3847781 warnings.go:70] autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavain v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
W0404 04:51:41.957767 3847781 warnings.go:70] autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavain v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
W0404 04:51:41.963127 3847781 warnings.go:70] autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavain v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
NAME: nwdaf
LAST DEPLOYED: Tue Apr  4 04:44:47 2023
NAMESPACE: nwdaf-test
STATUS: deployed
REVISION: 1
TEST SUITE: None

Verify if all the dependencies are in Running state (if any pod is not in Running state wait for a maximum of five restarts).

Run the following command to view all the resources present in the namespace:

kubectl get all -n $K8_NAMESPACE

For example:

[cloud-user@occne224-cluster-bastion-1 ~]$ kubectl get all -n $K8_NAMESPACE

Figure 2-3 Sample Output

OCNWDAF Microservices Port Mapping

Table 2-8 Port Mapping

Service	Port Type	IP Type	Network Type	Service Port	Container Port
ocn-nwdaf-analytics	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
nwdaf-egress-gateway	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
nwdaf-ingress-gateway	External	NodePort	External/ K8s	80/TCP	8081/TCP
ocn-nwdaf-data-collection	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-nwdaf-mtlf	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-nwdaf-subscription	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-nwdaf-analytics-info	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-nwdaf-configuration	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-nwdaf-georedagent	Internal	ClusterIP	Internal / K8s	9181/TCP	9181/TCP
cap4c-kafka-ingestor	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
cap4c-model-controller	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
cap4c-model-executor	Internal	ClusterIP	Internal / K8s	9092/TCP	9092/TCP
cap4c-stream-transformer	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
cap4c-stream-analytics	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
cap4c-api-gateway	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
nwdaf-cap4c-reporting-service	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
nwdaf-cap4c-scheduler-service	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
nwdaf-portal	External	NodePort	External / K8s	80/TCP
nwdaf-portal-service	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
cap4c-configuration-manager-service	Internal	ClusterIP	Internal / K8s	9000/TCP	9000/TCP

Note:

For NodePort services, Kubernetes allocates the Service Port.

Installation of Simulator Chart

Follow the procedure below to install the simulator chart:

Update the values in the <replace here> tag present in values.yaml under /simulator-helmchart/ based on the setup:

...
    cluster:
        name: &clusterName '<replace here>'
        namespace: &nameSpace '<replace here>'
        dbConfig:
            MYSQL_HOST: &mySQLHost '<replace here>'
            MYSQL_PORT: &mySQLPort '<replace here>'
            MYSQL_ENGINE: &mySQLEngine '<replace here>'
            CNDBTIER_NAMESPACE: &cndbNameSpace '<replace here>'
            CNDBTIER_SQL_POD_NAME: &cndbSQLPodName '<replace here>'
...

Set the Subcharts flag in the centralized values.yaml file under the /simulator-helmchart directory. The allowed values are true or false. The services with the flag set to false are not deployed.
Optionally, update any other parameter in centralized or subchart values.yaml files.
For example, Prometheus monitoring details or hooks environment variables in the centralized values.yaml under the /simulator-helmchart directory. Any microservice specific values like image name or tag, environment variables in microservices subchart values.yaml file.

Install simulators, run the following Helm installation command:

helm install <installation name> <path to the chart directory> -n $K8_NAMESPACE --timeout <timeout>h

For example:

helm install simulators simulator-helmchart/ -n ocnwdaf-ns --timeout 30m

Note:

The parameter --timeout is optional. It is recommended to use this parameter to avoid any installation failure due to slow internet or CPU speeds. Use appropriate value for this parameter depending on the speed of image pull from the nodes of the Bastion host. The recommended timeout value is 30 minutes.

Sample of the terminal screen once the installation starts:

[cloud-user@occne224-cluster-bastion-2 ocn-nwdaf-helmChart]$ helm install simulators simulator-helmChart/ -n ttest --timeout 30m
W0511 10:38:19.670067 2848359 warnings.go:70] spec.template.spec.containers[0].env[61].name: duplicate name "SPRING_KAFKA_CONSUMER_PROPERTIES_MAX_POLL_INTERVAL_MS"
NAME: simulators
LAST DEPLOYED: Thu May 11 10:38:12 2023
NAMESPACE: ttest
STATUS: deployed
REVISION: 1
TEST SUITE: None

Run the following command to verify if all the dependencies are in Running state (if any pod is not in Running state wait for a maximum of five restarts):
```
kubectl get all -n $K8_NAMESPACE
```
Sample output:

Figure 2-4 Sample Output

The following services with port mapping are deployed:

Table 2-9 Port Mapping

Service	Port Type	IP Type	Network Type	Service Port	Container Port
ocn-nrf-simulator	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-amf-simulator	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
mesa-simulator	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-smf-simulator	Internal	ClusterIP	Internal / K8s	8080/TCP	8080/TCP
ocn-oam-simulator	Internal	ClusterIP	Internal / K8s	8085/TCP	8085/TCP

Configure Service Parameters

In the values.yaml under /helmchart/ select the services to deploy, the Helm chart parameters are listed below:

nrfclient.enabled: true
ocn-nrf-simulator.enabled: true
nwdaf-cap4c-zookeeper.enabled: true
nwdaf-cap4c-kafka.enabled: true
nwdaf-cap4c-redis.enabled: true
nwdaf-cap4c-spring-cloud-config-server.enabled: true
nwdaf-cap4c-scheduler-service.enabled: true
nwdaf-cap4c-reporting-service.enabled: true
nwdaf-cap4c-stream-analytics.enabled: true
nwdaf-cap4c-model-executor.enabled: true
nwdaf-cap4c-model-controller.enabled: true
nwdaf-cap4c-kafka-ingestor.enabled: true
ocn-nwdaf-configuration-service.enabled: true
ocn-nwdaf-subscription.enabled: true
ocn-nwdaf-data-collection.enabled: true
ocn-nwdaf-mtlf.enabled: true
ocn-nwdaf-analytics.enabled: true
ocnNwdafGeoredagent.enabled: false
nwdaf-portal-service.enabled: true
nwdaf-portal.enabled: tru
common-services-gateways.enabled: true
cap4cDeployTemp.enabled: false
ocn-nwdaf-datacollection-controller.enabled: true

In the values.yaml under /simulator-helmChart/ select the simulators to deploy, the simulator Helm chart parameters are listed below:

ocn-smf-simulator.enabled: true
ocn-mesa-simulator.enabled: true
ocn-amf-simulator.enabled: true
ocn-oam-simulator.enabled: true

2.2.3 Postinstallation Tasks

This section explains the postinstallation tasks for OCNWDAF.

2.2.3.1 Verifying Installation

To verify the installation:

Run the following command to check the installation status:
```
helm status <helm-release> -n <namespace>
```
Where,

<helm-release> is the Helm release name of OCNWDAF. <namespace>

<namespace> is the namespace of OCNWDAF deployment.

For example:
```
helm status ocndaf -n ocndaf
```
If the deployment is successful, then the STATUS is displayed as deployed.
Run the following command to verify if the pods are up and active:
```
kubectl get pods -n <namespace>
```
Where,

<namespace> is the namespace of OCNWDAF deployment.

The STATUS column of all the pods must be 'Running'.

The READY column of all the pods must be n/n, where n is the number of containers in the pod.
Run the following command to verify if the services are deployed and active:
```
kubectl -n <namespace> get services
```
Where,

<namespace> is the namespace of OCNWDAF deployment.

If the installation is unsuccessful or the status of all the pods is not in RUNNING state, , perform the troubleshooting steps provided in Oracle Communications Networks Data Analytics Function Troubleshooting Guide.

2.2.3.2 Performing Helm Test

Helm Test is a feature that validates the successful installation of OCNWDAF and determines if the NF is ready to take traffic. The pods are tested based on the namespace and label selector configured for the helm test configurations.

Note:

Helm Test can be performed only on helm3.

Prerequisite: To perform the helm test, you must have the helm test configurations completed under the "Global Parameters" section of the custom_values.yaml file. For more information on parameters, see Global Parameters.

Run the following command to perform the helm test:

helm3 test <helm-release_name> -n <namespace>

where:

helm-release-name is the release name.

namespace is the deployment namespace where OCNWDAF is installed.

Example:

helm3 test ocnwdaf -n ocnwdaf

Sample output:

NAME: ocnwdaf
LAST DEPLOYED: Mon Nov 14 11:01:24 2022 
NAMESPACE: ocnwdaf
STATUS: deployed
 REVISION: 1
TEST SUITE: ocnwdaf-test
Last Started: Mon Nov 14 11:01:45 2022  
Last Completed: Mon Nov 14 11:01:53 2022  
Phase: Succeeded 
NOTES:
# Copyright 2022 (C), Oracle and/or its affiliates. All rights reserved

2.2.3.3 Configuring OCNWDAF GUI

This section describes how to configure Oracle Communications Networks Data Analytics Function (OCNWDAF) GUI using the following steps:

Configure OCNWDAF GUI in CNC Console

Prerequisite: To configure OCNWDAF GUI in CNC Console, you must have CNC Console installed. For information on how to install CNC Console, refer to Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Before installing CNC Console, ensure that the instances parameters are updated in the CNC Console's custom values.yaml file.

Follow the steps listed below:

Set the Image Repository
In the CNC Console's custom values.yaml file, set the Image Repository to the repository where the images are located. The parameter dockerRegistry is found in line number 10 of the global parameters section:
For example:
```
dockerRegistry: ocnwdaf-docker.dockerhub-phx.oci.oraclecorp.com
```
Update the Cluster Domain
Update the cluster's DNS domain based on the deployment. The parameter clusterDomain is located in line number 16 of the global parameters section:
For example:
```
clusterDomain: &clusterDomain "sunstreaker"
```
To identify the cluster name, run the following command:
```
kubectl -n kube-system get configmap kubeadm-config -o yaml | grep -i
    dnsDomain
```

Load Balancer Configuration

If a Load Balancer is used, use the following configuration:

The annotation metallb.universe.tf/address-pool: signaling/oam is required in global section if MetalLB in CNE 1.8.x onwards is used
 
# Line 25:
customExtension:
  lbServices:
    labels: {}
    annotations:
     # The annotation metallb.universe.tf/address-pool: signaling/oam is required if MetalLB in CNE 1.8.x is used
      metallb.universe.tf/address-pool: oam
      service.beta.kubernetes.io/oci-load-balancer-internal: "true"

Set Database Details

Use the following configuration:

# DB Details by fqdn
  dbHost: &mySqlHostRef "mysql-connectivity-service.<namespace_name>"
  dbPort: &mySqlPortRef "3306"
  secretName: &mySqlSecretNameRef cncc-db-secret
 
# DB Details by external ip:
  dbHost: &mySqlHostRef 10.233.34.56 <- External ip from mysql-connectivity-service
  dbPort: &mySqlPortRef 3306
  secretName: &mySqlSecretNameRef cncc-db-secret

Activate Cluster IP for Load Balancer

Set the parameter useClusterIpForLbServices to true.

Use the following configuration:

# Use ClusterIP for LoadBalancer(LB) services.
# The LB services are assigned LoadBalancer service type in k8s service definition. Set this flag to true to assign ClusterIP service type.
useClusterIpForLbServices: true

Update Automatic route generation for CNC Console Manager and Agent Deployment

Update the Automatic route generation for CNC Console Manager and Agent Deployment sections either using an external IP or a Load Balancer:

Using an external IP

self:
 
    cnccId: Cluster1
 
  mCnccIams:
 
  - id: Cluster1
 
    # IP of one of external IP of Cluster nodes
 
    ip: <external_k8s_node_ip>
 
    # IAM app port
 
    port: <service_node_port>
 
  mCnccCores:
 
   - id: Cluster1
 
  aCnccs:
 
   - id: Cluster1
 
     role: Cluster1
 
     # Path to acore ingress service "service-name.namespace.svc.clustername" 
 
     fqdn: nwdaf-cncc-acore-ingress-gateway.<namespace_name>.svc.<cluster_domian>
 
     # cncc app port
 
     port: 80
 
  instances:
 
   - id: OCCNE-NWDAF-UI-instance1
      
     # Set type to NWDAF-UI
 
     type: NWDAF-UI
      
     owner: Cluster1
      
     # Path to nwdaf portal UI service "service-name.namespace.svc.clustername"
 
     fqdn: nwdaf-portal.<namespace_name>.svc.<cluster_domian>
 
     # Portal UI port
 
     port: 80
 
     # Path to NWDAF on kubernetes cluster "clustername/namespace/ocnwdaf"
 
     apiPrefix: /<cluster_domain>/<namespace_name>/ocnwdaf
 
   - id: OCCNE-NWDAF-UI-instance1
 
     # Set type to NWDAF-API
 
     type: NWDAF-API
 
     owner: Cluster1
 
     # Path to nwdaf API service "service-name.namespace.svc.clustername" 
 
     fqdn: cap4c-api-gateway.<namespace_name>.svc.<cluster_domain>
 
     # Portal API port
 
     port: 8080
 
     # Path to NWDAF on kubernetes cluster "clustername/namespace/ocnwdafapi"
 
     apiPrefix: /<cluster_domain>/<namespace_name>/ocnwdafapi

For example:

self:
    cnccId: Cluster1
  mCnccIams:
    - id: Cluster1
      ip: 10.123.158.150
      port: 30085
  mCnccCores:
    - id: Cluster1
  aCnccs: 
    - id: Cluster1  
      role: Cluster1
      fqdn: cncc-acore-ingress-gateway.cncc.svc.blurr7
      port: 30076   
  instances:
    - id : Cluster1-nwdaf-instance1
      # Set type to NWDAF-UI
      type: NWDAF-UI
      owner: Cluster1
      fqdn: nwdaf-portal.ocnwdaf-ns.svc.blurr7
      port: 80
      apiPrefix: /blurr7/ocnwdaf-ns/ocnwdaf
    - id : Cluster1-nwdaf-instance1
      type: NWDAF-API
      owner: Cluster1
      fqdn: cap4c-api-gateway.ocnwdaf-ns.svc.blurr7
      port: 8080
      apiPrefix: /blurr7/ocnwdaf-ns/ocnwdafapi

Using Load Balancer

self:
 
    cnccId: Cluster1
 
  mCnccIams:
 
      - id: Cluster1
 
        # IP of one of Load Balancer IPs of Cluster nodes
 
        ip: 10.75.245.212
 
  mCnccCores:
 
          - id: Cluster1
 
  aCnccs:
 
          - id: Cluster1
 
            role: Cluster1
 
            # Path to acore ingress service "service-name.namespace.svc.clustername"
 
            fqdn: cncc-acore-ingress-gateway.cncc.svc.sunstreaker
 
            # cncc app port
 
            port: 80
 
  instances:
 
          - id: OCCNE-NWDAF-UI-instance1
 
            # Set type to NWDAF-UI
 
            type: NWDAF-UI
 
            owner: Cluster1
 
            # Path to nwdaf portal UI service "service-name.namespace.svc.clustername"
 
            fqdn: nwdaf-portal.ocnwdaf-ns.svc.sunstreaker
 
            # Portal UI port
 
            port: 80
 
            # Path to NWDAF on kubernetes cluster "clustername/namespace/ocnwdaf"
 
            apiPrefix: /sunstreaker/ocnwdaf-ns/ocnwdaf
 
          - id: OCCNE-NWDAF-UI-instance1
 
            # Set type to NWDAF-API
 
            type: NWDAF-API
 
            owner: Cluster1
 
            # Path to nwdaf API service "service-name.namespace.svc.clustername" 
 
            fqdn: cap4c-api-gateway.ocnwdaf-ns.svc.sunstreaker
 
            # Portal API port
 
            port: 8080
 
            # Path to NWDAF on kubernetes cluster "clustername/namespace/ocnwdafapi"
 
            apiPrefix: /sunstreaker/ocnwdaf-ns/ocnwdafapi

For example:

self:
    cnccId: Cluster1
  mCnccIams:
      - id: Cluster1
        ip: 10.75.245.212
  mCnccCores:
          - id: Cluster1
  aCnccs:
          - id: Cluster1
            role: Cluster1
            fqdn: cncc-acore-ingress-gateway.cncc.svc.sunstreaker
            port: 80
  instances:
          - id: OCCNE-NWDAF-UI-instance1
            type: NWDAF-UI
            owner: Cluster1
            fqdn: nwdaf-portal.ocnwdaf-ns.svc.sunstreaker
            port: 80
            apiPrefix: /sunstreaker/ocnwdaf-ns/ocnwdaf
          - id: OCCNE-NWDAF-UI-instance1
            type: NWDAF-API
            owner: Cluster1
            fqdn: cap4c-api-gateway.ocnwdaf-ns.svc.sunstreaker
            port: 8080
            apiPrefix: /sunstreaker/ocnwdaf-ns/ocnwdafapi

Move to the CNC Console IAM Attributes Section

Move to the CNC Console IAM attributes section and update the values as follows:

Update port to the same used by IAM
 
LOC 244: publicHttpSignalingPort: 30085
 
If Static node port needs to be set, then set staticNodePortEnabled flag to true and provide value for staticNodePort.
 
Else random node port will be assigned by K8
 
    staticNodePortEnabled: true
 
    staticHttpNodePort: 30085
 
    staticHttpsNodePort: 30053

Move to the CNC Console Core Attributes Section

Move to the CNC Console Core attributes section and update the values as follows:

Update port to the same used by cncc core
 
LOC 244: publicHttpSignalingPort: 30085
 
If Static node port needs to be set, then set staticNodePortEnabled flag to true and provide value for staticNodePort.
 
Else random node port will be assigned by K8
 
    staticNodePortEnabled: true
 
    staticHttpNodePort: 30085
 
    staticHttpsNodePort: 30053

To identify the external IPs during installation, run the following command:

kubectl get pods -n ocnwdaf-ns -owide | grep portal

Helm Install

Run the Helm install command in the folder where the custom yaml file is located. For example:
```
helm install cncc occncc-xx.x.x.tgz -f occncc_custom_values_xx.x.x.yaml -n cncc
```
Monitor the Installation

To monitor the installation process, run the following command:
```
watch kubectl get pods -n cncc
```
You can access the IAM and CNC Console once the pods are in up and running state.

Verify IAM

Verify if IAM is running. For example:

IAM: http://10.123.158.150:30085/
 
Default user: admin
 
Default password: password

Integrate OCNWDAF and CNC Console

If CNC Console is already installed, ensure all the parameters are updated in the occncc_custom_values.yaml file. For information refer to Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Login to the CNC Console
Click Clients option, In the Settings tab update the Root URL field with the IP on which CNC Console is running and the port defined on mcore-ingress-gateway service.

Figure 2-6 Clients

Click Save
To add new user, click Users and click Add User. Provide a Username and fill the form. Click Save.

Figure 2-7 Add User
Click Users, select the newly added user, go to the Role Mappings tab.
For example:

Figure 2-8 Role Mapping

Add NWDAF_READ and NWDAF_WRITE to the Assigned Roles.
Use the Reset Password screen to create a new password for the user.

Figure 2-9 Reset Password

Access OCNWDAF GUI

To access OCNWDAF GUI, follow the procedure mentioned in the "Accessing CNC Console" section of Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

Uninstall CNC Console

To uninstall CNC Console, run the following commands:

helm delete cncc -n cncc

Delete all jobs, run the following command:


kubectl delete jobs --all -n cncc

2.2.3.4 Taking a Backup

Take a backup of the following files, which are required during fault recovery:

Updated NWDAF-custom-values.yaml file.
Updated Helm charts.
Secrets, certificates, and keys that are used during installation.