Secure offline coordination, built into OEM devices

Embedded device, gateway, and application responsibilities

offline-protocol-leaf¹ combines the embedded protocol surface with offline-protocol-core and offline-protocol-mls. The platform supplies frame I/O, entropy, time, and atomic durable storage. The leaf joins the established secure group and responds; it does not run the full std/Tokio routing engine.

The gateway runs the Offline Protocol Mesh SDK², including discovery, service routing, and reliability. Dynamic Offline Relay Switch (DORS) selects its qualified transports. OfflineID⁵ provides device identity, and Messaging Layer Security (MLS)⁶ protects the application exchange.

Bluetooth, Matter, Thread, Zigbee, Z-Wave, and Wi-SUN retain their vendor implementation and certification requirements. An adapter exposes a supported byte path to Offline Protocol. Compatibility with a vendor platform is not a claim that every radio protocol is a native transport or that separate networks can be bridged without qualification.

The reference build makes the footprint concrete

The linked Cortex-M33 leaf image occupies 449.5 KiB in the supplied reference build. Against a 1,536 KiB flash class, that is 29.3%, leaving 1,086.5 KiB before the radio stack, RTOS, bootloader, OTA arrangement, storage, and OEM application are allocated.⁷

The representative encrypted short-message fixture is 472 bytes, compared with 1,342 bytes in the prior representation. That is a 64.8% smaller encoded frame, before radio and retry overhead. Under the fixture's BLE fragmentation assumptions, the message uses four fragments instead of ten.⁴ MTU and radio behavior remain board-level measurements.

The reported MLS software-path microbenchmarks are 79.5 microseconds to seal and 91.3 microseconds to open on Apple Silicon.³ They establish that software benchmark's cost; they are not Cortex-M33 execution time or end-to-end request latency.

The reported footprint is a reference-build snapshot, not a fixed size across SDK and compiler versions. The footprint harness documents rustc 1.97.1 and targets thumbv8m.main-none-eabihf with size optimization, LTO, and abort-on-panic.⁷ Linking establishes flash consumption. Running the actual board establishes peak heap, task stack, interoperability, radio timing, and energy use. These measurements answer different OEM decisions.

Persistence is part of the device contract

Provisioning establishes the device identity and secure group state before operational requests are accepted.⁸ An OEM capability request carries a stable ID, scope, expiry, and payload version. The leaf verifies it under the secure context and applies the OEM's application policy.

LeafStore provides atomic durable protocol-state storage. Required state is persisted before a response is emitted. Reset recovery cannot roll cryptographic state back and reuse it as though no exchange occurred. Entropy, trustworthy time inputs, key storage, and update behavior are explicit platform responsibilities.

For physical actions, an OEM outcome journal and actuator interface determine what can be recovered after a power failure. A network receipt alone cannot promise exactly-once actuation. Read-only diagnostics are therefore a useful first qualification fixture before separately authorized physical-action workflows.

The package an OEM integrates

Data Edge Sync can support service views in the richer gateway profile through offline-protocol-data; it is not loaded onto the constrained leaf as a substitute for firmware state. The supplier distributes a reusable board-support interface and gateway profile, while OEMs own their application, partition plan, radio certification, release process, and field support.

The distribution package has two application profiles. Smart access connects a lock or controller, hub, and companion phone around authorized service requests and outcome evidence. Smart energy connects meter or field-device observations to the local gateway and existing head-end recipient. Both include reference firmware, a reproducible qualification suite, and an integration profile that sales and field engineering can take to additional OEMs.

Qualification follows the actual product

The integration progresses from pinned-version software interoperability to the selected board and then the OEM's complete firmware image. Each result records hardware, radio conditions, payload size, and firmware revision.

• Fit: the leaf qualification gate is below 500 KiB; the complete firmware must also fit the OEM's flash and OTA plan. Peak heap and stack are measured during pairing, receive, response, and rekey.
• Trust: invalid, expired, stale, and replayed requests must leave protected application state unchanged.
• Responsiveness: the selected local profile targets median authenticated request-to-response below 250 ms, excluding mechanical actuation.
• Recovery: reset and lost-receipt fixtures target at least 99.9% duplicate-free application outcomes, checked against the persistent journal.
• Interoperability: provisioning, frames, and group state must agree across the pinned leaf/gateway builds before actual radio qualification.

The delivered engineering result is an inspectable embedded implementation with repeatable size and wire-cost baselines. The original questions about device-side code and footprint now resolve to source, build settings, and measurement fixtures. Board qualification then measures the radio, memory, and recovery behavior of the OEM's complete product.

Managed services and expansion

The embedded integration gives the semiconductor supplier a repeatable route into additional OEM products. The next layer is the service experience around those devices: commissioning, diagnostics, field maintenance, and ongoing support under the OEM's own brand.

Product-specific capability profiles. Capability Exchange⁹ can package versioned service contracts for each product family. A smart-access profile can expose device health and authorized service-request outcomes; an energy profile can expose retained observations and diagnostic status. The richer gateway hosts discovery and routing, while the constrained leaf handles its supported requests and durable state. Adding these services does not require placing a hosted-service client or replicated database on every embedded device.

Managed aftermarket support. An OEM can connect gateway delivery through Hosted Relay and opt selected diagnostics into managed Telemetry.¹⁰ Support teams can then correlate provisioning, retry, and recovery problems with firmware and hardware revisions. Diagnostic collection is bounded and buffered at the gateway so it does not hold up local device requests. Commissioning evidence and field-service records create further support workflows using the same device identity.

Distribution beyond the first design. Additional OEMs inherit the reference firmware, gateway profile, storage contract, and qualification fixtures, then qualify their own boards and application behavior. This supports a commercial platform license with integration and distribution rights, product-specific engineering support, and optional managed operations.¹¹ The manufacturer can expand its service offering over the installed base while retaining its branded application, firmware release process, and customer relationship.