Definition
Overage refers to the handling strategy when a data pool, Shared Bucket shared quota, or a single SIM card data plan exceeds the Quota. Overage supports overage billing, speed limiting, alerts, suspension, etc., and works together with the Quota and Fair Usage Policy to achieve controllable usage and cost protection.
Handling Strategies
Typical Overage strategies: Overage Billing — excess usage is billed according to the Rate Card, suitable for elastic usage scenarios; Speed Limiting — after exceeding the limit, speed drops to 2G or lower, controlling cost while maintaining basic connectivity; Alerts — send alerts via Event Subscription, SMS, or email when exceeding the limit, notifying customers; Suspension — suspend data services after overage, requiring customer confirmation or top-up to resume. Strategies can be configured differently based on customer, data plan, or pool.
Use Cases
Overage applies to Pooled Data data pools, Shared Bucket, single SIM card data plans, etc. In pool scenarios, it should be combined with the Fair Usage Policy to prevent a single SIM from overusing and causing pool overage. In cross-border scenarios, roaming overage costs are high, so Overage strategies can be stricter (such as speed limiting or suspension) to avoid abnormal charges.
Implementation in ICMP
SimtoLink ICMP supports Overage policy configuration: overcharge, speed limit, alarm, suspension; linked with Quota, Usage Analytics for real-time usage; supports Event Subscription for overage alarm notifications; CDR and billing system accurately record overage consumption and charges.
Which Level Triggers the Overage Action
Overage is what the platform does after usage has already crossed a ceiling agreed in advance. The action can be to price the excess separately, to lower the rate, to notify the responsible person, or to suspend data service. These actions are not synonyms. The product must choose one, and it must say at which level the judgment is made: a single SIM, a shared pool, or the customer’s total account. Overage on one SIM affects only that SIM. Overage on a pool affects every SIM in the pool that is still consuming, even if most of those SIMs have used very little themselves. The quantity used for the judgment must also match the measure in usage aggregation. Otherwise the portal says the ceiling has not been crossed while the network side has already throttled.
Enable an overage rule only when the ceiling, the cycle, the treatment of late CDRs, and who receives the notice already exist. If roaming usage arrives late and the rule looks only at quantity already posted, it may fire only in the next cycle, while this cycle’s overage charge has already been incurred. If the rule suspends early on an estimate, it can hit a SIM that still has allowance left. Agree which one wins when the estimate and the final CDR conflict, and whether recovery after suspension needs a person to confirm or runs automatically. Suspension itself must call the suspension flow. A mark on the invoice, while the device keeps transmitting, is not suspension.
Reading a Drained Pool as One SIM
A common error is an alert on each SIM and no ceiling on the shared pool. A few SIMs use the pool up, the rest suddenly become unavailable, and the alert goes to someone who is not responsible for that SIM. Another error is an overage unit price that was never written into the tariff. The system keeps allowing traffic, and at month end the excess cannot be priced, so the whole amount is disputed. Configuring both throttle and suspension without a priority also leaves operations unable to explain why the device can still upload slowly.
If fair use has its own per-SIM ceiling, trigger it separately from pool overage. A SIM that hits its own limit first should be limited on its own. It should not wait until the whole pool is exhausted, and a per-SIM limit should not be displayed as a pool-wide fault. An overage record should keep the usage at the trigger, the threshold, the action, and the later recovery, so it can be compared with the final invoice, not only a status that says “over limit.”
A rule change applies only to usage after it takes effect. Saving the configuration should not, in passing, lift a throttle or a suspension already in force. A SIM newly added to a shared pool counts toward the same ceiling from the moment it joins, not from the next reset. If a final CDR reclassifies a stretch of traffic as non-billable, an overage action that was triggered on the estimate should be reversed under the same rule, and the quantities before and after the reversal should be kept, so a device is not left stopped with no matching excess record on the invoice.
Before the trigger, it is better to send one notice that does not change service, and to state how much usage or how much time remains before throttle, separate pricing, or suspension. Address the notice by level: a single-SIM anomaly goes to the person responsible for the device, and a shared pool about to be exhausted goes to the pool’s manager. Sending it to someone who is not responsible means the person who can add allowance or stop the abnormal device never sees it. If usage falls back because a late CDR arrives after the notice, send a recovery note as well, so the recipient does not suspend on a warning that has expired.
A grace period needs a clear end. During grace, traffic may continue and be billed at the excess unit price, or only a very small amount of usage may be allowed. Grace with no end is a ceiling that does not exist. The action after grace is exhausted must already be configured. Do not wait until it is exhausted and then decide. If the final CDR is below the estimate, excess already overcharged should be reversed. If the final CDR is higher, the additional part is still priced at the excess unit price in force at the time, not at a new price on the day of the late record.
When one SIM hits both a per-SIM rule and a pool rule, execute the stricter one that has already been written as taking priority, and record why the other was not executed. Otherwise support sees both throttle and suspension and does not know which one to explain to the customer. On recovery, lift the actions one by one. Restore first the action that should no longer be in force, then recompute the remaining allowance, and restore service fully only after the trigger condition is no longer met.