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 groups 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
Maximum number of export configurations supported	3
Maximum number of Trace configurations supported	1

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 attribute 'supi' value is used for matching from supported header lists and/or message body attributes. When the field's value is empty or null, it is treated as false in the filter condition. It 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. SUPI filter check from all supported attributes (PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY) as per the order defined in the priority table. "supi": "imsi-111122334455322": Check for the value in all supported attributes (PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY) based on priority and return from the first match. SUPI filter check from specific supported attributes (PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY). "supi": "imsi-111122334455322, <attribute-name>": <attribute-name> can be PATH, 3GPP_SBI_DISCOVERY_SUPI, LOCATION, or MESSAGE_BODY. Example: "supi": "imsi-111122334455322, PATH": Check for the value only in the path header (:path). See Priority Table Supported Supi: imsi, nai, gci, or gli Note: The filter will not be applied when the filter condition matches the response message but not the request message. It applies to the transaction filter. The response message will be considered when a match is found in the request message. Not applicable for Ingress Filter.
method	The value for the attribute 'method' is taken for matching from the ":method" attribute present in the header list. It applies to the transaction filter; the response message is considered when a match is found in the request message. When the value of the field is empty or null,it is treated as false in the filter condition. Values: [GET, POST, PUT, DELETE, PATCH, CONNECT, OPTIONS, TRACE]. Example: ":method": "POST" Note: Not applicable for 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 (supiOrSuci, supi, ueId, supiRm, varUeId)

3.2.5 SCP Model-D Support

Note:

The 'SCP User Agent Info' must be enabled on the SCP NF before running Model-D traffic.

Steps to enable 'SCP User Agent Info"

Follow the steps below to enable SCP User Agent Info on SCP:

1. Login to CNC Console interface and navigate to the SCP UI, then SCP Features.
2. Locate SCP User Agent Info and set enabled as true.

Reference:

For additional details, see Cloud Native Core, Service Communication Proxy REST Specification Guide and search for scp_user_agent_info.

Feature Overview:

In Model-D, the SCP takes full control of the NF discovery and selection processes. Unlike Model-C, which requires two separate requests for these processes, Model-D consolidates them into a single request.

As part of the Model-D flow, a new header, 3GPP-SBI-DISCOVERY, is introduced in 3GPP Release 16. This header enables indirect communication for discovery and selection.

Key Workflow:

1. The Consumer NF includes Discovery Parameters and directly sends a service request to the SCP with the 3GPP-SBI-DISCOVERY header:
   • Authority: SCP
   • 3GPP-SBI-DISCOVERY: Producer NF Discovery Parameters
2. The SCP performs delegated discovery and selects the optimal Producer NF to handle the request, based on factors such as location, load, capacity, priority and health of the Producer NFs.

Model-D Support Added in the Following OCNADD Features:

• Correlation Feature
• Message Sequencing
• dd-metadata-list

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

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
• user-agent

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.7.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.7.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.7.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.7.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.8 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-4 Data Replication

3.2.9 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-5 Backup and Restore

3.2.10 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-6 Secure Transport

3.2.11 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-7 Operational Dashboard

For more information about accessing the dashboard through CNC Console, see OCNADD Dashboard.

3.2.12 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.13 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.14 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 OCNADD 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 OCNADD 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 OCNADD 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 OCNADD 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 OCNADD site has a requirement to support 300~400K MPS then an additional worker group should be created on the centralized OCNADD site.
• Metrics and alarms are generated separately for each worker group.
• Each Centralized OCNADD 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.15 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.15.1 Correlation Feature Configuration and xDR Format

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

3.2.15.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.15.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.15.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.15.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.1.5 SCP Model-D TDR xDR

Reference: For details on SCP Model-D, see SCP Model-D Support section.

In this release, the correlation configuration includes an option to exclude SCP-originated messages from TDR xDRs. Use the following configuration parameter to enable this option:

Attribute: sourceFeedCorrCriteria

This attribute provides a configuration option to exclude SCP-originated messages (e.g., delegated discovery, OAuth2 token, etc.) from TDR xDRs.

• When enabled: SCP-originated messages are excluded from TDR xDRs to reduce unnecessary data, optimizing the information for third-party applications.
• Default setting: Disabled. This means all SCP-originated messages will be included in TDR xDRs.

Example Configuration: To exclude the SCP-originated messages

sourceFeedCorrCriteria: [{"SCP": "EXCLUDE_SCP_ORIGINATED_MESSAGES"}]

