APPROFONDIMENTO

Non ideal Fronthaul e attività TIM nell’ambito del TIP

Non ideal Fronthaul  e attività TIM nell’ambito del TIP
 

La soluzione di accesso mobile sperimentata nel TIP Community Lab di TIM a Torino è una soluzione multi vendor volta a verificare il comportamento del sistema nel caso di un FH non ideale trasportato su una rete a pacchetto. Differenti fornitori hanno contribuito alla sua realizzazione, in particolare:

Phluido ha fornito l’Upper Layer 1 della BBU (funzionalmente corrispondente all’insieme O-CU + O-DU definiti in O-RAN) e il Lower Layer 1 installato sulla FPGA della RRU (funzionalmente corrispondente alla O-RU definita in O-RAN);

Radisys ha fornito Layer 2 e Layer 3 della BBU;

Baicells ha fornito la RRU, costituita da una small cell indoor;

Athonet ha messo a disposizione una core LTE carrier grade;

Tech Mahindra insieme a TIM ha svolto il compito di System Integrator ed ha avuto la responsabilità dell’esecuzione dei test previsti, con analisi dei risultati ottenuti e generazione del report finale dell’attività svolta.

 

Figura D - Eco-sistema multi vendor realizzato nel TIP CL di TIM

Nella Figura D si riporta uno schema a blocchi con le connessioni logiche

È importante segnalare che, sebbene uno degli obiettivi iniziali del progetto fosse quello di specificare un’interfaccia open per il fronthaul, le attività del gruppo si siano limitate poi alla realizzazione del PoC.

La soluzione implementata sul FH è pertanto proprietaria e non allineata alle specifiche O-RAN, anche se è stata considerata la stessa opzione di functional split 7-2. Le attività sperimentali condotte nel TIP Community Lab di TIM sono state focalizzate sulla caratterizzazione del Sistema in configurazione RRU singola e multipla (abilitando anche algoritmi CoMP) secondo quanto riportato nella figura precedente (Figura D).

Nel seguito si riportano alcuni risultati ottenuti in configurazione singolo vendor (Phase 0 del progetto, in cui tutto lo stack protocollare è stato fornito da Phluido).

Il sistema è stato testato considerando la configurazione LTE MIMO 2x2. Un primo risultato interessante è la banda misurata sul FH in corrispondenza di un singolo utente connesso (single user peak throughput) in grado di generare quindi 150Mbps in Downlink e 50Mbps in Uplink sulla tratta radio, che mette in evidenza l’efficienza dell’algoritmo di compressione implementato.

 

Tabella T1 - Fronthaul peak throughput per differenti functional splits

I valori misurati sul fronthaul sono confrontati nella tabella (Tabella T1) con i valori teorici di alcuni degli split analizzati in 3GPP (si veda [4]), calcolati in assenza di algoritmi di compressione.

Un altro risultato interessante è ottenuto confrontando il throughput singolo utente sulla tratta radio con la banda corrispondente misurata sul FH nel caso di limitazione della banda disponibile sul trasporto (si veda Figura E). 

 

Figura E - Throughput Downlink e Uplink vs banda limitata sul fronthaul

Dai dati misurati è possibile non solo stimare l’overhead del FH ma soprattutto evidenziare come il sistema sia in grado di lavorare in caso di reti di trasporto congestionate anche se con una degradazione nelle prestazioni massime raggiungibili.

Al fine di valutare la robustezza del sistema alla presenza di possibili delay in rete di trasporto è stata introdotta della latenza aggiuntiva sulla connessione di FH (si veda Figura F). Il throughput TCP mostra una degradazione delle prestazioni per valori di latenza superiori ai 5 ms (dovuti alla mancanza di ottimizzazione degli algoritmi di controllo del TCP) mentre il traffico UDP mostra un buon comportamento anche per valori di latenza estremamente alti.

 

Figura F - Throughput in Downlink e Uplink vs Latenza sul fronthaul

I risultati ottenuti sono tanto più interessanti se confrontati con quanto previsto in letteratura e nella specifica di O-FH O-RAN (almeno nella versione 1.0), dove si parla di valori massimi dell’ordine delle centinaia di microsecondi. Le soluzioni adottate per gestire questi elevati valori di latenza possono comportare una riduzione di prestazione in alcuni scenari; in altre situazioni, tipicamente caratterizzate da bassa mobilità e da una bassa densità di utenti, ci si aspetta una degradazione delle prestazioni trascurabile se non nulla (si veda l’annex L in [5] per approfondimenti). L’implementazione di soluzioni di questo tipo consentirebbe pertanto una maggiore flessibilità per l’operatore nell’implementazione di una soluzione RAN in ottica cloud e il supporto di alcuni scenari quali small cell e FWA (Fixed Wireless Access) con impatti limitati sul trasporto.

 

Torna all'articolo