Session counters are session and charging activity counters stored in session state. For SIP sessions, "new" session counters replace the original session counters (which are still used with SS7 and Diameter front ends).
What are session counters?
Session counters record the current status of the charging activity in a session. The CDR written for a session includes session counter data that records the final status of the charging when the session ended.
This data may be used in post-processing, for:
-
determining any undebited units for the session
-
statistical purposes, such as reporting on granted free units that are otherwise not recorded
-
reconciliation of Sentinel with the OCS
-
analysis of any issues encountered during Sentinel operations.
Session counter structure
Session counters are stored in a ChargingInstance
which is accessed from the ChargingManager
. Each charging instance
contains one or more session counters. A session counter has an address that consists of a set of name/value pairs and
is unique for the charging instance.
The ChargingManager
is accessed via the SentinelSipMultiLegFeatureEndpoint
. For example:
ChargingInstance chargingInstance = getCaller().getChargingManager()
.getChargingInstance(B2BUAChargingFeatureUtil.DEFAULT_ECUR_CHARGING_INSTANCE);
SessionCounters sessionCounters = chargingInstance.getSessionCounters();
Each session counter has the following fields:
Field name | Purpose | Details |
---|---|---|
Counter Addressing |
||
address |
Counter addressing |
Set of name/value pairs uniquely identifying this session counter within a charging instance. |
Session Time and Duration |
||
startTime |
Session start time |
The start time is recorded when the session starts consuming units. For instance, when the session is established. Milliseconds since the epoch (January 1, 1970, 00:00:00 GMT). |
endTime |
Session end time |
The end time is recorded when the session ceases consuming units. For instance, when the session being charged is terminated. Milliseconds since the epoch (January 1, 1970, 00:00:00 GMT). |
cumulativeSuspendedDuration |
Cumulative suspended duration |
Cumulative duration of all periods where charging on the session was suspended in milliseconds. |
grantedUnitValidityExpiry |
Unit validity |
Expiry time for granted units in milliseconds since the epoch (January 1, 1970, 00:00:00 GMT). |
Unit Counters |
||
reportedUsed |
Units reported as used to be sent in the next CCR |
|
pendingRequested |
Units to be requested in the next CCR |
|
cumulativeRequested |
Cumulative requested unit reservations |
Sum of |
cumulativeGranted |
Cumulative granted unit reservations |
Sum of |
cumulativeSentUsed |
Cumulative used units |
Sum of |
cumulativeCommittedUsed |
Cumulative committed used units |
Sum of |
cumulativeRequestedRefund |
Cumulative requested refund units |
Sum of |
cumulativeGrantedRefund |
Cumulative requested refund units |
Sum of |
The values stored in counters are not strictly related to Diameter CCR and CCA AVP values but may be used for other purposes. For instance, session counter fields may record charging activity of promotions which do not use Diameter or the charging activity of a non-Diameter charging protocol. |
The Session Time
, Duration
, and Unit Counters
fields are maintained by Sentinel system features. Where necessary, user
features may update the reportedUsed
and pendingRequested
fields for counters created by system
features. Session counters added by user features may have all fields updated by the user features as required.
Access to session counters is via a SessionCounters
interface:
Function | Description |
---|---|
getAddresses |
Get a list of the addresses of all session counters. |
add |
Add a new session counter. |
get |
Get a session counter for an address. |
getSessionCounters |
Get all session counters. |
getSessionCountersByAddressSubset |
Get all session counters which have addresses which are a subset of the requested address. |
getAggregateSessionCounter |
Get a session counter which contains the aggregated values of all session counters which have addresses that are supersets of the requested address. |
Counter update algorithm pseudo code
Here is the counter update algorithm pseudo code, which updates counters for granted units.
Create a list of session counters which have pendingRequested units
Create a list MSCCs with Granted-Service-Units from the CCA
// Handle the common case where there is a single MSCC/GSU and single session counter expecting granted units
IF there is one and only one MSCC
AND one session counter awaiting granted units
AND MSCC GSU unit type is an address key of session counter THEN
Perform GSU updates to the session counter using values from MSCC
RETURN
ENDIF
// Exact matching cases
FOREACH MSCC DO
Create a session counter address for the MSCC based on configured ordered list of AVPs to consider (e.g. [Unit-Type, Service-Id, Rating-Group, Custom-Attribute]
Get session counter from charging instance using session counter address calculated from the MSCC
IF a session counter exists for the MSCC address THEN
Perform GSU updates to the session counter using values from MSCC
Mark MSCC processed
CONTINUE
ENDIF
DONE
// Best effort matching
FOREACH unmatched MSCC DO
Create a session counter address from the MSCC using the configured ordered list of AVPs to
consider (e.g. [Service-Id, Rating-Group, Unit-Type, Custom-Attribute])
Create a list of addresses based on the configured ordered list of AVPs with first address
including all then removing the last AVP until only first address left i.e.
[[Unit-Type, Service-Id, Rating-Group, Custom-Attribute],
[Unit-Type, Service-Id, Rating-Group],
[Unit-Type, Service-Id],
[Unit-Type]]
FOREACH address DO
Get matching session counters
IF there is a matching session counter THEN
Perform GSU updates to the first session counter
Mark MSCC processed
CONTINUE
ENDIF
DONE
DONE
// Record values from any unmatched MSCCs
FOREACH unmatched MSCC DO
Create a new session counter using the full MSCC session counter address if it does not already exist.
Perform GSU updates to the session counter using values from MSCC. Surplus units for an existing
counter will be applied to the counter at this point.
DONE
Updates for sent used units on successfully sending a CCR-U or CCR-T to the OCS:
IF CCR-U or CCR-T with USU sent THEN
Update cummulativeSentUsed for the counter matching the MSCC
ENDIF
Updates for committed used units on receiving a CCA-U or CCR-T from the OCS:
Update cummulativeCommittedUsed values for all USU sent in the CCR
Session counter address mappers
The SipRequestToSessionCounterAddress
mapper creates the default session counter address for SIP sessions.
The CCAToSessionCounterList
mapper creates a list of GSU counters which are processed by the counter
update algorithm. The priority order of the address name/value pairs is based on the order in which the name/value pairs
are added when creating the address.
Below are three examples:
SIP call with session charging with unit reservation
The following session counter shows the charging values at the end of the SIP call. The call has a successful 60s reservation and is 5s long . All units are successfully committed in the OCS.
Point in call flow | Pending Requested | Reported Used | Requested | Granted | Sent Used | Committed Used |
---|---|---|---|---|---|---|
1 CCR-I |
||||||
1.1 new charging instance |
60000 |
0 |
0 |
0 |
0 |
0 |
1.2 CCR-I sent |
60000 |
0 |
60000 |
0 |
0 |
0 |
1.3 CCA-I received |
0 |
0 |
60000 |
60000 |
0 |
0 |
2 CCR-U |
||||||
2.1 Charging Timer Expiry |
60000 |
60000 |
60000 |
60000 |
0 |
0 |
2.2 CCR-U sent |
60000 |
0 |
120000 |
60000 |
60000 |
0 |
2.3 CCA-U received |
0 |
0 |
120000 |
120000 |
60000 |
60000 |
3 CCR-T |
||||||
3.1 Party hangs up |
0 |
30000 |
120000 |
120000 |
60000 |
60000 |
3.2 CCR-T sent |
0 |
0 |
120000 |
120000 |
90000 |
60000 |
3.3 CCA-T received |
0 |
0 |
120000 |
120000 |
90000 |
90000 |
Final counter state:
address: {"Subscriber-Id":"tel:34600000002",
"Cc-Unit-Type":"Cc-Time",
"Service-Id":"1"}
reportedUsed: 0
pendingRequested: 0
cumulativeRequested: 120000
cumulativeGranted: 120000
cumulativeSendUsed: 90000
cumulativeCommittedUsed: 90000
cumulativeRequestedRefund: 0
cumulativeGrantedRefund: 0
SIP event charging with unit reservation
The following session counter shows the charging values at the end of the SIP event charging session.
The session has a successful 1
unit reservation, and 1
unit is used. All units are successfully committed in the OCS.
address: {"Subscriber-Id":"tel:34600000002",
"Cc-Unit-Type":"Cc-Service-Specific-Units",
"Service-Id":"1"}
reportedUsed: 0
pendingRequested: 0
cumulativeRequested: 1
cumulativeGranted: 1
cumulativeSendUsed: 1
cumulativeCommittedUsed: 1
cumulativeRequestedRefund: 0
cumulativeGrantedRefund: 0
SIP immediate event charging with refund
The following session counter shows the charging values at the end of the SIP event charging session.
The session has a successful 1
unit reservation, and 1
unit is used. All units are successfully committed in the OCS.
address: {"Subscriber-Id":"tel:34600000002",
"Cc-Unit-Type":"Cc-Service-Specific-Units",
"Service-Id":"1"}
reportedUsed: 0
pendingRequested: 0
cumulativeRequested: 1
cumulativeGranted: 1
cumulativeSendUsed: 0
cumulativeCommittedUsed: 0
cumulativeRequestedRefund: 1
cumulativeGrantedRefund: 1