SMPP: Der vollständige Protokollleitfaden.

Was SMPP ist und wo es seinen Platz hat

Eine SMPP-Sitzung hat immer zwei Rollen. ESME (Externe Kurznachrichten-Entität) ist Ihre Anwendung – eine Massen-SMS-Plattform, ein OTP-Dienst, ein Benachrichtigungssystem. Die SMSC (Short Message Service Centre), genannt ein MC Das Message Center (MSC) in Version 5.0 ist der Betreiber- oder Aggregatorknoten, der Nachrichten zwischen Mobiltelefonen im Mobilfunknetz speichert und weiterleitet. Das ESME ist mit dem SMSC verbunden; das SMSC ist mit dem übergeordneten SS7-/Mobilfunkkern verbunden.

SMPP ist das Rückgrat von A2P (Anwendung-zu-Person) Nachrichten – Bestätigungscodes, Belege, Benachrichtigungen, Marketing – im Gegensatz zu P2P (Person-zu-Person)-SMS zwischen zwei Mobiltelefonen. A2P Der Datenverkehr ist volumenstark, maschinell generiert und auf Zustell- und Empfangsbestätigungen ausgelegt – genau das, wofür SMPP entwickelt wurde.

Warum ein binäres TCP-Protokoll anstelle von HTTP? Eine einzelne SMPP-Bindung ist ein langlebiger Socket. Sobald dieser geöffnet ist, vermeidet man einen TCP- und TLS-Handshake pro Nachricht, es können viele Nachrichten gleichzeitig übertragen werden (asynchrones Windowing), und der SMSC sendet Zustellbestätigungen und eingehende Nachrichten direkt über dieselbe Verbindung zurück. Bei dauerhaft hohem Durchsatz ist dies deutlich effizienter als eine HTTP-API mit Anfrage/Antwort – weshalb Betreiber und große Absender es als Standard verwenden.

Versionsverlauf

• SMPP v3.3 — die erste weit verbreitete Version; führte ein den Kern-PDU-Satz ein, existierte aber vor TLVs (optionalen Parametern) und der Transceiver-Bindung.
• SMPP v3.4 — die heute am weitesten verbreitete Version. Hinzugefügt wurden: Transceiver-Bindung, optionale TLV-Parameter, message_payload und data_sm. Nahezu jede reale Integration, die Sie entwickeln werden, verwendet Version 3.4.
• SMPP v5.0 — die neueste Version. Benennt SMSC in MC um und fügt hinzu: Broadcast-PDUs (broadcast_sm), Stauzustandssignalisierung und weitere standardisierte TLVs. Die Verbreitung ist begrenzt; zunächst wird Version 3.4 unterstützt, Version 5.0 ist optional.

Architektur & Bindungstypen

Die Topologie ist einfach: Der ESME öffnet eine TCP-Verbindung zum SMSC/MC und authentifiziert sich mit einem system_id Und passwordDie Richtung, in die die Sitzung Datenverkehr leiten darf, wird zum Zeitpunkt der Bindung durch Auswahl einer von drei Optionen festgelegt. BindungsmodiJeder Modus ist eine andere Bindungs-PDU.

Ein vierter Schauspieler ist RoutingDas SMSC entscheidet pro Nachricht, welchen nachgelagerten Betreiber eine übermittelte Nachricht zum Zielgerät weiterleitet oder verbindet und zu welchem gebundenen ESME eine eingehende (vom Mobiltelefon stammende) Nachricht gehört.

Im Netzwerk läuft SMPP über TCP. Der von der IANA registrierte Standardport ist 2775 für einfache Verbindungen. SMPPS — SMPP in TLS — hat keinen einheitlichen Standardport; Anbieter stellen es auf einem Port ihrer Wahl bereit (3550, 8775 und 2776 sind gängige Beispiele). Verwenden Sie für den Produktivbetrieb immer den vom Anbieter zugewiesenen verschlüsselten Port.

Der Sitzungslebenszyklus

Jede SMPP-Sitzung folgt demselben Ablauf: TCP öffnen, binden, aktiv bleiben, Nachrichten und Empfangsbestätigungen austauschen, dann die Bindung aufheben und die Sitzung beenden. Das folgende Diagramm stellt eine vollständige Transceiver-Sitzung dar – jede Zeile repräsentiert eine PDU, blau vom ESME zum SMSC, grün zurück.

Zwei wichtige Details. Erstens: submit_sm_resp kehrt sofort zurück und bedeutet lediglich „zur Zustellung angenommen“ – das tatsächliche Ergebnis kommt später als deliver_sm-Zustellbestätigung. Zweitens: Zu jeder Anforderungs-PDU gibt es eine passende _resp, die deren sequence_number zurückgibt – so werden asynchrone Antworten ihren Anfragen zugeordnet.

PDU-Anatomie

Alles an einer SMPP-Verbindung ist ein PDUJede PDU beginnt mit einem festen 16-Byte-Header aus vier 4-Byte-Ganzzahlen (32 Bit, Big-Endian), gefolgt von einem befehlsspezifischen Rumpf. Lesen Sie zuerst den Header, dann wissen Sie genau, wie Sie den Rest lesen müssen.

Der Textkörper endet mit einer beliebigen Anzahl von TLVs — Optionale Parameter kodiert als Tag (2 Bytes), Länge (2 Bytes), Wert (Länge Bytes). TLVs sind die Erweiterung des Protokolls durch v3.4, ohne ältere Peers zu beeinträchtigen: message_payload, receipted_message_id, sar_* Verkettungsfelder und viele weitere werden als TLVs übertragen.

Der Sequenznummer ist der Schlüssel zur Fensterung. Da SMPP asynchron ist, kann ein ESME viele submit_sm PDUs senden – jede mit einer inkrementierenden Sequenznummer –, bevor Antworten eintreffen. Wenn submit_sm_resp PDUs zurückkommen, gibt ihre Sequenznummer an, welche Übermittlung jede einzelne beantwortet. Die Anzahl der zulässigen unbestätigten PDUs während der Übertragung ist die Fenstergröße

Core-PDUs-Referenz

Dies sind die Operationen, die Sie tatsächlich verwenden werden. Jede Anfrage hat eine Antwort-PDU, deren command_id die Anfrage-ID mit gesetztem High-Bit (0x80000000) ist. So gehört beispielsweise submit_sm 0x00000004 zu submit_sm_resp 0x80000004.

submit_sm Feld für Feld

submit_sm ist die PDU, die Sie am häufigsten senden werden. Ihr Inhalt besteht aus einer Folge obligatorischer Parameter und optionalen TLVs. Dies sind die Felder, die in der Praxis relevant sind.

Datenkodierung und -verkettung

Der data_coding Das Datenkodierungsschema (DCS) gibt dem Mobiltelefon vor, wie die Bytes zu interpretieren sind, und legt fest, wie viele Zeichen in eine SMS passen.

Eine Nachricht, die länger als ein Segment ist, wird auf dem Mobiltelefon aufgeteilt und mithilfe eines UDH (Benutzerdatenkopf) wird jedem Teil vorangestellt. Das Verkettungselement verwendet IEI 0x00 (8-Bit Referenz) – ein 6-Oktett-Header mit einer Referenznummer, der Gesamtanzahl der Bauteile und dem Index dieses Bauteils. Diese 6 Oktette sind der Grund, warum die Grenzwerte pro Bauteil auf 153 (GSM 7-Bit) bzw. 67 (UCS-2) sinken. Beim Senden einer UDH innerhalb von short_message muss auch das UDHI-Bit (0x40) in esm_class gesetzt werden.

Es gibt zwei Möglichkeiten, längere Inhalte zu senden: Entweder erstellen Sie die UDH-segmentierten Teile selbst (jeweils eine submit_sm mit festgelegtem UDHI) oder Sie übergeben den gesamten Inhalt an das SMSC. message_payload TLV und lassen Sie es segmentieren. Einige SMSCs akzeptieren stattdessen die TLVs sar_msg_ref_num / sar_total_segments / sar_segment_seqnum zur Beschreibung der Verkettung ohne UDH.

Zustellberichte (DLR)

