Overview
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.
The Rf Control RA provides a simple API allowing clients to create and deliver Rf requests to the CDF. The message is persisted either in the CDF or in the file system (in case the CDF is not reachable). The Rf Control RA can connect to a secondary CDF in case the primary CDF is not reachable.
The Rf Control RA provides Rhino TAS applications with a full implementation of the "Client accounting state machine" as per RFC 6733. It is responsible for:
-
management of I/O and communications between the SLEE and the CDF, including both diameter peer failure management, and primary/secondary CDF management
-
persistence of Account Requests (ACR) when there are communication issues
-
management of persistent buffers, including buffer replay
A client application only needs to create and provide Accounting Request (ACR) messages. The Rf Control RA performs all other client functions.
The health of an Rf Control RA entity is monitored by inspecting the statistics the Rf Control RA entity generates and by responding to alarms the Rf Control RA entity raises. See Monitoring the Rf Control Resource Adaptor for more information on the statistics collected and the alarms raised.
|
You can define your own threshold based alarms that are a function of the statistics the Rf Control Resource Adaptor collects. See Threshold Alarms in the Rhino TAS Admin Guide for more information about defining threshold based alarms. |
Major components
The following diagram presents the major components inside the Rf Control RA.
When an application (client) requests that an ACR should be sent to the CDF, the Rf Control RA attempts to persist the message either in the CDF or in the local disk buffer (in case the CDF is not reachable). The local disk buffer is implemented as an SQLite database.
|
|
SQLite is a simple, embedded, SQL database engine ideally suited to be used as an on-disk buffer. For more information on SQLite see www.sqlite.org |
The RA will continually try to send locally persisted messages to the CDF and and will only delete locally persisted messages upon successful delivery to the CDF.
The Rf Control RA uses the GRANT_AND_LOSE policy as defined in the section 8.2 from RFC6733.
This means that if the CDF is unavailable and buffers are full it will discard ACR requests and service will still be granted.
The Rf Control RA raises alarms in case of connectivity issues to the CDF or buffer related issues. For more information on Statistics and Alarms see Monitoring the Resource Adaptor.
The rest of this page discusses each of the components in turn:
Diameter Rf Protocol stack
The Diameter Rf protocol stack is responsible for communication with the CDF using the Rf protocol as defined in 3GPP TS 32.299. It uses the Opencloud Diameter protocol stack that implements the base Diameter specification according to RFC 6733.
The Rf Control RA can connect to a secondary CDF in case the primary CDF is not reachable. When the Rf Control RA identifies the major CDF is not available it will try to send messages to the secondary CDF. If there are no available CDF the Rf Control RA will raise an alarm. Meanwhile the Rf Control RA will keep checking if the primary CDF is again available and if the CDF is reachable it will route the traffic towards it.
The failover mechanism is handled in the diameter stack. For more information on OpenCloud Diameter Rf see About the Diameter Resource Adaptors
For further information on configuration and diameter stack routing, see Diameter RA Request Routing Configuration.
Request Handler
The Request Handler is invoked by the client application. It is provided Accounting Request (ACR) messages via the Rf Control RA’s API.
If a diameter peer connection is available the request handler attempts to send requests to the CDF. If the request handler is unable to send a request, it writes the request to the memory buffer (assuming space is available in the memory buffer).
If an ACR is unable to be acknowledged by the CDF, for example due to lack of a diameter peer connection (or a timeout awaiting an ACA, or a non-success response) the ACR is placed into the memory buffer. If placing the ACR in the memory buffer would result in the memory buffer overflowing, the ACR is discarded and an alarm is raised.
Once a message is buffered it is then the responsibility of the replay process.
Replay process
The replay process is implemented by four major components:
-
a memory buffer
-
a disk buffer (SQLite database)
-
a persist thread
-
a replay thread
Requests become the responsibility of the Replay process as soon as they are buffered.
The persist thread runs in a cycle of sleeping and waking. When awake it checks for content in the memory buffer. It wakes whenever new content is placed into the memory buffer. The persist thread attempts to:
-
read records from the memory buffer
-
write those records to the disk buffer, and if successful …
-
… remove those records from the memory buffer
Records are only removed from the memory buffer after they have been successfully persisted to the disk buffer. If an attempt to write records to the disk buffer fails for any reason the persist thread raises an alarm.
The replay thread runs in a cycle of sleeping and waking. When awake, it checks for a peer connection to the CDF, and checks if there is any content in the disk buffer. If there is no connection to the CDF, or no content in the disk buffer it returns to sleep. If there is a connection to the CDF, and records in the disk buffer, the replay thread:
-
reads content from the disk buffer,
-
attempts to send it to the CDF
-
upon receipt of a positive acknowledgement from the CDF, removes the records it sent to the CDF from the disk buffer
When the replay thread receives a "temporary failure" (as per RFC 6733), it goes to sleep. If the replay thread receives a "permanent failure" (as per RFC 6733) it logs a message, and deletes the record from the disk buffer.
The memory buffer size is configurable. The disk buffer size is limited by the size of the disk partition where the buffer is located. Alarms are raised if there are any issues writing messages to the memory or disk buffers.
