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, BSF, PCF, 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:


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:


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:
  • path
  • supi
  • method
  • 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 attribute ':path' is extracted from path attribute present in header list or dd-metadata-list.

Priority List:
  • dd-metadata list
  • 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.

Note: This change is not applicable for Ingress Filter. It is applicable for transaction filter, when a match is found in Request message and the attribute is missing in response message then also it will be considered.

user-agent

The value for the attribute 'user-agent' is taken from the user-agent attribute present in the header-list or dd-metadata-list.

Priority List:
  • dd-metadata list
  • header list

Example:

  • user-agent ='amf-*' or 'amf*'

    The condition will be true when the value of the user-agent starts with amf, and any suffix (e.g., amf-1275859595848, amf-1275859595848 3gppnetwork.org) added after amf will be ignored.

  • user-agent = 'amf-1275859595848 5G:mnc311.mcc282.3gppnetwork.org'

    The condition will be true when the value of the user-agent exactly matches 'amf-1275859595848 5G:mnc311.mcc282.3gppnetwork.org'.

Note: Not applicable for Ingress Filter. It is applicable for the transaction filter. When a match is found in the Request message, and the attribute is missing in the Response message, it will still be considered.

consumer-id

The value for the attribute 'consumer-id' is taken from the consumer-id attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

Example:

"consumer-id": "127-Abd-5859595848"

consumer-id = 127-Abd-5859595848"
producer-id

The value for the attribute 'producer-id' is taken from the producer-id attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

Example:

"producer-id": "9faf1bbc-6e4a-4454-a507-aef01a101a06"

producer-id = 9faf1bbc-6e4a-4454-a507-aef01a101a06
consumer-fqdn

The value for the attribute 'consumer-fqdn' is taken from the consumer-fqdn attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

Example:

"consumer-fqdn": "5G:mnc311.mcc100.3gppnetwork.org"

consumer-fqdn = 5G:mnc311.mcc100.3gppnetwork.org
producer-fqdn

The value for the attribute 'producer-fqdn' is taken from the producer-fqdn attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

Example:

"producer-fqdn": "scp.inter.oracle.com"

producer-fqdn = scp.inter.oracle.com
message-direction

The value for the attribute 'message-direction' is taken from the message-direction attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

Values:

  • TxRequest
  • RxRequest
  • RxResponse
  • TxResponse

Note: When message-direction is added in a single or combination filter, the Transaction filter shall not be applied. Each message will be evaluated separately using the configured filter rule and filter condition.

reroute-cause

The value for the attribute 'reroute-cause' is taken from the reroute-cause attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

Example:

'reroute-cause': "ErrorReceived"

reroute-cause = ErrorReceived

Note: The reroute-cause is sent only by the SCP NF.
feed-source-nf-type

The value for the attribute 'feed-source-nf-type' is taken from the feed-source attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

It represents Oracle NF types (SCP, NRF, SEPP, PCF, BSF, <NF>_NON_ORACLE).

Example:

"feed-source":  {
      "nf-type": "SCP",
 }

feed-source-nf-type = SCP
feed-source-nf-fqdn

The value for the attribute 'feed-source-nf-fqdn' is taken from the feed-source attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

It represents the Oracle NF's FQDN.

Example:

"feed-source": {  
      "nf-fqdn": "scp-worker.scpsvc.svc.ocnadd-tanzu.local"  
}  

feed-source-nf-fqdn = "scp-worker.scpsvc.svc.ocnadd-tanzu.local"
feed-source-nf-instance-id

The value for the attribute 'feed-source-nf-instance-id' is taken from the feed-source attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

It represents the Oracle NF's instance ID.

Example:

"feed-source": {  
      "nf-instance-id": "6faf1bbc-6e4a-4454-a507-a14ef8e1bc5e"  
}  

feed-source-nf-instance-id = "6faf1bbc-6e4a-4454-a507-a14ef8e1bc5e"
feed-source-pod-instance-id

The value for the attribute 'feed-source-pod-instance-id' is taken from the feed-source attribute present in the metadata-list.

When the value of the field is empty or null, it shall be treated as false in the filter condition.

It represents the Oracle NF pod's instance ID.

Example:

"feed-source": {  
      "pod-instance-id": "scpsvc-scp-worker-7d599cc56f-x5t62"  
}  

feed-source-pod-instance-id = "scpsvc-scp-worker-7d599cc56f-x5t62"
supi

It is supported from release 24.1.0.

The value for the attribute 'supi' is taken for matching from the supported header-list and/or message body attributes. When the value of the field is empty or null, it shall be 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 the priority table.

  • SUPI filter check from all supported attributes (PATH or 3GPP_SBI_DISCOVERY_SUPI or LOCATION or MESSAGE_BODY) as per the order defined in the priority table.

    Example:

    "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 1st match.

  • SUPI filter check from specific supported attributes (PATH or 3GPP_SBI_DISCOVERY_SUPI or LOCATION or MESSAGE_BODY).

    Example:

    "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

It is supported from release 24.2.0.

The value for attribute 'method' is taken for match from ":method" attributes present header-list or dd-metadata-list.

