TPS, Warteschlangen und Kapazität für A2P-SMS-Verkehrsspitzen dimensionieren
Operativer Leitfaden zur Berechnung von TPS, Dimensionierung von Warteschlangen, Trennung von Prioritäten und Prüfung der A2P-SMS-Versandkapazität, ohne Annahme, DLR und endgültigen Empfang zu verwechseln.
Die operative Frage: Wie viele TPS benötigt ein A2P-SMS-Betrieb tatsächlich?
TPS zu dimensionieren bedeutet nicht, eine einzige Zahl für die gesamte Plattform auszuwählen. Die hilfreiche Frage lautet: Wie viele Nachrichten müssen innerhalb eines bestimmten Betriebszeitfensters für eine konkrete Mischung aus Zieladressen und Verkehrsklassen angenommen, verarbeitet und versendet werden?
Die erforderlichen TPS sollten aus dem erwarteten Volumen und dem Zielzeitfenster abgeleitet werden. Als Ausgangspunkt gilt: Basis-TPS = erwartete Nachrichten / Sekunden des Zeitfensters. Diese Formel dient der Planung und stellt keine Kapazitätsgarantie einer HTTP-API, einer SMPP-Session, eines Anbieters, einer Route oder eines Mobilfunknetzes dar.
Die resultierende Zahl sollte zusammen mit ihren Annahmen dokumentiert werden: zeitliche Verteilung, Zielmix, Verkehrspriorität, Wiederholungsrichtlinie, Ablaufzeiten und bestätigte Limits für jede Verbindung oder Route. Ohne diese Annahmen kann ein aggregierter TPS-Wert einen relevanten Engpass verdecken.
- Definieren Sie, was „innerhalb des Zeitfensters“ bedeutet: interne Annahme, Annahme durch den Anbieter oder gemeldeter Endstatus.
- Berechnen Sie nach Verkehrsklasse und Zieladresse, nicht nur für die Gesamtsumme.
- Behandeln Sie den Puffer als explizite Entscheidung für Bursts, Wiederholungen und Routenschwankungen, nicht als implizite Garantie.
- Validieren Sie die effektiven Grenzen mit dem Anbieter oder Betreiber, der die jeweilige Kapazität verwaltet.
Die Spitze definieren: Volumen, Zeitfenster, zeitliche Verteilung und Zieladressen
Das tägliche oder monatliche Volumen dimensioniert keine Spitze. Zwei Betriebe mit demselben Volumen können sehr unterschiedliche Kapazitäten benötigen, wenn der eine Versand über Stunden verteilt und der andere ihn in Minuten durchführen muss. Die Analyseeinheit sollte das zeitliche Profil des Ereignisses sein, vorzugsweise pro Minute und, wenn der Anwendungsfall es erfordert, pro Sekunde.
Ebenso wichtig ist die Trennung der Zieladressen. Ein auf ein Land, ein Netz, einen Nummernbereich, einen Absender oder eine Route konzentriertes Volumen kann Grenzen erreichen, bevor die Gesamtplattform dies tut. Zielnummern sollten mit einer Normalisierung verwaltet werden, die mit dem internationalen E.164-Nummerierungsplan und den für die Integration geltenden Adressierungsregeln übereinstimmt.
Authentifizierungsspitzen sind häufig an gleichzeitige Nutzeraktionen oder Zugriffsereignisse gekoppelt. Kampagnen können auf einen bestimmten Startzeitpunkt synchronisiert sein. Beide Fälle erfordern ein realistisches Ankunftsprofil und keinen Tagesdurchschnitt.
- Erwartete Nachrichten pro Zeitintervall.
- Zielzeitfenster je Verkehrsklasse.
- Verteilung nach Land, Netz, Route und Absender.
- Erwarteter Anteil von OTP, Transaktionsverkehr und Kampagnen.
- Ereignisse, die Bursts verursachen können: Öffnungen, Einführungen, Wiederherstellung des Zugriffs oder Batch-Prozesse.
- Geplante Wiederholungen und die Bedingungen, die sie auslösen.
Vier Kapazitätsgrenzen unterscheiden
Eine Annahmeantwort der Schnittstelle belegt nicht, dass die Nachricht den Weg zum Empfänger abgeschlossen hat. Für einen präzisen Betrieb sollten mindestens vier Stufen getrennt werden: Annahme durch HTTP-API oder SMPP, interne Verarbeitung und Warteschlange, Annahme oder Verarbeitung durch den Anbieter sowie der von der SMS-Kette gemeldete Endstatus.
Bei SMPP spiegeln submit_sm und submit_sm_resp den Austausch zwischen ESME und SMSC wider. Das spätere Ergebnis kann über eine SMSC Delivery Receipt mitgeteilt werden, wenn diese angefordert wurde. TPS angenommener submit_sm dürfen daher weder als zugestellte TPS noch als Nachweis des Empfangs auf dem Endgerät dargestellt werden.
Diese Trennung verbessert auch die Diagnose. Bleibt die lokale Annahme stabil, während die interne Warteschlange wächst, liegt die Grenze vor dem Ausgang. Steigen ausstehende Anfragen oder verschlechtern sich Antworten, kann das Problem in der Verbindung oder beim entfernten Endpunkt liegen. Ändert sich der Endstatus je Zieladresse, muss die Auswertung nach Route und Netz erfolgen, nicht nur als globaler Durchschnitt.
- Annahmelimit: Anfragen, die von der Schnittstelle akzeptiert werden.
- Verarbeitungslimit: Kapazität zum Validieren, Einreihen, Priorisieren und Weiterleiten.
- Anbieter- oder Routenlimit: bestätigte technische und vertragliche Kapazität je Zieladresse.
- Netzverhalten: Endstatus und Zeiten, die entlang der Zustellkette variieren können.
Basis-TPS und dokumentierter Puffer berechnen
Die erste Berechnung ist einfach: Teilen Sie die Anzahl der Nachrichten, die verarbeitet werden müssen, durch die verfügbaren Sekunden. Muss ein Betrieb beispielsweise ein Paket innerhalb eines bestimmten Zeitfensters annehmen und weiterleiten, stellt die Basis-TPS die für dieses Zeitfenster erforderliche durchschnittliche Mindestrate dar. Vergleichen Sie diese Rate anschließend mit dem zeitlichen Profil: Konzentriert sich der Eingang auf den Beginn, kann die Eingangsrate den Durchschnitt deutlich übersteigen.
Der Puffer sollte nicht als universelle Zahl gewählt werden. Er sollte einer konkreten Annahme entsprechen: einem anfänglichen Burst, einer Session-Wiederherstellung, einem vorübergehenden Anstieg der Anfragen, einer Verschiebung im Zielmix oder kontrollierten Wiederholungen. Es ist besser, mehrere Szenarien – erwartet, hoch und Notfall – festzuhalten, als alle Risiken unter einem einzigen Multiplikator zu verbergen.
Die Berechnung sollte für jede operative Partition wiederholt werden. Eine Plattform kann über ausreichende aggregierte Kapazität verfügen und dennoch nicht die erforderliche Kapazität für eine bestimmte Zieladresse oder Route bereitstellen.
- Basis-TPS = erwartete Nachrichten / Sekunden des Zeitfensters.
- Berechnen Sie Eingangs-TPS und Ausgangs-TPS getrennt.
- Fügen Sie einen Puffer nur mit einer identifizierten operativen Ursache hinzu.
- Vergleichen Sie das Ergebnis mit Limits je Route, Zieladresse, Verbindung und Verkehrsklasse.
- Überprüfen Sie die Berechnung, wenn sich Zielprofil, Zeitfenster oder Wiederholungsrichtlinie ändern.
Warum der Durchschnitt irreführt
Ein Durchschnitt glättet genau das Verhalten, das Störungen verursacht. Treffen Tausende Anfragen gleichzeitig ein, erklärt eine durchschnittliche Tagesrate weder die erforderliche Warteschlangentiefe noch das Alter, das Nachrichten erreichen werden. Das Design muss in jedem Intervall die Differenz zwischen Ankunftsrate und nachhaltiger Ausgangsrate berücksichtigen.
Auch die Konzentration nach Zieladresse ist relevant. Der Versand an mehrere Zieladressen ist nicht gleichbedeutend mit dem Versand desselben Volumens an ein einziges Netz. Konkrete Limits sind weder durch SMPP noch durch HTTP standardisiert: Sie müssen über die anwendbare Dokumentation, betriebliche Vereinbarungen und die Beobachtung der tatsächlichen Route bekannt sein.
Bei OTP kann zudem eine lange Wartezeit eine technisch noch verarbeitbare Nachricht nutzlos machen. Daher wird eine Spitze nicht allein durch Vergrößern der Warteschlange bewältigt; es muss entschieden werden, welcher Verkehr angenommen, welcher verzögert und welcher kontrolliert ablaufen soll.
- Analysieren Sie Maxima pro Sekunde oder Minute, nicht nur Durchschnitte.
- Messen Sie die Konzentration nach Zieladresse, Route, Absender und Nachrichtentyp.
- Modellieren Sie den anfänglichen Eingang von Kampagnen und Authentifizierungsereignissen.
- Definieren Sie den Zeitpunkt, ab dem jede Nachrichtenklasse ihren Nutzen verliert.
Warteschlangen dimensionieren: Tiefe, Alter und Ablauf
Die erforderliche Warteschlangentiefe hängt vom zeitweisen Überschuss des Eingangs gegenüber der nachhaltigen Ausgangsrate ab. Eine operative Näherung besteht darin, während der Spitze die maximale Aufsummierung der Differenz zwischen Ankunftsrate und Bedienrate zu berechnen. Treffen mehr Nachrichten ein, als versendet werden können, sammelt sich die Differenz an; übersteigt der Ausgang später wieder den Eingang, wird die Warteschlange abgebaut.
Die Tiefe allein reicht nicht aus. Legen Sie ein maximal zulässiges Alter je Verkehrsklasse fest. Eine Warteschlange kann alle Nachrichten enthalten und dennoch den Nutzen eines OTP oder einer zeitkritischen Transaktionsbenachrichtigung verfehlen. Das Alter sollte ab einem definierten und einheitlichen Zeitstempel gemessen werden, beispielsweise ab der Annahme der Anfrage durch die Plattform.
SMPP erlaubt die Angabe eines validity_period, der einen Ablaufzeitpunkt im SMSC darstellt, nach dem die Nachricht verworfen werden soll, wenn sie nicht zugestellt wurde. Diese Funktion ersetzt keine anwendungseigene funktionale Ablaufregel: Die Plattform sollte verhindern, dass eine wertlose Nachricht unnötig in internen Warteschlangen verbleibt oder mit kritischem Verkehr konkurriert.
- Berechnen Sie die erwartete maximale Ansammlung während der Spitze.
- Legen Sie für jede Verkehrsklasse ein Alterslimit fest.
- Definieren Sie, was bei Überschreitung des Alters geschieht: abbrechen, ablaufen lassen oder das Ursprungssystem informieren.
- Stimmen Sie den internen Ablauf bei Bedarf mit validity_period und den Regeln des Anbieters ab.
- Messen Sie Tiefe und Alter nach Warteschlange, Zieladresse und Priorität.
OTP, Transaktionsnachrichten und Kampagnen trennen
OTP, Transaktionsverkehr und Kampagnen sollten nicht ohne Kontrollen eine einzige Warteschlange teilen. Die Klassifizierung ist eine Produkt- und Betriebsentscheidung, muss aber in explizite Richtlinien für Annahme, Priorität, Kapazitätsreservierung, Ablauf und Degradierung übersetzt werden.
OTP erfordern üblicherweise ein sehr kurzes funktionales Höchstalter. Transaktionsnachrichten können je nach Geschäftsprozess eine andere Toleranz haben. Legitime und einwilligungsbasierte Kampagnen sind dagegen bei Kapazitätsdruck häufig Kandidaten für eine flexiblere Planung. Die Richtlinie sollte Produktteams, Betrieb und den nachrichtenerzeugenden Systemen bekannt sein.
SMPP enthält priority_flag und dienstbezogene Felder, doch der Standard schreibt keine Warteschlangenrichtlinie vor und garantiert nicht, dass eine Prioritätsmarkierung in allen Implementierungen das gleiche Ergebnis erzeugt. Priorität sollte primär auf der eigenen Plattform umgesetzt und mit den Bedingungen der Route abgestimmt werden.
- Reservieren Sie bei Bedarf Kapazität oder Annahme für kritischen Verkehr.
- Verhindern Sie, dass eine Kampagne die für OTP vorgesehene Warteschlange oder Kapazität verbraucht.
- Weisen Sie je Klasse ein Höchstalter und eine Ablaufaktion zu.
- Protokollieren Sie den Grund jeder Degradierung für spätere Analysen.
- Halten Sie die Sendungen legitim, einwilligungsbasiert und den geltenden Regeln unterworfen.
Latenzbudgets und Semantik von DLR
Ein hilfreiches Latenzbudget unterteilt den Ablauf in beobachtbare Stufen: Zeit bis zur Annahme durch API oder SMPP, Wartezeit in der eigenen Warteschlange, Zeit bis zur Annahme oder Verarbeitung durch den Anbieter sowie Zeit bis zum gemeldeten Endstatus. Jede Stufe sollte über einen Zeitstempel, eine Quelle und eine Korrelationsmethode verfügen.
Setzen Sie die anfängliche Antwort nicht mit dem endgültigen Empfang gleich. Bei SMPP bestätigt die Antwort auf submit_sm den Austausch der Anfrage mit dem SMSC, während das spätere Ergebnis über einen Delivery Receipt mitgeteilt wird, wenn dieser angefordert wurde. Zu den Statuswerten können unter anderem DELIVRD, EXPIRED, UNDELIV und REJECTD gehören.
Auch haben nicht alle Zustellberichte dieselbe Semantik. 3GPP unterscheidet zwischen Berichten, die vom Service Centre ausgegeben werden, und solchen, die von der Mobilstation ausgegeben werden. Daher sollte ein von einem SMSC oder einem zwischengeschalteten Netz ausgegebener DLR nach Aussteller und Bedeutung gekennzeichnet werden. Er darf nicht automatisch als unabhängiger Nachweis für den Empfang auf dem Endgerät dargestellt werden.
- Messen Sie Latenz nach Stufe, nicht nur als Gesamtzeit.
- Verwenden Sie Perzentile, um lange Warteschlangen und Warteschlangendegradierung zu erkennen.
- Bewahren Sie die Quelle des Status auf: Plattform, Anbieter, SMSC oder ein anderer Teil der Kette.
- Unterscheiden Sie Annahme, gemeldeten Endstatus und Empfang auf dem Endgerät, wenn Nachweise dieser Art vorliegen.
- Vermeiden Sie Zusagen zum endgültigen Empfang, die sich ausschließlich auf eine anfängliche Antwort oder auf einen DLR mit unbestätigter Semantik stützen.
Häufige Fragen
Wie werden die erforderlichen TPS für A2P-SMS berechnet?
Als Ausgangspunkt teilen Sie die erwarteten Nachrichten durch die Sekunden des Zielzeitfensters. Berechnen Sie anschließend nach Zieladresse, Route, Verbindung und Verkehrsklasse und dokumentieren Sie den Puffer für Bursts, Wiederholungen und operative Schwankungen getrennt. Das Ergebnis ist ein Planungsbedarf und keine Garantie für Netzkapazität.
Bedeutet ein erfolgreiches submit_sm_resp, dass die SMS auf dem Mobiltelefon angekommen ist?
Nein. submit_sm_resp gibt die Antwort auf die SMPP-Anfrage zwischen ESME und SMSC wieder. Das spätere Ergebnis erfordert die Beobachtung des Delivery Receipt, sofern dieser angefordert wurde, sowie die Analyse seines Status und seiner Semantik. Ein von einem SMSC ausgegebener DLR belegt nicht automatisch den Empfang auf dem Endgerät.
Wie wird die Größe einer SMS-Warteschlange berechnet?
Schätzen Sie die maximale Ansammlung in den Intervallen, in denen die Ankunftsrate die nachhaltige Ausgangsrate übersteigt. Definieren Sie zusätzlich zur Tiefe ein Höchstalter je Verkehrsklasse und die Maßnahme bei Überschreitung, etwa kontrollierten Ablauf oder Abbruch.
Warum sollte ich OTP und Kampagnen trennen?
Weil ihre Anforderungen an Nutzen und Wartezeit unterschiedlich sind. Eine Kampagne kann bei Kapazitätsdruck geplant oder reduziert werden, während ein OTP typischerweise an Wert verliert, wenn es zu lange wartet. Richtlinien sollten Annahme, Priorität, Alter und Degradierung trennen.
Wie beeinflusst SMPP die Dimensionierung der Parallelität?
SMPP ermöglicht asynchrone Anfragen und verwendet sequence_number zur Korrelation von Anfragen und Antworten. Eine hilfreiche Näherung besteht darin, Anfragen in Bearbeitung als Ziel-TPS multipliziert mit der beobachteten submit_sm_resp-Latenz zu schätzen. Das endgültige Limit muss je Session anhand von Dokumentation, Fehlern, Timeouts und beobachtetem Anbieterverhalten angepasst werden.
Welche Vorsicht ist bei HTTP-Wiederholungen erforderlich?
Ein Timeout oder eine geschlossene Verbindung vor Erhalt einer Antwort beweist nicht, dass der Versand nicht angenommen wurde. Da ein Versand nicht idempotent sein kann, sollten Wiederholungen nicht ohne Idempotenzkennung, zuverlässige Statusabfrage oder gleichwertigen Nachweis automatisiert werden, der Duplikate verhindert.
Verwendete Quellen
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- RFC 9110: HTTP SemanticsInternet Engineering Task Force (IETF) / RFC Editor
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3rd Generation Partnership Project (3GPP)
- Recommendation ITU-T E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)