When Your PTT Radio Is Also a Web Browser: Managing Data on Android Field Devices
April 23, 2026
What Is an IoT Data Pool and How Does It Work?
If your IoT fleet has some devices that use almost nothing and others that use a lot, a data pool changes the billing math in your favor.
Picture a fleet of 50 IoT SIM cards. Twenty are in active field sensors reporting data every few minutes. Fifteen are in devices that check in a handful of times a day. The remaining 15 are in standby units or low-activity locations that barely transmit at all. If each SIM is on its own individual data plan, you’re paying for 50 separate data buckets — and most of them are only partially full at month end. That wasted unused data is called breakage, and it’s one of the most common ways IoT operators overpay for connectivity without realizing it.
A data pool solves this by replacing 50 individual buckets with one shared bucket that the whole fleet draws from together.
What a data pool is and how it works
An IoT data pool is a shared allocation of cellular data distributed across a group of SIM cards under a single account. Instead of each SIM having its own fixed monthly allowance, all SIMs in the fleet contribute to a combined total and draw from it as needed.
The maths is straightforward. A fleet of 100 SIM cards on a 25MB bundle each contributes 25MB to the shared pool, giving the account a total of 2,500MB to work with that month. A device that uses 80MB consumes from that shared total. A device that uses 2MB also consumes from it. As long as the fleet’s combined usage stays within 2,500MB, no overage is incurred — regardless of how unevenly consumption is distributed across individual SIMs.
This is the core advantage. In a per-SIM model, the device that uses 2MB doesn’t “share” its unused 23MB with the device that needed 80MB. Each SIM’s unused allocation simply disappears at month end. In a pooled model, the light users effectively subsidize the heavy users, and the overall allocation is used more efficiently.
The pool resets each billing cycle. Usage is calculated at the account level, not per device. If the total fleet consumption stays within the pool, the cost is fixed. If the fleet goes over, overages are billed on the excess at a per-MB rate. Monitoring total pool consumption — not per-SIM consumption — is what matters for cost control.
Figure 1 — Stat callout: the breakage problem
Why this matters specifically for IoT
Consumer data plans assume roughly consistent usage from month to month — someone streaming video or browsing the web generates fairly predictable consumption. IoT devices don’t behave that way. Usage varies by device type, by location, by operating conditions, and by what the device is doing in any given month.
A temperature sensor in a cold storage unit reports continuously during a full operational month. The same sensor in a seasonal facility goes nearly silent during off-peak periods. A GPS tracker on an active delivery vehicle logs hundreds of location pings a day. An identical tracker on a parked asset reports almost nothing. Understanding how different devices consume data is the starting point — but even with good estimates, a mixed fleet will always have devices that use significantly more or less than the average.
Per-SIM plans deal with this by forcing you to pick a bundle size per device. If you pick too small, devices hit their limit and stop reporting or generate overages. If you pick too large, you pay for data that never gets used. Across a fleet of any meaningful size, you’re almost always doing one or the other on a significant portion of your SIMs. A pooled plan sidesteps this by letting the fleet self-balance. The device that used 5MB this month covers for the device that needed 45MB, and the overall allocation reflects the fleet’s actual aggregate behavior rather than an assumption about any individual unit.
This is also why pooled plans pair well with usage monitoring. Keeping visibility across your fleet’s total consumption lets you adjust the pool size before you hit an overage rather than discovering it at month end.
Figure 2 — Step sequence: how pool billing works at month end
What can go wrong
The most common mistake is sizing the pool based on average device usage without accounting for outliers. If most of your sensors use 10MB a month but one device is on a reporting schedule that generates 200MB, that single outlier can consume a disproportionate share of the pool and trigger overages every month. Right-sizing a connectivity plan starts with measuring actual usage across the full distribution of devices, not just the typical case.
The second mistake is treating the pool as a set-and-forget decision. If your fleet grows — say you add 15 devices mid-quarter — the pool grows proportionally, but the per-SIM bundle size stays fixed. A fleet that was comfortably within its pool at 50 SIMs may be chronically over its pool at 65 SIMs if the bundle size wasn’t adjusted to reflect the actual per-device consumption pattern. Monitor total pool consumption regularly, not just at invoice time.
A third, less obvious mistake is using a pooled plan when a pay-as-you-go structure would be more appropriate. Pooled bundles are efficient when usage is uneven but predictable in aggregate. If your fleet is small, early-stage, or highly variable month to month — some months heavy, others nearly zero — a PAYG model where you pay only for what’s actually consumed may produce a lower total cost. The pool model rewards consistency and scale; it doesn’t always reward unpredictability.
What to do
Three steps before committing to a pool structure. First, measure before you commit. Run your devices on a PAYG or prepaid plan for at least one full billing cycle and log actual per-SIM consumption. The distribution matters more than the average — if usage is tightly clustered, a pool is clearly the right model. If it’s wildly variable, revisit.
Second, set the pool size based on 80th percentile consumption, not median. Using the median leaves you exposed to the heavy users. Adding a buffer for the top users means you’ll rarely hit an overage without a genuine anomaly driving it.
Third, configure usage alerts at the account level. When total pool consumption hits 80% of the allocation before month end, you want to know — and the right response is either to increase the bundle size for the current cycle or investigate which devices are running hot. Simplex’s SIM management portal supports per-account usage alerts, and increasing the bundle size mid-month is allowed — the end-of-month cost calculation reflects the higher tier for that period.
A data pool doesn’t eliminate the need to understand your fleet’s usage patterns. It does eliminate the waste that comes from per-SIM plans in fleets where usage is inherently uneven — which describes most IoT deployments at any meaningful scale.
Explore Simplex’s pooled data bundle options or talk to the team at sales@simplexwireless.com if you’re figuring out which plan structure fits your fleet.
This article was curated by Jan Lattunen, CCO Simplex Wireless
About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen