OpenCloud’s Sentinel framework enables online charging over Diameter Ro, Diameter Rf and CAP.
Online and Offline charging is a key part of Voice over LTE, and is particularly relevant for the MMTEL-AS.
Charging instance model
The following image shows the three key types of charging instances. Each is a Sentinel VoLTE B2BUA.
The diagram shows the three key concepts:
-
There are Originating, Terminating, and Forwarding MMTEL instances.
-
The S-CSCF “re-targets” a session if it is performing terminating processing, and the destination is altered. This means iFC is re-evaluated.
-
The History-Info header communicates the fact that the Session has been forwarded. The MMTEL-AS inserts (if not present) or adds-to (if already present) the History-Info header, when it re-targets the INVITE to a changed destination.
Forwarded Sessions may be forwarded, and then forwarded, and so on, infinitely. To stop infinite forwarding, the History-Info header is used.
MMTEL’s CDIV Service (a feature in Sentinel VoLTE) is responsible for stopping infinite forwarding.
Charging within the instance model
Let us assume that Online Charging is used for every session:
-
When you make a call, Online Charging is applied (to charge you for making the call).
-
When you receive a call, Online Charging is applied (to charge you to receive a call — this is typical when you roam to another country).
Therefore, each Instance is creating Online Charging requests. So for a session that is forwarded once, and only once, and answered, the OCS will see four sessions:
-
One Originating for A→B (charging the A party for a call to B)
-
One Terminating for A→B (charging the B party for a call from A)
-
One Originating_CDIV (or Forwarding) for B→C (charging the B party for a call to C)
-
One Terminating for B→C (charging the C party for a call from B)
In the Terminating case — typically if the B party is not roaming — then the B party is often not charged.
In order to disable Online Charging for the B-party’s Terminating Instance (for example, when not roaming), you can:
-
return the Online Charging System “credit control not applicable”, or
-
disable the Sentinel Session Plan Online Charging (in the terminating and not-roaming case) or
-
both of the above approaches.
All instances within a network can be tied to the same “real world session” through the IMS Charging Identifier (ICID).
SDP and charging
Under the SIP protocol, media streams may be added and removed, as well as having their codecs changed.
When codecs change, Sentinel may consult its SDP codec configuration to determine if the change was a “meaningful” change from a charging perspective.
-
If a change is deemed meaningful, then Sentinel will perform client initiated re-authorization towards the Online Charging System.
-
If a change is not meaningful, then the current credit reservation remains.
Below is a screen showing Sentinel VoLTE’s default codec configuration:
Codecs in the same equivalence class are treated as “equivalent” from a charging perspective; so changes between codecs in the same class do not cause client-initiated re-authorization.
The table in the image above can be found by navigating through REM to Management ▶ Profiles and scrolling to select “SdpMediaCodecProfileTable”. This table can be edited, and new codecs and equivalence classes introduced.
|
For more about Sentinel and its various capabilities, including charging, see Sentinel Overview and Concepts. |
Charging and Sessions Terminating in WiFi Networks
Sentinel VoLTE has support for allowing sessions to terminate in WiFi networks (Voice over WiFi). When a session is answered,
the Terminating Access Domain Selection (T-ADS) Features
on the SCC AS will analyse the response to determine the type of network that the call is terminating in. Once the network
type has been determined, the T-ADS features will attach a proprietary header to the response before forwarding it
upstream. This header is called the OC-Terminating-Domain Header,
and when a session is answered over a WiFi network, the header will be given the value PS=WLAN.
When Sentinel VoLTE is configured to use online charging this header will be consumed at the MMTel AS serving the terminating user.
A feature on the MMTel AS called MMTelWifiChargingFinalisation
will read the header and, if the value matches PS=WLAN, the feature will issue an instruction to any active online charging instances to
finalise charging for the terminating user, before stripping the header from the upstream forwarded response. When Sentinel
VoLTE is not configured to use online charging, the header will not be stripped by the MMTel AS. This allows it to be
read by upstream charging functions.
The IM-SSF contains support for the OC-Terminating-Domain header.
It terminates the IN dialog towards the Prepaid SCP if it is processing a terminating session, and the terminating 2xx response to the INVITE contains the OC-Terminating-Domain header with value PS=WLAN.
In this case it strips the header before forwarding the 2xx response upstream.
Charging over Diameter Rf interface
The Rf Control Resource Adaptor allows VoLTE to persist offline charging information in the Charging Data Function (CDF). The principle is the same as writing a CDR, but instead of storing the information in a local disk, the Call Detail Records are sent via Diameter Rf interface to any CDF connected.
The AVPs that are populated on the Diameter Rf interface are documented on the Rf Interface AVPs section of the Sentinel VoLTE Administration guide.
For more information on Rf Control Resource Adaptor see Rf Control Resource Adaptor Architecture.
Population of AVPs on the Diameter Ro interface
The AVPs that are populated on the Diameter Ro interface are documented on the Ro Interface AVPs section of the Sentinel VoLTE Administration guide.
Using online and offline charging together
When configured for both online and offline charging, it may be desirable to allow sessions to proceed when there is a communications outage with the OCS.
This can be achieved using the procedure at Fault Tolerant Online Charging.
Note that when configured this way, conference calls will still fail when the OCS connection fails or times out mid-session, and there will be no CCR-T for calls that experience an outage.