3.2.16 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.17 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 from 24.1.0.
2. Key-based message writing from Oracle NFs must be enabled.
3. It is recommended to use RF > 1 for Kafka topics to avoid data loss in case of broker or topic partition failure.
4. In case of an upgrade, rollback, or service restart, duplicate messages will be sent by the aggregation service to avoid data loss, and message sequencing will be impacted during that time.
5. In the 24.2.0.0.1 release, SCP Model-D support has been added, which is applicable for all types of SCP message sequencing. See SCP Model-D Support.

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.
   
   
   
   
   

3.2.18 Third-party NF Data Processing Through Ingress Adapter

The Ingress Adapter is a component of Data Director that extends its capabilities to allow data processing from various third-party Network Functions (NFs). The third-party NFs will provide data in HTTP/2 format along with predefined custom headers. The third-party NFs provide data in HTTP/2 format with predefined custom headers. The Ingress Adapter transforms the data into a format supported by Data Director (DD), which internal OCNADD services can then utilize for further processing.

To enable or disable third-party NF data processing through Ingress Adapter, see Enabling or Disabling Third-party NF Data Processing.

3.2.18.1 Data Transformation

The message transformation functionality will allow data conversion and mapping from Thirdparty NF to Oracle NF data which will be consumed by OCNADD internal services for data processing. The conversion framework will provide capabilities to map the following metadata fields into OCNADD format (OracleNfFeedDto) for processing.

Metadata Mapping

Table 3-22 Metadata Mapping

Parameter	Description
correlation-id	Range: <Ingress-attribute-name> Condition: M Default Value: NA Description: Correlation ID is mandatory to correlate all mirrored request and response messages of a transaction. If a custom correlation ID is not provided, OCNADD will attempt to retrieve this from the 3gpp-Sbi-Correlation-Info header if available. It must be present in either of the two attributes.
timestamp	Range: <Ingress-attribute-name> Condition: M Default Value: NA Description: This property defines the timestamp of the request when it is initiated. If a non-Oracle NF is not sending the timestamp, then OCNADD will generate it. However, the end-to-end latency calculation will not be accurate in that case.
message-direction	Range: <Ingress Attribute name(list)> Condition: M Default Value: NA Description: It consists of both the message direction (ingress or egress) and the message type (Request or Response). The non-Oracle feeds may send message direction and message type in different custom headers. The Oracle ingress adapter will combine both and map it to the supported OracleNfFeedDto.
consumer-fqdn	Range: <Ingress Attribute name> Condition: O Default Value: NA Description: The consumer FQDN will be mapped with the received value of the configured ingress attribute name in custom headers. If the value is not present, then it will be skipped.
consumer-id	Range: <Ingress Attribute name> Condition: O Default Value: NA Description: The consumer ID will be mapped with the received value of the configured ingress attribute name in custom headers. If the value is not present, then it will be skipped.
hop-by-hop-id	Range: <Ingress Attribute name> Condition: O Default Value: NA Description: The hop-by-hop ID will be mapped with the received value of the configured ingress attribute name in custom headers. If the value is not present, then it will be skipped.
producer-fqdn	Range: <Ingress Attribute name> Condition: O Default Value: NA Description: The producer FQDN will be mapped with the received value of the configured ingress attribute name in custom headers. If the value is not present, then it will be skipped.
producer-id	Range: <Ingress Attribute name> Condition: O Default Value: NA Description: The producer ID will be mapped with the received value of the configured ingress attribute name in custom headers. If the value is not present, then it will be skipped.
reroute-cause	Range: <Ingress Attribute name> Condition: O Default Value: NA Description: The reroute cause will be mapped with the received value of the configured ingress attribute name in custom headers. If the value is not present, then it will be skipped.
feed-source-nf-type	Range: <Ingress Attribute name>, use feed-source Host Address mapping Condition: M Default Value: <default-nf-type> The "nf type" for OracleNfFeedDto will be mapped from the ingress attribute name provided during feed creation. However, if the attribute name is not present in the custom headers, then the feed-source host IP address will be taken from the "custom-forward-for" or "x-forwarded-for" header if present. A lookup will then be performed from the feed source host address mapping to get the nf-type. If the x-forwarded-for header is not present, then the source IP of the request will be used. If the source IP is not present in the feed source host address map, then a default value will be used for mapping. However, it is recommended to use the default value when only one NF is producing data.
feed-source-nf-instance-id	Range: <Ingress Attribute name>, Use feed-source Host Address mapping Condition: C Default Value: <default-nf-instance-id> Description: The "nf instance id" for OracleNfFeedDto will be mapped from the ingress attribute name provided during feed creation. However, if the attribute name is not present in the custom headers, then the feed-source host IP address will be taken from the "custom-forward-for" or "x-forwarded-for" header if present. A lookup will then be performed from the feed source host address mapping to get the nf-instance-id. If the x-forwarded-for header is not present, then the Source IP of the request will be used. If the source IP is not present in the feed source host address map, then a default value will be used for mapping. However, it is recommended to use the default value when only one NF is producing data.
feed-source-nf-fqdn	Range: <Ingress Attribute name>, Use feed-source Host Address mapping Condition: C Default Value: <default-nf-fqdn> Description: The "nf instance fqdn" for OracleNfFeedDto will be mapped from the ingress attribute name provided during feed creation. However, if the attribute name is not present in the custom headers, then the feed-source host IP address will be taken from the "custom-forward-for" or "x-forwarded-for" header if present. A lookup will then be performed from the feed source host address mapping to get the nf-fqdn. If the x-forwarded-for header is not present, then the Source IP of the request will be used. If the source IP is not present in the feed source host address map, then a default value will be used for mapping. However, it is recommended to use the default value when only one NF is producing data.
feed-source-nf-pod-instance-id	Range: <Ingress Attribute name> Condition: O Default Value: <default-nf-pod-instance-id> Description: The "nf pod instance id" for OracleNfFeedDto will be mapped from the ingress attribute name provided during feed creation. However, if the attribute name is not present in the custom headers, then a default value will be used for mapping. It is recommended to use the default value when only one NF is producing data.

The metadata fields from Thirdparty NFs can be present either in "MESSAGE_HEADER" or "MESSAGE_BODY". Depending on the value of the parameter "metadataLocation" supplied during configuration creation, the ingress adapter will retrieve the attributes and perform the transformation of these fields to the OracleNfFeedDto. If metadata is present in the message body, additional fields such as "metadataFormat" and "metadataMappingAttrName" need to be configured.

Headers and Payload Mapping

The ingress adapter will also map the incoming headers (SBI Message headers) and payload (5G SBI Message) information to the data format supported by Data Distribution (DD). Currently, the SBI Message headers are extracted from the message body and mapped to the OCNADD supported data format.

3.2.19 Data Director Metadata Enrichment

Metadata refers to additional information about a message that can be leveraged for message processing without delving deep into the message itself. Applications utilize this metadata for various purposes, such as enriching other messages, filtering messages, and correlating transactions. Enriching data using metadata facilitates enhanced troubleshooting of network scenarios created by third-party applications receiving feeds from the Data Director.

The Data Director metadata enrichment framework is beneficial when NF metadata is incomplete or when NFs cannot provide additional message information. In such cases, Data Director inspects message headers or bodies to gather supplementary information and enriches messages belonging to the same transactions. Additional metadata from Data Director is provided as a separate JSON structure within the message. Users have the flexibility to enable/disable metadata enrichment and include/exclude metadata from messages delivered as part of Data Director message feeds.

The following key points should be considered for the metadata enrichment in the Data Director:

1. The metadata enrichment is configured using the UI; however, in current release, the APIs are used to configure the metadata attributes configuration on the Data Director.
2. When the feature is enabled on the Aggregation service, it will populate the in-memory table of configured metadata attributes against the correlation key made up of "correlation-id + nf-instance-id."
3. The metadata attributes are populated from the RxRequest/TxRequest message for the given key "correlation-id + nf-instance-id." The table is then looked up further to add/update the "dd-metadata-list" for the other messages of the transaction (having the same correlation key). In current release, RxRequest is used to populate the Metadata table for SCP and SEPP, whereas RxRequest and TxRequest are used to populate the Metadata table for NRF, BSF, and PCF..
4. The Aggregation service adds the "dd-metadata-list" in the original incoming message before writing into the MAIN topic. However, the consumer feeds (HTTP2/Synthetic) or Kafka feed (filtered feed, correlated, correlated filtered) will have the option to exclude this "dd-metadata-list" from the original packet.
5. The metadata enrichment requires that Message sequencing must be enabled for Message Sequencing Type=TRANSACTION/REQUEST_RESPONSE/TIME_WINDOW.
6. The aggregated Kafka feed will always have "dd-metadata-list" if the metadata feature is enabled on the Data Director.
7. The dd-metadata-list, even if excluded in the consumer/Kafka feeds, is used for filtering, l3l4 mapping, correlation features. The priority will be given to the "dd-metadata-list" over the NF metadata for filtering as well as l3l4 mapping for synthetic packet.

