# Was ist SMPP? Das Sitzungsprotokoll für SMS

SMPP ist das Protokoll, mit dem eine Plattform über eine dauerhafte Sitzung Kurznachrichten mit einem Message-Center austauscht. Ein Bind legt die Richtung fest, die Sitzung trägt ein Durchsatzfenster, und Zustellberichte kommen als PDUs zurück. Es ist keine API nach dem Muster Anfrage und Antwort.

- SMPP ist eine dauerhafte Sitzung mit einer festgelegten Bind-Richtung.

- Ein Bind trägt eine Durchsatzzuteilung und ein Fenster laufender Anfragen.

- Eine PDU hat einen 16-Byte-Header und einen befehlsspezifischen Body.

- Zustellberichte kommen asynchron über die Sitzung an; ordnen Sie sie über die Message-ID zu.

## Eine Sitzung, kein Aufruf

SMPP hält eine Verbindung zwischen Ihrer Plattform und einem Message-Center offen. Die Plattform authentifiziert sich einmal, legt fest, was sie tun will, und sendet dann über dieselbe Sitzung Nachrichten und empfängt Ereignisse. Das Message-Center wartet nicht auf eine neue Anfrage, um einen Zustellbericht oder eine eingehende Nachricht zu senden; es schickt eine PDU, sobald es etwas zu melden hat.
Diese Form passt zu einem gleichmäßigen Strom. Der Aufwand pro Nachricht ist gering, weil der Sitzungszustand bereits besteht und der Kanal für Zustellberichte bereits offen ist. Es bedeutet aber auch, dass Ihr Client einen Zustand verwaltet, den ein HTTP-Client nicht hat: den Bind-Status, das Fenster laufender Anfragen, das Keep-Alive-Timing und das Verhalten beim Wiederverbinden.

## Binds legen eine Richtung fest

Ein Bind ist die authentifizierte Sitzung plus eine Richtung. Ein Transmitter-Bind sendet Nachrichten. Ein Receiver-Bind empfängt vom Mobilgerät gesendete Nachrichten (MO) und Zustellberichte. Ein Transceiver-Bind erledigt beides über eine Sitzung. Der Anbieter vergibt Zugangsdaten für jeden Bind und kann begrenzen, wie viele Binds Sie öffnen dürfen.
Skalieren Sie durch zusätzliche Binds, nicht indem Sie einen Bind über seine Zuteilung hinaus belasten. Ein Bind trägt eine Durchsatzzuteilung und ein Fenster laufender Anfragen. Braucht Ihre Spitzenlast mehr, fragen Sie nach einem weiteren Bind und verteilen Sie den Verkehr. Ein einzelner Bind, der über sein Fenster hinaus betrieben wird, erzeugt Drosselung, Timeouts und Wiederholungen, die wie ein Netzfehler aussehen, aber im Client beginnen.

### Bind, Submit, Zustellbericht

Die Sitzung wird einmal geöffnet; jeder Submit erhält eine Antwort mit einer Message-ID; der Zustellbericht kommt später über dieselbe Sitzung.

Alt: Eine Abfolge von der Anwendung über eine Bind-Anfrage und das Message-Center zu einer Submit-Antwort und einem Zustellbericht.

Die Anwendung öffnet einen Bind, und das Message-Center antwortet. Die Anwendung sendet eine Kurznachricht mit submit_sm und erhält submit_sm_resp mit einer Message-ID. Später sendet das Message-Center eine deliver_sm-PDU, die den Zustellbericht enthält. Die Anwendung bestätigt sie mit deliver_sm_resp. Ein Unbind schließt die Sitzung, wenn die Arbeit erledigt ist.

| Item | Value | Note |
| --- | --- | --- |
| Erster Zustand · 1 | Anwendung (ESME) |  |
| Erster Zustand · 2 | bind_transceiver | Sitzung öffnen |
| Erster Zustand · 3 | SMSC |  |
| Erster Zustand · 4 | submit_sm_resp | Zur Zustellung angenommen |
| Erster Zustand · 5 | Zustellbestätigung |  |

Source: smpp.org: SMPP-Sitzungen und PDU-Operationen (https://smpp.org/)

## Das Fenster ist die Vereinbarung

Das Fenster ist die Zahl der Anfragen, die Ihr Client offen haben darf, bevor er auf Antworten wartet. Es ist keine Empfehlung. Senden Sie mehr, als das Fenster zulässt, drosselt Sie das Message-Center; wiederholen Sie weiter mit derselben Rate, wächst die Warteschlange. Lesen Sie den Antwortcode jedes Submits, verlangsamen Sie bei Drosselung und lassen Sie das Fenster leerlaufen, bevor der nächste Schub kommt.
Keep-Alive-Verkehr hält die Sitzung offen. Ein Client, der nie enquire_link sendet, kann auf einer toten Verbindung sitzen, bis der erste Submit fehlschlägt. Ein Client, der sich nach jedem Abbruch sofort neu verbindet, kann den Anbieter überlasten. Nutzen Sie ein Backoff, begrenzen Sie die Rate der Wiederverbindungen und lösen Sie einen Alarm aus, wenn der Bind länger ausgefallen ist, als Ihr Verkehr verkraftet.

### Eine PDU, Feld für Feld

Der Header ist fest; der Body hängt vom Befehl ab. Ein submit_sm enthält Adressen, Kodierung und ein Flag für den Zustellbericht.

Alt: Eine dekodierte submit_sm-PDU mit Befehlslänge, Befehls-ID, Status, Sequenznummer und Body-Feldern.

Jede PDU beginnt mit einer Befehlslänge von vier Byte, einer Befehls-ID von vier Byte, einem Befehlsstatus von vier Byte und einer Sequenznummer von vier Byte. Danach folgt der Body. Bei submit_sm enthält er Quell- und Zieladresse, die Kurznachricht, die Datenkodierung und das Flag für registered delivery. Optionale Parameter werden als Tag-Length-Value-Felder übertragen.

| Item | Value | Note |
| --- | --- | --- |
| command_length | 53 |  |
| command_id | 0x00000004 |  |
| command_status | 0x00000000 |  |
| sequence_number | 1 |  |
| service_type |  |  |
| source_addr_ton | 1 |  |
| source_addr_npi | 1 |  |
| source_addr | 12345 |  |
| dest_addr_ton | 1 |  |
| dest_addr_npi | 1 |  |
| destination_addr | 15551234567 |  |
| esm_class | 0x00 |  |
| protocol_id | 0x00 |  |
| priority_flag | 0 |  |
| schedule_delivery_time |  |  |
| validity_period |  |  |
| registered_delivery | 0x01 |  |
| replace_if_present_flag | 0x00 |  |
| data_coding | 0x00 |  |
| sm_default_msg_id | 0x00 |  |
| sm_length | 4 |  |
| short_message | 54657374 |  |
| Text | Test |  |

Source: SMPP-v3.4-Spezifikation, PDU-Header und submit_sm (https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## Ein Tag im Leben einer Nachricht

Der Client öffnet einen Transceiver-Bind und liest die Bind-Antwort. Er sendet eine Nachricht und speichert die Message-ID aus der Antwort. Das Message-Center leitet die Nachricht an das Zielnetz weiter. Minuten später kommt eine deliver_sm-PDU mit dem Zustellbericht an: die ursprüngliche Message-ID, ein Status und oft ein Netzcode. Der Client bestätigt den Zustellbericht und gleicht den Status mit seinem eigenen Datensatz ab.
Jeder Schritt hat ein eigenes Fehlerbild. Ein Bind kann wegen falscher Zugangsdaten oder einer falschen Schnittstellenversion abgelehnt werden. Ein Submit kann gedrosselt oder abgelehnt werden oder angenommen werden und dann im Zustellbericht scheitern. Ein Zustellbericht kann ankommen, nachdem der Code abgelaufen ist. Gestalten Sie den Client so, dass er die Message-ID speichert, einen verspäteten Zustellbericht annimmt und den eigenen Zustand der Anwendung als maßgebliche Quelle dafür behält, was der Nutzer getan hat.

Der Decoder läuft im Browser; der eingefügte Zustellbericht bleibt dort.

[Open the tool](/de/tools/smpp-decoder/?src=learn-what-is-smpp&scenario=dlr-example&sample=id%3A0123456789+sub%3A001+dlvrd%3A001+submit+date%3A2610181200+done+date%3A2610181201+stat%3ADELIVRD+err%3A000+text%3AYour+code+is+123456)

### Dekodieren Sie einen Zustellbericht, bevor Sie eine Route untersuchen

Fügen Sie einen Zustellbericht in den [SMPP- und DLR-Decoder](/de/tools/smpp-decoder/) ein und lesen Sie die Felder. Prüfen Sie die Message-ID, den Status, das Abschlussdatum und den Fehlercode. Lautet der Status nicht DELIVRD, kann der Fehlercode, gelesen anhand der Codetabelle des Anbieters, darauf hinweisen, ob die Nummer, das Endgerät oder das Netz die Nachricht abgelehnt hat. Tun Sie das, bevor Sie den Anbieter bitten, die Route zu ändern.

## Zustellberichte und Fehlersuche

Ein Zustellbericht ist asynchron. Er kommt über die Sitzung als deliver_sm-PDU an, und sein Format hängt vom Message-Center ab. Neuere Implementierungen übertragen den Status in einem message_state-Feld im Tag-Length-Value-Format. Ältere legen einen Textbericht in das Feld short_message, mit Schlüssel-Wert-Paaren wie id, stat und err. Werten Sie beide Formen aus, statt von einer auszugehen.
Ordnen Sie über die Message-ID zu, nicht über die Reihenfolge des Eingangs. Zwei Nachrichten, die im Abstand von einer Sekunde gesendet wurden, können in umgekehrter Reihenfolge zurückkommen, und eine Wiederholung kann ein Duplikat erzeugen. Speichern Sie die ID beim Submit, aktualisieren Sie den Datensatz, wenn der Zustellbericht ankommt, und ignorieren Sie einen zweiten Zustellbericht für dieselbe ID, sofern sein Status nicht neuer ist. Der [Verbindungsleitfaden](/de/resources/guides/smpp-http-connection/) macht daraus einen Betriebsablauf.

### Check what you learned

**Warum hilft ein zweiter Bind mehr als eine höhere Wiederholungsrate?**

Ein Bind trägt ein Fenster. Ein zusätzlicher Bind schafft Kapazität; Wiederholungen gegen ein volles Fenster erzeugen Warteschlange und Verzögerung.

**Woher kommt die Message-ID?**

Das Message-Center gibt sie in submit_sm_resp zurück. Speichern Sie sie und ordnen Sie den späteren Zustellbericht über diese ID zu.

**Was beweist ein Zustellbericht mit dem Status zugestellt?**

Dass das Netz die Nachricht angenommen und an den Übertragungsweg zum Endgerät zugestellt hat. Er beweist nicht, dass ein Mensch sie gelesen hat.

## FAQ

**Brauchen wir SMPP für den Start?**

Nein. HTTP lässt sich an einem Nachmittag integrieren; SMPP lohnt sich, sobald ein gleichmäßiges Volumen eine Sitzung rechtfertigt.

**Was ist ein Bind?**

Eine dauerhafte Sitzung mit einer festgelegten Richtung: Transmitter, Receiver oder Transceiver. Sie trägt eine Durchsatzzuteilung und bleibt durch Keep-Alive-Austausch offen.

**Was ist eine PDU?**

Protocol Data Unit: die binäre Nachricht, die SMPP austauscht. Jede PDU hat einen 16-Byte-Header und einen befehlsspezifischen Body.

**Können wir SMPP über das öffentliche Internet nutzen?**

Oft ja, mit TLS und IP-Allowlisting, aber fragen Sie den Anbieter. Manche Installationen nutzen stattdessen eine private Verbindung.

**Wie werden lange Nachrichten behandelt?**

Als verkettete Segmente mit einem User Data Header oder als message_payload-TLV, das das Netz segmentiert. Testen Sie das Ergebnis auf dem Endgerät.

## Sources

- [smpp.org: SMPP-Sitzungen, Bind-Operationen und Zustellberichte](https://smpp.org/) — Accessed: 2026-10-19
- [SMPP-v3.4-Spezifikation, Issue 1.2](https://smpp.org/SMPP_v3_4_Issue1_2.pdf) — Accessed: 2026-10-19
- [3GPP TS 23.040: Technical realization of the Short Message Service](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19