This page presents illustrative flows for the MT Online Charging.
MT Online Charging uses the Diameter Ro protocol. The IP-SM-GW acts as the Charging Trigger Function, and uses Immediate Event Charging. MT Online Charging is triggered from the MT Delivery path. In Sentinel IP-SM-GW, the use of MT Online Charging is optional, and is selected during installation.
MT Delivery can either use the CS network (MSC and/or SGSN) or the PS Network (IMS core). Delivery related charging can be enabled separately for each network. If charging is disabled for a particular network, it is assumed that the network itself will take over this responsibility.
The PS network is used for delivery for two cases:
An SMS being sent to the UE. In this case the IP-SM-GW sends a SIP Message request with body containing RP-DATA where the RP-User Data contains an SMS_DELIVER.
An SMS Status Report sent to the UE. In this case the IP-SM-GW sends a SIP Message request with body containing RP-DATA where the RP-User Data contains an SMS_STATUS_REPORT.
The Online Charging System is able to distinguish these cases according to the AVPs sent by the IP-SM-GW. Details of the precise AVPs used is documented in the IPSMGWChargingInstanceToCCR mapper.
MT Online Charging is implemented by the IPSMGW IEC Feature.
If online charging is enabled for both the PS and CS networks, and the
DeliveryOrder attribute in the
UNRESOLVABLE BXREF: shared-configuration-profile[Shared Configuration Profile] is set to
CS_THEN_PS, then the charging session will carry over to the fallback session in the case of a delivery failure.
This means that the IEC feature will not request a refund after the first failure, and it will not initiate a new charging session for the fallback delivery attempt.
A refund will only be requested if the delivery attempts over both networks fail.
In the scenarios on this page, "Bob" is the receiver of the SMS.
All MT Online Charging related logic in the IP-SM-GW is triggered from the receipt of a
MAP MT Forward Short Message operation.
This flow shows that:
A PS delivery will be attempted, and therefore
immediate charging request occurs, and is granted successfully
the PS delivery fails, and therefore charging is refunded as CS charging is disabled
The product default is that if PS delivery fails, CS delivery is attempted. This is a different set of functionality than charging. For more information on delivery order please refer to MT Delivery Flows.
The next flow shows default behaviour for when the charging request is refused, as the credit limit has been reached.
The next flow shows a delivery order of
CS_THEN_PS, with charging enabled for both.
Both delivery attempts fail, so a refund is initiated after the failed PS delivery.
The Sentinel framework (IP-SM-GW is built on top of the Sentinel framework) allows different models for units being requested and granted than that shown in the above flow. These capabilities are often used for various "OCS failure handling" policies.
For example Sentinel can be configured such that:
There are pools of units that are locally granted if the OCS request times out, once the pool is expired, further reservations against the pool are refused
Certain classes of users are always granted credit, and the OCS is not requested
other combinations of local pool use with user distinctions
For more information about such capabilities please refer to Promotions.