3.2.19.1 Data Director Metadata Attributes

The following attributes are supported in the Data Director metadata list:

Table 3-23 Data Director Metadata Attributes

path	The path and query parts of the target URI. They are present in the HEADERS frame. They are taken from the header-list and populated from the first occurrence of the request message. For SCP and SEPP, it will be RxRequest. For NRF, it can be with either RxRequest or TxRequest as NRF transactions could be RxRequest→TxResponse or TxRequest→RxResponse. Example: "/nausf-auth/v1/ue-authentications/reg-helm-charts-ausfauth-6bf59-kx.34/5g-aka-confirmation"
user-agent	The User Agent identifies which equipment made the Request. It is present in the HEADERS frame. It shall be taken from the header-list and populated from the first occurrence of the request message. For SCP and SEPP, it will be RxRequest. For NRF, it can be with either RxRequest or TxRequest as NRF transactions could be RxRequest→TxResponse or TxRequest→RxResponse. Example: "UDM-26740918-e9cd-0205-aada-71a76214d33c udm12.oracle.com"
method	It represents the type of request for the transaction. It is present in the HEADERS frame. It shall be taken from the header-list and populated from the first occurrence of the request message. For SCP and SEPP, it will be RxRequest. For NRF, it can be with either RxRequest or TxRequest as NRF transactions could be RxRequest→TxResponse or TxRequest→RxResponse. Value: POST, PUT, DELETE, PATCH
consumer-via	It contains a branch unique in space and time identifying the transaction with the next hop. It shall be taken from the header-list and shall be populated from the first occurrence RxRequestuest. In the case of an array of "via" in a message, the last occurrence from the list will be considered. For SCP and SEPP, it will be RxRequest. For NRF, it will be RxRequest or TxRequest as NRF transactions could be RxRequest→TxResponse or TxRequest→RxResponse. Example: "SCP-scp1.5gc.mnc001.mcc208.3gppnetwork.org"
ingress-authority	Node's local IP/FQDN on the ingress side. It shall be taken from the header-list and shall be populated from the last occurrence of RxRequestuest. For SCP and SEPP, it will be RxRequest. For NRF, it will be from RxRequest or TxRequest as NRF transactions could be RxRequest→TxResponse or TxRequest→RxResponse. Example: "172.19.100.5:9443"
supi	It represents the subscription identifier, pattern: '^(imsi-[0-9]{5,15}|nai-.+| gci-.+|gli-.+|.+)$'. It shall be populated from the first occurrence in RxRequest path header or the 3GPP_SBI_DISCOVERY_SUPI header. For SCP and SEPP, it will be RxRequest. For NRF, it can be with either RxRequest or TxRequest as NRF transactions could be RxRequest→TxResponse or TxRequest→RxResponse. Example: "imsi-208014489186000"

3.2.19.2 Data Director Metadata Enrichment Configuration

OCNADD Metadata Configuration

For regular HTTPS connection:

curl -vk --location --request POST https://ocnaddconfiguration.ab-mgmt:12590/ocnadd-configuration/v1/dd-metadata \
--header 'Content-Type: application/json' \
--data-raw '{
    "workerGroup": "dd-wg1:ocnadd-vcne",
    "metadataEnabled": true,
    "metadataAttributes": ["path","supi","consumer-via","ingress-authority","method","user-agent"],
    "feedSourceNfTypes": ["SCP"]
}'

If intraTLS or intraTLS & mTLS are enabled, use the following command:

curl -vk --location --cert-type P12 --cert /var/securityfiles/keystore/clientKeyStore.p12:$OCNADD_SSL_KEY_STORE_PASSWORD --request POST https://ocnaddconfiguration.ab-mgmt:12590/ocnadd-configuration/v1/dd-metadata \
--header 'Content-Type: application/json' \
--data-raw '{
    "workerGroup": "dd-wg1:ocnadd-vcne",
    "metadataEnabled": true,
    "metadataAttributes": ["path","supi","consumer-via","ingress-authority","method","user-agent"],
    "feedSourceNfTypes": ["SCP"]
}'

Data Director Metadata Consumer Feed Configuration

