SMS-Durchsatz und TPS-Planung: Dimensionierung von SMPP-Bindungen für Kampagnen mit hohem Volumen.

TPS (Transaktionen pro Sekunde) bezeichnet die Anzahl der SMS-Übermittlungsvorgänge, die Ihre Plattform pro Sekunde durchführt. Über SMPP wird der nachhaltige Durchsatz durch das Sitzungsfenster – die Anzahl der noch nicht bestätigten PDUs während der Übertragung – geteilt durch die Round-Trip-Latenz zum SMSC bestimmt: Durchsatz ≈ Fenster ÷ RTT. Um die Kapazität einer einzelnen Sitzung zu überschreiten, führen Sie mehrere parallele Bindungen durch.

Was bedeutet TPS in SMS?

TPS (Transaktionen pro Sekunde, synonym mit Nachrichten pro Sekunde im A2P-Messaging verwendet) misst, wie viele Nachrichtenübermittlungsvorgänge pro Sekunde Ihr System verlassen und nachgelagert empfangen werden. Im SMPP-Kontext entspricht eine Transaktion einer submit_sm-PDU, die vom SMSC mit einer submit_sm_resp bestätigt wird. TPS ist die Einheit, in der alle Verträge, Ratenbegrenzungen und Kapazitätspläne definiert sind. Daher ist die genaue Definition wichtig: Gezählt werden Übermittlungen, die zur Zustellung angenommen werden, nicht die bestätigten Zustellungen an ein Endgerät – dies ist ein separater Zustellungs- und Empfangsbestätigungsprozess (DLR), der später als deliver_sm-PDUs eintrifft.

Die Unterscheidung zwischen Sende- und Zustellungsrate ist der häufigste Fehler bei Kapazitätsplanungen. Sie können beispielsweise 5.000 Transaktionen pro Sekunde (TPS) senden, während ein nachgelagerter Betreiber nur 2.000 Transaktionen pro Sekunde verarbeitet; die Differenz füllt irgendwo eine Warteschlange. Durchsatzplanung bedeutet die Planung der gesamten Kette – Ihres Clients, der SMPP-Sitzung zur Plattform, der Route der Plattform zum terminierenden SMSC-Gateway und der A2P-Ratenbegrenzung dieses Betreibers.

Wie der SMPP-Durchsatz tatsächlich funktioniert: Fenster und Latenz

SMPP ist ein persistentes, zustandsbehaftetes TCP-Protokoll. Es wird einmalig gebunden und PDUs werden über Stunden in beide Richtungen übertragen. Der Durchsatz bei einer einzelnen Bindung wird nicht durch die Bandbreite bestimmt – SMS-PDUs sind winzig –, sondern durch zwei Variablen: das asynchrone Fenster und die Round-Trip-Zeit.

Das Zeitfenster gibt die maximale Anzahl an submit_sm-PDUs an, die Sie senden können, bevor Sie auf eine submit_sm_resp-Antwort warten müssen. Im synchronen Modus beträgt das Zeitfenster effektiv 1: Sie senden eine Anfrage, warten auf die Antwort und senden dann erneut – ein einziger langsamer Roundtrip drosselt also alles. Im asynchronen (fensterbasierten) Modus können Sie bis zu N Anfragen ohne Blockierung senden, und die Antworten fließen gleichzeitig zurück. Dieses N ist die Zeitfenstergröße, die pro Bindung mit der Plattform ausgehandelt wird.

Da ein Bind höchstens „window“ PDUs im Status „ausstehend“ haben kann und jede PDU die Leitung für eine Round-Trip-Time (RTT) belegt, bevor ihr Slot wieder freigegeben wird, ist die maximale Anzahl an PDUs pro Bind einfach das Fenster geteilt durch die RTT:

1# Maximaler SMPP-Durchsatz bei einer einzelnen Bindung
2tps_per_bind = Fenstergröße / rtt_Sekunden
3 
4# Fenster mit 10 nicht bestätigten PDUs, 100 ms Roundtrip zum SMSC:
5tps_per_bind = 10 / 0,100 = 100 submit_sm/s
6 
7# Gleiches Fenster, Latenz halbiert auf 50 ms:
8tps_per_bind = 10 / 0,050 = 200 submit_sm/s
9 
10# Horizontale Skalierung über N parallele Bindungen:
11total_tps = tps_per_bind * n_binds
12 
13= 200 * 4 = 800 submit_sm/s

Daraus ergeben sich zwei Hebel. Ein größeres Zeitfenster führt dazu, dass mehr PDUs pro Roundtrip übertragen werden. Eine kürzere Roundtrip-Zeit (RTT) – beispielsweise durch die Platzierung des Clients in der Nähe des Plattform-Ingestionspunkts oder durch den Verzicht auf TLS-Handshakes pro Anfrage (was durch eine persistente SMPP-Bindung gegenüber HTTP-Anfragen pro Aufruf erreicht wird) – beschleunigt die Wiederverwendung der einzelnen Zeitschlitze. Ein zu kleines Zeitfenster beeinträchtigt die Latenz einer Verbindung mit niedriger Latenz; ein zu großes Zeitfenster puffert PDUs, die der SMSC noch nicht verarbeiten kann, und erhöht die Latenz ohne zusätzlichen Durchsatz.

Beispielrechnung: Fenster und RTT zu TPS, dann mehrere Bindungen

Angenommen, Ihr Client befindet sich in derselben Region wie die Plattform und misst unter Last eine Round-Trip-Time (RTT) von 80 ms. Mit einem ausgehandelten Fenster von 50 ms erreicht eine einzelne Bindung 50 ÷ 0,080 ≈ 625 Transaktionen pro Sekunde (TPS). Das ist für die meisten Absender bereits ausreichend. Wenn Ihre Spitzenlast höher ist, versuchen Sie nicht, ein immer größeres Fenster zu erreichen – ab einem gewissen Punkt führt dies nur noch zu einer Warteschlange –, sondern Sie fügen weitere Bindungen hinzu. Vier Bindungen mit jeweils 625 TPS ergeben insgesamt etwa 2.500 TPS; die Plattform verteilt die Anfragen gleichmäßig auf die Sitzungen.

Die unterste Zeile liegt nahe der von BroadNet im Netzwerk bereitgestellten maximalen Dauerleistung von bis zu 30.000 SMS/Sekunde pro Knoten – erreicht nicht durch einen einzigen, extremen Bind-Vorgang, sondern durch ein moderates Zeitfenster, geringe Latenz und horizontale Bind-Vorgänge. Modellieren Sie Ihre eigene Kombination im TPS-Rechner, bevor Sie sich für einen Vertragspreis entscheiden, da die Berechnung bestimmt, wie viele Bind-Vorgänge Ihr Betriebsteam durchführen und überwachen muss.

Bereitgestellte Transaktionsverarbeitungskapazität im Vergleich zur Rohkapazität

Es gibt zwei Durchsatzwerte, die nicht identisch sind. Die Rohkapazität gibt an, wie viel Ihre Verbindungen laut der obigen Berechnung von Fenster und Latenz maximal leisten können. Die vertraglich vereinbarte Transaktionsrate (TPS) ist die Rate, mit der Ihr Konto Anfragen senden darf – eine von der Plattform festgelegte Grenze, die verhindern soll, dass ein einzelner Kunde eine gemeinsam genutzte Route blockiert oder die Missbrauchskontrollen eines Betreibers auslöst. Wenn Ihr Vertrag 500 TPS vorsieht, erreichen Sie durch das Öffnen von zehn breiten Verbindungen nicht 5.000 TPS; die Plattform regelt die Übertragungsrate auf den vertraglich vereinbarten Wert und gibt bei darüber hinausgehenden Datenmengen Drosselungsmeldungen (ESME_RTHROTTLED) zurück.

