SMPP v5.0 ist abwärtskompatibel zu v3.4 und ergänzt Congestion-Control-Signalisierung, Broadcast-Messaging-Operationen (broadcast_sm und Verwandte), einen zusätzlichen Nachrichtenzustand (SKIPPED) und weitere TLVs. Dennoch bleibt v3.4 die dominierende Kopplung, weil sie universell unterstützt wird; v5.0 wird nur genutzt, wo beide Gegenstellen es implementieren.
bind_transceiverSitzung öffnen und authentifizierenbind_transceiver_respSitzung akzeptiertsubmit_smNachricht sendensubmit_sm_respAkzeptiert, Nachrichten-ID zurückgegebendeliver_smZustellungsbericht oder eingehende Nachrichtdeliver_sm_respBestätigtenquire_linkKeepalive im Leerlauf
Was v5.0 ergänzt
v5.0 ist eine inkrementelle, abwärtskompatible Überarbeitung von v3.4. Die zentralen Ergänzungen sind Congestion Control (das SMSC zeigt die Last an, sodass ESMEs langsamer werden, bevor sie gedrosselt werden), eine Familie von Broadcast-Operationen für Cell-Broadcast-artiges Messaging, ein neuer Nachrichtenzustand SKIPPED und zusätzliche Optionalparameter. Das Kern-PDU-Format, das Bind-Modell sowie submit_sm/deliver_sm bleiben unverändert, weshalb eine v3.4-ESME mit einem v5.0-SMSC sprechen kann.
| Bereich | v3.4 | Erweiterung v5.0 |
|---|---|---|
| Überlastkontrolle | Keine (auf Throttling reagieren) | congestion_state TLV — proaktiv |
| Broadcast | Nicht unterstützt | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| Nachrichtenzustände | 8 Zustände | Fügt SKIPPED (9) hinzu |
| Optionale Parameter | v3.4 TLV-Set | Zusätzliche TLVs |
| interface_version | 0x34 | 0x50 |
Was gleich geblieben ist
Die Grundlagen sind identisch: der 16-Byte-Header, die Big-Endian-Codierung, die drei Bind-Typen, die Sitzungszustände, das enquire_link-Keepalive, die Feld-Layouts von submit_sm/deliver_sm und der ESME_R*-Fehlerbereich werden alle übernommen. TLVs — eingeführt in v3.4 — bleiben der Erweiterungsmechanismus. Diese Kontinuität ist gewollt: v5.0 wurde so entworfen, dass bestehende v3.4-Integrationen weiter funktionieren.
Welche Version verwenden
Verwenden Sie v3.4, sofern Sie keinen konkreten Grund für v5.0 haben und beide Gegenstellen es unterstützen. v3.4 ist der sichere, universelle Standard für die A2P-Kopplung. Greifen Sie zu v5.0, wenn Sie ausdrücklich dessen Congestion-Signalisierung oder Broadcast-Operationen benötigen und der Anbieter die Unterstützung bestätigt. Bestätigen Sie die ausgehandelte Version stets aus dem bind_resp (dem sc_interface_version-TLV), statt anzunehmen, eine Funktion sei verfügbar.
Häufig gestellte Fragen
Ist SMPP v5.0 abwärtskompatibel zu v3.4?
Ja. v5.0 bewahrt das v3.4-PDU-Format, das Bind-Modell und die Kernoperationen, sodass eine v3.4-ESME und ein v5.0-SMSC interoperieren können. Die Version wird in interface_version deklariert (0x34 vs. 0x50).
Warum ist SMPP v3.4 weiterhin die häufigste Version?
Weil sie universell implementiert ist und die Anforderungen von A2P-Messaging vollständig abdeckt. Die Ergänzungen von v5.0 — Congestion Control, Broadcast — sind in bestimmten Szenarien nützlich, aber für Standard-MT/MO-Verkehr nicht erforderlich, sodass die meisten Kopplungen bei v3.4 blieben.
Was ist der wichtigste praktische Vorteil von v5.0?
Vorbeugende Congestion Control: Das congestion_state-TLV lässt das SMSC seine Last anzeigen, sodass eine kooperative ESME langsamer wird, bevor sie auf harte ESME_RTHROTTLED-Fehler stößt, was einen gleichmäßigeren Durchsatz unter Druck ergibt.
Woran erkenne ich, welche Version eine Sitzung ausgehandelt hat?
Lesen Sie das sc_interface_version-TLV, das im bind_resp zurückgegeben wird. Nehmen Sie nicht an, dass v5.0-Funktionen verfügbar sind, nur weil Sie interface_version 0x50 gesendet haben — das SMSC meldet, was es tatsächlich unterstützt.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)