3 OCNADD Features and Feature Specific Limits

This section describes OCNADD features and limits specific to these features.

3.1 OCNADD Feature Specific Limits

This chapter provides a list of the limits defined for specific features in OCNADD.

Table 3-1 OCNADD Feature Specific Limits

Description	Limit Value
Maximum number of worker group support in a Centralized Site	2
Maximum number of parallel filters support per worker group	4
Maximum number of chaining filters support per worker group	2
Maximum number of replicated adapter feeds per worker group	2
Maximum number of Kafka feeds per worker group Maximum two aggregated feeds Maximum three Correlation/Correlation-Filtered feeds Maximum three combinations of Kafka feeds	3
Maximum number of global L3L4 mapping rules supported per worker group	500
Note: The limits are controlled through the helm parameters. For more information, see section "Global Parameters" of Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

3.2 OCNADD Features

This section explains Oracle Communications Network Analytics Data Director (OCNADD) features.

3.2.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.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.2.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.2.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.

You can configure Egress filters based on filter conditions such as:

• 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

You can configure ingress filters based on filter conditions such as:

• 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 section in Configuring OCNADD Using CNC Console.

3.2.4.1 Filter Enhancement

This section explains filter enhancements done in this release.

Table 3-2 Filter Enhancement

Attribute Name	Description
path (old name: service-name)	The attribute name has been changed to 'path,' which was previously 'service-name' until the 23.4.0 release. It can now be utilized to filter data based on the service name along with other values of ":path." The value for the attribute ':path' is extracted from the path attribute present in the header list. Example: ":path": "/nausf-auth/va/ue-authentications" path = nausf-auth or path = ue-authentications This allows to match any specific value from the path header. The name of 'service-name' will be updated to 'path' in the UI starting from the 24.1.0 release, and it will be mapped to the path attribute in the backend. The release upgrade should address the name change from "service-name" to "path" in the UI, Backend, and Database with the 24.1.0 release onwards. Note: This change is not applicable for Ingress Filter.
supi	The value for the 'supi' attribute is obtained by matching the supported header-list and/or message body attributes. When the field's value is empty or null, it should be treated as false in the filter condition. This mechanism provides an option for an exact value match or a pattern-based match from specific supported attributes or from all supported attributes using a priority table. For SUPI filter checks across all supported attributes (PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY), the order is determined by the priority table. For example: "supi":"imsi-111122334455322" This checks for the value in all supported attributes (PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY) based on priority and returns the result from the first match. For SUPI filter checks from specific supported attributes, the attribute name can be specified as follows: "supi": "imsi-111122334455322, <attribute-name>" Where, <attribute-name> can be PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION or MESSAGE_BODY. For example: "supi":"imsi-111122334455322, PATH" This checks for the value only in the path header (:path). The <attribute-name> can be PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY. See Priority Table Supported SUPI values include imsi, nai, gci, or gli. Note: When the filter condition matches with the response message only from the incoming message (and not in the request message), the Transaction filter will not be applied. In such cases, only the response message will be sent or skipped based on the ALLOW/DENY criteria. This behavior is not applicable to Ingress Filter.

Priority Table

The following table lists the priorities with the corresponding attribute and location information:

Table 3-3 Priority Table

1st Priority		2nd Priority		3rd Priority		4th Priority
Attribute name	Location	Attribute name	Location	Attribute name	Location	Attribute name	Location
PATH	header-list (:path)	3GPP_SBI_DISCOVERY_SUPI	header-list (3gpp-sbi-discovery-supi)	LOCATION	header-list (location)	MESSAGE_BODY	5g-sbi-message (supi Or Suci, supi, varUeId(ueId))

3.2.5 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. With the introduction of weighted load balancing, the requests and responses 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 two. 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. At present, only two endpoints are supported. So, any failure in one of the endpoints will result in the complete traffic being sent to the available endpoint.

For information about configuring load balancing using CNC Console, see Configuring OCNADD Using CNC Console

3.2.6 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.2.6.1 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-4 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-4 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.

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-5 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/id, consumer-fqdn/id 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/id	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	producer-fqdn/id	DD_MAPPING	<IP>
	source-port	METADATA	producer-fqdn	producer-fqdn/id, feed-source-nf-fqdn AND producer-fqdn/id	DD_MAPPING	<PORT>
	destination-port	METADATA	producer-fqdn	producer-fqdn/id	DD_MAPPING	<PORT>
RxResponse	source-ip	DD_MAPPING	producer-fqdn	producer-fqdn/id	DD_MAPPING	<IP>
	destination-ip	DD_MAPPING	feed-source-nf-fqdn AND message-direction		DD_MAPPING	<IP>
	source-port	DD_MAPPING	producer-fqdn	producer-fqdn/id	DD_MAPPING	<PORT>
	destination-port	DD_MAPPING	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/id, consumer-fqdn/id AND producer-fqdn/id	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/id	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-6 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-7 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-8 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-9 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-10 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-11 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-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	TxResponse

Table 3-13 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-14 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-15 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-16 Synthetic Packet Encoding

Source Address	Destination Address	Source Port	Destination Port
10.10.14.14	10.10.15.15	1818	1515

3.2.6.2 TCP Seq/Ack

Note:

• This feature is available starting from the OCNADD release 23.4.0 and can be enabled through the Helm chart, with the default setting being off in the 23.4.0 release.
• Starting from OCNADD release 24.1.0, this feature is always enabled, and there is no Helm parameter to enable or disable it.
• The source port of the request message and the destination port of the response message will be changed, and they may not align with the L3L4 Global Mapping configuration in synthetic packet encoding data sent to the 3rd party.
• Users must ensure that the IP and PORT combinations for each connection are configured uniquely and with variance in global L3L4 configuration to avoid collisions.
• During service restart or upgrade, the TCP sequence (Seq) and acknowledgment (Ack) counters will be reset, and the evaluation will restart.

TCP Sequence Number (Seq)

• The TCP sequence number is a 32-bit number crucial for providing a sequence that aligns with other transmitting bytes of the TCP connection.
• It allows the unique identification of each data byte.
• Helps in the formation of TCP segments and reassembling them.
• Maintains a record of the amount of data transferred and received.
• In cases where data is received out of order, it ensures the correct order is maintained.
• If data is lost in the transmission process, it facilitates the request for the retransmission of the lost data.

TCP Acknowledgment Number (Ack)

The acknowledgment number is a counter tracking every byte received in a TCP connection.

TCP Seq & Ack Flow

3.2.6.3 TCP And HTTP2 Connection Message

This feature enables the addition of TCP and HTTP2 connection messages at the beginning of HTTP2 frames for each new connection.

• The first outgoing direction message of a new connection will include the TCP SYN message, TCP SYN ACK message, TCP ACK message, HTTP2 magic frame, HTTP2 SETTINGS frame, and HTTP2 HEADERS frame (DATA frame if present).
• The first incoming direction message of a new connection will include the HTTP2 SETTINGS frame and HTTP2 HEADERS frame (DATA frame if present).
• Subsequent outgoing and incoming messages of the connection will not include any TCP and HTTP2 connection messages; they will send only HTTP2 HEADERS and/or DATA frames.

This feature can be disabled or enabled in the synthetic feed configuration. By default, it is enabled.

Unique connection identifier: srcIP + dstIP + srcPort + dstPort

Note:

• This feature is available starting from the OCNADD release 24.1.0.
• The addition of TCP and HTTP2 connection messages on top of actual HTTP2 HEADERS frames for the initial connection of a message is a customer-specific requirement.

3.2.6.4 Synthetic Packet Segmentation

The synthetic packet segmentation is a customer-specific requirement for their third-party app. By default, this feature shall be disabled.

The synthetic packet segmentation length is configured through synthetic feed configuration. Based on the configured length, the synthetic packet shall be segmented and transmitted to the third-party app.

Note:

It is recommended to provide a segmentation length within the range [1000-5000] when segmentationRequired is set to true in the synthetic feed configuration.

3.2.6.5 HTTP2 Connection based STREAM-ID

This feature enables OCNADD to generate a stream-id instead of using a correlation-id in place for synthetically encoded HTTP2 packets.

• stream-id starts from 0 for the HTTP2 connection message and 1 for HTTP2 HEADERS and DATA frames for each new HTTP2 connection.
• stream-id gets incremented in incremental order within a connection for each new transaction.
• stream-id will be the same for all messages of a transaction, including request messages and response messages.
• A context is maintained for the stream-id in OCNADD, which shall get cleared after the configured timeout. If a message is received after the timeout, it shall have a new stream-id.
• The transaction identifier is the correlation-id, which is present in the metadata list in the incoming message from Oracle NFs.

HTTP2 connection identifier = srcIP + dstIP + srcPort + DstPort

3.2.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.2.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.2.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.2.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.2.11 Health Monitoring

OCNADD performs health monitoring to check the readiness and liveness of each OCNADD service and raises alarms 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 alarm. Few of the important scenarios when an alarm 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:

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 alarms for the missing heartbeat, connection breakdown, and the exceeding threshold.

3.2.12 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 UI, see Kafka Feed section in Configuring OCNADD Using CNC Console.

3.2.13 Centralized Deployment

The OCNADD Centralized deployment modes provide the separation of the configuration and administration PODs from the traffic processing PODs. The single management PODs group can serve multiple traffic processing PODs groups (called Worker Groups), thereby saving resources for management PODs in very large customer deployments spanning multiple individual OCANDD sites. The Management Group of PODs maintains configuration & administration, health monitoring, alarms, and user interaction for all the individual worker groups. The Worker Group represents the traffic processing functions and services and provides features like aggregation, filtering, correlation, and Data Feeds for third-party applications.

Management Group: A logical collection of the configuration and administration functions. It consists of Configuration, Admin, Alarm, HealthMonitoring, Backup, and UI services.

Worker Group: A logical collection of the traffic processing functions. It consists of Kafka, Aggregation, Filter, Adapter, and Correlation services. The worker group names are formed by worker group namespaces and site or cluster name "worker_group_namespace:site_name".

Where,

• The site or Cluster name is a global parameter in the helm charts controlled by the global.cluster.name parameter.
• Worker Group namespaces are:
  • Default worker group namespace: The namespace name used in the Non-Centralized deployment. It will be used as the default worker group namespace name when upgrading from the Non-Centralized DD deployment mode to the Centralized deployment mode.
  • In fresh deployments, it is the namespace name given to the worker group in the worker group charts.

The important points for Centralized deployment are:

• The Centralized deployment mode separates configuration management from traffic processing, enabling independent scaling of traffic processing units.
• Each worker group within a Centralized DD site can have different capacity configurations, but the maximum supported capacity for each worker group must be the same.
• Multiple worker groups can exist in a centralized DD site, supporting traffic rates based on the resource profiles of the worker group PODs. If the worker group is dimensioned for processing 100K MPS traffic and the Centralized DD site has a requirement to support 300~400K MPS then an additional worker group should be created on the centralized DD site.
• Metrics and alarms are generated separately for each worker group.
• Each Centralized DD site should support a fixed number of worker groups; the current release limits this to two.
• Releases 23.4.0 or later support fresh deployments in centralized mode only.
• Upgrading from previous supported releases to Centralized deployment mode is recommended.
• The UI facilitates the configuration of data feeds, filters, and correlation configuration creation specific to the worker group. For more information, see Configuring OCNADD Using CNC Console chapter.

3.2.14 Correlation Feature

The correlation feature provides the capability to correlate messages within a network scenario, represented by a transaction, call, or session, and generate a summary record known as xDR. These generated summary records offer deep insights and visibility into the customer network, proving useful in various features such as:

• Network troubleshooting
• Revenue assurance
• Billing and CDR reconciliation
• Network performance KPIs and metrics
• Advanced analytics & observability

Network troubleshooting stands as a key feature in the monitoring solution. The correlation capability assists the Data Director in providing applications and utilities for troubleshooting failing network scenarios, tracing these scenarios across multiple NFs, and generating KPIs for network utilization and load. This capability enhances network visibility and observability. The KPIs and threshold alerts derived from xDRs offer intuitive insights, enabling reports like network efficiency reports displayed on network dashboards.

The xDRs generated by the Data Director facilitate advanced descriptive and predictive network analytics. The correlation output in the form of xDRs can be integrated into network analytics frameworks like NWDAF or Insight Engine. This integration empowers AI/ML capabilities beneficial in fraud detection, predicting and preventing network spoofing, and mitigating DOS attacks.

Note:

In case of an upgrade, rollback, service restart, or configuration created with the same name, duplicate messages or xDRs will be sent by correlation service to avoid data loss.

For more details about Correlation configuration and xDR, see Correlation Feature Configuration and xDR Format.

For information about Kafka feed creation, correlation configuration, and xDR generation using OCNADD UI, see Creating Kafka Feed, Correlation Configurations, and OCNADD Dashboard sections.

3.2.14.1 Correlation Feature Configuration and xDR Format

This chapter provides the details Kafka feed configuration, correlation configuration, and xDR generation.

3.2.14.1.1 Kafka Feed Configuration for Correlation

This section provides the details of the Kafka Feed configuration for correlation.

Prerequisites

It is mandatory to enable intra TLS for Kafka and create Kafka feed configuration with CORRELATED or CORRELATED_FILTERED Feed Type to consume xDR (Extended Detailed Record) from OCNADD using Correlation Configurations.

Hence, the following prerequisites are crucial for correlation configuration and xDR generation:

1. Create ACL user prior to creating Kafka feeds. See Enable Kafka Feed Configuration Support.
2. Kafka Feed is enabled only when OCNADD services are on TLS. See Enable Kafka Feed Configuration Support.
3. Kafka feed type should be CORRELATED or CORRELATED_FILTERED.
   • CORRELATED Feed Type:

     When the feed type is selected CORRELATED, aggregated data without a filter is used by the Correlation service to generate the xDRs.

     The source topic for correlation service would be the MAIN topic.

     The destination topic to consume data by third-party consumers is prefixed as <kafka-feed-name>-CORRELATED topic.

     Note:

     The user needs to trigger the corresponding Kafka ACL feed delete manually to delete the corresponding Topic, correlation config delete will not delete the topic.
   • CORRELATED_FILTERED Feed Type

     When the feed type is selected CORRELATED_FILTERED, filtered data is used by the Correlation service to generate the xDRs.

     In this type, a filter topic with the name <kafka-feed-name>-FILTERED also gets created along with <kafka-feed-name>-CORRELATED-FILTERED topic. Here the <kafka-feed-name>-FILTERED topic will be used by filter svc to write the filtered data and act as the source topic for the Correlation service. Hence, it is mandatory to create a filter and add <kafka-feed-name> in the egress association name of the filter.

     If the filter is not configured, then the xDR will not be generated by the correlation service.

     The destination topic to consume data by third-party consumers is prefixed as <kafka-feed-name>-CORRELATED-FILTERED topic.

     Note:

     The user needs to trigger the corresponding Kafka ACL feed deletion manually to delete the corresponding topic, correlation configuration deletion will not delete the topic.

3.2.14.1.2 XDR Content

This section provides the details of the xDR mandatory and optional xRD content.

Mandatory xDR Content

Table 3-17 Mandatory xDR Content

Field	Data Type	Presence	Description
version	String	M	Version number of xDR content. Version is 1.0.0 in release 23.3.0 with SUDR support. Version is 2.0.0 in release 23.4.0 with TDR and new attributes support.
configurationName	String	M	Correlation configuration name. This can be used by 3rd party consumers to distinguish between multiple configuration xDR
beginTime	String(UTC time)	M	Date and time in milliseconds of the first message of the xDR. Example: "2023-01-23T07:03:36.311Z"
endTime	String(UTC time)	M	Date and time of the last event in the transaction (last message or timeout). Example: "2023-01-23T07:03:39.311Z"
xdrStatus	Enum	M	xDR status of the correlated transaction. Value: SUDR, COMPLETE, TIMER_EXPIRY, NOT_MATCHED

Optional xDR Content

Note:

The mandatory fields will always be present in xDRs and optional fields will be present based on their availability in the message.

Field	Data Type	Presence	Description
totalPduCount	Integer	O	The total number of messages are present in the transaction. It must be selected in xDR when correlation mode is not set to SUDR. An xDR is generated with a request message and response message then total-pdu-count is set to 2 or the total no. of message of transaction. An xDR is generated with either only a request message or a response message then total-pdu-count is set to 1.
totalLength	Integer	O	Total sum of the message size of all the messages present in the transaction. It will be in bytes.
transactionId	String	O	The unique identifier of the transaction. It must be selected in xDR when correlation mode is not set to SUDR.
transactionTime	String	O	Duration of the complete transaction(endTime-beginTime ). In case of a timeout the transaction time will be calculated between transaction begin time and the timeout event. It must be selected in xDR when correlation mode is not set to SUDR. It will be in milliseconds. Example: 1000
userAgent	String	O	The User-Agent identifies which equipment made the Request. It is taken from the header list and also populated from the first occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: UDM-26740918-e9cd-0205-aada-71a76214d33c udm12.oracle.com
path	String	O	The path and query parts of the target URI. It is present in the HEADERS frame. It is taken from the header list and also populated from the first occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: /nausf-auth/v1/ue-authentications/reg-helm-charts-ausfauth-6bf59-kx.34/5g-aka-confirmation"
supi	String	O	It contains either an IMSI or an NAI. Pattern: '^(imsi-[0-9]{5,15}|nai-.+|.+)$' It is populated from the first occurrence in the message(header-list/5g-sbi-message).
gpsi	String	O	It contains either an External ID or an MSISDN. Pattern: '^(msisdn-[0-9]{5,15}|extid-.+@.+|.+)$' It is populated from the first occurrence in the message(header-list/5g-sbi-message).
pei	String	O	Permanent equipment identifier and it contains an IMEI or IMEISV. Pattern: '^(imei-[0-9]{15}|imeisv-[0-9]{16}|.+)$' It is populated from the first occurrence in the message(header-list/5g-sbi-message).
methodType	Enum	O	It represents the type of request for the transaction. Value: POST, PUT, DELETE, PATCH It is taken from the header list and also populated from the first occurrence RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.
statusCode	String	O	It represents the status type of response for a request in a transaction. Value: 2XX, 3XX, 4XX, 5XX It is taken from the header list and also populated from the last occurrence of TxResponse, or RxResponse in case NRF transactions are TxRequest and RxResponse.
feedSourceNfType	String	O	The type of Oracle NF that copies 5G messages to DD. It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. In 23.3.0: The attribute name was producerNfType. Example: SCP, SEPP, NRF
feedSourceNfFqdn	String	O	The FQDN of Oracle NF copies messages to DD for the transaction. It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: sepp1.5gc.mnc001.mcc101.3gppnetwork.org
feedSourceNfId	UUID	O	The ID of Oracle NF which copies messages to DD for the transaction. It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: 23f32960-7443-1122-90d6-0242ac120003
consumerId	UUID	O	The unique identifier of the consumer sends the request message and receives the response message. It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: 23f32-7443-1122-90d6-0242ac120003
producerId	UUID	O	The unique identifier of the producer receives the request message and sends a response message to the consumer. It is taken from the header list and also populated from the last occurrence of TxRequest. Example: 32960-7443-1122-90d6-0242ac120003 Note: When feedSourceNfType is SEPP or NRF and the data stream point is EGW, it will not be present in the metadata list.
consumerFqdn	String	O	The fqdn address of the consumer who sends the request message and receives the response message. It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: AMF.5g.oracle.com
consumerNfType	String	O	The type of consumer that sends the request message and receives the response message. It is populated from the header list of RxRequest User-Agent, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: AMF, NRF Only the NF name extracted from the user-agent header. user-agent: UDM-26740918-e9cd-0205-aada-71a76214d33c udm12.oracle.com consumerNfType: "UDM"
producerFqdn	String	O	The fqdn address of the producer receives the request message and sends a response message to the consumer. It is taken from the header list and also populated from the last occurrence of TxRequest. Example: UDM.5g.oracle.com
contentType	String	O	It represents the type of message payload (data is DATA frames) that is exchanged in a transaction. It is taken from the header list and also populated from the first occurrence RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: application/json
ingressAuthority	String	O	Node's local IP/FQDN on the ingress side. It is taken from the header list and also populated from the last occurrence of RxRequest. Example: 172.19.100.5:9443
egressAuthority	String	O	Node Next hop's local IP/FQDN on the egress side It is taken from the header list and also populated from the last occurrence of TxRequest. Example: 33.19.10.17:443
consumerVia	String	O	It contains a branch unique in space and time identifying the transaction with the next hop. It is taken from the header list and also populated from the first occurrence RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse. Example: SCP-scp1.5gc.mnc001.mcc208.3gppnetwork.org
producerVia	String	O	It contains a branch unique in space and time identifying the transaction with the next hop. It is taken from the header list and also populated from the first occurrence of RxResponse. Example: sepp02.5gc.mnc002.mcc276.3gppnetwork.org
consumerPlmn	String	O	Public Land Mobile Networkis a mobile operator's cellular network in a specific country. Each PLMN has a unique PLMN code that combines an MCC (Mobile Country Code) and the operators' MNC (Mobile Network Code) It is taken from 5g-sbi-data and also populated from the last occurrence of RxRequest. Example: consumerPlmn: "208-001" 208: MCC 001: MNC
producerPlmn	String	O	Public Land Mobile Networkis a mobile operator's cellular network in a specific country. Each PLMN has a unique PLMN code that combines an MCC (Mobile Country Code) and the operators' MNC (Mobile Network Code) It is taken from 5g-sbi-data and also populated from the last occurrence of TxRequest. Example: consumerPlmn: "276-002" 276: MCC 002: MNC
registrationTime	String	O	Registration time of NF instance with NRF. It is taken from 5g-sbi-data and also populated from the first occurrence in the message.
ueId	String	O	It represents the subscription identifier, pattern: "(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-.+|.+)" It is populated from the first occurrence in the message(header-list/5g-sbi-message). Example: imsi-208014489186000
pduSessionId	Integer	O	Unsigned integer identifying a PDU session. It is taken from 5g-sbi-data and also populated from the first occurrence in the message. Example: 1
smfInstanceId	String	O	Unique identifier for SMF instance It is taken from 5g-sbi-data and also populated from the first occurrence in the message. Example: 8e81-4010-a4a0-30324ce870b2
smfSetId	String	O	Identifier of SMF set id. It is taken from 5g-sbi-data and also populated from the first occurrence in the message.
snssai	String	O	The set of Network Slice Selection Assistance Information. It is taken from 5g-sbi-data and also populated from the first occurrence in the message. Example: "snssai": "{\"sst\":1,\"sd\":\"000001\"}"
dnn	String	O	Data Network Name, It is used to identify and route traffic to a specific network slice. It is taken from 5g-sbi-data and also populated from the first occurrence in the message.
pcfInstanceId	String	O	Unique identifier for PCF instance It is taken from 5g-sbi-data and also populated from the first occurrence in the message. Example: 9981-4010-a4a0-30324ce870b2

3.2.14.1.3 Correlation Modes

This section provides the details of the correlation modes supported by OCNADD.

SUDR xDR

OCNADD generates an SUDR type xDR for each message.

TRANSACTION XDR

Complete Transaction

Once both the request and response messages have been received and processed, a successful transaction xDR is generated with xDR status = Complete.

Complete Re-transmission Transaction

When a request message is resent or re-transmitted within the duration of a transaction, it is referred to as re-transmission.

Timer Expiry Transaction

When the request message has only been received and the response message has either not been received or received after transaction duration, Timer expiry xDR is generated with xDR status = TimerExpiry.

Timer Expiry Re-transmission Transaction

When a request message has not been received with multiple retries but response message has either not been received or received after transaction duration, Timer expiry xDR is generated with xDR status = TimerExpiry.

Not Matched Transaction

When a request message has not been received due to a network issue and only a response message has been received, Not Matched xDR is generated with xDR status = Not Matched.

Un-ordered Transactions

In the case of unordered transactions, if not all messages within a transaction arrive in sequence, a timer, governed by the configured maxTransactionWaitTime in the correlation configuration, will activate to wait for the remaining messages of the transaction.

If the pending messages arrive within the timer's duration, they're included in an existing transaction xDR. Otherwise, new xDRs are generated based on message type.

Note:

When the timestamp of a response message precedes the timestamp of the corresponding request message, the transaction time recorded in the xDR will be a negative value. This discrepancy signals an issue within the network since the response message's timestamp should naturally be later than the request message's timestamp, indicating a potential anomaly.

3.2.14.1.4 Correlation KPIs

These KPIs can be configured with correlation configuration. The selected KPIs in correlation configuration can be visualized in DD UI through the KPI dashboard.

Supported KPIs

• TOTAL_FAILED_NF_DEREGISTRATIONS
• TOTAL_FAILED_NF_DEREGISTRATIONS_PER_NFTYPE
• TOTAL_FAILED_NF_REGISTRATIONS
• TOTAL_FAILED_NF_REGISTRATIONS_PER_NFTYPE
• TOTAL_FAILED_TRANSACTION
• TOTAL_FAILED_TRANSACTION_PER_NFTYPE
• TOTAL_FAILED_TRANSACTION_PER_RESPCODE_CAUSEVALUE
• TOTAL_FAILED_TRANSACTION_PER_SERVICETYPE
• TOTAL_N12_TRANSACTION
• TOTAL_N13_TRANSACTION
• TOTAL_SUCCESSFUL_NF_DEREGISTRATIONS
• TOTAL_SUCCESSFUL_NF_DEREGISTRATIONS_PER_TYPE
• TOTAL_SUCCESSFUL_NF_REGISTRATIONS
• TOTAL_SUCCESSFUL_NF_REGISTRATIONS_PER_NFTYPE
• TOTAL_SUCCESSFUL_TRANSACTION
• TOTAL_SUCCESSFUL_TRANSACTION_PER_NFTYPE
• TOTAL_SUCCESSFUL_TRANSACTION_PER_SERVICETYPE
• TOTAL_TRANSACTION

3.2.15 Two-Site Redundancy

The Two-Site Redundancy feature enhances system reliability by introducing redundancy capabilities across OCNADD sites. In the event of a site failure, the feature ensures uninterrupted data processing by seamlessly transitioning services to a backup site. This is done using a coordination of mated pairs of worker groups, which offer flexibility to configure multiple mated pairs.

The Two-Site Redundancy feature ensures "High Availability" by processing data at different OCNADD sites in the event of a site failure. This id done using mated pairs of worker groups, responsible for managing service redundancy across sites.

To facilitate seamless communication and failover, configuration synchronization is maintained between the worker groups of a mated pair. Here, the "Redundancy Agent" service serves as a crucial component, handling communication between the mated sites. In the event of a failover, the Network Functions (NFs) detect failures and transition to the standby data director site, directing data to the mate worker group.

The Two-Site Redundancy feature has 2 sites, one configured as the "Primary" site and the other as the "Secondary" site. The Primary site also remains in "ACTIVE" mode, while the Secondary can be in "STANDBY" or "ACTIVE" mode. In case of Site Redundancy where the "way" is set to "UNIDIRECTIONAL," the configuration flow always goes from "Primary" to "Secondary." The Data Director mate hosts the different Kafka cluster, and the NFs configure bootstrap addresses for both Kafka clusters, designating one as primary and the other as standby.

When the "way" is set to "BIDIRECTIONAL", the configuration will flow in both the direction, from "Primary" to "Secondary" and "Secondary" to "Primary" site.

Note:

Data redundancy is not in the current scope; only service redundancy is supported in this release.

Key Components:

1. Mated Worker Groups:
   • The feature introduces mated pairs of worker groups responsible for managing service redundancy between OCNADD sites.
   • The configuration of mated pairs is facilitated through the mate group configuration, providing a flexible and scalable setup.
2. Mate Redundancy Agent:
   • A dedicated service, the mate redundancy agent, is introduced to facilitate configuration synchronization between worker groups within a mated pair.
   • The UI sends the mate configuration to the configuration service, and the configuration service relays it to the redundancy agent.
   • This agent plays a crucial role in ensuring seamless failover and maintaining consistency across redundant worker groups.
3. Failover Mechanism:
   • In the event of a site failure, Network Functions (NFs) detect the failure and initiate a failover process.
   • NFs seamlessly transition to the standby data director site and redirect data to the mate worker group, ensuring continuous service availability.
4. Data Director Mate:
   • The Data Director Mate is responsible for hosting a separate Kafka cluster to handle data redirection during failover.
   • NFs configure bootstrap addresses for both Kafka clusters and designate one as primary and the other as standby.

Enable Redundancy

To enable Two-Site Redundancy, see Enable or Disable Two-Site Redundancy Support section.

Two-Site Redundancy Configuration Details

The following table explains the configuration details of various types of feeds.

Table 3-18 Supported Feed Sync

Feed Type	Parameter	Values	AllowConfigSync	Description
Kafka	None	None	Always	Sync will always happen.
Consumer	feed	true or false	Conditional	Sync will happen when UI Site Redundancy Configuration "feed" is set to true.
Filter	filter	true or false	Conditional	Sync will happen when UI Site Redundancy Configuration "filter" is set to true.
Correlation	correlation	true or false	Conditional	Sync will happen when UI Site Redundancy Configuration "correlation" is set to true.

Table 3-19 Syncing Rules

Feed Type	Rules Description
Kafka	List of Kafka Feed Parameters Validated During Sync When Feed Names Match: Feed Type ACL Configuration Rule: If the Kafka feed name is the same, then check for the Kafka Feed Type and ACL configuration. If the feed type is not the same or the ACL configuration is different, a discrepancy alarm is raised, and feed sync is not performed.
Consumer	List of Consumer Feed Parameters Validated During Sync When Feed Names Match: Outbound Connection Target URI Endpoint Aggregation Rules LB Type (Load Balancer Type) Metadata Required Data Stream Offset Rule: If the Consumer feed name is the same, then check for the other attributes listed above. If any of the attributes listed above is different, a discrepancy alarm is raised, and consumer feed sync is not performed.
Filter	List of Filter Parameters Validated During Sync When Filter Names Match: Filter Condition Dto Filter Rule Filter Action (ALLOW/DENY) Filter Association Type Filter Association Names Rule: If the filter name is the same, then check for the other attributes listed above. If any of the attributes listed above is different, a discrepancy alarm is raised, and filter sync is not performed.
Correlation	List of Correlation Feed Parameters Validated During Sync When Correlation Feed Names Match: Data Stream Start Point XDR Type Supported XDR Content Include Message with XDR (Options are Metadata, Header, and Message) Condition check if XDR Type is TDR: Correlation Mode Max Transaction Wait Time Supported KPIs Rule: If the Correlation Feed name is the same, then check for the other attributes listed above. If any of the attributes listed above is different, a discrepancy alarm is raised, and correlation feed sync is not performed.

Two-Site Redundancy Configuration Sync Scenarios

Note:

For more information on Discrepancy Alarms, see Operational Alarms.

Table 3-20 Two Site Redundancy Configuration Sync Scenarios

Config Sync	Mode	Way	Description	Discrepancy Alarms
Consumer Feed: True Filter: True Correlation: True	ACTIVE	UNIDIRECTIONAL	The consumer feed, filter and correlation configuration will be synced to the secondary site as per the Consumer Feed Sync Rules, Correlation Config Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050020, OCNADD050021 and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: True Correlation: True	ACTIVE	BIDIRECTIONAL	The consumer feed, filter and correlation configuration will be synced from primary to the secondary site and vice-versa as per the Consumer Feed Sync Rules, Filter Sync Rules and Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050020, OCNADD050021 and OCNADD050022 could be raised in both primary and secondary sites
Consumer Feed: True Filter: True Correlation: True	STANDBY	UNIDIRECTIONAL	The consumer feed, filter and correlation configuration will be synced to the secondary site as per the Consumer Feed Sync Rules, Correlation Config Sync Rules and Filter Sync Rules is no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050020, OCNADD050021 and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: True Correlation: True	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: True Filter: True Correlation: False	ACTIVE	UNIDIRECTIONAL	The consumer feed and filter configuration will be synced to the secondary site as per the Consumer Feed Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050020 and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: True Correlation: False	ACTIVE	BIDIRECTIONAL	The consumer feed and filter configuration will be synced from primary to the secondary site and vice-versa as per the Consumer Feed Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050020 and OCNADD050022 could be raised in both primary and secondary sites
Consumer Feed: True Filter: True Correlation: False	STANDBY	UNIDIRECTIONAL	The consumer feed and filter configuration will be synced to the secondary site as per the Consumer Feed Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050020 and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: True Correlation: False	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: True Filter: False Correlation: True	ACTIVE	UNIDIRECTIONAL	The consumer feed and correlation configuration will be synced to the secondary site as per the Consumer Feed Sync Rules and Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050021 and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: False Correlation: True	ACTIVE	BIDIRECTIONAL	The consumer feed and correlation configuration will be synced from primary to the secondary site and vice-versa as per the Consumer Feed Sync Rules and Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050021 and OCNADD050022 could be raised in both
Consumer Feed: True Filter: False Correlation: True	STANDBY	UNIDIRECTIONAL	The consumer feed and correlation configuration will be synced to the secondary site as per the Consumer Feed Sync Rules and Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, OCNADD050021 and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: False Correlation: True	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: True Filter: False Correlation: False	ACTIVE	UNIDIRECTIONAL	The Consumer feed configuration will be synced to the secondary site as per the Consumer Feed Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: False Correlation: False	ACTIVE	BIDIRECTIONAL	The Consumer feed configuration will be synced from primary to the secondary site and vice-versa as per the Consumer Feed Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, and OCNADD050022 could be raised in both sites
Consumer Feed: True Filter: False Correlation: False	STANDBY	UNIDIRECTIONAL	The Consumer feed configuration will be synced to the secondary site as per the Consumer Feed Sync Rules if no discrepancy is reported.	OCNADD050018, OCNADD050019, and OCNADD050022 could be raised in Secondary
Consumer Feed: True Filter: False Correlation: False	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: False Filter: True Correlation: True	ACTIVE	UNIDIRECTIONAL	The filter and the correlation configuration will be synced to the secondary site as per the Correlation Config Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050019, OCNADD050020, OCNADD050021, and OCNADD050022 could be raised in Secondary
Consumer Feed: False Filter: True Correlation: True	ACTIVE	BIDIRECTIONAL	The filter and the correlation configuration will be synced from primary to the secondary site and vice-versa as per the Correlation Config Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050019, OCNADD050020, OCNADD050021, and OCNADD050022 could be raised in both primary and secondary sites
Consumer Feed: False Filter: True Correlation: True	STANDBY	UNIDIRECTIONAL	The filter and the correlation configuration will be synced to the secondary site as per the Correlation Config Sync Rules and Filter Sync Rules if no discrepancy is reported.	OCNADD050019, OCNADD050020, OCNADD050021, and OCNADD050022 could be raised in Secondary
Consumer Feed: False Filter: True Correlation: True	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: False Filter: True Correlation: False	ACTIVE	UNIDIRECTIONAL	The filter configuration will be synced to the secondary site as per the Filter Sync Rules if no discrepancy is reported and all the filter association will be removed in secondary site.	OCNADD050019, OCNADD050020, and OCNADD050022 could be raised in Secondary site
Consumer Feed: False Filter: True Correlation: False	ACTIVE	BIDIRECTIONAL	The filter configuration will be synced from primary to the secondary site and vice-versa as per the Filter Sync Rules if no discrepancy is reported and filter association will be removed from secondary site if syncing happened from primary to secondary and from primary site if syncing happened from secondary to primary.	OCNADD050019, OCNADD050020, and OCNADD050022 could be raised in both primary and secondary sites
Consumer Feed: False Filter: True Correlation: False	STANDBY	UNIDIRECTIONAL	The filter configuration will be synced to the secondary site as per the Filter Sync Rules if no discrepancy is reported and all the filter association will be removed in secondary site.	OCNADD050019, OCNADD050020, and OCNADD050022 could be raised in Secondary
Consumer Feed: False Filter: True Correlation: False	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: False Filter: False Correlation: True	ACTIVE	UNIDIRECTIONAL	The correlation configuration will synced to the secondary site as per the Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050019, OCNADD050021 and OCNADD050022 could be raised in Secondary site
Consumer Feed: False Filter: False Correlation: True	ACTIVE	BIDIRECTIONAL	The correlation configuration will synced from primary to the secondary site and vice-versa as per the Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050019, OCNADD050021 and OCNADD050022 could be raised in both primary and secondary sites
Consumer Feed: False Filter: False Correlation: True	STANDBY	UNIDIRECTIONAL	The correlation configuration will synced to the secondary site as per the Correlation Config Sync Rules if no discrepancy is reported.	OCNADD050019, OCNADD050021 and OCNADD050022 could be raised in Secondary site
Consumer Feed: False Filter: False Correlation: True	STANDBY	BIDIRECTIONAL	Not Applicable	Not Applicable
Consumer Feed: False Filter: False Correlation: False	-	-	This is not applicable as one of the option must be selected.	-

Note:

Sync Config Update/Delete

Scenario: Way set to "BIDIRECTIONAL"

If a user deletes or updates the Consumer Feed, Filter, Correlation, or Kafka Feed, a discrepancy alarm will be raised in sync. The primary will also be deleted or updated accordingly.

Check the alarm and verify if the sync discrepancy is corrected or not.

Two-Site Redundancy worker group Name Restriction

The workerGroup serves as a unique identifier, formed by combining the "siteName" and "worker group namespace" with a colon (:) separator. The workerGroup parameter needs to be unique for primary site and secondary site, where "siteName" is the clusterName of the setup and "worker group namespace" is the current worker group namespace.

Scenario: Same site name causing conflict during mate configuration

Site 1

If the siteName is "occne-ocdd," and the workerGroup namespaces are "ocnadd-wg1" and "ocnadd-wg2," then the "workerGroup" attribute will be:

"workerGroup": "ocnadd-wg1:occne-ocdd" or "workerGroup": "ocnadd-wg2:occne-ocdd"

Site 2

If the siteName is "occne-ocdd," and the workerGroup namespaces are "ocnadd-wg1" and "ocnadd-wg2," then the "workerGroup" attribute will be:

"workerGroup": "ocnadd-wg1:occne-ocdd" or "workerGroup": "ocnadd-wg2:occne-ocdd"

If Site Redundancy is mapped for Site 1 as "ocnadd-wg1:occne-ocdd" and Site 2 as "ocnadd-wg1:occne-ocdd," both the Primary site and Mate Site will have the same "workerGroup." This results in similar entries for both Primary and Mate sites.

Resolution

It is recommended that "siteName" should be unique for both sites. If unique site names for the sites are not feasible, mapping of Site 1 "ocnadd-wg1:occne-ocdd" and Site 2 "ocnadd-wg2:occne-ocdd" should be done to maintain unique entries while creating and saving the mate configuration.

3.2.16 Message Sequencing

The Message Sequencing feature enhances transactional message delivery from Data Director (OCNADD) to third-party applications. This capability ensures the ordered and reliable transmission of messages, contributing to a more robust and dependable communication mechanism.

Note:

1. Supported Version: The Message Sequencing feature is supported from version 24.1.0.
2. Key-Based Message Writing: To leverage the full functionality of this feature, key-based message writing from Oracle Network Functions (NFs) must be enabled. This ensures that messages are appropriately ordered based on transaction keys.
3. Recommended Kafka Configuration: It is recommended to set the replication factor (RF) to a value greater than 1 for Kafka topics. This precautionary measure aims to mitigate the risk of data loss in scenarios involving broker failures or partition failures within Kafka topics.
4. Handling Upgrades, Rollbacks, and Service Restarts: During system upgrades, rollbacks, or service restarts, the aggregation service will forward duplicate messages. This is done to prevent data loss and maintain message sequencing integrity during these critical operational events.

Message Sequencing Modes

The Message Sequencing feature offers three distinct modes, each catering to specific use cases and providing flexibility in managing the order and timing of message delivery. The three modes are:

1. Time Based Message Sequencing (Windowing)
2. Transaction Based Message Sequencing
3. Request/Response Based Message Sequencing

Helm Parameters

Table 3-21 Helm Parameters

