Mobilfunkmast-Standortoptimierung

Das echte Ausmaß des Problems

Die deutsche Mobilfunkinfrastruktur befindet sich seit 2020 in einer Investitionswelle ohne Vergleich. Allein die drei großen Netzbetreiber — Deutsche Telekom, Vodafone und O2 Telefónica — haben im Zeitraum 2020–2025 zusammen über 15 Milliarden Euro in den 5G-Ausbau investiert. Deutsche Funkturm, die größte Infrastrukturgesellschaft mit rund 34.000 Standorten, wurde 2024 von DigitalBridge und Brookfield für 17,5 Milliarden Euro übernommen — mit einem Nachfolgeplan von 300 Millionen Dollar allein für Asset-Management-Software und Standortoptimierung.

Das Investitionsvolumen macht Fehlentscheidungen bei Standortwahl teuer: Ein falsch gesetzter Makromast kostet im Schnitt 150.000–400.000 Euro für Erschließung, Fundamentbau, Antenneninstallation und Backhaul — zuzüglich Mietverträge über typisch 15–20 Jahre. Wer zehn Standorte suboptimal setzt, verbrennt damit potenziell Millionen Euro an CapEx, die alternativ zehn besser platzierte Standorte finanzieren könnten.

Das klassische RF-Planungsverfahren hat zwei strukturelle Schwächen:

Veraltete Nachfragedaten. Netzausbauplanung basiert traditionell auf Verkehrsprognosen, die 2–3 Jahre zurückliegende KPIs extrapolieren. In dynamischen Gebieten — Stadtentwicklung, Gewerbegebiete, neue Großereignisse — ist dieser Horizont zu kurz.

Selbst gemeldete Versorgungsdaten. Die Bundesnetzagentur veröffentlicht im Breitbandatlas Versorgungsdaten auf Basis von Netzbetreiber-Eigenmeldungen im 100m×100m-Raster. Unabhängige Messungen von Opensignal zeigen systematisch, dass tatsächliche Nutzererfahrungen die gemeldeten Werte im Innenbereich um 15–30 % unterschreiten. Wer Lückenanalyse auf selbst gemeldeten Daten betreibt, findet die falschen Lücken.

Laut Opensignal-Bericht Deutschland November 2024 belegt Deutschland bei der mobilen Video-Experience im europäischen Vergleich den Platz hinter Dänemark, Schweden und den Niederlanden — trotz hoher Netzinvestitionsrate. Das Mess-Ergebnis deutet auf ein Optimierungsdefizit hin, nicht auf ein Investitionsdefizit.

Die Datenlage in Deutschland: Was öffentlich verfügbar ist

Bevor ein Modell gebaut wird, muss klar sein, was an Daten tatsächlich vorhanden ist. In Deutschland gibt es dafür eine ungewöhnlich gute öffentliche Basis — aber auch klare Lücken.

Öffentlich verfügbare Geodaten (kostenlos, CC BY 4.0):

• Bundesnetzagentur Breitbandatlas — Versorgungsdaten von über 380 Telekommunikationsunternehmen, 100m×100m-Raster, Aktualisierung halbjährlich. Enthält Mobilfunkversorgung aller vier Generationen (2G–5G), differenziert nach Innen- und Außenbereich. Direktdownload über das Gigabit-Grundbuch.
• SRTM/DGM-Geländemodell — Digitales Geländemodell Deutschland, Auflösung 1m–10m, über die Landesvermessungsämter kostenlos verfügbar. Grundlage jeder Ausbreitungsberechnung.
• OpenStreetMap + ALKIS — Gebäudegrundrisse, Straßennetz, Landnutzung. Für urbane Gebiete mit guter OSM-Abdeckung ausreichend für erste Modelle.
• Zensus 2022 — Bevölkerungsdaten auf 100m-Gitterebene, kostenlos über das Statistische Bundesamt. Differenzierter als bisher — mit Altersstruktur und Haushaltsgrößen.
• EMF-Standortdaten der Bundesnetzagentur — Alle genehmigten Sendestandorte inklusive Koordinaten, Frequenzbänder und Betreiberkennung. Öffentlich einsehbar.

Nicht öffentlich verfügbare Daten (interne Betreiberdaten):

• OSS-KPIs (Operations Support System) — Standort-bezogene Auslastung, durchschnittlicher Durchsatz, Handover-Raten, PRB-Belegung. Das sind die eigentlich entscheidenden Signale.
• Drive-Test-Daten und CQT-Messungen — Qualitätsmessungen aus Fahrzeugen und Indoor-Tests. Netzbetreiber akkumulieren diese über Jahre.
• CRM-/Churn-Daten — Wo kündigen Kunden wegen Netzqualität? Direkter Hinweis auf Versorgungsunzufriedenheit.

Die Erkenntnis: Ein Betreiber, der seine eigenen OSS-KPIs nicht in die Standortoptimierung einbindet, verpasst den wichtigsten Teil des Signals. Externe Daten allein reichen für ein produktionsreifes Modell nicht aus.

Passive Infrastruktur vs. aktive Netzplanung — warum der Unterschied entscheidend ist

Wer ein Optimierungsmodell für Mobilfunkmast-Standorte baut, muss zuerst eine organisatorische Frage klären: Wer entscheidet hier über was?

In Deutschland ist die Infrastruktur heute stark vertikalisiert. Passive Infrastruktur — das physische Mast, das Fundament, die Kabeldurchführung, die Zaunanlage — betreiben meist spezialisierte Tower Companies: Deutsche Funkturm (ca. 34.000 Standorte), Vantage Towers (Vodafone-Tochter, ca. 19.000 Standorte), American Tower Germany. Sie monetarisieren ihre Standorte durch Vermietung an einen oder mehrere Netzbetreiber (Tenancy Ratio). Für sie ist Standortoptimierung eine Frage der Nachfrage-Prognose: Wo werden in fünf Jahren MNOs bereit sein, Miete für einen Standort zu zahlen?

Aktive Netzplanung — welche Frequenzbänder, welche Antennenparameter, welche Kapazitätseinstellungen — liegt bei den Mobilfunkbetreibern selbst (MNOs). Für sie ist die Frage: Welche Standorte sollen mit welchen Technologien ausgerüstet werden, und welche neuen Standorte werden für das 5G-Ausbauversprechen gebraucht?

Ein ML-Modell für Standortoptimierung muss jeweils auf diesen unterschiedlichen Use Case zugeschnitten sein:

Diese Unterscheidung ist kein akademisches Detail. Ein Tool, das für MNO-Rollout gebaut wurde, gibt der Tower Company die falsche Antwort — und umgekehrt.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Zeitersparnis bei der Analyse ist real: O2 Telefónica berichtete im Januar 2025, dass ihr ML-gestütztes Netzplanungstool 250 Gigabyte Standortdaten in einem halben Tag verarbeitet — eine Analyse, die mit klassischen Werkzeugen Wochen dauern würde, mit über 90 Prozent Vorhersagegenauigkeit für Kapazitätsbedarf.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5)
RF-Planungsteams sparen erheblich: Was vorher Wochen dauerte, dauert Stunden. Aber die Zeitersparnis betrifft ein kleines Spezialistenteam, nicht die gesamte Organisation. Wer drei RF-Ingenieurinnen hat, die jetzt zwei Wochen statt vier Wochen für eine Planungsrunde brauchen, gewinnt Zeit, aber kein massives Arbeitsvolumen wie etwa bei der Kundensupport-Automatisierung.

Kosteneinsparung — mittel (3/5)
CapEx-Optimierung durch bessere Standortentscheidungen kann substanziell sein — ein verhindeter Fehlstandort à 200.000+ Euro lohnt sich schnell. Deutsche Funkturm investiert 300 Millionen Dollar in genau solche Optimierungssoftware, weil der Business Case evident ist. Das Problem ist die zeitliche Zuordnung: Die Einsparung entsteht über 5–10 Jahre Betrieb, nicht im ersten Quartal.

Schnelle Umsetzung — sehr niedrig (1/5)
Das ist die ehrlichste Zahl in diesem Profil. Kein anderer Anwendungsfall in diesem Branch ist schwerer zu starten. Es braucht OSS-Datenzugang, GIS-Integration, ML-Expertise und eine organisatorische Einigkeit über Entscheidungsprozesse — das alles in einem Umfeld, das traditionell auf zertifizierte RF-Planerinnen und -Planer setzt, die ihre Werkzeuge kennen. 6–18 Monate bis zum produktiven Betrieb sind realistisch. Vergleichbar mit der Backbone-Kapazitätsplanung und der 5G RAN-Optimierung.

ROI-Sicherheit — gering (2/5)
Der ROI entsteht aus vermiedenen Fehlinvestitionen — also aus dem, was nicht passiert. Das ist per Definition schwer zu messen. Wie beweist man, dass ein nicht gebauter suboptimaler Standort Geld gespart hat? Die Korrelation zwischen besserer Standortplanung und KPI-Verbesserungen (Throughput, Churn, Beschwerden) lässt sich ex-post herstellen, aber der kausale Nachweis ist aufwendig. Nur Predictive Maintenance hat in dieser Kategorie einen ähnlich indirekten ROI.

Skalierbarkeit — maximal (5/5)
Sobald das Modell läuft, ist die Grenzkosten-Logik überzeugend: Jeder neue Kandidatenstandort, jedes neue Gebiet, jede neue Frequenz kostet kaum mehr als das Vorherige. Das Modell lernt mit jedem Deployment-Ergebnis, wird besser, und der gleiche Aufwand deckt ein immer größeres Planungsgebiet ab. Tower Companies mit tausenden Standorten profitieren überproportional — das ist der eigentliche Skalierungshebel dieser Lösung.

Richtwerte — stark abhängig von vorhandenem OSS-Reifegrad, Datenqualität und Teamgröße des RF-Planungsbereichs.

Was das Optimierungsmodell konkret macht

Der technische Ansatz kombiniert klassische GIS-Analyse mit Machine Learning in einer mehrstufigen Pipeline:

Stufe 1 — Datenfusion. Das Modell aggregiert Datenquellen, die heute in separaten Silos liegen: OSS-KPIs pro Standort (Auslastung, Handovers, Durchsatz), Breitbandatlas-Rasterdaten, Zensus-Bevölkerungsdaten, DGM-Geländemodell, Gebäudedaten und — wenn verfügbar — Opensignal-Qualitätsmessungen für den Wettbewerbsvergleich. Die Zusammenführung dieser Quellen auf einer geografischen Ebene (typisch: Hexagon-Grid mit 250m–500m Kantenlänge) ist der aufwendigste Teil der gesamten Implementierung.

Stufe 2 — Nachfragemodellierung. Ein Gradient-Boosting-Modell oder ein räumliches Regressionsmodell lernt, wo Netzlast entsteht: tageszeit- und wochentagsabhängige Muster, saisonale Effekte, Wechselwirkungen mit demografischen Faktoren. Das ist kein statisches Bild, sondern eine Prognose: Wo wird Nachfrage in 12–36 Monaten sein?

Stufe 3 — Versorgungslückenanalyse. Das Modell berechnet für jede Gitterzelle das Verhältnis aus prognostizierter Nachfrage und vorhandener Versorgungskapazität. Zellen mit hohem Defizit werden als Kandidatengebiete markiert.

Stufe 4 — Standort-Suitability-Bewertung. Für jedes Kandidatengebiet bewertet das Modell potenzielle Standorte auf Basis von: Geländehöhe, Sichtbarkeit (Line-of-Sight), Entfernung zu Backhaul-Infrastruktur, Grundstücksverfügbarkeit, genehmigungsrechtlichen Restriktionen (Naturschutz, Denkmalschutz), Distanz zu bestehenden Standorten und prognostizierter Funkausbreitung. Das Ergebnis ist ein Ranking von Kandidatenstandorten, priorisiert nach erwartetem Abdeckungsgewinn je eingesetztem CapEx.

Was das Modell nicht macht: Es ersetzt keine RF-Ingenieurin und keinen RF-Ingenieur. Die Sektorkonfiguration, Antennenparameter, Frequenzzuweisung und finale Genehmigungsverfahren bleiben klassische Ingenieursarbeit. Das Modell beantwortet die Frage „Wo und wann?” — die Frage „Wie?” bleibt beim Team.

Konkrete Werkzeuge — was wann passt

Atoll (Forsk) — das RF-Planungswerkzeug der Wahl
Nahezu alle großen Netzbetreiber in Europa setzen Atoll als primäres RF-Planungswerkzeug ein. Es berechnet Ausbreitung, Abdeckung und Kapazität für alle Mobilfunkgenerationen. Für ML-basierte Standortoptimierung ist Atoll der Ausgangspunkt: Es liefert Planungsszenarien, die dann durch ML-Modelle priorisiert und optimiert werden. Ohne Atoll (oder ein vergleichbares RF-Tool wie Planet von Infovista) fehlt die Ausbreitungssimulation als Grundlage für den Modell-Output. Preis: auf Anfrage, fünfstellig pro Arbeitsplatz/Jahr.

Cellular Expert — RF-Planung direkt im GIS
Cellular Expert läuft als Erweiterung in Esri ArcGIS Enterprise und kombiniert GIS-Analyse mit RF-Propagationsberechnung. Besonders geeignet für Betreiber, die bereits ein Esri-Ökosystem betreiben und Standortentscheidungen im GIS-Kontext visualisieren und dokumentieren wollen. Die KI-gestützte Standortempfehlung erfordert Integration mit externen ML-Modellen. Preis: ab ca. 5.000–12.000 USD/Jahr für Einzelplatzlizenz.

Opensignal — unabhängige Qualitätsdaten als Benchmark
Für den Wettbewerbs- und Qualitätsvergleich ist Opensignal wertvoll: crowdgesourcte Messungen aus über 100 Millionen Smartphones, differenziert nach Straße und Stadtteil, zeigen, wo tatsächliche Nutzerwahrnehmung von der eigenen Versorgungsrechnung abweicht. Netzbetreiber-Lizenzen typisch im fünf- bis sechsstelligen Bereich pro Jahr. Einsatz sinnvoll, wenn die eigene Versorgungsplanung mit unabhängigen Nutzermessungen validiert werden soll.

Databricks oder Azure Machine Learning — ML-Pipeline
Für die eigentliche Modellentwicklung braucht es eine skalierbare Datenplattform. Databricks bietet Spark-basierte Verarbeitung für große Standortdaten-Mengen, Delta Lake für Datenversionierung und integrierte ML-Workflows. Azure Machine Learning ist die Alternative für Betreiber im Microsoft-Ökosystem. Beide sind EU-gehostet. Typische Betriebskosten: 2.000–8.000 EUR/Monat für einen mittelgroßen Betreiber.

AWS SageMaker — wenn der Betreiber AWS nutzt
Für Betreiber, die bereits auf AWS-Infrastruktur setzen, bietet AWS SageMaker eine vollständige ML-Pipeline von Datenaufbereitung bis Modelldeploy. EU-Hosting in Frankfurt. Pay-as-you-go nach Rechenzeit, typisch 1.000–4.000 EUR/Monat für periodische Planungsläufe.

Zusammenfassung: Wann welcher Ansatz

• RF-Ausbreitung + Planung → Atoll
• RF-Planung im Esri-Ökosystem → Cellular Expert
• Unabhängige Netzqualitätsdaten → Opensignal
• ML-Pipeline bei Microsoft-Infrastruktur → Azure Machine Learning
• ML-Pipeline bei AWS → AWS SageMaker
• Spark-basierte Verarbeitung großer Standortmengen → Databricks

Datenschutz und Datenhaltung

Mobilfunk-Standortplanung verarbeitet auf den ersten Blick keine personenbezogenen Daten — es geht um Masten, Frequenzen, Geländemodelle. In der Praxis ist das differenzierter.

OSS-KPI-Daten: Standortbezogene Auslastungsdaten können bei ausreichend feiner Granularität indirekt auf Bewegungsprofile einzelner Personen hinweisen. Bei Datenaggregation auf Zellebene und zeitlichen Durchschnittswerten ist das DSGVO-Risiko gering — bei hochaufgelösten Zeitreihendaten auf Einzelkunden-Ebene dagegen relevant. Wer CRM-Daten (Churn, Beschwerden) mit Standortdaten verknüpft, um abgewanderte Kunden nach geografischen Versorgungsdefiziten zu analysieren, ist unbedingt im DSGVO-Scope und braucht eine klare Rechtsgrundlage.

Wettbewerber-Messdaten: Opensignal-Daten sind aggregiert und pseudonymisiert — kein DSGVO-Problem für den Nutzer der Analytics-Plattform.

Infrastrukturdaten (Atoll, Cellular Expert): Betreiben Betreiber ihre Planungssoftware on-premise oder auf EU-gehosteter Cloud, liegen ihre Netzplandaten im eigenen Kontrollbereich. Der EU AI Act klassifiziert KI-gestützte Standortoptimierung für kritische Infrastruktur derzeit als hochriskant gemäß Artikel 6 — das bedeutet: Dokumentationspflichten, menschliche Aufsicht über automatisierte Empfehlungen und Konformitätsbewertung vor Inbetriebnahme. Diese Anforderungen sind für Mobilfunk-Netzbetreiber als Betreiber kritischer Infrastruktur (KRITIS) besonders relevant.

Empfehlung für die Datenhaltung: OSS-KPIs und interne Netzplandaten sollten nicht an US-Cloud-Dienste ohne EU-Datentransfersicherung übergeben werden. Azure Machine Learning mit EU-Datenresidenz (West Europe / Germany North) oder Databricks auf europäischer Cloud-Infrastruktur sind die naheliegenden Optionen.

Was es kostet — realistisch gerechnet

Infrastruktur- und Toolkosten

• Atoll (Forsk): 30.000–80.000 EUR/Jahr je nach Anzahl Arbeitsplätze und Modulen
• Cellular Expert: 5.000–12.000 USD/Jahr Einzelplatzlizenz; Enterprise-Anbindung an ArcGIS Enterprise auf Anfrage
• Opensignal Analytics-Lizenz: typisch 50.000–150.000 EUR/Jahr für Netzbetreiber-Zugang
• ML-Plattform (Databricks / Azure ML): 2.000–8.000 EUR/Monat für laufenden Betrieb
• Implementierungsprojekt (Datenfusion, Modellentwicklung, GIS-Integration): 200.000–600.000 EUR einmalig, je nach Datenqualität und Scope

Wer das trägt: Das Investitionsvolumen dieser Lösung passt zu Betreibern, die pro Jahr im dreistelligen Millionenbereich Netzausbau-CapEx planen. Bei 100 Millionen Euro CapEx/Jahr und einer hypothetischen Optimierung von nur 5 % — weniger Fehlstandorte, kürzere Planungszyklen, bessere Priorisierung — wäre der Break-even eines 500.000-Euro-Projekts in einem einzigen Planungszyklus erreichbar. Deutsche Funkturm hat diese Rechnung 2024 mit einem $300-Millionen-Investitionsplan in Asset-Management-Software öffentlich vollzogen.

Was du tatsächlich messen kannst:

• Anzahl Kandidatenstandorte, die nach ML-Analyse abgelehnt und nicht gebaut wurden (CapEx-Vermeidung)
• Auslastungsverbesserung in Gebieten, wo neue Standorte nach Modellempfehlung platziert wurden (KPI-Delta 6–12 Monate nach Deployment)
• Planungsgeschwindigkeit: Wochen zu Stunden je Analysezyklus

Drei typische Einstiegsfehler

1. Mit dem öffentlichen Breitbandatlas als einziger Datenquelle starten.
Die Verlockung ist verständlich: Der Breitbandatlas ist kostenlos, flächendeckend und im richtigen Format. Aber er basiert auf Netzbetreiber-Eigenmeldungen und gibt Indoor-Szenarien systematisch zu optimistisch wieder. Ein Modell, das auf dieser Basis Versorgungslücken findet, findet die Lücken, die Betreiber selbst für relevant halten — nicht die, wo Kunden tatsächlich unversorgt sind. Lösung: Von Anfang an eigene Drive-Test-Daten und OSS-KPIs integrieren. Ohne interne Daten kein Modell, das intern Vertrauen verdient.

2. Das Modell ohne RF-Ingenieure bauen.
ML-Experten, die keine RF-Planung kennen, bauen Modelle, die statistisch korrekte, physikalisch aber unsinnige Empfehlungen geben. Ein Kandidatenstandort, der aus demographischer Sicht perfekt ist, aber durch einen Gebirgsrücken von allen Nutzern getrennt ist, landet trotzdem auf der Empfehlungsliste — wenn das Modell Ausbreitungsphysik nicht kennt. Die Integration von RF-Expertise ist keine Option, sondern eine Voraussetzung. Und umgekehrt: RF-Ingenieurinnen und -Ingenieure ohne ML-Kenntnisse können Modellausgaben nicht sinnvoll interpretieren oder hinterfragen. Das erfordert interdisziplinäre Teamkonstellation von Projektbeginn an.

3. Genehmigungsprozesse als nachgelagerten Schritt behandeln.
Das Modell empfiehlt Standorte A, B, C als optimal. Das Team investiert sechs Monate in die technische Vorbereitung. Dann zeigt sich: Standort A liegt in einem Naturschutzgebiet, B ist denkmalgeschützt, C gehört einer Grundstücksbesitzerin, die kategorisch ablehnt. Genehmigungsrestriktionen — Naturschutz, Denkmalschutz, EMF-Auflagen, kommunale Bebauungspläne — müssen bereits als Constraints ins Modell eingebaut sein. Die Bundesnetzagentur und die Landesbehörden liefern dafür zum Teil maschinenlesbare Daten. Was nicht verfügbar ist, muss manuell vorab recherchiert werden. Optimierung ohne Genehmigungsrealität ist Optimierung ins Leere.

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

Die Organisation eines Netzbetreibers ist darauf eingerichtet, dass RF-Planerinnen und -Planer Entscheidungen treffen. Sie haben Zertifizierungen, sie kennen Atoll, sie wissen, wie man eine Coverage-Map liest. Wenn ein ML-Modell jetzt Standortempfehlungen liefert, entsteht eine Frage, die technisch klingt, aber kulturell ist: Wessen Einschätzung gilt?

Erfahrungsgemäß gibt es zwei Widerstands-Muster:

Die „Trust but verify”-Gruppe. RF-Ingenieurinnen und -Ingenieure, die das Modell akzeptieren, aber jede Empfehlung manuell nachrechnen. Das ist kein Problem — es ist der richtige Umgang mit einem neuen Werkzeug. Das Problem ist, wenn dieser Schritt zum Standard wird und die Zeitersparnis vollständig aufgezehrt wird durch doppelte Arbeit. Lösung: klare Protokolle, welche Empfehlungen nochmals geprüft werden (Neu-Standorte ja, Upgrade-Priorisierungen nein), und eine transparente Fehlerstatistik, die das Vertrauen schrittweise aufbaut.

Die strategische Ablenkung. Manche Entscheidungen in der Netzplanung sind nicht rein technisch — sie werden durch Lieferantenverträge, historische Vereinbarungen mit Kommunen oder Konzernstrategien beeinflusst. Ein Modell, das unbequeme Empfehlungen macht (z.B. „dieser Standort sollte nicht ausgebaut werden, weil Kunden abwandern”), kann politisch unangenehm sein. Das Modell wird dann nicht abgelehnt, sondern ignoriert oder selektiv zitiert. Vorbeugung: von Beginn an mit Entscheiderteams klären, welche Fragestellungen das Modell beantworten darf — und welche nicht in seinen Scope fallen.

Was in den ersten 12 Monaten realistisch erreichbar ist: schnellere Priorisierung von Upgrade-Investitionen, bessere Begründbarkeit von Standortentscheidungen nach außen (gegenüber Behörden, Kommunen), und die Grundlage für ein kontinuierlich lernfähiges Planungssystem.

Was nicht realistisch ist: dass das Modell nach 12 Monaten autonom Standortentscheidungen trifft. Das ist kein Ziel — es ist eine Falle.

Realistischer Zeitplan mit Risikohinweisen

Wichtiger Hinweis: Der häufigste Abbruchpunkt ist nicht die Technik, sondern der Übergang von Pilotvalidierung zu produktivem Betrieb. Wenn RF-Team und Projektteam sich auf keine gemeinsame Metrik einigen können, die den Modellerfolg misst, bleibt das Projekt dauerhaft im Pilotmodus.

Häufige Einwände — und was dahintersteckt

„Wir machen das schon mit Atoll — was bringt ML on top?”
Atoll löst das Ausbreitungsproblem hervorragend. Es beantwortet nicht die Frage, wo in zwei Jahren Nachfrage entstehen wird — oder warum Kunden in Gebiet X abwandern. ML ergänzt Atoll, ersetzt es nicht. Der kombinierte Einsatz — Atoll für Ausbreitung, ML für Nachfragemuster — ist der richtige Ansatz. Wer von ML-only spricht, hat das Werkzeugset nicht verstanden.

„Die Daten, die wir haben, sind zu uneinheitlich.”
Das ist real — und kein Ausschlussgrund, sondern ein Planungsparameter. Fast jedes OSS-System hat Datenlücken, historische Brüche und Formatinkonsistenzen. Der Datenaudit in Monat 1–2 quantifiziert diese Probleme, bevor Geld ausgegeben wird. Viele Modelle liefern gute Ergebnisse mit 70 % der theoretisch verfügbaren Daten — wenn die 30 % Lücken dokumentiert sind und das Team weiß, welche Regionen oder Zeiträume das Modell weniger sicher macht.

„Das können wir nicht intern — wir brauchen Ericsson oder Nokia dafür.”
Die großen Netzausrüster haben eigene Planungs- und Optimierungsplattformen. Für Betreiber, die ausschließlich auf einem Vendor-Ökosystem fahren (Ericsson OSS oder Nokia NetAct), kann der Vendor-eigene ML-Layer ein schnellerer Weg sein als ein unabhängiges Modell. Der Preis dafür ist Lock-in: Das Modell sieht nur, was der Vendor zeigt. Unabhängige Modelle auf neutralen Daten haben dafür mehr Spielraum für Wettbewerbsdatenintegration und multi-vendor Szenarien.

Woran du merkst, dass das zu dir passt

• Du planst mehr als 50 neue Standorte pro Jahr und die RF-Team-Kapazität ist der Engpass
• Du hast operative Daten aus dem OSS über mindestens 2–3 Jahre, die strukturiert und zugänglich sind
• Du betreibst ein Netz mit mehr als 500 aktiven Standorten — darunter fehlt schlicht die Trainingsdatenbasis für ein valides ML-Modell
• Deine aktuellen Standortentscheidungen werden regelmäßig durch Kapazitätsprobleme in scheinbar gut versorgten Gebieten widerlegt — ein Signal dafür, dass Nachfragemuster mit klassischer Methodik nicht mehr ausreichend erfasst werden
• Du hast einen RF-Planungsbereich, der mit den Analyseergebnissen arbeiten will und ML als Unterstützung, nicht als Bedrohung sieht

Wann diese Lösung (noch) nicht passt — drei harte Ausschlusskriterien:

1. MVNOs und Betreiber ohne eigenes Spektrum. Du entscheidest nicht, wo Infrastruktur gebaut wird — das tut der Host-MNO. Standortoptimierung ist kein Hebel, den du in der Hand hast. Diese Lösung ist ausschließlich für Betreiber mit eigenen Frequenzlizenzen und eigenem Netzausbaubudget relevant.

