Gli operatori di rete stabiliscono le priorità O-RAN

Aggiornamento: 13 maggio 2021
Gli operatori di rete stabiliscono le priorità O-RAN

Il gruppo chiede implementazioni O-RAN su larga scala dal prossimo anno. "L'implementazione macro è l'obiettivo principale", afferma il gruppo, aggiungendo che le piccole celle O-RAN sono anche un obiettivo per interni.

"Un chiaro obiettivo per Open RAN è su 3.4-3.8 GHz e un numero di bande FDD legacy, mentre l'interesse per le onde millimetriche è legato alle disponibilità specifiche del paese", afferma il documento.

“Gli X2/Xn aperti rappresentano una linea di base, ma una RAN completamente disaggregata richiederà anche un’interfaccia Open F1 per la suddivisione CU-DU dei gNB. Sono richieste anche le interfacce aperte E2 e A1 che devono essere conformi alle specifiche O-RAN ALLIANCE per consentire multi-vendor/multi0la tecnologia L'implementazione dei RIC a medio termine", si legge nel documento, aggiungendo "per un approccio SMO unificato, saranno necessarie interfacce O1 interoperabili verso tutti i nodi RAN, mentre l'interfaccia O2 sarà necessaria affinché SMO (Service Management & Orchestration) gestisca il CNF in esecuzione sull’infrastruttura O-Cloud.”

Il documento afferma che l'implementazione principale sarebbe una piattaforma O-Cloud (Open Cloud) basata su Kubernetes che supporta il software RAN necessario. Per il software, una funzione di rete containerizzata (CNF) su Bare Metal è la soluzione di destinazione.

Gli operatori supportano funzioni cloud come "la definizione di policy di auto-scaling per un dato pool di nodi, consentendo di scalare automaticamente il numero di nodi in base a metriche come CPU e numero di utenti".

La piattaforma O-Cloud dovrebbe supportare anche la sincronizzazione temporale (PTP, SyncE, GPS) e acceleratori hardware, nonché un Acceleration Abstraction Layer (AAL) che fornisce un set di API aperte alle applicazioni CNF per scaricare le funzioni con accelerazione hardware.

Gli O-CU / O-DU saranno implementati come CNF su "CPU GPP efficienti dal punto di vista energetico e affidabili con supporto dell'accelerazione HW per l'elaborazione O-DU".

Il documento richiede varianti per bande legacy, 3.4-3.8 GHz e spettro di onde millimetriche, con varie modalità di trasmissione (numero di TRX), valori di potenza in uscita e requisiti di larghezza di banda a seconda delle bande di frequenza.

“A seconda delle rispettive bande, sono necessari prodotti a banda singola, doppia o tripla. Il supporto per O-RU multibanda per le bande basse e medie è importante per una distribuzione economica. I prodotti MIMO di massa (32 e 64 TRX) sono richiesti principalmente in 3.4-3.8 GHz. L'attenzione principale è sui prodotti a macro cellule, ma sono necessari anche prodotti a piccole cellule, sia per interni che per esterni ".

RIC riceve l'approvazione affermando che dovrebbe apportare miglioramenti in termini di programmabilità, con applicazioni SON e Radio Resource Management abilitate AI / ML relative al governo del traffico, ottimizzazione QoS / QoE, RAN slicing e Massive MIMO.

"Le interfacce E2 e A1 aperte sono i requisiti di base per consentire l'implementazione di RIC multi-vendor sin dalle prime fasi", afferma il documento.

Anche le distribuzioni devono essere gestibili all'interno di un file framework di automazione e gestione dei servizi e orchestrazione (SMO), e qui gli operatori affermano: “I fornitori di automazione e SMO adotteranno un modello di dati e informazioni unificato (allineato con O-RAN ALLIANCE, 3GPP, ETSI e ONAP) per aumentare l'efficienza della gestione dei servizi e l'automazione indipendente dal fornitore.

“Il framework di gestione e orchestrazione dei servizi è una funzione di dominio RAN centrale per gestire e controllare le funzioni di rete RAN (NF) multi-vendor disaggregate. La visione è quella di evitare l'adozione specifica del fornitore di funzioni proprietarie EMS (Element Management System) utilizzando un approccio di modellazione unificato ".

"La funzione SMO richiede interfacce Northbound definite, ad esempio 3GPP, TM Forum Open API o una divisione funzionale definita per i sistemi OSS."

 

"Il fronthaul aperto è considerato l'interfaccia chiave per implementare una RAN disaggregata e multi-vendor, incluso MIMO massiccio, come base per le prime implementazioni macro".

"Per diventare un'alternativa competitiva alla RAN tradizionale, gli operatori richiedono soluzioni che non compromettano la qualità della rete, la sicurezza, l'elevata efficienza energetica, come supporto per 4G e 5G basati su condivisione RAN indipendente e non autonoma, efficiente e supporto di banda legacy ".

“Si prevede che in seguito emergeranno altre capacità relative a una RAN intelligente e programmabile, offrendo la possibilità alle start-up specializzate di emergere e svolgere un ruolo attivo. Tutti sono essenziali a lungo termine per costruire un ecosistema RAN aperto e competitivo ".