Netzbetreiber legen O-RAN-Prioritäten fest

Update: 13. Mai 2021
Netzbetreiber legen O-RAN-Prioritäten fest

Die Gruppe fordert ab dem nächsten Jahr umfangreiche O-RAN-Bereitstellungen. "Die Makrobereitstellung ist das primäre Ziel", sagt die Gruppe und fügt hinzu, dass kleine O-RAN-Zellen auch ein Ziel für Innenräume sind.

„Ein klarer Fokus für Open RAN liegt auf 3.4-3.8 GHz und einer Reihe älterer FDD-Bänder, während das Interesse an Millimeterwellen an die Verfügbarkeit bestimmter Länder gebunden ist“, heißt es in dem Dokument.

„Open X2/Xn sind eine Basislinie, aber ein vollständig disaggregiertes RAN erfordert auch eine Open F1-Schnittstelle für die CU-DU-Aufteilung von gNBs. Offene E2- und A1-Schnittstellen sind ebenfalls erforderlich und müssen den O-RAN ALLIANCE-Spezifikationen entsprechen, um Multivendor/Multi0 zu ermöglichenTechnologie „Mittelfristige RIC-Einführung“, heißt es in dem Dokument und fügt hinzu: „Für einen einheitlichen SMO-Ansatz werden interoperable O1-Schnittstellen zu allen RAN-Knoten erforderlich sein, während die O2-Schnittstelle für den Betrieb des SMO (Service Management & Orchestration) erforderlich sein wird.“ CNFs laufen auf der O-Cloud-Infrastruktur.“

Dem Papier zufolge wäre die Mainstream-Implementierung eine Kubernetes-basierte O-Cloud-Plattform (Open Cloud), die die erforderliche RAN-Software unterstützt. Für die Software ist eine Containerized Network Function (CNF) auf Bare Metal die Ziellösung.

Die Betreiber unterstützen Cloud-Funktionen wie "die Definition von Richtlinien für die automatische Skalierung für einen bestimmten Knotenpool, sodass die Anzahl der Knoten automatisch anhand von Metriken wie CPU und Anzahl der Benutzer skaliert werden kann".

Die O-Cloud-Plattform sollte auch Zeitsynchronisations- (PTP, SyncE, GPS) und Hardwarebeschleuniger sowie eine Beschleunigungsabstraktionsschicht (AAL) unterstützen, die CNF-Anwendungen eine Reihe offener APIs zum Auslagern der hardwarebeschleunigten Funktionen bietet.

Die O-CU / O-DUs werden als CNFs auf „energieeffizienten und zuverlässigen GPP-CPUs mit Unterstützung der HW-Beschleunigung für die O-DU-Verarbeitung“ implementiert.

Das Papier fordert Varianten für Legacy-Bänder, 3.4-3.8 GHz und Millimeterwellenspektrum, mit verschiedenen Übertragungsmodi (Anzahl der TRX), Ausgangsleistungswerten und Bandbreitenanforderungen in Abhängigkeit von den Frequenzbändern.

„Je nach Band sind Einzelband-, Doppelband- oder Dreifachbandprodukte erforderlich. Die Unterstützung von Multiband-O-RUs für niedrige und mittlere Bänder ist wichtig für eine kostengünstige Bereitstellung. Massive MIMO-Produkte (32 und 64 TRX) werden hauptsächlich bei 3.4-3.8 GHz nachgefragt. Das Hauptaugenmerk liegt auf Makrozellenprodukten, aber es werden auch Produkte für kleine Zellen benötigt, sowohl im Innen- als auch im Außenbereich. “

RIC erhält die Genehmigung, Verbesserungen in Bezug auf die Programmierbarkeit mit AI / ML-fähigen SON- und Radio Resource Management-Anwendungen in Bezug auf Verkehrssteuerung, QoS / QoE-Optimierung, RAN-Slicing und Massive MIMO vorzunehmen.

„Offene E2- und A1-Schnittstellen sind die Grundvoraussetzungen, um eine RIC-Bereitstellung mehrerer Hersteller ab einer frühen Phase zu ermöglichen“, heißt es in dem Dokument.

Bereitstellungen müssen auch innerhalb von verwaltet werden können SMO-Framework (Automation and Service Management and Orchestration)und hier sagt der Betreiber: „Automation & SMO Vendors müssen ein einheitliches Daten- und Informationsmodell (abgestimmt auf O-RAN ALLIANCE, 3GPP, ETSI und ONAP) anwenden, um die Effizienz des Service-Managements und die herstellerunabhängige Automatisierung zu erhöhen.

„Das Service Management and Orchestration-Framework ist eine zentrale RAN-Domänenfunktion zur Verwaltung und Steuerung disaggregierter RAN-Netzwerkfunktionen (NF) mehrerer Anbieter. Die Vision ist es, die herstellerspezifische Übernahme proprietärer EMS-Funktionen (Element Management System) durch einen einheitlichen Modellierungsansatz zu vermeiden. “

"Die SMO-Funktion erfordert definierte Northbound-Schnittstellen, z. B. 3GPP, TM Forum Open API oder eine definierte Funktionsaufteilung für OSS-Systeme."

 

"Open Fronthaul wird als Schlüsselschnittstelle für die Implementierung eines disaggregierten RAN mit mehreren Anbietern, einschließlich massivem MIMO, als Basis für die ersten Makrobereitstellungen angesehen."

„Um eine wettbewerbsfähige Alternative zu herkömmlichem RAN zu werden, benötigen die Betreiber Lösungen, die keine Kompromisse bei Netzwerkqualität, Sicherheit und hoher Energieeffizienz eingehen, da 4G und 5G sowohl auf eigenständiger als auch auf nicht eigenständiger, effizienter RAN-Freigabe und Legacy-Band-Unterstützung basieren ”.

„Weitere Funktionen im Zusammenhang mit einem intelligenten und programmierbaren RAN werden voraussichtlich später verfügbar sein und das Potenzial für spezialisierte Start-ups bieten, eine aktive Rolle zu spielen. Alle sind auf lange Sicht unerlässlich, um ein wettbewerbsfähiges offenes RAN-Ökosystem aufzubauen. “