Backbone-Kapazitätsplanung per KI

Das echte Ausmaß des Problems

Backbone-Kapazitätsplanung ist eine der folgenreichsten Investitionsentscheidungen, die ein Telekommunikationsanbieter trifft — und gleichzeitig eine der methodisch veraltetsten.

Der typische Planungszyklus sieht so aus: Ein Planungsteam von ein bis drei Ingenieurinnen und Ingenieuren sammelt über mehrere Wochen Daten aus OSS, BSS, Netzwerkmanagementsystemen und externen Quellen. Es fügt sie in Excel zusammen, bereinigt Anomalien manuell, bildet Jahresmittelwerte und extrapoliert linear mit einem Sicherheitsaufschlag. Das Ergebnis fließt in Investitionsanträge, die oft sechs bis zwölf Monate vor der geplanten Beschaffung gestellt werden müssen.

Das Problem: Lineares Denken in einem nicht-linearen System.

• Strukturbrüche sind normal. Ein neues Rechenzentrum, ein Streaming-Dienst, ein 5G-Rollout — jedes davon kann die Wachstumskurve eines Knotenpunkts innerhalb von Monaten verdoppeln. Keine lineare Extrapolation sieht das voraus.
• Datensammlung dominiert den Prozess. Laut einer Analyse von Ericsson aus dem Jahr 2020 entfallen bei herkömmlicher Netzwerkplanung rund 60 Prozent der gesamten Planungszeit auf Datenbeschaffung und manuelle Verarbeitung — für die eigentliche Analyse verbleiben weniger als 20 Prozent.
• Überprovisioning ist teuer, Unterprovisioning teurer. Carrier halten im Durchschnitt 25–40 Prozent ungenutzter Backbone-Kapazität vor, um Wachstumsspitzen abzufedern. Das ist gebundenes Kapital in Millionenhöhe. Auf der anderen Seite: Notbeschaffungen kosten im Vergleich zu geplanten Beschaffungen erfahrungsgemäß 15–30 Prozent mehr — und gefährden im Ernstfall SLA-Verträge.
• KI ist in der Branche angekommen. Laut der NVIDIA State-of-AI-in-Telco-Umfrage 2026 nutzen bereits 54 Prozent der Telekommunikationsanbieter weltweit KI für Netzwerkplanung, -deployment und -optimierung — ein Anstieg von 17 Prozentpunkten gegenüber dem Vorjahr. 90 Prozent berichten von positivem ROI.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Prognosegenauigkeit stammt aus Ericssons Beschreibung ihrer KI-gestützten Kapazitätsplanungsanalyse (2020), in der über 75 Prozent Feldsicherheit bei 3-Monats-Prognosen berichtet werden. Alle anderen Werte sind Erfahrungswerte aus Carrier-Projekten — keine repräsentative Studie.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Der Planungsprozess verkürzt sich von 4–8 Wochen auf 1–2 Wochen je Runde — real und messbar, aber der Effekt konzentriert sich auf ein sehr kleines Team von ein bis drei Planungsingenieurinnen und -ingenieuren. Das ist kein Einspareffekt, der sich auf die gesamte Belegschaft verteilt. Verglichen mit Kundensupport-Automatisierung oder SLA-Tracking, die täglich Dutzende Mitarbeitende entlasten, ist der organisatorische Hebeleffekt begrenzt.

Kosteneinsparung — hoch (4/5) Das ist der zentrale Hebel dieser Anwendung. Eine Effizienzverbesserung von 20 Prozent bei Kapazitätsinvestitionen klingt abstrakt — bei einem jährlichen Capex-Budget von 5–50 Millionen Euro für Backbone-Infrastruktur bedeutet das 1–10 Millionen Euro weniger gebundenes oder verschwendetes Kapital. Dazu kommen vermiedene Notbeschaffungskosten und SLA-Strafzahlungen. Kein anderer Anwendungsfall in dieser Branche bewegt sich so nah an der Investitionsentscheidung.

