Session counters are charging activity counters stored in session state.
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. |
|
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.
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
75slong and had a successful60sreservation from theAnytimeOnNetpromotions. -
An update reservation to the promotion was unsuccessful, so the OCS was interrogated.
-
The unit reservation of
60sto the OCS was successful, of which15swere 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.
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.
|
In this session the lower sub-counters have id CCServiceSpecificUnits, which represents the unit type for an SMS session.
|
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.
