12 Correlation Feature Configuration and xDR Format

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

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

12.2 XDR Content

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

Mandatory xDR Content

Table 12-1 Mandatory xDR Content

Field Data Type Presence Description
version String M

Version number of xDR content.

Version is 1.0.0 in release 23.3.0 with SUDR support.

Version is 2.0.0 in release 23.4.0 with TDR and new attributes support.
configurationName String M

Correlation configuration name.

This can be used by 3rd party consumers to distinguish between multiple configuration xDR
beginTime String(UTC time) M

Date and time in milliseconds of the first message of the xDR.

Example: "2023-01-23T07:03:36.311Z"

endTime String(UTC time) M

Date and time of the last event in the transaction (last message or timeout).

Example: "2023-01-23T07:03:39.311Z"

xdrStatus Enum M

xDR status of the correlated transaction.

Value: SUDR, COMPLETE, TIMER_EXPIRY, NOT_MATCHED

Optional xDR Content

Note:

The mandatory fields will always be present in xDRs and optional fields will be present based on their availability in the message.
Field Data Type Presence Description
totalPduCount Integer O

The total number of messages are present in the transaction.

It must be selected in xDR when correlation mode is not set to SUDR.

    • An xDR is generated with a request message and response message then total-pdu-count is set to 2 or the total no. of message of transaction.
    • An xDR is generated with either only a request message or a response message then total-pdu-count is set to 1.
totalLength Integer O

Total sum of the message size of all the messages present in the transaction.

It will be in bytes.
transactionId String O

The unique identifier of the transaction.

It must be selected in xDR when correlation mode is not set to SUDR.
transactionTime String O

Duration of the complete transaction(endTime-beginTime ). In case of a timeout the transaction time will be calculated between transaction begin time and the timeout event.

It must be selected in xDR when correlation mode is not set to SUDR.

It will be in milliseconds.

Example: 1000

userAgent String O

The User-Agent identifies which equipment made the Request.

It is taken from the header list and also populated from the first occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: UDM-26740918-e9cd-0205-aada-71a76214d33c udm12.oracle.com
path String O

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

It is taken from the header list and also populated from the first occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

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

supi String O

It contains either an IMSI or an NAI.

Pattern: '^(imsi-[0-9]{5,15}|nai-.+|.+)$'

It is populated from the first occurrence in the message(header-list/5g-sbi-message).
gpsi String O

It contains either an External ID or an MSISDN.

Pattern: '^(msisdn-[0-9]{5,15}|extid-.+@.+|.+)$'

It is populated from the first occurrence in the message(header-list/5g-sbi-message).
pei String O

Permanent equipment identifier and it contains an IMEI or IMEISV.

Pattern: '^(imei-[0-9]{15}|imeisv-[0-9]{16}|.+)$'

It is populated from the first occurrence in the message(header-list/5g-sbi-message).
methodType Enum O

It represents the type of request for the transaction.

Value: POST, PUT, DELETE, PATCH

It is taken from the header list and also populated from the first occurrence RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.
statusCode String O

It represents the status type of response for a request in a transaction.

Value: 2XX, 3XX, 4XX, 5XX

It is taken from the header list and also populated from the last occurrence of TxResponse, or RxResponse in case NRF transactions are TxRequest and RxResponse.
feedSourceNfType String O

The type of Oracle NF that copies 5G messages to DD.

It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

In 23.3.0: The attribute name was producerNfType.

Example: SCP, SEPP, NRF

feedSourceNfFqdn String O

The FQDN of Oracle NF copies messages to DD for the transaction.

It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: sepp1.5gc.mnc001.mcc101.3gppnetwork.org

feedSourceNfId UUID O

The ID of Oracle NF which copies messages to DD for the transaction.

It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: 23f32960-7443-1122-90d6-0242ac120003

consumerId UUID O

The unique identifier of the consumer sends the request message and receives the response message.

It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: 23f32-7443-1122-90d6-0242ac120003

producerId UUID O

The unique identifier of the producer receives the request message and sends a response message to the consumer.

It is taken from the header list and also populated from the last occurrence of TxRequest.

Example: 32960-7443-1122-90d6-0242ac120003

Note: When feedSourceNfType is SEPP or NRF and the data stream point is EGW, it will not be present in the metadata list.

consumerFqdn String O

The fqdn address of the consumer who sends the request message and receives the response message.

It is taken from the header list and also populated from the last occurrence of RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: AMF.5g.oracle.com

consumerNfType String O

The type of consumer that sends the request message and receives the response message.

It is populated from the header list of RxRequest User-Agent, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: AMF, NRF

Only the NF name extracted from the user-agent header.

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

consumerNfType: "UDM"
producerFqdn String O

The fqdn address of the producer receives the request message and sends a response message to the consumer.

It is taken from the header list and also populated from the last occurrence of TxRequest.

Example: UDM.5g.oracle.com

contentType String O

It represents the type of message payload (data is DATA frames) that is exchanged in a transaction.

It is taken from the header list and also populated from the first occurrence RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

Example: application/json

ingressAuthority String O

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

It is taken from the header list and also populated from the last occurrence of RxRequest.

Example: 172.19.100.5:9443

egressAuthority String O

Node Next hop's local IP/FQDN on the egress side

It is taken from the header list and also populated from the last occurrence of TxRequest.

Example: 33.19.10.17:443

consumerVia String O

It contains a branch unique in space and time identifying the transaction with the next hop.

It is taken from the header list and also populated from the first occurrence RxRequest, or TxRequest in case NRF transactions are TxRequest and RxResponse.

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

producerVia String O

It contains a branch unique in space and time identifying the transaction with the next hop.

It is taken from the header list and also populated from the first occurrence of RxResponse.

Example: sepp02.5gc.mnc002.mcc276.3gppnetwork.org

consumerPlmn String O

Public Land Mobile Networkis a mobile operator's cellular network in a specific country. Each PLMN has a unique PLMN code that combines an MCC (Mobile Country Code) and the operators' MNC (Mobile Network Code)

It is taken from 5g-sbi-data and also populated from the last occurrence of RxRequest.

Example: consumerPlmn: "208-001"

208: MCC

001: MNC
producerPlmn String O

Public Land Mobile Networkis a mobile operator's cellular network in a specific country. Each PLMN has a unique PLMN code that combines an MCC (Mobile Country Code) and the operators' MNC (Mobile Network Code)

It is taken from 5g-sbi-data and also populated from the last occurrence of TxRequest.

Example: consumerPlmn: "276-002"

276: MCC

002: MNC
registrationTime String O

Registration time of NF instance with NRF.

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.
ueId String O

It represents the subscription identifier, pattern: "(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-.+|.+)"

It is populated from the first occurrence in the message(header-list/5g-sbi-message).

Example: imsi-208014489186000

pduSessionId Integer O

Unsigned integer identifying a PDU session.

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.

Example: 1

smfInstanceId String O

Unique identifier for SMF instance

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.

Example: 8e81-4010-a4a0-30324ce870b2

smfSetId String O

Identifier of SMF set id.

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.
snssai String O

The set of Network Slice Selection Assistance Information.

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.

Example:

"snssai": "{\"sst\":1,\"sd\":\"000001\"}"
dnn String O

Data Network Name, It is used to identify and route traffic to a specific network slice.

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.
pcfInstanceId String O

Unique identifier for PCF instance

It is taken from 5g-sbi-data and also populated from the first occurrence in the message.

Example: 9981-4010-a4a0-30324ce870b2

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

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