5G Network Slicing: cos'è e come funziona

Immagina un porto industriale in cui droni di sorveglianza trasmettono dati in tempo reale, telecamere ad alta risoluzione monitorano le banchine e centinaia di sensori ambientali inviano piccoli pacchetti ogni pochi minuti. Tutti questi dispositivi funzionano sulla stessa infrastruttura 5G.

Come può un'unica rete garantire pochi millisecondi di latenza per il drone mentre, nello stesso momento, fornisce decine di megabit al secondo alla telecamera, senza che uno rallenti l'altra? La risposta tecnica è il network slicing.

Il network slicing è la capacità di suddividere una singola infrastruttura fisica 5G in più reti logiche indipendenti, chiamate slice. Nonostante condividano un'infrastruttura fisica comune, ogni slice viene implementata per fornire capacità e caratteristiche specifiche per soddisfare i propri requisiti di servizio.

Immaginalo come la costruzione di corsie dedicate su un'unica autostrada: il traffico nella corsia di sorpasso non viene rallentato da quello nelle corsie normali, anche se tutti viaggiano sullo stesso asfalto. Il network slicing è stato standardizzato come parte del sistema 5G nella Release 15 del 3GPP, rendendolo una delle caratteristiche chiave che distingue il 5G standalone (SA) dalle generazioni precedenti, a cui mancavano i meccanismi per isolare veramente il traffico a questo livello.

Affinché una slice soddisfi con successo i requisiti di servizio, le caratteristiche di servizio richieste devono essere mantenute su tre domini principali: RAN, core network e rete di trasporto.

Nella RAN (Radio Access Network), le risorse radio vengono allocate tra le slice per frequenza e tempo, in modo che un dispositivo a bassa latenza non debba competere per lo spettro con uno ad alto traffico dati. Nella core network, le funzioni di rete vengono virtualizzate utilizzando NFV (Network Functions Virtualization), mentre l'SDN (Software-Defined Networking) indirizza dinamicamente il traffico e applica le policy. Insieme, queste tecnologie consentono a ogni slice di operare come una rete logica indipendente con le proprie regole di autenticazione, routing e qualità del servizio. Anche la rete di trasporto, la parte che collega le antenne al core, deve garantire percorsi e priorità distinti.

Ogni dispositivo che desidera utilizzare una specifica network slice deve identificarla in modo preciso. Tale informazione è trasportata in un campo chiamato S-NSSAI (Single Network Slice Selection Assistance Information), che consiste in due parti:

• un SST (Slice/Service Type) obbligatorio: un valore a 8 bit che identifica il tipo di servizio che la slice è progettata per supportare. Può riferirsi a uno dei valori SST standardizzati definiti dal 3GPP o a un valore specifico dell'operatore.
• e un SD (Slice Differentiator) opzionale: un valore a 24 bit utilizzato per distinguere tra più slice che condividono lo stesso SST.

In parole povere: l'SST è come scegliere una classe di servizio postale: standard, espresso, raccomandata. Ma cosa succede se due clienti desiderano la stessa classe di servizio, ma necessitano di livelli di servizio diversi?

È qui che entra in gioco l'SD. Se due clienti necessitano di slice separate con lo stesso SST, è possibile utilizzare valori SD diversi per distinguerle. Entrambi possono richiedere una slice eMBB, ad esempio, ma i loro S-NSSAI possono comunque essere diversi perché utilizzano valori SD differenti.

Le specifiche 3GPP (TS 23.501, sezione 5.15.2.2) definiscono sette Slice/Service Types (SST) standardizzati, ciascuno identificato da un valore numerico a 8 bit che fa parte dell'S-NSSAI utilizzato per richiedere una slice. Questi valori standardizzati forniscono un modo comune per identificare i tipi di slice ampiamente utilizzati e supportare l'interoperabilità tra reti, anche in scenari di roaming.

I tre più noti sono:

• eMBB (enhanced Mobile Broadband, SST 1), pensato per servizi che richiedono un throughput elevato, come i video ad alta definizione;
• URLLC (Ultra-Reliable Low-Latency Communications, SST 2), per applicazioni che non tollerano ritardi, pensate al controllo di un drone o di un braccio robotico;
• e MIoT (Massive IoT, SST 3), per la gestione di un numero molto elevato di sensori che trasmettono piccole quantità di dati raramente.

Questi tre corrispondono da vicino ai tre principali scenari di utilizzo definiti dall'ITU-R per IMT-2020: eMBB, URLLC e mMTC. Ecco perché appaiono in quasi tutte le introduzioni al 5G.

Ma lo standard va oltre.

• V2X (SST 4) copre le comunicazioni vehicle-to-everything.
• HMTC (High-Performance Machine-Type Communications, SST 5) si rivolge al traffico IoT industriale esigente che necessita di più di quanto il MIoT di base possa offrire.
• HDLLC (High Data rate and Low Latency Communications, SST 6), aggiunto con la Release 18, si rivolge a servizi come la realtà estesa e il cloud gaming che necessitano di larghezza di banda e velocità contemporaneamente.

L'aggiunta più recente, GBRSS (Guaranteed Bit Rate Streaming Service, SST 7), introdotta nella Release 19, è pensata per i servizi che necessitano di un throughput continuo e garantito, come le trasmissioni in diretta o la presenza virtuale.

Un singolo operatore, o una singola rete privata, può supportare diversi di questi tipi di slice contemporaneamente, senza costruire un'infrastruttura fisica separata per ciascuno.

Prima dello slicing, un operatore che desiderava offrire garanzie diverse a clienti diversi aveva due opzioni poco allettanti: sovradimensionare l'intera rete per il caso più esigente, sprecando risorse per tutti gli altri, o costruire infrastrutture fisicamente separate, con costi in rapido aumento.

Lo slicing supera questo compromesso. Consente a un operatore di offrire livelli di servizio differenziati (SLA) sulla stessa infrastruttura fisica, isolando il traffico in modo che un picco su una slice non degradi le prestazioni delle altre. Per chi gestisce la rete, questo significa poter lanciare nuovi servizi rapidamente, senza dover installare nuove apparecchiature ogni volta che cambia un requisito. Perché costruire tre reti quando puoi ricavarne tre da una sola?

Nel mondo delle reti private, il termine slicing viene utilizzato in due modi diversi che vale la pena distinguere.

Il primo è una slice ricavata dalla rete pubblica di un operatore: un'azienda può ricevere connettività differenziata e caratteristiche di QoS definite dall'operatore, senza possedere direttamente l'infrastruttura RAN e core sottostante. È un'opzione conveniente per chiunque necessiti di un'ampia copertura senza investimenti infrastrutturali.

Il secondo, più rilevante per le organizzazioni che costruiscono reti private standalone come l'NGCI (Next-Generation Communication Infrastructure), è lo slicing applicato internamente, all'interno del perimetro dell'organizzazione stessa. Nello stabilimento di una fabbrica, ad esempio, un sistema di veicoli a guida autonoma (AGV) può funzionare su una slice URLLC dedicata, mentre le telecamere per il controllo qualità si trovano su una slice eMBB e i sensori ambientali su una slice mMTC, tutto sulla stessa rete privata. Negli ambienti di sorveglianza costiera o marittima, lo stesso principio separa il traffico di comando inviato ai droni, che non tollera ritardi, dal flusso video ad alta risoluzione rinviato in tempo reale. Nella difesa e in altri ambienti critici, l'isolamento delle slice può contribuire anche alla sicurezza limitando l'impatto di problemi o traffico compromesso all'interno di una singola slice.

I due concetti sono spesso presentati come alternative, ma in pratica funzionano bene insieme. Una rete privata standalone fornisce già un dominio di rete dedicato e il controllo diretto sulla sua infrastruttura: aggiungervi lo slicing significa poter gestire contemporaneamente casi d'uso con requisiti molto diversi, senza moltiplicare le apparecchiature.

È questa combinazione che rende un'infrastruttura come NGCI adattabile a diversi scenari, dalla linea di produzione di una fabbrica a un sito di sicurezza, senza bisogno di essere riprogettata ogni volta che l'applicazione cambia.

Niente di tutto questo sostiene che le reti commerciali siano inadatte a ogni scopo. Molte attività collegate alla difesa non richiedono questo livello di controllo, e costruire infrastrutture standalone ovunque non sarebbe né pratico né necessario.

Il valore di una rete privata standalone non risiede semplicemente nel rendere un'organizzazione indipendente da tutto. Piuttosto, permette all'organizzazione di decidere quali dipendenze è disposta ad accettare e quali no, anziché lasciare che questa decisione sia determinata da un contratto commerciale.

Per le organizzazioni che operano in ambienti critici, la vera domanda è quindi quanto controllo sulla rete sia effettivamente necessario e quale approccio (on-premises o commerciale) sia in grado di garantirlo. Per un approfondimento sul compromesso tra reti on-premises e reti di operatori commerciali, e su cosa questo significhi per la sovranità della rete, consulta il nostro articolo dedicato.