3 OCNADD Features
This section explains Oracle Communications Network Analytics Data Director (OCNADD) features.
3.1 Data Governance
OCNADD provides data governance by managing the availability and usability of data in enterprise systems. It also ensures that the integrity and security of the data is maintained by adhering to all the Oracle defined data standards and policies for data usage rules.
3.2 High Availability
OCNADD supports microservice based architecture and OCNADD instances are deployed in Cloud Native Environments (CNEs) which ensure high availability of services and auto scaling based on resource utilization. In the case of pod failures, new service instances are spawned immediately.
In case of K8s cluster failure, the OCNADD deployment is restored to a different cluster using the disaster recovery mechanisms. For more information about the disaster recovery procedures, see Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.
3.3 Data Aggregation
OCNADD performs data aggregation of the network traffic coming from different NFs, such as SCP, SEPP, and NRF. It aggregates the data and provides aggregated traffic feed to the third party consumer applications.
The following diagram shows a high-level architecture of the OCNADD data aggregation feature:
Figure 3-1 Data Aggregation
For information about creating data feeds using CNC Console, see Configuring OCNADD Using CNC Console.
3.4 Data Filtering
OCNADD performs data filtering on messages and enables third-party consumers to gather relevant traffic. The filtering provides the following advantages to consumers:
- Streamlined Troubleshooting: By reducing the volume of traffic, OCNADD facilitates smoother troubleshooting processes.
- Targeted Traffic: Consumers exclusively receive traffic that aligns with their interests.
- Optimized Bandwidth Utilization: OCNADD ensures efficient utilization of the network bandwidth.
OCNADD supports filtering on both Ingress and Egress gateways. It allows to filter packets sent on the N12 interface between AMF and AUSF and N13 interface between AUSF and UDM. The SCP is the data source of traffic (or data) captured between AMF and AUSF. The OCNADD is placed between both the ingress and egress flows therefore filtering can be applied on both the flows, as depicted in the diagram below:
Figure 3-2 Data Filtering
Currently, the OCNADD filtering module offers fundamental metadata filtering for key fields in the metadata list. In the future, this module will be expanded to include advanced filtering capabilities.
- service-name
- user-agent
- consumer-id
- producer-id
- consumer-fqdn
- producer-fqdn
- message-direction
- reroute-cause
- feed-source-nf-type
- feed-source-nf-fqdn
- feed-source-nf-instance-id
- feed-source-pod-instance-id
- consumer-id
- producer-id
- consumer-fqdn
- producer-fqdn
- reroute-cause
- feed-source-nf-type
- feed-source-nf-fqdn
- feed-source-nf-instance-id
- feed-source-pod-instance-id
You can configure data filters (maximum of four filters) through the CNC Console GUI.
However, you can also configure any combination of the filter conditions.
When more than one filter condition is configured, you can define filtering rules using
keywords such as “or” or “and”. For example, consumer-id OR
producer-id. For more information about creating, editing, or
deleting a filter, see Data Filters List section in Configuring OCNADD Using CNC Console.
3.5 Synthetic Packet Data Generation
OCNADD converts incoming JSON data into network transfer wire format and sends the converted packets to the third-party monitoring applications in a secure manner. This third-party probe feeds the synthetic packets to the internal monitoring applications. The feature helps third-party vendors to eliminate the need of creating additional applications to receive JSON data and converting the data into probe compatible format, thereby saving critical compute resources and associated costs.
The following diagram shows a high-level architecture of the OCNADD synthetic packet data generation feature:
Figure 3-3 Synthetic Packet Data Generation
3.6 Health Monitoring
OCNADD performs health monitoring to check the readiness and liveness of each OCNADD service and raises alerts in case of service failure.
OCNADD performs the monitoring based on the heartbeat mechanism where each of the OCNADD service instances registers with the Health Monitoring service and exchanges heartbeat with it. If the pod instance goes down, the health monitoring service raises an alert. Few of the important scenarios when an alert is raised, are as follows:
- When maximum number of replicas for a service have been instantiated.
- When a service is in down state.
- When CPU or memory threshold is reached.
The health monitoring functionality allows OCNADD to generate health reports of each service on a periodic basis or on demand. You can access the reports through the OCNADD Dashboard. For more information about the dashboard, see OCNADD Dashboard.
The health monitoring service is depicted in the diagram below:
Figure 3-4 Health Monitoring
The health monitoring functionality also supports collection of various metrics related to the service resource utilization. It stores them in the metric collection database tables. The health monitoring service generates alerts for the missing heartbeat, connection breakdown, and the exceeding threshold.
3.7 Data Replication
OCNADD allows data replication functionality. The data streams from OCNADD services can be replicated to multiple third party applications simultaneously.
The following diagram depicts OCNADD data replication:
Figure 3-5 Data Replication
3.8 Backup and Restore
OCNADD supports backup and restore to ensure high availability and quick recovery from failures such as cluster failure, database corruption, and so on. The supported backup methods are automated and manual backups. For more information on backup and restore, see Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.
The following diagram depicts backup and restore supported by OCNADD:
Figure 3-6 Backup and Restore
3.9 Secure Transport
OCNADD provides secure data communication between producer NFs and third party consumer applications. All the incoming and outgoing data streams from OCNADD are TLS encrypted.
The following diagram provides a secure transport by OCNADD:
Figure 3-7 Secure Transport
3.10 Operational Dashboard
OCNADD provides an operational dashboard which provides a rich visualization of various metrics, KPIs, and alarms.
The dashboard can be depicted as follows:
Figure 3-8 Operational Dashboard
For more information about accessing the dashboard through CNC Console, see OCNADD Dashboard.
3.11 Weighted Load Balancing Based on Correlation ID
OCNADD supports the weighted load balancing of data feeds among the different endpoints of the third-party consumer application. A new load balancing method “Weighted Load Balancing” is introduced, all incoming messages to the Data Director have a correlation ID, and with the introduction of weighted load balancing the request and response having the same correlation ID are delivered to the same destination endpoint. The operator can configure Weighted Load Balancing through the CNC Console GUI. The default load balancing method is “Round Robin”. The operator can allocate load factors (in percentage) to each destination endpoint, and the total of the load factors assigned to the destination endpoints must be 100 %. By default, load sharing is equally distributed among the endpoints. The maximum number of destination endpoints allowed is “2”. Weighted load balancing can be applied to HTTP, HTTPS, and Synthetic Packet traffic. In case of an endpoint failure, the Data Director distributes the response to the available endpoints in an equal percentage or as per the configured percentage.
For information about configuring load balancing using CNC Console, see Configuring OCNADD Using CNC Console
3.12 Support for Multisite Georedundant Deployments
Overview
A network comprises of multiple sites, and each site can be located at different data centers and can be spread across geographic locations. In a georedundant deployment, data is replicated across sites in order 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 OCNADD supports both two site and three site georedundant deployments. The following diagram depicts a two site georedundant deployment:
Figure 3-9 Georedundancy Architecture
Note:
- Ensure the georedundant sites have sufficient resources to manage the failover traffic from NFs.
- The feed configuration in the redundant sites should be the same.
If any of the georedundant OCNADD sites experience a failure, manual failover procedures must be performed to move NF traffic from the failed site to the available OCNADD site. For information about procedures to route traffic to live OCNADD sites, see Manual Failover in Multisite Georedundant Deployments.
3.13 L3-L4 Information for Synthetic Packet Feed
The OCNADD allows users to configure the L3-L4 mapping rule in the feed and the Global L3-L4 configuration to fetch L3-L4 information when the rule defined in the feed matches the incoming data.
Figure 3-10 Global L3-L4 Configuration
Note:
OCNADD supports GUI-based configuration of L3-L4 information:- For feed level L3L4 configuration using GUI, see Creating Standard Feed and Editing Feed Level L3L4 Configuration.
- For global L3L4 configuration using GUI, see Configuring Global L3L4 Mapping.
Global L3-L4 Mapping Configuration
OCNADD users can configure a list of L3-L4 attribute rules (a combination of rules) by specifying the attribute names and values mapped to IP addresses and port numbers. OCNADD uses these configuration rules that are used to obtain the L3 and L4 address from the global mapping configuration during synthetic packet encoding. Only one Global L3-L4 mapping configuration is applicable to all synthetic feeds.
Table 3-1 Global L3-L4 Configuration
| Attribute 1 | Value | Attribute 2 | Value | IP Address | Port |
|---|---|---|---|---|---|
| L3L4MappintAttributes | String | SuportedL3L4MappingDto | String | String | String |
| consumer-fqdn | 1244 | - | - | 10.10.10.100 | 8080 |
| feed-source-nf-fqdn | <FQDN> | message-direction | RxRequest | 100.100.100.101 | 8181 |
| producer-fqdn | <FQDN> | api-name | nausf-auth | 100.100.100.102 | 8182 |
Note:
- Only two attributes are supported in each row.
- Two attributes in a row are combined with the condition AND during internal processing to identify a match.
- IPv6 is not supported.
- The attribute values are case-sensitive.
- api-name: User must add the api-name taken from
the :path header as value for this attribute in Global L3-L4
configuration.
- nausf-auth or nausf* or *nausf*
formats are supported, and will have the same matching output.
For example: When the api-name is nausf*, the value present in metadata: nausf-auth or nausf-sorprotection or nausf-upuprotection match.
This fulfills the requirement of L3 and L4 mapping when the same AUSF NF is serving all services.
-
nausf*-auth: It is recommended not to add * between
the attribute values for matching, as the condition may or may not
be matched based on value.
For example: When the api-name is nausf*-auth, the value present in metadata: nausf-auth or nausf-sorprotection or nausf-upuprotection, a different value is matched and only the first value matches.
When the api-name is nausf*-test , the value present in metadata: nausf-auth or nausf-sorprotection or nausf-upuprotection a different value is matched and none of the other values match.
- nausf-auth or nausf* or *nausf*
formats are supported, and will have the same matching output.
Feed L3-L4 Mapping Configuration
This configuration allows the user to add L3-L4 mapping rule in the synthetic feed configuration that is verified during synthetic packet encoding to obtain L3-L4 mapping information.
The following table depicts the feed L3-L4 mapping configuration:
Note:
Two mapping rules should be combined only with the operator AND, no other operator is supported.
Table 3-2 Feed L3-L4 Mapping Configuration
| Direction | Address | Mapping Priority | L3-L4 Mapping Rule | Mapping Reference | Least Priority Address | |
|---|---|---|---|---|---|---|
| Supported Values: rxRequest, txRequest, rxResponse. txResponse | Supported Values: source-ip, destination-ip, source-port, destination-port | Default Value: METADATA, Supported Values: METADATA, DD_MAPPING | Default Rule | Recommended Rule | Default Value: DD_MAPPING, Supported Value: DD_MAPPING | Address |
| RxRequest | source-ip | METADATA | consumer-fqdn | consumer-fqdn, consumer-fqdn AND api-name | DD_MAPPING | <IP> |
| destination-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | <IP> | ||
| source-port | METADATA | feed-source-nf-fqdn | feed-source-nf-fqdn, feed-source-nf-fqdn AND consumer-fqdn | DD_MAPPING | <PORT> | |
| destination-port | METADATA | feed-source-nf-fqdn | DD_MAPPING | <PORT> | ||
| TxRequest | source-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | <IP> | |
| destination-ip | METADATA | producer-fqdn | DD_MAPPING | <IP> | ||
| source-port | METADATA | producer-fqdn | producer-fqdn, feed-source-nf-fqdn AND producer-fqdn | DD_MAPPING | <PORT> | |
| destination-port | METADATA | producer-fqdn | DD_MAPPING | <PORT> | ||
| RxResponse | source-ip | METADATA | producer-fqdn | DD_MAPPING | <IP> | |
| destination-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | <IP> | ||
| source-port | METADATA | producer-fqdn | DD_MAPPING | <PORT> | ||
| destination-port | METADATA | producer-fqdn | producer-fqdn, feed-source-nf-fqdn AND producer-fqdn | DD_MAPPING | <PORT> | |
| TxResponse | source-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | <IP> | |
| destination-ip | METADATA | consumer-fqdn | consumer-fqdn, consumer-fqdn AND producer-fqdn | DD_MAPPING | <IP> | |
| source-port | METADATA | feed-source-nf-fqdn | DD_MAPPING | <PORT> | ||
| destination-port | METADATA | feed-source-nf-fqdn | feed-source-nf-fqdn, feed-source-nf-fqdn AND consumer-fqdn | DD_MAPPING | <PORT> | |
Supported L3-L4 Attributes
- consumer-fqdn
- producer-fqdn
- api-name
- feed-source-nf-fqdn
- message-direction
- producer-Id
- consumer-Id
Note:
producer-Id and consumer-Id are supported from OCNADD release 23.3.0 onward.Table 3-3 L3-L4 Mapping Rules
| Mapping Priority | First Priority | Second Priority | Third Priority |
|---|---|---|---|
| DD_MAPPING | Global L3-L4 Mapping Configuration | Least Priority Address (from feed configuration) | - |
| METADATA | Metadata list (incoming message from NF to DD) | Global L3-L4 mapping configuration | Least Priority Address (from feed configuration) |
Note:
- Layer 2 (Ethernet address) information must always be taken from L2-L4 information attributes present in the feed configuration.
- When L3-L4 mapping configuration is absent in feed configuration, the value present in L2-L4 information attributes for feed configuration is used in synthetic packet encoding for Layer3 (IP) and Layer4 (Port).
L3-L4 Information for Synthetic Packet Feed Use Cases
Note:
Only one Global L3-L4 configuration is applicable to all synthetic feeds.Table 3-4 Global L3-L4 Mapping Configuration
| Attribute 1 | Attribute 1 Value | Attribute 2 | Attribute 2 Value | IP Address | Port |
|---|---|---|---|---|---|
| consumer-fqdn | AMF.5g.oracle.com | api-name | nausf-auth | 10.10.10.10 | 1010 |
| consumer-fqdn | AMF.5g.oracle.com | producer-fqdn | AUSF.5g.oracle.com | 10.10.10.10 | 1010 |
| consumer-fqdn | pcf.5g.oracle.com | - | - | 10.10.19.19 | 1919 |
| producer-fqdn | AUSF2.5g.oracle.com | - | - | 10.10.13.13 | 1313 |
| producer-fqdn | AUSF2.5g.oracle.com | - | - | 10.10.15.15 | 1515 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | message-direction | RxRequest | 10.10.11.11 | 1111 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | message-direction | TxResponse | 10.10.11.11 | 1111 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | message-direction | TxRequest | 10.10.14.14 | 1414 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | message-direction | RxResponse | 10.10.14.14 | 1414 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | - | - | 10.10.16.16 | 1616 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | consumer-fqdn | AMF.5g.oracle.com | 10.10.17.17 | 1717 |
| feed-source-nf-fqdn | ocscp.scp1.oracle.com | producer-fqdn | AUSF.5g.oracle.com | 10.10.18.18 | 1818 |
Scenario 1:
When incoming message direction is RxRequest, mapping priority is set to METADATA and source-ip, destination-ip, source-port, destination-port are not present in the metadata-list.
Feed Configuration:
Table 3-5 Feed Configuration
| Direction | Address | Mapping Priority | L3-L4 Mapping Rule | Mapping Reference | Least Priority Address |
|---|---|---|---|---|---|
| RxRequest | source-ip | METADATA | consumer-fqdn AND api-name | DD_MAPPING | 10.20.30.10 |
| destination-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | 10.20.40.10 | |
| source-port | METADATA | feed-source-nf-fqdn AND consumer-fqdn | DD_MAPPING | 3010 | |
| destination-port | METADATA | feed-source-nf-fqdn | DD_MAPPING | 4010 |
NFs Feed Data:
Table 3-6 Metadata List Value
| feed-source-nf-type | consumer-fqdn | message-direction |
|---|---|---|
| ocscp-scp1.oracle.com | AMF.5g.oracle.com | RxRequest |
Header-list Value:
Path:
/nausf-auth/v1/ue-authentications/reg-helm-charts-ausfauth-6bf5986587-kxvb2.34773/5g-aka-confirmation
Table 3-7 Synthetic Packet Encoding
| Source Address | Destination Address | Source Port | Destination Port |
|---|---|---|---|
| 10.10.10.10 | 10.10.11.11 | 1717 | 1616 |
Scenario 2:
When incoming message direction is TxResponse, mapping priority is set to METADATA, and source-ip, destination-ip, source-port, destination-port are not present in the metadata-list.
Feed Configuration:
Table 3-8 Feed Configuration
| Direction | Address | Mapping Priority | L3-L4 Mapping Rule | Mapping Reference | Least Priority Address |
|---|---|---|---|---|---|
| TxResponse | source-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | 10.20.40.10 |
| destination-ip | METADATA | consumer-fqdn AND producer-fqdn | DD_MAPPING | 10.20.30.10 | |
| source-port | METADATA | feed-source-nf-fqdn | DD_MAPPING | 4010 | |
| destination-port | METADATA | feed-source-nf-fqdn AND consumer-fqdn | DD_MAPPING | 3010 |
Metadata-list value:
Table 3-9 Metadata List Value
| feed-source-nf-type | producer-fqdn | consumer-fqdn | message-direction |
|---|---|---|---|
| ocscp-scp1.oracle.com | AUSF.5g.oracle.com | AMF.5g.oracle.com | TxResponse |
Table 3-10 Synthetic Packet Encoding
| Source Address | Destination Address | Source Port | Destination Port |
|---|---|---|---|
| 10.10.11.11 | 10.10.10.10 | 1616 | 1717 |
Scenario 3:
When incoming message direction is TxRequest, mapping priority is set to METADATA and source-ip, destination-ip, source-port, destination-port are not present in the metadata-list.
Feed Configuration:
Table 3-11 Feed Configuration
| Direction | Address | Mapping Priority | L3-L4 Mapping Rule | Mapping Reference | Least Priority Address |
|---|---|---|---|---|---|
| TxRequest | source-ip | METADATA | feed-source-nf-fqdn AND message-direction | DD_MAPPING | 10.20.40.20 |
| destination-ip | METADATA | producer-fqdn | DD_MAPPING | 10.20.50.10 | |
| source-port | METADATA | feed-source-nf-fqdn AND producer-fqdn | DD_MAPPING | 4020 | |
| destination-port | METADATA | producer-fqdn | DD_MAPPING | 5010 |
Metadata-list Value:
Table 3-12 Metadata List Value
| feed-source-nf-type | producer-fqdn | consumer-fqdn | message-direction |
|---|---|---|---|
| ocscp-scp1.oracle.com | AUSF.5g.oracle.com | AMF.5g.oracle.com | TxRequest |
Table 3-13 Synthetic Packet Encoding
| Source Address | Destination Address | Source Port | Destination Port |
|---|---|---|---|
| 10.10.14.14 | 10.10.15.15 | 1818 | 1515 |
3.14 External Kafka Feeds
OCNADD supports the external Kafka consumer applications using the external Kafka Feeds. This enables third-party consumer applications to directly consume data from the Data Director Kafka topic, eliminating the need for any egress adapter. OCNADD only permits only those third-party applications that are authenticated and authorized third-party by the Data Director Kafka service, which is handled using the KAFKA ACL (Access Control List) functionality.
Access control for the external feed is established during Kafka feed creation. Presently, third-party applications are exclusively allowed to perform consumption (READ) from a specific topic using a designated consumer group.
The Data Director provides the following support for external Kafka feeds:
- Creation, updating, and deletion of external Kafka Feeds using OCNADD User Interface (UI).
- Authorization of third-party Kafka consumer applications based on specific user, consumer group, and optional hostname.
- Display of status reports from third-party Kafka consumer applications utilizing external Kafka Feeds in the UI.
- Presentation of consumption rate reports from third-party Kafka consumer applications utilizing external Kafka Feeds in the UI.
Authorization by Kafka requires clients to undergo authentication through either SASL or SSL (mTLS). As a result, enabling external Kafka feed support requires specific settings to be activated within the Kafka broker. This ensures mandatory authentication of Kafka clients by the Kafka service. These properties are not enabled by default and must be configured in the Kafka Service before any Kafka feed can function.
See Enable Kafka Feed Configuration Support section before creating any Kafka Feed using OCNADD UI.
For Kafka Consumer Feed configuration using OCNADD Console UI, see Kafka Feed section in Configuring OCNADD Using CNC Console.