Priority List:
  • dd-metadata list
  • 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 5th Priority
Attribute name Location Attribute name Location Attribute name Location Attribute name Location Attribute name Location
PATH dd-metadata list ( path) 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.

SCP Model D Support

Model-D Support Added in the Following OCNADD Features:

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.


Weighted Load Balancing Based on Correlation ID

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-1 Synthetic Packet Data Generation


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.


Global L3-L4 Configuration

Note:

OCNADD supports GUI-based configuration of L3-L4 information:

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.


Feed L3-L4 Mapping Configuration

Note:

Two mapping rules should be combined only with the operator AND, no other operator is supported.

Supported L3-L4 Attributes

Table 3-5 Supported L3-L4 Attributes

Attribute Description
user-agent

The user-agent will always be considered from the "dd-metadata-list" for matching with the global L3L4 configuration. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping). If it is not present in the "dd-metadata-list" of the message, the least priority address (default mapping) will be used for synthetic packet encoding.

Supported From: Release 24.2.0

Prerequisites:
  • Message reordering feature must be enabled.
  • "dd-metadata-list" addition in inbound data must be enabled with the feature "DD_METADATA."
Supported Pattern Matching:

Incoming Message Value

user-agent = 'amf-1275859595848 5G:mnc001.mcc002.3gppnetwork.org'

  1. Match Any Value After Suffix
    • Condition:

      user-agent = 'amf*'

      The condition will be true when the value of the user-agent starts with amf, and any suffix (e.g., amf-1275859595848 or amf-1275859595848 3gppnetwork.org) added after amf will be ignored.

  2. Match Exact Value
    • Condition:

      user-agent = 'amf-1275859595848 5G:mnc001.mcc002.3gppnetwork.org'

      The condition will be true when the value of the user-agent exactly matches 'amf-1275859595848 5G:mnc001.mcc002.3gppnetwork.org.

  3. Match In-Between Value
    • Condition:

      user-agent = '*1275859595848*'

      The condition will be true when the value of the user-agent contains 1275859595848 in the user-agent metadata header.

      Note: The pattern must start and end with *. This is useful for matching in-between values of the user-agent.

source-ip

The source-ip will always be considered from the "metadata-list" for matching with the global L3L4 configuration. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).

Supported From: Release 25.1.0

producer-id

The producer-id will always be considered from the "metadata-list" for matching with the global L3L4 configuration. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).

Supported From: Release 23.3.0

producer-fqdn The producer FQDN will always be considered from "metadata-list" for matching with global L3L4 config. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).
message-direction The message direction will always be considered from "metadata-list" for matching with global L3L4 config. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).
ingress-authority

Ingress-authority will always be considered from the "dd-metadata-list" for matching with the global L3L4 configuration. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping). If it is not present in the "dd-metadata-list" of the message, it shall be taken from the least priority address (default mapping) for synthetic packet encoding.

Supported From: Release 25.1.0

Prerequisite:

  • Message reordering feature must be enabled.
  • "dd-metadata-list" addition in inbound data must be enabled with the feature DD_METADATA.
feed-source-nf-fqdn feed-source-nf-fqdn will always be considered from "metadata-list" for matching with global l3l4 config, if it matches, ip and/or port will be mapped in synthetic message else it will be taken from least priority address (default mapping).
destination-ip The destination IP will always be considered from "metadata-list" for matching with global L3L4 config. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).

Supported From: Release 25.1.0

consumer-id The consumer ID will always be considered from "metadata-list" for matching with global L3L4 config. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).
consumer-fqdn The consumer FQDN will always be considered from "metadata-list" for matching with global L3L4 config. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).
api-name
  • The api-name will always be considered from the "metadata-list" for matching with the global L3L4 configuration. If it matches, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).
  • The user must add the api-name taken from the :path header as a value for this attribute in the global L3L4 configuration.
Supported Formats:
  • nausf-auth or nausf* or *nausf* formats are supported, and they will have the same matching output.
    • Example: When api-name is nausf*, values present in the metadata, such as nausf-auth, nausf-sorprotection, or nausf-upuprotection, will match.

      This will fulfill the requirement for L3 and L4 mapping when the same AUSF NF is serving all services.

  • nausf*-auth: It is not advisable to add * in between the attribute's value for regex matching, as the condition may or may not match based on the value.
    • Example:
      • When api-name is nausf*-auth, values present in the metadata, such as nausf-auth, nausf-sorprotection, or nausf-upuprotection, will match, but only the first one will be taken.
      • When api-name is nausf*-test, values such as nausf-auth, nausf-sorprotection, or nausf-upuprotection will not match, as no value will fulfill the condition.
egress-authority

The egress-authority will always be considered from the dd-metadata-list for matching with the global L3L4 configuration. If a match is found, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).

If egress-authority is not present in the dd-metadata-list of the message, it will be taken from the least priority address (default mapping) for synthetic packet encoding.

This feature is supported from release 25.1.200 and is not available in the RxRequest message.

Prerequisites:

  • Message reordering feature must be enabled.
  • dd-metadata-list addition in inbound data must be enabled via the DD_METADATA feature.
  • The value will be populated from the TxRequest message and enriched in the remaining response messages of the transaction.
previous-hop

The previous-hop will always be considered from the dd-metadata-list for matching with the global L3L4 configuration. If a match is found, the IP and/or port will be mapped in the synthetic message; otherwise, it will be taken from the least priority address (default mapping).

If previous-hop is not present in the dd-metadata-list of the message, it will be taken from the least priority address (default mapping) for synthetic packet encoding.

This is supported from release 25.1.200.

Prerequisites:

  • Message reordering feature must be enabled.
  • dd-metadata-list addition in inbound data must be enabled via the DD_METADATA feature.
  • See dd-metadata for priority rule mapping.

Table 3-6 L3-L4 Mapping Rules Priority

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


TCP Seq and 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.

TCP and HTTP2 Connection Message

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.

Synthetic Packet Segmentation

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


HTTP2 Connection based STREAM-ID

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:


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-2 Backup and Restore


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-3 Secure Transport


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


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:


Health Monitoring

The health monitoring functionality also supports collection of various metrics related to the service resource utilization. It stores them in the metric collection database tables. The health monitoring service generates 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.


External Kafka Feed

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


Correlation Service

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/BSF/PCF 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/BSF/PCF 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/PCF/BSF 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/PCF/BSF 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/PCF/BSF 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/PCF/BSF 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/PCF/BSF 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/PCF/BSF 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 /NRF/PCF/BSF and the data stream point is Egress Gateway, 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/PCF/BSF 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/PCF/BSF 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/PCF/BSF 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/PCF/BSF 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.
SUDR xDR

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.
TRANSACTION XDR

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.
Complete Re-transmission Transaction

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 Transaction

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.
Timer Expiry Re-transmission Transaction

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.
Not Matched Transaction

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.


Un-ordered Transactions

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.


Enable Redundancy

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:
  1. Feed Type
  2. 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:
  1. Outbound Connection
  2. Target URI Endpoint
  3. Aggregation Rules
  4. LB Type (Load Balancer Type)
  5. Metadata Required
  6. 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:
  1. Filter Condition Dto
  2. Filter Rule
  3. Filter Action (ALLOW/DENY)
  4. Filter Association Type
  5. 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:
  1. Data Stream Start Point
  2. XDR Type
  3. Supported XDR Content
  4. Include Message with XDR (Options are Metadata, Header, and Message)
  5. 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:

  • Supported from 24.1.0.
  • Key-based message writing from Oracle NFs must be enabled.
  • It is recommended to use RF > 1 for Kafka topics to avoid data loss in case of broker or topic partition failure.
  • 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.
  • In the 25.1.0 release, SCP Model-D support has been added, which is applicable for all types of SCP message sequencing. See SCP Model-D Support.
  • In case request messages are not in order (e.g., TxRequest of oauth2 message comes before TxRequest of discovery messages, etc.) in a transaction, it is recommended to check the network as well as SCP message copy behavior. Until this is resolved, follow these steps:
    • Enable ENQUEUE_SCP_ORIGIN_MESSAGES=true in the value.yaml file of the ocnaddaggregation service for SCP.
    • Perform a Helm update.
  • When the parameter is enabled, DD will hold all SCP-originated messages until the NF-origin RxResponse or TxResponse messages are received, or the transaction timer expires to handle the scenario. This will also add some latency in message delivery. Enable this parameter only when the above scenario or issue is occurring frequently.

Message Sequencing Overview

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, PCFAggregation. BSFAggregation).
  • 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.

    Time Based Message 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/PCF/BSF:
      • Not applicable for feed-type=NRF, PCF, BSF 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.

    Request/Response Based Message Sequencing

  3. Transaction Based Message Sequencing

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

    Sequencing Rule:

    1. NRF/PCF/BSF:

      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.

    Transaction Based Message Sequencing

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.


Third-party NF Data Processing Through Ingress Adapter

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 used during message processing without requiring applications to deeply inspect the message content. Applications use metadata to enrich other messages, filter messages, and correlate transactions. Metadata-enriched data can assist third-party applications that consume feeds from the Data Director in more effectively troubleshooting network scenarios.

The Data Director metadata enrichment framework is particularly useful when metadata from Network Functions (NFs) is incomplete or when NFs are not capable of providing sufficient contextual information about the message. In such cases, the Data Director inspects message headers or message bodies to derive and attach additional metadata, enriching all messages associated with the same transaction. This enriched metadata is provided as a separate JSON construct within the message.

Metadata enrichment can be configured to be enabled or disabled. It is also possible to include or exclude metadata from the messages delivered as part of the Data Director's message feeds.

Figure 3-5 Data Director Metadata Enrichment


Data Director Metadata Enrichment

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

  1. Configuration: Metadata enrichment shall be configured using the UI; however, in the current release, APIs will be used to configure the metadata attributes on the Data Director.
  2. Metadata Table Lookup: Metadata attributes will be populated from the RxReq/TxReq message using the key "correlation-id + nf-instance-id". The metadata table will then be looked up to add or update the dd-metadata-list for other messages in the same transaction (having the same correlation key).
  3. Source NfType: SCP/SEPP:
    1. RxRequest: Used to create an entry in the metadata table. Metadata attributes are extracted from either the NF metadata or the header list in the incoming message. These are populated in the metadata table, and the dd-metadata-list is created and added to the RxReq message.
    2. TxRequest: The metadata table is looked up, and the metadata attributes are used to create the dd-metadata-list, which is added to the TxReq message.
      • For some dd-metadata attributes, the TxRequest message will be used to create the entry in the metadata table. In that case, enriched attributes will not be added to the dd-metadata-list in the RxRequest message.
    3. TxResponse: The metadata table is looked up, and the metadata attributes are used to create the dd-metadata-list, which is added to the TxResp message.
    4. RxResponse: The metadata table is looked up, and the metadata attributes are used to create the dd-metadata-list, which is added to the RxResp message.
  4. Source NfType: NRF / BSF / PCF (Two flows supported):
    1. Flow A:
      • RxRequest: Creates the metadata table entry. Metadata attributes are extracted from either the NF metadata or the header list in the incoming message. The dd-metadata-list is created and added to the RxReq message.
      • TxResponse: The metadata table is looked up, and the metadata attributes are used to create the dd-metadata-list, which is added to the TxResp message.
    2. Flow B:
      • TxRequest: Used to create the metadata table entry. Metadata attributes are extracted from either the NF metadata or the header list in the incoming message. The dd-metadata-list is created and added to the TxReq message.
      • RxResponse: The metadata table is looked up, and the metadata attributes are used to create the dd-metadata-list, which is added to the RxResp message.
  5. Aggregation Service: The Aggregation service shall add the dd-metadata-list to the original incoming message before writing it into the MAIN topic. However, consumer feeds (HTTP2/Synthetic) or Kafka feeds (Filtered feed, Correlated, Correlated Filtered) will have the option to remove the dd-metadata-list from the original packet.
  6. Retention Policy: Entries in the metadata table are retained for a configurable period of time, after which they are purged. This retention period is the same as that used by the message ordering feature. Note that the message ordering feature is required for metadata enrichment.
  7. Kafka Feed Behavior: The aggregated Kafka feed will always include the dd-metadata-list if the metadata feature is enabled on the Data Director.
  8. Usage in Features: The dd-metadata-list, even if not enabled in consumer/Kafka feeds, will still be used for Filtering, L3/L4 Mapping, and Correlation features. Priority will be given to the dd-metadata-list over the NF metadata for both Filtering and L3/L4 Mapping in synthetic packets.
  9. Resource Requirements: If message sequencing and metadata enrichment are both enabled, additional compute resources such as CPU and memory will be required.
  10. Helm Configuration: Message sequencing will be enabled through Helm chart parameters in the Aggregation services.
3.2.19.1 Data Director Metadata Attributes

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

Note:

The priority mapping rule can be reordered, but adding or removing a rule is prohibited.

Attribute: path

Description: The path and query parts of the target URI. It is present in the HEADERS frame.

Feed Source Mapping – Priority Mapping Rule:

Table 3-23 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP First occurrence of RxRequest :path header-list
NRF/PCF/BSF First occurrence of RxRequest or TxRequest

Example:

/nausf-auth/v1/ue-authentications/reg-helm-charts-ausfauth-6bf59-kx.34/5g-aka-confirmation

Attribute: user-agent

Description: The User Agent identifies which equipment made the request. It is present in the HEADERS frame.

Feed Source Mapping – Priority Mapping Rule:

Table 3-24 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP First occurrence of RxRequest user-agent header-list
NRF/PCF/BSF First occurrence of RxRequest or TxRequest

Example:

UDM-26740918-e9cd-0205-aada-71a76214d33c udm12.oracle.com

Attribute: method

Description: Represents the type of request for the transaction. It is present in the HEADERS frame.

Feed Source Mapping – Priority Mapping Rule:

Table 3-25 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP First occurrence of RxRequest :method header-list
NRF/PCF/BSF First occurrence of RxRequest or TxRequest

Value: POST, PUT, DELETE, PATCH

Attribute: consumer-via

Description: Contains a branch unique in space and time, identifying the transaction with the next hop.

Feed Source Mapping – Priority Mapping Rule:

Table 3-26 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP First occurrence of RxRequest via header-list
NRF/PCF/BSF First occurrence of RxRequest or TxRequest

Note: In case of an array of via in a message, the last occurrence from the list will be used.

Example:

SCP-scp1.5gc.mnc001.mcc208.3gppnetwork.org

Attribute: ingress-authority

Description: Node's local IP/FQDN on the ingress side.

Feed Source Mapping – Priority Mapping Rule:

Table 3-27 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP Last occurrence of RxRequest :authority header-list
NRF/PCF/BSF Last occurrence of RxRequest or TxRequest

Example:

172.19.100.5:9443

Attribute: supi

Description: Represents the subscription identifier. Pattern: ^(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)$

Feed Source Mapping – Priority Mapping Rule:

Table 3-28 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP Last occurrence of RxRequest :path header-list
NRF/PCF/BSF Last occurrence of RxRequest or TxRequest 3gpp-Sbi-Discovery-supi header-list

