The IPSMGW IEC charging feature defines immediate event charging of MO- and MT-FSMs delivered over the PS and CS networks for Sentinel as an IPSMGW.
Description
Feature script name |
IPSMGWIECFeature |
|---|---|
Applicable contexts |
SIP service |
Prerequisite features |
PS Delivery or CS Delivery or MO Submission |
Feature execution points |
SipAccess_ChargingAbort SipAccess_CreditAllocatedPostCC SipAccess_CreditLimitReachedPostCC SipAccess_ControlNotRequiredPostCC SipAccess_ServiceTimer SipInstructionExecutionFailure SipThirdPartyAccess_SubscriberCheck SipThirdPartyAccess_PartyRequest SipThirdPartyAccess_PartyResponse SipTransaction_SubscriberCheck SipTransaction_Request SipTransaction_PartyResponse |
The IPSMGW IEC feature covers immediate event charging using a charge/refund model. The feature is responsible for:
-
creating the reservation charging instance (
IPSMGWChargingFeatureUtil.DEFAULT_IEC_CHARGING_INSTANCE) and default session counter on a pending delivery. -
instructing the charging manager to send a direct debit to the OCS
-
detection of message nondelivery conditions and refunding as necessary
The general use case is that an SMS will be delivered by one of IPSMGW’s delivery or submission features. On the incoming MO SIP MESSAGE, or MT-FSM DialogTcapMessage, the IEC feature will trigger a direct debit, suspending the outgoing message until a charging response is received, before allowing the message to be sent. If a response to the message is received which indicates failure, a refund will be issued, unless a fallback is attempted that also has charging enabled.
For a high level overview of Sentinel charging see Sentinel SIP Charging Architecture
|
Currently, IPSMGW only supports one charging instance per Sentinel session, though this instance may have multiple session counters. |
|
All of IPSMGW’s charging features make use of Sentinel’s comprehensive charging API — see Using the SIP Charging Manager |
Feature cheat sheet
| Feature Name | Network Operator Data | Used in PlanId(s) | Stateful or Stateless | POJO Feature or SBB Feature |
|---|---|---|---|---|
IPSMGWIECFeature |
No |
MTFSM_PS,MTFSM_CS,MTFSM_CS_PS,MTFSM_PS_CS |
Stateless |
SBB |
Session state inputs and outputs
Inputs
| Name | Format | Description | Behaviour if null/invalid |
|---|---|---|---|
SentinelSelectionKey |
selection key (for example, |
For selecting mappers |
Increment InputParameterErrors Common cleanup actions |
SentinelIPSMGWAddress |
MAP-CommonDataTypes.AddressString |
The value that the feature will use as the MSC-address in outgoing messages. Written to SessionState for retrieval by charging mappers. |
N/A |
IPSMGWChargingCounterAddress |
key/value pairs identifying the session charged service |
Determines which counter the feature will update with charging data (the IEC feature only treats one counter as the immediate charging counter at a time). Also see Outputs. |
No-op unless initial request |
LatestOcsAnswer |
Last received CCA |
Passed through to a charging mapper to generate the session counter values |
Exception thrown, if the feature is expecting a response from the OCS. Otherwise ignored. |
PSDeliveryStatus |
NOT_ATTEMPTED/FAILED/SUCCEEDED |
Outcome of last PS Delivery attempt |
N/A |
CSDeliveryFailed |
boolean |
Whether the CS Delivery feature delivery attempt failed |
N/A |
MoSubmissionFailed |
boolean |
Whether the MOSubmission feature delivery attempt failed |
N/A |
PSDeliveryTimerID |
The ID of the PS Delivery timer |
Used in determining whether to do a refund after a delivery failure |
Timer event is ignored |
IECChargingInstructed |
boolean |
Whether there has already been a charging instruction in this session |
N/A |
IECRefundInstructed |
boolean |
Whether there has already been a refund instruction in this session |
N/A |
LatestClientRequest |
Credit-Control-Request |
Determine whether an incoming CCA is a direct debit |
N/A |
Outputs
| Name | Format | Description |
|---|---|---|
IPSMGWChargingCounterAddress |
key/value pairs identifying the session charged service |
Mapped from initial incoming chargeable event request in SIP initiated sessions to determine the default session counter against which the units will be charged. |
UserSessionId |
String |
The MT SIP session ID |
InboundSipRequest |
The incoming SIP request in MO deliveries |
Used to extract information for use in a CCR |
InboundDialogTcapMessage |
The incoming TCAP message in MT deliveries |
Used to extract information for use in a CCR |
IECChargingInstructed |
boolean |
Set after a |
IECRefundInstructed |
boolean |
Set after a |
Charging API interactions
The charging API interactions fall under the following categories:
-
charging instructions issued on the
IPSMGWChargingFeatureUtil.DEFAULT_IEC_CHARGING_INSTANCEitself -
updates made to all counters on the charging instance, mainly limited to updates from CCAs.
-
complete implementation of event based charging on the default counter.
Interaction with the default charging instance
Initialisation
When the feature is first triggered on an incoming message, if there is a delivery message pending, it creates the default IEC charging instance, under the name IPSMGWChargingFeatureUtil.IPSMGW_IEC_CHARGING_INSTANCE.
It then maps the request to a session counter address written to the session state field IPSMGWChargingCounterAddress.
This is the default session counter on which all subsequent IEC based charging is performed.
Initial debit
On any trigger other than an incoming message request, the feature checks whether the IPSMGWChargingFeatureUtil.DEFAULT_IEC_CHARGING_INSTANCE has been initialised.
The first step is to check the instance exists in the ChargingManager, then that the instance has a session counter with the address specified in session state IPSMGWChargingCounterAddress.
If either check fails, the feature ends immediately on the assumption that IEC is not enabled.
The feature will instruct the charging instance to send a direct debit message to the OCS. It will suspend the outgoing delivery leg until the OCS authorises the request.
The Ro Credit-Control-Request is generated using the IPSMGWChargingInstanceToCCR mapper.
Interaction with all session counters
When a CCA is received, all counters on the ChargingInstance will be processed according to the algorithm outlined in Counter update algorithm pseudo code. The feature will clear the pending requested units on all session counters.
When charging using a non-default counter, another feature will need to set reported used and pending requested units on the counters as needed.
Mappers
This feature relies on two mappers:
-
The first converts the initial message to a SessionCounterAddress.
The default implementations are MTFSMToSessionCounterAddress and `SipRequestToSessionCounterAddress`SipRequestToSessionCounterAddress:// a mapper that takes a DialogTcapMessage or SipRequest and generates a SessionCounterAddress. final Mapper<SentinelSipSessionState> mapper = getMapperLibrary().findMapper( getSessionState().getSentinelSelectionKey(), argClass, SessionCounterAddress.class, mappingPoint); -
The second mapper converts a CCA into a list of session counters.
The default implementation is CCAtoSessionCounterList:// a mapper that takes a CreditControlAnswer and generates a List<SessionCounter>. final Mapper<SentinelSipSessionState> mapper = getMapperLibrary().findMapper( getSessionState().getSentinelSelectionKey(), CreditControlAnswer.class, List.class mappingPoint);
