Evoluzione della Core Network verso il 5G

Con le nuove reti 5G stiamo creando l’ecosistema per un mondo connesso dove le persone, le applicazioni, gli oggetti di uso quotidiano, i sistemi di trasporto, le città comunicano tra di loro e condividono informazioni per migliorare la qualità della vita. In questo contesto “flessibilità” diventa la nuova parola d’ordine (flessibilità nella progettazione, realizzazione e gestione dei servizi di comunicazione) e questo comporta la necessità di ripensare il modo di progettare la Core Network, aprendosi a nuove tecnologie mutuate dall’Information Technology

 

Introduzione

L’articolo si propone di descrivere le principali caratteristiche della Core Network (CN) 5G e come possa evolvere in generale la CN nella prospettiva di un operatore che voglia dispiegare il 5G. Già nelle strategie attuali di molti operatori esistono tecnologie che precorrono alcune specificità del 5G. Ciò sarà descritto nella parte iniziale dell’articolo. Nel resto dell’articolo si chiarirà come partendo da queste tecnologie, la standardizzazione stia definendo un approccio a fasi per l’introduzione della CN 5G.

 

Principali driver evolutivi della Core Network

In questi anni abbiamo assistito ad una crescita esponenziale del traffico dati trasportato sulla rete mobile di TIM. Stante le attuali previsioni, il trend di crescita del traffico dati sulla rete mobile TIM nei prossimi anni sarà ancora maggiore. L’aumento del traffico dati è stato guidato in questi anni dalla proliferazione degli smartphone che permettono il trasferimento dei dati con bit rate elevati e dall’incremento della domanda per applicazioni multimediali: il traffico video rappresenta all’incirca il 50% del traffico dati sulla rete mobile e tale tipologia di traffico è destinata ad aumentare con l’avvento dei video 3D.
Inoltre bisogna anche considerare la crescita esponenziale del traffico dati e la complessità di rete dovute al fenomeno che sta letteralmente esplodendo in questi ultimi anni, ovvero la connessione ad Internet di dispositivi prima isolati che danno vita all’Internet of Things (IoT). L’Internet of Things si occupa di comunicazione Machine-to-Machine (M2M) ed è definita Machine-Type Communications (MTC) in ambito 3GPP. La gamma delle applicazioni IoT è molto ampia: smart grids, smart cities, smart automotive driving, solo per citarne alcune. Le reti di nuova generazione devono affrontare la coesistenza del traffico Human-Type Traffic (HTC), che richiede sempre più capacità, con l'emergere di traffico MTC, che è fondamentalmente diverso da quello HTC. Ciò implica che la progettazione della rete deve prendere queste differenze in considerazione.
Il traffico MTC ha caratteristiche estremamente eterogenee, ma in molti casi è caratterizzato da trasmissioni sporadiche di piccole quantità da parte di una miriade di dispositivi a bassa mobilità che, dispiegati sul territorio, devono assicurare anni di funzionamento senza la necessita di sostituire la batteria.
Al fine di supportare tali requisiti le tecnologie radio che risultano di maggiore interesse sono NB-IoT (Narrowband IoT), a banda stretta per applicazioni a bassa mobilità, e LTE-M (LTE – Machine Type Communications), anche nota come e-MTC (enhanced MTC) per applicazioni M2M con maggiori requisiti di banda e supporto della mobilità.
Nel caso dell’ eMTC il servizio IoT co-esisterà  con quello mobile broadband sulla medesima rete radio LTE, mentre nel caso del NB-IoT sarà dispiegato un nuovo accesso radio narrow band e low power specifico per l’IoT.
Il supporto in rete di queste nuove tecnologie radio richiederà l’introduzione nella CN a pacchetto di nuove funzionalità, definite nella Release 13 3GPP, note come C-IoT (Cellular IoT) EPS optimizations: in una prima fase mediante l’aggiornamento di nodi SGSN-MME e SGW-PGW esistenti, in seguito con il dispiegamento di una CN dedicata in grado di scalare con dispiegamenti IoT massivi, basata su un unico nodo combinato chiamato C-SGN (C-IoT Servig Gateway Node). L’architettura di riferimento è riportata nella figura seguente:

 

Figura 1 - Architettura CIoT

L’architettura C-IoT comprende inoltre la SCEF (Service Capability Exposure Function) che viene utilizzata per esporre servizi di rete verso terze parti, tipicamente di aziende clienti, attraverso API (Application Programming Interface) definite da OMA, GSMA e altri forum. Nel contesto IoT le funzioni da essa svolte sono il trasferimento di Non-IP-Data (NIDD) tra il terminale e le piattaforme di servizio e la notifica alle applicazioni IoT dello stato del terminale (ad es. raggiungibilità).
L’utilizzo di una CN dedicata richiede alla rete di accesso radio la capacità di instradare verso di essa il traffico dei terminali di tipo NB-IoT o e-MTC, continuando a servire gli utenti mobile broadband tramite la EPC legacy.  Sono possibili differenti soluzioni:

  • La soluzione più semplice, ma con importanti impatti in rete e di servizio, si basa sulla definizione di un identificativo di rete (PLMN Id) differenziato, specifico per gli accessi radio NB-IoT, e l’utilizzo della funzionalità di MOCN (Multi Operator Core Network).
  • Una soluzione alternativa utilizza la funzionalità DeCOR (Dedicated Core Network) a standard 3GPP Release 13 che, sulla base di un parametro di sottoscrizione nel profilo HSS (UE-Usage-Type), permette ridirigere la procedura di registrazione in rete verso la CN dedicata C-IoT.  In questo caso è richiesta una profilatura ad-hoc dell’utenza IoT.
  • Infine può essere utilizzata la funzionalità enhanced DeCOR (eDeCOR), definita nella Release 14 3GPP, che si basa su una indicazione da parte del terminale all’e-NodeB per assistere l’instradamento del traffico verso la CN dedicata C-IoT.

Sulla base di quanto indicato,  possiamo affermare che il Mobile Internet e l’IoT sono i due driver più importanti per l’evoluzione dell’attuale CN PS di TIM verso il 5G. A questi si aggiungono altre innovazioni tecnologiche già ampiamente descritte in numeri precedenti di questo notiziario tecnico.
Una delle innovazioni tecnologiche da introdurre in rete a breve termine in vista dell’avvento del 5G è rappresentata dall’inserimento del protocollo IPv6  al fine di poter gestire l’aumento esponenziale di terminali mobili contemporaneamente attivi. L’analisi per l’inserimento in rete del protocollo IPv6 dovrà essere estesa anche a tutti gli elementi a contorno ovvero i sistemi di tariffazione e lawful interception e supervisione.
Al fine di poter gestire la crescita del traffico prevista per i prossimi anni e tenendo in considerazione l’avvento del 5G, la tecnologia NFV rappresenta un potente abilitatore per adeguare opportunamente l’infrastruttura della CN TIM. L’NFV viene considerata un elemento cardine dell’evoluzione della rete verso il 5G e fa parte di un percorso di trasformazione più ampio che interessa tutto il mondo delle telecomunicazioni e dei servizi. Tra i principali benefici attesi dall’utilizzo della tecnologia NFV sono:

  • accelerazione del “Time to Market” per l’inserimento in rete di nuove funzionalità;
  • maggiore agilità nella progettazione e gestione della rete, grazie alla possibilità di rimodulare e riassegnare dinamicamente le risorse dedicate alle diverse funzionalità.

L’introduzione delle tecnologie NFV nella CN TIM ad oggi è pianificato per il 2018.

 

La Core Network 5G

Il 3GPP ha completato a fine 2016 lo studio di fattibilità per la nuova Core Network 5G (5GC) ed i risultati sono stati documentati nel Technical Report 23.799 [1].  Nel 2017, nella sua Release 15, il 3GPP ha iniziato l’attività normativa di specifica dell’architettura e delle procedure per la 5GC documentata rispettivamente nelle Technical Specification 23.501 [2] e 23.502 [3]; parallelamente è iniziata la definizione degli aspetti protocollari e dell’accesso radio 5G e si prevede che nel giugno 2018 sarà disponibile un set completo di specifiche implementabile da parte dei costruttori di apparati (vedi Figura 2).

 

Figura 2 - Piano delle attività 3GPP per il 5G

L’architettura della nuova rete 5G è rappresentata in Figura 3.

 

Figura 3 - Architettura della nuova rete 5G

La 5GC di Release 15 supporta la connettività dei terminali via 5G Radio Access Network (5G-RAN), e via accessi non-3GPP untrusted (ad es. WLAN). Il requisito di supportare anche accessi non-3GPP trusted e di rete fissa verrà presumibilmente soddisfatto in Release 16.
Nell’architettura della nuova rete 5G la Core Access and Mobility Management Function (AMF) costituisce il punto di accesso alla 5GC per la segnalazione da e per il terminale analogamente all’MME delle reti 4G. Tuttavia, a differenza dell’MME, l’AMF gestisce solo la registrazione e la mobilità del terminale, poiché la segnalazione relativa alla creazione ed alla gestione delle sessioni dati d’utente viene inoltrata trasparentemente alla Session Management Function (SMF). Un primo elemento di novità nella nuova architettura di rete è rappresentato quindi dalla separazione del controllo della mobilità da quello delle sessioni dati d’utente. Questa modularizzazione delle funzionalità consente di aumentare la flessibilità con la quale esse possono essere composte per realizzare catene di servizio e gioca un ruolo importate in una delle caratteristiche distintive delle reti 5G, ovvero il Network Slicing di cui si parlerà più avanti.
Un altro elemento di flessibilità nell’architettura è rappresentato dalla separazione del piano di controllo delle sessioni dati da quello dei dati d’utente. La separazione tra SMF e User Plane Function (UPF) consente all’Operatore di dispiegare le UPF nel modo più efficace, in funzione della tipologia di servizi che esse sono deputate a veicolare; ad esempio, per servizi ove è richiesta bassissima latenza, le UPF e le piattaforme di servizio verranno dispiegate quanto più possibile vicino ai dispositivi da controllare. La separazione del piano di controllo da quello d’utente è stata introdotta anche nella EPC in Release 14 [4] per Serving e PDN Gateway. Tuttavia, nel disegnare SMF e UPF nella 5GC sono stati aggiunti concetti completamente nuovi. Infatti, a differenza di quanto accade nelle reti 4G dove lo SGW rappresenta un’ancora per tutte le sessioni dati d’utente, nella 5GC sessioni dati d’utente diverse possono essere ancorate ad UPF diverse. Inoltre una UPF, mediante le funzionalità di Uplink Classifier, può selezionare determinati flussi di traffico nell’ambito di una sessione dati d’utente e ridirigerli verso una rete locale dove, ad esempio, possono essere collocate piattaforme di Mobile Edge Computing (MEC). Una UPF, mediante le funzionalità di Branching Point, può anche distribuire una sessione dati IPv6 multi-homed verso altre UPF, tutte agganciate alla stessa rete dati, e abilitare uno dei nuovi schemi di gestione della mobilità (make-before-break) introdotti nella rete 5G.
Riguardo alla mobilità si è considerato che i progressi nello sviluppo delle applicazioni hanno consentito a molte di esse  di tollerare cambiamenti di indirizzo IP senza pregiudicare il servizio percepito dall’utente. Per questa ragione, accanto allo schema tradizionale di gestione della mobilità che si applica a servizi come la Voice over IMS (VoIMS), in cui la connessione dati viene spostata da un punto di aggancio alla rete ad un altro preservando l’indirizzo IP, si sono introdotti nuovi meccanismi meno onerosi in termini di risorse dove si ammette che l’indirizzo IP possa variare al cambiare del punto di aggancio alla rete della connessione dati, secondo i paradigmi make-before-break e break-before-make.
La complessità introdotta da queste innovazioni hanno però un prezzo: in Release 15 le sessioni dati dual-stack IPv4v6 non sono supportate e la nuova 5GC supporta terminali dual-stack usando sessioni dati separate per IPv4 e IPv6. Ricordiamo che accanto alle sessioni dati di tipo IP la nuova 5GC supporta anche connessioni dati di tipo non-IP e di tipo ethernet per indirizzare scenari d’uso come quelli connessi al mondo della Internet of Things (IoT). A questo riguardo la nuova 5GC supporta nativamente alcune delle funzionalità/ottimizzazioni che erano state aggiunte alla EPC in Release 13, come le già citate connessioni dati di tipo non-IP e la possibilità di registrarsi alla rete senza la necessità di attivare una connessione dati. Tuttavia in Release 15 il traffico generato da dispositivi IoT potrà gestito solo mediante l’attivazione di sessioni dati; non verranno cioè sviluppate in questa Release ottimizzazioni per il trasferimento di “small and infrequent data” mediante i pacchetti di segnalazione sul piano di controllo.
Una funzionalità nuova rispetto al 4G, pensata per il mondo dei sensori che devono poter funzionare per anni senza sostituzione della batteria, è quella che va sotto il nome di Mobile Initiated Connection only (MICO). Un terminale che chiede alla rete di operare il modalità MICO non deve monitorare il canale radio di paging fintanto che si trova nello stato CM-IDLE. La rete (AMF) lo considera irraggiungibile e differisce la consegna di SMS e di altro traffico terminato fino a quando quando transisce dallo stato CM-IDLE a quello CM-CONNECTED perché trasmettere, ad esempio, dei dati o della segnalazione.
Quanto descritto sino ad ora ci fa capire come la nuova 5GC debba supportare in modo agile e flessibile una offerta di servizi estremamente eterogenea (mobile broadband, IoT, Public Safety, vehicular, ecc.) con requisiti spesso contrastanti. Per accomodarli a meglio la strada scelta è quella della segregazioni mediante il network slicing. Il concetto non è nuovo e già a partire dalla Release 13 il 3GPP ha definito in la funzionalità Dedicated Core Networks (DECOR) che, basandosi sul parametro di sottoscrizione “UE Usage Type”, consente di connettere il terminale ad una istanza di Core Network dedicata (DCN). Tale concetto è stato ulteriormente sviluppato in Release 14 con eDECOR dove è previsto che il terminale assista la RAN nella selezione della DCN mediante un parametro specifico inserito nella segnalazione di Access Stratum (AS) verso l’evolved NodeB (eNB), durante la procedura di registrazione alla EPC.
Tuttavia il limite di queste soluzioni è rappresentato dal fatto che in una rete 4G un terminale può connettersi ad una sola DCN per volta, che pertanto non può essere specializzata e ottimizzata per una molteplicità di servizi. Nella nuova rete 5G il terminale può invece connettersi contemporaneamente a più Network Slice, ciascuna delle quali può quindi essere ottimizzata per offrire un servizio specifico: una Network Slice infatti è una rete logica che comprende un insieme di funzioni di rete composte in modo tale da fornire certe caratteristiche e servizi di rete. Si tratta di un concetto end-to-end; tuttavia poiché lo Slicing della RAN è ancora in discussione in 3GPP nel seguito ci focalizzeremo sulla parte di Core Network delle Network Slice.
Data la capacità del terminale di accedere contemporaneamente a più Network Slice, si è deciso di mettere la gestione della mobilità a fattor comunque di gruppi di Network Slice, come indicato in Figura 3.Ciò introduce un’azione di coordinamento dell’AMF che evita l’invio al terminale di comandi contrastanti.

 

Figura 4 – Network Slicing

Nella 5GC possono essere dispiegati gruppi di AMF (AMF Pool) diversi ciascuno dei quali può gestire un proprio gruppo di Network Slice. Un punto non ancora definito è la modalità di selezione dell Network Slice da parte del terminale. E’ stato stabilito che il terminale, in funzione del servizio o dei servizi di cui vuole usufruire, invii alla rete delle informazioni che verranno utilizzate per effettuare la selezione. Queste informazioni prendono il nome di Network Slice Selection Assistance information (NSSAI). A sua volta il NSSAI risulta costituito da  più Single Network Slice Selection Assistance information (S-NSSAI) e ciascun S-NSSAI da due parametri: un Slice/Service type (SST) che indica la tipologia di Network Slice in termini di caratteristiche e servizi offerti; uno Slice Differentiator (SD) che è una informazione opzionale che può indicare, ad esempio, il tenant della Network Slice. La RAN in base al NSSAI, inviato dal terminale nella segnalazione di AS, sceglie lo AMF Pool. Il punto ancora controverso è come lo AMF Pool poi sceglie la slice: la Figura 2-3 mostra una delle proposte in discussione, dove una AMF (appartenente all’AMF Pool selezionato dalla RAN) interroga (usando come keyword l’NSSAI ricevuto dal terminale nella segnalazione di Non Access Stratum (NAS)) una Network Slice Repository Function che interagisce con i sistemi di O&M e che conosce la topologia di tutta la rete e quindi ha traccia di tutte le slice attive.
Come anticipato nella descrizione dello Slice Differentiator la gestione e il controllo di una Network Slice può essere in larga parte affidata ad una terza parte (ad esempio, una utility, la polizia, ecc.) che abbia un accordo commerciale in tal senso con l’Operatore.
La flessibilità e l’agilità nel dispiegamento e la gestione delle Network Slice deriva dal fatto che l'infrastruttura di rete 5G sfrutterà tecnologie quali Network Function Virtualization (NFV) e Software Defined Networking (SDN) e che le funzioni di rete virtualizzate (VNF) verranno distribuite nei Data Center degli Operatori di Telecomunicazioni. Questo porta ad un altro modo di rappresentare l’architettura della 5GC: accanto ad una rappresentazione tradizionale, con interfacce punto-punto tra gli elementi di rete (Figura 3), ve ne è anche una nuova che va sotto il nome di Service Based Architecture (SBA), presentata in Figura 5.

 

Figura 5 – 5G System Service-based architecture

Onde sgombrare il campo da ogni fraintendimento è bene precisare che si tratta di due rappresentazioni della stessa architettura, non di due architetture diverse. La SBA rende semplicemente conto del fatto che rispetto alle generazioni precedenti le funzioni di rete 5G vengono progettate fin dall’inizio facendo riferimento alle tecnologie IT: ove possibile e vantaggioso ogni elemento della rete 5G offre le proprie funzionalità ad altri elementi di rete sotto forma di micro-servizi; i flussi di segnalazione vengono realizzati da una sequenza di servizi scambiati tra gli elementi della rete. Il vantaggio di questo approccio risiede nella flessibilità: infatti, anziché dover definire interfacce punto-punto e protocolli specifici per ciascuna interazione tra elementi di rete, vengono definiti servizi che potenzialmente possono essere consumati da qualsiasi elemento di rete e che, pertanto, possono essere facilmente riutilizzati in flussi di segnalazione diversi. Ad esempio, un AMF offre lo stesso servizio "Get UE Context" a qualsiasi altro elemento di rete abbia bisogno di ottenere il contesto di uno specifico terminale d’utente, a prescindere dal flusso di segnalazione in cui questo scambio di informazioni è inserito. Come si è detto la 5GC nasce per essere dispiegata nella Cloud. In questo ambiente le VNF hanno un loro ciclo di vita (vengono istanziate e terminate in funzione delle esigenze operative della rete) e per questa ragione è stato introdotto nell’architettura un nuovo elemento funzionale che va sotto il nome di Network Repository Function (NRF). Il ruolo del NRF è quello di tenere traccia di tutte le VNF up and running nella rete: quando una VNF (ad es. un AMF) ha necessità di interagire con un’altra VNF con certe caratteristiche (ad es. un SMF) interroga il NRF per scoprire quali sono le istanze della VNF target attive in quel momento.
Anche se non mostrato esplicitamente in Figura 5 ad ogni VNF o gruppo di VNF è associato una Unstructured Data Storage network Function (UDSF) dove le VNF dopo ogni transazione o gruppo di transazioni possono scaricare i dati relativi allo stato del terminale per poi recuperarli alla transazione successiva. Sebbene in Release 15 i dati relativi allo stato del terminale vengano memorizzati come dati opachi, cioè specifici di ciascun costruttore di apparati di rete, ugualmente si realizza la separazione tra la parte di compute e la parte di storage delle VNF. Il vantaggio di questo approccio risiede nel rendere le VNF stateless tra una transazione e la successiva e pertanto resilienti a possibili guasti: se una VNF dovesse smettere di funzionare una qualsiasi altra VNF dello stesso tipo potrebbe rimpiazzarla semplicemente recuperando i dati relativi allo stato del terminale dalla USDF. Inoltre, in un ambiente virtualizzato la separazione tra compute e storage agevola lo scale in/out delle VNF. Esiste inoltre un altro elemento di storage che prende il nome di Structured Data Storage network function (SDSF) dove le VNF possono memorizzare dati strutturati (secondo un data model da definire in 3GPP) che la Network Exposure Function (NEF) può esporre ad altre VFN, a delle Application Function oppure che possono essere utilizzati per alimentare i Network Data Analytics (NWDA).
Quest’ultimo punto rappresenta una ulteriore innovazione rispetto alle reti delle precedenti generazioni. Infatti nella 5GC le policy che sovrintendono l’allocazione delle risorse e lo steering del traffico possono essere influenzate dai Big Data raccolti nella rete secondo lo schema rappresentato in Figura 6.

 

Figura 6 – Analytics-based policy

Scenari di migrazione e interlavoro tra EPC e 5GC

Alcuni Operatori in Corea e Giappone si sono posti come obiettivo di presentare servizi branded 5G già in occasione dei giochi olimpici del 2018 e del 2020. Questo ha prodotto una forte pressione sul 3GPP che ha deciso di specificare nel 2017, cioè l’utilizzo della 5G New Radio (NR) in Dual Connectivity (DC) come dispiegamento ancillare ad un nodo LTE collegato all’EPC. Ne consegue che nei prossimi anni gli Operatori potranno scegliere percorsi diversi per dispiegare la nuova rete 5G e, quasi sicuramente,  per molto tempo potremo assistere alla presenza contemporanea di varie opzioni di dispiegamento di cui bisogna assicurare la coesistenza. La Figura 7 illustra con le linee tratteggiate il comportamento atteso dei terminali e della rete in uno di questi dispiegamenti eterogenei dove sono presenti sia la EPC sia la 5GC, una RAN pre-Release 15 (in grado di connettersi alla sola EPC) e una RAN di Release 15 (in grado di connettersi alla sola 5GC, oppure sia alla 5GC sia alla EPC), terminali  pre-Release 15 che supportano solo segnalazione EPC NAS (in grado di connettersi alla sola EPC), terminali Release 15 che supportano solo segnalazione EPC NAS (in grado di connettersi alla sola EPC), terminali Release 15 che supportano segnalazione 5GC NAS (in grado di connettersi alla 5GC).
Bisogna comunque ricordare che i terminali Release 15 che supportano la segnalazione 5GC NAS devono, in generale, supportare anche la segnalazione EPC NAS per potersi connettere alla EPC laddove la connettività alla 5GC non sia disponibile ad esempio per mancanza di copertura radio 5G oppure in scenari di roaming.

 

Figura 7 – Architettura per uno scenario di migrazione da EPC a 5GC

La coesistenza di EPC e 5GC determina l’opportunità di prevedere un interlavoro tra le due Core Network per terminali che supportano sia 5GC NAS ed EPC NAS. A tale proposito sono in corso di definizione in 3GPP delle procedure opzionali di mobilità tra EPC e 5GC che si basano su:

  • un database comune per i dati di sottoscrizione e profilo degli utenti (HSS + UDM in Figura 7);
  • una interfaccia Nx tra MME e AMF per la sincronizzazione dei contesti di Mobility Management (MM) e Session Management (SM) tra le due Core Network;
  • un gateway condiviso (PGW + SMF + UPF) che rappresenta l’ancora per le sessioni dati d’utente (non rappresentato in Figura 7).

L’interfaccia Nx, quando presente, garantisce una mobilità seamless tra EPC e 5GC in entrambe le direzioni.

 

Evoluzione della Core Network 5G

La prima fase (Relelase 15 3GPP) della standardizzazione della 5GC garantisce la definizione di un ambiente cloud ready, automatizzato e nel quale differenti applicazioni di rete possono essere segregate in aree dedicate della rete grazie allo slicing. Alcune applicazioni verticali saranno già dispiegabili nella prima fase come alcune applicazioni di Public Safety (ad es. Mission Critical Push To Talk), il monitoring ed il controllo di apparati industriali, applicazioni basate su IMS, ecc.. La seconda fase della standardizzazione (Release 16 3GPP) estenderà notevolmente le capacità del sistema ampliando l‘applicabilità della tecnologia 5G a molteplici settori industriali. Di seguito saranno indicate le estensioni di funzionalità attualmente previste per la seconda fase della standardizzazione.
I sistemi mobili che precedono il 5G forniscono già un supporto iniziale ai paradigmi di servizio dell’IoT con tecnologie come il NB-IoT. Nella seconda fase di standardizzazione degli abilitatori tecnologici per il 5G, il supporto dell’IoT sarà esteso fino ad utilizzi massivi della rete. Il massive IoT (mIoT) sarà capace di supportare alcune centinaia di migliaia di dispositivi IoT per chilometro quadrato. I dispositivi IoT, inoltre, saranno capaci di comunicare tra di loro e con la rete con modalità molto differenti ed utilizzando i media più variegati.
E’ evidente quindi che gli impatti attesi in CN per l’estensione al mIoT siano significativi. La 5GC che supporterà mIoT dovrà supportare modelli di segnalazione estremamente semplificati, per ridurre i consumo delle batterie dei dispositivi IoT, ed allo stesso tempo comunicazioni con consumo intensivo di banda, come ad esempio flussi video.
In un ambiente che prevede l’esistenza di un così alto numero di dispositivi IoT è necessario abilitare modelli cosiddetti di “bulk operation” grazie ai quali la rete può controllare contemporaneamente un gruppo di dispositivi limitando al massimo l’utilizzo di risorse come ad esempio risorse di comunicazione e d’indirizzamento (identificatori di rete). Inoltre dovrà essere possibile configurare in modalità “bulk” gruppi interi di dispositivi IoT.
Nell’ambito più esteso dell’mIoT sarà necessario prevedere anche una gestione differenziata della mobilità. Per dispositivi stazionari dovrà essere possibile disabilitare quasi completamente la mobilità, mentre potranno esistere dispositivi per i quali sarà consentita solo una mobilità restretta (ad esempio nel caso di dispositivi IoT in ambito domestico). Esisteranno invece dispositivi montati a bordo di mezzi in movimento che potrebbero avere bisogno di una gestione della mobilità discreta o addirittura continua. Ciò evidenzia la necessità di implementare nella 5GC dei modelli di abilitazione e controllo selettivo degli schemi di mobilità consentiti per un dispositivo o un gruppo di dispositivi IoT.
Un’altra caratteristica saliente del mIoT è rappresentata dai modelli di comunicazione che saranno utilizzati. Infatti a differenza degli attuali abilitatori IoT (NB-IoT), dove la comunicazione avviene prevalentemente tra il dispositivo e la rete, il 5G abiliterà modelli sempre più estensivi. Infatti un dispositivo IoT potrà raggiungere la rete da più reti d’accesso contemporaneamente. Inoltre sarà possibile comunicare tra dispositivi IoT utilizzando il transito su altri dispositivi (denominati Relay), concatenando nella stessa comunicazione più reti d’accesso allo stesso tempo. Sarà anche possibile una comunicazione diretta tra dispositivi IoT previa l’autorizzazione da parte della rete. La 5GC quindi non potrà più essere considerata una semplice rete di controllo degli accessi a pacchetto mobili, ma dovrà interagire con gli accessi più disparati, implementando anche le funzionalità di autorizzazione necessarie per abilitare tutte le forme di comunicazione richieste.
Uno degli abilitatori tecnologici più significativi del 5G è costituito dal supporto di Ultra Reliable Low Latency Communication (URLLC) ovvero la possibilità di garantire la comunicazione tra due dispositivi con ritardi di pochissimi millisecondi e con un’affidabilità che garantisca livelli di error rate nella comunicazione pari a 10-9.
Tale modello di comunicazione può trovare applicazione in una molteplicità di applicazioni come ad esempio: 3D video rendering e realtà aumentata, controllo remoto (robotica remota, chirurgia remota, internet tattile), automazione wireless delle catene produttive, supporto all’efficienza e sicurezza del traffico veicolare, mobile gaming, ecc.
L’’implementazione in rete di queste applicazioni richiedere una serie di prestazioni che impattano prevalentemente la rete d’accesso, ma anche la 5GC è impattata sia in termini funzionali che architetturali. Le principali innovazioni attese nella CN per supportare le URLLC sono:

  • Un Session Management rinnovato che contenga le ottimizzazioni necessarie a favorire tempi di commutazione estremamente ridotti all’ordine delle centinaia di microsecondi;
  • Una connettività multi-punto tra le funzionalità di rete che aumenti il livello di affidabilità della comunicazione;
  • L’applicazione di criteri di edge computing per il dispiegamento in rete delle funzionalità di CN per ridurre i ritardi indotti dall’attraversamento della rete.
  • Ricorso significativo alla comunicazione device-to-device e conseguente abilitazione delle necessarie funzionalità di CN.

Tra i segmenti verticali che sarà indirizzato maggiormente dalle tecnologie 5G vi è sicuramente il settore veicolare, la cui standardizzazione è già iniziata con le reti 4G. L’estensione delle prestazioni di Vehicle-to-Everything (V2X) nel 5G comprenderà un insieme di funzionalità che avranno un impatto anche sulla 5GC.
Le principali innovazioni introdotte sono finalizzate al controllo parziale o totale di veicoli in movimento, al miglioramento dell’infotainment a bordo del veicolo ed alla definizione di hot spot a bordo dei veicoli per finalità consumer e business. In particolare le innovazioni per il controllo veicolare abiliteranno il platooning (ovvero la guida di un gruppo di veicoli che si muovono insieme), l’advanced ed il remote driving (ovvero la guida parziale o completa del veicolo con controllo locale o remoto) e la possibilità di coordinare sensori di differente natura (ad esempio Road Side Unit, flussi video, dispositivi a bordo di altri veicoli o di altri pedoni) per garantire un insieme più ricco di informazioni.  
Tra gli impatti più rilevanti che sono previsti per la 5GC, vi è il supporto di prestazioni che riducano al minimo i tempi di ritardo della trasmissione nella rete. Infatti scenari come il platooning richiedono una stima precisa delle distanze tra i veicoli, mentre scenari di remote driving richiedono ritardi massimi di 5 ms tra l’Application Server ed il veicolo. Ciò comporta necessariamente che la CN sia alleggerita di funzionalità e dislocata nella periferia della rete per favorire ritardi minimi di trasmissione. Inoltre per le stesse ragioni anche la correlazione dei sensori locali dovrà essere effettuata nella periferia della rete. Come per alcune applicazioni ULLRC, anche le applicazioni V2X evidenziano non solo impatti funzionali sulla 5GC, ma anche una nuova filosofia di dispiegamento della CN che non sarà più centralizzata, ma in molti casi avrà delle funzionalità UPF e di controllo del servizio dispiegate molto vicino all’accesso.
Tra le applicazioni che troveranno maggiore applicazione in ambito 5G vi sono sicuramente quelle di Public Safety (PS). I sistemi che anticipano il 5G hanno già previsto l’adozione di architetture e funzionalità specifiche per le comunicazioni Mission Critical di voce, video e dati. In un ambiente nativo 5G tutti gli abilitatori previsti possono concorrere alla realizzazione di modelli di servizio sempre più complessi.
Infatti lo slicing potrà garantire una segregazione delle componenti di CN che dovranno essere dedicate a servizi di PS. L’utilizzo di reti molto dense potrà estendere le comunicazioni per applicazioni di tipo Mission Critical (per esempio in caso di mobilità e di riservazione delle risorse). La presenza di molti sensori che potranno interagire con gli operatori di pubblica sicurezza sul campo richiederanno in CN il controllo e la correlazione di tutte le forme di comunicazione.
I sistemi mobili che precedono il 5G prevedono già alcune prestazioni di broadcast e multicast come ad esempio Public Warning System (PWS), evolved Multimedia Broadcast Multicast Service (eMBMS) e Group Communication System Enablers (GCSE). Tali prestazioni possono supportare nella EPC applicazioni consumer, business e Mission Critical.
Nella 5GC si prevede un’evoluzione di queste prestazioni che potranno supportare comunicazione 1 a N non solo grazie a meccanismi di broadcast e multicast implementati nella CN, ma anche grazie a soluzioni native delle reti d’accesso.
I concetti già esistenti all’interno delle prestazioni di broadcast e multicast della EPC saranno estesi. Ad esempio la definizione dei gruppi sarà arricchita con la possibilità di considerare anche la distribuzione geografica dei gruppi stessi abilitando nuovi modelli di servizio.
Inoltre le prestazioni di broadcast e multicast dovranno essere in grado di interagire con i servizi di rete specifici del 5G come ad esempio Mission Critical (PTT, Video e Dati), Critical Communications e massive IoT.
L’estensione della copertura del 5G al maggior numero di casi possibili tocca il suo estremo con l’ipotesi di includere nella fase due della standardizzazione l’attestazione di accessi satellitari alla 5GC. La principale finalità di un accesso satellitare al sistema 5G è l’estensione dei servizi 5G anche ad utenti e dispositivi in movimento su aerei, navi e treni.
In questo contesto le principali sfide tecniche che dovranno essere affrontate sono associate al disegno di una procedura efficiente di riselezione della rete che possa garantire quanto più possibile, ad un gruppo di dispositivi, la continuità tra un accesso terrestre ed uno satellitare. Inoltre nel tentativo di garantire l’accesso ad utenti e dispositivi che viaggiano a bordo di un aereo, dovranno essere definite specializzazioni delle procedure di Mobility Management per garantire il tracciamento ed il paging.
Quando descritto finora evidenzia che la 5GC non potrà più esercitare il controllo di una sola parte della rete d’accesso (ovvero degli accessi mobili), ma dovrà essere disegnata in modo Access Neutral. Ciò pone delle sfide molto severe alla nuova 5GC in quanto sarà necessario definire interfacce e procedure che tengano conto delle specificità di ciascun accesso. Esistono infatti accessi trusted (ovvero gestiti dall’operatore) ed untrusted sui quali dovranno essere garantiti requisiti di comunicazione contemporanea, di nomadicità o mobilità e di continuità del servizio.
Nella nuova 5GC tali requisiti di Access Neutrality richiederanno:

  • L’adozione di meccanismi di discovery da parte del dispositivo delle reti d’accesso utili per l’erogazione di una categoria di servizi;
  • La conseguente configurazione dei dispositivi d’utente curando la possibile coesistenza tra differenti configurazioni per ciascun accesso usato dal dispositivo;
  • L’armonizzazione di differenti modelli di riconoscimento (autenticazione) del terminale in rete;
  • L’omogeneizzazione delle soluzioni di indirizzamento dei dispositivi. Partendo dall’indirizzamento IP fino all’indirizzamento dell’utente che utilizza lo specifico dispositivo.
  • La distribuzione efficace delle policy che i dispositivi dovranno rispettare per l’erogazione dei servizi. Sarà infatti possibile che alcune famiglie di servizi siano erogabili solo sotto alcune reti d’accesso o per ragioni di prestazioni o per volontà dell’operatore di rete.
  • Il controllo della qualità considerando che vi sono accessi che definiscono esplicitamente il concetto di “bearer” ed altri che non lo prevedono.
  • Uniformazione dei modelli di documentazione delle componenti di traffico sui singoli accessi.
  • Ridefinizione del controllo della mobilità abilitando restrizioni totali, parziali (solo in alcune zone) o sulla tipologia della mobilità (discreta o continua).
  • Rivisitazione delle funzionalità che abilitano la continuità del servizio laddove sarà richiesto.
 

Conclusioni

Le esigenze di introdurre nel mondo telco di tecnologie già consolidate in altri ambiti tecnologici di natura IT (ad esempio virtualizzazione, cloud) e quelle di servire su un’unica piattaforma di CN quanti più servizi con requisiti molto differenti (Verticals) trovano la massima sintesi nella tecnologia 5G. La 5GC parte infatti dall’adozione di tecnologie virtualizzate e cloud per fornire supporto ad una miriade di potenziali applicazioni.
La complessità della suddetta sintesi è affrontata negli enti di standardizzazione mediante un approccio a fasi che garantisce in due rilasci di specifiche una piattaforma potenzialmente capace di ospitare tutti i Verticals che finora appaiono di interesse. La complessità si rifletterà anche nelle fasi di dispiegamento dove, a differenza da oggi, saranno necessarie istanze della 5GC anche nella estrema periferia della rete e dove differenti “slice” della CN potranno avere cicli di vita differenti. Ne consegue che anche l’orchestrazione e la gestione della complessità di queste reti virtualizzate rappresenterà una sfida che dovrà essere affrontata.
L’estrema flessibilità di questa piattaforma apre infatti la porta a nuove opportunità e modelli di servizio. Infatti l’approccio nativamente IT implicherà una naturale esposizione di servizi e dati che potranno essere utilizzate dall’operatore o da terzi per la creazione di nuovi servizi.

 

Bibliografia

  1. 3GPP TR 23.799: "Study on Architecture for Next Generation System" Rel-14
  2. 3GPP TS 23.501: “System Architecture for the 5G System” Rel-15
  3. 3GPP TS 23.502: “Procedures for the 5G System” Rel-15
  4. 3GPP TS 23.214: “Architecture enhancements for control and user plane separation of EPC nodes” Rel-14
 

comments powered by Disqus