Datenbedarf für IoT-Geräte berechnen — der Rechenweg in fünf Schritten

Das tatsächliche Datenvolumen eines IoT-Geräts wird in Beschaffungsgesprächen regelmäßig zu niedrig geschätzt, weil dabei nur die Sensorwerte selbst gezählt werden. Die Frage danach kommt praktisch in jedem solchen Gespräch.

Wie viel ein Gerät tatsächlich braucht, gehört zu den Grundrechnungen der IoT-Kosten und Beschaffung. Dieser Artikel zeigt den Rechenweg in fünf Schritten, vier Beispielrechnungen für typische Meldeprofile und die Zusatzposten, die eine Schätzung im Nachhinein sprengen.

Welche vier Größen den Datenbedarf bestimmen

Vier Größen bestimmen das Monatsvolumen einer IoT-Karte: die Nutzlast je Meldung, die Anzahl der Meldungen pro Tag, der Protokoll-Overhead für Adressierung und Bestätigung sowie eine Reserve für Firmware-Updates und Wiederholungen. Alle vier lassen sich vor der Beschaffung abschätzen. Fehlt eine davon in der Rechnung, ist das Ergebnis systematisch zu niedrig.

Der stärkste Hebel in dieser Rechnung ist die Meldefrequenz: Eine Verdopplung der Meldungen pro Tag verdoppelt näherungsweise das Monatsvolumen, während sich an der Nutzlast selbst meist wenig ändern lässt. Wie sich dieser Hebel im laufenden Betrieb beobachten und begrenzen lässt, zeigt der Artikel Datenverbrauch im IoT-Betrieb überwachen.

Wie viel Overhead auf eine einzelne Meldung kommt

Jede Meldung trägt Adressierungs- und Protokolldaten mit: rund 20 Byte für den IP-Kopf, 8 Byte für UDP und 4 Byte für einen CoAP-Kopf, dazu eine Bestätigung in ähnlicher Größe zurück. Bei einer Nutzlast von 20 Byte kostet eine bestätigte Meldung damit etwa 84 Byte — der Overhead übersteigt die Nutzdaten um mehr als das Dreifache.

Wer statt CoAP auf MQTT über TCP setzt, überträgt mehr Zusatzdaten und braucht zusätzlich einen Verbindungsaufbau — qualitativ ein größerer Posten, auch ohne dass sich das hier in einer allgemeingültigen Zahl fassen lässt. Welcher Funkstandard überhaupt zur Verfügung steht, begrenzt zusätzlich die verfügbare Datenrate — siehe dazu den Vergleich NB-IoT vs. LTE-M.

Der Rechenweg in fünf Schritten

Der Rechenweg braucht keine Spezialkenntnisse: Nutzlast je Meldung bestimmen, Overhead addieren, mit der Anzahl der Meldungen pro Monat multiplizieren, Zusatzposten wie Updates und Wiederholungen aufschlagen und am Ende einen Sicherheitszuschlag setzen. Die fünf Schritte unten führen jeweils eine Beispielzahl mit, damit Sie Ihren eigenen Fall daneben rechnen können.

Beispielrechnungen für vier Meldeprofile

Vier Meldeprofile decken die meisten Anwendungen ab: eine Meldung pro Tag, pro Stunde, pro Minute oder alle zehn Sekunden. Zwischen dem sparsamsten und dem dichtesten Profil liegen fast vier Größenordnungen — von wenigen Kilobyte bis zu mehreren Dutzend Megabyte im Monat. Die Meldefrequenz ist damit der stärkste Hebel der ganzen Rechnung.

Die kleinsten am Markt verkauften Monatspakete liegen bei einigen Megabyte — für einen Zähler mit einer Tagesmeldung ist das um Größenordnungen mehr als nötig. Genau diese Ungleichverteilung zwischen Karten mit unterschiedlichem Meldeprofil ist der Grund, warum Datenpooling überhaupt existiert.

Welche Posten die Rechnung nachträglich sprengen

Vier Posten tauchen in Schätzungen selten auf und wirken im Betrieb umso deutlicher: Firmware-Updates über Mobilfunk, Wiederholungen bei schwacher Abdeckung, Verbindungsaufbau mit Verschlüsselung und die Rundung in der Abrechnung. Besonders bei sehr kleinen Meldungen entscheidet nicht die Nutzlast über die Rechnung, sondern diese vier Posten zusammen — sie lassen sich einzeln abschätzen.

• Firmware-Updates: reine Multiplikation. Ein Update von 500 KB auf 100 Geräte sind 50 MB — bei Zählerprofilen ein Vielfaches des Jahresverbrauchs. Als Rechnung offenlegen, nicht als Fremdzahl behaupten.
• Wiederholungen: jede erneute Übertragung zählt voll.
• Verbindungsaufbau mit Verschlüsselung: überträgt Zertifikate und ist damit um Größenordnungen teurer als eine Messwertmeldung. Wer je Meldung neu verbindet, zahlt den Aufbau jedes Mal — ohne belastbare Zahl dazu, weil keine Primärquelle einen typischen Wert nennt.
• Rundung in der Abrechnung: Bei Meldungen von wenigen Dutzend Byte entscheidet die Rundung über das Ergebnis. Bei SIM4IOT erfolgt die Abrechnung auf 1 KB genau, je Pool bzw. je Service-Profil; je Länderzone oder Roaming-Profil kann eine höhere Rundung gelten. Worauf sich die Rundung bei anderen Anbietern bezieht, steht selten im Preisblatt — das ist eine Frage für das Anbietergespräch, weil sie bei sehr kleinen Meldungen das Ergebnis erheblich verschieben kann.

Beschaffung: welchen Puffer Sie einplanen

Wirtschaftlich zählt nicht die exakte Zahl, sondern die Richtung des Irrtums: Ein zu klein gewähltes Volumen kostet Nachbuchungen und Aufmerksamkeit im Betrieb, ein zu großes bindet Budget über die gesamte Laufzeit. Wer die Rechnung mit einem klar benannten Zuschlag abschließt, kann später begründen, warum genau dieses Volumen bestellt wurde.

Nachbuchen ist ausdrücklich zusatzkostenpflichtig. Suspendierte Karten kosten dagegen nichts — das erlaubt es, Karten schon zu beschaffen und erst bei Inbetriebnahme zu aktivieren, ohne dass bis dahin Kosten entstehen. Bei langen Laufzeiten wächst der Bedarf zudem über die Jahre, weil Protokolle und Updates zunehmen — ein Grund, die Laufzeitentscheidung bewusst zu treffen, wie sie die drei Tarifmodelle im Vergleich gegenüberstellen.

Was Sie mit dem Ergebnis anfangen

Mit einer gerechneten Zahl im Kopf verläuft jedes Anbietergespräch anders: Sie fragen nach einem Volumen statt nach einem Preis, erkennen überdimensionierte Pakete und können Pooling sinnvoll bewerten. Für den Zuschnitt selbst bleibt ein Gespräch nötig, weil Netzverfügbarkeit am Standort und Rundungsregeln nicht auf einer Seite stehen können.

Sie haben Ihren Bedarf gerechnet und möchten wissen, welches Volumen und welcher Tarif dazu passen? Nennen Sie uns Kartenmenge und Meldeprofil — wir rechnen Ihren Fall gegen und sagen auch, wenn ein kleineres Paket genügt.