A2P-SMS-Routingrichtlinien vor der Bereitstellung validieren

Warum Regeln vor ihrer Aktivierung geprüft werden sollten

Dieser Leitfaden schlägt allgemeine Kontrollen zur Überprüfung einer Konfiguration vor. Er ist weder eine Norm von 3GPP, ITU-T oder GSMA noch beschreibt er von diesen Organisationen validierte Verfahren. Die verfügbaren Informationen rechtfertigen es nicht, diesen Organisationen konkrete Leitlinien zur Priorität, zu Überschneidungen oder zu Tests kommerzieller A2P-SMS-Routingrichtlinien zuzuschreiben.

Im Rahmen einer Überprüfung kann ein Team kontrollieren, ob mehrere Regeln auf dieselbe Nachricht zutreffen, ob ihre Bedingungen widersprüchlich erscheinen oder ob für bestimmte Fälle keine geeignete Route gefunden wird. Wie solche Fälle zu interpretieren sind, hängt von der jeweiligen Implementierung ab und sollte anhand ihrer Dokumentation bestätigt werden. Diese Prüfungen beweisen weder, dass eine Route verfügbar ist, noch dass ein Betreiber den Datenverkehr annimmt oder die SMS auf dem Gerät ankommt.

• Die Suche nach doppelten oder teilweise überlappenden Regeln ist als vorgeschlagene Prüfung zu verstehen, nicht als normative Anforderung.
• Prüfen Sie, ob die Kriterien unterschiedliche Aktionen auswählen könnten, und bestätigen Sie das Verhalten anhand der Dokumentation der Implementierung.
• Notieren Sie, welche Fälle das Team als abgedeckt betrachtet und welche noch überprüft werden müssen.
• Verstehen Sie eine geprüfte Konfiguration nicht als Zustellgarantie.

Bedingungen und Aktionen erfassen

Als Ausgangspunkt für eine interne Prüfung können Sie aktuelle und vorgeschlagene Regeln in einem vergleichbaren Format zusammenstellen. Das geeignete Schema und die passenden Felder hängen von der Implementierung ab. Es liegen nicht genügend Informationen vor, um hier ein für alle Systeme geeignetes Mindestregelschema festzulegen.

Verwenden Sie nur Felder, die in der Implementierung und in den geltenden Betriebsvereinbarungen vorhanden sind. Wenn das Team eine Vorlage erstellt, kann sie die von jeder Regel geprüften Bedingungen, die ausgeführte Aktion, relevante Einschränkungen, die Version und die Quelle der jeweiligen Einschränkung erfassen. Betrachten Sie diese Vorlage als Organisationsvorschlag, nicht als durch eine externe Norm gestütztes technisches Verfahren.

• Halten Sie als Vorschlag für die Dokumentation die Regelkennung, den Zweck, die verantwortliche Person und den Status fest.
• Beschreiben Sie die Bedingungen anhand der Werte und Formate, die das System tatsächlich erkennt.
• Dokumentieren Sie die implementierte Aktion, sofern sie sich anhand der Plattformdokumentation bestätigen lässt.
• Trennen Sie bestätigte Einschränkungen von Annahmen, die noch überprüft werden müssen.
• Halten Sie die Richtlinienversion und die Quelle der erfassten Informationen fest.

Prioritäten ausdrücklich festlegen

Wenn mehrere Regeln zutreffen könnten, lesen Sie in der Dokumentation der Implementierung nach, wie die Auswahl aufgelöst wird. Die vorliegenden Informationen reichen nicht aus, um einen einheitlichen Prioritätsmechanismus für kommerzielle A2P-SMS-Routingrichtlinien festzulegen. Nehmen Sie nicht an, dass die sichtbare Reihenfolge, die Erstellungsreihenfolge oder eine informelle Konvention das Ergebnis bestimmt.

Wenn die Dokumentation nicht klärt, wie zwei zutreffende Regeln mit unterschiedlichen Aktionen aufgelöst werden, halten Sie die Frage als offen fest und bitten Sie vor dem Vertrauen auf ein Ergebnis um technische Bestätigung. Die vorgeschlagene Dokumentation dieser Bestätigung ist eine allgemeine Kontrollmaßnahme und keine 3GPP, ITU-T oder GSMA zuzuschreibende Vorgabe.