Schnelle Umsetzung — niedrig (1/5) Das ist die realistischste Einschätzung im gesamten Branchenvergleich. Datenbeschaffung aus OSS und BSS, Datenbereinigung und -integration, Modellauswahl und -training, Validierung gegen historische Engpässe, Integration in Planungsprozesse — das dauert 18–24 Wochen in einem gut organisierten Projekt. Wer schneller agieren will, riskiert ein Modell, das auf Trainingsdaten optimiert ist, aber in der Praxis Strukturbrüche nicht erkennt.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist real, aber die Kausalzurechnung ist schwierig. Wenn in diesem Jahr keine Notbeschaffung anfiel: War das das Modell — oder hatte das Netz einfach Glück? Das ist ein strukturelles Problem aller präventiven Systeme. Was sich messen lässt: die Planungseffizienz (Zeitersparnis der Planungsteams), die Überprovisioning-Quote (hat sie sich verändert?), und ob prognostizierte Engpässe tatsächlich eingetreten wären. Ohne aktives Tracking dieser Metriken ab Tag eins wird der ROI-Nachweis schwierig.

Skalierbarkeit — mittel (3/5) Das Modell skaliert mit dem Netz: Mehr Knoten bedeuten mehr Prognoseobjekte, nicht grundlegend mehr Aufwand. Aber die Übertragbarkeit ist begrenzt — jedes Netz hat seine eigene Topologie, seine eigenen Wachstumsmuster, seine eigenen Datenquellen. Ein Modell, das für Netz A funktioniert, ist kein Plug-and-Play für Netz B. Mit wachsendem Netz oder veränderten Wachstumsmustern (5G-Rollout, neues Rechenzentrum) braucht das Modell aktive Pflege.

Richtwerte — stark abhängig von Netzgröße, Datenqualität und verfügbarer Data-Science-Kapazität.

Was das Prognosemodell konkret macht

Der technische Kern ist eine Predictive Analytics-Pipeline, die mehrere Datenquellen verknüpft und automatisch Prognosen über definierte Backbone-Segmente erstellt.

Schritt 1: Datenintegration Das System verbindet sich mit den Telemetriedaten des Netzes (Bandbreitennutzung, Paketdurchsatz, Fehlerraten pro Segment), dem OSS für Topologieinformationen, und externen Signalquellen (Firmenansiedlungen in Versorgungsgebieten, geplante Events, 5G-Ausbauplanung). Diese Daten fließen in eine Zeitreihendatenbank, typischerweise InfluxDB oder ein vergleichbares System.

Schritt 2: Modellierung Für jedes Backbone-Segment wird ein separates Zeitreihenmodell trainiert. Einfachere Segmente mit regelmäßigem Wachstum: klassische Ansätze wie Prophet (Metas quelloffene Zeitreihenbibliothek) modellieren Wochen-, Tages- und Jahressaisonalität direkt. Komplexere Abhängigkeiten zwischen Segmenten: Graph Neural Networks, wie sie AWS für sein eigenes Backbone nutzt — hier erreichte der Ansatz laut AWS-Veröffentlichung (2024) eine 35-prozentige Verbesserung gegenüber klassischem XGBoost bei Prognosen über mehrere Segmente hinweg. Das ist kein Werkzeug für den Einstieg, aber ein realistisches Ziel für eine zweite Ausbaustufe.

Schritt 3: Szenariorechnung Statt einer einzigen Prognose produziert das System mehrere Szenarien: Basisfall (Trendfortschreibung), Wachstumsszenario (neue Kundensegmente, externe Signale), Stressszenario (außergewöhnliche Ereignisse wie Großveranstaltungen). Planerinnen und Planer wählen aus diesen Szenarien oder kombinieren sie — das ist eine ganz andere Qualität der Entscheidungsunterstützung als eine einzelne lineare Hochrechnung.

Schritt 4: Monitoring und Abweichungsalarm Läuft das Modell produktiv, vergleicht es wöchentlich Prognose mit tatsächlichem Traffic. Überschreitet ein Segment die Prognose um mehr als einen definierten Schwellwert (z. B. 15 Prozent), löst das eine Meldung aus. Das ist keine Alarmierung für Ausfälle — das ist ein Frühwarnsystem für Kapazitätstrends.

Datengrundlage: Was wirklich benötigt wird

Das ist oft der unterschätzte Teil. Ein Prognosemodell ist nur so gut wie die Daten, auf denen es trainiert wird — und Netzwerkdaten sind selten so sauber, wie man sich das wünscht.

Mindestanforderungen an historische Daten:

• Mindestens 18 bis 24 Monate stündliche oder 15-minütliche Telemetriedaten je Backbone-Segment (tägliche Mittelwerte reichen nicht, um Tages- und Wochenmuster zu modellieren)
• Topologiedaten des Netzes (welche Segmente sind wie verbunden, welche Knoten haben welche Kapazität)
• Änderungshistorie: Wann wurden Kapazitäten erweitert? Wann gab es Ausfälle oder Wartungsfenster? Nicht modellierte Kapazitätserweiterungen verfälschen das Modell

Externe Signalquellen (wertvoll, aber optional):

• Ansiedlungsdaten aus dem BSS (neue Großkunden, neue Rechenzentren im Versorgungsgebiet)
• Geplante Infrastrukturprojekte (5G-Rollout, FTTx-Ausbau, der Traffic auf bestimmte Segmente verlagert)
• Öffentliche Ereigniskalender für Regionen mit typischen Traffic-Spitzen (Sportveranstaltungen, Messen)

Typische Datenprobleme in der Praxis:

• Monitoring-Daten aus mehreren Systemen mit unterschiedlichen Zeitstempeln und Granularitäten — Harmonisierung kostet Wochen
• Lücken durch Wartungsfenster oder Systemausfälle, die das Modell als unerkannte Anomalien behandelt
• Historische Kapazitätserweiterungen, die nicht systematisch dokumentiert sind — das Modell sieht einen Nachfrageeinbruch, wo in Wirklichkeit die Kapazitätsgrenze angehoben wurde
• OSS und BSS sprechen oft verschiedene Datenmodelle — die Integration ist ein eigenständiges Ingenieursprojekt

Diese Datenarbeit ist der eigentliche Flaschenhals in fast jedem Backbone-Prognose-Projekt. Wer sie unterschätzt, plant zu kurz.

Modellarchitektur und Retraining-Kadenz

Ein wichtiges Detail, das in Projektpräsentationen oft fehlt: Einmal trainieren und fertig ist keine Option. Telekommunikationsnetze sind dynamische Systeme — neue Kunden, neue Dienste, 5G-Rollouts, Rechenzentrumsansiedlungen. Was das Modell vor zwölf Monaten gelernt hat, passt möglicherweise nicht mehr zu dem, was das Netz heute tut.

Concept Drift in der Praxis: Ericsson hält in ihrem Whitepaper zur KI-Adoption in 5G-Netzen fest, dass Konzeptdrift — also die Verschiebung der statistischen Grundgesamtheit, auf der das Modell trainiert wurde — neue Anforderungen an den Lebenszyklus-Management-Prozess stellt. Das ist keine theoretische Warnung: In akademischen Untersuchungen zeigen traditionelle statistische Modelle und viele statische Deep-Learning-Modelle gutes Verhalten kurz nach dem Training, aber deutliche Degradierung, sobald sich die Netzumgebung verändert.

Empfohlene Retraining-Kadenz:

• Routinemäßig: Monatliches Nachtraining mit den aktuellen Telemetriedaten — automatisierbar mit Tools wie MLflow als Experiment-Tracking und Modellversionierung
• Ereignisbasiert: Immer wenn ein struktureller Eingriff erfolgt — neuer Großkunde, Netzausbau, bedeutende technische Änderung — sollte das Modell manuell überprüft und ggf. neu kalibriert werden
• Monitoring der Modellgenauigkeit: Prognose vs. tatsächlicher Wert, wöchentlich visualisiert in Grafana. Wenn die Abweichung systematisch anwächst, ist das ein Signal für Drift, nicht für Netzprobleme

Wer ist verantwortlich? Dieses System braucht eine Eigentümerschaft — eine Data-Science-Funktion oder mindestens eine Person mit ML-Kompetenz, die nicht nur das Modell baut, sondern es dauerhaft betreibt. Ohne namentliche Zuständigkeit für Monitoring und Retraining ist das Ergebnis nach 12–18 Monaten ein Modell, das selbstbewusst falsche Prognosen liefert.

Kapazitätsreservelogik: Der richtige Puffer

Das ist eine Ingenieursentscheidung, die oft pauschal getroffen wird: 20 Prozent Aufschlag auf die Prognose, fertig. Ein ML-Modell ermöglicht eine fundamentale Verbesserung dieser Logik.

Konfidenzintervalle statt Daumenregel: Gute Zeitreihenmodelle — Prophet tut das nativ, andere Modelle brauchen Zusatzlogik — produzieren nicht nur einen Prognosewert, sondern ein Konfidenzintervall. Der 95. Perzentilwert sagt: “In 95 Prozent der möglichen Szenarien wird die tatsächliche Nachfrage unter diesem Wert liegen.” Das ist ein statistisch begründeter Puffer, kein Daumenaufschlag.

Segmentspezifische Puffer: Nicht jedes Backbone-Segment hat dieselbe Planungsunsicherheit. Ein stabiles Transitnetz zwischen zwei Ballungszentren mit vorhersehbarem Wachstum braucht weniger Reserve als ein Knotenpunkt in einem Wachstumsgebiet mit unstrukturierten Neuentwicklungen. Das Modell macht diese Unterschiede sichtbar — und erlaubt es, Reserve dort zu konzentrieren, wo sie gebraucht wird, statt überall gleichmäßig dieselbe Puffermarge anzusetzen.

Lead-Time-adjustierter Planungshorizont: Backbone-Hardware (Dense Wavelength Division Multiplexing-Equipment, optische Verstärker, Router-Line-Cards) hat Lieferzeiten von 6 bis 18 Monaten. Das bedeutet: Eine Kapazitätsentscheidung heute muss auf dem Nachfrageniveau von in 12 bis 18 Monaten basieren. Ein Modell, das nur 3 Monate vorausblickt, ist für die Beschaffungsplanung wenig hilfreich. Der Prognosehorizont muss zur Lieferkettensituation der Beschaffungsorganisation passen — das ist eine Anforderung, die oft vergessen wird.

Konkrete Werkzeuge — was wann passt

Prophet — Die naheliegende Einstiegslösung für Carrier, die Python-Know-how im Haus haben und ohne spezialisierte ML-Infrastruktur starten wollen. Prophet modelliert saisonale Verkehrsmuster, Feiertagseffekte und Trend-Strukturbrüche mit vergleichsweise wenig Konfigurationsaufwand. Vollständig kostenlos (Open Source, MIT-Lizenz). Einschränkung: Keine nativen Topologie-Abhängigkeiten zwischen Segmenten — jedes Segment wird unabhängig modelliert.

InfluxDB — Als Zeitreihendatenbank für die Speicherung und Vorverarbeitung der Netztelemetriedaten. Die Open-Source-Variante lässt sich on-premise betreiben — für Carrier mit KRITIS-Anforderungen ein wesentlicher Punkt. Die integrierte Flux-Abfragesprache erlaubt erste Aggregationen und Anomalie-Queries direkt auf den Rohdaten.

Grafana — Für die Visualisierung von Prognosen, Konfidenzintervallen und Abweichungen. Grafana verbindet sich direkt mit InfluxDB und zeigt Planern, wie Ist-Traffic und Modellprognose auseinanderrücken. Grafana ML ermöglicht zusätzlich ML-basierte Anomalieerkennung auf den laufenden Traffic-Zeitreihen. Open-Source-Version ist kostenlos self-hostbar.

MLflow — Als Experiment-Tracking- und Modell-Registry-Lösung, wenn mehrere Modellversionen parallel bewertet und verwaltet werden sollen. MLflow hält fest, welches Modell wann trainiert wurde, auf welchen Daten, und wie gut es in der Retrospektive prognostiziert hat. Vollständig kostenlos (Open Source, Apache 2.0) bei Self-Hosting.

Datadog — Wer bereits Datadog für Netzwerkmonitoring einsetzt, kann dessen ML-basierte Anomalieerkennung (Watchdog) als ersten Schritt nutzen — kein neues System, sondern eine Erweiterung bestehender Monitoring-Infrastruktur. Einschränkung: Datadog ist kein Kapazitätsplanungstool im engeren Sinne; die Prognosefähigkeiten sind auf kurzfristige Anomalieerkennung ausgelegt, nicht auf 6–12-Monats-Kapazitätsprognosen.

Wann welcher Ansatz:

• Erster Pilot, Python-Know-how vorhanden, einfache Segmente → Prophet + InfluxDB + Grafana
• Mehrere Segmente mit Topologieabhängigkeiten, Graph-basierte Modelle → Python + NetworkX + Grafana (individuelles ML-Projekt)
• Größeres Team, Modellversionierung wichtig → MLflow als Tracking-Schicht ergänzen
• Bestehende Datadog-Infrastruktur → als Einstieg nutzen, aber langfristig um dediziertes Forecasting ergänzen

Datenschutz und Datenhaltung

Backbone-Kapazitätsdaten sind keine personenbezogenen Daten im Sinne der DSGVO — Zeitreihendaten über aggregierten Netzwerktraffic enthalten in der Regel keine direkt personenbezogenen Informationen. Trotzdem gibt es relevante datenschutzrechtliche und regulatorische Aspekte.

KRITIS-Relevanz: Viele mittlere und große Carrier fallen unter die Kritische-Infrastruktur-Regelungen (KRITIS) nach BSI-Gesetz. Das stellt Anforderungen an die IT-Sicherheit und Datenhaltung der Netzwerkmanagement-Systeme — und damit auch an die Systeme, die auf deren Daten zugreifen. Wer Netzdaten in Cloud-Systeme überträgt, sollte das mit der IT-Sicherheitsabteilung und dem BSI-Beauftragten abstimmen.

Datenresidenz-Anforderungen: Für Carrier mit KRITIS-Einstufung empfiehlt sich die Verarbeitung der Netzdaten auf eigener Infrastruktur oder auf zertifizierten deutschen/europäischen Cloud-Plattformen. InfluxDB und Grafana können vollständig on-premise betrieben werden — das ist für diesen Anwendungsfall oft die sauberste Lösung.

Drittanbieter-Systeme: Wenn Prognosedaten oder Modelle auf Plattformen wie Databricks oder AWS SageMaker laufen, gelten EU-Anforderungen für API-basierte Datentransfers. Für viele Carrier ist das ein Hinderungsgrund für Cloud-Ansätze — nicht wegen DSGVO, sondern wegen IT-Sicherheitsrichtlinien. Prüfe das frühzeitig, bevor Tool-Entscheidungen getroffen werden.

BSS/OSS-Daten: Wenn Kundendaten aus dem BSS (z. B. Unternehmensnamen als Annotation für Traffic-Spitzen) in das Prognosemodell einfließen, gilt DSGVO. In diesem Fall AVV mit dem Tool-Anbieter oder vollständige On-Premise-Verarbeitung.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• Datenintegration (OSS/BSS-Anbindung, Historisierung): 4–12 Wochen Ingenieurzeit, intern oder extern; externe Kosten 20.000–80.000 Euro je nach Heterogenität der Quellsysteme
• Modellentwicklung und -validierung: 3–6 Monate Data-Science-Kapazität, intern oder als Projektauftrag an spezialisierte Dienstleister; Tagessätze für spezialisierte ML-Ingenieurinnen und -Ingenieure: 1.200–2.500 Euro
• Gesamtprojektbudget für einen realistischen Carrier-Piloten mit 10–50 Backbone-Knoten: 60.000–200.000 Euro

Laufende Kosten (monatlich)

• Open-Source-Stack (Prophet + InfluxDB + MLflow + Grafana), on-premise: Infrastrukturkosten 500–3.000 Euro/Monat, je nach Datenvolumen; kein Lizenzaufwand
• Personalaufwand für Modellpflege und Monitoring: 0,2–0,5 FTE einer Data-Science-Funktion; kein rein technisches Problem, wer das vernachlässigt, hat nach 18 Monaten ein nicht mehr brauchbares Modell
• Externe Beratungsunterstützung für Retraining-Zyklen (optional): 500–1.500 Euro/Monat

Was du dagegenrechnen kannst Ein Carrier mit 100 Millionen Euro jährlichem Backbone-Capex und einer um 20 Prozent verbesserten Investitionseffizienz spart 20 Millionen Euro — in einem einzigen Planungszyklus. Das ist eine Zahl aus dem McKinsey-Report zu KI-gestützten Telekommunikationsnetzwerken (2021), der 15–30 Prozent Opex-Reduktion durch KI-gestützte Netzwerkoptimierung als realistischen Bereich benennt. Nicht alle Carrier haben solche Budgets — bei einem regionalen Carrier mit 5 Millionen Euro Backbone-Capex wäre dieselbe Effizienzverbesserung 1 Million Euro jährlich.

Wie du den Nutzen wirklich misst Die ehrlichste Methode: Vergleich der tatsächlichen Überprovisioning-Quote vor und nach Einführung des Systems. Wie viel Kapazität liegt dauerhaft brach? Ist die Quote gesunken? Außerdem: Zähle, wie viele Notbeschaffungen in einem Jahr nötig waren — und ob das weniger ist als vorher. Das ist unbequemer als eine theoretische Rechnung, aber es ist der Nachweis, der im Investitionsausschuss Bestand hat.

Drei typische Einstiegsfehler

1. Mit zu wenig Historiendata starten. Es ist verlockend, schnell loszulegen und das Modell auf 6–12 Monaten Daten zu trainieren. Das reicht nicht, um Jahressaisonalität korrekt zu modellieren — Weihnachtspeaks, Sommerferien, Messetermine. Ein Modell, das nur einen Sommer gesehen hat, kennt den nächsten nicht. Mindestens 18, besser 24 Monate stündliche Granularität sollten vorliegen, bevor das erste Produktivmodell deployed wird.

2. Datenintegration unterschätzen. Das Modell ist in drei Monaten trainiert. Die Datenintegration dauert sechs. OSS und BSS sprechen selten dieselbe Sprache, Zeitstempelformate weichen ab, Wartungsfenster erzeugen Lücken in den Telemetriedaten, und die Kapazitätserweiterungshistorie ist oft nur in Mails dokumentiert. Wer das nicht als eigenständiges Teilprojekt plant, blockiert später den gesamten Projektfortschritt.

3. Kein Monitoring der Modellgenauigkeit einrichten. Das ist der gefährlichste Fehler — weil er still passiert. Ein Zeitreihenmodell, das zu Beginn gut performt, degradiert bei Strukturbrüchen im Netz. Wenn niemand wöchentlich Prognose gegen Ist-Wert vergleicht und bei systematischer Abweichung eingreift, produziert das Modell nach 12 Monaten selbstbewusst falsche Prognosen — und niemand merkt es, bis eine Kapazitätsentscheidung auf Basis falscher Zahlen getroffen wurde. Was löst ein Retraining aus? Das muss festgelegt werden, bevor das System in Betrieb geht.

4. Den Planungsprozess nicht mitverändern. Ein neues Prognosemodell ohne angepassten Planungsprozess ist Technologie auf dem Abstellgleis. Wenn die Planungsingenieurinnen und -ingenieure weiterhin ihre eigene Tabelle pflegen und das Modell als Kontrollblick benutzen — ohne Konsequenzen —, wird das System mittelfristig aufgegeben. Die Einführung muss mit der Frage beginnen: Welche Entscheidung wird künftig wie getroffen, und wer ist dafür zuständig?

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

Backbone-Kapazitätsplanung ist kein Self-Service-Prozess, den man mit einem neuen Tool von heute auf morgen ändert. Hier sind die Widerstands- und Adoptionsmuster, die in der Praxis auftreten.

Das Erfahrungswissen-Problem. Petra Steinhauer weiß, dass der NRW-Knotenpunkt im dritten Quartal immer höher läuft als die ersten beiden — wegen der Firmenmessen in Düsseldorf. Dieses Wissen steckt nirgendwo im System. Ein Modell, das nur auf Telemetriedaten trainiert ist, sieht diese Saisonalität entweder aus den Daten oder gar nicht. Die Einführungsphase muss explizit Zeit dafür einplanen, dieses Erfahrungswissen in externe Regressoren und Kalenderannotationen zu übersetzen — oder es geht verloren.

Die Zuständigkeitsfrage. Wer ist Eigentümer des Modells? Die Netzplanung? Die IT? Die Data-Science-Funktion, falls es sie gibt? Diese Frage wird oft nicht beantwortet, bis das Modell zum ersten Mal falsch liegt — und dann streiten zwei Abteilungen darum, wer schuld ist. Besser: Im Projekt explizit klären, wer das Modell pflegt, wer es validiert, und wer bei systematischer Degradierung entscheidet, es neu zu trainieren oder zu rekalibrieren.

Der erste Fehler kommt. Irgendwann wird das Modell einen Trend nicht sehen, den ein Planungsingenieur intuitiv schon geahnt hatte. Oder es wird einen Trend prognostizieren, der nicht eintritt. Wenn dieser Moment kommt, ohne dass das Team vorbereitet ist, kann das die Akzeptanz für das gesamte System gefährden. Was hilft: Von Anfang an kommunizieren, dass das Modell kein Orakel ist, sondern ein Entscheidungsunterstützungssystem. Der Planungsingenieur behält die letzte Entscheidung — das Modell liefert mehr und bessere Szenarien als bisher.

Was konkret hilft:

• Einen Piloten mit einem einzigen gut dokumentierten Netzabschnitt starten, der das Potenzial des Ansatzes zeigt, ohne dass das gesamte Planungsteam von Anfang an involviert ist
• Die Planungsingenieurinnen und -ingenieure als Hauptnutzer (nicht als Stakeholder) behandeln: Was brauchen sie, in welcher Form, in welchem Rhythmus?
• Modellgenauigkeit transparent machen: monatliche Retrospektive, Prognose gegen Ist, im Team besprochen

Realistischer Zeitplan mit Risikohinweisen

Achtung: Die Zeitangaben setzen voraus, dass Data-Science-Kapazität im Haus oder durch externe Dienstleister bereitsteht. Wer das Projekt mit bestehenden Netzplanungsingenieuren ohne ML-Hintergrund angehen will, braucht entweder externe Unterstützung oder muss den Zeitplan deutlich nach hinten verschieben.

Häufige Einwände — und was dahintersteckt

„Wir haben schon ein Forecasting-Tool im OSS.” Die meisten OSS-Systeme enthalten eine einfache Trendextrapolation, keine ML-basierte Szenariorechnung. Der Unterschied: Extrapolation verlängert die Vergangenheit. Ein ML-Modell lernt nicht-lineare Muster, saisonale Schwankungen und externe Einflüsse. Wenn dein OSS-Forecasting keine Konfidenzintervalle und keine Szenarienvarianten liefert, ist es kein vollwertiger Ersatz.

„Unsere Daten sind zu unvollständig.” Das ist ein ernst zu nehmender Einwand. Wenn weniger als 12 Monate historischer Telemetriedaten auf Stundenbasis vorliegen oder wenn die Daten Lücken über mehrere Wochen haben, ist jetzt nicht der richtige Zeitpunkt für ML-basierte Prognosen. Lass die Datenbasis erst auf 18–24 Monate anwachsen — das ist eine ehrliche Empfehlung, keine Ausrede.

„KI ist zu teuer und zu komplex für unser Unternehmen.” Für regionale Carrier mit weniger als 20 Backbone-Knoten und einem Capex-Budget unter 2 Millionen Euro stimmt das. Das Projektbudget von 60.000–200.000 Euro steht nicht in einem vernünftigen Verhältnis zum möglichen Nutzen. Hier empfiehlt sich ein besserer Excel-Prozess, keine ML-Lösung.

„Wir haben keine Data-Science-Kapazität.” Das ist kein Einwand gegen die Idee, sondern gegen den Zeitpunkt. Eine dauerhafte Lösung braucht eine dauerhafte Zuständigkeit. Externe Dienstleister können das Modell bauen — aber wer pflegt es in 18 Monaten? Ohne Antwort auf diese Frage ist das Projekt kein guter Start.

Woran du merkst, dass das zu dir passt

• Dein Backbone-Netz umfasst mindestens 20–30 Knotenpunkte mit eigenem, differenziertem Wachstumsverhalten
• Du hast mindestens 18 Monate historische Telemetriedaten auf Stunden- oder Viertelstundenbasis — vollständig, nicht lückenhaft
• Dein jährliches Backbone-Capex-Budget liegt über 5 Millionen Euro — darunter lohnt das Projektbudget kaum
• Du hast mindestens einmal eine ungeplante Kapazitätserweiterung als Notfallmaßnahme durchgeführt — und weißt, was das kostet
• Du hast Data-Science-Kapazität im Haus oder kannst sie langfristig aufbauen oder einkaufen
• Deine Planungszyklen dauern mehr als 4 Wochen und die Datenbeschaffung ist der größte Zeitfresser

Wann es sich nicht lohnt — drei harte Ausschlusskriterien:

1. Unter 20 Backbone-Knoten oder unter 5 Millionen Euro jährlichem Capex. Das Projektbudget und der laufende Betrieb stehen in keinem vernünftigen Verhältnis zum möglichen Nutzen. Ein verbesserter manueller Prozess mit klar definierten Prognoseformaten und regelmäßigen Datenexporten aus dem OSS ist die bessere Investition.

2. Weniger als 18 Monate vollständiger Stundengranularitätsdaten. Ein Modell auf dieser Datenbasis wird Jahressaisonalitäten nicht kennen und bei Strukturbrüchen früh scheitern. Warte, bis die Datenbasis ausreichend ist — das ist kein Aufschub, das ist Qualitätssicherung.

3. Keine nachhaltige Data-Science-Zuständigkeit vorhanden oder planbar. Wer das Modell baut und wer es in 18 Monaten pflegt, muss vor dem Projektstart feststehen. Ohne diese Zuständigkeit riskierst du ein System, das nach zwei Jahren veraltete Prognosen produziert, ohne dass es jemand bemerkt.

Das kannst du heute noch tun

Starte mit einer einfachen Machbarkeitsanalyse: Lade dir die letzten 24 Monate monatlicher Trafficdaten für einen einzelnen, gut beobachteten Backbone-Knotenpunkt herunter und mach eine manuelle Retrospektive. Wo lagen deine linearen Extrapolationen falsch? Wann hättest du früher handeln müssen? Dieser Schritt kostet einen halben Arbeitstag und zeigt dir, ob das Problem groß genug ist, um ein ML-Projekt zu rechtfertigen.

Für einen ersten technischen Test: Installiere Prophet (pip install prophet), nimm denselben Datensatz, und lass das Modell auf den ersten 18 Monaten trainieren. Prüfe dann, wie gut es die letzten 6 Monate prognostiziert hätte. Das ist kein Produktivsystem — aber es zeigt, ob der Ansatz für deine konkreten Daten funktioniert.

Den folgenden Prompt kannst du nutzen, um deine aktuelle Planungsmethodik systematisch zu evaluieren und Verbesserungspotenziale zu identifizieren:

Quellen & Methodik

• Ericsson, „How AI will impact network capacity planning decisions” (2020): Beschreibt die Verschiebung von 60 % Planungszeit für Datenbeschaffung hin zu automatisierter Datenverarbeitung; berichtet über 25 % Reduktion bei Carrier- und Standorterweiterungen sowie über 75 % Feldsicherheit bei 3-Monats-Prognosen. URL: ericsson.com/en/blog/2020/12/ai-and-network-capacity-planning-decisions
• AWS Machine Learning Blog, „Mitigating risk: AWS backbone network traffic prediction using GraphStorm” (2024): Beschreibt den GNN-basierten Ansatz für Backbone-Traffic-Prognosen bei AWS, 35 % Verbesserung gegenüber XGBoost, Inferenz unter 2 Sekunden. URL: aws.amazon.com/blogs/machine-learning/mitigating-risk-aws-backbone-network-traffic-prediction-using-graphstorm/
• NVIDIA, State of AI in Telecommunications 2026 Survey: 54 % der Carrier nutzen KI für Netzplanung (plus 17 Pp. ggü. Vorjahr), 90 % berichten positivem ROI. URL: blogs.nvidia.com/blog/ai-in-telco-survey-2026/
• McKinsey, „Issue Brief: AI-driven telecom networks” (2021): 15–30 % Opex-Reduktion durch KI-gestützte Netzwerkoptimierung als realistischer Bereich. URL: mckinsey.com/industries/technology-media-and-telecommunications
• Ericsson, Whitepaper „Accelerating the adoption of AI in programmable 5G networks”: Hält explizit fest, dass Konzeptdrift in KI/ML-Modellen neue Anforderungen an Lifecycle-Management-Prozesse stellt. URL: ericsson.com/en/reports-and-papers/white-papers/accelerating-the-adoption-of-ai-in-programmable-5g-networks
• Lohrasbinasab et al., „From statistical- to machine learning-based network traffic prediction” (2022), Transactions on Emerging Telecommunications Technologies: Bestätigt, dass statische Modelle nach anfänglich gutem Verhalten bei veränderten Netzumgebungen schnell degradieren. DOI: 10.1002/ett.4394
• Implementierungskosten: Erfahrungswerte aus Carrier-Projekten; Tagessätze für ML-Ingenieure nach Markterhebungen Frühjahr 2026.

Du willst die Datenbeschaffung aus deinem OSS konkret durchdenken oder wissen, welcher Modellansatz für deine Netzgröße realistisch ist? Meld dich — das klären wir in einem kurzen Gespräch.