• A parameter "ddMetadataRequired" to include the "OCNADD Metadata List" shall be provided in the adapter feeds for both synthetic and HTTP2 feed types.
• If this parameter is enabled, then the consumer adapter will include the "dd-metadata-list" in the message; otherwise, exclude it from the message.

Data Director Metadata Kafka Feed Configuration

• A parameter "ddMetadataRequired" to include the "OCNADD Metadata List" shall be provided in the Kafka feeds for AGGREGATED-FILTERED Feed type. This parameter should only be provided for the "AGGREGATED-FILTERED" feed type and should not be provided for other Kafka feed types.
• If this parameter is enabled, then the Filter service will include the "dd-metadata-list" in the message; otherwise, exclude it from the message while writing it to the filtered topic.
• The AGGREGATED feed type will always include the "dd-metadata-list" in the message.

Data Director Metadata Correlation Configuration

• A parameter "ddMetadataRequired" to include the "OCNADD Metadata List" shall be provided in the correlation configuration.
• If this parameter is enabled in the correlation configuration, then the corresponding correlation service will include the "dd-metadata-list" in the message; otherwise, exclude it from the message while writing to the xDR topic.

For more information on the Data Director Metadata List, See Oracle Communications Network Analytics Data Director Outbound Specification Document.

3.2.19.3 SCP Model-D Support

Reference: For details on SCP Model-D, see SCP Model-D Support section.

The dd-metadata support is introduced for the SCP Model-D scenario with the following rules:

• Rule 1: The dd-metadata from the RxRequest is copied only to NF-originated messages within the transaction. It will not be included in SCP-originated messages.
• Rule 2: The dd-metadata from SCP-originated TxRequest messages is copied to the same hop's RxResponse transaction message. This applies to the TxRequest and RxResponse pair with the same hop-by-hop ID in a transaction.

Table 3-24 NF Message Meta Data Attributes

NF Message Meta Data Attributes						DD Meta Data Attributes
Message Direction	Time Stamp	Message Type	Hop-by-hop-id	consumer-fqdn == feed-source-nf-fqdn	path	user-agent	method	consumer-via	producer-via	ingress-authority	egress-authority	supi
RxRequest	1727130533265522369	NF Originated	NA_cp-scp-worker-5fc7cc4d9b-8x2vs	no	/USEast/nudm-uecm/...	udm	POST	2.0 SCP-scp1	amf	-	udmocscp	100001101
TxRequest	1727130533365522369	SCP Originated(Discovery)	cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_3	yes	/discovery-path/...	nrf	PUT	-	nrf	nrfocscp	-	123344
RxResponse	1727130533465522369	SCP Originated(Discovery)	cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_3	yes	/discovery-path/...	nrf	PUT	-	nrf	nrfocscp	-	123344
TxRequest	1727130533515522369	SCP Originated(Oauth2)	cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_1	yes	/oauth2-path/…	nrf1	POST	scp2	nrf	-	ocscpnrf2	-
RxResponse	1727130533535522369	SCP Originated(Oauth2)	cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_1	yes	/oauth2-path/…	nrf1	POST	scp3	nrf	-	ocscpnrf3	-
TxRequest	1727130533545522369	NF Originated	cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_6	no	/USEast/nudm-uecm/...	udm	POST	2.0 SCP-scp1	amf	-	udmocscp	100001101
RxResponse	1727130533555522369	NF Originated	cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_6	no	/USEast/nudm-uecm/...	udm	POST	2.0 SCP-scp1	amf	-	udmocscp	100001101
TxResponse	1727130533565522369	NF Originated	NA_cp-scp-worker-5fc7cc4d9b-8x2vs	no	/USEast/nudm-uecm/...	udm	POST	2.0 SCP-scp1	amf	-	udmocscp	100001101
Metadata from NF originated RxRequest are enrcihed as a dd-metadata on NF originated TxRequest, RxResponse and TxResponse messages. Metadata from SCP originated TxRequest discovery are enrcihed as a dd-metadata on SCP originated TxResponse discovery message. Metadata from SCP originated TxRequest oath2 are enrcihed as a dd-metadata on SCP originated TxResponse oauth2 message.

3.2.20 Extended xDR Storage

The Data Storage feature enhances the Data Director's capability to persist xDRs records with PDUs in a database. The persisted xDRs can be exported to NFS or an external file storage in CSV/PCAP format. The persisted xDR records provide deep insights and visibility into the customer network and can be helpful in features such as:

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

