Die Telekommunikationsbranche, ein Eckpfeiler der globalen Konnektivität, erlebt seit einiger Zeit eine technologische Renaissance, angetrieben durch Innovationen wie 5G, IoT, Cloud Computing und KI. Infolgedessen ist es immer schwieriger geworden, Netzwerke zu verwalten. Es besteht Bedarf an Automatisierung, um Routineaufgaben zu erledigen, den Netzwerkzustand zu überwachen und in Echtzeit auf Probleme zu reagieren. Allerdings sind die vorhandenen Kompetenzen der Kommunikationsdienstanbieter (CSPs) möglicherweise nicht auf die sich entwickelnden Anforderungen dieser dynamischen Landschaft abgestimmt. Um im modernen Zeitalter erfolgreich zu sein, benötigen CSPs vielseitige Teams, darunter Datenwissenschaftler für Dateninterpretation und -betrieb, Softwareentwickler für die Automatisierung über Anwendungsprogrammierschnittstellen (API) von Anbietern und Service-Assurance-Ingenieure für die Gestaltung geschlossener Kreisläufe zur Gewährleistung der Servicezuverlässigkeit.

Während CSPs diese Lücke schließen, indem sie Teams mit unterschiedlichen Erfahrungen aufbauen, profitieren sie gleichzeitig auch von erheblichen Fortschritten bei einem gleichzeitigen Trend. Programmiersprachen haben sich zu Low-Code/No-Code-Paradigmen entwickelt und mit dem Aufkommen der generativen KI sind wir an einem Punkt angelangt, an dem grundlegende Modelle formalen Code basierend auf Beschreibungen der Aufgaben in natürlicher Sprache generieren können. Dies gab dem Konzept eine neue Perspektive Absichtsbasierte Vernetzung (IBN), bei dem menschliche Administratoren übergeordnete Netzwerkziele in natürlicher Sprache ausdrücken, die als „Absichten“ bezeichnet werden, und dass diese menschlichen Absichten automatisch in Netzwerkrichtlinien und -konfigurationen übersetzt werden. IBN hat das Potenzial, das Netzwerkmanagement zu verbessern und könnte bei der Schließung der Talentlücke in Telekommunikationsunternehmen eine entscheidende Rolle spielen. Gehen wir noch einen Schritt weiter, autonome Netzwerke (AN) versprechen, Absichten als Eingaben für die autonome Selbstkonfiguration, Selbstoptimierung und Selbstheilung von Netzwerken zu nutzen, wenn sich ihre Bedingungen weiterentwickeln.

Während wir uns sowohl für IBN als auch für AN eine glänzende Zukunft vorstellen können, bestehen anhaltende Bedenken hinsichtlich ihrer Machbarkeit und Programmanwendungen, einschließlich der Absichtsäußerung, der genauen Übersetzung in die Netzwerkkonfiguration, der Systemtransparenz und -komplexität und anderen. In diesem Blog tauchen wir in die Bereiche ein, in denen ihre praktische Anwendung Potenzial birgt, und analysieren die Herausforderungen, denen sie dabei begegnen könnten.

Ein motivierender Fall: Einführung neuer Dienste ohne Absichten

Um die Notwendigkeit einer Optimierung der Interaktionen zwischen CSP-Teams und dem Netzwerk zu verstehen, verwenden wir als Beispiel eine neue Dienstbereitstellung.

Wir gehen davon aus, dass der CSP-Netzwerkbetrieb gemäß den in der aufgeführten Spezifikationen automatisiert ist TMF-Einführungsleitfaden 1230 (IG1230) zur technischen Architektur autonomer Netzwerke. In diesem Zusammenhang verfügt das OSS des CSP über (1) einen Orchestrator für die Dienstbereitstellung, automatisierte Bereitstellung und automatisierte Tests, (2) ein Sicherungssystem mit Netzwerkinventar, das Daten sammelt, Einblicke in den Netzwerkstatus schafft und somit die datengesteuerte Entscheidungsfindung erleichtert im Kontext der Regelung mit geschlossenem Regelkreis und (3) ein Richtlinienmanager, der das Netzwerkverhalten mithilfe vordefinierter Richtlinien steuert und so die Ausrichtung an den umfassenderen CSP-Richtlinien gewährleistet. Kurz gesagt, bei automatisierten Abläufen geht es um die enge Kopplung von Diensten mit den ihnen zugewiesenen, von Menschen entworfenen TOSCA-Dienstbeschreibungen, Konfigurationen, Richtlinien und zwingenden Arbeitsabläufen, bei denen Dienstdesigner während der Entwurfszeit Informationen und Entscheidungsfindung hinzufügen. Service-Designer müssen proaktiv eine Vielzahl von Bedingungen vorhersehen, die im Netzwerk auftreten können, und detaillierte Anweisungen dazu geben, wie diese angegangen werden müssen – ein Zero-Touch-Erlebnis wird erreicht, solange die zukünftigen Bedingungen vorhergesehen wurden und es Richtlinien für den Umgang mit ihnen gibt.

Wir verwenden die Begriffe Tag 0, Tag 1 und Tag 2 für verschiedene Service-Lebenszyklusphasen, nämlich Service-Design, Dienstinstanziierung und Service Assurance, Bzw.

• Service-Design umfasst die Entwicklung verschiedener Service-Assets, wie in Abbildung 1 dargestellt. Dies ist die Aufgabe des Service-Design-Teams, das die Day1- und Day-2-Operationen des Service verstehen und die erforderlichen Workflows und Skripte erstellen muss. Die roten Linien in Abbildung 2 stellen den Dienstbereitstellungsprozess eines neuen Dienstes dar und stellen sicher, dass der Dienst jetzt bestellt werden kann.

• Die Dienstinstanziierung erfolgt, wenn der Dienstauftrag nach einer Abonnentenanfrage eintrifft. Heutzutage kommt der Serviceauftrag bei CSPs typischerweise über die TMF 641-Schnittstelle vom Service Order Manager (SOM) an. Wenn der Service Orchestrator den Serviceauftrag erhält, stellt er sicher, dass die Arbeitsabläufe ausgeführt werden und dass die angeforderten Überwachungskonfigurationen, PM/FM-Modelle und Richtlinien bereitgestellt und ausgeführt werden. Wir zeigen die Dienstinstanziierung in Abbildung 2 in grünen Linien.

• Die Service-Assurance folgt einem Closed-Loop-Ansatz, bei dem die Bedingungen der bereitgestellten Services einer kontinuierlichen Überwachung und automatisierten Lebenszyklusaktionen unterzogen werden. Wir zeigen den geschlossenen Sicherheitskreislauf in Abbildung 2 in blauen Linien.

Zusammenfassend lässt sich sagen, dass die Entwurfsphase einen erheblichen manuellen Arbeitsaufwand erfordert, da das Netzwerk mit Anweisungen für den neuen Dienst versorgt werden muss.

Was sind Absichten?

In IBN beziehen sich Absichten auf übergeordnete Ziele, die CSP in seinem Netzwerk erreichen möchte. Anstatt sich wie oben beschrieben mit komplexen Low-Level-Netzwerkkonfigurationen während des Betriebs am Tag 0 zu befassen, drücken die Engineering-Teams die Ziele mit Absichten aus, und die den Absichten zugrunde liegende Logik übersetzt sie in die erforderliche Netzwerkkonfiguration, die das Absichtsziel erfüllt.

Nach der Anwendung der Konfigurationen auf das Netzwerk überwacht der AN dann kontinuierlich die bereitgestellten Dienste und passt die Konfiguration an, um sicherzustellen, dass der Betrieb im Einklang mit den angegebenen Absichten bleibt. Das AN erweitert die Verwendung von Absichten auf Tag-2-Operationen.

Perspektiven von IBN und AN

Als Nächstes stellen wir einige Aspekte vor, bei denen Absichten möglicherweise etablierte Praktiken aus der Zeit vor der Absicht revolutionieren könnten:

• Tag 0 Operationen:
  • Vorbereitung auf neue Dienste – Nutzen Sie generative KI, um Eingaben in natürlicher Sprache zu verarbeiten und so Serviceanforderungen autonom zu ergänzen.
  • Einführung neuer Dienste – Definieren Sie neue Dienste mithilfe natürlicher Sprache, z. B. „Bereitstellung einer maßgeschneiderten Konnektivitätslösung für die sichere Kommunikation innerhalb von Gesundheitseinrichtungen“ oder „Ermöglichen Sie die IoT-Gerätekommunikation in der gesamten Smart-City-Infrastruktur“ und nutzen Sie generative KI für die automatische Generierung der erforderlichen Serviceressourcen.
  • Automatisierte Generierung herstellerspezifischer Ressourcentreiber– Nutzen Sie generative KI, um herstellerspezifische Ressourcentreiber auf der Grundlage der Herstellerdokumentation zu erstellen.
• Tag 1 Operationen:
  • Vereinfachung der Servicebestellung – Ermöglicht Kunden, Dienste in natürlicher Sprache anzufordern. Dieser benutzerfreundliche Ansatz ermöglicht ein neuartiges Service-Bestellerlebnis, beispielsweise das Mischen und Anpassen von Angeboten aus dem Katalog.
  • Machbarkeitsprüfungen – Optimiert Validierungsprüfungen, wenn Kunden ihre Absichten äußern, indem kritische Faktoren wie die Verfügbarkeit von Glasfaserleitungen effizient bewertet werden. Das Ergebnis ist eine geringere Belastung der Netzwerktechniker, eine schnellere Servicevalidierung sowie eine agilere und reaktionsschnellere Bereitstellung.
• Tag 2 Operationen:
  • Dynamische Servicesicherung – Ermöglicht Netzwerken, intelligent auf sich ändernde Bedingungen und Benutzerbedürfnisse zu reagieren. Flexible, absichtsbasierte Richtlinien erhöhen die Agilität und gewährleisten Echtzeitzuverlässigkeit und Reaktionsfähigkeit der Netzwerkdienste.

Die Herausforderungen bei IBN und AN

Es sind zwei Hauptherausforderungen zu bewältigen:

1. Wie kann man eine Absicht ausdrücken und vermitteln?
2. So führen Sie eine Absicht aus: Wie sieht der Absichtshandler aus?

Das TM Forum stellte die TMF921 Intent-based Networking API vor und bietet ein strukturiertes Framework für die Definition von Netzwerkabsichten auf hoher Ebene. TM Forum definiert die Absicht wie folgt: „Absicht ist die formale Spezifikation aller Erwartungen, einschließlich Anforderungen, Ziele und Einschränkungen, die an ein technisches System gestellt werden“. Allerdings das Teil formale Spezifikation bringt ein Problem mit sich: Netzwerkingenieure müssten sich mit dieser formalen Sprache vertraut machen, um das volle Potenzial des Absichtskonzepts auszuschöpfen. Darüber hinaus reduzieren Intents mit formaler Spezifikation nicht unbedingt die Anzahl der Parameter, die mit ihnen bereitgestellt werden müssen. Dieser Aspekt stellt die erwartete Rationalisierung des Netzwerkmanagements in Frage, die man normalerweise mit IBN assoziieren würde.

Darüber hinaus wird der Absichtshandler, die Kernkomponente von IBN, die die Logik für die Absichtsinterpretation enthält, durch die Formalisierung der Absichtsspezifikation lediglich zu einem deterministischen Interpreter der formalen Absichtssprache. Es stellt sich die Frage, wie wir den Intent-Handler zu einem autonomen System mit deklarativer Funktionsweise weiterentwickeln, bei dem Menschen nicht jeden potenziellen Netzwerkzustand vorhersehen und spezifische Anweisungen für deren Lösung bereitstellen müssen. Andernfalls kann der Systembetrieb nicht erfolgreich von automatisiert auf autonom umgestellt werden (TMF IG1230).

In zukünftigen Blogs werden wir detaillierter auf die Herausforderungen und Chancen von IBN und AN eingehen. Möchten Sie mehr erfahren? Kontaktiere uns unter maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com und tmtattis@ae.ibm.com.

Transformieren Sie für die Zukunft
mit Telekommunikation