SMSC vs. SMS-Gateway vs. SMPP-Server: was jedes wirklich tut

Fragen Sie drei Anbieter, was sie verkaufen, und Sie hören womöglich „ein SMSC“, „ein SMS-Gateway“ und „ein SMPP-Server“ für etwas, das wie dasselbe Produkt aussieht. Die Begriffe sind nicht austauschbar, und die Verwechslung kostet Geld: Manche kaufen einen SMPP-Server in der Annahme, er erreiche Endgeräte, oder planen Budget für „ein SMSC“ ein, obwohl sie ein Gateway und zwei Carrier-Verträge brauchen. Dieser Leitfaden klärt die Frage SMSC vs. SMS-Gateway vs. SMPP-Server mit einfachen Definitionen, zeigt, wie die drei in einem realen Nachrichtenpfad zusammenhängen, und endet damit, welches davon Sie tatsächlich betreiben müssen.

SMSC vs. SMS-Gateway vs. SMPP-Server in einem Absatz

Ein SMSC sitzt im Netz eines Mobilfunkbetreibers und stellt Textnachrichten an Telefone zu. Ein SMS-Gateway sitzt außerhalb des Netzes, nimmt Nachrichten von Anwendungen und Kunden entgegen, leitet sie an die richtige Betreiberverbindung weiter und sammelt die Zustellberichte ein. Ein SMPP-Server ist eine Komponente eines Gateways, über die sich andere Systeme per SMPP-Protokoll mit dem Gateway verbinden, so wie sich das Gateway mit den Betreibern verbindet. SMSCs betreiben die Netzbetreiber. Unternehmen, die Nachrichten senden oder weiterverkaufen, betreiben Gateways. Gateways, die technische Kunden bedienen, betreiben zusätzlich SMPP-Server.

Alles Weitere in diesem Leitfaden ist dieser Absatz mit den Details.

SMSC: die Store-and-Forward-Maschine des Betreibers

Das Short Message Service Centre ist der Teil des Mobilfunknetzes, der für SMS zuständig ist. Wenn ein Telefon eine SMS sendet, geht sie an das SMSC des Betreibers, bei dem der Absender ist; das SMSC speichert sie, ermittelt, wo sich das Telefon des Empfängers befindet, und leitet sie weiter, mit erneuten Versuchen, wenn das Telefon ausgeschaltet oder außer Reichweite ist. Dieses Verhalten nach dem Prinzip „Speichern und Weiterleiten“ (Store and Forward) ist der Grund, warum eine SMS ankommt, sobald Sie Ihr Telefon wieder einschalten, und es ist das SMSC, das dafür sorgt.

Daraus folgen drei Dinge. Das SMSC spricht mit den Endgeräten über den Signalisierungskern des Netzes (SS7 oder, in neueren Kernnetzen, Diameter), und das ist eine Telekommunikationsbeziehung, kein Internetprotokoll. Das SMSC gehört dem Betreiber, und jeder Betreiber hat sein eigenes; ein globales SMSC gibt es nicht. Und das SMSC ist das Einzige in diesem Artikel, das eine Nachricht auf ein Telefon bringen kann. Alles andere ist ein Weg, eine Nachricht zu einem SMSC zu bringen.

Unternehmen erreichen ein SMSC auf einem von zwei Wegen: über einen Aggregator, der bereits Verbindungen zu vielen Betreibern hat, oder direkt, mit einem Vertrag und einem SMPP-Bind, den der Betreiber bereitstellt. In beiden Fällen ist das Unternehmen Kunde des SMSC, nicht dessen Betreiber. Produkte, die als „SMSC für Unternehmen“ vermarktet werden, sind Gateways, die SMPP-Binds annehmen; sie stellen nicht aus eigener Kraft an Endgeräte zu.

SMS-Gateway: Router, Hauptbuch und Dashboard

Ein SMS-Gateway ist das System, das ein Unternehmen betreibt, um Nachrichten in großem Umfang zu senden und, falls es weiterverkauft, seine eigenen Kunden senden zu lassen. Die Arbeit des Gateways ist alles zwischen „eine Nachricht wurde eingereicht“ und „hier ist der Zustellbericht“:

• Nachrichten annehmen aus einer Webkonsole, einer HTTP-API, einem Datei-Upload oder einem SMPP-Bind.
• Validieren: Regeln für Absenderkennungen, Kodierung, Länge, das Guthaben des Kunden.
• Routing: entscheiden, welche Betreiberverbindung oder welcher Aggregator diese Nachricht an dieses Ziel transportiert, nach Preis, Qualität oder Vertrag.
• Zustellen über die gewählte Verbindung, meist per SMPP an einen Carrier oder Aggregator, manchmal per HTTP an einen Anbieter, unter Einhaltung von Rate und Fenster der Verbindung.
• Zustellberichte einsammeln und den Nachrichten zuordnen, damit „zugestellt“, „fehlgeschlagen“ oder „abgelaufen“ beim Kunden und im Hauptbuch ankommt.
• Abrechnen: dem Kunden jede Nachricht berechnen, die Kosten der Route erfassen und die Marge anzeigen.
• Berichte für den Kunden und für den Betreiber des Gateways.

Das Gateway kann eine einzelne Engine sein (Kannel ist die bekannteste Open-Source-Engine; sie verwaltet Binds, Warteschlangen und Zustellberichte und nichts darüber) oder eine vollständige Plattform, in der die Engine eine Schicht unter einem Portal, einer Routing-Tabelle, drei Abrechnungsmodellen und einem Berichts-Stack ist. Die Plattformseite zeichnet diesen vollständigen Stack für Smppcube in einem einzigen Diagramm: NGINX, die PHP-Konsole und die Node.js-Pipeline, Redis-Warteschlangen, MySQL als Aufzeichnungssystem, MongoDB für Archive, Elasticsearch für die Suche und darunter Kannel, das mit den SMSCs spricht. All das zusammen ist „das SMS-Gateway“. Kannel allein ist die Zustell-Engine.

Ein Gateway trägt auch die Teile des Geschäfts, die nichts mit Protokollen zu tun haben: Kundenkonten, Preislisten pro Ziel, Prepaid-Guthaben und Postpaid-Salden, Rechnungen, Reseller-Portale und die Marge pro Route, die darüber entscheidet, ob der Betrieb Geld verdient. Diese Teile sind der Grund, warum der Kauf eines Gateways eine andere Entscheidung ist als der Download einer Engine.

SMPP-Server: die Tür, an die sich Ihre Kunden binden

SMPP, das Protokoll, auf das sich die Carrier standardisieren, ist ein Client-Server-Protokoll. Wenn sich Ihr Gateway an einen Betreiber bindet, ist die Seite des Betreibers der SMPP-Server und Ihre Seite der Client. Wenn sich Ihre eigenen Kunden per SMPP an Sie binden wollen, müssen Sie der Server sein. Diese Komponente ist der SMPP-Server: Er lauscht auf einem Port (per Konvention 2775), authentifiziert Binds mit system_id und Passwort, nimmt submit_sm-Pakete an, gibt Nachrichten-IDs zurück, setzt den Durchsatz pro Konto durch und schickt die Zustellberichte über die Sitzung zurück.

Er ist, mit anderen Worten, ein weiterer Eingang in das Gateway. Nachrichten, die über den SMPP-Server eintreffen, landen in derselben Warteschlange, derselben Routing-Tabelle und demselben Hauptbuch wie Nachrichten aus der HTTP-API und der Konsole; der Leitfaden zu SMPP und HTTP erklärt, warum eine Plattform beides braucht und wie sich beide in der Praxis unterscheiden. Was ein SMPP-Server nicht ist: ein Weg zu den Endgeräten. Er ist eine Tür hinein, keine Tür hinaus. Ein Unternehmen, das nur senden muss, braucht nie einen. Ein Unternehmen, das Banken, OTP-Anbieter und andere Aggregatoren als Kunden gewinnen will, braucht einen an dem Tag, an dem der erste von ihnen danach fragt.

Wie die drei in einem realen Nachrichtenpfad zusammenhängen

Setzt man die drei zusammen, sieht der Weg einer Nachricht vom Kunden eines Resellers zu einem Telefon so aus:

1. Der Kunde reicht die Nachricht beim Gateway des Resellers ein, über die Webkonsole, die HTTP-API oder einen Bind an den SMPP-Server des Resellers.
2. Das Gateway validiert sie, belastet das Guthaben des Kunden und wählt eine Route für das Ziel.
3. Die Engine des Gateways sendet sie über einen SMPP-Bind (oder einen HTTP-Aufruf) an einen Aggregator oder direkt an den Zielbetreiber.
4. Das SMSC des Betreibers speichert die Nachricht, findet das Telefon und stellt sie zu.
5. Das SMSC schickt einen Zustellbericht über dieselbe Kette zurück; das Gateway ordnet ihn der Nachricht zu, schließt die Buchung im Hauptbuch ab und leitet ihn an den Kunden weiter (als deliver_sm auf dessen SMPP-Bind oder als Webhook an dessen API).

Zwei Beobachtungen. Erstens: Der SMPP-Server des Resellers und das SMSC des Betreibers sprechen nie direkt miteinander; das Gateway dazwischen spricht SMPP vorgelagert als Client und nachgelagert als Server, und deshalb werden die Begriffe verwechselt. Zweitens: Dasselbe Gateway kann gleichzeitig Kunde mehrerer SMSCs und Aggregatoren sein, und darauf beruht das gesamte Routing: Die Nachricht nimmt die Verbindung, die für dieses Ziel am günstigsten, am besten oder vertraglich vereinbart ist.

Wer was betreibt

	SMSC	SMS-Gateway	SMPP-Server
Wo es läuft	Im Kernnetz eines Mobilfunkbetreibers	Auf einem Server, den das Unternehmen kontrolliert (oder als SaaS gemietet)	Im Gateway, als einer seiner Eingänge
Wer es betreibt	Mobilfunkbetreiber	Unternehmen, Reseller, Aggregatoren, CPaaS-Plattformen	Gateways, die technische Kunden bedienen
Spricht mit	Endgeräten (über SS7/Diameter) und angebundenen Gateways	Vorgelagert mit SMSCs, Aggregatoren, HTTP-Anbietern; nachgelagert mit Kunden	Kunden, die sich per SMPP binden
Erreicht ein Telefon allein	Ja	Nur über ein SMSC	Nein
Beispiele	Eigene Systeme der Betreiber	Kannel (Engine); vollständige Plattformen wie Smppcube	In eine Plattform eingebaut oder auf eine Engine aufgesetzt

Der Hinweis „als SaaS gemietet“ in der Gateway-Spalte betrifft die andere häufige Verwechslung: Ein gehostetes SMS-Panel ist ebenfalls ein Gateway, eines, das jemand anderes betreibt und auf das Sie als Mandant zugreifen. Der Leitfaden zum selbst gehosteten Gateway ist der ehrliche Vergleich zwischen dem eigenen Betrieb eines Gateways und der Miete eines Platzes auf einem fremden.

Welches davon Sie betreiben müssen

Wenn Sie Nachrichten aus einer einzigen Anwendung senden (OTPs, Warnmeldungen, Benachrichtigungen) und keine eigenen Kunden haben, brauchen Sie keines davon. Die HTTP-API eines Aggregators ist ein Gateway, dessen Kunde Sie sind; Ihre einzige Entscheidung ist die Wahl des Anbieters.

Wenn Sie Messaging weiterverkaufen, Kampagnen für andere fahren oder Messaging für viele interne Teams betreiben, brauchen Sie ein Gateway. Gemietet oder selbst gehostet ist die nächste Frage, und sie entscheidet sich an Daten, Marge und Anbieterbindung, nicht an der Technik; eine einmalige Lizenz wie die von Smppcube auf Ihrem eigenen Server ist das selbst gehostete Ende dieser Wahl.

Wenn zu Ihren Kunden jemand mit einer SMPP-Client-Bibliothek gehört (Banken, OTP-Anbieter, Marketingplattformen, andere Aggregatoren), braucht Ihr Gateway einen SMPP-Server. Manche Plattformen bringen einen mit; bei einer reinen Engine ergänzen Sie ihn selbst.

Sie brauchen kein SMSC. Ohne Netzbetreiber zu sein, können Sie keines betreiben, und Sie müssen es auch nicht: Das SMSC jedes Betreibers ist über einen Bind oder einen Aggregator erreichbar. Die praktische Fassung von „wir brauchen ein SMSC“ lautet fast immer „wir brauchen ein Gateway mit SMPP-Server und zwei oder drei Carrier-Verträge“, und das ist ein weit kleineres und weit günstigeres Problem.

Außerhalb eines Netzbetreibers betreibt niemand ein SMSC. Was Unternehmen betreiben, ist ein Gateway, und woran sich technische Kunden binden, ist der SMPP-Server dieses Gateways. Ordnen Sie das Vokabular, und die Einkaufsliste ordnet sich von selbst.

Eine Anmerkung zu den Namen, die Anbieter verwenden

Weil sich die Begriffe im Marketing überschneiden, lesen Sie die Funktionsliste statt des Etiketts. Ein Produkt namens „SMSC-Software“, das SMPP-Binds, Routing und Abrechnung aufführt, ist ein Gateway. Ein „SMPP-Server“, der Kundenkonten, Preislisten und ein Portal aufführt, ist ein Gateway mit einem SMPP-Eingang. Ein „SMS-Gateway“, das nur ein REST-Endpunkt ohne Routing-Tabelle ist, ist die API eines einzelnen Anbieters. Keines davon ist ein Fehlkauf; es geht darum zu wissen, was es tut, bevor Sie Preise vergleichen, und bei allem, was Sie wählen, zu prüfen, dass es auf einem Server liegt, den Sie erreichen können, und Datensätze führt, die Sie exportieren können.