Zero-Touch Ordering unter menschlicher Kontrolle: ein BSS-Auftrag, Aktivierungen in Mobilfunk-, Festnetz- und TV-Netzen

Das Problem

Ein konvergenter Betreiber verkauft Mobilfunk, Festnetztelefonie, Internet über GPON (Gigabit Passive Optical Network) und Kupfer sowie Satelliten-TV aus einem BSS. Ein einziger kommerzieller Auftrag bedeutet Arbeit an mehreren Netzelementen: Eine neue Postpaid-Leitung betrifft das HLR (Home Location Register), die PCRF (Policy and Charging Rules Function), das OCS und die Voicemail-Plattform, und jedes spricht sein eigenes Protokoll — MML (Man-Machine Language) über SSH, SOAP, CLI, HTTP.

Wenn der Manager des kommerziellen Auftrags all das kennen muss, wird ein neues Paket zur Änderung in mehreren Systemen, und ein Fehler an einem Element lässt den Auftrag halb erledigt zurück, ohne dass jemand sieht, wo er stehen geblieben ist.

Was bestellt wird

• Mobilfunk: neue Leitung, Rufnummernwechsel, SIM- oder IMEI-Wechsel (International Mobile Equipment Identity), Daten- und Sprach-Add-on-Pakete, Sperrung und Reaktivierung in beide Richtungen, administrative Sperren, Leitungskündigung, Geräte-Blacklisting.
• Festnetz und Internet: Leitungsaktivierung, Abschaltung und Wiederanschaltung, Voicemail, Rufnummernanzeige und Rufumleitung, Internet für Privat- und Geschäftskunden, AAA-Konten (Authentication, Authorization and Accounting) und deren Sperren.
• TV: Reaktivierung nach Zahlung, Sperrung wegen Nichtzahlung, ein zusätzlicher Decoder, Arbeitsaufträge für Installation und Deinstallation.

Was sich ändert

1. Das BSS sendet eine Product Order über TM Forum Open API. Der Produktkatalog zerlegt sie in Order Items bis hinunter zu Customer-Facing und Resource-Facing Services.
2. Das Service Order Management übernimmt die Service Order (TMF641 Service Order), erfasst den Service im Service Inventory und baut aus den Order Items und ihren Abhängigkeiten einen Orchestration-Plan.
3. Für jede Ressource eröffnet es eine Resource Order: Das Profil kommt aus dem Resource Profiles Inventory, die Aktivierung (TMF640 Service Activation and Configuration) läuft als ausführbare Netzvorlage — ein BPMN-Prozess pro Elementtyp über HTTP, SSH oder Telnet.
4. Wenn die Elemente bestätigen, werden Resource Inventory und Service Inventory aktualisiert, und das BSS erhält „completed“ als Event; jedes Team sieht unterwegs den Status jedes Order Items.
5. Änderungen während der Ausführung — Add, Change, Disconnect, Suspend, Resume sowie die Revision eines bereits revidierten Auftrags — fließen in denselben Plan statt in einen neuen Auftrag.
6. Wo ein Element ausfällt oder ein Schritt einen Menschen braucht, wird der Schritt zu einer manuellen Provisioning-Aufgabe oder einem Trouble Ticket: Ein Mensch bearbeitet den Auftrag, und der Prozess läuft weiter. Arbeitsaufträge für Installation und Deinstallation gehen an Partnersysteme.

Was es bringt

• Das BSS sendet einen Auftrag und erhält eine Antwort; Protokolle und Befehlssätze des Netzes bleiben im Service Order Management, sodass ein neues Paket eine Änderung an Katalog und Vorlagen ist, nicht am BSS.
• Jede Operation wird auditiert und die Verbindung zu jeder Plattform überwacht, mit Alarmen auf dem Bildschirm und per E-Mail.
• Designziel: Timeouts, Benutzer, Berechtigungen und Serviceeinstellungen ändern sich in einer Konfigurationsmaske mit Rollen, ohne Codeänderungen.
• Prioritäten und parallele Verarbeitung verhindern, dass kritische Aufträge hinter einer Warteschlange warten; das Designziel sind 30 Sekunden pro Aktivierung, Deaktivierung oder Serviceänderung.

Lösungsumfang

Zielszenario: eine Lösung für einen konvergenten Betreiber mit Mobilfunk, Festnetz, Internet und TV — Architektur, Auftragszerlegung, Adapter zu Netzelementen und Hochverfügbarkeit an zwei Standorten, Active-Active oder Active-Standby, auf Kubernetes. Der Umfang wird im Projekt je Servicebereich vereinbart.

Zielszenario für AI-gestütztes Service Order Management: Netzvorlagen auf IETF YANG-Modellen zusammen mit TMF641 Service Order und TMF640 Service Activation and Configuration sowie Knowledge Graph, der kundenseitige Services mit Netzressourcen verknüpft — Zerlegung in Customer Facing Service (CFS) und Resource Facing Service (RFS), Inventory und Topologie auf YANG-Modellen. Das Modell wird im Projekt auf den Daten des Betreibers aufgebaut.

Was MEF.DEV einbringt

Service Order Management auf der Enablement & Monetization Platform mit MEF.DEV BPMN Low-code: BPMN Flow Designer, Orchestration Engine, Katalogkonfiguration und Integrationsadapter zu Netzelementen als Backend-Plugins, mit Service-Aktivierung und Inventories aus WideCoup Convergent BSS. Der BSS-Partner und der Betreiber behalten den kommerziellen Auftrag und die Geschäftslogik; MEF.DEV baut das Backend und die Adapter.