Die Dimensionierung von Binds hat zwei Aufgaben: Sie muss genügend vertraglich vereinbarte TPS für Ihre tatsächliche Spitzenlast bereitstellen und genügend Binds und Fenster konfigurieren, um diese bereitgestellte Anzahl angesichts Ihrer Latenz auch tatsächlich zu erreichen. Bei zu geringer Bereitstellung wird Ihre Leistung gedrosselt; bei zu vielen Binds für ein niedriges Vertragsvolumen verschwenden Sie Betriebsressourcen. Dimensionieren Sie den Vertrag zuerst anhand der Spitzenlast und passen Sie die Binds dann entsprechend an.

Was Ihren tatsächlichen Durchsatz beeinträchtigt

Die Formel liefert eine klare Obergrenze. Vier reale Faktoren drücken den tatsächlichen Durchsatz darunter, und jede Kapazitätsplanung sollte diese Faktoren berücksichtigen:

• Segmentierung. Eine Nachricht, die länger als ein SMS-Segment ist, wird aufgeteilt und als mehrere submit_sm PDUs – eine verkettete (UDH-)Nachricht – versendet. Eine 480 Zeichen lange GSM-7-Marketingnachricht besteht aus drei Segmenten und verbraucht daher drei Transaktionen Ihres TPS-Budgets, nicht nur eine. UCS-2 (Arabisch, Emojis) reduziert die Zeichenbegrenzung für ein einzelnes Segment auf 70 Zeichen, wodurch Kampagnen mit nicht-lateinischen Sprachen ihr TPS-Budget schneller verbrauchen. Planen Sie daher Segmente, nicht Nachrichten.
• Warteschlangenbildung und Gegendruck. Wenn Sie Daten schneller senden, als ein nachgelagerter Operator sie abschließt, werden PDUs in eine Warteschlange gestellt. Eine intakte Plattform wendet Gegendruck an – durch Drosselung der Antworten oder Verkleinerung des effektiven Zeitfensters – anstatt Daten stillschweigend zu verwerfen. Behandeln Sie ESME_RTHROTTLED und steigende Antwortlatenz als Signale, die Übermittlungsschleife zu verlangsamen, und nicht als Fehler, die blindlings zu Wiederholungsversuchen führen.
• Die Datenratenbegrenzungen der einzelnen Routenbetreiber werden individuell festgelegt. Der Zielbetreiber legt seine eigene A2P-Transaktionsgeschwindigkeitsbegrenzung (TPS) pro Absender oder pro Bindung fest, unabhängig von Ihrem Vertrag. Sie können zwar 5.000 TPS senden, aber wenn das Zielnetzwerk für Ihre Absender-ID nur 1.000 akzeptiert, wird die tatsächliche Zustellung auf 1.000 begrenzt, der Rest wird in eine Warteschlange gestellt. Die tatsächliche Durchsatzrate wird häufig durch die Routenbegrenzungen und nicht durch Ihre Bindung bestimmt.
• Dauerhaft versus Spitzenlast. Ein für die durchschnittliche Last dimensioniertes Fenster kann eine Lastspitze nicht auffangen. OTP-Datenverkehr ist naturgemäß spitzenbesetzt – eine Produkteinführung oder eine Rundfunkmeldung löst innerhalb von Sekunden eine Flut von Verifizierungscodes aus – daher sollte die Dimensionierung auf die Spitzenlast und nicht auf den Tagesmittelwert ausgelegt sein.

Spitzenwert versus Dauerleistung: Dimensionierung von OTP-Bursts

Die kontinuierliche Transaktionsrate (TPS) ist Ihre konstante Rate; die maximale TPS ist die kritische Sekunde, die Sie ohne verspätete Codezustellung überstehen müssen. Bei Einmalpasswörtern (OTP) ist die maximale TPS entscheidend – ein Bestätigungscode, der erst eintrifft, nachdem der Nutzer aufgegeben hat, gilt als fehlgeschlagen, selbst wenn er letztendlich zugestellt wird. OTP-Zustellungen erfolgen sprunghaft und korreliert: Eine Marketingkampagne, ein Blitzverkauf oder eine regionale Veranstaltung im Golf-Kooperationsrat (GCC) während des Ramadan oder eines nationalen Feiertags können die Anmeldungen innerhalb weniger Minuten konzentrieren. Die Größe des Systems bindet die TPS an diese maximale TPS mit ausreichendem Puffer und ermöglicht es der gemeinsam genutzten Plattform, den Überlauf durch Warteschlangen aufzufangen, anstatt Transaktionen zu verwerfen.

Hier zeigt sich auch der höhere Betriebsaufwand von SMPP gegenüber HTTP. Durch eine persistente Verbindung wird der TLS-Handshake pro Anfrage aus dem kritischen Pfad entfernt, sodass die Latenz auch bei steigendem Datenvolumen konstant bleibt – eine wünschenswerte Eigenschaft bei Lastspitzen. Teams, die dieses Profil nicht benötigen, sind mit der SMS API über HTTPS oft besser bedient; der Kompromiss besteht in der geringeren Durchsatzkapazität und Latenzstabilität gegenüber der einfacheren Integration.

Häufig gestellte Fragen

Was ist TPS in SMS?

TPS bedeutet Transaktionen pro Sekunde – die Anzahl der SMS-Übermittlungsvorgänge, die Ihre Plattform pro Sekunde verarbeitet. Im A2P-Messaging wird dieser Wert synonym mit Nachrichten pro Sekunde verwendet. In SMPP entspricht eine Transaktion einer submit_sm-PDU, die von einer submit_sm_resp bestätigt wird. TPS zählt die zur Zustellung angenommenen Übermittlungen, nicht die auf einem Endgerät bestätigten Nachrichten. Letztere werden separat über Zustellbestätigungen in Form von deliver_sm-PDUs erfasst.

Wie viele SMS pro Sekunde kann SMPP versenden?

Es gibt keine allgemeingültige Zahl; ein einzelner SMPP-Bind verarbeitet Nachrichten pro Sekunde (TPS) im Verhältnis Fenstergröße ÷ RTT. Ein Fenster von 50 Nachrichten bei einer Roundtrip-Zeit von 80 ms ergibt etwa 625 TPS pro Bindung. Durch die parallele Ausführung mehrerer Bindungen lässt sich dieser Wert weiter steigern – bis in den Tausenderbereich. Der tatsächliche Durchsatz ist dann durch die vertraglich vereinbarte TPS und die jeweilige A2P-Ratenbegrenzung des jeweiligen Zielnetzbetreibers begrenzt, je nachdem, welcher Wert niedriger ist.

Wie dimensioniere ich SMPP-Bindungen und -Fenster für Spitzenlasten?

Beginnen Sie mit Ihrem maximalen TPS, nicht mit dem Durchschnittswert. Teilen Sie diesen durch die maximale Anzahl an Bindungen (Fenster ÷ RTT), um die Anzahl der Bindungen zu ermitteln. Stellen Sie anschließend vertraglich vereinbarte TPS bereit, die den Spitzenwert mit ausreichender Reserve abdecken. Zählen Sie Segmente statt Nachrichten – Multipart- und UCS-2-Nachrichten benötigen zusätzliche Transaktionen – und berücksichtigen Sie mögliche OTP-Spitzen. Modellieren Sie die Kombination vor der Festlegung in einem TPS-Rechner und führen Sie anschließend einen Lasttest durch.

Referenzen

• SMPP v3.4 Protokollspezifikation – asynchrone Übertragung, Fenstergröße und PDU-Semantik: smpp.org
• SMPP v5.0 Protokollspezifikation – Stauzustand und Drosselungsverhalten: smpp.org
• GSMA — IR.71 SMS Network-to-Network Interconnect und A2P-Framework: gsma.com
• BroadNet — SMPP-Integrationsleitfaden und der TPS-Rechner zur Bestimmung der Bindungsgröße.