1. ECE Implementing Charging
  2. Integrating with External Systems
  3. Generating CDRs for External Systems

18 Generating CDRs for External Systems

You can configure Oracle Communications Elastic Charging Engine (ECE) to generate call detail records (CDRs) for unrated 5G usage events. ECE does not use CDRs for convergent charging, so it does not generate them by default. You might want CDRs for roaming partners, data warehousing, and legacy billing systems.

Caution:

Generating CDRs for unrated 5G events requires a cloud native deployment of ECE and BRM components. The HTTP Gateway and CDR Gateway can be used only on an ECE cloud native system.

Topics in this document:

About Using the HTTP Gateway

By default, HTTP Gateway sends all 5G usage requests to ECE Server for online and offline charging.

You can configure HTTP Gateway to convert some of the usage requests into CDRs based on the charging type by enabling CDR generation. You can then send the CDRs to roaming partners, a data warehousing system, or legacy billing systems for rating.

When CDR generation is enabled, HTTP Gateway routes usage requests to one of the following, depending on your configurations and the charging type:

You specify where to route online charging requests and offline charging requests when you configure the HTTP Gateway. See "Configuring HTTP Gateway for CDR Generation".

About Generating CDRs

You can configure ECE to publish CDRs as files or send them to a Kafka messaging service. In both cases, the CDRs are in JSON format.

ECE generates CDR files in the Charging Function component (CHF) using this process:

  1. The HTTP Gateway sends a request to the CDR Gateway. The requests can be for online charging, offline charging, or both.

  2. The CDR Gateway does the following:

    1. Generates individual CDR records for each request or aggregates multiple requests into a CDR record according to the trigger criteria you specify.

    2. Stores CDR records in the CDR database. You can use either Oracle NoSQL Database or Oracle Database.

  3. The CDR Formatter does the following:

    1. Extracts CDR records from the database and passes them to the CDR Formatter plug-in module for processing. You can use the default plug-in included with ECE or create a custom plug-in.

    2. Purges CDR records from the database after a specified amount of time. You can purge both processed and incomplete CDR records based on your configuration.

  4. The CDR Formatter plug-in module generates CDR files. Depending on your configuration, it stores them on the disk or sends them to the Kafka messaging service.

Figure 18-1 shows the process flow for generating CDRs.

Figure 18-1 CDR Process Flow


Description of Figure 18-1 follows
Description of "Figure 18-1 CDR Process Flow"

For details about the CDR format, see "CHF-CDR Format" in ECE 5G CHF Protocol Implementation Conformance Statement.

About Saving CDR Files to Disk

If you configure CDR Gateway to save JSON-formatted CDR files to disk, it stores the files to the directory you specify using the following file naming format:

  • For ECE 12.0 Patch Set 7 and later:

    ClusterName_StartTimeStamp_EndTimeStamp_SequenceNumber.Extension

    For example: BRM_1654514133000_1654514134000_1.out

  • For ECE 12.0 Patch Set 6 and earlier:
    StartTimeStamp_EndTimeStamp.Extension

    For example: 1654514133000_1654514134000.out

You set the filename extension, the maximum number of CDRs that can be written to a CDR output file, and the directory in which to store CDR files when you configure the CDR Formatter Plug-In. See "Configuring the CDR Formatter Plug-in".

Setting Up ECE to Generate CDRs

To set up ECE to generate CDRs:

  1. Connect your 5G client to HTTP Gateway. See "Connecting ECE to a 5G Client".

  2. Configure HTTP Gateway to route usage requests to the CDR Gateway. See "Configuring HTTP Gateway for CDR Generation".

  3. Configure the CDR Gateway to generate CDRs and store them in the database. See "Configuring the CDR Gateway".

  4. Configure the CDR Formatter to extract unrated CDRs from the database. See "Configuring the CDR Formatter".

  5. Specify the plug-in to use for creating JSON formatted CDR files. See "Configuring the CDR Formatter Plug-in".

Accessing ECE Configuration MBeans

For all configurations, start by accessing the ECE configuration MBeans:

  1. Log on to the driver machine.
  2. Start the ECE charging servers (if they are not started).
  3. Connect to the ECE charging server node enabled for JMX management.

    This is the charging server node set to start CohMgt = true in the ECE_home/config/eceTopology.conf file, where ECE_home is the directory in which ECE is installed.

  4. Start a JMX editor that enables you to edit MBean attributes, such as JConsole.
  5. In the editor's MBean hierarchy, find the ECE configuration MBeans.

Configuring HTTP Gateway for CDR Generation

You can configure HTTP Gateway to send usage requests to the CDR Gateway by enabling CDR generation.

You can also configure HTTP Gateway to route usage requests to ECE Server for rating or the CDR Gateway based on the type of charging request:

  • Offline Charging Requests: To send offline charging requests to ECE Server, set the rateOfflineCDRinRealtime attribute to true. To send them to the CDR Gateway, set the attribute to false.

  • Online Charging Requests: To send online charging requests to ECE Server, set the generateCDRsForOnlineRequests attribute to false. To send them to the CDR Gateway, set the attribute to true.

To configure the HTTP Gateway:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.httpGatewayConfigurations.

  4. Expand Attributes.

  5. Specify values for the fields in Table 18-1.

    Table 18-1 Fields for Configuring CDR Generation

    Name Default Description
    cdrGenerationEnabled "false"

    If set to true, ECE generates CDRs according to your configuration.

    If set to false, ECE uses convergent charging for all charging requests. If set to false, no other settings in this area are relevant.

    cdrGenerationStandaloneMode "false" If set to true, HTTP Gateway doesn't send any requests to ECE, but it still generates CDRs.
    cdrGatewayList "localhost:8084" Specifies one or more servers for the CDR Gateway. Use a comma-separated list for multiple servers.
    cdrGatewayRetry "3" The number of attempts for sending requests to CDR Gateway before giving up.

    rateOfflineCDRinRealtime

    "false"

    If set to true, HTTP Gateway sends offline charging requests to ECE for rating.

    generateCDRsForOnlineRequests

    "true"

    If set to true, HTTP Gateway generates CDRs for all online charging requests.

Configuring the CDR Gateway

You configure the CDR Gateway to connect to your CDR storage database. You can also configure the CDR Gateway to generate either individual CDRs or aggregate multiple CDRs together according to trigger criteria that you specify.

To configure the CDR Gateway:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
  2. Expand the ECE Configuration node.
  3. Expand charging.cdrGatewayConfigurations.
  4. Expand Attributes.
  5. Specify values for the fields in Table 18-2.

    Table 18-2 Fields for Configuring CDR Gateway

    Name Default Description
    name "cdrGateway1"

    The name of this CDR Gateway instance.

    You can specify multiple CDR Gateways when configuring the HTTP Gateway.

    primaryInstanceName

    "cdrGateway1"

    The name of the primary CDR Gateway instance.
    schemaNumber "1"

    The number of the database schema used to store CDRs. Different CDR Gateways can write to different schemas.

    isNoSQLConnection

    "true"

    The type of database used for storing CDRs:

    • true: Oracle NoSQL Database

    • false: Oracle Database

    noSQLConnectionName "@NO_SQL_CONNECTION@"

    The connection name for the NoSQL database. This attribute applies only if you are using Oracle NoSQL Database for storing CDRs.
    connectionName "@ORACLE_PERSISTENCE_CONNECTION_NAME@"

    The connection name of the Oracle database.

    This attribute applies only if you are using Oracle Database for storing CDRs.
    cdrPort "8084"

    The port number for the CDR Gateway server.
    cdrHost "localhost"

    The IP address, host name, or fully qualified domain name for the CDR Gateway server.

    cdrHost and cdrPort are also included in the cdrGatewayList field for the HTTP Gateway.

    individualCdr "false"

    The type of CDR generation:

    • true: ECE generates an individual CDR for each event.

    • false: ECE aggregates requests until a trigger takes effect to write out the partial CDR or terminate the request.

      For more information, see "About Trigger Types".

    cdrServerCorePoolSize

    "32"

    The number of threads in the CDR server pool.

    cdrServerMaxPoolSize

    "256"

    The maximum number of threads allowed in the CDR server pool.

Configuring the CDR Formatter

You can configure the CDR Formatter to do the following:

  • Retrieve completed CDRs from the CDR Store and pass them to a specified plug-in module for processing.

  • Purge completed CDRs from the CDR Store that are older than a specified number of days (configured in retainDuration).

  • Purge orphan CDRs from the CDR Store.

    Orphan CDRs are incomplete CDRs that are older than a specified number of seconds (configured in cdrOrphanRecordCleanupAgeInSec). The CDR Gateway can create orphan CDRs if your ECE system goes down due to maintenance or failure.

To configure the CDR Formatter:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
  2. Expand the ECE Configuration node.
  3. Expand cdrFormatters.
  4. Expand Attributes.
  5. Specify values for the fields in Table 18-3.

    Table 18-3 Fields for Configuring the CDR Formatter

    Name Default Description
    name "cdrFormatter1"

    The name of a CDR Formatter instance.

    You should name CDR Formatter instances consistently and uniquely (for example, cdrFormatter1, cdrFormatter2, and so on).

    primaryInstanceName

    "cdrFormatter1"

    The name of the primary CDR Formatter instance.
    schemaNumber "1"

    The number of the database schema for processing CDRs.

    isNoSQLConnection

    "true"

    The type of database used for storing CDRs:

    • true: Oracle NoSQL Database
    • false: Oracle Database
    noSQLConnectionName "@NO_SQL_CONNECTION@"

    The connection name for the NoSQL database. This attribute applies only if you are using Oracle NoSQL Database for storing CDRs.

    This is the same connection you use for CDR Gateway.
    connectionName "@ORACLE_PERSISTENCE_CONNECTION_NAME@"

    The connection name of the Oracle database. This attribute applies only if you are using Oracle Database for storing CDRs.

    This is the same connection you use for CDR Gateway.
    threadPoolSize "6"

    The number of threads used by the CDR Formatter instance to process a set of CDRs for each time range defined by checkPointInterval.

    Valid values are greater than zero and up to any number the system resources allow. Tune this value to the expected workload in the deployed environment.
    retainDuration "0"

    The duration in seconds that processed CDRs are retained in the CDR Store before they can be purged.

    The default is 0, which means that CDRs are purged immediately after being processed.

    ripeDuration "60"

    The duration in seconds that CDRs must be stored in the CDR Store before the CDR Formatter can read them.

    Delaying the processing of CDRs up to the ripeDuration time allows time for resolving any duplicate CDRs that may have been persisted to the CDR Store.

    checkPointInterval "6"

    The time interval in seconds that the CDR Formatter instance waits before reading a batch of CDR information.

    This value must be:

    • Less than or equal to the value of ripeDuration
    • Evenly divisible by the number of threads configured for threadPoolSize

    The CDR Formatter doesn't read CDR information when the time interval is less than the ripeDuration interval.

    pluginPath "ece-cdrformatter.jar"

    The path to the JAR library that contains the reader plug-in implementation.

    A custom plug-in has a modified path to the JAR library.
    pluginType

    "oracle.communication.brm.charging.cdr.formatterplugin.internal.SampleCdrFormatterCustomPlugin"

    		 The type of plug-in used to format CDRs.
    pluginName "cdrFormatterPlugin1"

    The class name with the package path for the formatter plug-in object to be called by the CDR formatter.

    You can write a custom plug-in and specify it here.
    noSQLBatchSize "25" The number of CDR records to be read from the NoSQL Database in a single read operation.

    cdrStoreFetchSize

    "2500"

    The number of CDR records to retrieve from the CDR Store and hold in memory at a time.

    cdrOrphanRecordCleanupAgeInSec

    "200"

    The amount of time, in seconds, at which an incomplete record in the CDR Store is considered an orphan.

    The CDR Formatter purges orphan records from the CDR Store that are this age or older.

    cdrOrphanRecordCleanupSleepIntervalInSec

    "200"

    The sleep interval, in seconds, between each call to purge orphan CDRs from the CDR Store.

Configuring the CDR Formatter Plug-in

You can configure the CDR Formatter plug-in to create JSON-formatted CDR files and then store them in your file system or send them to your Kafka messaging service.

To configure the CDR Formatter plug-in:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
  2. Expand the ECE Configuration node.
  3. Expand cdrFormatterPlugins.
  4. Expand Attributes.
  5. Specify values for the fields in Table 18-4.

    Table 18-4 Fields for Configuring the CDR Formatter Plug-in

    Name Default Description
    name "cdrFormatterPlugin1" Name of the formatting plug-in. cdrFormatterPlugin1 is the default plug-in that comes with ECE, but you can also specify a custom plug-in.
    tempDirectoryPath "/tmp/tmp" Path for CDR files being formatted.
    doneDirectoryPath "/tmp/done" Path for formatted CDR files.
    doneFileExtension ".out" Extension for CDR files.
    enableKafkaIntegration "false"

    Whether or not to send records to Kafka. Because ECE uses Kafka for notifications, you set it up during installation and configure the HTTP Gateway to use it.

    See "Creating Kafka Topics for ECE" in ECE Installation Guide and "Connecting ECE to Kafka Topics".

    enableDiskPersistence "true" Whether or not to save records as JSON files in the path specified for doneDirectoryPath.

    maxCdrCount

    "20000"

    The maximum number of CDRs that can be written to a CDR output file.

About Trigger Types

If you configured ECE to aggregate events in the same CDR, triggers determine when a CDR remains open and when it closes. See:

Triggers for Convergent Charging Events

When an event meets any of the trigger conditions in Table 18-5, the event is added to the open CDR. The CDR remains open with the same sequence number.

Table 18-5 Triggers for Adding to an Open CDR

Category Trigger
Change of Charging Conditions
  • QoS change
  • User Location change
  • Serving Node change
  • Change of UE presence in Presence Reporting Area(s)
  • Change of 3GPP PS Data off Status
  • Handover cancel
  • Handover start
Limit per Rating Group
  • Expiry of data time limit per RG
  • Expiry of data volume limit per RG
  • Expiry of data event limit per RG
Quota Management Triggers
  • Time threshold reached
  • Volume threshold reached
  • Unit threshold reached
  • Time quota exhausted
  • Volume quota exhausted
  • Unit quota exhausted
  • Expiry of quota validity time
  • Re-authorization request by CHF

When an event meets any of the trigger conditions in Table 18-6, it is added to the open CDR and then the CDR is closed.

Table 18-6 Triggers for Closing a CDR

Category Trigger
Change of Charging Conditions
  • UE time zone change
  • PLMN change
  • RAT type change
  • DNN-AMBR change
  • Removal of UPF
  • Management intervention
  • Addition of access
Limit per PDU Session
  • Expiry of data time limit per PDU session
  • Expiry of data volume limit per PDU session
  • Expiry of data event limit per PDU session
  • Expiry of limit of number of charging condition changes

Note:

If the request type is TERMINATE, the CDR is closed regardless of the trigger type.

Triggers for Roaming Events

When a roaming event meets any of the trigger conditions in Table 18-7, it is added to the open CDR.

Table 18-7 Triggers for Adding to an Open CDR (Roaming Event)

Category Trigger
Change of Charging conditions
  • QoS change
  • User Location change
  • Serving Node change
  • Change of UE presence in Presence Reporting Area(s)
  • Change of 3GPP PS Data off Status
Limit per QoS Flow
  • Expiry of data time limit per QoS Flow
  • Expiry of data volume limit per QoS Flow
Others
  • Expiry of data time limit per QoS Flow
  • Expiry of data volume limit per QoS Flow

When a roaming event meets any of the trigger conditions in Table 18-8, it is added to the open CDR, and the CDR is then closed.

Table 18-8 Triggers for Closing a CDR (Roaming Event)

Category Trigger
Change of Charging conditions
  • UE time zone change
  • PLMN change
  • RAT type change
  • DNN-AMBR change
  • Removal of UPF
  • Management intervention
Limit per PDU session
  • Expiry of data time limit per PDU session
  • Expiry of data volume limit per PDU session
  • Expiry of data event limit per PDU session
  • Expiry of limit of number of charging condition changes