Plattform · Konnektivität
Vom Modem zur Cloud, durchgehend typisiert.
Alle wichtigen Modems 2G–5G + LPWA, Dual-Band-WiFi-Backend zur Laufzeit erkannt, BLE-Central-Rolle, DHCP-Server und -Client pro Schnittstelle, Multi-Protokoll-Cloud-Uplink und ein minimaler SRV-DNS-Resolver — jede Schicht typisiert, beobachtbar und konfigurationsgesteuert.
Kennzahlen
Die Zahlen, die den Stack dimensionieren.
Cellular
Alle wichtigen Modems — Fähigkeit zuerst.
Alle wichtigen Modem-Varianten, 2G → 5G + LPWA
Der Modem-Stack lädt Vendor-Bibliotheken zur Laufzeit. Die Abdeckung umfasst 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M) und NB-IoT — IPv4 und IPv6. Ein neues Mobilfunk-Modul hinzufügen ist ein Bibliotheks-Tausch plus ein Config-Update — keine micro service-Neukompilierung.
eUICC Consumer + eUICC M2M in versiegelten Gehäusen
GSMA SGP.22 v2.2 eUICC-Profilverwaltung: Download, Aktivierung, Deaktivierung, Löschung und Wiederherstellung — ohne einen separaten eUICC-Verwaltungs-micro service. Bedingt kompiliert — fügt keinen Overhead bei Physical-SIM-Builds hinzu. Dasselbe Binary wird an beide Hardware-Varianten ausgeliefert.
IP-Routing und NAT
IP-Routing, NAT/MASQUERADE und IP-Forwarding werden vom Modem-micro service über RoutingService verwaltet — kein separater micro service.
Software-definiertes Wärmemanagement
Für Module ohne Firmware-Ebene-Thermalzonen: Host-seitiges Polling mit gestuften Aktionen: Protokollieren → MTU-Reduzierung → Radio aus → Herunterfahren.
WiFi
WiFi — Dual-Backend, ein Binary.
Der WiFi-micro service liest den Device-Tree beim Start und wählt das Backend ohne
Compile-Time-Flag aus. AP- und STA-Modi wechseln zur Laufzeit über SetMode .
| Backend | Modi | Frequenzbänder | ScanNetworks |
|---|---|---|---|
| AP+STA Dual-Band | AP + STA | 2,4 GHz + 5 GHz | Ja |
| AP+STA 2,4 GHz | AP + STA | 2,4 GHz | Nicht unterstützt |
Auf Plattformen, auf denen WiFi und BT eine Radio-Stromschiene teilen, abonniert der Bluetooth-micro service Stromzustandsereignisse und suspendiert/reaktiviert den BT-Adapter automatisch. BLE-Verbraucher benötigen kein WiFi-Koexistenz-Bewusstsein.
3-stufiges Self-Healing
Eskaliert: L1 Software-Neustart → L2 rfkill-Radio-Zyklus → L3 vollständiger micro service-Neustart. Wenn L3 erschöpft ist, hört der micro service auf, den MOS-Watchdog zu petten und löst Supervisor-Wiederherstellung aus.
7-Methoden-WifiService
SetMode, GetStatus, GetConnectedStations, StreamEvents, GetConfig, UpdateConfig, ScanNetworks — alle typisiert über die MOS4-Transport-Ebene.
Laufzeit-Rekonfiguration
UpdateConfig rekonfiguriert einen laufenden AP ohne Stop/Neustart. SetMode wechselt AP↔STA zur Laufzeit. No-Code-Konfiguration via TOML-Policy.
Siehe No-Code-Engines für TOML-gesteuerte Konnektivitäts-Policy.
Bluetooth
Bluetooth — BLE-Central-Rolle, Multi-Chip.
Alle wichtigen Bluetooth-Familien
Chip-Familie automatisch aus Device-Tree beim Start erkannt. Mehrere Bluetooth-Familien unterstützt — Compute-Class-integriert und Wi-Fi-Family-Coprozessor-Varianten. Classic BT und BLE beide verfügbar.
Wake-on-BT (Wi-Fi-Family-Coprozessor)
Auf Wi-Fi-Family-Coprozessor-Chips wechselt Leerlauf-Eintritt zu einem internen BLE-Modus. Ein BLE-Write auf das Wake-Characteristic löst den Wake-Pin aus; der Host empfängt ein Wake-Ereignis auf dem Event-Bus — kein Polling erforderlich.
DHCP
DHCP-Server und -Client pro Schnittstelle.
DHCP-Server- und -Client-Instanzen laufen unabhängig auf beliebig vielen Netzwerk-Schnittstellen gleichzeitig — WiFi-AP-Server, Upstream-Ethernet-Client und Diagnose-Schnittstelle auf demselben Gerät zur gleichen Zeit.
Pro-Schnittstellen-Rolle
Server- oder Client-Rolle unabhängig pro Schnittstelle zuweisen. WiFi-AP-Schnittstelle führt einen DHCP-Server aus; Upstream-Ethernet-Schnittstelle führt einen Client aus; Diagnose-Schnittstelle bedient ihren eigenen Lease-Pool — alles gleichzeitig.
8 RPC-Methoden
Vollständige typisierte API-Oberfläche: Server und Client starten/stoppen, Server-Config aktualisieren, Lease-Zustand abfragen und Ereignisse streamen — alles ohne Shell-Befehle oder Config-Datei-Neustarts zugänglich.
Laufzeit-Rekonfiguration + Lease-Persistenz
UpdateServerConfig rekonfiguriert einen laufenden DHCP-Server ohne Stop/Neustart.
Lease-Zustand persistiert über micro service-Neustarts über den Datenbankdienst.
Cloud-Uplink
Multi-Protokoll-Cloud-Uplink.
Das Kommunikations-Gateway wählt und leitet Tracking-Daten an ein oder mehrere Cloud-Protokolle gleichzeitig weiter. MDI21, MQTT TR50, MQTT Munic und MQTT generisch sind alle verfügbar — Pro-Track-Routing-Richtlinien bestimmen, welches Protokoll welchen Datenstrom trägt.
MDI21-Binärprotokoll
ASN.1-UPER-Codierung minimiert die Payload-Größe bei eingeschränkten Mobilfunktarifen. Relative Zeitstempel und kompakte Nachrichten-IDs komprimieren Pro-Paket-Header. Pro-Feld-Aufzeichnungs-Richtlinien (OnChange, Periodic, PeriodicOnChange, Manual) justieren Bandbreiten- und Batterie-Trade-offs. Persistentes TCP/TLS mit PDM-gestütztem Retry bei Verbindungsunterbrechung.
MQTT TR50
Produktionsgradige TR50-JSON-Schema-Zustellung über MQTT zu TR50-fähigen Cloud-Plattformen. Zusammen mit anderen Protokollen über die Routing-Tabelle konfiguriert; Bestätigung wird Pro-Protokoll verfolgt, sodass ein Retry nur das Protokoll anvisiert, das noch nicht bestätigt hat.
MQTT Munic
Produktionsgradige Zustellung auf dem Munic-Topic-Schema über MQTT in Munic-Cloud-Plattform-Deployments. Teilt dieselbe Pro-Track-Routing- und Retry-Infrastruktur wie alle anderen Protokolle.
MQTT generisch
Produktionsgradiges generisches MQTT — jeder Standard-MQTT-Client erreicht MOS4-Services über den In-Prozess-MQTT-Broker, keine SDK-Adoption erforderlich. JSON-Payloads werden am Eingang transcodiert; ein retained Service-Katalog ermöglicht Clients, verfügbare Services zur Verbindungszeit zu entdecken. Siehe SDK für das Entwickler-Integrations-Muster.
Protokolle werden pro Track-ID geroutet. Ein Track kann gleichzeitig auf mehrere Protokolle aufgefächert werden; Wiederübertragung zielt nur auf Protokolle, die noch nicht bestätigt haben. Siehe den vollständigen Katalog für den Kommunikations-Gateway-micro service.
DNS
Minimaler SRV-Resolver.
Ein leichtgewichtiger DNS-Resolver verarbeitet SRV-Einträge (RFC 2782) mit A/AAAA-Follow-up.
Er liest /etc/resolv.conf bei jedem Aufruf — sodass Nameserver-Änderungen aus
DHCP-Erneuerung oder Modem-Bring-up ohne Prozess-Neustart aufgegriffen werden.
Während des Modem-Bring-ups, bevor ein Nameserver konfiguriert ist, gibt der Resolver einen typisierten Fehler zurück, sodass Aufrufer korrekte Retry-Logik implementieren, anstatt still zu scheitern. Die Implementierung ist absichtlich minimal — keine ICU/IDNA-Abhängigkeit — was den binären Footprint auf Modem-Class-Hardware niedrig hält.
MQTT-Bridge
In-Prozess-MQTT-Broker — jeder Standard-Client erreicht MOS4.
Ein MQTT-Broker läuft In-Prozess — kein externer Prozess. Transcodiert JSON zum typisierten Aufruf-Format am Eingang. Jeder Python-, Go-, C- oder Embedded-C-Client kann jeden MOS4-Service aufrufen, ohne das MOS4-SDK oder .proto-Dateien zu adoptieren.
Eingebetteter Broker
Läuft In-Prozess. Kein externer Broker-Prozess. Keine zusätzliche Infrastruktur-Abhängigkeit.
Service-Entdeckung
Veröffentlicht einen retained Service-Katalog bei Verbindung. Clients zählen verfügbare Services ohne Out-of-band-Konfiguration auf.
Alle Service-Aufruf-Typen
Leitet zu unären Aufrufen, Server-Streaming-Aufrufen und Event-Bus-Abonnements weiter. Dualer Content-Type: JSON und typisiertes Binary auf demselben Topic-Namespace. Siehe SDK für Client-Beispiele.
FAQ
Häufig gestellte Fragen
-
Funktioniert bestehendes MQTT-Tooling mit MOS4-Services?
Ja. MOS4 bettet einen MQTT-Broker In-Prozess ein — kein externer Prozess. Er transcodiert JSON-Payloads zum typisierten Format am Eingang und leitet zu jedem MOS4-Service als unären Aufruf, Server-Streaming-Aufruf oder EventBus-Abonnement weiter. Jeder Standard-MQTT-Client funktioniert ohne MOS4-SDK-Adoption.
-
Welche Mobilfunk-Standards werden unterstützt?
Alle wichtigen Mobilfunk-Standards — 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M) und NB-IoT — werden über zur Laufzeit geladene Vendor-Bibliotheken unterstützt. Ein neues Mobilfunk-Modul hinzufügen erfordert eine passende Vendor-Bibliothek und ein Config-Update — keine micro service-Neukompilierung.
-
Wie funktioniert die WiFi-Backend-Auswahl?
Der WiFi-micro service liest den Device-Tree beim Start und wählt den Dual-Band-hostapd-Pfad oder den 2,4-GHz-esp-control-Pfad ohne Compile-Time-Flag aus. Dasselbe Binary läuft auf beiden Hardware-Varianten.
-
Wird eSIM in versiegelten Gehäusen unterstützt?
Ja. Der Modem-Stack implementiert eUICC-Profilverwaltung (GSMA SGP.22 v2.2 Consumer; GSMA SGP.02 M2M) für eUICC-Profil-Download, Aktivierung, Deaktivierung, Löschung und Wiederherstellung. Bedingt kompiliert — fügt keinen Overhead bei Physical-SIM-Builds hinzu.
-
Wie funktioniert BLE-Chip-Erkennung?
Der Bluetooth-micro service erkennt die Chip-Familie automatisch aus dem Device-Tree beim Start. Mehrere Bluetooth-Familien werden unterstützt — integrierte Compute-Class-Chips und Wi-Fi-Family-Coprozessor-Varianten — ohne Neukompilierung.
-
Welche MQTT-Version verwendet der In-Prozess-Broker?
Die MQTT-Version wird nicht öffentlich bekannt gegeben. Der Broker bietet eine Standard-MQTT-Oberfläche — jeder Standard-MQTT-Client verbindet sich ohne SDK-Adoption.
Bringen Sie Ihren Flotten-Konnektivitätsplan.
Das Engineering-Team erläutert Modem-Auswahl, WiFi-Koexistenz, Cloud-Uplink-Protokoll-Auswahl und MQTT-Bridge-Integration für Ihre Zielhardware.