Core-RAN-Blueprint 2026: Von 5G-Abdeckung zu monetarisierbaren Netzdiensten 

Die Core-RAN-Strategie gewinnt zunehmend an Bedeutung, da der Wert von 5G heute davon abhängt, wie gut 5G Core und RAN zusammenarbeiten.

Der 5G Core ist der Ort, an dem der Betreiber die Serviceregeln des Netzes definiert. Er legt fest, welche Nutzer, Geräte oder Anwendungen welches Qualitätsniveau erhalten, welche Datensession sie nutzen, über welche UPF der Traffic geführt wird, auf welche Slices sie zugreifen dürfen und wie die Nutzung abgerechnet wird.

Diese Regeln ermöglichen konkrete Servicezusagen wie niedrige Latenz für industrielle Anwendungen, garantierte Qualität für Enterprise-Traffic, priorisierten Zugriff für kritische Nutzer sowie dedizierte Slices (dedizierte logische Service-Lanes innerhalb desselben gemeinsam genutzten 5G-Netzes) für Fertigungseinheiten, Gesundheitswesen oder Campusnetze.

Diese Zusagen werden jedoch nur dann Realität, wenn das RAN die erforderliche Abdeckung, Kapazität, Latenz und Funkqualität im Feld tatsächlich liefern kann. Deshalb ist ein Slice, ein Quality-on-Demand-Angebot oder eine Premium-Enterprise-Verbindung kein reines Core-Produkt. Es ist ein Core-RAN-Service.

Der Markt entwickelt sich genau in diese Richtung. Laut dem Ericsson Mobility Report gibt es inzwischen 65 kommerzielle Service-Provider-Angebote auf Basis von 5G-SA-Network-Slicing, und die weltweiten 5G-Abonnements sollen bis 2031 auf 6,4 Milliarden steigen (Ericsson Mobility Report, 2025). Der Bericht unterstreicht zugleich die wachsende Bedeutung von 5G Standalone und differenzierter Konnektivität. Das bedeutet: Betreiber bewegen sich von reiner 5G-Abdeckung hin zu paketierten 5G-Services mit konkreten Performanceversprechen.

Ein Core-RAN-Blueprint ist das Entscheidungsmodell für diesen Wandel. Er zeigt, wie Core-Policy, RAN-Performance und Service Assurance zusammenwirken müssen.

Warum Core-RAN einen gemeinsamen Blueprint braucht

In vielen Betreiberorganisationen werden Core und RAN weiterhin über getrennte Modernisierungspfade geplant. Dadurch entsteht eine Lücke, die erst sichtbar wird, nachdem beide Domänen ihre jeweiligen Aufgaben korrekt erfüllt haben.

Der Core kann die richtige S-NSSAI (Single Network Slice Selection Assistance Information: Identifikator eines Network Slices) auswählen, den passenden QoS-Flow zuweisen (Quality of Service Flow: Verkehrsklasse für Latenz, Priorität, Zuverlässigkeit oder Durchsatz), die Session an die richtige UPF (User Plane Function: Funktion für Traffic-Forwarding und Breakout) binden und die passende Policy anwenden.

Dennoch kann der Service scheitern, wenn das RAN nicht genügend Funkkapazität bereitstellt, Zellen überlastet sind, die PRB-Zuteilung (Physical Resource Block Allocation: Zuweisung von Funkressourcen) eingeschränkt ist, Handover instabil sind oder Uplink- und Latenzwerte unter Last schwanken.

Umgekehrt gilt: Auch ein optimiertes RAN allein reicht nicht aus, wenn der Core keine Policy-, Charging- und Slicing-Funktionen bereitstellt.

Genau deshalb braucht Core-RAN einen gemeinsamen Blueprint: Er schließt die Lücke zwischen Service-Intent im Core und Service-Erlebnis im Funknetz.

Der Blueprint sollte drei Fragen beantworten:

1) Welchen Service soll der Core ermöglichen?

2) Kann das RAN diese Zusagen unter realen Bedingungen erfüllen?

3) Kann der Betreiber nachweisen, dass der Service funktioniert hat?

Der Blueprint sorgt dafür, dass Core- und RAN-Entscheidungen auf konkrete Serviceergebnisse rückführbar werden.

Was sich 2026 in Core-RAN verändert

1. 5G SA verschiebt den Fokus von Abdeckung zu Services

Betreiber wechseln von der Frage „Wo haben wir 5G-Abdeckung?“ hin zu „Welchen konkreten Service können wir auf diesem 5G-Netz garantieren?“.

Hier wird 5G SA (5G Standalone: 5G-Netzarchitektur mit eigenem 5G Core ohne Abhängigkeit von 4G-Core-Infrastruktur) entscheidend. Es ermöglicht ein stärker serviceorientiertes Netzverhalten.

Es kann Network Slicing unterstützen (eine dedizierte logische Service-Lane auf gemeinsam genutzter 5G-Infrastruktur), Quality on Demand (QoD: ein Dienst, bei dem eine Anwendung für eine bestimmte Session oder Zeitspanne ein höheres Netzqualitätsniveau anfordert) sowie Enterprise Connectivity, wenn Kunden für Standorte oder Use Cases planbare Performance benötigen.

Unterschiedliche Kunden benötigen unterschiedliches Netzverhalten: Ein Broadcaster benötigt stärkere Uplink-Performance, eine Fabrik stabile Latenz für Maschinen, ein Public-Safety-Nutzer priorisierten Zugriff bei Netzüberlastung, während ein normaler Consumer-Video-Nutzer meist nur Standard-Mobilfunk benötigt.

Diese Use Cases werden in messbare Netzanforderungen übersetzt – etwa Latenz, Jitter, Durchsatz, Uplink-Geschwindigkeit, Verfügbarkeit, Mobilitätsperformance und Priorität in Spitzenzeiten. Anschließend werden daraus verkaufbare Servicepakete entwickelt.

2. Der Core wird schneller cloud-native als das RAN

Aus architektonischer Sicht bewegt sich der Core schneller in Richtung cloud-native Deployments. Der 5G Core wird zunehmend softwaregetrieben und cloud-nativ.

Ein cloud-nativer Core bedeutet, dass Core-Netzfunktionen als Softwarekomponenten auf Cloud-Infrastruktur betrieben werden. Diese Funktionen lassen sich flexibler deployen, updaten, skalieren und zurückrollen als klassische appliance-basierte Systeme.

Im Jahr 2026 hat MasOrange Ericsson für ein sechsjähriges Programm zur Vereinheitlichung und Absicherung der 5G-Netzarchitektur ausgewählt. Die Vereinbarung umfasst die Integration des 5G Standalone Core unter einem europäischen Single-Vendor-Ansatz sowie die Konsolidierung von IMS-Voice-Plattformen. Damit wird eine fragmentierte Post-Merger-Landschaft ersetzt, in der die Cores von Orange und MásMóvil noch parallel betrieben wurden.

Der Schritt wird nicht nur als technologische Vereinfachung verstanden, sondern auch als Grundlage für 5G-Monetarisierung: Der einheitliche 5G-SA-Core soll Advanced Services wie Network APIs, Slicing und Multislicing, industrielle Konnektivität und Low-Latency-Use-Cases unterstützen. Das Deployment umfasst zudem cloud-natives Subscriber Data Management, Charging- und Billing-Funktionen, Analytics und Automatisierung, um die Time-to-Market neuer Angebote zu verkürzen (Cinco Días, 2026).

Ebenfalls 2026 erweiterten BT Group und Ericsson die 5G-SA-Fähigkeiten von BT durch die Integration der Network Slice Selection Function und der Network Exposure Function in den 5G Core. Ziel ist der Übergang zu dynamischem Network Slicing und sicheren Network APIs, um planbare, sichere und applikationsbewusste Konnektivität für Enterprise Use Cases zu ermöglichen (TechRadar Pro, 2026).

3. Das RAN wird programmierbar

Open RAN (Open Radio Access Network) trennt Teile der RAN-Architektur und führt offene Schnittstellen ein. Dadurch erhalten Betreiber mehr Flexibilität bei der Wahl von Lieferanten und beim Aufbau des RAN-Stacks.

Die O-RAN Alliance beschreibt ihre Mission als Neugestaltung der RAN-Industrie hin zu intelligenteren, offeneren, virtualisierten und interoperablen Mobilfunknetzen.

Die zentrale Veränderung ist die Programmierbarkeit.

Ein RIC (RAN Intelligent Controller) ermöglicht softwarebasierte Steuerung im RAN:

– Near-RT RIC (Near-Real-Time RAN Intelligent Controller) für Steuerung nahe Echtzeit

– Non-RT RIC (Non-Real-Time RAN Intelligent Controller) für Policy-, Optimierungs- und Lernfunktionen

xApps laufen auf dem Near-RT RIC, rApps auf dem Non-RT RIC.

Programmables RAN schafft jedoch auch Governance-Risiken: Eine xApp kann Durchsatz maximieren wollen, eine andere Energieverbrauch reduzieren, eine weitere Servicequalität priorisieren. Diese Ziele können miteinander in Konflikt geraten.

Forschung zur Konfliktminderung in O-RAN zeigt, dass widersprüchliche xApp-Entscheidungen ein reales Architekturproblem darstellen. Vorgeschlagen werden Mechanismen zur Konflikterkennung und -lösung innerhalb des Near-RT RIC.

Wie Core-RAN-Lösungen heute umgesetzt werden

Die Branche realisiert Core-RAN-Blueprints heute über drei zentrale Workstreams, die direkt mit der Marktentwicklung verbunden sind: autonome Betriebsmodelle, cloud-native Umsetzung und monetarisierbare 5G-Services.

1. Autonomous: von manuellen Netzoperationen zu kontrollierter Core-RAN-Automatisierung

Autonomie wird essenziell, um moderne Core-RAN-Netze im großen Maßstab zu betreiben. Betreiber reduzieren manuelle Operationen durch Automatisierung wiederkehrender Aufgaben, geben dem Netz jedoch keine uneingeschränkte Kontrolle.

Mit „uneingeschränkter Kontrolle“ ist ein Netz gemeint, das Policies ändern, Funkverhalten anpassen, Konfigurationen verändern, Traffic priorisieren, Energiesparmaßnahmen aktivieren oder Servicebehandlungen anpassen kann – ohne menschliche Freigaben, Sicherheitsgrenzen oder Rollback-Mechanismen.

Der aktuelle Ansatz ist daher kontrollierte Autonomie. Automatisierung wird zunächst auf konkrete Probleme angewendet. Der Betreiber definiert, was erkannt, empfohlen, automatisch geändert werden darf und wo menschliche Freigaben erforderlich sind.

Das ist entscheidend, da Core-RAN-Automatisierung ohne Governance Risiken erzeugen kann: Eine RAN-Optimierungsanwendung kann Energie sparen wollen, einen anderen Durchsatz sichern, eine Core-Policy Enterprise-Traffic priorisieren. Ohne Regeln entstehen Konflikte.

Die Lösung ist eine Automation-Governance-Schicht, die festlegt, welche Aktionen freigegeben werden müssen, welche closed-loop laufen dürfen, welche KPIs geschützt sind und wie Rollbacks erfolgen.

2. Cloud-native: von Plattformmigration zu disziplinierten Day-2-Operations

Betreiber verlagern den 5G Core auf cloud-native Plattformen, da softwarebasierte Funktionen flexibler sind als appliance-basierte Systeme.

Die Branche hat jedoch gelernt: Ein cloud-nativer Core hat keinen Wert per se. Sein Wert entsteht erst im stabilen Betrieb nach dem Rollout.

Deshalb gewinnen Day-2-Operations an Bedeutung: Upgrades, Rollbacks, Observability, Konfigurationskontrolle, Drift Detection, Service Assurance und Lifecycle Management.

Diese Disziplin ist auch im RAN erforderlich. Die meisten Betreiber werden nicht ein einheitliches RAN-Modell einführen, sondern über Jahre hinweg Purpose-Built RAN, Cloud RAN und Open RAN parallel betreiben. Dadurch wird operative Disziplin wichtiger, nicht weniger.

Die Lösung besteht darin, klare Betriebsregeln vor der Skalierung zu definieren: Welche Core-Funktionen zuerst migrieren, welche RAN-Zonen cloudifiziert werden, wie Änderungen getestet und rückgängig gemacht werden und wie Core- und RAN-Performance gemeinsam überwacht wird.

So wird Cloud-Native von einer Plattformentscheidung zu einem Core-RAN-Betriebsmodell.

3. Monetarisierbar: von Netzfähigkeit zu verkaufbaren 5G-Services

Monetarisierung ist der Punkt, an dem der Core-RAN-Blueprint zum Business Case wird.

Betreiber gehen über die Vorstellung hinaus, dass 5G-Wert allein aus Abdeckung oder Bandbreite entsteht. Der nächste Schritt ist die Verpackung von Netzwerkverhalten in Services, die Kunden verstehen, kaufen und messen können.

Kunden kaufen keine Slice-IDs, QoS-Profile oder Policy-Regeln. Sie kaufen Ergebnisse: stabile Latenz, priorisierte Konnektivität oder garantierte Performance für konkrete Anwendungen.

Der Core-RAN-Blueprint muss daher zeigen:

– wie der Service geliefert wird

– wie er nachgewiesen wird

– und wie er abgerechnet bzw. berichtet wird

Was Betreiber als Nächstes tun sollten

Der nächste Schritt ist nicht der Start eines umfassenden Transformationsprogramms. Stattdessen sollten Betreiber mit einem fokussierten Blueprint und einem klar messbaren Use Case beginnen.

Die erste Priorität ist die Auswahl eines Services, der Core und RAN gemeinsam erfordert – etwa Network Slicing für Enterprise-Kunden, Quality-on-Demand für eine Anwendung oder ein Private-5G-Setup für einen Standort.

Die zweite Priorität ist die Definition der technischen End-to-End-Kette: Core-Policy, RAN-Verhalten, Assurance-Daten, operative Verantwortlichkeiten sowie Charging- und Reporting-Logik. So wird verhindert, dass einzelne Domänen isoliert optimieren, der Service aber nicht nachweisbar ist.

Die dritte Priorität ist Skalierung erst dann, wenn das Betriebsmodell funktioniert. Der Betreiber muss nachweisen können, dass der Service bereitgestellt, überwacht, angepasst, zurückgerollt und verständlich erklärt werden kann.

Damit erhält Core-RAN-Modernisierung einen pragmatischen Pfad: mit einem Service starten, Zusammenarbeit von Core und RAN nachweisen, Betriebsregeln etablieren und dann skalieren.

Abschließende Einordnung

Die klarste Erkenntnis der letzten fünf Jahre aus Standardisierung, Vendor-Roadmaps, OSS-Entwicklung und angewandter Forschung ist, dass der Core-RAN-Blueprint zu einem wiederholbaren Architekturmodell für die nächste Phase der Telekommunikation geworden ist.

Seine Bedeutung liegt nicht in der Modernisierung einzelner Domänen, sondern in ihrer Verbindung zu einem programmierbaren Service-Fabric, in dem Core, RAN, Edge, Orchestrierung, Analytics, Exposure und Monetarisierung zusammenwirken.

Die Lehre für Betreiber ist eindeutig: Core und RAN dürfen nicht isoliert modernisiert werden. Ein cloud-nativer 5G Core schafft Flexibilität, kann jedoch ohne programmierbares RAN keine differenzierten Serviceerlebnisse liefern. Ein modernisiertes oder offenes RAN erhöht die Agilität, kann aber ohne Core-Policy, Slicing, Exposure, Charging und Assurance keinen skalierbaren Umsatzmotor bilden.

Der Core-RAN-Blueprint bildet damit die Brücke zwischen 5G-Infrastruktur und echter Wertschöpfung im Telekommunikationsgeschäft. Er übersetzt technische Fähigkeiten wie O-RAN-RIC-Regelkreise, NWDAF-Analytics und slice-aware Policies in kundenseitige Ergebnisse: garantierte Qualität, sichere Enterprise-Konnektivität und API-basierte digitale Services.

Der Core-RAN-Blueprint ist damit nicht nur eine Netzwerkarchitektur, sondern die Brücke zwischen 5G-Infrastruktur und Wachstum im Telekommunikationsmarkt. Betreiber, die ihn nur zur Modernisierung nutzen, verbessern ihre Netze. Betreiber, die ihn nutzen, um Netzwerkfähigkeiten bereitzustellen, abzusichern, zu paketieren und zu monetarisieren, definieren das Netz als programmierbare Plattform für zukünftige digitale Services neu.