Parameter	Description	Value
MESSAGE_SEQUENCING_TYPE	Defines the type of message sequencing. The default value is NONE, indicating no message sequencing. Enabling any message sequencing mode will increase end-to-end latency based on the configured time corresponding to the message sequencing mode. Only one message sequencing mode can be enabled at a time. The parameter can be configured separately in the Helm chart for each aggregation service (SCPAggregation, SEPPAggregation, NRFAggregation). REQUEST_RESPONSE is not applicable for NF-TYPE=NRF. When any incorrect or unsupported value is passed in MESSAGE_SEQUENCING_TYPE, it will fall back to the default option (NONE).	NONE TIME_WINDOW REQUEST_RESPONSE TRANSACTION
WINDOW_MSG_SEQUENCING_EXPIRY_TIMER	This parameter defines the time for window-based message sequencing. It must be set when MESSAGE_SEQUENCING_TYPE=TIME_WINDOW. When any incorrect or unsupported value is passed, it will fall back to the default (10ms).	Range [5ms-500ms]; default: 10ms
REQUEST_RESPONSE_MSG_SEQUENCING_EXPIRY_TIMER	This parameter defines the time for REQUEST_RESPONSE based message sequencing. It must be set when MESSAGE_SEQUENCING_TYPE=REQUEST_RESPONSE. When any incorrect or unsupported value is passed, it will fall back to the default (10ms).	Range [5ms-500ms]; default: 10ms.
TRANSACTION_MSG_SEQUENCING_EXPIRY_TIMER	This parameter defines the time for TRANSACTION based message sequencing. It must be set when MESSAGE_SEQUENCING_TYPE=TRANSACTION. When any incorrect or unsupported value is passed, it will fall back to the default (200ms).	Range [20ms-30s]; default: 200ms
MESSAGE_REORDERING_INCOMPLETE_TRANSACTION_METRICS_ENABLE	This parameter can be enabled when the requirement is to check metrics for the failure of message reordering/incomplete transactions. Metrics Name: ocnadd_message_reordering_incomplete_transaction_count The metrics will be pegged for MESSAGE_SEQUENCING_TYPE=REQUEST_RESPONSE or TRANSACTION.	true or false Default: false

1. Time-Based Message Sequencing (Windowing)

   This mode enables the reordering of unordered messages based on the timestamp present in each message. The group of messages received within the window time for each partition separately will be considered for message sequencing. For each partition, when time-based sequencing is completed, all the sequenced messages will stream to the Kafka MAIN topic.

   Helm Parameters:

   • MESSAGE_SEQUENCING_TYPE: TIME_WINDOW
   • WINDOW_MSG_SEQUENCING_EXPIRY_TIMER: 10(ms), range: [5ms-500ms]

   Note:

   • This will add or increase the end-to-end message latency to the configured value of WINDOW_MSG_SEQUENCING_EXPIRY_TIMER and processing time.
   • The older timestamp messages of different windows can be seen in the partition, as, in parallel, multiple threads will be writing data into the same partition (assuming source topic partition count < target topic partition count). The aim is to achieve transaction sequencing.
   
   
   
   
   
2. Request/Response Based Message Sequencing

   This mode enables the reordering of unordered messages based on request (RxRequest, TxRequest) and response (RxResponse, TxResponse) pairs for each transaction.

   Sequencing Rule:

   • NRF:
     • Not applicable for feed-type=NRF as we receive messages of transactions in pairs (RxRequest and TxResponse, TxRequest and RxResponse), and if configured, it will be ignored.
   • SCP/SEPP:
     • When TxRequest is received before RxRequest for a transaction, it shall wait for RxRequest. When RxRequest is received, the messages will stream to the Kafka MAIN topic in order (RxRequest, TxRequest).
     • When RxRequest is received first, the message will stream to the Kafka MAIN topic without any delay.
     • When TxResponse is received before RxResponse for a transaction, it shall wait for RxResponse. When RxResponse is received, the messages will stream to Kafka MAIN topic in order (RxResponse, TxResponse).
     • When RxResponse is received first, the message will stream to Kafka MAIN topic without any delay.

   Helm Parameters:

   • MESSAGE_SEQUENCING_TYPE: REQUEST_RESPONSE
   • REQUEST_RESPONSE_MSG_SEQUENCING_EXPIRY_TIMER: 10 ms (range: 5 ms - 500 ms)

   Note:

   This will add or increase the end-to-end message latency up to the configured value of REQUEST_RESPONSE_MSG_SEQUENCING_EXPIRY_TIMER and processing time.
   
   
   
   
   
3. Transaction Based Message Sequencing

   This mode enables the reordering of unordered messages based on transactions (RxRequest, TxRequest, RxResponse, TxResponse).

   Sequencing Rule:

   1. NRF:

      Transaction order: 'RxRequest and TxResponse' or 'TxRequest and RxResponse'

      • When all messages of a transaction (RxRequest and TxResponse or TxRequest and RxResponse) are received in order, the message will be streamed to Kafka MAIN topic without any delay.
      • When RxResponse is received before TxRequest for a transaction, it will be sent in order when TxRequest is received or after TRANSACTION_EXPIRY_TIME expires.
      • When TxResponse is received before RxRequest for a transaction, it will be sent in order when RxRequest is received or after TRANSACTION_EXPIRY_TIME expires.
   2. SCP/SEPP:

      Transaction order: RxRequest, TxRequest, RxResponse, TxResponse

      • When all messages of a transaction (RxRequest, TxRequest, RxResponse, TxResponse) are received in order, the message will be streamed to Kafka MAIN topic without any delay.
      • When TxRequest is received before RxRequest for a transaction, it will be sent in order when RxRequest is received or after TRANSACTION_EXPIRY_TIME expires.
      • When RxRequest & TxRequest are received in order, and TxResponse is received before RxResponse, the RxRequest and TxRequest will be sent without any delay, and TxResponse shall be sent in order when RxResponse is received or after TRANSACTION_EXPIRY_TIME expires.
      • When RxResponse is received first, it will be sent when RxRequest and TxRequest are received or after TRANSACTION_EXPIRY_TIME expires.
      • When TxResponse is received first, it will be sent when RxRequest, TxRequest, and TxResponse are received or after TRANSACTION_EXPIRY_TIME expires.

   Helm Parameters:

   • MESSAGE_SEQUENCING_TYPE: TRANSACTION
   • TRANSACTION_MSG_SEQUENCING_EXPIRY_TIMER: 200 ms (range: 20 ms - 30 s)

   Note:

   This will add or increase the end-to-end message latency up to the configured value of TRANSACTION_MSG_SEQUENCING_EXPIRY_TIMER and processing time.