Research and tool methodology

Research and comparison method

We start with the question a deployment team needs to answer, identify the decision factors that affect it, and prefer primary material such as standards, regulator notices, operator announcements, and official technical documentation. Sources are linked where they support time-sensitive or consequential factual statements.

Comparisons are qualitative unless a page publishes measurements and a reproducible protocol. We compare relevant trade-offs under stated assumptions rather than assigning a universal score. We do not claim that an explanation is original research, a complete market census, or an independent laboratory result merely because multiple sources were consulted.

Vendor material can accurately describe that vendor’s product, but it is also commercial material. We avoid treating a vendor’s broad performance or superiority claim as neutral evidence. The site is owned by Atomic Mobile; our editorial standards explain that commercial context and our correction approach.

IoT data calculator formula

The IoT data usage calculator is a deterministic planning estimate. It does not use a traffic dataset or a trained model. Inputs are converted with binary units: 1 KB = 1,024 bytes and 1 MB = 1,048,576 bytes.

For each device, the implemented calculation is:

1. Payload bytes = entered payload converted to bytes.
2. Bytes per message = payload bytes × (1 + protocol overhead ÷ 100) × (1 + retry allowance ÷ 100).
3. Transmissions per day = entered transmissions, or entered transmissions × 24 when “per hour” is selected.
4. Operational bytes per month = bytes per message × transmissions per day × active days.
5. Per-device monthly bytes = operational bytes per month + (firmware update MB × 1,048,576).
6. Fleet monthly bytes = per-device monthly bytes × device count.

The daily result excludes firmware updates; firmware is added only to the monthly result. Overhead and retries are compounded because the calculator applies them as separate multipliers, rather than adding the two percentages together.

Calculator limitations

The result is not a bill forecast. A single percentage input cannot model every protocol layer or network state. The calculator does not separately measure IP, transport, security, application, radio, billing-block, attach, Domain Name System, keepalive, acknowledgement, roaming, or failed-session traffic. It assumes a fixed average payload and transmission rate, applies one retry allowance uniformly, and treats the entered firmware volume as a monthly per-device amount.

It also does not model compression, batching, variable signal quality, power-saving behavior, partial fleet activity, staged firmware rollout, operator rounding, pooled plans, taxes, or pricing tiers. Use pilot-device and operator-billing measurements for a production forecast.

IoT market tracker method

The IoT market tracker presents sourced acquisition and funding records tagged for IoT relevance. The integration uses Atomic Mobile’s versioned JSON feed, not CSV. Records are validated before a complete snapshot replaces the previous one; the tracker is not a complete market census.

Synchronization is currently off. The tracker is a saved-snapshot resource, not a live feed: displayed records may be out of date, and the initial page can contain a build-time snapshot. Rebuilding the site does not fetch new Atomic records. If synchronization is separately authorized and enabled, a request can trigger a refresh after the saved import is more than six hours old; there is no background refresh schedule.

A failed refresh retains the last successfully saved snapshot with a stale or error notice. If no readable validated snapshot is available to the API, it reports unavailable rather than substituting invented records. Check the displayed status and timestamps before using the records, and confirm material facts with their linked sources.

The reported date reflects the date associated with an announcement or event in the dataset. Where Atomic provides distinct announcement and completion dates backed by primary-source links, the tracker displays them separately. “Completion reported” means the cited primary source reported the transaction as completed on that date; it does not infer a separate legal effective date. Dates that are not provided remain unavailable rather than being inferred from a record’s status.

Each record can show when Atomic last modified it, and the summary can show the latest such modification among the displayed feed records. Older snapshots may not contain these timestamps. A record-update time is not the date of the underlying transaction, the date a source was reviewed, or independent verification. The separate last successful sync describes only when GlobalIoT most recently imported the feed successfully.

Because the tracker is a scoped subset and records can be revised as source information changes, it does not publish market totals or imply that summing displayed values produces a complete market figure. Review the linked source for the context and status of an individual record. The underlying data is provided by Atomic Mobile.

Network sunset tracker method

The network sunset tracker is a curated set of individual 2G and 3G operator records, not a complete global dataset. The current file was last compiled on 2026-09-07. Each displayed record contains a country, operator, technology, target or completion date, status, source, and a date on which that source was checked.

We prefer regulator and operator pages. A record is included only when it has a source URL and a verification date. “Announced” records reflect a published future plan; “in progress” records reflect a phased closure described as underway; “completed” records reflect a source describing the shutdown as completed. The date is preserved at the precision the source supports—day, month, or year—rather than inventing a more precise deadline.

Sunset tracker limitations

Absence from the tracker does not mean a network remains available. A national date can hide regional phases, exceptions, enterprise arrangements, roaming changes, or continued service on another operator. Announced dates can move, source pages can change, and a completed radio shutdown does not by itself establish device behavior or emergency-call support.

The table is a planning aid, not a coverage check or contractual commitment. Confirm current service, roaming access, frequency support, voice requirements, and device certification directly with the relevant operator and connectivity provider before making hardware or deployment decisions.