Behinderung der digitalen Transformation und Serviceagilität durch eine proprietäre Integration zwischen OSS/BSS und dem Netzwerk

Aufgrund fehlender gemeinsamer Standards haben CSPs lange Zeit proprietäre Schnittstellen verwendet, um OSS/BSS-Komponenten eng mit dem zugrunde liegenden Netzwerk zu integrieren und so individuelle Produktangebote zu ermöglichen. Dieser Ansatz bietet zwar kurzfristige Vorteile, wie z. B. eine schnelle Rentabilität, führt aber auch zu einigen ernsthaften und kostspieligen langfristigen Problemen. CSPs benötigen für das Management des immer größeren Integrationsaufwands ein ganzes Heer interner und externer Mitarbeiter, was zu immer höheren Kosten für die Softwareintegration und -wartung führt.

Ein weiterer Nebeneffekt dieses Ansatzes ist die starke Abhängigkeit von ineffizienten manuellen Eingriffen für Routineaufgaben beim Design, der Aktivierung und der Gewährleistung von Services. Integrationen erfolgen immer taktisch und produktorientiert. Selbst wenn Automatisierung Teil der Lösung ist, ist sie grundsätzlich begrenzt und in vielen Fällen nicht praktisch umsetzbar. Zur Umgehung dieser Einschränkungen entwickeln die Abteilungen für Netzwerktechnik und -betrieb manuelle Prozesse, die schließlich zu Standardbetriebsverfahren werden. Da dieses Wissen im Laufe der Zeit jedoch nur noch intern an wenige Personen weitergegeben wird, sind Änderungen der Verfahren nur schwer möglich.

Dies sind einige der größten Hürden, vor denen CSPs stehen, wenn sie ihre Serviceagilität erhöhen und die digitale Transformation beschleunigen möchten. Dabei verfolgen sie die folgenden Ziele:

  • Vereinfachung und Transformation des OSS zur Unterstützung neuer Geschäftsmodelle wie NaaS
  • Verkürzung der Markteinführungszeit für 5G-Services
  • Entwicklung schlanker Abläufe zur Senkung der Betriebskosten
  • Weichenstellung für die Disaggregation und Transformation hin zu virtuellen und softwaredefinierten Netzwerken

Entkopplung des Netzwerks vom OSS durch das NaaS-Framework des TM Forums

Das NaaS-Framework ermöglicht es CSPs, die Herausforderungen ihrer veralteten Spaghetti-Integrationsarchitektur zu überwinden, indem sie das Netzwerk von ihrem OSS/BSS entkoppeln. Dazu wird ein Abstraktionslayer eingeführt, der die Komplexität der zugrunde liegenden physischen und virtuellen Netzwerke verdeckt und übergeordnete offene Standard-APIs für die Kommunikation mit dem OSS des höheren Layers sowie untergeordnete offene Standard-APIs für die Kommunikation mit den Controllern in den Netzwerkdomänen des unteren Layers verwendet. Das NaaS-Framework unterstützt außerdem offene APIs und Branchenstandards für eine einfache Integration und konsistente Kommunikation zwischen dem CSP, seinen Kunden und Partnern.

Dieser offene Ansatz ermöglicht es CSPs, eine digitale Transformationsstrategie mit zwei Geschwindigkeiten für das Netzwerk und OSS zu verfolgen.

  • Netzwerktransformation: Initiativen zur strategischen Netzwerktransformation wie Netzwerk-Disaggregation, Skalierung von Software Defined Networking (SDN), Cloudifizierung und Automatisierung haben sich verlangsamt, weil ein Fortschritt nicht möglich ist, ohne gleichzeitig erhebliche Änderungen am OSS vorzunehmen. Der Grund dafür ist die enge Kopplung von OSS und Netzwerk sowie die bestehenden proprietären Integrationen, die im Laufe der Jahre als herstellerspezifische NMS, gerätetypspezifische EMS und domänenspezifische Schnittstellen eingeführt wurden, die eine Fülle von Integrationstechnologien wie CORBA, SNMP, MTOSI, XML, FTP, REST und sogar CLI verwenden. Der NaaS-Abstraktionslayer verdeckt diese Komplexität, indem er diese Integrationstechnologien durch moderne Ansätze wie YANG für die untergeordneten Schnittstellen mit den Netzwerkgeräten und übergeordnete ONF- und IETF-basierte APIs für die Integration mit dem OSS ersetzt. Dies ermöglicht den CSPs die Umsetzung der Strategie für die Netzwerktransformation in einem angemessenen Tempo und ohne direkte Auswirkungen auf das OSS.
  • OSS-Transformation: ein modernes automatisiertes OSS wird für den Erfolg von CSPs in der 5G-Ära entscheidend sein. Funktionen wie Self-Service-Auftragsmanagement und Serviceorchestrierung, Echtzeit-Inventarisierung und Ende-zu-Ende-Automatisierung des Service-Lifecycles werden benötigt, um Unternehmen ein digitales Service- und Kundenerlebnis zu bieten und neue On-Demand-Services wie Network-Slicing sowie neue NaaS-basierte Geschäftsmodelle zu unterstützen. Der NaaS-Abstraktionslayer ermöglicht den CSPs die Modernisierung des OSS mit der Gewissheit, dass sich das OSS nur an die vom NaaS-Layer vorgegebenen, untergeordneten Schnittstellen anpassen muss, wie z. B. die ONF T-API. Darüber hinaus bietet der NaaS-Layer die Fähigkeit zum Verfügbarmachen von Services, um CSPs in die Lage zu versetzen, geschäftliche On-Demand-Business-Services als Teil ihrer NaaS-Geschäftsstrategie anzubieten.

Orientierung der iFUSION-Implementierung von Telefónica am NaaS-Framework

Telefónica Deutschland hat für sein teilweise disaggregiertes optisches Netz eine hierarchische SDN-Controller-Architektur implementiert, die entkoppelte offene Terminals (OTs) und ein offenes Leitungssystem (OLS) umfasst. Das Unternehmen nutzt für das Management von Konnektivitätsservices, die über das optische Multi-Vendor-Netz des Unternehmens bereitgestellt werden, die NaaS-konforme MDSO-Lösung von Blue Planet als SDTN-Controller (Software Defined Transport Network).

Mehr über diese Implementierung finden Sie in der Analysys Mason-Fallstudie:
Telefónica Deutschland geht zur Umsetzung der iFUSION-Transport-SDN-Strategie eine Partnerschaft mit Blue Planet ein

Das NaaS-Framework des TM Forums unterstützt modellbasierte Abstraktion und offene APIs, die es den CSPs ermöglichen, das Management des Service-Lifecycles zu automatisieren und Unternehmenskunden die Kontrolle über diese Services zu überlassen. Des Weiteren bietet dieser einfache, standardbasierte Betriebsansatz den CSPs die Grundlage für eine beschleunigte digitalen Transformation und Unterstützung bei der Einführung von 5G-Technologien und -Services.