Eskalation von A2P-SMS-Störungen zwischen Anbietern: Zuständigkeiten und Nachweise
Ein praxisorientierter Leitfaden zur Koordination von Untersuchungen zu A2P-SMS über mehrere Anbieter hinweg, zur Dokumentation der Beobachtungen und dazu, Ursachen nicht ohne ausreichende Nachweise zuzuschreiben.
Warum eine Störung mehrere betriebliche Zuständigkeitsbereiche betreffen kann
In einer Großhandelskette kann eine Nachricht mehrere Unternehmen oder Systeme durchlaufen, bevor sie ihr Ziel erreicht. Die für diesen Leitfaden verfügbaren Nachweise erlauben keine Aussage darüber, was die einzelnen Beteiligten sehen, wie Protokolle zwischen Betreibern abgeglichen werden oder welches System eine Störung verursacht hat. Ein Kundenbericht allein reicht daher nicht aus, um eine Ursache zuzuschreiben.
Als betriebliche Vorsichtsmaßnahme kann es hilfreich sein, direkt beobachtete Daten von Informationen zu unterscheiden, die von anderen Beteiligten stammen. Eine solche Gliederung hilft dabei, klar zu beschreiben, was bekannt und was nicht bestätigt ist. Sie stellt jedoch kein hier durch einen technischen Standard gestütztes Verfahren dar.
- Beschreiben Sie, welche Informationen Sie direkt beobachtet und welche Sie von anderen Beteiligten erhalten haben.
- Gehen Sie nicht davon aus, dass alle Beteiligten dieselben Referenzen, Statusangaben oder Zeitfenster verwenden.
- Kennzeichnen Sie ungeklärte Punkte, statt eine vorläufige Erklärung als Ursache darzustellen.
Benennen Sie eine fallverantwortliche Person und Kontakte für die einzelnen Abschnitte
Als Vorschlag für die interne Organisation können Sie eine Person oder ein Team benennen, das die Fallinformationen zusammenführt und die Kommunikation koordiniert. Das bedeutet nicht, dass diese Stelle Systeme Dritter kontrolliert oder allein feststellen kann, wo ein Problem entstanden ist.
Die verfügbaren Nachweise legen weder fest, wie Zuständigkeiten zwischen Anbietern verteilt werden sollten, noch welche Eskalationskanäle, Fristen oder Anforderungen gelten. Wenn solche Punkte intern oder zwischen den Beteiligten vereinbart werden, sollten sie als Vereinbarungen gekennzeichnet und nicht als allgemeingültige Regeln dargestellt werden.
- Vergeben Sie bei Bedarf für Ihre Organisation eine interne Fallreferenz.
- Ermitteln Sie die vereinbarten Ansprechpartner und Kommunikationskanäle.
- Stellen Sie Prioritäten oder Aktualisierungsintervalle nicht als allgemeingültige Anforderungen dar.
- Unterscheiden Sie die Fallkoordination von der technischen Untersuchung durch die einzelnen Anbieter.
Sammeln Sie vor der Eskalation hilfreiche Daten
Die verfügbaren Nachweise legen nicht fest, welche Daten mindestens erforderlich oder ausreichend sind, um eine Nachricht anbieterübergreifend abzugleichen. Als praktischer Vorschlag kann eine Anfrage die Informationen beschreiben, die in den eigenen Systemen vorliegen, und die andere Partei fragen, welche Daten sie für die Prüfung ihrer Protokolle benötigt.
Geben Sie Quelle und Kontext jeder Angabe an und nennen Sie, sofern relevant, Uhrzeit und Zeitzone. Wenn Sie Informationen zu Empfängern oder Absendern weitergeben, verwenden Sie nur die erforderlichen Daten und von Ihrer Organisation zugelassene Kanäle.
- Interne Fallreferenz und weitere verfügbare Referenzen.
- Für die Anfrage relevante Empfänger- und Absenderangaben, unter angemessenem Schutz der Daten.
- Datum, Uhrzeit, Zeitzone und Quellsystem für jede Zeitangabe.
- Empfangener Status, genaue Bezeichnung des Felds oder Ereignisses sowie die meldende Quelle.
- Route oder Konfiguration, sofern diese in den abgefragten Protokollen vermerkt ist.
- Konkrete Beschreibung der beobachteten Auswirkungen und des bekannten Umfangs, ohne daraus weitere Schlüsse abzuleiten.
Unterscheiden Sie zwischen Beobachtungen, erhaltenen Informationen und Hypothesen
Als vorgeschlagene Dokumentationspraxis können Sie Protokolle aus dem eigenen System von Aussagen der Anbieter und noch nicht bestätigten Erklärungen getrennt erfassen. So wird die Quelle jeder Aussage deutlich. Die verfügbaren Nachweise begründen dies nicht als technische oder offizielle Anforderung.
Bewahren Sie den Kontext der für die Untersuchung relevanten Daten und Mitteilungen. Kennzeichnen Sie Deutungen als solche und geben Sie an, welche Informationen zu ihrer Bestätigung noch fehlen.
- Eigene Beobachtung: Nennen Sie das System und das abgefragte Protokoll.
- Information eines Anbieters: Halten Sie fest, wer sie wann mitgeteilt hat.
- Hypothese: Kennzeichnen Sie sie als vorläufig und nennen Sie die noch erforderlichen Prüfungen.
- Leiten Sie eine Ursache nicht allein daraus ab, dass zwei Ereignisse zeitlich zusammenfallen.
Vereinbaren Sie Prioritäten, Aktualisierungen und Eskalationswege
Die bereitgestellten Nachweise legen weder Reaktionsfristen, Prioritäten und Eskalationsstufen noch allgemeingültige Kriterien für deren Vergabe fest. Wenn die Beteiligten solche Vorgaben benötigen, können sie diese entsprechend ihrer Zusammenarbeit vereinbaren und dokumentieren, dass es sich um Absprachen zwischen ihnen handelt.
Beschreiben Sie die beobachteten Auswirkungen und den bekannten Umfang. Versprechen Sie weder eine Lösung noch einen Zeitrahmen, der von den zuständigen Beteiligten nicht bestätigt wurde.
- Dokumentieren Sie die vereinbarten Kriterien, wenn Prioritäten festgelegt werden.
- Vereinbaren Sie mit den Beteiligten Format und Häufigkeit der Aktualisierungen.
- Halten Sie zusätzliche Eskalationen und den dafür mitgeteilten Grund fest.
- Verwenden Sie für zusammengehörige Mitteilungen eine einheitliche Referenz, sofern die Beteiligten dies umsetzen können.
Interpretieren Sie Statusmeldungen und DLR mit Vorsicht
Die verfügbaren Nachweise enthalten keine relevante technische Spezifikation, anhand derer sich bestimmen ließe, was ein DLR in einer konkreten Implementierung bedeutet oder in welchem Abschnitt es erzeugt wird. Aus den vorliegenden Informationen lässt sich daher nicht ableiten, dass ein DLR den Empfang oder das Lesen der SMS auf dem Endgerät bestätigt.
Bitten Sie um Dokumentation, die für die jeweilige Implementierung und das meldende System gilt, bevor Sie einen Status beschreiben. Liegen solche Informationen nicht vor, beschränken Sie die Zusammenfassung darauf, anzugeben, welcher Status von wem und in welchem Kontext empfangen wurde. Machen Sie ausdrücklich kenntlich, was nicht überprüft werden konnte.
- Bewahren Sie den Wortlaut der Statusmeldung auf und halten Sie fest, wer sie übermittelt hat.
- Stellen Sie ein DLR ohne einschlägige Dokumentation nicht als Beleg für den Empfang oder das Lesen auf dem Endgerät dar.
- Gehen Sie nicht davon aus, dass ähnlich bezeichnete Statusmeldungen in verschiedenen Systemen dieselbe Bedeutung haben.
- Unterscheiden Sie den empfangenen Status von Sachverhalten, die unabhängig davon überprüft wurden.
Dokumentieren Sie den zeitlichen Verlauf des Falls
Als Vorschlag für das Fallmanagement können Sie die für die Untersuchung relevanten Informationen in einer Fallakte zusammenführen und jeweils Quelle und Eingangszeitpunkt angeben. Die bereitgestellten Nachweise legen keine Anforderungen an Audits, die Aufbewahrung von Protokollen oder Speicherfristen für A2P-Vorfälle zwischen Anbietern fest.
Wenn während einer Untersuchung eine Route oder Konfiguration geändert wird, beschreiben Sie die Änderung und den mitgeteilten Zweck. Schreiben Sie eine spätere Änderung des Ergebnisses dieser Anpassung nicht zu, wenn keine Nachweise den Zusammenhang belegen.
- Notieren Sie relevante Mitteilungen und Entscheidungen, mit denen sich der Fall nachvollziehen lässt.
- Geben Sie, sofern verfügbar, Quelle und Zeitpunkt der erfassten Daten an.
- Beschreiben Sie Änderungen an Route oder Konfiguration und den dafür genannten Grund.
- Beachten Sie die geltenden internen Richtlinien und Vereinbarungen zu Zugriff und Aufbewahrung.
Schließen Sie den Fall ab und halten Sie offene Punkte fest
Beim Abschluss einer Fallakte können Sie zusammenfassen, was beobachtet wurde, welche Erklärungen von den Beteiligten bestätigt wurden und welche Fragen offenbleiben. Die bereitgestellten Nachweise legen weder offizielle Abschlusskategorien noch technische Kriterien zur Ursachenbestimmung fest.
Wenn Folgemaßnahmen vereinbart werden, halten Sie fest, wer sie mitgeteilt hat und was noch aussteht. Machen Sie aus einer vorläufigen Erklärung keine allgemeine Regel für künftige Störungen.
- Fassen Sie die Beobachtungen und die sie stützenden Quellen zusammen.
- Geben Sie an, welche Punkte nicht bestätigt werden konnten.
- Dokumentieren Sie vereinbarte Folgemaßnahmen der Beteiligten.
- Trennen Sie die Schlussfolgerungen zum konkreten Fall von weiterhin offenen Hypothesen.
Häufige Fragen
Beweist ein DLR, dass die SMS auf dem Telefon angekommen ist?
Die bereitgestellten technischen Nachweise lassen nicht erkennen, was ein DLR in einer konkreten Implementierung bestätigt. Behaupten Sie nicht, dass es den Empfang oder das Lesen auf dem Endgerät belegt, solange keine einschlägige Dokumentation dies stützt.
Welche Daten sollten in einer Anfrage an einen Anbieter enthalten sein?
Sie können Referenzen, relevante Empfänger- und Absenderdaten, Uhrzeiten und Zeitzonen, den empfangenen Status samt Quelle sowie die beobachteten Auswirkungen beschreiben. Die verfügbaren Nachweise legen keinen allgemeingültigen Mindestsatz an Daten fest. Geben Sie nur das Erforderliche über zugelassene Kanäle weiter.
Wer sollte eine Störung koordinieren, die mehrere Anbieter betrifft?
Ihre Organisation kann eine Person benennen, die Informationen und Kommunikation koordiniert. Die bereitgestellten Nachweise legen keine allgemeingültige Verteilung der Zuständigkeiten zwischen Anbietern fest. Die Fallkoordination bedeutet weder, dass die Person Systeme Dritter kontrolliert, noch dass sie die Ursache allein feststellen kann.
Was ist zu tun, wenn Anbieter unterschiedliche Darstellungen liefern?
Als organisatorische Maßnahme können Sie die Darstellungen und ihre jeweiligen Quellen getrennt dokumentieren, bei jeder Partei die für die Prüfung des Falls erforderlichen Informationen erfragen und eine nicht aufgelöste Abweichung ausdrücklich festhalten. Die verfügbaren Nachweise enthalten kein offizielles Verfahren zur Klärung solcher Widersprüche.
Verwendete Quellen
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA