# SMPP submit_sm: jedes Pflichtfeld

> submit_sm (command_id 0x00000004) sendet eine mobil-terminierte Nachricht von der ESME an das SMSC. Der Body ist eine feste Folge von Pflichtfeldern — Adressierung (TON/NPI + Adresse), esm_class, protocol_id, priority_flag, Terminierung, registered_delivery, data_coding, sm_length und short_message — optional gefolgt von TLVs. submit_sm_resp gibt die message_id des SMSC zurück.

- Kanonische URL: https://www.broadnet.me/de/reference/smpp-submit-sm
- Sprache: de
- Zuletzt aktualisiert: 2026-07-18
- Herausgeber: BroadNet (https://www.broadnet.me)

Eine vollständige feldweise Referenz für submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message und den Rest — mit den Werten, die wirklich zählen.

## Die vollständige Reihenfolge der Pflichtfelder

Der Body von submit_sm ist eine feste, geordnete Folge — es gibt keine Feld-Tags, sodass Reihenfolge und Größe alles bestimmen. Die Tabelle listet alle Pflichtparameter in Wire-Reihenfolge. short_message darf leer sein, wenn der Text stattdessen in einem message_payload-TLV getragen wird; befüllen Sie niemals beide.

*submit_sm-Pflichtparameter (in Wire-Reihenfolge)*

| # | Feld | Typ | Anmerkungen |
|---|---|---|---|
| 1 | service_type | C-Octet String (6) | Servicekategorie; normalerweise leer |
| 2 | source_addr_ton | Integer (1) | Nummerntyp des Absenders |
| 3 | source_addr_npi | Integer (1) | Nummernplan des Absenders |
| 4 | source_addr | C-Octet String (21) | Absenderadresse / alphanumerische ID |
| 5 | dest_addr_ton | Integer (1) | Nummerntyp des Empfängers |
| 6 | dest_addr_npi | Integer (1) | Nummernplan des Empfängers |
| 7 | destination_addr | C-Octet String (21) | Empfänger-MSISDN |
| 8 | esm_class | Integer (1) | Nachrichtenmodus + Typ + UDHI-Flag |
| 9 | protocol_id | Integer (1) | GSM TP-PID; üblicherweise 0 |
| 10 | priority_flag | Integer (1) | 0 (normal) – 3 (höchste) |
| 11 | schedule_delivery_time | C-Octet String (1\|17) | Leer = sofort |
| 12 | validity_period | C-Octet String (1\|17) | Leer = SMSC Standard |
| 13 | registered_delivery | Integer (1) | Zustellbestätigung anfordern |
| 14 | replace_if_present_flag | Integer (1) | 0 = nein, 1 = ersetzen |
| 15 | data_coding | Integer (1) | Kodierung / DCS |
| 16 | sm_default_msg_id | Integer (1) | Vordefinierte Nachrichten-ID; normalerweise 0 |
| 17 | sm_length | Integer (1) | Länge von short_message (0–254) |
| 18 | short_message | Octet String (0–254) | Die Nachrichten-Payload |

## Adressierung: TON und NPI

source_addr und destination_addr tragen jeweils einen Type of Number (TON) und einen Numbering Plan Indicator (NPI). Für eine internationale MSISDN verwenden Sie TON 1 (International) mit NPI 1 (ISDN/E.164). Für eine alphanumerische Absenderkennung verwenden Sie TON 5 (Alphanumeric) — die source_addr enthält dann bis zu 11 GSM-7-Zeichen. Falsche TON/NPI sind eine führende Ursache für nicht zugestellten oder fehlgeleiteten Verkehr.

*Gängige TON- und NPI-Werte*

| TON | Bedeutung | NPI | Bedeutung |
|---|---|---|---|
| 0 | Unbekannt | 0 | Unbekannt |
| 1 | International | 1 | ISDN (E.163/E.164) |
| 2 | National | 3 | Daten (X.121) |
| 3 | Netzwerkspezifisch | 4 | Telex (F.69) |
| 4 | Teilnehmernummer | 6 | Land Mobile (E.212) |
| 5 | Alphanumerisch | 8 | National |
| 6 | Abgekürzt | 9 | Privat |

## esm_class

esm_class ist ein Bitfeld, das den Messaging-Modus, den Nachrichtentyp und GSM-spezifische Funktionen festlegt. Das wichtigste Bit für Absender ist UDHI (0x40): Setzen Sie es, wenn short_message mit einem User Data Header beginnt, zum Beispiel einem Verkettungs-Header. Bit 0x80 fordert den GSM-Reply-Path an.

*Bedeutung der esm_class-Bits (Auswahl)*

| Bits | Feld | Wert → Bedeutung |
|---|---|---|
| 1–0 | Messaging-Modus | 0 Standard · 1 Datagramm · 2 Weiterleitung · 3 Speichern und Weiterleiten |
| 5–2 | Nachrichtentyp | 0 Standard · 0x04 Zustellbestätigung · 0x08 Zustell-Ack · 0x10 Benutzerbestätigung |
| 6 | UDHI | 0x40 = short_message begins with a UDH |
| 7 | Antwortpfad | 0x80 = set GSM reply path |

## data_coding, registered_delivery und Gültigkeit

data_coding wählt die Textcodierung: 0x00 = SMSC-Standard (typischerweise GSM 7-bit), 0x04 = 8-bit-Binär, 0x08 = UCS-2 für Unicode. Die beiden unteren Bits von registered_delivery steuern die Berichte: 0 = keine, 1 = Bericht bei endgültigem Erfolg oder Fehlschlag, 2 = nur bei Fehlschlag. validity_period und schedule_delivery_time verwenden die absolute Form YYMMDDhhmmsstnnp oder eine relative Form; ein leerer String bedeutet sofortige Zustellung und die Standardgültigkeit des SMSC. Halten Sie validity_period bei OTPs eng, damit ein verzögerter Code abläuft, statt veraltet anzukommen.

*data_coding — die Werte, die Sie tatsächlich verwenden*

| Wert | Kodierung |
|---|---|
| 0x00 | SMSC-Standardalphabet (üblicherweise GSM 7-Bit) |
| 0x03 | Latin-1 (ISO-8859-1) |
| 0x04 | 8-Bit-Binär (Oktett nicht spezifiziert) |
| 0x08 | UCS-2 (UTF-16BE) — Unicode |

## Die Response

submit_sm_resp (0x80000004) gibt command_status zurück und, bei Erfolg, eine message_id (C-Octet String, bis zu 65 Zeichen), die das SMSC der Nachricht zuweist. Speichern Sie sie: Sie ist der Schlüssel, den Sie gegen die receipted_message_id im Zustellbericht abgleichen. Achten Sie auf Formatabweichungen — manche SMSCs geben die ID beim Submit hexadezimal und im DLR dezimal zurück, normalisieren Sie daher beide bei der Korrelation.

## Häufige Fragen

### Welche TON/NPI verwende ich für eine alphanumerische Absenderkennung?

Verwenden Sie source_addr_ton = 5 (Alphanumeric) und source_addr_npi = 0 (Unknown). Die source_addr enthält dann bis zu 11 GSM-7-Zeichen. Alphanumerische Absenderkennungen sind reine Anzeigekennungen und können keine Antworten empfangen.

### Wie fordere ich in submit_sm einen Zustellbericht an?

Setzen Sie registered_delivery = 1, um einen Bericht bei endgültiger Zustellung oder Fehlschlag zu erhalten, oder 2 nur bei Fehlschlag. Fordern Sie Berichte nur dort an, wo Sie sie tatsächlich verarbeiten, da ungelesene DLRs Durchsatz verschwenden.

### Was ist die maximale Länge von short_message?

Das Feld short_message fasst bis zu 254 Oktette, wobei sm_length die genaue Anzahl angibt. Für längeren Text segmentieren Sie entweder mit einem UDH über mehrere submit_sm-PDUs oder tragen die gesamte Nutzlast im message_payload-TLV statt in short_message.

### Kann ich sowohl short_message als auch message_payload setzen?

Nein. Befüllen Sie das eine oder das andere. Anbieter weisen ein submit_sm zurück, das die Nachricht sowohl im Pflichtfeld short_message als auch im message_payload-TLV trägt.

### Wie sende ich eine Unicode-Nachricht?

Setzen Sie data_coding = 0x08 (UCS-2) und codieren Sie den Text als UTF-16 Big-Endian in short_message. Eine einzelne UCS-2-SMS fasst 70 Zeichen; längerer Unicode-Text wird bei 67 Zeichen je Teil segmentiert.

## Quellen

- [SMPP v3.4 specification — §4.4 submit_sm](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [3GPP TS 23.040 — SMS technical realization](https://www.3gpp.org/dynareport/23040.htm)

## Verwandte Seiten

- [SMPP deliver_sm & MO-Nachrichten](https://www.broadnet.me/de/reference/smpp-deliver-sm)
- [Datenkodierungsschema (DCS)](https://www.broadnet.me/de/reference/data-coding-scheme-dcs)
- [SMS Segmentierung & UDH](https://www.broadnet.me/de/reference/sms-segmentation-concatenation-udh)
- [SMPP-PDU-Decoder (kostenloses Tool)](https://www.broadnet.me/de/tools/smpp-pdu-decoder)
- [SMS API Produkt](https://www.broadnet.me/de/products/sms-api)