Fleet telemetry and field work stay connected beyond cellular coverage

Vehicle gateways and crew devices retain telemetry, assignments, and completion evidence locally, then reconcile with dispatch when a route becomes available

Field technicians beside service vehicles coordinate a remote maintenance visit using a rugged tablet.

Problem

The fleet team came to Offline Protocol with a gap between the work happening in the field and the work visible to dispatch. Vehicle observations, assignment acknowledgments, and completion evidence did not all reach the central system at the same time. When coverage dropped, dispatch lost context while the crew still had a job to finish. That gap created follow-up calls and reconciliation work at the next contact.

Solution

The deployed gateway and crew integration uses the Offline Protocol Mesh SDK1 to exchange assignments, progress, and approved vehicle observations over a reachable local path. Data Edge Sync2 keeps task views and checklists with the crew, while a durable event ledger retains telemetry and completion evidence with their original capture times and task versions. Automatic transport selection carries retained records upstream when coverage returns or a depot connection becomes available; the dispatch adapter deduplicates delivery and checks the assignment version.

Outcome

The operating change is visible at both ends. Crews keep working through coverage gaps and record completion where the job happens, without waiting to reconnect to enter their evidence. Dispatch receives the history needed to resolve the visit and distinguish a delayed upload from a late event or conflicting assignment. Field work becomes less dependent on connectivity, with fewer details left for crews and dispatchers to reconstruct at the next contact.

Coverage changes along the route

The vehicle gateway and authorized crew devices use the Offline Protocol Mesh SDK1. Dynamic Offline Relay Switch (DORS) automatically selects a qualified local or internet path. A depot encounter is another opportunity to exchange retained records; continuous vehicle-to-vehicle networking is not required.

Vehicle + field crewFleet operationsField taskAssigned v4EvidenceOverviewVehicle + gatewayCrew deviceHosted RelayQualified local exchangeTwo retained records, one recovery boundaryTelemetryDevice + boot epoch + source sequenceTask evidenceTask ID + assignment version + crew scopeWAN / depot pathExisting dispatchDeduplicate, check task versionConfirm commit or flag conflict
Vehicle + field crewField taskAssigned v4EvidenceOverviewVehicle + gatewayLocal pathRetained operational recordTelemetry: device / epoch / sequenceWork: task ID / version / evidenceTime-sensitive tasks have priorityWAN / depot pathRelay → existing dispatchSource-key deduplicationAssignment-version validationRecipient commit receiptsReassignment conflicts retain the crew evidence.
01 / Retained fleet records and dispatch reconciliation

OfflineID3 binds devices to their fleet and work scope. Messaging Layer Security (MLS)4 protects the exchange. Read-only telematics exports supply vehicle observations. Existing engine controls, safety systems, route planning, and dispatch authority remain outside the write path.

A task carries its task ID, assignment version, and crew scope. Dispatch owns the assignment; the crew app appends acknowledgments, observations, and completion evidence against that version. The recipient compares the submitted version with its current assignment before applying a completion. A reassignment during isolation preserves the crew evidence but raises a dispatcher exception instead of closing the newer assignment. Driver interaction follows the operator's safe-use rules.

A late upload is not a late event

Telematics consumers need to know when an observation occurred, not merely when a server received it. The retained stream records device identity, boot epoch, source sequence, capture time, and arrival time. That allows the recipient to distinguish delayed delivery from a missing section of history.

Capture timeReceipt timeNo cellular path09:10Captured09:15Captured09:20Captured09:30Captured09:32 / batch arrivesSource sequence and capture time survive delayed delivery. Example times show the mechanism.
Same observations, two clocksCaptured 09:10Received 09:10ConnectedCaptured 09:15Received 09:32Retained during gapCaptured 09:20Received 09:32Retained during gapCaptured 09:30Received 09:32Recovery batchExample timestamps illustrate ordering, not latency results.
02 / Capture time survives delayed arrival

GNSS availability is separate from cellular reachability. A fresh position can be retained without a cloud connection; an old position stays old even if the device reconnects. The application retains the last fix's age and accuracy rather than manufacturing live movement from an upload.

Tasks use a different model from telemetry. Data Edge Sync2, Offline Protocol's replicated-data layer, holds small task views, checklists, and crew notes. Dispatch owns assignments; the crew owns its attributed progress. High-volume vehicle observations remain in an append-only ledger rather than a shared document whose latest writer could erase history.

Keeping the queue useful under pressure

The application separates time-sensitive task traffic from bulk history. Nonurgent observations batch by age and size; completion evidence has reserved capacity. Queue age and storage pressure are observable. The retained stream is bounded by the configured storage envelope, with nonessential sampling policies explicit at ingestion.

The native gateway runs offline-protocol with offline-protocol-core, offline-protocol-services, offline-protocol-transport, offline-protocol-router, offline-protocol-reliability, and offline-protocol-mls. Crew applications use offline-protocol-uniffi or a supported Mesh SDK bridge. offline-protocol-data supplies task replication.

The source ledger and outbox commit together. A durable queue projects task state into the SDK's separate store. On recovery, Relay forwards retained ciphertext to the fleet or dispatch recipient adapter; that adapter deduplicates source keys and confirms business commits. Replay is throttled so it does not crowd out the next live assignment.

The record now follows the work

The crew's completed work remains available on the device through isolation and restart. When contact resumes, dispatch receives attributable acknowledgments and completion history against the original assignment version. Stale locations stay marked as stale, and reassignment conflicts remain visible to the dispatcher.

This gives the operator a consistent basis for resolving a field visit and its telemetry together. The productivity measures are manual dispatch contacts, repeated form entry, and task acknowledgment time.

Validation follows a route with planned dead zones, a field task, gateway restart, and depot recovery. The comparison ledger answers four questions:

  • Was the history retained? Match device/epoch/sequence keys against the committed source set and require no unexplained gaps within the configured capacity.
  • Was the task applied once? Replay events and lose receipts while checking the resulting assignment and completion records.
  • Did coordination improve? Record task-to-acknowledgment time, manual dispatch contacts, and form re-entry in matched operating windows.
  • Did batching help? Compare total transmitted bytes for the same event trace, including retries and overhead, alongside added delivery delay.

Managed services and expansion

Connect the depot visitInspections, checklists, and tool custodyCapability ExchangeSupport crews at the roadsideRead-only diagnostics and service evidenceVehicle-scoped accessGive dispatch the full recordVisit evidence and route recovery patternsHosted Relay + Telemetry
Connect the depot visitInspections, checklists, and tool custodyCapability ExchangeSupport crews at the roadsideRead-only diagnostics and service evidenceVehicle-scoped accessGive dispatch the full recordVisit evidence and route recovery patternsHosted Relay + Telemetry
03 / Connect depot and roadside service to fleet support

The vehicle gateway already connects field evidence to dispatch. Depot operations and roadside service can build on that connection, extending the record from a single assignment to the equipment and service interactions around it.

A managed view of the disconnected fleet. Selected Telemetry records5 can feed an opt-in managed observability stream covering queue pressure, transport changes, and recovery failures. Application events supply task acknowledgment and completion status. Operations can compare routes, depots, and hardware profiles without treating an old position as live. Hosted Relay forwards the retained field history; priority and batching remain under the fleet application's control.

Depot and roadside services. Capability Exchange6 can let an authorized technician request a read-only vehicle diagnostic snapshot, inspect equipment availability, or submit a service acknowledgment. The gateway returns attributed results through the same request and recovery model. Depot inspections, tool custody, and roadside-service completion then reuse task identity and evidence retention instead of introducing separate offline forms for each workflow.

Verification of a service visit. Proof of Location7 can add witnessed presence at a depot or equipped service point to the work record. The crew's checklist and receiving acknowledgment still establish completion. These extensions support managed fleet diagnostics and service-partner coordination, with access scoped by vehicle and assignment rather than granting partners access to the whole fleet.

References

  1. 01Offline Protocol Mesh SDK
  2. 02Data Edge Sync: replicated documents and persistence
  3. 03OfflineID and device identity
  4. 04Messaging Layer Security: RFC 9420
  5. 05Runtime telemetry
  6. 06Service discovery and authenticated invocation
  7. 07Proof of Location

Bring the failure case. Leave with evidence. One workflow, agreed criteria, 4 to 16 weeks.

Scope an evaluation Read the docs