# SMPP: Der vollständige Protokollleitfaden.

- Kanonische URL: https://www.broadnet.me/de/developers/smpp
- Sprache: de
- Zuletzt aktualisiert: 2026-09-27
- Herausgeber: BroadNet (https://www.broadnet.me)
- Markdown-Fassung der Seite, aus der ausgelieferten Seite erzeugt.

Entwicklerhandbuch · Protokoll· /developers/smpp

SMPP – das **Short-Message-Peer-to-Peer** -Protokoll – ist das offene Protokoll auf TCP/IP-Ebene für den SMS-Austausch zwischen einer Anwendung (einem ESME) und dem Nachrichtenzentrum eines Mobilfunkbetreibers (einem SMSC/MC). Es ist das Arbeitspferd des A2P-Messaging: eine persistente Binärverbindung, die dafür gebaut ist, sehr große Nachrichtenmengen samt ihrer Zustellbestätigungen effizient und in Echtzeit zu übertragen. Dieser Leitfaden erklärt SMPP v3.4 – die vorherrschende Version – von Anfang bis Ende und zeigt, wo sich v5.0 unterscheidet.

Lesezeit: 18 Minuten · Aktualisiert im Juli 2026 [Entwicklerportal](https://www.broadnet.me/de/developers)

Auf dieser Seite

## Überblick

SMPP ist ein Protokoll der Telekommunikationsbranche, das Ende der 1990er Jahre von Aldiscon/Logica erstmals veröffentlicht und heute vom SMPP-Entwicklerforum weiterentwickelt wird. Es definiert, wie zwei Kommunikationspartner diskrete Einheiten, sogenannte PDUs (Protocol Data Units), über eine einzelne TCP-Verbindung austauschen: Die Anwendung bindet, sendet Nachrichten, empfängt Empfangsbestätigungen, hält die Verbindung aufrecht und trennt die Verbindung. Da es binär und verbindungsorientiert ist, bewältigt es konstant Arbeitslasten von Millionen von Nachrichten pro Tag mit deutlich geringerem Aufwand als das Öffnen einer HTTP-Anfrage pro Nachricht. Lesen Sie diese Seite vollständig durch, um jedes Feld einer realen SMPP-Sitzung zu verstehen.

## 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 `password` Die Richtung, in die die Sitzung Datenverkehr leiten darf, wird zum Zeitpunkt der Bindung durch Auswahl einer von drei Optionen festgelegt. **Bindungsmodi** Jeder Modus ist eine andere Bindungs-PDU.

Sender (TX)

bind_transmitter · 0x00000002

Nur zum Senden. Der ESME kann submit_sm senden, aber in dieser Sitzung keine deliver_sm empfangen. Empfangsbestätigungen müssen über eine separate Empfängerbindung erfolgen.

Empfänger (RX)

bind_receiver · 0x00000001

Nur Empfang. Das SMSC übermittelt deliver_sm (eingehende Nachrichten und DLRs) an das ESME, das in dieser Sitzung keine Nachrichten senden kann.

Transceiver (TRX)

bind_transceiver · 0x00000009

Beide Richtungen in einer Sitzung – submit_sm ausgehend, deliver_sm eingehend. Eingeführt in Version 3.4 und die empfohlene Standardeinstellung für neue Integrationen.

Ein vierter Schauspieler ist **Routing** Das 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.

Bevorzugen Sie eine Transceiver-Bindung

Sofern ein älteres SMSC die Aufteilung nicht erzwingt, sollte eine einzige bind_transceiver-Sitzung anstelle eines separaten Sender-Empfänger-Paares geöffnet werden. Dies vereinfacht die Aufrechterhaltung der Verbindung, die Wiederherstellung der Verbindung und korreliert Empfangsbestätigungen mit Übermittlungen über denselben Socket.

## 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.

ESME (Ihre App)

SMSC / MC (BroadNet)

bind_transceiver

Öffnen Sie die Sitzung mit system_id und Passwort.

1

2

bind_transceiver_resp

Bindung akzeptiert (command_status = ESME_ROK)

3

enquire_link / _resp

Keepalive alle ~30 s im Leerlauf

submit_sm

Senden Sie eine Nachricht an eine Ziel-MSISDN

4

5

submit_sm_resp

Gibt die SMSC message_id zurück.

6

deliver_sm

Zustellbestätigung (esm_class = 0x04) oder eingehender MO

deliver_sm_resp

ESME bestätigt den Empfang

7

unbind

Sitzung ordnungsgemäß beenden.

8

9

unbind_resp

SMSC bestätigt – TCP-Verbindung wird geschlossen

ESME → SMSC SMSC → ESME Keepalive (in beide Richtungen)

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 **PDU** Jede 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.

Byte 0

4

8

12

15

16 …

command_length 0–3 • 4 B

command_id 4–7 • 4 B

command_status 8–11 • 4 B

sequence_number 12–15 • 4 B

Körper · TLVs 16 … · Variable

Fester 16-Byte-Header (vier 32-Bit-Big-Endian-Ganzzahlen), gefolgt von einem Rumpf variabler Länge.

| Offset | Feld | Größe | Bedeutung |
|---|---|---|---|
| 0–3 | Befehlslänge | 4 Bytes | Gesamtlänge der gesamten PDU in Oktetten, einschließlich Header und Body. |
| 4–7 | Befehls-ID | 4 Bytes | Um welche Operation handelt es sich (z. B. submit_sm = 0x00000004)? Antworten setzen das oberste Bit (0x80000000). |
| 8–11 | Befehlsstatus | 4 Bytes | 0 in Anfragen; ein ESME_R* Ergebniscode in Antworten (0 = ESME_ROK = Erfolg). |
| 12–15 | Sequenznummer | 4 Bytes | Der Anrufer hat die ID 1…0x7FFFFFFF zugewiesen; die entsprechende _resp gibt sie zurück, um sie zu korrelieren. |
| 16… | Körper | Variable | Obligatorische Parameter für diesen Befehl, anschließend alle optionalen TLV-Parameter. |

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_

Dekodieren Sie eine echte PDU

Fügen Sie den rohen SMPP-Sechskant in das ein [SMPP PDU-Decoder](https://www.broadnet.me/de/tools/smpp-pdu-decoder) Um den 16-Byte-Header und jedes einzelne Feld des Datenkörpers aufgeschlüsselt zu sehen – der schnellste Weg, ein intuitives Verständnis für das oben beschriebene Byte-Layout zu entwickeln.

## 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.

| PDU | Befehls-ID | Zweck |
|---|---|---|
| bind_receiver | 0x00000001 | Öffnen Sie eine Sitzung, in der nur empfangen wird. |
| bind_transmitter | 0x00000002 | Öffnen Sie eine Sitzung nur zum Senden. |
| bind_transceiver | 0x00000009 | Öffnen Sie eine bidirektionale Sitzung (v3.4). |
| submit_sm | 0x00000004 | Senden Sie eine einzelne Nachricht an ein Ziel. |
| submit_multi | 0x00000021 | Senden Sie eine Nachricht an bis zu 254 Empfänger. |
| deliver_sm | 0x00000005 | SMSC → ESME: eine Zustellbestätigung oder eingehende (MO) Nachricht. |
| data_sm | 0x00000103 | TLV-basierte, bidirektionale Alternative zu submit_sm / deliver_sm. |
| query_sm | 0x00000003 | Erfragen Sie beim SMSC den aktuellen Status einer übermittelten Nachricht. |
| cancel_sm | 0x00000008 | Eine zuvor gesendete, noch nicht zugestellte Nachricht stornieren. |
| replace_sm | 0x00000007 | Ersetzen Sie den Inhalt/Zeitplan einer ausstehenden Nachricht. |
| enquire_link | 0x00000015 | Keepalive – bestätigen, dass die Sitzung noch aktiv ist. |
| unbind | 0x00000006 | SMPP-Sitzung ordnungsgemäß beenden. |
| generic_nack | 0x80000000 | Negative Bestätigung für eine nicht auswertbare/ungültige PDU. |

## 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.

| Feld | Was es tut |
|---|---|
| service_type | Optionale SMS Anwendungskategorie (z. B. leer oder ein Wert, den Ihr SMSC für Routing-/Abrechnungsklassen verwendet). |
| source_addr_ton / _npi | Nummerntyp und Nummerierungsplanindikator für den Absender. TON 5 = alphanumerisch (eine Absenderkennung); TON 1 = international E.164. |
| source_addr | Die Absenderadresse – ein Kurzcode, eine lange Nummer oder eine bis zu 11-stellige alphanumerische Absenderkennung. |
| dest_addr_ton / _npi | TON / NPI für das Ziel. Üblicherweise TON 1 (international), NPI 1 (ISDN / E.164). |
| destination_addr | Die MSISDN des Empfängers, normalerweise im internationalen Format ohne vorangestelltes +. |
| esm_class | Messaging-Modus/Typ-Bitmaske – z. B. wird die Anforderung einer Zustellbestätigung durch registered_delivery verarbeitet, während das UDHI Bit (0x40) angibt, dass short_message mit einem UDH beginnt. |
| data_coding | Der DCS: 0 = GSM 7-Bit (Standard), 3 = Latin-1, 8 = UCS-2 (Unicode). Bestimmt die Zeichenbegrenzung. |
| registered_delivery | Setzen Sie den Wert auf 1, um eine Zustellbestätigung (deliver_sm) für diese Nachricht anzufordern; auf 0, wenn keine Bestätigung angefordert wird. |
| sm_length / short_message | Die Nutzlastlänge (0–254) und die Nachrichtenoktette selbst, kodiert gemäß data_coding. |
| message_payload (TLV 0x0424) | Optionales TLV das den Nachrichtentext anstelle von short_message enthält – wird für längere Inhalte über 254 Oktette hinaus verwendet. |
| schedule_delivery_time / validity_period | Optionale absolute/relative Zeitangabe für die Zustellungsplanung und wie lange das SMSC die Zustellung wiederholen soll. |

Kurznachricht vs. Nachrichtennutzlast – wählen Sie eines aus

Der Inhalt einer Nachricht sollte entweder im obligatorischen Feld „short_message“ oder im TLV „message_payload“ enthalten sein, nicht in beiden. Wenn „message_payload“ vorhanden ist, muss „sm_length“ 0 sein. Die Vermischung beider Felder ist eine häufige Ursache für ESME_RINVMSGLEN-Fehler.

## 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.

| Datenkodierung | Codierung | Einzel | Verkettet |
|---|---|---|---|
| 0 | GSM 7-Bit-Standardalphabet | 160 Zeichen | 153 Zeichen / Teil |
| 3 | Latin-1 (ISO-8859-1), 8-Bit | 140 Zeichen | 134 Zeichen / Teil |
| 8 | UCS-2 (UTF-16BE) — Unicode | 70 Zeichen | 67 Zeichen / Teil |

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.

Zählen Sie die Segmente, bevor Sie sie senden

Schätzen Sie Teile und Kosten mit dem [SMS-Segmentrechner](https://www.broadnet.me/de/tools/sms-segment-calculator)— Es erkennt den Moment, in dem ein einzelnes Unicode-Zeichen eine ganze Nachricht von GSM-7 (160) auf UCS-2 (70) herunterskaliert.

## 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 (`0x04` Der Belegtext befindet sich im Feld „short_message“ als bekanntes Schlüsselwort:

deliver_sm · receipt text

```
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 ...

| Statistik | Bedeutung |
|---|---|
| DELIVRD | An das Mobiltelefon übermittelt. Erfolgsstatus. |
| EXPIRED | Die Gültigkeitsdauer ist vor der Zustellung abgelaufen – das SMSC hat die erneuten Zustellversuche eingestellt. |
| DELETED | Die Nachricht wurde im SMSC gelöscht. |
| UNDELIV | Unzustellbar — keine Route oder das Mobiltelefon konnte nicht erreicht werden. |
| ACCEPTD | Akzeptiert (z. B. manuell im SMSC gelesen) – ein Zwischenzustand. |
| UNKNOWN | Dem SMSC liegen keine Statusinformationen zu der Nachricht vor. |
| REJECTD | Abgelehnt vom SMSC oder einem nachgelagerten Netzwerk (z. B. blockierter Absender). |

Beantworten Sie eine deliver_sm-Nachricht immer mit einem `deliver_sm_resp` Andernfalls 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.

Belege analysieren

Fügen Sie eine Rohquittung in das Feld ein. [DLR-Decoder](https://www.broadnet.me/de/tools/dlr-decoder) um ID, Status, Fehler und die Zeitstempel für Absenden/Fertigstellen unabhängig von der genauen Formatierung des Anbieters aufzuschlüsseln.

## 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.

| Code | Wert | Bedeutung |
|---|---|---|
| ESME_ROK | 0x00000000 | Kein Fehler – Erfolg. |
| ESME_RINVMSGLEN | 0x00000001 | Ungültige Nachrichtenlänge (Problem sm_length / Nutzdaten). |
| ESME_RINVCMDLEN | 0x00000002 | Ungültige command_length – die PDU Rahmenstruktur ist fehlerhaft. |
| ESME_RINVCMDID | 0x00000003 | Unbekannte oder nicht unterstützte command_id. |
| ESME_RINVBNDSTS | 0x00000004 | Befehl im aktuellen Bindungszustand ungültig (z. B. Submit bei einer RX Bindung). |
| ESME_RALYBND | 0x00000005 | ESME ist bereits gebunden. |
| ESME_RINVSRCADR | 0x0000000A | Ungültige Absenderadresse (Sender-ID). |
| ESME_RINVDSTADR | 0x0000000B | Ungültige Zieladresse. |
| ESME_RBINDFAIL | 0x0000000D | Bindung fehlgeschlagen — falsche system_id / falsches Passwort. |
| ESME_RINVPASWD | 0x0000000E | Ungültiges Passwort. |
| ESME_RTHROTTLED | 0x00000058 | Drosselungsfehler – Sie haben die zulässige Nachrichtenrate überschritten. |
| ESME_RSUBMITFAIL | 0x00000045 | submit_sm / submit_multi fehlgeschlagen. |
| ESME_RSYSERR | 0x00000008 | SMSC Systemfehler. |

Das vollständige Verzeichnis – einschließlich der anbieterspezifischen Sortimente – ist durchsuchbar in der [SMPP-Fehlercode-Referenz](https://www.broadnet.me/de/tools/smpp-error-codes)

## 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.

Fenstergröße, nicht nur die Bewertung

Wenn Ihre effektive Transaktionsrate (TPS) deutlich unter dem SMSC-Maximum liegt, ist der Flaschenhals häufig eine Fenstergröße von 1 (synchrones Senden). Die Erhöhung des Fensters, sodass mehrere submit_sm-PDUs gleichzeitig ausstehen, führt in der Regel zur größten Durchsatzsteigerung.

## 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.

smpp-submit · illustrative

```
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.

Verbindung über SMPP

Fordern Sie einen Bind für Ihr Konto an, und unser Sales-Engineering-Team richtet Ihre system_id, Ihren TLS-Endpunkt, Ihre TPS und Ihre IP-Allowlist ein. Oder lesen Sie, wie das Gateway aufgebaut ist.

[Sprechen Sie mit dem Vertrieb.](https://www.broadnet.me/de/contact) [SMSC-Gateway](https://www.broadnet.me/de/operators/smsc-gateway) [A2P-SMS](https://www.broadnet.me/de/products/a2p-sms)

## Häufig gestellte Fragen

**Welchen Port verwendet SMPP?**

Der von der IANA registrierte Standardport für unverschlüsseltes SMPP ist TCP-Port 2775. Es gibt keinen einheitlichen Standard-TLS-Port – SMPP über TLS (SMPP over TLS) verwendet üblicherweise einen anbieterspezifischen Port wie 3550, 8775 oder 2776. Verwenden Sie daher immer den Port, den Ihr SMSC-Betreiber Ihnen zuweist. BroadNet veröffentlicht seinen Bind-Host, den unverschlüsselten Port und den TLS-Port zusammen mit Ihren Zugangsdaten.

**Worin besteht der Unterschied zwischen submit_sm und data_sm?**

submit_sm ist die primäre PDU, die ein ESME zum Senden einer einzelnen Kurznachricht verwendet. Sie enthält das klassische Feld short_message (bis zu 254 Oktette) sowie optionale TLVs. data_sm ist eine optimierte, symmetrische Alternative, die mit SMPP v3.4 eingeführt wurde. Sie enthält stets den Inhalt des message_payload-TLVs und kann in beide Richtungen fließen (ESME→SMSC oder SMSC→ESME). Der Großteil des A2P-Verkehrs verwendet submit_sm; data_sm kommt zum Einsatz, wenn die bidirektionale Struktur mit ausschließlich TLVs bevorzugt wird.

**Wie verarbeitet SMPP Unicode?**

Unicode wird durch Setzen von data_coding auf 8 (UCS-2 / UTF-16BE Big-Endian) gesendet. Ein einzelnes UCS-2-Segment umfasst 70 Zeichen; verkettete UCS-2-Teile umfassen jeweils 67 Zeichen, da 6 Oktette vom UDH-Verkettungsheader belegt werden. GSM 7-Bit (data_coding 0) ist der Standard für einfachen lateinischen Text mit 160/153 Zeichen.

**Was ist eine Transceiver-Bindung?**

Ein Transceiver-Bind (TRX-Bind) ist eine einzelne SMPP-Sitzung, die mit `bind_transceiver` geöffnet wird und über dieselbe TCP-Verbindung sowohl Nachrichten senden (`submit_sm`) als auch Nachrichten und Zustellbestätigungen empfangen kann (`deliver_sm`). Er ersetzt das ältere Verfahren, separate Sender- und Empfänger-Binds zu öffnen, und ist für die meisten modernen Integrationen die empfohlene Vorgehensweise.

**Warum sollte man SMPP einer HTTP-API vorziehen?**

SMPP ist ein persistentes, binäres TCP-Protokoll, das für dauerhaft hohen Durchsatz entwickelt wurde. Eine langlebige Verbindung vermeidet TLS/TCP-Handshakes pro Nachricht, unterstützt asynchrones Windowing (viele ausstehende submit_sm-Anfragen vor einer Bestätigung) und übermittelt Deliver_sm-Empfangsbestätigungen und vom Mobilgerät stammende Nachrichten in Echtzeit über denselben Socket. Bei sehr hohem, konstantem A2P-Datenvolumen ist es effizienter als HTTP-Anfrage/Antwort; HTTP REST ist einfacher für geringere Datenmengen und komplexere Kanäle.

**Was ist enquire_link?**

enquire_link ist eine schlanke Keepalive-PDU, die ein Peer sendet, um zu bestätigen, dass die SMPP-Sitzung und die zugrunde liegende TCP-Verbindung noch bestehen. Die Gegenseite antwortet mit enquire_link_resp. Sie wird typischerweise alle 30 Sekunden in Leerlaufzeiten gesendet. Bleiben mehrere enquire_link-Anfragen unbeantwortet, betrachtet der Peer die Verbindung als unterbrochen und stellt sie wieder her.

**Was bedeutet command_length in einem PDU-Header?**

Die erste 4-Byte-Variable des SMPP-PDU-Headers, `command_length`, gibt die Gesamtlänge der PDU in Oktetten an, einschließlich des 16-Byte-Headers und des gesamten Inhalts. Ein Empfänger liest diese 4 Bytes zuerst, um die genaue Anzahl der noch zu lesenden Bytes für die vollständige PDU zu ermitteln, bevor er `command_id`, `command_status` und `sequence_number` analysiert.

**Was ist ein Zustellbericht (DLR) in SMPP?**

Eine Zustellbestätigung ist die SMSC-Mitteilung an die ESME über den endgültigen Status einer übermittelten Nachricht. Sie trifft als deliver_sm PDU mit gesetztem esm_class-Zustellbestätigungsbit (0x04) ein. Die Kurznachricht enthält eine Zeichenfolge mit den Schlüsselwörtern id, sub, dlvrd, Übermittlungsdatum, Lieferdatum, stat und err, wobei stat den endgültigen Status wie DELIVRD, EXPIRED, UNDELIV oder REJECTD angibt.

## Verwandte Tools und Dokumente

[Werkzeug SMPP PDU-Decoder /tools/smpp-pdu-decoder](https://www.broadnet.me/de/tools/smpp-pdu-decoder) [Referenz SMPP-Fehlercodes /tools/smpp-error-codes](https://www.broadnet.me/de/tools/smpp-error-codes) [Werkzeug SMS-Segmentrechner /tools/sms-segment-calculator](https://www.broadnet.me/de/tools/sms-segment-calculator) [Werkzeug DLR-Decoder /tools/dlr-decoder](https://www.broadnet.me/de/tools/dlr-decoder) [Dokumente Entwicklerzentrum /developers](https://www.broadnet.me/de/developers) [Plattform SMSC-Gateway /operators/smsc-gateway](https://www.broadnet.me/de/operators/smsc-gateway)

Auf dem Drahtseil aufbauen

## Bereit für die Bindung über SMPP?

[Erhalten Sie SMPP-Zugriff](https://www.broadnet.me/de/contact) [Entwicklerportal](https://www.broadnet.me/de/developers)