How do session counters work?

Session counters are used to record the current status of the charging activity in a session. When a CDR is written for the session, the session counter data is transferred. The session counter data in the CDR records the final status of the charging when the session ended. The session counter data is used in post processing:

  • to determine any undebited units for the session

  • for statistical purposes, such as reporting on granted free units that are otherwise not recorded

  • for reconciliation of Sentinel with the OCS.

Session counter structure

The session counters' Session State field contains one or more session counters. Each session counter is a tree which records the sum of values of any child counters, unless it has none, in which case it holds its own counter values.

The root of a session counter has the following fields:

Field name Purpose Details
subscriberId

Subscriber id associated with the charging values stored in this counter

bucketName

The name of the counter

cumulativeRequestedUnits

Cumulative requested unit reservations

Sum of Requested-Service-Units in CCR Multiple-Service-CreditControl AVPs associated with this counter.

cumulativeGrantedUnits

Cumulative granted unit reservations

Sum of Granted-Service-Units in CCA Multiple-Service-CreditControl AVPs associated with this counter.

cumulativeSentUsedUnits

Cumulative used units

Sum of Used-Service-Units in CCR Multiple-Service-CreditControl AVPs associated with this counter.

cumulativeCommittedUsedUnits

Cumulative committed used units

Sum of Used-Service-Units in CCR Multiple-Service-CreditControl AVPs associated with this counter which have received a CCA response successfully. Also used for the values reported in DIRECT_DEBIT CCRs.

cumulativeRequestedRefundUnits

Cumulative requested refund units

Sum of Requested-Service-Units in CCR(REFUND) Multiple-Service-CreditControl AVPs.

cumulativeGrantedRefundUnits

Cumulative requested refund units

Sum of Requested-Service-Units in CCR(REFUND) Multiple-Service-CreditControl AVPs associated with this counter which have received a CCA response successfully.

Important The values stored in counters are not always related to Diameter CCR and CCA AVP values. They may also represent the charging activity of promotions which do not use Diameter or the charging activity of a non-Diameter charging protocol.

A session counter has one or more sub-counters which store charging values related to a charging reference, such as a service identifier or unit type (for example, time units, service specific units, octets, and so on).

Field name Purpose
subCounterId

An identifier for the contents of this sub-counter (such as service id or unit type).

cumulativeRequestedUnits

All values as above but associated with the sub-counter identifier.

cumulativeGrantedUnits
cumulativeSentUsedUnits
cumulativeCommittedUsedUnits
cumulativeRequestedRefundUnits
cumulativeGrantedRefundUnits

MediationClient, OCS, promotions counters

All Sentinel session will record charging activity in a session counter with bucketName set to MediationClient. This represents the charging activity from the perspective of the protocol client: SIP, SS7, Diameter, or custom protocol in the case of Sentinel Charge.

The MediationClient session counter shows the overall charging values. Other session counters in the session counter’s structure detail the various charging activities which are accumulated in the MediationClient counter. When there is only an OCS involved, then the OCS and MediationClient values will be identical. If a promotion and an OCS are involved in providing units, then there will be a counter for the promotion and for the OCS.

Examples

Below are examples of:

Successful MOC call

The following session counter shows the charging values at the end of the call. The call in this case was 5s long and had a successful 60s reservation. All units were successfully committed in the OCS. There are two sub-counter levels. The first level is used for the MSCC Service-Identifier. The second level is used for the unit type, in this case CC-Time.

sentinel session counter moc 2001

Successful MOC call with promotion

The following session counter shows the charging values at the end of the call:

  • The call in this case was 75s long and had a successful 60s reservation from the AnytimeOnNet promotions.

  • An update reservation to the promotion was unsuccessful, so the OCS was interrogated.

  • The unit reservation of 60s to the OCS was successful, of which 15s were used and reported to the OCS.

The session counters structure for this session has three counters: AnytimeOnNet, OCS, and MediationClient The view of the IN service is shown in MediationClient. The detail activity, including promotions and OCS interaction, is show in the AnytimeOnNet and OCS counters.

sentinel session counter moc promotions 1001

Unlimited SMS promotion

This session counters structure shows an SMS session which was successfully completed using units from the UnlimitedSMS promotion. For this session, the OCS was not necessary, so no session counter structure is shown.

Note In this session the lower sub-counters have id CCServiceSpecificUnits, which represents the unit type for an SMS session.
sentinel session counter sms promotions 1001

Diameter Ro OCS failure handling and undebited units handling

The session counters structure below is for a Diameter Ro charging session. The initial interrogation of the OCS failed.

The subscriber had some units available in the OCS failure handling bucket which were granted. Using these values from the CDR, the undebited units are identified and the subscriber’s balance correctly debited in post processing.

sentinel session counter diameter ocs failure 3001
Previous page Next page