Open RAN: dalle specifiche ai trials

Open RAN: dalle specifiche ai trials
 

Open RAN: dalle specifiche ai trials

 

Verso l’Open RAN

Negli ultimi anni si è assistito ad un aumento esponenziale del traffico mobile a cui si è affiancata la domanda crescente di supporto di connessioni di tipo “always connected” e di terminali controllati da remoto (la cosiddetta Internet of Things). Questa rapida evoluzione spinge gli operatori a cospicui investimenti al fine di aggiornare la rete per far fronte alle sempre crescenti richieste di capacità, a cui non corrisponde un analogo aumento dei profitti anche a causa della forte competizione in atto tra i diversi operatori. Queste dinamiche stanno spingendo gli operatori mobili a cercare nuove soluzioni architetturali che permettano da una parte di introdurre più velocemente nuovi servizi e nuove funzionalità per aumentare la capacità offerta dalla rete, e che dall’altra parte aiutino a rendere i costi di ampliamento e gestione della rete compatibili con lo scenario fortemente competitivo.

Nel caso del segmento dell’accesso radio, visti i maggiori investimenti richiesti, si fa più pressante l’esigenza di ricercare nuove soluzioni ed approcci che permettano di realizzare un’architettura più flessibile, anche a supporto dell’introduzione delle nuove funzionalità legate al 5G. In quest’ottica si stanno affermando diverse iniziative che propongono, con diverse sfumature, il concetto di ‘Open RAN’, con l’obiettivo di introdurre una maggiore competizione nel segmento radio e favorire anche l’ingresso di nuovi attori. In particolare, è possibile individuare alcuni obiettivi comuni alle diverse iniziative:

  • La possibilità di utilizzare dispositivi, apparati e applicativi da diversi fornitori, garantendo quindi l’interoperabilità tramite la definizione di interfacce standard aperte;
  • L’utilizzo di hardware non specializzato su cui poter installare i moduli software (realizzati anche da fornitori differenti) che implementano le diverse funzionalità di rete;
  • L'introduzione di maggiore intelligenza nel segmento radio, sfruttando anche tecniche di AI/ML (Artificial Intelligence/Machine Learning) al fine di automatizzare molte operazioni volte alla gestione, configurazione e ottimizzazione radio.

Un approccio cloud, mediante l’impiego di opportune soluzioni di Iaas/PaaS per l’hosting anche delle funzioni radio è visto come un importante abilitatore per il raggiungimento degli obiettivi sopra elencati. Al fine di perseguire questi obiettivi TIM ha aderito a due consorzi internazionali, l’O-RAN Alliance [1] e il Telecom Infra Project (TIP) [2], rispettivamente sin dal 2018 e dal 2017.

L’O-RAN Alliance è un’iniziativa guidata da operatori e risultante dalla fusione tra xRAN Forum e C-RAN Alliance al fine di spingere verso una maggiore apertura delle interfacce nella rete di accesso radio dei sistemi mobili di futura generazione. Supportata da operatori quali AT&T, China Mobile, Deutsche Telekom, NTT DOCOMO, Orange, Verizon e TIM, persegue l’obiettivo di fare evolvere l’accesso radio secondo i paradigmi della disaggregazione delle funzionalità radio, virtualizzazione e disaccoppiamento hardware/software con utilizzo di hardware generico (cosiddetto whitebox), automazione e standardizzazione di interfacce aperte per abilitare una vera interoperabilità.

Il TIP è un’iniziativa patrocinata da Facebook, a cui partecipano operatori e costruttori, con un obiettivo più generale che può riassumersi con la frase ‘connect the unconnected’: supportare l’innovazione tramite lo sviluppo di Proof of Concept e trial al fine di sviluppare soluzioni cost-effective che permettano di portare internet ovunque. Per il segmento radio questo obiettivo ha portato a considerare elementi comuni all’O-RAN: disaggregazione delle funzionalità, virtualizzazione e disaccoppiamento hardware/software con utilizzo di whitebox.

 

Figura 1 - La disaggregazione del nodo radio (e/gNB) in diversi blocchi funzionali e relative interfacce

O-RAN Alliance

Uno degli obiettivi dell’O-RAN Alliance è  favorire la realizzazione di una RAN aperta, basata sulla disaggregazione del nodo di accesso radio secondo quanto previsto dall’architettura 3GPP, alla quale sono stati aggiunti ulteriori elementi funzionali e le relative interfacce. A tal fine è stata definita un’architettura di riferimento (riportata in Figura 1) dove sono rappresentati diversi componenti associati alle varie funzionalità radio:

O-RU (O-RAN Radio Unit):
La parte del nodo radio connessa alle antenne (o che le integra nel caso di sistemi di antenne attive) e responsabile della conversione del segnale da digitale ad analogico e a radiofrequenza in trasmissione e viceversa in ricezione. Il blocco contiene la parte bassa del livello protocollare fisico (Low-PHY).

O-DU (O-RAN Distributed Unit):
La componente del nodo radio che contiene la parte alta del livello fisico (High-PHY) insieme ai livelli protocollari MAC e RLC. Questo blocco, contenendo sia lo scheduler che la codifica di canale, è quello che richiede il maggior carico computazionale. Al fine di perseguire un approccio cloud anche per la componente RAN l’idea è virtualizzare anche questa componente e centralizzarla in un opportuno data centre consentendo l’abilitazione di algoritmi di coordinamento quali Carrier Aggregation e CoMP. In tal caso, visti gli elevati requisiti in termini di processing e esigenze real time, al fine di avere una soluzione più efficiente, è prevedibile l’impiego di soluzioni di accelerazione hardware (quali FPGA o GPU) in aggiunta a hardware non specializzato (tipicamente basato su architetture x86).

O-CU (O-RAN Central Unit):
questo elemento è standardizzato anche in 3GPP e viene ulteriormente composto da una parte che gestisce lo User Plane (contenente il protocollo PDCP e il protocollo SDAP) e una parte di Control Plane (contenente il protocollo RRC). Facendo riferimento agli split funzionali analizzati in 3GPP (si veda [4]), l’interfaccia tra la O-CU e la O-DU (indicata con F1 per NR e W1 per LTE) è basata pertanto sull’opzione 2. Anche tenendo conto delle prime soluzioni di virtual RAN, la virtualizzazione di questo elemento è fattibile impiegando unicamente hardware non specializzato.

RT-RIC (Real Time Radio Intelligence Controller):
è l’elemento funzionale in cui vengono centralizzate alcune procedure di RRM (Radio Resource Management) quali ad esempio l’Admission Control, l’Handover e il Measurement Report, permettendo anche l’utilizzo di implementazioni fornite da terze parti e l’impiego di tecniche di AI/ML.

NRT-RIC (Non Real Time Radio Intelligence Controller):
è l’elemento funzionale presente all’interno del layer di Service Management and Orchestration (SMO) che permette il controllo del nodo RAN attraverso l’invio di Policy e monitorando le informazioni FCAPS (Fault, Configurations, Allarms, Performance and Security) provenienti dai vari blocchi dell’architettura.

Per favorire l’apertura dell’ecosistema dell’accesso radio a diversi player, l’O-RAN si è posto l’obiettivo di assicurare l’effettiva interoperabilità tra i diversi elementi di rete. Per questo, a partire dalle specifiche standard già definite in 3GPP, vengono definiti opportuni profili ottenuti selezionando sottoinsiemi delle opzioni previste dallo standard. Essendo tuttavia presenti nuovi elementi nell’architettura, l’O-RAN specifica anche nuove interfacce:

  • L’interfaccia O-FH (Open Fronthaul) è l’interfaccia tra la O-DU e la O-RU, che abilita l’interoperabilità tra O-DU (che può essere installata presso il sito radio o presso un data centre) e O-RU (installata vicino alle antenne) e che possono essere fornite da costruttori differenti. Facendo riferimento agli split funzionali analizzati in 3GPP (si veda [4]), per tale interfaccia è stato selezionata l’opzione 7-2.
  • Le interfacce A1 e E2, che consentono il monitoraggio e la riconfigurazione della rete in modo dinamico e automatico in funzione delle esigenze di servizio/copertura, applicando anche tecniche di AI/ML. Come si vede nell’esempio in Figura 2 l’interfaccia O1 permette di passare al RT-RIC un ML Model (step 3). Il Modello passato verrà usato dal RT-RIC per ottimizzare le decisioni da applicare in rete attraverso input e output sulle interfacce A1 e E2 (step 4 e 5). I contatori di rete vengono poi collezionati nel SMO (step 6) e vengono usati per fare il training di nuovi modelli ML (step 1), i modelli ritenuti validi vengono caricati come quelli utilizzabili dal NRT-RIC (step 2) pronti per aggiornare quelli esistenti nei RT-RIC.

L’attività O-RAN è organizzata in Working Group che hanno lo scopo di definire le interfacce descritte in Figura 1.

WG1: è il gruppo che si occupa di standardizzare l’interfaccia O1 che corrisponde all’interfaccia di OAM (Operation & Maintenance). Le informazioni FCAPS provenienti dai vari blocchi vengono catturate da questa interfaccia, che allo stesso tempo può essere usata per la configurazione del nodo.

WG2: è il gruppo che si occupa di standardizzare l’interfaccia A1, il cui scopo è inviare informazioni relative alle policy con cui la RAN deve gestire gli utenti o i servizi legati ai diversi utenti. La stessa interfaccia può essere usata per trasmettere alla RAN modelli di Machine Learning (ML) e/o Enrichment Information (EI) al fine di migliorare la gestione delle procedure Radio per raggiungere l’obiettivo prefissato a livello di SMO.

WG3: è il gruppo che si occupa di definire l’interfaccia E2, il cui compito è quello gestire le procedure radio del nodo in real-time (RT). Per fare questo deve comunicare con i moduli che gestiscono il C- Plane nel nodo radio ovvero: RRC della O-CU e lo scheduler a livello MAC che risiede nella O-DU.

WG4: è il gruppo che si occupa di definire l’interfaccia O-FH che collega la O-DU alla O-RU. Il gruppo definisce anche le specifiche dell’interfaccia di gestione della O-RU e di conformance test e di interoperabilità dell’interfaccia O-FH

WG5: è il gruppo che si occupa delle interfacce tra O-DU e O-CU (F1/W1), tra C-Plane e U-Plane (E1) e anche delle interfacce tra altri nodi radio (X2/Xn).  Essendo queste interfacce oggetto di standardizzazione in 3GPP, il compito di questo gruppo è assicurarsene l’effettiva interoperabilità andando a ridurre le opzioni e gli aspetti lasciati all’implementazione.

Il compito di O-RAN non si limita solo alla definizione di interfacce logiche tra funzionalità radio: nel consorzio sono presenti ulteriori working group con l’obiettivo di promuovere l’implementazione di soluzioni O-RAN in ottica cloud, al fine di disaccoppiare l’hardware dal software e permettere l’utilizzo di hardware non specializzato:

WG6: è il gruppo che si occupa di definire l’architettura cloud per il nodo RAN, in funzione delle diverse ipotesi di dispiegamento. L’attività comprende la definizione di modalità per l’utilizzo di piattaforme di accelerazione hardware (come FPGA/DSP/ASIC/GPU) necessarie per alcune delle funzioni radio più onerose dal punto di vista computazionale.

WG7: è il gruppo che si occupa della definizione di un reference design per l’hardware di una “white box” in grado di implementare il nodo radio (in particolare per la componente O-DU ed O-RU)

WG8: è il gruppo che si occupa della definizione di un reference design del software che implementa il nodo radio.

Un passo ulteriore verso la realizzazione di RAN multivendor consiste nella possibilità di certificare il livello di conformance allo standard e l’interoperabilità delle soluzioni sviluppate. Per questo è stato istituito il TIFG (Test and Interoperability Focus Group) il cui compito è definire un processo di test e di certificazione delle diverse interfacce al fine di validare la bontà delle soluzioni proposte dai diversi vendor. A tal fine il gruppo prevede la costituzione di diversi laboratori OTIC (O-RAN test and integration certification) responsabili della certificazione di apparati O-RAN compliant. Il gruppo si occupa anche dell’organizzazione di plugfest, eventi nei quali i vari fornitori possono verificare il livello di interoperabilità raggiunto delle proprie soluzioni con quelle sviluppate da altri fornitori. Infine, è importante segnalare l’intento di promuovere lo sviluppo open source dei moduli che compongono l’architettura O-RAN. Per questo è stata stabilita una relazione con la Linux Foundation dove è stata istituita la OSC (O-RAN Software Community) il cui compito è fornire un’implementazione open source dei vari moduli, partendo in particolare dalle piattaforme di NRT-RIC e RT-RIC e da altri moduli del Service Management and Orchestration basati sulla piattaforma ONAP e opportunamente specializzati per le applicazioni in ambito RAN.

 

Figura 2 - La disaggregazione del nodo radio (e/gNB) in diversi blocchi funzionali e relative interfacce

Telecom Infra Project

Nell’ambito del TIP, TIM ha partecipato sin dalla sua costituzione al progetto vRAN Fronthaul [3]. Il progetto, nato nel 2017, ha l’obiettivo di sviluppare una soluzione di RAN virtualizzata multi vendor in grado di poter essere dispiegata in presenza anche di soluzioni di trasporto per il fronthaul cosiddette non ideali, ovvero in scenari dove non è sempre disponibile la fibra e le tecnologie di trasporto sono caratterizzate da una banda limitata e latenze anche superiori al millisecondo. All’interno del progetto sono stati selezionati 4 laboratori (Community Labs) sponsorizzati da altrettanti operatori, dove diverse soluzioni prototipali multi-vendor sono state sviluppate al fine di supportare diversi use case:

  • CableLabs: La sperimentazione in questo caso è focalizzata a misurare l’efficienza di compressione della banda e di robustezza a elevati valori di latenza sul fronthaul tali da permettere il dispiegamento della soluzione vRAN sulla rete DOCSIS esistente. Gli scenari di dispiegamento considerano quindi femto celle indoor e small cell in ambito urbano.
  • BT: nel caso di BT l’interesse è per soluzioni di vRAN con fronthaul efficiente in grado di essere trasportato su reti ethernet (quali quelle presenti in campus universitari o grandi aziende), G.Fast e ponti radio. Gli scenari di interesse in tal caso considerano anche funzionalità multi-operatore/neutral host.
  • Airtel: anche nel caso dello use case considerato da Airtel l’efficienza e robustezza alla latenza sono importanti in quanto si prevede l’utilizzo di ponti radio multi-hop per il trasporto del fronthauling.
  • TIM: Lo use case considerato da TIM indirizza un utilizzo efficiente della fibra già dispiegata, dove le capacità di compressione della banda è la prima priorità per assicurare lo sfruttamento adeguato degli asset in fibra e loro evoluzione. In tal caso lo scenario considerato è quello a supporto del dispiegamento di small cell con utilizzo di tecnologia PON (Passive Optical Network) e sue evoluzioni per il trasporto del fronthauling. Pensando ai meccanismi di allocazione della banda in questi sistemi punto-multipunto, anche la robustezza nei confronti della latenza è un fattore importante. 

Un dettaglio sulle attività svolte nell’ambito del Community Lab di TIM è illustrato nel box di approfondimento “Non ideal Fronthaul e attività TIM nell’ambito del TIP”. È importante segnalare come le varie aziende che hanno partecipato al progetto vRAN Fronthaul hanno poi proposto un work item in O-RAN per estendere le specifiche dell’O-FH, al fine di considerare anche latenze tipiche di questi scenari “non ideal”. Questa estensione è stata approvata nella release 2.0. In aggiunta, al fine di permettere il supporto da parte dell’O-FH di tecnologie di trasporto quali DOCSIS e PON è stato avviato un altro work item in O-RAN (CTI, Cooperative Transport Interface) tutt’ora in corso 

 

References

[1]      https://www.o-ran.org/

[2]      https://telecominfraproject.com/

[3]      https://vran.telecominfraproject.com/

[4]     3GPP TR 38.801, 3rd Generation Partnership Project, Technical Specification Group Radio Access Network, Study on new radio access technology: Radio access architecture and interfaces (Release 14).

[5]     ORAN-WG4.CUS.0-v02.00, O-RAN Fronthaul Working Group, Control User and Synchronization Plane Specification.

[6]     O-RAN A1 interface: General Aspects and Principles Version 1.0 - October 2019 (ORAN-WG2.A1.GA&P-v01.00)

[7]      O-RAN NR U-plane profile for EN-DC Version 1.0 - June, 2019 (ORAN-WG5.U.0-v1.00)

[8]     O-RAN NR C-plane profile for EN-DC Version 1.0- June, 2019 (ORAN-WG5.C.1-v1.00)

[9]     O-RAN Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN Version 1.0 - October 2019 (O-RAN-WG6.CAD-V01.00.00)

[10]   O-RAN Operations and Maintenance Architecture Version 1.0 - July 2019 (O-RAN-WG1.OAM Architecture -v01.00)

[11]       O-RAN Operations and Maintenance Interface Version 1.0 - July 2019 (O-RAN-WG1.OAM Interface Specification-v1.0)

 

 

Acronimi

ASIC            Application Specific Integrated Circuit

BBU             Baseband Unit

CoMP           Coordinated Multi Point

DOCSIS        Data Over Cable Service Interface Specification

DSP              Digital Signal Processor

eCPRI           enhanced CPRI

FPGA            Field Programmable Gate Array

GPU              Graphics Processing Unit

LTE               Long Term Evolution

MAC              Medium Access Control

MIMO            Multiple Input Multiple Output

MU-MIMO      Multi User MIMO

NR                 New Radio

PDCP             Packet Data Convergence Protocol

RAN              Radio Access Network

RLC               Radio Link Control

RRC               Radio Resource Control

RRM               Radio resource Management

RRU               Radio Remote Unit

SDAP              Service Data Adaptation Protocol

TCP                Transmission Control Protocol

UDP                User Datagram Protocol