5G: focus su N3IWF, TNGF, TWIF e W-5GAN

Versione di riferimento 15 del 3GPP: Architettura 5G Standalone e interfacce UE

La Figura 1 riporta il ben noto schema basato sui servizi di una rete 5G come estratta da [1].

Figura 1: Architettura 5G basata su servizi non di roaming – rel 15 [1]

Ogni blocco funzionale è interconnesso con gli altri tramite una specifica interfaccia, chiamata punto di riferimento, che è realizzata da una specifica pila di protocolli. Nella parte superiore dell’architettura (northbound) abbiamo le NF del piano di controllo, che sono collegate tramite punti di riferimento N1, N2 e N4 alle NF verso il basso coinvolte nella gestione del traffico degli utenti (data plane o User Plane – UP -). Concentrandosi sul piano dati, il traffico tra l’apparecchiatura utente (UE) e la rete dati (DN) passa attraverso la RAN e uno o più UPF. Tra UE e RAN si può ipotizzare normalmente l’utilizzo della New Radio Air Interface (NR-Uu), mentre tra RAN e UPF viene definito il punto di riferimento N3, abilitato tramite tunnel GTP-U. In caso di passaggio attraverso più UPF, queste vengono collegate tramite il punto di riferimento N9 (che è simile a N3) e infine tramite il punto di riferimento N6 al DN (cioè Internet).

Se si semplifica la rete 5G considerando solo le funzioni e le interfacce in ottica UE, ipotizzando un’unica UPF e un singolo gNB per RAN (senza alcuna suddivisione CU/DU), si ottiene l’architettura mostrata in Figura 2. N1 è l’interfaccia del piano di controllo con AMF/SMF, i cui messaggi vengono consegnati tramite le interfacce NR-Uu e N2 attraverso il gNB. N3 fornisce i dati utente all’UPF e quindi al DN tramite N6.

Figura 2: Punto di vista UE – piano di controllo e piano utente

Come riferimento, riportiamo per completezza l’intera pila di protocolli per queste interfacce con l’identificazione dei protocolli in uso (anche se grazie alla flessibilità del 5G possono essere impiegate diverse opzioni e diversi protocolli a diversi livelli a seconda della configurazione). In primo luogo, il piano di controllo interfaccia la pila protocollare con N1 che invia messaggi di controllo (inclusa l’autenticazione) tra UE e AMF (e, a seconda del tipo di messaggio, fino a SMF), tramite NR-Uu (interfaccia aerea) e interfaccia N2. NG Application Protocol (NG-AP) viene utilizzato in N2 per trasportare la segnalazione N1 Non-Access-Stratum (NAS).

Figura 3: Pila di protocolli N1 e N2 (piano di controllo)

Successivamente, viene segnalata la pila protocollare delle interfacce del piano utente, presupponendo la consegna delle PDU dell’applicazione utente tra UE e UPF utilizzando IP e con TCP o UDP come protocollo di trasporto. Al posto dell’IP (IPv4 o IPv6), è possibile utilizzare in alternativa anche Ethernet e PDU non strutturate. Si noti che N6 corrisponde in tutti i casi alla classica pila TCP/IP di Internet.

Figura 4: Pile protocollari N3 e N6 (piano utente)

Accesso non-3GPP untrusted: N3IWF

Nella versione 15 del 5G 3GPP [1], viene descritto il supporto per l’accesso non-3GPP alla Core Network (ovvero evitando la parte RAN e utilizzando altri tipi di accesso), definendo la funzione di rete Non-3GPP Inter-Working Function (N3IWF). Più specificamente, viene preso in considerazione l’accesso Wi-Fi (802.11) non attendibile (untrusted), poiché la grande maggioranza delle UE dispone sia di un’interfaccia radio 3GPP che di un’interfaccia Wi-Fi. N3IWF si occupa di “adattare” i protocolli di accesso e autenticazione della sezione WiFi non-3GPP verso il CN 5G, interfacciandosi con il CN con lo stesso ruolo della RAN (ovvero abilitando N2 e N3).

Untrusted si riferisce al fatto che si presume che l’accesso non 3GPP (cioè l’Access Point WiFi) non sia gestito dallo stesso operatore della rete 5G: ad esempio un hotspot in un aeroporto o un router Wi-Fi domestico privato. Per questo motivo deve essere stabilita un’associazione di sicurezza da estremo a estremo tra l’UE e N3IWF, indipendentemente da quella stabilita nell’accesso al livello 2 (cioè WPA2).

Si noti che l’accesso non attendibile non 3GPP era già disponibile nelle reti LTE, tramite la componente ePDG definita durante l’evoluzione delle reti 4G, utilizzando un approccio diverso per quanto riguarda il 5G e risultando in qualche modo di applicabilità limitata nelle reti reali. L’obiettivo del 3GPP è quello di definire per il 5G, fin dall’inizio, un meccanismo di accesso non-3GPP interoperabile, semplice e affidabile che molto probabilmente sarà adottato su scala più ampia. L’architettura risultante è mostrata in Figura 5, con l’UE che può abilitare contemporaneamente l’accesso NR-Uu tramite gNB, oppure avere il WiFi come metodo di accesso unico. In entrambi i casi, sono sempre necessarie le credenziali 3GPP per avviare l’accesso (ad esempio, USIM/eUICC).

Figura 5: Architettura N3IWF

N3IWF fornisce principalmente un gateway sicuro alla rete 5G dell’operatore per l’accesso non 3GPP. L’interfaccia NWu tra UE e N3IWF è basata su IPSec/IKE per stabilire un tunnel sicuro, bypassando i meccanismi di sicurezza applicati dall’Access Point (se presenti). Poiché si prevede che l’UE comunichi con AMF tramite l’interfaccia NAS, N3IWF dispone di un’interfaccia N2 che si connette con AMF per abilitare N1. Quindi, l’interfaccia N3 per interagire con UPF è inclusa anche in N3IWF.

N3IWF è responsabile della configurazione della connessione IPSec che deve essere utilizzata dal traffico del piano di controllo diretto ad AMF/SMF, nonché del traffico diretto all’UPF per il piano utente. Di conseguenza, l’UE e N3IWF devono instaurare due Associazioni di Sicurezza IPSec (SA):

• Segnalazione (piano di controllo) IPSec SA – trasporta i messaggi NAS destinati ad AMF
• Piano utente IPSec SA – trasporta i pacchetti destinati al DN

Nella prima fase delle operazioni di accesso, UE e N3IWF devono stabilire il principale sistema di segnalazione IPSec SA, utilizzando il protocollo IKE che consente di supportare la registrazione EAP dell’UE nel sistema 5G, in modo analogo e con gli stessi requisiti di sicurezza dell’accesso 3GPP. La Figura 6 presenta la pila protocollare del piano di controllo utilizzato per stabilire il tunnel IPSec di segnalazione.

Figura 6: Pila protocollare N3IWF prima della creazione di SA – piano di controllo

Quando viene stabilita l’associazione di protezione IPSec di segnalazione, il tunnel IPSec (ovvero l’ESP in modalità tunnel) è in grado di inviare messaggi EAP-5G, utilizzati per incapsulare i messaggi NAS tra UE e N3IWF. La specifica 3GPP indica che EAP-5G è identificato da un’intestazione di estensione EAP specifica “Tipo espanso” (0xFE) con valori specificati per “ID fornitore” e “Tipo di fornitore”. In questa fase, l’UE può comunicare con AMF per eseguire la segnalazione NAS da estremo a estremo come illustrato nella Figura 7, come farebbe normalmente tramite RAN. Si noti che il livello IPsec include anche l’intestazione “Inner IP”, necessaria per stabilire il tunnel IPSec.

Figura 7: Stack del protocollo N3IWF dopo l’istituzione di SA – piano di controllo

Una volta che l’UE è registrato nel sistema 5G e abilita la sua interfaccia N1/NAS, può negoziare l’istituzione della sessione PDU che si traduce nella creazione di un figlio IPSec SA (chiamato piano utente IPSec SA) per comunicare con le reti dati (DN). La pila protocollare del piano utente risultante è illustrata nella Figura 8. Il protocollo GRE (Generic Routing Encapsulation) viene utilizzato per trasportare la PDU (IP) dell’utente tra l’UE e N3IWF. Il GRE consente in particolare di applicare un modello QoS basato sul flusso come specificato nel TS 23.501, che trasporta QFI (QoS Flow Identifier) e QRI (QoS Reflective Identifier) associati ai pacchetti di dati dell’utente come definito dalle specifiche 3GPP. GRE supporta anche gli altri tipi di PDU previsti (ad esempio, Ethernet). Anche il tunnel IPSec del piano utente include un’intestazione “Inner IP”.

L’adattamento della WLAN per accedere a una rete 3GPP richiede quindi un sovraccarico relativamente più elevato per quanto riguarda l’uso diretto della stessa tecnologia da parte dell’UE: 2 livelli IP indipendenti, più 1 intestazione GRE più 1 intestazione IPSec con intestazione IP interna (per ESP in modalità tunnel) invece di una singola intestazione IP.

Figura 8: Stack di protocollo N3IWF dopo l’istituzione di SA – piano utente

Si noti che le attuali realizzazioni delle reti 5G si basano sulla versione 15 e su una configurazione della Core Network ereditata da LTE (cioè Non-Stand-Alone, NSA), quindi l’N3IWF non è normalmente disponibile né nella rete core né disponibile nei COTS UE.

Trusted non-3GPP access

A partire dalla versione 16 del 3GPP [2], vengono definiti ulteriori meccanismi di accesso non-3GPP, e nello specifico “trusted”. Trusted significa che l’operatore della 5G Core Network si occupa anche del funzionamento e della gestione dell’accesso non-3GPP che, oltre al WiFi, viene esteso anche all’accesso fisso terrestre. Questi aggiornamenti nella versione 16 consentono 4 nuovi scenari:

Scenario 1

Dispositivi mobili 5G UE in grado di registrarsi, accedere alla rete principale e fruire dei servizi sia tramite accesso 3GPP New Radio che WiFi affidabile. Questo è simile a quanto già consentito da N3IWF con la differenza che i punti di accesso WiFi sono coordinati e sotto il controllo dello stesso operatore di rete 5G (anche in termini di QoS). Questo scenario può essere denominato Mobile Wireless Access (MWA).

Scenario 2

Dispositivi mobili UE che non supportano le funzionalità 5G (ad esempio, protocollo NAS per N1 e NR-Uu) ma dispongono di credenziali 3GPP (USIM/EUICC), che accedono esclusivamente al CN tramite un WiFi affidabile.

Scenario 3

Dispositivi fissi 5G UE, denominati 5G Residential Gateway (5G-RG) che combinano l’accesso 3GPP NR con l’accesso fisso (sono disponibili specifiche per DOCSIS e altre sono in fase di definizione) allo stesso CN. Questo scenario è denominato Fixed Wireless Access (FWA).

Scenario 4

Dispositivi UE fissi, denominati Fixed Network Residential Gateway (FN-RG), che non supportano le funzionalità 5G ma dispongono di credenziali 3GPP, accedono esclusivamente al CN tramite rete fissa (i.e., DOCSIS o Modem fisso a banda larga).

L’accesso fisso non attendibile non è di interesse pratico, quindi non è affatto considerato.

In tutti i casi sopra descritti, la differenza fondamentale per quanto riguarda l’accesso WiFi Untrusted (ad esempio, N3IWF) è che la sicurezza può essere abilitata direttamente su livelli di accesso non 3GPP, come IEEE 802.11, e non come parte dell’istituzione IKEv2. Ciononostante, si è deciso di mantenere la stessa pila di protocolli UE, con l’utilizzo di IPSec “VPN” ma senza crittografia (NULL): questo permette di sviluppare nell’UE la stessa pila di protocolli indipendentemente dall’accesso “trusted” o “non trusted”.

In tutti questi nuovi 4 scenari, viene introdotto un componente di accesso/gateway dedicato (logicamente equivalente a N3IWF), necessario per abilitare le interfacce N2 e N3 in direzione nord necessarie per integrare il terminale utente all’interno del CN. Oltre a ciò, esiste una differenza significativa per gli scenari 2) e 4): l’interfaccia N1 deve essere terminata e gestita dalla funzione gateway, che diventa quindi a tutti gli effetti un 5G UE per conto dell’utente finale.

Nei 4 diversi scenari, le funzioni di accesso hanno un nome diverso e sono descritte di seguito. Una volta realizzato un accesso non 3GPP in un CN 5G, se è disponibile anche l’accesso 3GPP, è possibile abilitare anche l’opzione ATSSS per l’indirizzamento, la commutazione e la ripartizione del traffico.

Accesso wireless: TNGF

Nel primo scenario di WiFi attendibile, la funzione di accesso è denominata Trusted Non-3GPP Access Network (TNAN). La TNAN è suddivisa in due parti, la funzione TNAP (Trusted Non-3GPP Access Point Function) e la funzione TNGF (Trusted Non-3GPP Gateway Function), come mostrato in Figura 9. Si noti che una configurazione simile per l’accesso attendibile WiFi non 3GPP è stata definita anche per le reti LTE, utilizzando invece rispettivamente i componenti Trusted WLAN Access Network (TWAN) e Trusted WLAN Access Gateway (TWAG). In TNAN, Ta rappresenta l’interfaccia tra il punto di accesso attendibile e il TNGF, all’interno della CN. Nella versione 16 non ci sono indicazioni su come un AP possa essere considerato affidabile (quindi “promosso” a TNAP) e quali associazioni di fiducia e interfacce aggiuntive con il CN sono necessarie (ad esempio, un protocollo EAP-5G modificato, interfacce con AAA, ecc.).

Figura 9: Scenario 1 dell’architettura TNAN (TNGF)

Dal punto di vista della pila protocollare, TNGF è in pratica equivalente a N3IWF, con l’eccezione dell’utilizzo di un tunnel IPSec senza crittografia (abbassando il carico della CPU UE), mentre vengono applicati meccanismi di sicurezza WLAN di livello inferiore. Ad esempio, la pila protocollare del Piano Utente è riportata in Figura 10. In questo scenario, l’UE può ovviamente accedere alla CN anche tramite 3GPP.

Figura 10: Pila protocollare del piano utente TNGF

Accesso Wireless: TWIF

Come specificato in [2] per lo scenario 2, gli UE che non supportano la segnalazione NAS CN 5G su WLAN (N1) sono denominati “Non-5G-Capable over WLAN” o N5CW. Anche se un N5CW UE potrebbe non supportare il punto di riferimento N1, tuttavia, potrebbe essere in grado di funzionare come 5G UE con l’introduzione di una funzione gateway dedicata. Il ruolo di TNGF è quindi sostituito dalla Trusted WLAN Interworking Function (TWIF), con la differenza principale che TWIF termina l’interfaccia NAS N1 e si comporta come un UE+RAN “fuso” 5G per quanto riguarda la rete principale.

Figura 11: Scenario 2 dell’architettura TNAN (TWIF)

In questo caso non abbiamo interfacce equivalenti NWu/NWt, poiché l’autenticazione viene effettuata individualmente su Yt’ e Yw (indicato in Figura 12 da una procedura EAP generica). Il TNAP trasmetterà le credenziali di autenticazione a TWIF, che supporterà l’autenticazione 3GPP e abiliterà la segnalazione NAS con il CN per conto del N5CW UE.

Come conseguenza di come sono definiti, gli N5CW non supportano l’accesso 3GPP tramite New Radio e non sono compatibili con il 5G; pertanto, la WLAN può essere considerata il metodo di accesso esclusivo alla CN. Tuttavia, si presume che l’associazione di sicurezza sia basata su credenziali 3GPP (ad esempio, USIM). Poiché è probabile che un terminale N5GW non disponga di tali credenziali, devono essere presi in considerazione metodi alternativi, anche se non ancora definiti dal 3GPP (questo dovrebbe essere affrontato nella versione 17).

Figura 12: Pila protocollare del piano di controllo TWIF

Accesso fisso alla linea fissa: 5G-RG W-AGF

A partire dalla versione 16 sono state definite altre tipologie di accesso diverse dal WiFi, con particolare riferimento all’accesso fisso rappresentato dai modem domestici a banda larga (come DOCSIS – Internet via Cable – diffuso negli USA). Lo stesso approccio in linea di principio potrebbe essere esteso ad altre tecnologie di accesso fisso, comprese quelle basate su satellite, ed è oggetto di ulteriori discussioni nella versione 17. In questo terzo scenario viene definita una nuova funzione di gateway Wireline 5G Access network (W-5GAN) nel CN. W-5GAN include la funzione Wireline Access Gateway (W-AGF), che è equivalente a TNGF per quanto riguarda le sue funzionalità e le interfacce/relazioni con il CN. W-AGF fa parte dell’infrastruttura ISP di base di rete fissa ed è collegato al CN abilitando le interfacce N2/N3. Il 5G-RG può accedere anche tramite 3GPP alla rete principale, come per il primo scenario (cioè un modem DSL con accesso 3GPP NR-Uu).

Figura 13: Scenario 3 dell’architettura W-5GAN

Si noti che un 5G-RG potrebbe avere solo accesso 3GPP: in tal caso diventa un UE standard nell’architettura 5G e non richiede funzioni di gateway di adattamento.

Accesso fisso su linea cablata: FN-RG W-AGF

Infine, per l’accesso fisso senza supporto 3GPP N1/NAS, viene definita un’architettura simile per quanto riguarda lo scenario 3, con N1 gestito dal W-AGF per conto di FN-RG in modo tale che sia stato eseguito dal TWIF.

Figura 14: Scenario 4 dell’architettura W-5GAN

Possibili implementazioni di W-5GAN

Nel caso di modem che utilizzano DOCSIS, l’elemento W-5GAN è definito in [3] e rinominato W-5GCAN (dove viene aggiunta una “C” per indicare Cavo). Le funzioni W-5GAN vengono eseguite tramite la rete di accesso cablata DOCSIS (AN) dalle funzioni W-AGF suddivise in piano utente e piano di controllo.

In relazione allo scenario 3 il dispositivo presso la sede dell’utente viene chiamato 5G Cable Residential Gateway, o 5G-CRG e viene proposta l’architettura mostrata in Figura 15 (estratta direttamente da [3]).

 

Figura 15: Architettura di integrazione di Cable Labs per i gateway residenziali via cavo 5G [3]

In relazione allo scenario 4, il dispositivo finale presso la sede dell’utente è chiamato invece Fixed Network-Cable Residential Gateway (FN-CRG), e la differenza con l’architettura precedente risiede sostanzialmente nella gestione di N1 all’interno del blocco W-AGF-CP direttamente.

Figura 16: Architettura di integrazione di Cable Labs per gateway residenziali fissi “solo cavo” [3]

Nel caso in cui invece si tratti di dispositivi a banda larga conformi alle specifiche del Broadband Forum (BBF) [4], la convergenza 5G è descritta in [5], sia per il 5G-RG (con accesso 3GPP NR) che per l’FN-RG (senza accesso 3GPP NR), introducendo la specifica dell’Access Gateway Function (AGF), ovvero la Wireline Access Gateway Function W-AGF menzionata nelle specifiche 3GPP. Le architetture convergenti complessive possibili, come estratte da [6] sono mostrate in Figura 17. La prima architettura rappresenta un dispositivo domestico solo 3GPP (cioè un UE); la seconda architettura può essere allineata con lo scenario 3 descritto in precedenza. La terza architettura è associata allo scenario 4.

In alternativa all’accesso mediato da AGF, un altro meccanismo di accesso è definito da BBF per i dispositivi della precedente generazione (cioè, non consapevoli del 5G), in cui sono definiti un Broadband Network Gateway (BNG) e una Fixed Mobile Interworking Function (FMIF). BBF prevede anche un by-pass diretto della rete centrale che accede direttamente alla DN tramite il BNG. Queste sono le architetture 4 e 5 in Figura 17, al momento non descritte nelle specifiche 3GPP. Si prega di notare che le specifiche delle funzioni BNG e FMIF sono ancora in fase di finalizzazione.

Figura 17: Scenari di convergenza 5G fisso-mobile [6]

Conclusione

L’accesso a una rete 5G e ai servizi di qualità garantita associati tramite un accesso non 3GPP apre alla definizione di nuovi servizi a valore aggiunto estesi a un gruppo più ampio di dispositivi e casi d’uso degli utenti finali. Al momento sono state definite le specifiche Wi-Fi/WLAN e via cavo, e ulteriori estensioni potranno essere proposte nelle future versioni del 5G, con particolare riferimento all’accesso non 3GPP basato su satellite. Il satellite potrebbe in particolare consentire applicazioni transfrontaliere ad ampia copertura e mobilità, in cui l’accesso satellitare può essere utilizzato come collegamento complementare (failover, ridondanza e resilienza) o come collegamento supplementare sfruttando la sua natura di trasmissione (più adatto per i servizi IPTV in diretta). Una volta stabilito l’accesso sia 3GPP che non-3GPP alla CN, è possibile applicare strategie di accesso multiplo nella nuova versione 16 ATSSS (Access Traffic Steering, Switching and Splitting).

Riferimenti

[1] System Architecture for the 5G System (3GPP TS 23.501 version 15.3.0 Release 15)
[2] System Architecture for the 5G System (3GPP TS 23.501 version 16.6.0 Release 16)
[3] 5G Wireless Wireline Converged Core Architecture Technical Report WR-TR-5WWC-ARCH-V01-190820 Cable Labs, 2019
[4] BBF TR-124 issue 5: “Functional Requirements for Broadband Residential Gateway Devices”
[5] BBF TR-456 issue 1 “AGF Functional Requirements”, Aug. 2020
[6] TIM, NotiziarioTecnico, “5G Network convergence and orchestration initiatives by BBF, ONF, LF EDGE, TM FORUM and ETSI”, 2019.

 

© RomARS – Francesco Zampognaro