The Charging Session Binding Repository (Charging SBR) provides a high availability (HA) distributed database for the DSR Charging Proxy Application (CPA). The Charging SBR stores information that the CPA uses for consistently routing Diameter requests from instances of Charging Trigger Function (CTF) to instances of Charging Data Function (CDF). For any given session, the CPA stores in the Charging SBR the identity of the CDF that the CPA has chosen to service the Diameter requests for that session, or a session binding. When the CPA routes subsequent Diameter requests for a session, it queries the Charging SBR for the session binding to determine the identity of the serving CDF.
In the basic form, the Charging SBR consists of a Session Binding Database (SBDB) to store session binding data, and a server process to handle requests from the CPA to manipulate session bindings. For scalability, Charging SBR blades are divided into active/standby pairs. The SBDB is logically partitioned across each of the active/standby pairs. Each logical partition corresponds with a Charging SBR subresource. The CPA then submits the request to the selected Charging SBR subresource.
Each session binding record is stored with a timestamp that indicates when the record was last modified. Periodically, stale session binding records are deleted from the SBDB by an internal audit mechanism. The time at which the audit runs and the age at which a binding is considered stale are configurable. The cleanup audit helps to reduce the risk that stale session bindings could prevent the creation of new session bindings. Decreased database performance due to an unnecessarily large SBDB is also remedied by cleaning up stale session binding data.
Congestion in the Charging SBR is determined independently by each partition based on its queue depth. Congestion notifications are included with each Charging SBR response message. The Charging SBR will also monitor the current service time of its request queues. This information is provided with the congestion data included in the Charging SBR response messages. The CPA then judges whether the time for Charging SBR to process a request meets its needs.
If the Charging SBR becomes overloaded or congested, the Charging SBR will shed load in a predictable way in order to control the overload state. The load shedding strategy progressively increases the type of operation shed. Each higher level of congestion adds a new operation to be shed. At 85% congestion, create operations are shed. At 90% congestion, create and update operations are shed. At 95% congestion, read, create and update operations are shed. At 100% congestion, read, create, update and delete operations are shed. As the overload condition lessens, those levels are reversed as the system returns to normal operations.