Rf Control Resource Adaptor Guide

The Rf Control Resource Adaptor (Rf Control RA) is a component that interfaces Rhino TAS applications, with a Charging Data Function (CDF), for offline charging, using the Diameter Rf protocol. It provides applications a full implementation of the "Client accounting state machine" as per RFC 6733. Applications create Accounting Requests and pass them to the Rf Control RA. The Rf Control RA is responsible for delivery of Accounting Requests to the CDF.

This document includes the following topics:

For Rf Control sessions, the resource adaptor will create a new SAS trail and will associate it with the trail on the invoking thread.

When creating a SAS trail, the resource adaptors will raise a SAS marker for trail correlation. They raise a GENERIC_CORRELATOR_MARKER containing the Session-Id AVP.

The Rf Control Resource Adaptor (Rf Control RA) has 2 types of configuration:

Failover between CDF nodes is supported by the Diameter Rf stack. You configure the Rf Control RA by creating realm and peer tables in the Rf Control RA Diameter Configuration appropriate for your deployment. For further information on configuration and diameter stack routing see:

The health of the Rf Control Resource Adaptor entity can be monitored using the Rhino statistics tools. For example, to monitor the statistics from the command line (<entity-name> is the Resource Adaptor entity name):

The statistics collected by the Rf Control Resource Adaptor are:

The following alarms may be raised with a source of OpenCloud <entity-name> <version> (for a Resource Adaptor entity <entity-name>, of version <version>).

The Rf Control Resource Adaptor (Rf Control RA) will connect to the CDF when it is active. An alarm is raised if the Rf Control RA fails to connect to the CDF. There are several possible reasons connecting to the CDF may fail, including:

The alarm is automatically cleared once the failure is resolved, and the Rf Control RA successfully connects to the CDF.

The Rf Control RA uses an SQLite database as a disk buffer when the CDF is not reachable. SQLite is a simple, embedded, SQL database engine ideally suited to be used as an on-disk buffer.

The database name is: buffer-<ra entity>-<rhino node>.db. Example: buffer-rf-control-ra-101.db.

The location of the database is defined by the Rf Control RA Diameter Configuration profile parameter OnDiskBufferDirectoryName (default value is ${rhino.dir.home}/rf-control)

Accounting Request (ACR) messages are stored in the database when the CDF is not reachable.

As a rule of thumb, assume 3kB per ACR (large but reasonable) and 3 ACRs per call (START, INTERIM, STOP). Assuming 500 call attempts per second per Rhino node, the database will grow at a rate of:

If the Rf Control RA fulls the entire disk partition it is buffering to, an alarm of type write-failure or write-thread-failure will be raised (depending on the cause). The write-failure alarm will be cleared when the database is available for writing. The write-thread-failure alarm will require a Rf Control RA restart.

During the write-failure and write-thread-failure condition the Rf Control RA will store ACR records in a memory buffer. If the database or the CDF connection issue is not resolved, the memory queue will eventually become full and the Rf Control RA will start discarding records.

When the CDF becomes available again, the Replay thread will attempt to transmit stored ACR records. The database will automatically re-use the disk space that successfully replayed ACR records had occupied.

The SQLite database supports VACUUMING, which rebuilds the database file, repacking it into a minimal amount of disk space. VACUUMing is only necessary if the disk partition that the database is stored in is too small for normal operation use. For example, the database fits into the partition but the database size is deemed "too large". This procedure is nevertheless attempted automatically after all the records have been replayed by the replay thread, that is the database is nominally empty, since the impact on performance in this case is negligible. However, this attempt may fail if there happens to be a concurrent access to the database by another thread. This means that manual intervention may be necessary if disk space is getting low.

The database has incremental vacuum support enabled, since running an incremental vacuum should have less of a performance impact than a full one if there are a lot of records in the database, but it may be less effective.

An incremental vacuum procedure can be performed as follows:

If this doesn’t produce the desired results, a full VACUUM procedure can be performed as follows:

For more information on VACUUM see SQLite VACUUM.

We recommend that the disk partition is large enough to not require VACUUMing.

If the operator has an independent alarm configured to monitor the disk partition use, then it is possible that a VACUUM may be necessary to reduce the reported disk usage (after a CDF outage and replay completion). Such an alarm should clear once the VACUUM has completed.