Mobilfunknetz (RAN): Optimierung & Energieeinsparung

Das Funkzugangsnetz (RAN) ist der größte Energieverbraucher eines Mobilfunkbetreibers, doch die meisten Standorte laufen rund um die Uhr mit voller Leistung, obwohl der Verkehr nach Stunde und Ort stark schwankt. KI-Agenten prognostizieren die Last auf Zellebene und schalten Kapazitätsschichten, Träger oder Funkkomponenten in Schlafmodi, wenn der Bedarf es zulässt; zugleich stimmen sie Neigung, Leistung und Handover-Parameter ab, damit Abdeckung und Nutzererlebnis erhalten bleiben. Das ist ein konkreter Schritt hin zu autonomen Netzen und senkt außerdem Betriebskosten und CO2.

Problem & Nutzen

• Heute: Ingenieure legen statische Energiesparregeln fest (feste nächtliche Abschaltung einer Kapazitätsschicht) und stimmen Parameter per Messfahrten, Zähleranalyse und regelbasierten SON-Funktionen ab. Die Regeln sind vorsichtig, weil eine falsche Abschaltung ein Funkloch oder eine überlastete Nachbarzelle bedeutet. Netze mit mehreren Herstellern und Technologien (2G-5G) und Hunderttausenden Zellen machen die manuelle Abstimmung langsam.
• KI-Nutzen: Verkehrsprognosen je Zelle ermöglichen feinere, mutigere Schlafentscheidungen; RL oder beschränkte Optimierung wägt Energie gegen Durchsatz, Erreichbarkeit und Haltbarkeit der Verbindungen ab; eine geschlossene Regelschleife reagiert binnen Minuten auf Ereignisse statt wöchentlich.
• Belegte Hinweise: Energie ist ein großer Teil der Betriebskosten von Betreibern, und das RAN dominiert ihn (GSMA und Nachhaltigkeitsberichte der Betreiber [2]). Tests von Herstellern und Betreibern berichten von Stromeinsparungen im zweistelligen Prozentbereich, ohne dass hier eine einzelne überprüfte Kennzahl genannt wird; solche Werte sind testspezifisch und hängen von Ausgangslage, Verkehrsprofil und QoS-Vorgaben ab, messen Sie daher Ihre eigene Ausgangslage.

Varianten

• Funk-Energieeinsparung: Träger-/Zellen-Ein/Aus, Symbol-/Kanal-/Tiefschlaf bei Massive-MIMO-Funkeinheiten, Optimierung der Leistungsverstärker, Verkehrslenkung auf effiziente Schichten.
• Selbstoptimierende Netze (SON): automatische Nachbarbeziehungen, Mobilitätsrobustheit, Lastverteilung, Optimierung von Abdeckung und Kapazität (3GPP SON/MDA) [3].
• Netzplanung im Telekommunikationsbereich: KI-gestützte Standort-, Kapazitäts- und Frequenzplanung; Abdeckungsprognose aus Messfahrt- und Crowd-Daten; Priorisierung von Investitionen (Glasfaserausbau: OPT-036).
• AI-RAN: GPU-/beschleunigte Rechenleistung, die am Netzrand sowohl RAN-Funktionen als auch KI-Workloads hostet (AI-RAN Alliance, NVIDIA Aerial); der Energie-Zielkonflikt verlagert sich auf die Rechenauslastung [5].
• O-RAN rApps/xApps: Apps außerhalb von Echtzeit (Non-RT RIC, >1 s) und nahe Echtzeit (10 ms-1 s) von Drittanbietern über offene Schnittstellen [4].
• Private 5G- / Campus-Netze: dieselbe Logik im kleinen Maßstab, meist vom Hersteller betrieben.
• LLM-NetOps-Copiloten: Fehlersuche in natürlicher Sprache und absichtsbasierte Konfiguration; näher an CODE-010 (Störungs-Ursachenanalyse) und KNOW-004 (technische Dokumentation) und dort behandelt.

So funktioniert es

1. PM-Zähler + CM + Energiezähler (OSS/Data Lake, Streaming)
2. Feature Store (Zelle, Stunde, Nachbarn, Ereignisse)
3. Verkehrsprognose je Zelle (Zeitreihenmodell, Stunden bis Tage im Voraus)
4. Regel-Engine: Kandidatenaktionen (Schlafmodus, Träger aus, Neigung/Leistung, Offsets) begrenzt durch QoS-Leitplanken und Nachbarkapazität
5. Digital-Twin- / Simulationsprüfung der Aktion (Abdeckung, Lastverschiebung)
6. Aktion über rApp/xApp, SON oder Herstellersteuerung (offene Schleife: empfehlen
7. geschlossene Schleife: anwenden)
8. Überwachung: KPI-Verschlechterung
9. automatischer Rollback und Aufwecken
10. Lernen aus den Ergebnissen (RL-Belohnung = eingesparte Energie − QoS-Strafe)

• Prognose: Gradient Boosting oder tiefe Zeitreihenmodelle auf Zählern (tägliche/wöchentliche Saisonalität, Ereignisse, Wetter); Foundation-Modelle für Zeitreihen werden erprobt.
• Entscheidungsschicht: beschränkte Optimierung oder sicheres/Offline-RL; harte Leitplanken (Mindestabdeckung, Notruffähigkeit, geschützte Standorte wie Krankenhäuser) sind Regeln und werden nicht gelernt.
• Mensch-in-der-Schleife (Human-in-the-Loop): Neue Strategien starten im reinen Empfehlungsmodus; Ingenieure geben den Rollout je Cluster frei; Rollback und Notaus sind Pflicht; Änderungen werden protokolliert.

Datenaufbereitung

Die Daten sind Performance-Management-Zähler (PM), Konfigurationsmanagement-Stände (CM), Alarme und Energiezählerwerte je Zelle, die typischerweise im Hersteller-OSS, in Data Lakes der Betreiber und in Standortdatenbanken liegen; Planungs- und Standortstammdaten befinden sich in separaten Inventarwerkzeugen. Typische Lücken: Zählerdefinitionen, die je Hersteller und Softwarestand abweichen, fehlende oder verschobene Zeitstempel, Lücken durch Ausfälle der Erfassung, abweichende Zellnamen zwischen OSS und Inventar, Energiezähler nicht an jedem Standort und nicht protokollierte Änderungshistorie, sodass sich Wirkungen früherer Maßnahmen nicht von natürlichen Verkehrsschwankungen trennen lassen.

Schritte der Aufbereitung: 1. Quellen erfassen und Verantwortliche benennen (PREP-001, PREP-004); das OSS über Exporte oder APIs anbinden (PREP-005). 2. Eine harmonisierte Zell-Stammtabelle mit Standort, Nachbarn, Hersteller und Trägerschichten aufbauen (PREP-011, PREP-012). 3. Zähler über Hersteller und Softwarestände hinweg normalisieren und KPI-Definitionen dokumentieren (PREP-012). 4. Lücken füllen und Ausfälle markieren; CM-Änderungsprotokolle und Energiewerte zusammenführen. 5. Geschützte Standorte (Krankenhäuser, Notruf-Abhängigkeiten) als regelbasierte Leitplanken kennzeichnen. 6. Testzeiträume für Backtests anlegen (PREP-018).

Die Daten sind überwiegend Netzdaten und keine personenbezogenen Daten, aber aus Sicherheitsgründen sensibel. Rechnen Sie mit 50-60 % des Aufwands für Datenharmonisierung und OSS-Integration. Siehe auch DATA-003 und GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• enterprise (Betreiber, Funkturmgesellschaften): A, weil die Energiesparfunktionen der Hersteller in zertifizierte RAN-Software integriert sind und Gewährleistung und Support erhalten bleiben.
• developer: C, weil die RIC der O-RAN Software Community, Sionna und offene ML-Bibliotheken den Bau und Test von rApps ohne Lizenzkosten erlauben.
• public (Regulierer, kommunale oder Campus-Netze, Forschung): C, weil private Netze und Forschungstestumgebungen offene RIC- und srsRAN-Stacks auf eigener Hardware mit voller Kontrolle über Daten und Code betreiben können.

Weg A — Kaufen (Standardlösung für Betreiber und Funkturmgesellschaften)

• RAN-Hersteller mit eingebauten KI-Energiefunktionen: Ericsson (Intelligent Automation Platform, Radio-Energy-Saving-Funktionen; EU/Schweden), Nokia (MantaRay, Energy Efficiency; EU/Finnland), Huawei und ZTE (außerhalb der EU; in vielen Mitgliedstaaten gelten Lieferketten-Beschränkungen).
• SON/Automatisierung für mehrere Hersteller: Amdocs, Viavi, Cellwize/Qualcomm, Rakuten Symphony, Mavenir, Juniper (RIC) sowie in der EU ansässige Spezialisten vom Typ Net-AI/Opanga; prüfen Sie die tatsächliche Verfügbarkeit 2026.
• A wählen, wenn: Sie ein Produktivnetz betreiben, da Herstellerfunktionen in zertifizierte RAN-Software integriert sind und Gewährleistung und Support erhalten bleiben.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Telko-Data-Lake auf Azure, AWS oder Google Cloud (EU-Regionen) oder in souveränen EU-Clouds; verwaltete Zeitreihen- und AutoML-Dienste für Prognosen sowie Streaming-Einspeisung von PM-Dateien.
• LLM-APIs nur für die Copilot-Schicht (Zusammenfassung von Änderungen, Erklärungen, Erfassung von Absichten), niemals zur direkten Parametersteuerung. Nutzen Sie nach Möglichkeit einen Modell-Endpunkt in der EU-Region.
• Entscheidungen als O-RAN-rApps auf dem Non-RT RIC des Betreibers bereitstellen (z. B. Ericsson, Nokia oder Open-Source-RIC).

Weg C — Selbst betreiben (Open Source)

• RIC-Plattform: Near-RT RIC und Non-RT RIC der O-RAN Software Community (Linux Foundation) [4]; srsRAN Project und OpenAirInterface für Labor und private Netze.
• ML-Stack: Python mit scikit-learn/LightGBM, PyTorch, Ray RLlib oder Stable-Baselines3 für RL, Sionna (NVIDIA, Open Source) für Link-Level- und Systemsimulation, Kafka/Flink für Streaming.
• Hardware: HW1 genügt für Prognose und Inferenz; HW2 für RL-Training und Simulation. Hauptkosten sind die Integration mit dem Hersteller-OSS, nicht die Rechenleistung.

Weg D — Eigenes Training

Lohnt sich für große Betreiber mit eigenen Data-Science-Teams: standortspezifische RL-Strategien in einem Digital Twin trainieren und dann mit Schutzmaßnahmen übertragen. Erfordert Monate an Zählerdaten je Zelle, Konfigurationshistorie und einen validierten Simulator; Offline-RL und konservative Strategie-Updates verringern das Risiko der Exploration im Livebetrieb.

Stand der Technik (2026)

• Energieeinsparung ist der ausgereifteste KI-Anwendungsfall im RAN: Große Hersteller liefern KI-gesteuerte Zell-/Träger- und Funk-Schlaffunktionen, und Betreiber führen Closed-Loop-Tests im großen Maßstab durch. Standardisierung: 3GPP- Spezifikationen zu Energieeinsparung und SON/MDA, rApp-/xApp-Spezifikationen der O-RAN Alliance [3][4].
• Open-RAN-rApps schaffen einen Marktplatz für Optimierung durch Dritte, doch Interoperabilität zwischen Herstellern und Lücken im Datenmodell bremsen die Verbreitung.
• AI-RAN (beschleunigte Rechenleistung für RAN und KI) geht von Tests in frühe Einsätze über; die Netto-Energiebilanz hängt von der Auslastung ab [5].
• Grenzen und Fehlerbilder: Prognosefehler bei Ereignissen (Konzerte, Ausfälle), Funklöcher nach dem Schlafmodus, Ping-Pong-Handover, Reward Hacking beim RL, Rückkopplungen zwischen unabhängig optimierten Nachbarzellen sowie Lücken zwischen Simulation und Realität. Einsparungen schrumpfen oft, sobald QoS-Leitplanken den geschäftlichen SLAs entsprechen. Quantifizierte Ergebnisse sollten per A/B-Test gegen Kontrollcluster geprüft werden.

Gemeinsame Bausteine & Kombinationen

• Gleiche Fähigkeiten (time-series, optimization-solver, reinforcement-learning): OPT-007 Gebäude- energie, OPT-022 Netzengpässe, OPT-025 Verkehrssignale, OPT-015 Cloud-Kosten; ein MLOps-/Feature- Store-Stack kann mehrere bedienen.
• Vor-/nachgelagert: PRED-019 (Methoden der Bedarfsprognose), CODE-010 (AIOps-Ursachenanalyse bei Netzstörungen), KNOW-004 (NetOps-Dokumentations-Copilot), ANOM-024 (Telekom-Betrug auf denselben OSS/BSS-Daten), SEC-015 (Sicherheitsüberwachung von OT/IoT).

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für die Aktivierung der Funktionen, 3-9 Monate für den Rollout über ein Netz.
• Weg B/C: 6-18 Monate inkl. Datenpipelines, Leitplanken und Abnahme durch den Netzbetrieb.
• Kostentreiber: OSS-Datenzugriff, Integration mehrerer Hersteller, Simulationsgenauigkeit, Feldvalidierung.
• Kennzahlen: kWh je Standort oder je GB, % eingesparte Energie gegenüber Kontrollcluster, Erreichbarkeit, Haltbarkeit der Verbindungen, Perzentile von Durchsatz und Latenz, Kundenbeschwerden, Schlafstunden je Zelle, Rollback-Rate, CO2e (Scope 2).

Menschen & Veränderung

Beziehen Sie die Geschäftsführung für die Energie- und Kostenziele ein, die Leitung des Netzbetriebs (department-lead) als Prozessverantwortliche, IT und IT-Sicherheit für OSS-Zugriff und Notaus-Konzept sowie den Hersteller (suppliers) für unterstützte Schnittstellen. Recht und Compliance prüfen Pflichten aus den Vorschriften für kritische Infrastruktur (NIS2, Verfügbarkeit von Notrufen). RAN-Ingenieure sind die Hauptanwender: Beziehen Sie sie zuerst als Prüfer der empfohlenen Aktionen im reinen Empfehlungsmodus ein, später als Freigeber je Cluster.

Betriebsrat: kommt darauf an. Netzzähler sind keine Beschäftigtendaten, daher löst reine Verkehrsoptimierung meist keine Mitbestimmung aus. Sie greift, wenn das Werkzeug Freigaben oder Übersteuerungen der Ingenieure protokolliert und damit zur Verhaltensüberwachung geeignet ist (§ 87 Abs. 1 Nr. 6 BetrVG, BAG-Rechtsprechung), oder wenn sich Arbeitsabläufe wesentlich ändern: § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Information, und eine kurze Betriebsvereinbarung zur Protokollierung ist ratsam.

Datenschutz: Aggregierte Zelldaten sind normalerweise nicht personenbezogen; prüfen Sie, ob Nutzer- oder Standortdaten in die Pipeline gelangen, und beziehen Sie dann den/die Datenschutzbeauftragte(n) ein und führen Sie eine DSFA durch. KI-Kompetenz: Unterstützen Sie Ingenieure mit Schulungen zu Prognosegrenzen und Leitplanken (GUIDE-006, KI-Verordnung (AI Act) Art. 4). Pilotieren Sie auf einem ländlichen Cluster mit geringem Risiko und legen Sie Go-/No-go-Kennzahlen fest (GUIDE-009). Typische Sorge: „KI verschlechtert die Qualität oder vernichtet Arbeitsplätze.“ Begegnen Sie dem mit harten Leitplanken, Rollback und menschlicher Freigabe (GUIDE-011, GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Einstufung hängt vom Einzelfall ab. Mobilfunknetze sind kritische digitale Infrastruktur; Anhang III Nr. 2 (Hochrisiko) erfasst KI, die als Sicherheitskomponenten bei der Verwaltung und dem Betrieb kritischer digitaler Infrastruktur eingesetzt wird. Reine Energiesparoptimierung, die die Verfügbarkeit nicht wesentlich beeinträchtigen kann, hat typischerweise minimales Risiko; Regelung in geschlossener Schleife, die den Dienst stören kann, einschließlich Notrufen, sollte als potenziell hochriskant bewertet werden [1].
• NIS2 und Telekommunikationsrecht: Betreiber sind wesentliche Einrichtungen nach NIS2 und dem EECC (Pflichten zu Sicherheit und Resilienz); die 5G-Toolbox der EU und nationale Lieferketten-Vorgaben beeinflussen die Herstellerwahl.
• DSGVO: Zellzähler sind aggregiert und meist nicht personenbezogen; Daten auf Nutzer- oder Teilnehmerebene (Standort, IMSI-Spuren) sind personenbezogene Daten und ePrivacy-relevant, daher Aggregation und Pseudonymisierung nutzen und die Optimierung auf Zell-KPIs beschränken.
• Betriebsrisiken: Ausfall durch fehlerhafte Automatisierung, Herstellerabhängigkeit (Lock-in), Modelldrift. Gegenmaßnahmen: Leitplanken, gestufter Rollout, Rollback, Änderungsmanagement, Audit-Protokolle, Notrufschutz.

Erste Schritte

1. Energie je Standort und Cluster als Ausgangslage erfassen; prüfen, welche Energiesparfunktionen der Hersteller bereits lizenziert sind.
2. Einen sauberen PM-/CM-/Energie-Datensatz für einen Pilot-Cluster (städtisch plus ländlich) mit Kontrollcluster aufbauen.
3. Im reinen Empfehlungsmodus starten: Verkehr prognostizieren und vorgeschlagene Schlafphasen mit den Herstellerregeln vergleichen.
4. QoS-Leitplanken und Rollback-Auslöser mit dem Netzbetrieb festlegen, dann die geschlossene Regelschleife aktivieren.
5. Cluster für Cluster ausrollen und monatlich kWh und QoS berichten.

Quellen

1. Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. GSMA — Mobile Net Zero / energy efficiency — https://www.gsma.com/solutions-and-impact/connectivity-for-good/external-affairs/climate-action/
3. 3GPP — Self-Organizing Networks (SON) — https://www.3gpp.org/technologies/son
4. O-RAN Software Community (Linux Foundation) — https://o-ran-sc.org/
5. AI-RAN Alliance — https://ai-ran.org/
6. NVIDIA Sionna — https://nvlabs.github.io/sionna/
7. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj