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 Requested-Service-Units in CCR Multiple-Service-CreditControl AVPs associated with this counter.

cumulativeGranted

Cumulative granted unit reservations

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

cumulativeSentUsed

Cumulative used units

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

cumulativeCommittedUsed

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.

cumulativeRequestedRefund

Cumulative requested refund units

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

cumulativeGrantedRefund

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 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.

Default address name values

The following default address name values are used in the system. Other values may be used as required by the feature developer.

Cc-Total-Octets
Cc-Service-Specific-Units
Cc-Output-Octets
Cc-Input-Octets
Cc-Money
Cc-Time
Cc-Unit-Type
Rating-Group
Service-Id
Subscriber-Id

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
Previous page Next page