Netzausfälle vorausschauend vermeiden: Predictive Maintenance für DSLAMs und Antennen

Das echte Ausmaß des Problems

Ein regionaler Carrier mit 200.000 Anschlüssen betreibt typischerweise 800 bis 3.000 DSLAMs, OLTs und Antennenstandorte. Jedes Gerät sendet kontinuierlich Telemetrie: Fehlerrate, Temperatur, Lastzustand, Versorgungsspannung, Betriebsstunden, optische Dämpfung. Das sind mehrere hundert Millionen Datenpunkte pro Tag — gesammelt, gespeichert, und in 98 Prozent der Betriebe von niemandem systematisch auf Ausfallmuster hin ausgewertet.

Die Konsequenz lässt sich beziffern. Reactive Dispatch — ein Techniker fährt nach einem Ausfall raus — kostet laut Branchenanalysen drei- bis fünfmal mehr als ein geplanter Wartungseinsatz auf demselben Gerät. Dazu kommen SLA-Strafen: Bei 99,9-Prozent-Verfügbarkeitsversprechen darf ein Unternehmensanschluss im Jahr nicht mehr als 8,76 Stunden ausfallen. Ein einzelner DSLAM-Ausfall über 6 Stunden verursacht bei zehn Unternehmenskunden in diesem Cluster Strafzahlungen und Kündigungsrechte.

Für Deutschland kommt ein regulatorischer Aspekt hinzu: Laut § 168 TKG (Telekommunikationsgesetz 2021) sind Betreiber öffentlicher Telekommunikationsnetze verpflichtet, erhebliche Sicherheitsvorfälle mit signifikanten Auswirkungen auf den Netzbetrieb unverzüglich — spätestens 24 Stunden nach Bekanntwerden — der Bundesnetzagentur zu melden. Häufige oder großflächige Ausfälle landen in der BNetzA-Statistik und können regulatorische Aufmerksamkeit auf sich ziehen.

Was die Branche zeigt:

• Nokia berichtet für seinen Predictive Care-Dienst für Festnetze Ausfallreduktionen von bis zu 65 Prozent bei Betreibern, die prädiktive Analysen auf ihren DSLAM- und OLT-Flotten einsetzen (Nokia.com, 2024)
• Swisscom erzielte mit prädiktiver Analyse auf dem Heimnetz-Bestand eine 90-prozentige First-Time-Right-Rate bei Technikerempfehlungen — was den Anteil ineffektiver Vor-Ort-Einsätze dramatisch senkt
• POST Luxembourg erzielte mit Nokia Fixed Network Insights eine nachweislich beschleunigte Root-Cause-Analyse in 95 Prozent der Fälle

Mit vs. ohne KI — ein ehrlicher Vergleich

Angaben aus Branchenberichten und Nokia-Fallstudien; eigene Erfahrungswerte für Carrier 100K–500K Anschlüsse.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) NOC-Analysten sparen tatsächlich Zeit, weil sie priorisierte Predictions statt Alarm-Floods bearbeiten. Der größere Effizienzgewinn steckt aber in der Feldorganisation: gebündelte Wartungstouren statt Einzelfahrten, vorbestellte Ersatzteile, kürzere Gerätestillstandszeiten. Direkte Stundenersparnis je NOC-Mitarbeitenden liegt eher im Bereich 30–60 Minuten täglich — vergleichbar mit dem SLA-Tracking, aber ohne dessen direkten Dokumentationsgewinn.

Kosteneinsparung — hoch (4/5) Ein Notfalleinsatz kostet drei- bis fünfmal so viel wie ein geplanter Einsatz auf demselben Gerät. Das ist die Kernmathematik. Dazu kommen SLA-Strafzahlungen und Kundenverluste durch Ausfallzeiten. Der Delta zwischen reaktivem und prädiktivem Betrieb ist bei einem Carrier mit 200 Notfalleinsätzen pro Monat und einem Einsparpotenzial von 40 Prozent schnell im sechsstelligen Bereich jährlich — und das ohne technische Risikoaufschläge. Höchster Kosteneffekt unter den verglichenen Anwendungsfällen neben dem Techniker-Dispositionssystem.

Schnelle Umsetzung — sehr niedrig (1/5) Das ist die ehrlichste Zahl im Radar. Predictive Maintenance auf Netzinfrastruktur braucht: eine belastbare SNMP- oder Streaming-Telemetrie-Pipeline, mindestens 12–18 Monate historische Daten für das Modell-Training, eine saubere Gerätestammdaten-Basis, und die Integration in das bestehende Dispositionssystem. Wer heute anfängt, hat in 18–30 Monaten einen produktiven Betrieb. Das ist kein Projektfehler, das ist die physikalische Realität von ML auf Zeitreihendaten ohne ausreichende Baseline.

ROI-Sicherheit — hoch (4/5) Anders als bei Anwendungsfällen, bei denen der ROI sich schwer isolieren lässt, ist der Beweis hier direkt: Anzahl der Notfalleinsätze vorher und nachher, durchschnittliche Einsatzkosten, SLA-Strafzahlungen, MTTR. Alles im Ticketing-System erfasst, alles messbar. Nokia und andere Anbieter zeigen konsistente 30–65 Prozent Ausfallreduktion in kontrollierten Einsätzen. Die Unsicherheit liegt nicht in der Wirksamkeit, sondern in der Projektlaufzeit bis zum Nachweis.

Skalierbarkeit — hoch (4/5) Jede neue Geräteklasse, jeder neue Standort fügt Trainingsdaten hinzu. Das Modell wird besser, je größer das Netz ist — ein seltenes Merkmal, das dem Anwendungsfall bei der Backbone-Kapazitätsplanung ähnelt. Nicht die Höchstpunktzahl, weil der initiale Modellbau für jede neue Gerätegeneration oder jeden neuen Vendor Aufwand bedeutet.

Richtwerte — stark abhängig von Netzgröße, Gerätehomogenität und vorhandener Telemetrie-Infrastruktur.

Was das System konkret macht

Predictive Analytics auf Netzinfrastruktur bedeutet: Das System nimmt die kontinuierlichen Telemetrieströme jedes Geräts — Fehlerzähler, Temperaturen, Lastkurven, optische Leistungspegel, Versorgungsspannungen — und sucht nach Mustern, die historisch vor Ausfällen aufgetreten sind.

Das klingt einfach. Die Schwierigkeit liegt darin, dass kein einzelner Parameter einen Ausfall ankündigt. Ein DSLAM, der ausfällt, zeigt nicht “Fehler jetzt”. Er zeigt: CRC-Fehler-Rate leicht erhöht (seit 18 Tagen), Betriebstemperatur im 95. Perzentil (aber unter dem Hard-Alarm), Lüftergeschwindigkeit gestiegen (aber im normalen Bereich), Leistungsaufnahme mit ungewöhnlichem Tagesprofil. Erst das gleichzeitige Auftreten mehrerer schwacher Signale ist der Indikator.

Machine Learning-Modelle — konkret meist Gradient Boosting, Random Forests oder LSTM-Netze auf den Zeitreihen — lernen diese multivariaten Korrelationen aus historischen Ausfällen. Das Training braucht: bekannte Ausfallzeitpunkte aus dem Ticketing-System und die zugehörigen Telemetriedaten der Wochen davor. Aus diesem Zusammenhang lernt das Modell, wie ein Gerät “kurz vor dem Ausfall” aussieht — und erkennt dieses Muster bei zukünftigen Geräten, bevor der Ausfall eintritt.

Was das System nicht macht

Es ersetzt nicht das menschliche Urteil. Eine Prediction mit 78 Prozent Ausfallwahrscheinlichkeit in 5 Tagen ist kein automatischer Wartungsauftrag. Sie ist ein priorisierter Hinweis an den NOC, dass dieses Gerät in die nächste Wartungstour eingeplant werden sollte. Ob das technisch und kapazitiv machbar ist, entscheidet weiterhin der Disponer. Der Wert liegt darin, dass er überhaupt gefragt wird — bevor der Ausfall geschieht.

Datenbasis: SNMP vs. Streaming-Telemetrie

Bevor du über ML-Modelle nachdenken kannst, musst du die Datenfrage lösen. Fast alle Carrier verfügen über SNMP-Polling in ihrem Network Management System — aber SNMP-Daten und Zeitreihen, die für Machine Learning taugen, sind zwei verschiedene Dinge.

SNMP-Polling (klassisch)
SNMP fragt Geräte in festen Intervallen ab — typisch alle 5 oder 15 Minuten. Das ist ausreichend für Verfügbarkeitsmonitoring und Schwellwert-Alarme. Für Predictive Maintenance reicht die Granularität oft nicht: Ein transienter Fehlerpuls, der 30 Sekunden dauert und dann verschwindet, ist bei 5-Minuten-Polling für immer verloren. Außerdem ist SNMP ein Pull-Modell — das Gerät antwortet auf Anfrage, und bei tausend Geräten gleichzeitig entsteht Poll-Latenz.

Streaming-Telemetrie (modern)
Streaming-Telemetrie (auch Model-Driven Telemetry, MDT) pusht Daten mit Sekunden- oder Subsekundenauflösung aktiv aus dem Gerät heraus. Das ergibt das 10- bis 100-fache an Datenpunkten pro Gerät. Für Anomalieerkennung auf frühen Ausfallsignalen ist das ein erheblicher Vorteil. Der Nachteil: Streaming-Telemetrie braucht YANG-Modelle und einen gRPC- oder gNMI-fähigen Kollektor — und nicht alle Gerätegenerationen in einem gewachsenen Netz sprechen dieses Protokoll.

Praktische Empfehlung für regionale Carrier
Starte mit dem, was du hast. Wenn SNMP-Daten der letzten 18 Monate aus dem NMS exportierbar sind und Ausfallzeitpunkte aus dem Ticketing-System vorliegen, ist das ausreichend für ein erstes Modell. Streaming-Telemetrie ist ein Upgrade-Pfad, der beim nächsten Gerätegenerationswechsel priorisiert werden sollte — nicht ein Blockadefaktor.

Multi-Vendor-Realität: Ericsson, Nokia und Huawei im selben Netz

Das häufigste ungelöste Problem in realen Carrier-Netzen ist nicht das ML-Modell. Es ist, dass Geräte von Ericsson, Nokia und Huawei unterschiedliche MIBs (Management Information Bases) verwenden, proprietäre Telemetrie-Namespaces definieren und manche Parameter nur über Vendor-spezifische Protokolle oder CLIs zugänglich sind.

Ein typisches Szenario: Das DSLAM-Blade eines Ericsson-Systems liefert die Temperatur als docsIfCmtsCmStatusSnr mit einer anderen OID als das Nokia ISAM-System, das dieselbe Information als xdsl2ChAtucCurrState anbietet. Das Huawei MA5800 wiederum bevorzugt die SNMP-Abfrage über proprietäre MIB-Erweiterungen, die in Standard-Polling-Konfigurationen fehlen.

Was das bedeutet:
Bevor du deine Daten in ein ML-Modell gibst, musst du eine Normalisierungsschicht bauen. Jeder Vendorparameter muss auf eine einheitliche Semantik gemappt werden — “Temperatur in °C”, “CRC-Fehler pro Minute”, “Signalrausch-Abstand in dB” — unabhängig davon, wie der jeweilige Hersteller ihn benennt. Diese Arbeit ist nicht glamourös, kostet aber oft 30–40 Prozent der Projektlaufzeit.

Ericsson, Nokia und Huawei bieten jeweils eigene Predictive-Maintenance-Module an, die dieses Problem umgehen, weil sie nur die eigenen Geräte kennen. Nokia Predictive Care für Festnetze ist der am weitesten ausgereifte Vertreter dieser Kategorie — mit dokumentierten Ergebnissen bei mehreren europäischen Betreibern. Der Haken: Diese Lösungen funktionieren homogen, aber kaum in Multi-Vendor-Umgebungen.

Wer eine herstellerübergreifende Lösung will, braucht entweder einen Systemintegrator mit Erfahrung in dieser Normalisierungsarbeit oder ein offenes AIOps-Framework, das vendor-agnostisch gebaut ist.

Konkrete Werkzeuge — was wann passt

Die Werkzeugkette für Predictive Maintenance auf Netzinfrastruktur hat drei Schichten: Datenspeicher, ML-Plattform, und Visualisierung/Alerting.

Datenspeicher (Zeitreihen)

InfluxDB — die am häufigsten genutzte Open-Source-Zeitreihendatenbank für Netz-Telemetrie. Selbst gehostet, DSGVO-konform, sehr hohe Write-Performance für hochfrequente Sensordaten. Eignet sich als Zwischenspeicher für SNMP-Polls und als Basis für Anomalie-Queries über Flux. On-premise-Betrieb ist für KRITIS-relevante Infrastruktur der empfohlene Pfad. Einstieg kostenlos (OSS), Betriebsaufwand für Multi-Node-Cluster erheblich.

ML-Plattformen und Anomalieerkennung

Amazon Lookout for Equipment — vollständig verwalteter AWS-Dienst, der multivariate Zeitreihendaten auf Anomaliemuster trainiert und inferiert, ohne dass ein ML-Team nötig ist. Geeignet für Carrier, die AWS bereits nutzen und eine schnelle Proof-of-Concept-Phase ohne eigene Data-Science-Kapazität starten wollen. Preis: Inferenz ab 0,15 USD/Stunde je Modell, EU-Region Frankfurt verfügbar. Einschränkung: Historische Daten von mindestens 14 Tagen (besser: 6+ Monate) erforderlich, kein Out-of-the-Box-UI — Ergebnisse müssen in eigene Dashboards integriert werden.

Azure Machine Learning — für Carrier mit bestehender Azure-Infrastruktur. Ermöglicht das Training eigener Gradient-Boosting- oder LSTM-Modelle mit voller Kontrolle über Feature Engineering und Modell-Architektur. EU-Region Germany West Central für DSGVO-konformes Hosting. Realistisches Monatsbudget für produktive Endpunkte: 1.000–5.000 EUR. Braucht ein Data-Science-Team oder einen Systemintegrator.

Visualisierung und Alerting

Grafana — de-facto-Standard für NOC-Dashboards auf Zeitreihendaten. Verbindet sich direkt mit InfluxDB, AWS CloudWatch und Azure Monitor. Grafana ML bietet Anomalieerkennung und Forecasting als Add-on — kein Ersatz für ein dediziertes ML-Modell, aber eine gute erste Schicht für Trend-Visualisierung. Open-Source-Kern selbst hostbar; EU-Region Frankfurt in Grafana Cloud. Für NOC-Dashboards mit Alerting-Routing an Bereitschaftsdienste die naheliegendste Wahl.

Dynatrace — für Carrier, die einen vollständigen AIOps-Stack ohne eigenes Data-Science-Projekt wollen. Davis AI identifiziert Root Causes automatisch und priorisiert nach Geschäftsauswirkung. Starke Telco-Integration, EU-Datenhosting verfügbar. Lizenzkosten bei Enterprise-Einführungen erheblich (typisch 100.000+ USD/Jahr). Sinnvoll, wenn die netzinterne Observability und Predictive Maintenance in einer Plattform landen sollen.

Datadog — für Carrier mit Cloud-nativer Infrastrukturschicht und DevOps-nahem NOC. ML-basiertes Anomalie-Alerting (Watchdog) erkennt Abweichungen vom Basisverhalten ohne manuell definierte Schwellwerte. EU1-Region in Deutschland. Einstieg mit 5 Hosts kostenlos; bei telco-relevanten Volumen (100+ Hosts, Log-Management) schnell im fünfstelligen Bereich pro Monat.

Zusammenfassung: Wann welcher Ansatz

• AWS-House, kein ML-Team, schneller PoC → Lookout for Equipment
• Azure-House, eigenes Data-Science-Team → Azure ML
• Vendor-homogenes Netz (Nokia-only oder Ericsson-only) → Nokia/Ericsson eigene PdM-Module prüfen
• Multi-Vendor, braucht AIOps-Stack → Dynatrace oder Datadog
• NOC-Dashboard und Visualisierung auf eigenem Stack → Grafana + InfluxDB

Datenschutz und Datenhaltung

Netzwerktelemetrie enthält in aller Regel keine personenbezogenen Daten im Sinne der DSGVO — Temperaturen, Fehlerzähler und Lastprofile sind technische Gerätedaten. Dennoch gibt es zwei relevante Aspekte.

Kritische Infrastruktur und Datenresidenz: Carrier, die als Betreiber Kritischer Infrastruktur (KRITIS) eingestuft sind, unterliegen dem BSI-Gesetz. Die KRITIS-Regulierung verlangt nicht explizit On-Premise-Datenhaltung, legt aber nahe, dass sicherheitskritische Netz-Telemetriedaten und Topologieinformationen unter strikter Zugangskontrolle stehen. Für Cloud-ML-Betrieb empfiehlt sich explizit EU-Hosting (Frankfurt-Region bei AWS, Azure Germany West Central) und ein Auftragsverarbeitungsvertrag mit dem Plattformanbieter.

Ticketing-Daten und personenbezogene Attribute: Das Ticketing-System, aus dem Ausfallzeitpunkte für das Modell-Training gezogen werden, enthält möglicherweise Kundendaten (Anschlussinhaber, Kontaktdaten, Vertragsdetails). Beim Export für ML-Training müssen diese Felder anonymisiert oder pseudonymisiert werden — nur technische Merkmale (Gerät-ID, Ausfallzeitpunkt, Ausfallursache) gehen in das Trainingsset.

AVVs sind bei AWS (EU), Azure und Datadog (EU1) standardmäßig verfügbar. Bei InfluxDB OSS on-premise entfällt die AVV-Frage, weil keine Daten den eigenen Perimeter verlassen.

Regulatorische Realität: § 168 TKG und BNetzA-Meldepflicht

Wer als regionaler Carrier unter das Telekommunikationsgesetz fällt, unterliegt seit der TKG-Novelle 2021 einer verschärften Meldepflicht. § 168 TKG verpflichtet Betreiber öffentlicher Telekommunikationsnetze, erhebliche Störungen mit signifikanten Auswirkungen unverzüglich — und spätestens 24 Stunden nach Bekanntwerden — der Bundesnetzagentur zu melden.

Das hat zwei direkte Auswirkungen auf den Business Case für Predictive Maintenance:

Erstens: Häufige BNetzA-Meldungen fallen auf. Die Behörde veröffentlicht jährlich Statistiken über Netzausfälle und kann bei auffälligen Betreibern regulatorische Prüfverfahren einleiten. Wer die Ausfallhäufigkeit nachweislich senkt, vermindert auch die regulatorische Exposur.

Zweitens: Die Meldepflicht erzeugt dokumentierte Ausfallzeitpunkte und Ausfallursachen — genau die gelabelten Trainingsdaten, die ein ML-Modell für Predictive Maintenance braucht. Carrier, die ihre BNetzA-Meldungen strukturiert archivieren (was viele bereits aus Compliance-Gründen tun), haben damit automatisch einen Teil der Trainingsbasis für ihr Predictive-Maintenance-Projekt — ohne zusätzlichen Aufwand für die Datenbeschaffung.

Was es kostet — realistisch gerechnet

Initiale Projektkosten

Die Projektlaufzeit bis zum produktiven Betrieb beträgt typisch 12–24 Monate. Die wichtigsten Kostentreiber:

• Daten-Engineering und Normalisierung: 40.000–150.000 EUR (abhängig von Netz-Heterogenität und vorhandener NMS-Infrastruktur). Das ist die häufigste Unterkostenposition — Multi-Vendor-Normalisierung dauert länger als geplant.
• ML-Entwicklung und Modellbau: 30.000–80.000 EUR intern (Data-Science-Team, 3–6 Monate) oder externe Systemintegration.
• Infrastruktur (InfluxDB + Grafana on-premise): 5.000–20.000 EUR einmalig für Hardware/VM, plus laufend 1–3 Personentage/Monat Administration.
• Cloud-ML-Alternative (Azure ML oder AWS Lookout): Laufende Plattformkosten 3.000–8.000 EUR/Monat für 500–2.000 Geräte bei täglicher Inferenz — kein eigenes ML-Team nötig.

Laufende Kosten

• Modell-Retraining: 1–2 Personentage/Monat für das Data-Science-Team (oder automatisiert über ML-Pipelines).
• Plattformkosten Cloud: 3.000–8.000 EUR/Monat (skaliert mit Gerätezahl und Inferenzfrequenz).
• NOC-Integration: bei Integration in bestehendes Ticketing (z. B. über ServiceNow oder Jira Service Management) einmalig 5.000–15.000 EUR Integrationsaufwand.

Wie du den ROI tatsächlich misst

Nicht durch Modellierungen, sondern durch Vergleich. Messe 6 Monate vor dem Go-live:

1. Anzahl reaktiver Einsätze pro Monat und durchschnittliche Kosten pro Einsatz
2. MTTR (mittlere Reparaturzeit) bei Ausfällen
3. SLA-Strafzahlungen im Quartal

Nach 12 Monaten Betrieb vergleichst du dieselben Metriken. Bei 30 Prozent Reduktion reaktiver Einsätze und einem durchschnittlichen Dispatch-Kostenunterschied von 1.500 EUR pro Einsatz ergeben sich bei 60 Einsätzen/Monat Einsparungen von etwa 27.000 EUR/Monat — oder über 320.000 EUR im Jahr. Selbst wenn das Projekt 200.000 EUR Anfangsinvestition gekostet hat, ist der Break-even im ersten Betriebsjahr erreichbar.

Typische Einstiegsfehler

1. Mit dem Modell starten, bevor die Datenbasis steht. Das verbreitetste Muster: Ein Carrier beauftragt einen Machine-Learning-Dienstleister, ohne zuvor zu prüfen, ob saubere historische Telemetriedaten mit zugehörigen Ausfallzeitpunkten überhaupt exportierbar sind. In der Praxis sind Telemetriedaten oft in verschiedenen NMS-Systemen fragmentiert, Ausfallzeitpunkte in einem Trouble-Ticket-System ohne strukturierten Gerätebezug, und Gerätestammdaten in einer Excel-Datei, die quartalsweise manuell gepflegt wird. Das ML-Modell ist das letzte Projekt-Element, nicht das erste. Sechs Monate Daten-Engineering kommen davor.

2. Zu viele Gerätetypen auf einmal. Ein Modell für DSLAMs, OLTs, Richtfunkstrecken und Mobilfunkantennen gleichzeitig zu trainieren ist verlockend — aber die Ausfallmuster der verschiedenen Geräteklassen sind so unterschiedlich, dass ein gemeinsames Modell auf keiner der Klassen gut funktioniert. Starte mit der Geräteklasse, auf der die meisten Notfalleinsätze stattfinden. Nach 6–12 Monaten produktivem Betrieb kommen die nächsten Klassen hinzu.

3. Zu viele False Positives nicht adressieren. Das ist der Killer-Fehler — weil er still passiert. Wenn ein Prediction-System in der ersten Betriebswoche dreimal Alarm schlägt und der Techniker dreimal nichts findet, verliert das NOC-Team das Vertrauen. Die Alarme werden ignoriert, das System bleibt aktiv, aber niemand handelt darauf. Das System ist dann teurer als ohne. Die Lösung: Ein klares Precision-Ziel definieren (z. B. mindestens 70 Prozent der Predictions sollen einem echten Problem entsprechen) und das Modell nicht live schalten, bevor dieses Ziel auf dem Validierungsset erreicht ist. In der Praxis bedeutet das mehrere Monate verlängertes Backtesting.

4. Kein Feedback-Loop eingebaut. Das Modell lernt aus historischen Ausfällen. Wenn nach dem Go-live neue Ausfälle auftreten und deren Telemetriedaten nicht systematisch ins Trainingsset zurückfließen, degradiert das Modell mit jeder neuen Gerätesoftware-Version, jedem ausgetauschten Blade, jeder Netzveränderung. Modell-Retraining muss im Betriebskonzept fest eingeplant sein — mindestens quartalsweise, idealerweise monatlich automatisiert.

Was mit der Einführung wirklich passiert — und was nicht

Die Technik ist der einfachste Teil dieses Projekts. Das Schwierigere ist die Organisationsveränderung.

Widerstand im NOC-Team: Predictive-Maintenance-Predictions ändern den Arbeitsalltag des NOC. Statt auf Alarme zu reagieren (vertrauter Rhythmus), sollen Techniker präventiv auf Basis von Wahrscheinlichkeiten disponiert werden. Das braucht Vertrauen in das System — das erst aufgebaut werden muss. Wer die Einführung als “das System entscheidet jetzt” framt, verliert das Team. Wer es als “das System zeigt euch früher, was ihr sowieso in den Daten sehen würdet, wenn ihr Zeit dafür hättet” framt, gewinnt die Akzeptanz deutlich schneller.

Erwartung: Sofortiger Rückgang der Ausfälle. In den ersten drei Monaten werden Ausfälle nicht dramatisch seltener, weil das Modell noch kalibriert wird und das Team noch lernt, mit Predictions umzugehen. Der messbare Rückgang beginnt typisch nach 6–9 Monaten. Wer das intern nicht kommuniziert, riskiert, dass das Projekt nach 3 Monaten als gescheitert gilt — obwohl es auf dem richtigen Weg ist.

Was konkret hilft:

• Monatliche Scorecard mit drei Metriken: Predictions gesamt, davon bestätigt (True Positives), davon falsch (False Positives). Diese Transparenz baut Vertrauen und zeigt, wo das Modell nachgebessert werden muss.
• Einen NOC-Analysten als Modell-Champion benennen, der die Predictions validiert und Feedback strukturiert ans Data-Science-Team gibt.
• Die erste erfolgreich verhinderte SLA-Verletzung explizit kommunizieren — intern und möglichst auch gegenüber dem betroffenen Unternehmenskunden.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir haben das schon im NMS — Schwellwert-Alarme laufen seit Jahren.” Schwellwert-Alarme reagieren, wenn ein Wert eine Grenze überschreitet. Sie entdecken keine multivariaten Muster, bei denen jeder Einzelwert normal ist, aber die Kombination auf einen bevorstehenden Ausfall hindeutet. Das ist der Kernunterschied. Wer 200–500 Alarme pro Tag aus dem NMS bekommt, hat dabei wahrscheinlich auch viele Geräte, die 6 Stunden vor dem Ausfall keinen einzigen Hard-Alarm erzeugen — und dann ausfallen.

„Unsere Techniker kennen die Infrastruktur — die wissen, was bald kaputt geht.” Das stimmt, und es ist wertvoll. Das Problem ist die Skalierung: Bei 2.000 Geräten über 800 km Netzgebiet kann kein Techniker jeden Gerätezustand im Kopf behalten. Predictive Maintenance macht das implizite Erfahrungswissen explizit und auf Tausende von Geräten gleichzeitig anwendbar. Die Techniker-Expertise ist der Kalibrierungsanker für das Modell, nicht sein Ersatz.

„Wir können uns das nicht leisten.” Das kommt auf die Rechnung an. Wenn du 80 Notfalleinsätze pro Monat mit durchschnittlich 2.000 EUR Kosten pro Einsatz hast und 40 Prozent davon verhindern könntest, sind das 64.000 EUR monatliche Einsparung — oder 768.000 EUR pro Jahr. Ein Projekt mit 200.000 EUR Anfangsinvestition amortisiert sich in weniger als vier Monaten. Die richtige Frage ist nicht “können wir uns das leisten”, sondern “können wir uns weiterhin leisten, nicht anzufangen”.

Woran du merkst, dass das zu dir passt

• Du betreibst mehr als 500 DSLAMs, OLTs oder Antennenstandorte in einem zusammenhängenden Versorgungsgebiet — weniger Geräte bedeuten zu wenig Trainingsdaten für zuverlässige Ausfallprognosen
• Dein NOC-Team bearbeitet mehr als 50 Alarme täglich, von denen mehr als 60 Prozent False Positives oder nicht-aktionierbare Ereignisse sind
• Du hattest in den letzten 12 Monaten mindestens 3 Notfalleinsätze, die im Nachgang klar hätten verhindert werden können, wenn jemand die Telemetriedaten der Wochen davor gelesen hätte
• Du hast historische SNMP- oder Telemetriedaten aus mindestens 12 Monaten exportierbar aus deinem NMS — das ist die Mindest-Baseline für Modell-Training
• Du hast Unternehmenskunden mit SLA-Vereinbarungen über 99,9 Prozent Verfügbarkeit, bei denen ein einziger längerer Ausfall Strafzahlungen oder Vertragsauflösungen auslöst
• Dein Netz ist halbwegs homogen — entweder ein dominanter Vendor (Nokia, Ericsson oder Huawei) mit 70+ Prozent Marktanteil im eigenen Netz, oder du hast bereits eine NMS-Schicht, die Multi-Vendor-Daten normalisiert

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter 500 verwaltete aktive Netzgeräte. Das Datenvolumen reicht nicht für ein belastbares ML-Modell — die Ausfallzahl pro Geräteklasse ist zu gering, um aus historischen Mustern statistisch robuste Prognosen abzuleiten. Für kleinere Netze sind regelbasierte Schwellwert-Systeme mit manuell definierten Eskalationspfaden deutlich kosteneffizienter.

2. Weniger als 12 Monate sauber archivierte und abrufbare Telemetriedaten. Ein ML-Modell ohne ausreichende Baseline ist schlechter als kein Modell: Es generiert viele False Positives, verliert das Vertrauen des NOC-Teams, und muss nach 6 Monaten ohnehin von vorne aufgebaut werden. Das Projekt beginnt mit Daten-Archivierung, nicht mit Modell-Training.

3. Keine SNMP-Infrastruktur oder kein NMS mit Datenexport-API. Wenn Telemetriedaten heute weder systematisch gesammelt noch abrufbar sind, ist der erste Schritt der Aufbau der Datenerfassungsschicht — ein eigenständiges 6–12-Monate-Projekt. Das Predictive-Maintenance-Modell kommt danach.

Das kannst du heute noch tun

Exportiere aus deinem NMS die SNMP-Zeitreihendaten eines Geräts, das in den letzten 6 Monaten ausgefallen ist — 4 Wochen vor dem Ausfall bis zum Ausfall. Lade die CSV in ein einfaches Analyse-Tool (Excel, Python, Jupyter) und schau dir folgende Parameter an: Fehlerzähler-Verlauf, Temperatur-Tagesprofil, Lüftergeschwindigkeit, Versorgungsspannung. Suche visuell nach Trends, die sich in den letzten 7–10 Tagen vor dem Ausfall geändert haben.

Das dauert 2–3 Stunden. Was du danach weißt: ob das Ausfallmuster in deinen Daten überhaupt sichtbar wäre — und damit, ob ein ML-Modell auf deiner Datenbasis grundsätzlich funktionieren könnte.

Wenn du diesen ersten Schritt gemacht hast und Muster sehen kannst, ist der nächste Schritt eine strukturierte Datenqualitätsbewertung über alle kritischen Geräteklassen. Hier ist ein Prompt, der dabei hilft:

Quellen & Methodik

• Nokia Predictive Care für Festnetze: Nokia.com (2024); Fallstudien POST Luxembourg (95 % Root-Cause-Beschleunigung) und Swisscom (90 % First-Time-Right-Empfehlungen). Produktseite: nokia.com/broadband-access/services/predictive-care-for-fixed-networks
• Vodafone Germany / Huawei Predictive Maintenance: Interview mit Klaudius Koschella, Head of Access & Transmission Network Operations, Vodafone GmbH; telecoms.com (2017, Grundlagenprojekt, weiterhin referenziert in Branchenliteratur)
• SNMP vs. Streaming Telemetry: World Wide Technology (WWT) Blog „Modernizing Network and Infrastructure Observability: SNMP to Streaming Telemetry” (2024); TechTarget „Telemetry vs. SNMP” (2024)
• Kosten-Delta reaktiv vs. geplant: Branchenkonses 3–5× Mehrkosten für Reactive Dispatch; Oxand „Predictive vs Reactive Maintenance: Cost Analysis Guide” (2024); Multitel „How Preventive Maintenance Lowers Operational Costs for Telecom Operators” (2024)
• Alert Fatigue als Hauptabbruchgrund: IoT For All „Predictive Maintenance Without Alert Fatigue” (2024); LLumin „Why 80 % of Factories Fail at Predictive Maintenance” (2024)
• § 168 TKG: Telekommunikationsgesetz (TKG 2021); Bundesnetzagentur Meldepflicht-Übersicht (bundesnetzagentur.de)
• AWS Lookout for Equipment Preise: AWS-Produktseite (Mai 2026); Inferenz ab 0,15 USD/Stunde je Modell, EU-Region Frankfurt verfügbar
• Fraunhofer-Befund Datenverfügbarkeit: Mittelstand-Digital „Predictive Maintenance in KMU” (2022); Fraunhofer-Institut für IPA-Praxisberichte zur Datenverfügbarkeit

Du willst wissen, ob die Telemetriedaten in deinem NMS für ein Pilot-Projekt taugen — und was die realistischen ersten Schritte für euren Carrier wären? Meld dich — das klären wir konkret.