ATSSS nelle reti 5G

ATSSS

Partendo dalle specifiche 3GPP 5G versione 15, è stato proposto di abilitare un accesso opzionale non-3GPP alla Core Network (CN), alternativo a quello 3GPP. L’accesso 3GPP si riferisce all’interfaccia nominale UU New Radio (NR-Uu) con la RAN di una rete 5G; l’accesso non 3GPP apre invece alla possibilità di collegare un UE al CN 5G tramite diverse tecnologie di accesso, e in particolare WiFi (WLAN). Per ulteriori dettagli sulle possibili configurazioni di accesso non 3GPP, si prega di fare riferimento al nostro articolo dedicato su N3IWF, TNGF, TWIF and W-AGF.

Una volta che in una rete 5G l’accesso opzionale non-3GPP è abilitato, è possibile accedere ai servizi nativi 5G utilizzando esclusivamente l’accesso non 3GPP (ad esempio, un punto di accesso WiFi pubblico in aeroporto). D’altra parte, a partire dalla versione 16 [1], è possibile anche abilitare la funzione opzionale denominata Access Traffic Steering-Switching-Splitting (ATSSS), in cui vengono utilizzati contemporaneamente sia l’accesso 3GPP che l’accesso non 3GPP. In ATSSS, “steering” si riferisce alla possibilità di selezionare per il traffico del piano utente, in base al servizio (tipo QoS per un flusso di dati), il miglior collegamento da utilizzare, ‘switching’ descrive la possibilità di effettuare l’handover senza interruzione del servizio verso l’altro collegamento quando necessario, “splitting” indica l’utilizzo simultaneo (bonding) dei due collegamenti.

ATSSS può essere abilitato in particolare nella configurazione “untrusted” (N3IWF) e in alcuni degli scenari “trusted” (TNGF e W-AGF) di accesso non-3GPP. A titolo di esempio, nella Figura 1 è riportata un’architettura semplificata del piano utente che mostra un UE con WiFi e NR che accede alla stessa CN attraverso una CN abilitata all’ATSSS.

Figura 1: Architettura semplificata ATSSS (piano utente)

Il supporto ATSSS opzionale è abilitato da funzioni dedicate del piano utente distribuite in UE e UPF e da nuove regole sul piano di controllo necessarie per applicare la gestione del traffico sui due collegamenti abilitando un livello Multi-Accesso (MA) PDU (N3), come mostrato nella seguente architettura semplificata (ad esempio, un CN compatibile con ATSSS rel-16).

Figura 2: Piani di controllo e dati semplificati ATSSS tra UE e UPF per una CN e un UE in grado di operare in ATSSS

 Le regole di Policy and Charging Configuration (PCC) generate dal Policy Control Function (PCF) abilitato all’ATSSS per ciascun tipo di Service Data Flow (SDF) vengono tradotte dallo Session Management Function (SMF), anch’esso abilitato all’ATSSS, in regole N4 destinate al User Plane Function (UPF). Queste regole includono parametri di instradamento e di qualità del servizio (QoS), come le Forwarding Action Rules (FAR) e le Packet Detection Rules (PDR), oltre a regole specifiche per il Multi-Access (MAR) e le regole ATSSS. Lo SMF invia inoltre queste regole ATSSS al dispositivo utente (UE) tramite l’Access and Mobility Management Function (AMF), insieme alle regole di UE Route Selection Policy (URSP), che vengono trasmesse attraverso l’interfaccia NAS (N1).

Le funzioni ATSSS nell’UE sono incaricate di gestire il traffico nella tratta in salita (dall’UE al DN), mentre le funzioni ATSSS nell’UPF sono incaricate di gestire il traffico nella tratta in discesa, abilitando una combinazione di MPTCP (livello superiore) [2] e/o di tecnologia multicollegamento di livello inferiore, detta in generale ATSSS-LL.

Un “Multi Access (MA) PDU Request” nel messaggio UL NAS Transport indica alla CN che è necessario stabilire una nuova MA PDU Session e applicare la funzionalità ATSSS-LL o la funzionalità MPTCP (o entrambe) per atttivare una sessione PDU multi-accesso. La sessione multi-accesso sarà regolata da un insieme specifico di possibili regole ATSSS, che in breve sono:

• Selezione dell’utilizzo di Multipath-TCP (MP-TCP) o ATSSS-LL per ogni SDF corrispondente
• L’indicazione di una modalità di direzionamento, selezionata tra

Active-Standby	Contrassegnare uno dei due collegamenti come Master e l’altro come Slave. Il traffico viene sempre inviato tramite il collegamento principale, a meno che non diventi (temporaneamente) non disponibile. Questa è l’unica modalità di reindirizzamento disponibile per le sessioni di traffico SDF (Guaranteed Bit Rate – GBR);
Smallest Delay	Utilizzare il collegamento che, al momento dell’avvio della sessione, mostra l’RTT più basso. Se, durante la durata della sessione, tale collegamento non è più disponibile, verrà utilizzato l’altro (in modo analogo a quello dell’Active-Standby);
Load Balancing	È possibile specificare una percentuale di condivisione tra i due collegamenti. Nel caso in cui uno dei due collegamenti non sia disponibile, il bilanciamento andrà tutto a favore dell’altro collegamento (100%);
Priority Based	Il traffico viene inviato inizialmente solo al collegamento contrassegnato con priorità più alta, fino a quando non risulta congestionato. La determinazione della congestione è lasciata libera allo sviluppatore. In quel momento, il traffico inizia a essere diviso su entrambi i collegamenti. Se il collegamento con priorità alta non è più disponibile, il traffico viene indirizzato al collegamento con priorità bassa.

Alcuni esempi di regole ATSSS per l’UE sono descritti nella versione 16 e riportati nel seguente testo citato:

• “Traffic Descriptor: UDP, DestAddr 1.2.3.4”, “Steering Mode: Active-Standby, Active=3GPP, Standby=non-3GPP”: Questa regola significa “indirizzare il traffico UDP con l’indirizzo IP di destinazione 1.2.3.4 all’accesso attivo (3GPP), se disponibile. Se l’accesso attivo non è disponibile, utilizzare l’accesso in standby (non 3GPP)”.
• “Traffic Descriptor: TCP, DestPort 8080”, “Steering Mode: Smallest Delay”: Questa regola significa “indirizzare il traffico TCP con la porta di destinazione 8080 all’accesso con il minor ritardo”. L’UE deve misurare l’RTT su entrambi gli accessi, al fine di determinare quale accesso ha il ritardo minore.
• “Traffic Descriptor: Application-1”, “Steering Mode: Load-Balancing, 3GPP=20%, non-3GPP=80%”, “Steering Functionality: MPTCP”: Questa regola significa “inviare il 20% del traffico dell’Applicazione-1 all’accesso 3GPP e l’80% all’accesso non 3GPP utilizzando la funzionalità MPTCP”.

Eventualmente, è possibile fornire una regola ATSSS con un descrittore di traffico “corrispondenza con tutti”, che corrisponde a tutti gli SDF. Questa regola viene applicata per ultima e determina il comportamento predefinito per tutto il traffico che non corrisponde alle regole precedenti.

MPTCP

Un numero maggiore di soluzioni per l’aggregazione di collegamenti e multipath allo strato L4 comporta modifiche al TCP. Attualmente, il MultiPath TCP (MPTCP) [2] è un approccio comune per l’aggregazione della larghezza di banda a livello di trasporto; è attualmente in fase di standardizzazione da parte del gruppo di lavoro MPTCP in IETF ed è disponibile per kernel Linux dalla versione 3.10 e per dispositivi smart Apple da iOS 7.

MPTCP richiede un livello di sessione stabilito da entrambi gli endpoint, altrimenti il mittente stabilirà una connessione TCP regolare su un singolo collegamento. Uno dei principali obiettivi di progettazione di MPTCP era quello di essere completamente trasparente sia per l’applicazione che per la rete. L’applicazione interagisce con il livello di trasporto tramite normali API socket mentre l’MPTCP, come livello intermedio, gestisce la comunicazione stabilendo più flussi TCP con l’estremo del collegamento, se supportato.

MPTCP può essere configurato secondo due strategie principali (es. path manager): channel bonding o link failover. Con il primo approccio, l’utente finale sperimenterà un’elevata velocità di trasmissione dati grazie allo sfruttamento di collegamenti multipli; quest’ultimo viene utilizzato per garantire la continuità del servizio in caso di guasto del collegamento. I dati in uscita vengono quindi programmati sui collegamenti in base a una politica (ad esempio, scheduler) e in base a uno schema di controllo della congestione semplice o a uno multipath dedicato (come OLIA). I dati in ingresso da tutti i flussi secondari TCP ricevuti vengono riordinati per mantenere l’astrazione del flusso di byte in ordine di TCP come visualizzato dall’applicazione.

Per stabilire una connessione MPTCP, all’inizio viene avviato un normale handshake a 3 vie tra i due nodi finali (host). L’opzione MP_CAPABLE presente nei messaggi SYN (per il client) e SYN+ACK (per il server) notifica che l’estremo finale supporta MPTCP. Nel caso in cui entrambe le parti siano compatibili con MPTCP, è possibile aggiungere ulteriori sotto-flussi TCP alla connessione stabilita: per ogni sotto-flusso è richiesto un handshake utilizzando un token scambiato dalle parti nei messaggi iniziali.

Attualmente MPTCP è disponibile solo nello spazio del kernel Linux (anche se esistono alcune realizzazioni in spazio utente e sono scarsamente manutenute). L’ultima versione di MPTCP (v0.95) è basata sul kernel Linux v4.19, ma può essere inclusa anche in alcune delle versioni più recenti del kernel Linux v5.x. Tuttavia, il suo supporto non è disponibile per impostazione predefinita nelle distribuzioni Linux e deve essere compilato o esplicitamente abilitato per funzionare.

Essendo MPTCP progettato per stabilire direttamente una connessione da estremo a estremo tra una sorgente e una destinazione a livello IP, se uno degli estremi non lo supporta, devono essere prese in considerazione middlebox dedicate (proxy). A tal fine, IETF ha specificato nel RFC8803 [3] il “0-RTT TCP Convert Protocol”, un proxy applicativo destinato a convertire la comunicazione MPTCP (o altri tipi di comunicazioni TCP) in TCP standard. “TCP Convert” è l’approccio obbligatorio definito dal 3GPP rel 16 per supportare MPTCP ATSSS, che deve essere supportato nativamente dall’UE. Vale la pena notare che non è previsto alcun ritardo aggiuntivo durante la conversione (ad esempio, il riferimento a 0-RTT in RFC8803). Si noti inoltre che questo protocollo non richiede alcun incapsulamento (ad esempio, tunnel o metodi di affinità) e non avrà alcun impatto sulla connessione sicura da estremo a estremo (TLS).

Per fornire un’indicazione dei vantaggi nell’abilitare MPTCP come tunnel tra UE e UPF, proponiamo i risultati di un esperimento derivato da [4] in cui l’accesso non-3GPP è assunto per essere un collegamento satellitare da 50 Mbit/s ad elevato ritardo, e l’accesso 3GPP è limitato a 10 Mbit/s. Il traffico viene suddiviso tra i due collegamenti, offrendo dal punto di vista dell’applicazione un throughput aggregato che è la somma dei throughput sui singoli collegamenti. Sul lato UPF, la conversazione MPTCP viene convertita da un proxy in TCP standard, per raggiungere un server su Internet. Si ricorda che, in caso di mancato collegamento, la comunicazione prosegue sul collegamento rimasto disponibile (a circa 15 s rimangono solo i collegamenti satellitari).

Figura 3: Esempio di aggregazione MPTCP e risposta di failover

ATSSS-LL e PMF

ATSSS-LL ha lo scopo di definire un meccanismo di accesso multiplo di livello 2 sul piano utente della CN 5G, tra UE(s) e UPF(s). Nel caso della PDU Ethernet, è l’unico meccanismo disponibile in ATSSS, mentre se la PDU è IP v4/v6, ATSSS-LL integra MPTCP gestendo il traffico che non utilizza MPTCP

Mentre la realizzazione MP-TCP è ben nota e disponibile, con una realizzazione proxy MP-TCP richiesta per ATSSS che deve essere basata su RFC TCP-Convert, lo sviluppo ATSSS-LL è lasciato aperto (ma soggetto a una serie di requisiti), come dal seguente estratto dalle specifiche versione 16 3GPP:

“La funzionalità ATSSS-LL nell’UE non applica un protocollo specifico. Si tratta di una funzione di commutazione dei dati, che decide come indirizzare, commutare e suddividere il traffico della tratta in salita tra accessi 3GPP e non 3GPP, in base alle regole ATSSS fornite e alle condizioni locali (ad esempio, condizioni di perdita del segnale). […] La funzionalità ATSSS-LL è obbligatoria nell’UE per la sessione MA PDU di tipo Ethernet. Quando l’UE non supporta la funzionalità MPTCP, la funzionalità ATSSS-LL è obbligatoria nell’UE per una sessione PDU MA di tipo IP. Quando l’UE supporta la funzionalità MPTCP, la funzionalità ATSSS-LL con modalità di indirizzamento Active-Standby è obbligatoria nell’UE […] per supportare il traffico non MPTCP. La rete (ad esempio, UPF) deve anche supportare la funzionalità ATSSS-LL come definito per l’UE.”

Per quanto riguarda le “condizioni locali” menzionate nelle specifiche 3GPP versione 16, un componente aggiuntivo della funzione di misurazione delle prestazioni (PMF) per ATSSS, che sfrutta il protocollo PMF (PMFP), deve essere incluso sia negli UEs che negli UPF. Sebbene MPTCP sia in grado di eseguire un’autovalutazione sulla disponibilità e sullo stato del collegamento (anche se gli input esterni possono essere considerati alla luce delle possibili modalità di indirizzamento), sono necessarie misure esplicite di latenza e carico per effettuare le operazioni ATSSS-LL. Si veda la seconda regola di ATSSS descritta in precedenza, in cui deve essere selezionato il collegamento con il ritardo più piccolo. L’obiettivo principale di PMF è quindi quello di fornire metriche in tempo reale ad entrambe le estremità (UE e UPF), utili per effettuare una gestione del traffico locale di basso livello sulla base dello stato di ciascun collegamento. PMF è in grado di valutare i valori di interesse utilizzando un protocollo server-client basato su UDP chiamato PMF Protocol (PMFP), i cui pacchetti condividono lo stesso livello PDU disponibile per i dati del piano utente. In questo modo, l’RTT e le misure di carico dedotte dal PMF rifletteranno le condizioni effettive del traffico sull’intero percorso dei dati tra UE e UPF.

PMFP si basa sullo standard RFC8972 (STAMP) – precedentemente RFC8762, basato su RFC5357 (TWAMP) che a sua volta si basa su RFC4656 (OWAMP). Sebbene esistano alcune realizzazioni STAMP/TWAMP [5], [6], [7] le versioni PMFP pienamente conformi non sono disponibili nel panorama Open-Source. STAMP, per semplificazione, può essere considerato una versione client-server dell’applicazione ICMP/Ping di base “sotto steroidi”.

Non siamo a conoscenza di alcuna soluzione ATSSS-LL Open-Source conforme al 5G, incluso PMF, o linee guida suggerite per la sua realizzazione a livello di collegamento, e RomARS sta attualmente svolgendo attività di ricerca e sviluppo su questo argomento. Un’indicazione su come ottenere una funzionalità ATSSS indipendente dal livello di trasporto per le PDU IP (cioè per il traffico non TCP o per le applicazioni che non utilizzano MPTCP) è quello di utilizzare i tunnel QUIC come proposto anche in [8] (anche se al momento questa bozza è scaduta). Si noti che questo approccio è stato proposto e studiato durante il progetto ESA VIBeS e di fatto è alternativo all’MPTCP. Come risultato di questo progetto, RomARS dispone di alcuni prototipi di terminazioni QUIC come istanze Docker adatte ad eseguire ATSSS.

Oltre all’approccio basato su QUIC per ATSSS-LL, possono essere considerati altri meccanismi di strato 2, come descritto nel lavoro di RomARS in [9]. Ci riferiamo in particolare ai possibili approcci di tunneling (ad esempio, GRE, GRE over VPN) che sfruttano le capacità di bonding di Linux [10], che supporta nativamente la configurazione Active-standby (chiamata active-backup), tra molte altre. In primo luogo, in ogni caso, questi tipi di approcci “layer 2” non dovrebbero offrire vantaggi significativi rispetto a quelli basati su QUIC.

Riferimenti

[1] System Architecture for the 5G System (3GPP TS 23.501 version 16.6.0 Release 16)
[2] Paasch and O. Bonaventure, “Multipath TCP Communications of the ACM”, 57(4):51-57. 2014
[3] Bonaventure , M. Boucadair, S. Gundavelli, S-H. Seo, and B. Hesmans, “0-RTT TCP Convert Protocol”, RFC 8803
[4] Abdelsalam, M. Luglio, C. Roseti and F. Zampognaro, “Linux MP-TCP performance evaluation in a combined terrestrial-satellite access”, 2019 International Conference on Wireless Technologies, Embedded and Intelligent Systems (WITS)
[5] https://github.com/nokia/twampy
[6] https://github.com/tcaine/twamp
[7] https://github.com/emirica/twamp-protocol
[8] M. Boucadair et al., “3GPP Access Traffic Steering Switching and Splitting (ATSSS) – Overview for IETF Participants”, proposed RFC “draft-bonaventure-quic-atsss-overview”
[9] Abdelsalam, A., et al. “Analysis of bandwidth aggregation techniques for combined use of satellite and xDSL broadband links.” International Journal of Satellite Communications and Networking 37.2 (2019): 76-90
[10] Linux Ethernet Bonding Driver, https://www.kernel.org/doc/Documentation/networking/bonding.txt

 

© RomARS – Francesco Zampognaro