Wenn Sie einstellen registered_delivery = 1, Das SMSC informiert Sie später über den Verbleib der Nachricht, indem es Ihnen eine Benachrichtigung sendet. deliver_sm mit gesetztem Zustellberichtbit in esm_class (0x04Der Belegtext befindet sich im Feld „short_message“ als bekanntes Schlüsselwort:

id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2607251432 done date:2607251432 stat:DELIVRD err:000 text:Your code is 8

Der id entspricht der empfangenen message_id in submit_sm_resp (wird auch in receipted_message_id TLV 0x001E ausgegeben). stat Das Feld enthält den Endzustand: Das ...

Beantworten Sie eine deliver_sm-Nachricht immer mit einem deliver_sm_respAndernfalls wird das SMSC die Empfangsbestätigung erneut senden und die Verbindung möglicherweise drosseln oder trennen. Beachten Sie, dass die Formatierung der Empfangsbestätigung nicht vollständig standardisiert ist – die Anbieter unterscheiden sich geringfügig in der Feldreihenfolge und der Zuordnung der Fehlercodes.

Fehler-/Befehlsstatuscodes

Jede Antwort-PDU enthält eine command_status in seiner Kopfzeile — ein ESME_R* Code. Null bedeutet Erfolg. Alle anderen Werte beschreiben, warum die Anfrage abgelehnt wurde. Dies sind die Codes, die Ihnen am häufigsten begegnen werden.

Das vollständige Verzeichnis – einschließlich der anbieterspezifischen Sortimente – ist durchsuchbar in der SMPP-Fehlercode-Referenz

Durchsatz, Fensterung und Drosselung

Der Durchsatz in SMPP wird gemessen in TPS — Transaktionen (submit_sm) pro Sekunde — und dies wird durch zwei Faktoren bestimmt: die vom SMSC zugelassene Rate und die Anzahl der Nachrichten, die Sie gleichzeitig senden. Da SMPP asynchron ist, müssen Sie nicht auf jede submit_sm_resp warten, bevor Sie die nächste PDU senden. Die Anzahl der gleichzeitig zulässigen unbestätigten Übermittlungen ist Ihre Fenstergröße (üblicherweise 10–100). Ein größeres Fenster kaschiert die Roundtrip-Latenz und erhöht die effektive Transaktionsrate (TPS) – bis zum Maximum des SMSC.

• Respektiere das Gaspedal. Wenn der SMSC den Wert ESME_RTHROTTLED (0x58) zurückgibt, sollten Sie einen Rücksetzer einlegen – pausieren Sie und versuchen Sie es erneut mit exponentiellem Backoff, anstatt die Bindung wiederholt zu versuchen. Dies kann zu einer Verbindungsunterbrechung führen.
• Halten Sie sich im Rhythmus am Leben. Sende enquire_link etwa alle 30 Sekunden im Leerlauf; wenn einige Anfragen unbeantwortet bleiben, gehe davon aus, dass die Verbindung nicht mehr funktioniert.
• Knüpfen Sie bewusst wieder Kontakt. Bei Verbindungsabbruch erneut verbinden und mit Backoff und Jitter neu binden; keine enge Schleife verwenden. Ausstehende Sequenznummern verfolgen, um Belege nach einer erneuten Verbindung abgleichen zu können.
• Skalieren Sie mit Bindungen, aber vorsichtig. Höhere Gesamttransaktionen pro Sekunde (TPS) resultieren üblicherweise aus mehreren Bindungen – jedoch nur bis zu dem Limit, das Ihr Anbieter pro Konto autorisiert.

Codebeispiel

Ein beispielhafter Ablauf von Verbinden → Binden → Absenden in Node-typischem Pseudocode. Echte SMPP-Bibliotheken (z. B. node-smpp, jSMPP für Java oder python-smpplib) übernehmen die PDU-Kodierung; dies zeigt die Struktur der Sitzung, nicht die API einer bestimmten Bibliothek.

import smpp from "smpp";

// 1. Open a TCP (or TLS) session to the SMSC.
const session = smpp.connect({
  // Host, port and bind credentials come with your test access.
  // Plain SMPP conventionally uses 2775; the TLS port is provided with your account.
  url: process.env.SMPP_URL!,             // e.g. smpp://<host>:2775 (plain) or smpps://<host>:<tls-port>
  auto_enquire_link_period: 30000,        // keepalive every 30s
});

// 2. Bind as a transceiver.
session.bind_transceiver(
  {
    system_id: "YOUR_SYSTEM_ID",
    password:  "YOUR_PASSWORD",
    system_type: "",
  },
  (pdu) => {
    if (pdu.command_status !== 0) {
      throw new Error("bind failed: 0x" + pdu.command_status.toString(16));
    }

    // 3. Submit a Unicode message, asking for a delivery receipt.
    session.submit_sm(
      {
        source_addr_ton: 5,                // alphanumeric Sender ID
        source_addr:      "BroadNet",
        dest_addr_ton:    1,               // international E.164
        destination_addr: "447700900123",
        registered_delivery: 1,            // request a DLR
        data_coding: 8,                    // UCS-2 (Unicode)
        short_message: "Your code is 8123",
      },
      (submitResp) => {
        // submit_sm_resp returns the SMSC message_id.
        console.log("accepted, message_id =", submitResp.message_id);
      }
    );
  }
);

// 4. Receive delivery receipts on the same session.
session.on("deliver_sm", (pdu) => {
  if ((pdu.esm_class & 0x04) === 0x04) {   // delivery-receipt bit
    console.log("DLR:", pdu.short_message.message);
  }
  session.send(pdu.response());            // ALWAYS deliver_sm_resp
});

BroadNet SMPP

BroadNet betreibt ein SMSC-Gateway in Carrier-Qualität, das SMPP v3.4-Bindungen über TLS akzeptiert. Sie erhalten: Transceiver-Bindungen, hohe Transaktionsraten (TPS) mit asynchroner Fensterung, vollständige Zustellbestätigungen, Unicode und Zeichenkettenverkettung sowie eine IP-Listen-basierte, authentifizierte Verbindung, um Netzbetreiber weltweit zu erreichen. Es handelt sich um dasselbe Protokoll, das auf dieser Seite erläutert wird – nur eben für reale Routen.

Häufig gestellte Fragen

Verwandte Tools und Dokumente