• Prüfen Sie in der Dokumentation, welcher Prioritätsmechanismus gegebenenfalls gilt.
• Halten Sie Fälle mit Gleichstand oder Konflikte fest, deren Ergebnis unklar ist.
• Gehen Sie nicht davon aus, dass eine Ausnahme oder eine spezifischere Regel Vorrang hat, ohne dies zu bestätigen.
• Wenn sich das Verhalten der Routing-Engine nicht feststellen lässt, bitten Sie vor der Aktivierung der Änderung um Bestätigung.

Abdeckung, Überschneidungen und geeignete Routen prüfen

Ein Team kann die Regeln anhand der erwarteten Anwendungsfälle überprüfen. Die bereitgestellten externen Informationen stützen jedoch kein konkretes technisches Verfahren zum Testen von Abdeckung, Überschneidungen, unerreichbaren Regeln oder geeigneten Routen. Die Durchführung solcher Prüfungen hängt von Aufbau und Funktionen der jeweiligen Implementierung ab.

Als allgemeine Prüffragen kann das Team überlegen, ob es Fälle ohne definierte Übereinstimmung gibt, ob mehrere Regeln zutreffen könnten und ob eine Regel durch eine andere wirkungslos werden könnte. Prüfen Sie anhand der Dokumentation oder verfügbarer Testmöglichkeiten, wie die Engine solche Fälle tatsächlich verarbeitet. Leiten Sie das Ergebnis nicht allein aus der Position einer Regel in einer Liste ab.

Wenn keine Route die konfigurierten Einschränkungen erfüllt, prüfen Sie, welches Ergebnis die Implementierung dafür vorsieht. Nehmen Sie weder an, dass es eine Option für „keine geeignete Route“ gibt, noch dass beim Fehlen einer Route automatisch eine Alternative aktiviert wird.

• Betrachten Sie die Prüfung einzelner Regeln und ihres Zusammenspiels als vorgeschlagene interne Kontrollmaßnahme.
• Notieren Sie Fälle ohne Übereinstimmung, Mehrfachübereinstimmungen und scheinbar nicht angewendete Regeln, ohne anzunehmen, dass die Liste allein das tatsächliche Verhalten erkennen lässt.
• Bestätigen Sie anhand der Dokumentation, wie Einschränkungen ausgewertet werden und was geschieht, wenn keine geeignete Route verfügbar ist.
• Dokumentieren Sie offene Fragen, die sich bei der Prüfung nicht klären ließen.

Grenzfälle mit einer Entscheidungsmatrix prüfen

Eine Entscheidungsmatrix kann als Arbeitsformat dienen, mit dem Betrieb und Technik gemeinsam die Auslegung einer Richtlinie dokumentieren. Die bereitgestellten Quellen enthalten nicht genügend technische Informationen, um diese Methode als validiertes oder auf allen Plattformen anwendbares Verfahren darzustellen.

Wenn das Team eine Matrix verwenden möchte, kann es für relevante Fälle Eingaben, erwartete Ergebnisse und beobachtete Ergebnisse festhalten, etwa für zutreffende oder nicht zutreffende Bedingungen, Einschränkungen, Ausnahmen und mögliche Mehrfachübereinstimmungen. Welche Fälle ausgewählt werden, sollte von den vorhandenen Bedingungen und den dokumentierten Möglichkeiten der Plattform abhängen.

Unterscheiden Sie eine manuelle Prüfung von einem ausgeführten Test. Bevor Sie Ergebnisse interpretieren, bestätigen Sie, welches Werkzeug oder welche Umgebung das Verhalten der Richtlinie abbildet und welche Grenzen es beziehungsweise sie hat.

• Erfassen Sie in einer verwendeten Matrix die Eingaben sowie die erwarteten und beobachteten Ergebnisse.
• Notieren Sie, welche Fälle das Team geprüft hat und warum sie ausgewählt wurden.
• Geben Sie an, ob das Ergebnis aus einem ausgeführten Test oder einer manuellen Prüfung stammt.
• Stellen Sie die Matrix nicht als Nachweis einer tatsächlichen Zustellung dar.

Die Prüfung von Regeln beweist keine Zustellung

Die Logik einer Konfiguration zu prüfen und das Verhalten des Datenverkehrs zu beobachten sind zwei unterschiedliche Tätigkeiten. Die verfügbaren Informationen reichen nicht aus, um ein konkretes technisches Verfahren zur Messung der Abdeckung, der Zustellqualität oder des Verhaltens von A2P-SMS-Routen zu empfehlen.

Eine Zustellbestätigung (DLR) ist ein vom jeweiligen System gemeldeter Status. Für sich genommen beweist sie nicht, dass der Empfang auf dem Gerät verifiziert wurde. Geben Sie bei der Darstellung von Ergebnissen an, welche Nachweise beobachtet wurden und welche Unsicherheiten bestehen bleiben.

• Beschreiben Sie, ob es sich bei der Prüfung um eine Konfigurationskontrolle oder eine Beobachtung des Datenverkehrs handelte.
• Geben Sie Quelle und Umfang der Zustellnachweise an, über die Sie berichten.
• Unterscheiden Sie eine gemeldete DLR von einem verifizierten Empfang Ende zu Ende.
• Stellen Sie eine logische Prüfung nicht als Garantie für Verfügbarkeit oder Zustellung dar.

Ergebnisse, Verantwortliche und Änderungen dokumentieren

Bewahren Sie als vorgeschlagene interne Praxis die vorherige und die vorgeschlagene Version einer Richtlinie sowie verfügbare Informationen dazu auf, wer die Änderung beantragt oder geprüft hat. Dokumentieren Sie, was untersucht wurde, welches Ergebnis erwartet und was beobachtet wurde, ohne dieses Format als normative technische Anforderung darzustellen.

Wenn das Team Ausnahmen oder ein Verfahren zur Rückkehr zu einer früheren Konfiguration festlegt, dokumentieren Sie, wer diese genehmigt hat und wie sie im verwendeten System umgesetzt würden. Nehmen Sie nicht an, dass eine automatische Rücksetzfunktion vorhanden ist. Wenn nicht erklärbare Abweichungen auftreten, halten Sie die Frage fest und bitten Sie um eine technische Prüfung, bevor Sie den Anwendungsbereich erweitern.

• Halten Sie als Vorschlag zur Dokumentation die Richtlinienversion, das Datum und die für die Änderung verantwortliche Person fest.
• Bewahren Sie Informationen über die durchgeführten Prüfungen und ihre Grenzen auf.
• Dokumentieren Sie Ausnahmen und ihre Genehmigung, sofern dies dem internen Prozess entspricht.
• Halten Sie fest, wie die vorherige Konfiguration wiederhergestellt würde, sofern ein solches Verfahren existiert und bestätigt wurde.

Prüfliste und Nachverfolgung

Die folgende Liste fasst allgemeine Fragen zusammen, die ein Team an die Dokumentation und die tatsächlichen Funktionen seiner Plattform anpassen kann. Sie ist weder eine technische Norm noch eine von 3GPP, ITU-T oder GSMA validierte Checkliste. Die bereitgestellten Informationen reichen nicht aus, um konkrete Empfehlungen zur Validierung von A2P-SMS-Richtlinien zu stützen.

Nach einer Änderung kann das Team die betroffenen Aspekte entsprechend seiner Implementierung prüfen und die Grenzen dieser Prüfung dokumentieren. Eine begrenzte Auswahl von Kontrollen ist keine allgemeingültige Garantie.

• Wurden die Regeln und die Bedingungen ermittelt, die die Plattform tatsächlich erkennt?
• Ist dokumentiert, wie Übereinstimmungen aufgelöst werden, oder wurde eine Bestätigung angefragt?
• Wurden Überschneidungen und Fälle mit unklarem Ergebnis festgehalten?
• Sind die geprüften Fälle und die Grenzen der Prüfung beschrieben?
• Wird zwischen einer Konfigurationsprüfung und einer Beobachtung der Zustellung unterschieden?
• Sind Verantwortliche, Ausnahmen und Änderungen gemäß dem internen Prozess dokumentiert?
• Wurde bestätigt, ob ein Verfahren zur Rückkehr zur vorherigen Konfiguration existiert?