ESMPP Always Expects PPS_CHARGE_NOTIFY
Last updated on JUNE 09, 2017
Applies to:Oracle Communications Convergent Charging Controller - Version 6.0.0 to 6.0.1 [Release 6.0]
Information in this document applies to any platform.
On all versions of Oracle Communications Convergent Charging Controller (OC3C), the optional component Enhanced Short Message Fee Deduction (ESMPP) component is available as an interface to Short Message Fee Deduction (SMPP+) protocol compliant Short Message Service Centers (SMSCs).
ESMPP acts as a gateway between SMPP+ and the internal Intelligent Network Application Part (INAP) protocol used by Advanced Control Services (ACS) when triggering service logic configured in Control Plans (CPs).
In SMPP+, there are four message types:
- PPS_USER_CHECK - Sent by the SMSC to instruct the Oracle Service Logic Controller (SLC) of an attempt to deliver a short message (SMS)
- PPS_USER_CHECK_RESP - Response from the SLC to the SMSC to either allow or disallow the delivery of the SMS, usually based on funds but other service logic may be applied
- PPS_CHARGE_NOTIFY - An optional message from the SMSC based on the notify_mode value in the PPS_USER_CHECK_RESP used to notify the SLC of the delivery status of the SMS
- PPS_CHARGE_NOTIFY_RESP - Confirmation response from the SLC to the SMSC for the PPS_CHARGE_NOTIFY which advises the SMSC on whether the necessary action was successful or not
In theory, the first two messages are sufficient for the successful charging of an SMS (assuming the delivery of the SMS was successful).
ESMPP assumes all four messages are necessary and will therefore either:
- Hold resources open waiting for the PPS_CHARGE_NOTIFY irrespective of whether this message will arrive
- Time out the context which is necessary to correlate the PPS_CHARGE_NOTIFY to a PPS_USER_CHECK[_RESP] session making refunds impossible
Whether a PPS_CHARGE_NOTIFY will be sent by the SMSC depends on the notify_mode value in the PPS_USER_CHECK_RESP from the SLC. The possible values are:
- 0x01: Indicating notification in the case of success and failure
- 0x02: Indicating notification in the case of failure
- 0x03: Indicating notification in the case of success
- 0x04: Indicating no notification in the case of success and failure
ESMPP should use this value to determine whether to:
- Immediately release all resources if no PPS_CHARGE_NOTIFY message is expected
- Leave resources open for the duration configured ESMPP.server.sessionTimeout period in anticipation for a PPS_CHARGE_NOTIFY
This will prevent excessive resource usage as resources are released as soon as they are no longer necessary and allow for the possibility of a successful refund.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms