A connected-vehicle fleet sends telemetry over unreliable mobile networks with limited bandwidth and intermittent connectivity. What protocol and session characteristics matter, and what is the wrong choice?

What matters

• Connection setup cost. On a mobile network, a TCP handshake plus a TLS handshake can take a significant fraction of a second and consume disproportionate power. A persistent connection with a lightweight keepalive beats reconnecting per message, which is the primary argument against plain HTTP request-response for frequent telemetry.
• Message size, because bandwidth is metered and the radio is the dominant power consumer. Binary encoding and delta encoding matter far more here than in a datacentre.
• Behaviour under intermittent connectivity. The device must buffer locally, resume without losing data, and deduplicate on the server — because at-least-once from an intermittently connected device is the only achievable guarantee.
• Quality-of-service levels applied per message type. A periodic position update can be fire-and-forget; a fault code or a trip-complete event needs acknowledgement. Applying one level to everything either wastes bandwidth or loses important events.

What is usually wrong

HTTPS request-response per telemetry message. It is the default because it is familiar, and it pays a connection setup on every message, carries large headers, and has no useful behaviour when the network drops.

Also wrong: sending everything at a fixed high frequency. A stationary vehicle reporting identical coordinates every few seconds produces enormous volume with near-zero information. Filter at the edge — transmit on meaningful change plus a low-frequency heartbeat — which is a very large reduction achieved at the cheapest point in the system.

The parts that are not protocol choices

• Device identity and attestation. Each device needs a unique credential provisioned securely, rotatable remotely, and revocable — because a fleet with a shared secret is one extracted key away from a total compromise.
• Over-the-air update safety. A failed update on a vehicle is not a rollback, it is a recovery vehicle. Staged rollout, an A/B partition scheme, and a device-side ability to fall back are architectural requirements.
• Time. Devices have unreliable clocks, so event ordering must come from sequence numbers rather than device timestamps, with the server recording its own receipt time separately.

The framing

The physical world sets the constraints and the protocol is downstream of them. Power, radio cost, intermittent coverage and the impossibility of a physical rollback determine the design; the protocol is whichever one respects those constraints.