The persisted xDRs records can facilitate advanced descriptive and predictive network analytics as xDRs can be fed into network analytics tools to provide AI/ML capabilities that can be helpful in fraud detection, predicting, and preventing network spoofing and DOS attacks.

Note:

• In the current release, 1K MPS inbound data rate is supported in the correlation feed for extended storage with a maximum of 24 hours of retention.
• IPv6/FQDN is not supported in the SFTP server IP.
• File paths should be relative; absolute paths are not supported.
• In case there is no data (either data is not present or for some intervals it is not present) or very little data due to which the max file size is not reached, the file will be generated when the max file size is reached, or if the existing file has some data from the past and the currentTimeStamp+interval does not have data.
• In case of an upgrade, rollback, service restart, or configuration created with the same name, duplicate messages/xDRs will be sent by the storage adapter service to avoid data loss.

Steps to Delete/Stop Purge Job for Each Correlation Configuration When Extended Storage is Enabled

1. Exec into any management service pod:

   First, gain access to the management service pod by executing the following command:

   kubectl exec -it <management-service-pod-name> -- /bin/bash

2. Run the command to delete/stop the purge job:

   Use the following curl command to delete/stop the purge job for the corresponding correlation configuration when extended storage is enabled:

   
   curl -v -k --location --request DELETE 'https://ocnaddexportservice:12595/ocnadd-export/v1/event/<correlation configuration name>' --header 'Content-Type: application/json'

   Replace <correlation-configuration-name> with the actual name of your correlation configuration.

3.2.21 Trace

The Data Trace feature provides the capability to visualize the trace of records with or without messages in the OCNADD UI. A list of transactions, calls, or sessions can represent this visualization. The generated trace of records can offer deep insights and visibility into the customer network and can be useful in various features, including:

• Network troubleshooting
• Revenue Assurance
• Advanced analytics & observability

Network troubleshooting is a key feature of the monitoring solution, and the Data Director's correlation capability enables it to provide applications and utilities for troubleshooting failing network scenarios, tracing network scenarios across multiple NFs, and generating KPIs to provide network utilization and load insights. This feature serves as an enabler for network visibility and observability, just like the trace of records.

For Trace configuration using OCNADD GUI, see Trace Criteria for xDR.

3.2.22 Export

Data Export Service provides the capability to export xDRs with or without messages in CSV or PCAP format, represented by a list of transactions, calls, or sessions. The generated export records can offer deep insights and visibility into the customer network and can be useful in features such as:

• Network troubleshooting
• Revenue assurance
• Advanced analytics & observability

Network troubleshooting is one of the key features of the monitoring solution, and the correlation capability will help Data Director to provide applications and utilities to perform troubleshooting of failing network scenarios, tracing network scenarios across multiple NFs, and generating the KPIs to provide network utilization and load insights. This feature is an enabler for network visibility, observability, and the trace of records.

For Export configuration using OCNADD GUI, see Create Export Configuration.

Export Feature Prerequisite

Create credentials for the SFTP server:

Run the follwing command to create crednetials for the SFTP server:

kubectl create secret generic sftpuser-10148214139 --from-literal=credential=password123 -n <management-namespace>

For example:

• Secret Name: sftpuser-10148214139 (username-ipaddress without '.' and '-' is mandatory)
• Username: sftpuser
• SFTP Server IP Address: 10.148.214.139
• Credential: password123 (password of the SFTP server)

Note:

• In case of an upgrade, rollback, service restart, or configuration created with the same name, duplicate reports (CSV/PCAP/trace) will be sent by the export service to avoid data loss.
• PCAP export will only work when "includeMessageWithxDR=METADATA_HEADERS_DATA" in correlation configuration.

3.2.23 OCCM In OCNADD

OCNADD supports authentication and authorization procedures, including TLS, OAuth2, and CCA, using key pairs and X.509 certificates issued by trusted authorities (Certificate Authority). To comply with security standards, these certificates must be periodically renewed as they can be revoked if compromised.

This feature integrates OCNADD with Oracle Communications Certificate Manager (OCCM) to automate the entire certificate lifecycle management including, creation, renewal, revocation, and removal using CMPv2 procedures. It ensures continuous service availability and adherence to security recommendations. OCCM in OCNADD automates key-pair generation, certificate enrollment, and distribution to NFs, efficiently managing certificates and preventing service disruptions.

For more information about OCCM, see Renewing SSL certificates for OCNADD Services section in this document, and see "Installing OCNADD " and "Customizing OCNADD" chapters in the Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.