Traffic pool costs are allocated per unit; additional payments are required in the second year.
When 300 devices share a single data pool, usage disparities can cause immediate over-allocation, leading to throttling and additional charges by the second year. This document outlines the logic for grouping pools by device type and highlights critical terms that must be defined in contracts upfront: billing bases, rollover policies, independent pool creation, and alert thresholds.
300 devices in one pool: 100 gobble all the traffic, while the other 200 get throttled by mid-month. By month-end, total usage exceeds the cap, forcing extra charges. This isn't bad luck—the pool was misconfigured from day one. How you allocate resources matters more than raw capacity.
The volume disparity is significant; averaging means the lower-usage users subsidize the higher-usage ones.
The surveillance camera continuously streams video, consuming dozens of gigabytes per month on a single unit. The charging pile only sends heartbeat packets and order reports, using merely tens of megabytes monthly. Smart water meters consume even less; a year's usage is less than one day of the camera's traffic. For in-vehicle devices traveling across provinces, data usage fluctuates significantly.
100 cameras and 200 charging stations share the same pool, but 90% of the traffic is consumed by the first 100, leaving the remaining 200 unable to use their full allocation.
The "average usage" is a calculated figure derived by dividing total traffic by the number of units. This metric serves as the basis for allocating costs per unit and determining year-end payments.
Splitting a pool involves breaking one ledger into multiple ledgers.
Group by type and maintain separate pools. The camera pool is sized with a buffer above the monthly average usage; the charging pile pool is sized based on fixed heartbeat packet consumption. Pools are isolated—neither can draw from the other, and depletion in one does not affect the other.
Same 300 units; total traffic unchanged. We simply split one pool into two, so the 200 units that were throttled no longer compete with the 100 units.
Some projects settle based on actual monthly traffic volume, while others require a fixed upfront payment in the first month of each year. The former depends on that month's actual usage; the latter depends on how much remains in the pool. By the time you reach month 12, the billing difference can span an entire tier.
After grouping, you can see each group's spending and remaining balance for the month, with clear reconciliation in the ledger. Without grouping, you only see a total, and overspending isn't discovered until the settlement statement arrives.
Whether carryover is allowed in the pool and whether it's included in the contract appendix are separate matters—simple to address. However, if it's not written down, it doesn't exist.
Pools are isolated per project, and alert thresholds are configured per project. We can support this, provided the device type is specified before card activation.
The way to verify is simple: ask them directly, "How were these 300 units grouped?"
Splitting costs evenly is the easiest path but often leads to problems in year two. Month-end reconciliation disputes are minor; the real pain comes from the client using this against you during renewal negotiations. First, clarify the usage volume of your current batch—that's faster than haggling over prices. Want a breakdown? DM me your device type and quantity, and I'll segment it by usage tier for you.