Example:

imsi-208014489186000

Attribute: previous-hop

Description: Represents a portion of the network path between the source NF and the destination NF.

Feed Source Mapping – Priority Mapping Rule:

Table 3-29 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population)
SCP/SEPP Last occurrence of RxRequest
NRF/PCF/BSF Last occurrence of RxRequest or TxRequest

Table 3-30 Priority Mapping Rule

Rule Name Location
via header-list
3gpp-Sbi-NF-Peer-Info header-list
3gpp-Sbi-Discovery-requester-nf-instance-fqdn header-list
3gpp-Sbi-Discovery-requester-nf-instance-id header-list
consumer-fqdn metadata-list
user-agent header-list

Format of previous-hop value in dd-metadata-list:

Table 3-31 Format of previous-hop value in dd-metadata-list

Default Priority Order DD Metadata Attribute Name DD Metadata Value Format
1 via via_<value>
2 3gpp-Sbi-NF-Peer-Info nf-info_<value>
3 3gpp-Sbi-Discovery-requester-nf-instance-fqdn nf-fqdn_<value>
4 3gpp-Sbi-Discovery-requester-nf-instance-id nf-id_<value>
5 consumer-fqdn con-fqdn_<value>
6 user-agent usr-agnt_<value>
  • The priority rule order can be changed in the dd-metadata configuration.
  • A prefix (short name of the attribute) will be added before the value to identify the source attribute.
  • In L3L4 mapping, Filter, and other processing features using dd-metadata, the prefix will be removed from the value before applying previous-hop conditions.

Example (populated from via):

previous-hop: "via_SCP-scp1.5gc.mnc001.mcc208.3gppnetwork.org"

Attribute: egress-authority

Description: Node's local IP/FQDN on the egress side.

Feed Source Mapping – Priority Mapping Rule:

Table 3-32 Feed Source Mapping – Priority Mapping Rule

NF Type Message Direction (source of attribute population) Rule Name Location
SCP/SEPP Last occurrence of TxRequest :authority header-list
NRF/PCF/BSF Last occurrence of RxRequest or TxRequest

Example:

172.19.100.5:9443

Note:

egress-authority is supported from release 25.1.200 release. It shall not be populated in the RxRequest message's dd-metadata-list header for SCP/SEPP.
3.2.19.2 Data Director Metadata Enrichment Configuration

Create Configuration

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata 

curl -v --location --request POST 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata' \
--header 'Content-Type: application/json' \
--data-raw '{
  "workerGroup": "<dd-worker-group-name>",
  "ddMetadataEnabled": true,
  "ddMetaData": [
    {
      "ddMetaDataAttribName": "method",
      "feedSourceMapping": {
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": {
        ":method": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "user-agent",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"]
      },
      "priorityMappingRule": {
        "user-agent": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "path",
      "feedSourceMapping": {
        "SCP": ["RxRequest"],
        "BSF": ["RxRequest", "TxRequest"]
      },
      "priorityMappingRule": {
        ":path": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "consumer-via",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"]
      },
      "priorityMappingRule": {
        "via": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "ingress-authority",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"],
        "BSF": ["RxRequest", "TxRequest"],
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": {
        ":authority": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "supi",
      "feedSourceMapping": {
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": {
        ":path": ["header-list"],
        "3gpp-Sbi-Discovery-supi": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "egress-authority",
      "feedSourceMapping": {
        "SCP": ["TxRequest"]
      },
      "priorityMappingRule": {
        ":authority": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "previous-hop",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"],
        "SCP": ["RxRequest"],
        "BSF": ["RxRequest", "TxRequest"],
        "PCF": ["RxRequest", "TxRequest"]
      },
      "priorityMappingRule": {
        "via": ["header-list"],
        "3gpp-Sbi-NF-Peer-Info": ["header-list"],
        "3gpp-Sbi-Discovery-requester-nf-instance-fqdn": ["header-list"],
        "3gpp-Sbi-Discovery-requester-nf-instance-id": ["header-list"],
        "consumer-fqdn": ["metadata-list"],
        "user-agent": ["header-list"]
      }
    }
  ]
}'

Update Configuration

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata 

curl -v --location --request PUT 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata' \
--header 'Content-Type: application/json' \
--data-raw '{
  "workerGroup": "<dd-worker-group-name>",
  "ddMetadataEnabled": true,
  "ddMetaData": [
    {
      "ddMetaDataAttribName": "method",
      "feedSourceMapping": {
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": {
        ":method": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "user-agent",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"]
      },
      "priorityMappingRule": {
        "user-agent": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "path",
      "feedSourceMapping": {
        "SCP": ["RxRequest"],
        "BSF": ["RxRequest", "TxRequest"]
      },
      "priorityMappingRule": {
        ":path": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "consumer-via",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"]
      },
      "priorityMappingRule": {
        "via": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "ingress-authority",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"],
        "BSF": ["RxRequest", "TxRequest"],
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": {
        ":authority": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "supi",
      "feedSourceMapping": {
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": {
        ":path": ["header-list"],
        "3gpp-Sbi-Discovery-supi": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "egress-authority",
      "feedSourceMapping": {
        "SCP": ["TxRequest"]
      },
      "priorityMappingRule": {
        ":authority": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "previous-hop",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"],
        "SCP": ["RxRequest"],
        "BSF": ["RxRequest", "TxRequest"],
        "PCF": ["RxRequest", "TxRequest"]
      },
      "priorityMappingRule": {
        "consumer-fqdn": ["metadata-list"],
        "3gpp-Sbi-NF-Peer-Info": ["header-list"],
        "3gpp-Sbi-Discovery-requester-nf-instance-fqdn": ["header-list"],
        "3gpp-Sbi-Discovery-requester-nf-instance-id": ["header-list"],
        "via": ["header-list"],
        "user-agent": ["header-list"]
      }
    }
  ]
}'

Delete Configuration

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata/{workerGroup} 

curl -v --location --request DELETE 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata/<dd-worker-group-name>'

Get DD Metadata Configuration

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata?workerGroup={workerGroup}

cURL Example (GET Request)

curl -v --location --request GET 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata?workerGroup={workerGroup}'

Response Body Example

{
  "workerGroup": "<dd-worker-group-name>",
  "ddMetadataEnabled": true,
  "ddMetaData": [
    {
      "ddMetaDataAttribName": "method",
      "feedSourceMapping": { "SCP": ["RxRequest"] },
      "priorityMappingRule": { ":method": ["header-list"] }
    },
    {
      "ddMetaDataAttribName": "user-agent",
      "feedSourceMapping": { "SEPP": ["RxRequest"] },
      "priorityMappingRule": { "user-agent": ["header-list"] }
    },
    {
      "ddMetaDataAttribName": "path",
      "feedSourceMapping": { "SCP": ["RxRequest"], "BSF": ["RxRequest", "TxRequest"] },
      "priorityMappingRule": { ":path": ["header-list"] }
    },
    {
      "ddMetaDataAttribName": "consumer-via",
      "feedSourceMapping": { "SEPP": ["RxRequest"] },
      "priorityMappingRule": { "via": ["header-list"] }
    },
    {
      "ddMetaDataAttribName": "ingress-authority",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"],
        "BSF": ["RxRequest", "TxRequest"],
        "SCP": ["RxRequest"]
      },
      "priorityMappingRule": { ":authority": ["header-list"] }
    },
    {
      "ddMetaDataAttribName": "supi",
      "feedSourceMapping": { "SCP": ["RxRequest"] },
      "priorityMappingRule": {
        ":path": ["header-list"],
        "3gpp-Sbi-Discovery-supi": ["header-list"]
      }
    },
    {
      "ddMetaDataAttribName": "egress-authority",
      "feedSourceMapping": { "SCP": ["TxRequest"] },
      "priorityMappingRule": { ":authority": ["header-list"] }
    },
    {
      "ddMetaDataAttribName": "previous-hop",
      "feedSourceMapping": {
        "SEPP": ["RxRequest"],
        "NRF": ["RxRequest", "TxRequest"],
        "SCP": ["RxRequest"],
        "BSF": ["RxRequest", "TxRequest"],
        "PCF": ["RxRequest", "TxRequest"]
      },
      "priorityMappingRule": {
        "consumer-fqdn": ["metadata-list"],
        "3gpp-Sbi-NF-Peer-Info": ["header-list"],
        "3gpp-Sbi-Discovery-requester-nf-instance-fqdn": ["header-list"],
        "3gpp-Sbi-Discovery-requester-nf-instance-id": ["header-list"],
        "via": ["header-list"],
        "user-agent": ["header-list"]
      }
    }
  ]
}

Get Supported DD-Metadata Attributes

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata/supported-dd-metadata-attributes

cURL Example (GET Request)

curl -v --location --request GET 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata/supported-dd-metadata-attributes'

Response Body Example

[
  "method",
  "user-agent",
  "path",
  "consumer-via",
  "ingress-authority",
  "supi",
  "egress-authority",
  "previous-hop"
]

Get DD-Metadata Attribute Mapping Rule

Fetch All Mapping Rule

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata/attribute-mapping-rule

cURL Example (GET Request)

curl -v --location --request GET 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata/attribute-mapping-rule'

Response Body Example

[
  {
    "ddMetaDataAttribName": "method",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      ":method": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "user-agent",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      "user-agent": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "path",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      ":path": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "consumer-via",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      "via": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "ingress-authority",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      ":authority": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "supi",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      ":path": ["header-list"],
      "3gpp-Sbi-Discovery-supi": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "egress-authority",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      ":authority": ["header-list"]
    }
  },
  {
    "ddMetaDataAttribName": "previous-hop",
    "feedSourceMapping": {
      "SCP": ["RxRequest"],
      "SEPP": ["RxRequest"],
      "NRF": ["RxRequest", "TxRequest"],
      "BSF": ["RxRequest", "TxRequest"],
      "PCF": ["RxRequest", "TxRequest"]
    },
    "priorityMappingRule": {
      "via": ["header-list"],
      "3gpp-Sbi-NF-Peer-Info": ["header-list"],
      "3gpp-Sbi-Discovery-requester-nf-instance-fqdn": ["header-list"],
      "3gpp-Sbi-Discovery-requester-nf-instance-id": ["header-list"],
      "consumer-fqdn": ["metadata-list"],
      "user-agent": ["header-list"]
    }
  }
]
Fetch Specific DD-Metadata Attribute Mapping Rule

Rest End Point: <apiRoot>/ocnadd-configuration/v2/dd-metadata/attribute-mapping-rule?previous-hop

cURL Example (GET Request)

curl -v --location --request GET 'http://<ocnaddconfiguration_svc-ip>:<port>/ocnadd-configuration/v2/dd-metadata/attribute-mapping-rule?attribute-name=previous-hop'

Response Body Example

{
  "ddMetaDataAttribName": "previous-hop",
  "feedSourceMapping": {
    "SCP": ["RxRequest"],
    "SEPP": ["RxRequest"],
    "NRF": ["RxRequest", "TxRequest"],
    "BSF": ["RxRequest", "TxRequest"],
    "PCF": ["RxRequest", "TxRequest"]
  },
  "priorityMappingRule": {
    "via": ["header-list"],
    "3gpp-Sbi-NF-Peer-Info": ["header-list"],
    "3gpp-Sbi-Discovery-requester-nf-instance-fqdn": ["header-list"],
    "3gpp-Sbi-Discovery-requester-nf-instance-id": ["header-list"],
    "consumer-fqdn": ["metadata-list"],
    "user-agent": ["header-list"]
  }
}

Data Director Metadata Consumer Feed Configuration

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

Data Director Metadata Kafka Feed Configuration

  • A parameter ddMetadataRequired to include the DD Metadata List shall be provided in the Kafka feeds for the 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, the Filter service will include the dd-metadata-list in the message; otherwise, it will 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 DD Metadata List shall be provided in the correlation configuration.
  • If this parameter is enabled in the correlation configuration, the corresponding correlation service will include the dd-metadata-list in the message; otherwise, it will 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-33 NF Message Meta Data Attributes

Message Direction Time Stamp Message Type Hop-by-hop-id consumer-fqdn == feed-source-nf-fqdn path
RxRequest 1727130533265522369 NF Originated NA_cp-scp-worker-5fc7cc4d9b-8x2vs no /USEast/nudm-uecm/...
TxRequest 1727130533365522369 SCP Originated (Discovery) cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_3 yes /discovery-path/...
RxResponse 1727130533465522369 SCP Originated (Discovery) cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_3 yes /discovery-path/...
TxRequest 1727130533515522369 SCP Originated (Oauth2) cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_1 yes /oauth2-path/...
RxResponse 1727130533535522369 SCP Originated (Oauth2) cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_1 yes /oauth2-path/...
TxRequest 1727130533545522369 NF Originated cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_6 no /USEast/nudm-uecm/...
RxResponse 1727130533555522369 NF Originated cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_6 no /USEast/nudm-uecm/...
TxResponse 1727130533565522369 NF Originated NA_cp-scp-worker-5fc7cc4d9b-8x2vs no /USEast/nudm-uecm/...

Table 3-34 DD Meta Data Attributes

Message Direction user-agent method consumer-via producer-via ingress-authority egress-authority supi
RxRequest udm POST 2.0 SCP-scp1 amf - udmocscp 100001101
TxRequest nrf PUT nrf nrf nrfocscp - 123344
RxResponse nrf PUT nrf nrf nrfocscp - 123344
TxRequest nrf1 POST scp2 nrf - ocscpnrf2 -
RxResponse nrf1 POST scp3 nrf - ocscpnrf3 -
TxRequest udm POST 2.0 SCP-scp1 amf - udmocscp 100001101
RxResponse udm POST 2.0 SCP-scp1 amf - udmocscp 100001101
TxResponse udm POST 2.0 SCP-scp1 amf - udmocscp 100001101

Note:

  • Metadata from NF-originated RxRequest messages is enriched as dd-metadata on NF-originated TxRequest, RxResponse, and TxResponse messages.
  • Metadata from SCP-originated TxRequest discovery is enriched as dd-metadata on SCP-originated TxResponse discovery messages.
  • Metadata from SCP-originated TxRequest OAuth2 is enriched as dd-metadata on SCP-originated TxResponse OAuth2 messages.

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.

Extended xDR Storage

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.


Trace

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.


Export

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.

Enhancement from OCNADD Release 24.3.0

In case the export type is set to PCAP, the user has the option to derive L2L4 and L3L4 information from the available synthetic feed name.

This reduces the manual effort if the information is already provided in the synthetic feed configuration and needs to be used in the export configuration.

  • If the synthetic feed is not available or not selected by the user, manual entry for L2L4 and L3L4 is allowed.
  • If the already selected synthetic feed's L2L4 and/or L3L4 information is updated, deleted, or recreated, the change is not reflected in the export configuration, as updates to the export configuration are not currently supported. Recreate the export configuration to fetch the latest L2L4 and L3L4 information from the synthetic feed.
  • Recreate the export configuration to map updated L2L4 and L3L4 information from the synthetic feed to the export configuration.
  • Updates for L2L4 and L3L4 information from the synthetic feed will be considered when export configuration updates are supported.

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.

3.2.24 Traffic Segregation Using CNLB

In response to the need for more efficient traffic management within the combined Oracle Communications Cloud Native Environment (OCCNE) stack, which includes OCNADD, Oracle Communications Billing and Revenue Management (BRM), and Elastic Charging Engine (ECE), the "Traffic Segregation Using CNLB" feature was developed.

This feature addresses the challenge of logically separating IP traffic of different profiles, such as latency-sensitive traffic and configuration or management traffic, which are typically handled through a single network (Kubernetes overlay). The new functionality ensures that critical networks, including OAM, signalling, and data replication, are not cross-connected or sharing the same routes on the Network Functions Virtualization Infrastructure (NFVI) provider side, thereby preventing network congestion.

With "Traffic Segregation Using CNLB," operators can segregate traffic to external feeds and applications more effectively. Previously, all external traffic was routed through the same external network, but now, egress traffic from the OCNADD adapter pods can be directed through non-default networks to third-party applications. This separation is achieved by leveraging cloud-native infrastructure and the load balancing algorithms in OCCNE.

The feature supports the configuration of separate networks, network attachment definitions (NADs), and the Cloud Native Load Balancer (CNLB). These configurations are crucial for enabling cloud native load balancing, facilitating egress traffic separation, and optimizing load distribution within the OCNADD.

Note:

The CNLB feature is only available in OCNADD if OCCNE is installed with CNLB enabled.

For detailed instructions on configuring and utilizing this feature, see the Oracle Communications Cloud Native Environment Installation Guide, which covers CNLB support in OCCNE.

Traffic Segregation using CNLB

In the current release, the Data Director supports traffic segregation only for the following:

  • Egress traffic for the adapter HTTP2 and Synthetic feeds
  • Ingress traffic for the ingress adapter for non-Oracle NFs

The Data Director shall provide the mechanism for external communication between:

  • The two Redundancy Agents in the Two-Site redundancy feature via CNLB external IP support
  • NFs and the Data Director running in separate clusters using external Kafka access via CNLB external IP support
  • Third-party applications and the Data Director running in separate clusters using external Kafka access via CNLB external IP support

Prerequisites for Installing CNLB Supported OCCNE Cluster

The following pre-requisites must be met before CNLB-supported OCCNE cluster installation:

  1. Customer/User must create the required ingress NADs and egress NADs according to the Data Director services and their third-party feed endpoint requirements before CNLB CNE cluster installation.
  2. Customer/User must know the required CNLB IPs (external IPs) and ingress NADs for Data Director services such as the Ingress Adapter, Kafka, and Redundancy Agent.
  3. Based on the ingress traffic segregation requirement for non-Oracle NFs, the required CNLB IPs (external IPs) and ingress NADs need to be configured for the Ingress Adapter in advance in the cnlb.ini file of CNLB.
  4. Customers/Users must know their third-party endpoint traffic segregation requirements in advance, which can be:
    1. Egress NAD per Feed per third-party endpoint: Each Data Director consumer feed will have a separate egress NAD (separate egress network) to segregate egress traffic for its third-party endpoint.
    2. Egress NAD per Feed: Each Data Director consumer feed will have a separate egress NAD that includes all third-party endpoint destination routes. In this case, the Data Director feed uses the same egress network for egress traffic segregation for its third-party endpoints.
    3. Egress NAD per DD: A single egress NAD can be configured that includes all possible third-party destination route information. In this case, a common egress network will be used by all consumer applications.
  5. Customer must create or use ingress NADs for redundancy agent communication.
  6. Customer must create or use ingress NADs for external Kafka communication.

Limitations

  1. In the current release, the CNLB external IPs for the Kafka service work correctly only if the NFs or third-party applications connect from outside the cluster where Data Director is deployed.
    1. If the NFs are deployed in the same cluster as the Data Director, they should use the Kafka service name instead of CNLB external IPs. This connection should be made using the SSL protocol over port 9093. If ACL is enabled, a client ACL using the SSL certificate’s common name as the user should be created; see the Creating Client ACL with CN Name from SSL Client Certificate section.
    2. The third-party consumer applications are always expected to connect to the Kafka service from outside the Data Director cluster. All direct Kafka feeds, such as aggregated, filtered, and correlated, can only be accessed using the Kafka service from outside the cluster for traffic consumption. The third-party applications cannot connect to the Kafka service from inside the same cluster as Data Director.
  2. Upgrade or migration from LBVM to the CNLB-based cluster is not supported; in this case, the only option is to perform a fresh install of the CNLB-based OCCNE cluster.
  3. The CNLB network configuration is only supported at the time of fresh site deployment; no runtime or dynamic CNLB network update is possible.
  4. IPv6 support is not available for the CNLB feature.
  5. External access is only possible for the Ingress adapter, Kafka service, and redundancy agent using the CNLB feature.

For more information, see Enabling or Disabling Traffic Segregation Through CNLB in OCNADD section.