Reducing IoT Data Costs: Optimisation Strategies for M2M Deployments
Data costs dominate M2M operational budgets. With the right optimisation strategies, you can reduce data consumption by 40-80% without sacrificing the information your business needs.
In this guide
Why Data Optimisation Matters for M2M
In most M2M deployments, the recurring cost of cellular data is the largest single operational expense, often exceeding the hardware cost of the device within the first year. When you're running 1,000 devices at $5 per month each, that's $60,000 per year — and much of that data spend may be wasted on inefficient protocols, redundant transmissions, and poorly designed reporting schedules.
The opportunity for optimisation is substantial. Many M2M devices transmit significantly more data than necessary, either because they use verbose protocols designed for web browsers rather than machine communication, because they report at fixed intervals regardless of whether anything has changed, or because they send raw data that could be compressed or aggregated before transmission.
Reducing data consumption doesn't just save money — it also extends battery life for battery-powered devices (less radio time means less power consumption), reduces network congestion, and can improve system reliability by minimising the time devices spend actively transmitting.
Protocol Selection: The Biggest Quick Win
The communication protocol your devices use has the largest single impact on data consumption. Many IoT devices default to HTTP/HTTPS because it's familiar to developers, but machine communication has far more efficient alternatives.
| Protocol | Typical Overhead per Message | Best For | Data Efficiency vs HTTP |
|---|---|---|---|
| HTTP/HTTPS | 500-2,000 bytes (headers alone) | Web applications; not ideal for M2M | Baseline (1×) |
| MQTT | 2-4 bytes minimum header | Frequent small messages; telemetry; event-driven | 5-10× more efficient |
| CoAP | 4 bytes fixed header | Constrained devices; request-response patterns; sensor data | Uses approximately 40% of the power of HTTP (per IETF RFC 7252 design goals) |
| LwM2M | Built on CoAP with device management | Device management + data reporting combined | 8-15× more efficient for managed fleets |
| Raw TCP/UDP | 20-28 bytes (TCP) / 8 bytes (UDP) | Custom binary protocols; maximum efficiency | 10-50× more efficient |
Switching from HTTP to MQTT alone can reduce data consumption by 80-90% for typical telemetry workloads. MQTT's minimal header overhead, persistent connections (eliminating repeated TLS handshakes), and publish-subscribe architecture make it the default choice for most M2M data transmission. CoAP is the alternative for extremely constrained devices on NB-IoT networks, where its UDP-based transport and compact binary format provide the absolute minimum data overhead.
Data Compression and Encoding
Beyond protocol selection, how you encode and compress your data payloads directly affects consumption.
| Technique | Typical Reduction | Implementation Effort | Best For |
|---|---|---|---|
| JSON → CBOR (binary JSON) | 30-50% smaller payloads | Low — libraries available for most languages | Structured data that's currently sent as JSON |
| JSON → Protocol Buffers | 50-70% smaller payloads | Medium — requires schema definition | High-volume telemetry with defined data structures |
| Delta encoding | 60-90% reduction for slowly-changing data | Medium — requires tracking previous values | Sensor readings where values change incrementally |
| Gzip compression on payload | 60-80% for text data; minimal for binary | Low — standard library support everywhere | Larger payloads (>100 bytes); text-heavy data |
| Custom binary encoding | 80-95% vs JSON | High — requires custom parser at both ends | Maximum efficiency for well-defined data structures |
The practical sweet spot for most deployments is CBOR encoding with MQTT transport. CBOR (Concise Binary Object Representation) provides a direct binary equivalent of JSON — your data structure stays the same, but the encoded payload is 30-50% smaller because field names and values are encoded as compact binary tokens rather than verbose text strings. Most modern IoT platforms support CBOR natively.
Smart Reporting: Send Less, Know More
The most effective data optimisation is not sending data that doesn't need to be sent. Many M2M devices are configured with fixed reporting intervals regardless of whether conditions have changed.
Report-by-exception is the single most impactful reporting optimisation. Instead of transmitting every 60 seconds, the device only transmits when a value changes beyond a defined threshold or when an event occurs. A temperature sensor that reports every minute generates 1,440 messages per day. The same sensor configured to report only when the temperature changes by more than 0.5°C might send 20-50 messages per day — a 95%+ reduction in data consumption.
Message batching is the complementary strategy. Rather than sending each data point as a separate transmission (each with its own protocol overhead, TLS handshake, and network signalling), devices collect multiple data points and transmit them in a single message. Batching 10 sensor readings into one transmission doesn't reduce the raw data volume, but it eliminates 90% of the protocol overhead.
Adaptive reporting combines both approaches: report frequently during interesting conditions (an alarm event, a rapid temperature change, a vehicle in motion) and minimally during steady-state conditions (building unoccupied overnight, vehicle parked, temperature stable). This gives you granular data when it matters and minimal data when nothing is happening.
Edge Processing: Compute Before You Transmit
Edge processing moves data analysis from your cloud servers to the device itself, transmitting only the results rather than raw data. This approach is increasingly viable as IoT device processors become more capable.
A vibration sensor monitoring industrial equipment might sample at 10,000 readings per second. Transmitting all that raw data would consume enormous bandwidth. Instead, the device performs a Fast Fourier Transform locally, extracts the frequency peaks and overall vibration severity, and transmits only the analysis results — perhaps 50 bytes instead of 50 kilobytes.
Practical edge processing strategies for M2M include: local averaging (send hourly averages instead of per-minute readings), threshold detection (only report anomalies), data deduplication (suppress repeated identical readings), and predictive filtering (only transmit data points that deviate from a predicted trend).
The trade-off is device complexity and processing power. Not every M2M device has the CPU capacity for meaningful edge processing — a basic GPS tracker or alarm panel has limited computational resources. But for deployments using more capable hardware (industrial gateways, connected vehicle systems, smart building controllers), edge processing can reduce data transmission volumes by 90% or more while actually improving the value of the data that does get transmitted.