Platform · Connectivity
From modem to cloud, typed all the way.
All major modems 2G–5G + LPWA. Dual APN — production payload and management plane on the same module. eUICC Consumer (GSMA SGP.22) and eUICC M2M (GSMA SGP.02) in sealed enclosures. WiFi AP + STA dual-band with runtime backend detection. BLE central and peripheral (GATT server) roles. DHCP server and client per interface. Multi-protocol cloud uplink. Each layer typed, observable, and config-driven.
Key metrics
The numbers that size the stack.
Cellular
All major modems — capability-first.
All major modem flavors, 2G → 5G + LPWA
The modem stack loads vendor libraries at runtime. Coverage spans 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M), and NB-IoT — IPv4 and IPv6. Adding a new cellular module is a library swap plus a config update — no micro service recompilation.
Dual APN — production + management plane
Two active data bearer sessions on the same module. Customer payload rides the production APN while OTA, remote-diagnostic tunnels, observability, and device management ride the management APN — physically isolated at the carrier core. No back-haul VPN gymnastics.
eUICC Consumer + eUICC M2M in sealed enclosures
GSMA SGP.22 v2.2 eUICC profile management: download, enable, disable, delete, and recovery — without a separate eUICC management micro service. Conditionally compiled — adds no overhead on physical-SIM builds. The same binary ships to both hardware variants.
IP routing and NAT
IP routing, NAT/MASQUERADE, and IP forwarding are owned by the modem micro service via RoutingService — not a separate micro service.
Software-defined thermal management
For modules without firmware-level thermal zones, host-side polling with graduated actions: log → MTU reduction → radio off → shutdown.
WiFi
WiFi — dual backend, one binary.
The WiFi micro service reads the device tree at startup and selects the backend without any
compile-time flag. AP and STA modes switch at runtime via SetMode .
| Backend | Modes | Frequency bands | ScanNetworks |
|---|---|---|---|
| AP+STA dual-band | AP + STA | 2.4 GHz + 5 GHz | Yes |
| AP+STA 2.4 GHz | AP + STA | 2.4 GHz | Not supported |
On platforms where WiFi and BT share one radio power rail, the Bluetooth micro service subscribes to power events and suspends/resumes the BT adapter automatically. BLE consumers need no WiFi coexistence awareness.
3-level self-healing
Escalates: L1 software restart → L2 radio power cycle → L3 full micro service restart. When L3 is exhausted the micro service stops petting the watchdog, triggering supervisor recovery.
7-method WifiService
SetMode, GetStatus, GetConnectedStations, StreamEvents, GetConfig, UpdateConfig, ScanNetworks — all typed over the MOS4 transport plane.
Runtime reconfiguration
UpdateConfig reconfigures a running AP without stop/restart. SetMode switches AP↔STA at runtime. No-code configuration via TOML policy.
See No-code engines for TOML-driven connectivity policy.
Bluetooth
Bluetooth — BLE central + peripheral, multi-chip.
All major Bluetooth families
Chip family auto-detected from device tree at startup. Multiple Bluetooth families supported — compute-class integrated and Wi-Fi-family co-processor variants. Classic BT and BLE both available.
Wake-on-BT (Wi-Fi-family co-processor)
On Wi-Fi-family co-processor chips, idle entry switches to an internal BLE mode. A BLE write to the wake characteristic triggers the wake pin; the host receives a wake event on the event bus — no polling required.
BLE peripheral — GATT server
A device acts as a BLE peripheral: it advertises a GATT server and accepts inbound commands, each authenticated with a signed token before it is acted on — and a command can wake the device from low power. Short-range control when no network is in reach.
DHCP
DHCP server and client per interface.
DHCP server and client instances run independently on any number of network interfaces simultaneously — WiFi AP server, upstream Ethernet client, and diagnostic interface on the same device at the same time.
Per-interface role
Assign server or client role independently per interface. WiFi AP interface runs a DHCP server; upstream Ethernet interface runs a client; diagnostic interface serves its own lease pool — all simultaneously.
8 RPC methods
Full typed API surface: start/stop server and client, update server config, query lease state, and stream events — all accessible without shell commands or config file restarts.
Runtime reconfiguration + lease persistence
UpdateServerConfig reconfigures a running DHCP server without stop/restart.
Lease state persists across micro service restarts via the Database Service.
Cloud uplink
Multi-protocol cloud uplink.
The communication gateway selects and routes tracking data to one or more cloud protocols simultaneously. MDI21, MQTT TR50, MQTT Munic, and MQTT generic are all available — per-track routing policies determine which protocol carries each data stream.
MDI21 binary protocol
A compact binary encoding (ASN.1 UPER) minimises payload size on constrained cellular plans. Relative timestamps and compact message IDs compress per-packet headers. Per-field recording policies (OnChange, Periodic, PeriodicOnChange, Manual) tune bandwidth and battery trade-offs. Persistent TCP/TLS connection with automatic retry on disconnect.
MQTT TR50
Production-grade TR50 JSON schema delivery over MQTT to TR50-aware cloud platforms. Configured alongside other protocols via the routing table; acknowledgment is tracked per-protocol so a retry targets only the protocol that has not yet confirmed.
MQTT Munic
Production-grade delivery on the Munic topic schema over MQTT into Munic cloud-platform deployments. Shares the same per-track routing and retry infrastructure as all other protocols.
MQTT generic
Production-grade generic MQTT — any standard MQTT client reaches MOS4 services via the in-process MQTT broker, no SDK adoption required. JSON payloads are transcoded at ingress; a retained service catalogue lets clients discover available services at connect time. See SDK for the developer integration pattern.
Protocols are routed per track ID. A track can fan out to multiple protocols simultaneously; retransmission targets only protocols that have not yet acknowledged. See the full catalog for the communication gateway micro service.
Field-level routing now lets the same fleet send overlapping schemas to different upstreams — for example, raw telemetry to one collector and a trimmed safety subset to a regulator endpoint — without duplicating data. Per-protocol field sets, activity deadlines, and slow-link scaling (down to CAT-M baseline) keep the wire honest under bandwidth pressure.
DNS
Minimal SRV resolver.
A lightweight DNS resolver handles SRV service-locator records (RFC 2782) with A/AAAA address
follow-up. It reads /etc/resolv.conf on every call — so nameserver changes from DHCP renewal or
modem bring-up are picked up without a process restart.
During modem bring-up, before a nameserver is configured, the resolver returns a typed error so callers implement correct retry logic rather than silently failing. The implementation is intentionally minimal — no Unicode internationalisation library required — which keeps the binary footprint low on modem-class hardware.
MQTT bridge
In-process MQTT broker — any standard client reaches MOS4.
An MQTT broker runs in-process — no external process. Transcodes JSON to the typed call format at ingress. Any Python, Go, C, or embedded-C client can call any MOS4 service without adopting the MOS4 SDK or .proto files.
Embedded broker
Runs in-process. No external broker process. No extra infrastructure dependency.
Service discovery
Publishes a retained service catalogue on connect. Clients enumerate available services without out-of-band configuration.
All service-call types
Routes to unary calls, server-streaming calls, and event bus subscriptions. Dual content-type: JSON and typed binary on the same topic namespace. See SDK for client examples.
FAQ
Frequently asked questions
-
Does existing MQTT tooling work with MOS4 services?
Yes. MOS4 embeds an MQTT broker in-process — no external process. It transcodes JSON payloads to the typed format at ingress and routes to any MOS4 service as a unary call, server-streaming call, or event-bus subscription. Any standard MQTT client works without adopting the MOS4 SDK.
-
Which cellular standards are supported?
All major cellular standards — 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M), and NB-IoT — are supported via runtime-loaded vendor libraries. Adding a new cellular module requires a matching vendor library and a config update — no micro service recompilation.
-
How does WiFi backend selection work?
The WiFi micro service reads the device tree at startup and selects the dual-band hostapd path or the 2.4 GHz esp-control path without any compile-time flag. The same binary runs on both hardware variants.
-
Is eSIM supported in sealed enclosures?
Yes. The modem stack implements eUICC profile management (GSMA SGP.22 v2.2 Consumer; GSMA SGP.02 M2M) for eUICC profile download, enable, disable, delete, and recovery. Conditionally compiled — adds no overhead on physical-SIM builds.
-
How does BLE chip detection work?
The Bluetooth micro service auto-detects chip family from the device tree at startup. Multiple Bluetooth families are supported — integrated compute-class chips and Wi-Fi-family co-processor variants — without recompilation.
-
Which MQTT version does the in-process broker use?
The MQTT version is not disclosed publicly. The broker presents a standard MQTT surface — any standard MQTT client connects without SDK adoption.
Bring your fleet connectivity plan.
Engineering will walk through modem selection, WiFi coexistence, cloud uplink protocol selection, and MQTT bridge integration for your target hardware.