Definition
Fair Usage Policy (FUP, Fair Usage Policy) is a usage constraint in data pool or Shared Bucket shared quota scenarios, preventing a single card or a few devices from excessively occupying shared resources, ensuring fairness for other users in the pool and keeping overall costs controllable. Together with Overage billing and Quota allocation, it achieves cost control and anomaly protection.
Typical rules
Common FUP rules include: Single SIM usage limit — a single SIM's daily/monthly usage must not exceed N times the pool average; Rate limiting — slow down or pause when a single SIM's rate exceeds the threshold; Priority — high-priority services are guaranteed first, low-priority services are restricted when the pool is tight; Anomaly detection — sudden usage spikes, unusual time periods, or abnormal locations trigger alerts or throttling. Rules can be configured differently per customer, per pool, or per data plan.
Use Cases
FUP applies to Pooled Data data pools, Shared Buckets shared quotas, and enterprise unified data plans. If a device experiences a surge in traffic due to malfunction, malicious activity, or misconfiguration, FUP can limit its impact and prevent uncontrolled costs within the pool. In cross-border scenarios, roaming data is costly, and FUP can limit single SIM roaming usage, combined with Roaming Policy for precise control.
Implementation in ICMP
SimtoLink ICMP supports FUP policy configuration: set single SIM usage limits and rate limits per pool or per customer; supports actions such as alerts, throttling, and suspension; integrates with Usage Analytics to identify anomalies and automatically trigger policies. The platform records FUP trigger events to Audit Trail, facilitating customer analysis and optimization.
Fair use constrains one SIM's share of the pool
A fair usage policy constrains the share of a shared pool that one SIM may take. It does not rewrite the contract price of the whole pool. The pool’s total is still charged as the plan states. The policy only limits a SIM, or a few SIMs, that consume too fast from crowding out the other members while shared balance remains. It is not the same as a hard quota. A hard quota is that SIM’s own ceiling, and when it is used up there is nothing left. Fair use, while shared balance remains, stops one SIM from exhausting the balance early. It is also not the same as an overage fee. Overage is how to price what goes over. Fair use is how to limit rate or suspend after a share is exceeded.
The policy therefore has to belong to a shared pool that is already defined. When there is no sharing and each SIM has its own plan, there is no “taking someone else’s share,” and applying fair use only makes people think the operator slowed them at random. The share must be calculated from usage inside one measurement period, and that period must match the pool’s reset day. Using a calendar day against a pool that resets monthly triggers the threshold wrongly every day.
Usage conditions that may trigger throttling or suspension
Before a trigger, write down what is compared, the time window, and the action. The comparison can be a multiple of average usage in the pool, or an absolute ceiling. The window has to be long enough that one firmware download does not cross a daily threshold. Graded actions are more stable: alert first, then throttle, and suspend data only at the end. Suspension takes the device offline, and field maintenance can go offline with it, so it suits an abnormality that has already been confirmed, not a first response.
Roaming usage can have its own tighter condition, because the same bytes cost more on a visited network. That condition should cite the networks allowed by the roaming policy, rather than treating all traffic abroad as abuse. When a quota also exists, state which one takes effect first. A SIM quota that is used up stops the SIM, with no need to wait for fair use. When fair use triggers, the SIM quota may still have some left. A pool with very few members has an average with no statistical meaning, and a multiple rule is distorted. That kind of pool is better served by an absolute ceiling.
A multiple of the average that penalizes normal bulk reporting
Most SIMs in a pool may be low-traffic sensors, and a few may be video devices or gateways that report in bulk. Limiting at a fixed multiple of the average makes the gateway exceed the limit every day, even though its usage is within the design. That is not abuse. The members have different profiles. Putting different applications in one pool, then applying one multiple, steadily penalizes the high-usage members, while a sensor that is truly abnormal still looks “normal” because the base is so low.
A short window also misreads a concentrated upgrade as an attack. Hundreds of devices pull software at once in a maintenance window, the pool average jumps, devices that finish first are throttled, and devices that start later never catch up. Exclude the upgrade window, or set thresholds by device type. If the business system is not told after a throttle, the application keeps retrying, and traffic rises instead of falling. A trigger should keep the SIM identifier, the pool identifier, the numerator and denominator used in the calculation, and the action, so it is possible to check whether the formula itself is the problem. Do not use fair use as a substitute for fault investigation. Repeated reporting caused by a broken session should go back to diagnostics, not end with the SIM suspended.
Before a policy goes live, replay historical usage. Do not apply it straight to devices on the network. The replay shows which SIMs would be throttled in the first measurement window, and how many of those are known high-usage gateways. If the threshold is wrong, change the rule first, then enable it on a small set. After enablement, send the trigger record to the person responsible for that device, and state whether it is a throttle or a suspension and when recovery is expected. If the application on the device does not back off, retransmissions during throttling keep consuming the share, and the policy looks as if it failed. When recovering, do not release every suspended SIM at once. They will catch up together and fill the pool again. The replay period must match the real measurement period. One day of data cannot simulate a monthly multiple.