2. Weniger als 500 aktive Standorte oder kein strukturierter OSS-KPI-Export. Unterhalb dieser Schwelle ist das Trainingsdaten-Problem nicht lösbar: Das Modell lernt zu wenig über Nachfragemuster, und die Ergebnisse sind nicht signifikant besser als erfahrungsbasierte RF-Ingenieurarbeit. Wer kein strukturiertes OSS-System hat, das KPIs je Standort exportiert, hat keine Datenbasis für ML — klassische RF-Planung mit Atoll ist dann der richtige Ansatz.

3. Kein interdisziplinäres Team aus RF-Expertise und ML-Kompetenz. Diese Lösung braucht beide — nicht alternativ, sondern parallel. Ein ML-Team ohne RF-Hintergrund baut Modelle, die physikalisch sinnlose Empfehlungen geben. Ein RF-Team ohne ML-Kompetenz kann Modellausgaben nicht interpretieren oder validieren. Wer keines der beiden intern hat und beides auslagern will, verliert Kontrolle über das Modell und seine Interpretierbarkeit.

Das kannst du heute noch tun

Der sinnvolle erste Schritt für einen Netzbetreiber, der diese Lösung ernsthaft prüft, ist kein Softwareauftrag — es ist ein interner Datenaudit.

Formuliere intern drei Fragen:

1. Welche OSS-Datenquellen haben wir, in welchem Format liegen sie vor, und wer hat Zugang?
2. Welche unserer letzten 20 Standortentscheidungen haben sich im Rückblick als suboptimal herausgestellt — und warum?
3. Welche Gebiete im Netz zeigen heute Kapazitäts- oder Qualitätsprobleme, die wir nicht mit dem aktuellen Planungsprozess antizipiert hatten?

Diese drei Fragen lassen sich mit einem KI-Assistenten vorstrukturieren. Hier ist ein Prompt dafür:

Quellen & Methodik

• O2 Telefónica KI-Netzplanung (Jan 2025): Pressemitteilung telefonica.de, „KI-gestützte Netzplanung: O2 Telefónica verbessert Prognose mobiler Datennutzung”, Januar 2025. Enthält: 28.000 Standorte, 250 GB Tagesdaten, über 90 % Vorhersagegenauigkeit, Plattform Google Cloud.
• Deutsche Funkturm Übernahme und Investitionsplan (2024): Dgtl Infra, „Deutsche Funkturm: Germany’s 32.8k Towers Crown Jewel”, 2024. Enthält: 34.000 Standorte, 17,5 Mrd. EUR Unternehmenswert, $300 Mio. Investitionsplan Asset-Management, opex-Reduzierung 8–12 % durch KI, Tenancy-Ziel 1.8x bis 2027.
• Bundesnetzagentur Breitbandatlas (2024–2025): gigabitgrundbuch.bund.de/GIGA/DE/Breitbandatlas. Pressemitteilung 24. Juni 2024 und 5. Dezember 2024. Datenstand Mobilfunk: Juli 2025. Lizenz: CC BY 4.0.
• Opensignal Germany Report November 2024: insights.opensignal.com/de/reports/2024/11/germany. Mobile-Experience-Vergleich Europa, systematische Abweichungen zwischen gemeldeter und gemessener Versorgung.
• 5G-Genehmigungsverfahren Deutschland: deutschland-spricht-ueber-5g.de, „Welchen Einfluss die Kommune beim Mobilfunkausbau hat”. 5g-anbieter.info, „5G Ausbau — aktuelle Stand, Pläne & Hürden”: bis zu 14 Monate für Baugenehmigung neuer Masten.
• Cellular Expert Preise und Spezifikation: cellular-expert.com, verifiziert April 2026. Ab ca. 5.000–12.000 USD/Jahr Einzelplatzlizenz.
• EU AI Act, Artikel 6 (Hochrisiko-KI): Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates, in Kraft getreten August 2024. Anwendbar auf KI-Systeme für kritische Infrastruktur.

Du willst wissen, ob eure OSS-Datenbasis für ein erstes Modell ausreicht, oder welche Implementierungspartner für euren Technologie-Stack infrage kommen? Meld dich — das lässt sich in einem kurzen Gespräch klären.