THE CHALLENGEThe Link Is Unreliable, the Data Cannot Be
A telematics device talks to the cloud over a cellular connection that drops in tunnels, dead zones, and during handovers, on a data plan that costs money per byte. The protocol sitting between the firmware and the backend has to survive all of that: hold data when the link is down, resend it without duplication when the link returns, keep every byte small, and stay secure end to end. Pick the wrong protocol or framing and you get lost trips, bloated bills, and a backend that cannot trust its own data. The device-to-cloud protocol is a deliberate engineering decision, matched to the device, the radio, and the platform.
Part of the GPS tracking device engineering stack, and commonly built alongside Telematics Backend Data Ingestion.
WHEN YOU NEED THIS
When the Wire Format Matters
You need protocol engineering when a device has to report reliably over cellular at scale, when data loss is unacceptable, or when an off-the-shelf protocol choice is costing you bandwidth, battery, or backend complexity.
New Telematics Devices
Greenfield trackers and gateways where the protocol, message schema, and security need to be designed alongside the firmware and the ingestion backend.
Bandwidth-Constrained Links
Devices on metered cellular, NB-IoT, or Cat-M1 where every byte counts and a verbose JSON-over-HTTP design is burning data budget and battery on each report.
Lossy Coverage
Vehicles and assets that move through tunnels, basements, and rural dead zones where the link drops constantly and data must be buffered and recovered without gaps.
SCOPE OF WORK
What's Included
Transport Selection
Transport is chosen between MQTT, raw TCP, and CoAP based on the device, the radio, and the backend. MQTT for pub-sub fan-out to a broker, raw TCP with a compact binary frame where the protocol overhead has to be minimal, and CoAP over UDP for the most constrained NB-IoT nodes.
Custom Binary Framing
Where bytes matter, a compact binary message format uses a fixed header, typed fields, and bit-packed flags instead of verbose text. A position report that would be hundreds of bytes as JSON becomes a few dozen bytes on the wire, which directly cuts data cost and transmit energy.
ACK, Retransmit, Store-and-Forward
Acknowledged delivery with retransmit and de-duplication ensures no report is lost or counted twice. When the link is down, the device stores reports in flash and forwards them in order on reconnect, so a tunnel or a dead zone produces a delayed report, not a missing one.
Security and Schema
The channel is secured with TLS, including session resumption to keep the handshake cost low on battery devices, and a versioned message schema lets firmware and backend evolve without breaking each other.
TECHNICAL APPROACH
How the Protocol Is Designed
The protocol is designed against the three things that actually constrain it: the cost per byte on the data plan, the energy of keeping the radio awake, and the reality that the link will fail mid-message. Every decision is made to keep all three low.
Bandwidth Optimization
Payload size is minimized with binary framing, delta encoding for slow-changing fields, and batching of buffered reports so one connection carries many records. Keep-alive intervals are tuned so the device is not paying to hold a connection it is not using.
Reliable Delivery
Each report carries a sequence number so the backend can detect gaps and duplicates. Retransmit uses backoff so a flapping link does not turn into a storm of retries, and store-and-forward preserves order across reconnects.
Tested Against Reality
The protocol is tested under simulated packet loss, latency, and abrupt disconnects, rather than only on a clean LAN. The firmware stack runs on the actual modem so the validated behavior is the behavior the field will see.
INTEGRATION AND OUTPUTS
Both Ends of the Link
A protocol is only useful if both ends agree on it, so scope covers the device-side implementation and a clear specification the ingestion backend builds against, with the broker or socket server configured to match.
Device and Backend Aligned
The protocol is implemented in the firmware, and the framing and schema are documented so the ingestion service decodes it cleanly. The MQTT broker or TCP server is configured to match the device behavior end to end.
Ready to Ingest
The wire format is defined so the backend can parse, validate, and store reports straight into the time-series pipeline, which keeps the device-to-cloud protocol and the ingestion layer in sync as both evolve.
FAQ
Common Questions
MQTT or a custom TCP protocol, which is better?
Neither is universally better. MQTT gives you pub-sub, a mature broker ecosystem, and quality-of-service levels out of the box, which suits fleets fanning data out to many consumers. A custom binary protocol over raw TCP wins when you need the absolute minimum bytes on the wire and full control of the framing. The choice depends on your bandwidth budget, backend, and how many systems consume the data.
How is no data lost when coverage drops?
Store-and-forward with acknowledged delivery handles this. The device buffers reports in flash while the link is down and forwards them in order when it returns, each carrying a sequence number so the backend can detect gaps and reject duplicates. A vehicle passing through a tunnel produces a delayed batch of reports rather than a hole in the trip history.
Why not just send JSON over HTTPS?
JSON over HTTPS is simple but expensive on a constrained cellular device. The text encoding and HTTP headers inflate every report, the TLS handshake repeats on each request, and the overhead burns both data plan and battery. A persistent MQTT or TCP session with a compact binary payload sends the same information in a fraction of the bytes and energy.
Need a Protocol That Does Not Lose Data?
Share your device, your radio, and your backend to get a device-to-cloud protocol, framing, and security designed so your data arrives complete and cheap to carry.
Schedule a Free Consultation