A2P-SMS-Geschwindigkeitslimits nach Ziel: Vereinbaren und verwalten
Ein angegebenes TPS-Limit garantiert keine Zustellung. Erfahren Sie, wie Sie den Geltungsbereich präzisieren, Warteschlangen je Ziel überwachen und operative Signale bewerten, ohne Annahme mit Zustellung zu verwechseln.
Ein angegebenes TPS-Limit ist keine Zustellgarantie
TPS wird häufig für Nachrichten pro Sekunde verwendet. Die angegebene Zahl ist für den Betrieb jedoch nur dann aussagekräftig, wenn klar ist, was sie misst, wo sie gilt und unter welchen Bedingungen. Ein allgemeines Limit lässt sich nicht allein aus dem Land, dem Betreiber oder der Verbindungsart ableiten: Es muss mit dem Verantwortlichen für die Route bestätigt und sein Geltungsbereich dokumentiert werden.
Auch die einzelnen Versandstufen müssen getrennt betrachtet werden. Eine Annahmebestätigung bestätigt höchstens, dass eine Anfrage an dieser Stelle der Verarbeitungskette angenommen wurde; sie beweist nicht, dass die SMS das Telefon erreicht hat. Nachfolgende Statusmeldungen, darunter DLRs, sind abhängig von ihrer Quelle und ihrem Verifizierungsgrad zu interpretieren.
- Behandeln Sie das mitgeteilte TPS-Limit als zu klärende Bedingung, nicht als allgemeines Zustellversprechen.
- Erfassen Sie die Annahme von Anfragen getrennt von den späteren Nachrichtenstatus.
- Übertragen Sie den Wert einer Route nicht auf andere Ziele, Betreiber oder Absender.
Was vor der Konfiguration des Datenverkehrs zu klären ist
Bitten Sie um eine schriftliche Definition des Geltungsbereichs des Limits und der Messmethode. Klären Sie, ob es für ein Land, einen Betreiber, eine Route, einen Absender, ein Konto oder eine Sitzung gilt. Fragen Sie außerdem, ob es je nach Verkehrstyp variiert, etwa bei OTP, transaktionalen Nachrichten oder zulässigem Marketing, und welches Zeitfenster zur Berechnung herangezogen wird.
Die Verbindung ersetzt diese Vereinbarung nicht. SMPP ist eine relevante Protokollspezifikation für den Nachrichtenaustausch zwischen einer Anwendung und einem SMSC. HTTP beschreibt die Semantik von Anfragen und Antworten. Keine dieser Spezifikationen legt für sich allein ein garantiertes TPS-Limit für eine A2P-Route fest oder bestätigt die Zustellung an ein Mobiltelefon.
- Ziel sowie betroffener Betreiber oder Betreibergruppe.
- Einbezogene Routenkennung, Konto, Absender und Verkehrstyp.
- Einheit, Messfenster und Behandlung abgelehnter Anfragen.
- Limit je Sitzung und aggregiertes Limit, sofern beide gelten.
- Bedingungen für Spitzenlasten, Parallelität, Pausen und Kapazitätsänderungen.
- Antwortcodes und operativer Kontakt für Vorfälle oder Anpassungen.
Dauerhafte Rate, Spitzenlast und Parallelität unterscheiden
Gehen Sie nicht davon aus, dass eine nominelle Rate bedeutet, dass dieses Volumen dauerhaft versendet werden kann. Lassen Sie vom Anbieter definieren, ob der Wert eine dauerhafte Rate, ein momentanes Maximum oder einen Durchschnitt über ein bestimmtes Zeitfenster darstellt. Wenn Spitzenlasten zulässig sind, fragen Sie nach den Bedingungen und der Dauer. Werden Sitzungen oder gleichzeitige Anfragen begrenzt, erfassen Sie diese Limits separat.
Die verfügbaren Informationen reichen nicht aus, um für diese Parameter allgemeingültige Werte zu empfehlen. Kann der Anbieter sie nicht definieren, kennzeichnen Sie die Bedingung als unbestätigt und richten Sie das System nicht auf einer optimistischen Auslegung aus.
- Dokumentieren Sie jeden Parameter separat; fassen Sie nicht alle Limits zu einem einzigen TPS-Wert zusammen.
- Unterscheiden Sie zwischen Nachrichtenrate, Anzahl gleichzeitiger Anfragen und Verbindungssitzungen.
- Halten Sie fest, ob das Limit zwischen Zielen, Absendern oder Verbindungen geteilt wird oder ob der Anbieter dies noch nicht geklärt hat.
Zulassungskontrollen und Warteschlangen je Ziel einrichten
Ordnen Sie den Datenverkehr in Warteschlangen ein, die dem tatsächlichen Geltungsbereich des jeweiligen Limits entsprechen. Bestätigt ein Anbieter unterschiedliche Limits je Betreiber oder Route, verhindern Sie, dass eine globale Warteschlange eine Überschreitung in einer dieser Gruppen verdeckt. Prüfen Sie vor dem Produktiveinsatz der Kontrolle, wie das Ziel identifiziert wird und was mit Nachrichten geschieht, deren Routing noch nicht feststeht.
Die Ausgangsrate sollte sich anpassen lassen, ohne Nachrichten unbemerkt zu verwerfen. Legen Sie fest, welche Nachrichten in der Warteschlange verbleiben, welche erneut versucht werden und wie verhindert wird, dass Wiederholungsversuche eine Überlastung verschärfen. Die konkreten Kriterien hängen von der Vereinbarung und dem beobachteten Verhalten ab; ohne diese Angaben lässt sich keine universelle Konfiguration empfehlen.
- Ordnen Sie jede Warteschlange einem bestätigten Limit zu und halten Sie diese Zuordnung in der Konfiguration fest.
- Legen Sie klare Regeln für das Pausieren, Fortsetzen und erneute Versenden nach Ablehnungen fest.
- Protokollieren Sie Änderungen an Rate und Konfiguration, um sie mit den Ergebnissen abgleichen zu können.
- Stellen Sie sicher, dass Verkehrs-Prioritäten die Einschränkungen des Ziels nicht außer Kraft setzen.
Operative Signale im Kontext beurteilen
Ein Anstieg der Ablehnungen oder der Antwortlatenz bei der Annahme kann darauf hindeuten, dass eine Einschränkung erreicht wird; für sich allein zeigt er jedoch nicht die Ursache. Prüfen Sie, ob der Anstieg mit einer Änderung des Volumens, der Route, der Sitzung oder der Konfiguration zusammenfällt, und bitten Sie den Anbieter um eine Auslegung der Antwortcodes. Führen Sie das Problem nicht automatisch auf ein TPS-Limit zurück.
Überwachen Sie außerdem die Tiefe und das Alter der Warteschlangen, angenommene und abgelehnte Anfragen sowie verfügbare nachfolgende Statusmeldungen. Annahmelatenz und DLR beziehen sich auf unterschiedliche Verarbeitungsstufen. Ein empfangener DLR darf nicht als unabhängiger Nachweis für den Empfang auf dem Telefon dargestellt werden, sofern keine entsprechende Verifizierung vorliegt.
- Ablehnungen: nach Code, Ziel, Route und Zeitraum erfassen.
- Latenz: die Antwortzeit der API oder Sitzung von den nachfolgenden Statusmeldungen trennen.
- Warteschlangen: Tiefe, Alter und Abbaurate beobachten.
- Status: Annahme, DLR und jede tatsächlich verifizierbare Empfangsbestätigung unterscheiden.
Schrittweise und mit Einwilligung testen
Vereinbaren Sie vor einem Test mit dem Anbieter das Ziel, den Absender, den Verkehrstyp, das Zeitfenster, die Startrate und die Bedingungen für einen Abbruch. Verwenden Sie ausschließlich zulässige Nachrichten und Empfänger, die dem Empfang des Datenverkehrs zugestimmt haben, und halten Sie die geltenden Vorschriften ein. Erhöhen Sie die Last auf reale Ziele nicht ohne ausdrückliche Genehmigung.
Steigern Sie das Volumen kontrolliert, protokollieren Sie jede Änderung und brechen Sie den Test bei den vereinbarten Anzeichen von Fehlern oder Überlastung ab. Ein Test zeigt das beobachtete Verhalten unter den jeweiligen Bedingungen. Das Ergebnis garantiert weder eine produktive Kapazität noch lässt es sich als Nachweis auf andere Routen oder Zeiträume übertragen.
- Vereinbaren Sie Umfang und Abbruchkriterien im Voraus.
- Halten Sie nicht untersuchte Variablen konstant und dokumentieren Sie jede Änderung.
- Verwenden Sie einen nicht genehmigten Test nicht als Ersatz für eine vertragliche Bestätigung.
Auf eine mögliche Überlastung reagieren
Nehmen Ablehnungen, Latenz oder Warteschlangen dauerhaft zu, senken Sie die Zulassungsrate und befolgen Sie das vereinbarte Verfahren. Verschlechtert sich die Lage weiter, pausieren Sie gegebenenfalls den betroffenen Datenverkehr und kontaktieren Sie den Anbieter mit konkreten Angaben. Erhöhen Sie nicht automatisch die Parallelität und beschleunigen Sie keine Wiederholungsversuche: Solange die Regeln der Route unbekannt sind, kann dies den Druck erhöhen oder die Diagnose erschweren.
Erstellen Sie eine Chronologie des Vorfalls mit Uhrzeit, Ziel, Route, Volumen, Konfigurationsänderungen, empfangenen Codes und Entwicklung der Warteschlangen. Bitten Sie um Bestätigung, ob ein Limit erreicht wurde, eine andere betriebliche Bedingung vorlag oder sich das geltende Limit geändert hat. Eskalieren Sie über die vereinbarten Kanäle und dokumentieren Sie die Antwort.
- Senken Sie die betroffene Rate und vermeiden Sie nicht vereinbarte aggressive Wiederholungsversuche.
- Stellen Sie Fehlercodes und Kennzahlen nach Ziel und Route aufgeschlüsselt bereit.
- Bitten Sie um eine operative Entscheidung und eine schriftliche Bestätigung jeder Limitänderung.
- Nehmen Sie den Verkehr gemäß dem vereinbarten Verfahren schrittweise wieder auf.
Limits überprüfen und Nachweise aufbewahren
Führen Sie ein versioniertes Register, in dem die vom Anbieter angegebenen Bedingungen von den Beobachtungen im Produktivbetrieb getrennt sind. Erfassen Sie das Bestätigungsdatum, den Geltungsbereich, die Parameter, Ausnahmen und die verantwortliche Person für die Freigabe von Änderungen. Weichen die Kennzahlen von der Vereinbarung ab, bitten Sie um eine Überprüfung. Ersetzen Sie das vertragliche Limit nicht durch ein in einem kurzen Test beobachtetes Maximum.
Öffentliche Zahlenangaben auf den Karten einer Plattform für die Suche, den Vergleich, den Kauf, Verkauf und die Verwaltung von A2P-SMS-Kapazität dienen zur Veranschaulichung, bis vertragliche Routendaten angebunden sind. Sie dürfen daher nicht als aktive kommerzielle Limits behandelt werden.
- Halten Sie das angegebene Limit, die angewandte Konfiguration und die beobachteten Nachweise getrennt fest.
- Dokumentieren Sie Zeitraum und Bedingungen jedes Tests oder Vorfalls.
- Prüfen Sie die Vereinbarung mit dem Anbieter, bevor Sie die Betriebskapazität ändern.
Häufige Fragen
Gibt es ein universelles TPS-Limit für A2P-SMS je Land?
Die verfügbaren Informationen reichen nicht aus, um einen universellen Wert festzulegen. Bestätigen Sie das Limit mit dem Verantwortlichen für die Route und dokumentieren Sie, für welches Ziel, welchen Betreiber, Absender, welche Sitzung und welches Messfenster es gilt.
Bedeutet die Annahme einer Anfrage, dass die SMS zugestellt wurde?
Nein. Die Annahme zeigt, dass die Anfrage an einer Stelle des Prozesses angenommen wurde, beweist aber nicht für sich allein die Zustellung an das Telefon. Interpretieren Sie die nachfolgenden Statusmeldungen getrennt und berücksichtigen Sie deren Verifizierungsgrad.
Legen SMPP oder HTTP die garantierte Geschwindigkeit einer Route fest?
Nach den verfügbaren Informationen nicht. SMPP und HTTP spezifizieren Aspekte des technischen Austauschs, legen aber nicht von sich aus eine garantierte A2P-Kapazität je Ziel fest.
Was soll ich tun, wenn die Grenzen für Spitzenlast und Parallelität nicht definiert sind?
Bitten Sie um eine schriftliche Definition und kennzeichnen Sie diese Parameter bis dahin als unbestätigt. Leiten Sie ihren Wert weder aus dem nominellen TPS noch aus einem einzelnen Test ab.
Beweist ein erfolgreicher Test die dauerhaft verfügbare Produktionskapazität?
Nicht unbedingt. Er beschreibt lediglich das unter den Testbedingungen beobachtete Verhalten. Das Ergebnis garantiert keine zukünftige Kapazität und lässt sich nicht automatisch auf andere Ziele, Routen oder Zeiträume übertragen.
Verwendete Quellen
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)Internet Engineering Task Force
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA