Verkettete A2P-SMS-Segmente: So prüfen Sie vor dem Versand die tatsächliche Anzahl

Was als SMS-Segment zählt und warum die Anzahl der Zeichen nicht ausreicht

Ein Segment ist eine SMS-Sendeeinheit. Passt der Text nicht in die verfügbare Nutzlast, kann er in mehrere verkettete Teile aufgeteilt werden, die das Empfangsgerät wieder zusammensetzt. Deshalb reicht es nicht aus, die sichtbaren Zeichen zu zählen: Das Ergebnis hängt davon ab, wie sie codiert werden und wie viel Platz die technischen Informationen neben dem Text beanspruchen.

Die TP-UD-Nutzlast kann ausschließlich Nutzerdaten enthalten oder einen Header umfassen. Ist ein Header vorhanden, belegt auch dessen Länge einen Teil des verfügbaren Platzes. Bei der Verkettung identifiziert der Header die Nachricht und die Position jedes Teils.

• Verwechseln Sie sichtbare Unicode-Zeichen nicht mit übertragenen Einheiten.
• Die technische Segmentanzahl bestimmt nicht automatisch einen kommerziellen Tarif.
• Die tatsächlich verfügbare Kapazität hängt von der Codierung und der Verkettungsvariante ab.

GSM 7-Bit, Escape-Zeichen und Unicode

Bei GSM 7-Bit werden Zeichen durch Septette dargestellt. Allerdings benötigen nicht alle Symbole, die üblicherweise als einzelne Zeichen beschrieben werden, nur ein Septett: Zeichen aus der Erweiterungstabelle werden mit einer Escape-Sequenz dargestellt und belegen zwei Septette. Bei der Berechnung müssen daher codierte Einheiten gezählt werden, nicht nur Textpositionen.

Ist ein Zeichen nicht in den jeweils geltenden GSM-Tabellen enthalten, muss der Sender möglicherweise eine andere Codierung wie UCS2 verwenden. Dabei wird jedes Zeichen in 16-Bit-Einheiten dargestellt. Bei Emojis und anderen Zeichen außerhalb des GSM-Zeichenvorrats muss geprüft werden, welche Codierung das System tatsächlich auswählt. Es ist nicht ratsam, davon auszugehen, dass die Nachricht GSM 7-Bit beibehält.

Auch nationale Sprachentabellen können die Wahl und Berechnung beeinflussen. Die tatsächlich verwendete Codierung hängt vom Inhalt, der Konfiguration und der Implementierung des Senders oder der Route ab.

• Zählen Sie jedes GSM-7-Bit-Zeichen mit Escape-Sequenz als zwei Septette.
• Prüfen Sie, wie sich der Encoder bei Akzenten, Symbolen, Emojis und ungewöhnlichen Zeichen verhält.
• Gehen Sie bei SMPP nicht von einem Standardwert für data_coding aus: Laut SMPP v3.4 gibt es keinen.

Wie sich die Verkettung auf die Kapazität auswirkt

Bei der Verkettung wird Platz für einen User Data Header (UDH) reserviert, der die zum Wiederherstellen der Nachricht erforderlichen Informationen enthält. Der Header kann eine gemeinsame Referenz, die Gesamtzahl der Teile und die Sequenznummer umfassen. Bei GSM 7-Bit kann zusätzlich eine Bitauffüllung erforderlich sein, um den Text nach dem Header auszurichten.

Als normativen Richtwert legt 3GPP TS 23.040 bei einem Standard-Verkettungsheader mit 8-Bit-Referenz Kapazitäten von 153 GSM-7-Bit-Zeichen oder 67 UCS2-Zeichen pro Segment fest. Für die Variante mit 16-Bit-Referenz sind es 152 beziehungsweise 66. Das sind technische Richtwerte und keine Garantie dafür, dass alle Plattformen oder Routen dieselbe Variante verwenden.

Die Spezifikation verlangt außerdem, dass bestimmte Sequenzen nicht auf mehrere Segmente aufgeteilt werden: GSM-Escape-Zeichen und UCS2-Zeichen müssen vollständig bleiben. Eine einfache Aufteilung in Zeichenblöcke kann daher zu einer falschen Berechnung führen.

• Klären Sie, ob die Implementierung eine Verkettungsreferenz mit 8 oder 16 Bit verwendet.
• Verwenden Sie die Richtwerte nicht als Ersatz für die Prüfung des tatsächlich eingesetzten Headers.
• Unterscheiden Sie die technische Segmentierung von den mit jedem Anbieter vereinbarten Abrechnungsregeln.

Reproduzierbare Methode zur Berechnung der Segmente

Damit die Berechnung wiederholt und geprüft werden kann, muss sie auf dem exakten Text basieren, der versendet wird. Eine Vorschau kann sich durch Ersetzungen, Leerzeichen, Zeilenumbrüche oder durch eine Vorlage eingefügte Zeichen vom übertragenen Inhalt unterscheiden.

Wenden Sie dieses Verfahren vor dem Produktionseinsatz an und speichern Sie die Berechnungsausgabe zusammen mit der Sendeanfrage.

• 1. Erfassen Sie den endgültigen Text nach Personalisierung und Ersetzungen exakt.
• 2. Ermitteln Sie die Codierung und die tatsächlich verwendeten Tabellen des Encoders; leiten Sie sie nicht allein aus dem Erscheinungsbild des Textes ab.
• 3. Zählen Sie bei GSM 7-Bit die Septette und rechnen Sie Zeichen aus der Erweiterungstabelle als zwei Einheiten. Zählen Sie bei UCS2 die 16-Bit-Einheiten gemäß dem verwendeten Encoder.
• 4. Bestimmen Sie die Verkettungsvariante und den vom Header belegten Platz. Berücksichtigen Sie gegebenenfalls die Ausrichtung der Septette.
• 5. Berechnen Sie die erforderliche Anzahl der Teile und achten Sie darauf, Escape-Sequenzen und UCS2-Zeichen nicht aufzuteilen.
• 6. Speichern Sie das Ergebnis zusammen mit einer Version oder einem Hash des Textes, der Encoderkonfiguration und der vorbereiteten Nutzlast.

Testfälle vor Änderungen an Vorlagen oder Encodern

Testen Sie sowohl Grenzwerte als auch Änderungen der Codierung. Eine kurze Nachricht kann durch ein einziges zusätzliches Zeichen, das ein anderes Codierungsschema erzwingt, in mehrere Teile aufgeteilt werden. Ein Zeichen aus der Erweiterungstabelle kann zwei Septette belegen, obwohl es optisch nur eine Position einnimmt.

Verwenden Sie kontrollierte Testfälle und speichern Sie den exakten Text jedes Tests. Ändern Sie nicht gleichzeitig Inhalt, Codierung und Verkettungsvariante, da sich die Ursache einer Abweichung sonst nur schwer ermitteln lässt.

• Text ausschließlich mit Zeichen aus der GSM-Standardtabelle.
• Text mit Zeichen aus der Erweiterungstabelle.
• Text mit Akzenten, Symbolen oder Emojis, um mögliche Änderungen der Codierung zu beobachten.
• Nachrichten nahe den Grenzen für ein und mehrere Teile, mit der tatsächlich konfigurierten Referenzvariante.
• Änderungen an Zeilenumbrüchen, Leerzeichen und Vorlagenvariablen, die den endgültigen Text beeinflussen.

Sendeanfrage und Protokolle prüfen

Die lokale Berechnung muss mit den tatsächlich gesendeten Daten abgeglichen werden. Prüfen Sie bei SMPP den Wert von data_coding, den Inhalt von short_message oder – je nach Implementierung – message_payload sowie den UDH-Header oder die verwendeten SAR-Parameter. SMPP v3.4 definiert sar_msg_ref_num, sar_total_segments und sar_segment_seqnum zur Übermittlung von Referenz, Gesamtzahl und Sequenz. Die Spezifikation besagt, dass alle drei zusammengehörigen Parameter vorhanden sein müssen, damit die SAR-Referenz verarbeitet wird.

Eine erfolgreiche submit_sm_resp bestätigt das Ergebnis der Anfrage und kann eine message_id zurückgeben. Das Standardformat enthält jedoch kein Feld, das die Anzahl der akzeptierten Segmente bestätigt. Die Annahme der Anfrage ersetzt daher nicht den Abgleich mit den Protokollen der Plattform oder des Anbieters.

Bei Versand über eine HTTP-API sollten Sie in der API-Dokumentation prüfen, was die Antwort bedeutet und ob sie Segmentierungsdetails enthält. Gehen Sie nicht davon aus, dass eine Annahmebestätigung die technische Segmentanzahl ausweist.

• Vergleichen Sie Text oder Hash, Codierung, UDH oder SAR-Parameter und die Sendeantwort.
• Ordnen Sie die message_id den späteren Protokolleinträgen zu, sofern verfügbar.
• Beachten Sie die Dokumentation der API, des Anbieters und der Route, um gemeldete Felder richtig zu interpretieren.
• Verwechseln Sie Annahmebestätigung, DLR und eine unabhängige Bestätigung des Empfangs auf dem Endgerät nicht.

Abweichungen untersuchen und abgleichen, ohne Tarife abzuleiten

Eine Abweichung zwischen der lokalen Berechnung und einem externen Protokoll kann darauf zurückgehen, dass unterschiedliche Texte verglichen werden, eine andere Codierung ausgewählt wurde, eine andere Verkettungsvariante zum Einsatz kam oder die Plattform den Text umgewandelt hat. Es kann auch Unterschiede darin geben, welche Daten die einzelnen Systeme melden. Klären Sie zunächst, was tatsächlich gesendet wurde und welche Einheit die jeweilige Seite erfasst.

Halten Sie die technische Segmentanzahl und den kommerziellen Abgleich getrennt. Technische Normen beschreiben Codierung, Nutzlast und Verkettung; sie legen nicht den geltenden Tarif fest. Verwenden Sie für Beträge die maßgeblichen Vertragsbedingungen und Abrechnungsprotokolle.

• Bewahren Sie den exakten Text oder seinen Hash sowie die Vorlagenversion auf.
• Protokollieren Sie Codierung, data_coding, berechnete Einheiten und Verkettungsvariante.
• Speichern Sie den UDH-Header oder die SAR-Parameter, das Sendeergebnis und die message_id.
• Notieren Sie die von jedem System gemeldeten Segmente, deren Quelle und den Zeitraum.
• Untersuchen Sie zunächst jeweils nur eine Variable und dokumentieren Sie die Schlussfolgerung, bevor Sie Änderungen in der Produktion vornehmen.

Checkliste und technische Referenzen

Bevor Sie eine Vorlage freigeben oder den Versand ändern, vergewissern Sie sich, dass die Berechnung auf dem endgültigen Text beruht, die tatsächlich verwendete Codierung bekannt ist und die Verkettungsvariante mit der realen Konfiguration übereinstimmt. Wiederholen Sie den Test, wenn sich Inhalt, Encoder, API, SMPP-Sitzung oder Route ändern.

Für normative Details konsultieren Sie 3GPP TS 23.038 zu Alphabeten und Codierung, 3GPP TS 23.040 zur technischen Umsetzung von SMS und ihren Headern sowie SMPP v3.4 zu data_coding, Antworten und SAR-Parametern.

• Stimmt der Testtext bytegenau oder per Hash mit dem gesendeten Text überein?
• Wurden GSM 7-Bit, Escape-Zeichen und ein möglicher Wechsel zu UCS2 geprüft?
• Ist die Verkettungsvariante samt Header bestätigt?
• Werden Anfrage, Antwort, Kennung und relevante Protokolle aufbewahrt?
• Bleibt der technische Abgleich von der Auslegung der Tarife getrennt?