Come indicato nel precedente articolo, la larghezza di banda sempre più ampia richiesta dal continuo aumento di traffico IP nonché dalla crescente popolarità di servizi “bandwith hungry” (video, file sharing, online gaming, cloud computing, realtà virtuale, ecc.) porta alla necessità di realizzare reti di nuova generazione, sia fisse che mobili, sempre più veloci e performanti — NG(A)N, next generation (access) network a banda ultra larga (ultrabroadband, UBB).
E’ molto importante sottolineare la differenza – nota agli esperti e agli operatori del settore (V. ad esempio considerazioni di Gianfranco Ciccarella e Tiziano Tofoni su Reissblog) ma molto meno agli utenti – tra velocità di trasmissione / banda disponibile (bit rate, BR) nelle reti IP e velocità (di scambio dati) delle applicazioni (throughput, TH).
Date le architetture e prestazioni delle attuali reti, il throughput può risultare anche significativamente inferiore al bit rate. BR è il parametro generalmente propagandato dai fornitori di accesso – Telco / internet service provider (ISP) – mentre i key performance indicator (KPI) / requisiti di prestazioni end-to-end dei fornitori di contenuti (content provider, CP) sulle reti degli operatori si concentrano (comprensibilmente) non tanto sul bit rate quanto sulla velocità delle applicazioni (TH) — e tempo di risposta alle richieste degli end user (download time, DT), parametro che interessa direttamente i ricavi potenziali dei CP stessi. Infatti, il tempo di download di una pagina web influenza pesantemente il sentiment degli utenti e la loro permanenza o meno nei relativi siti, con conseguenti impatti diretti sul business dei fornitori di contenuti CP. Riduzioni di pochissimi (1-2) secondi nel download time possono portare a significativi incrementi dei ricavi (anche maggiori del 10%) per piattaforme di e-commerce, motori di ricerca, ecc.
Il throughput dipende dal bit rate – che è una precondizione per ottenere alti valori di TH poiché il massimo valore del TH sarà sempre limitato dal BR – ma in genere è inferiore rispetto al bit rate, essendo limitato (i) dalla latenza / round trip time (RTT = 2 x latenza), cioè dal tempo necessario per trasferire i pacchetti (in genere 1.500 byte) tra sorgente e destinazione a causa del ritardo di propagazione (per la fibra ottica ~5µsec / km), lunghezza delle code (router, server, ecc.), … , in parte come vedremo gestibile dagli operatori di rete, e (ii) dalla percentuale di pacchetti persi nel transito attraverso le varie reti – packet loss (PL), più difficile da gestire (ad esempio nell’accesso radio).
Il throughput è pertanto generalmente (anche molto) inferiore alla banda disponibile (BR), e aumentare solo quest’ultima (ad esempio attraverso reti ultrabroadband in fibra) senza ridurre round trip time e packet loss non è sufficiente ad incrementare il throughput, e di conseguenza il livello di qualità di esperienza / soddisfazione dell’utente — quality of experience (QoE). Questa dipende da TH e download time, e per migliorare questi indicatori di prestazioni si deve operare al livello 4 (Trasporto degli applicativi IP) della pila a 5 livelli dell’internet reference model IETF RFC 1622 — simile allo stack a 7 livelli ISO-OSI, con i livelli 5÷7 sostanzialmente compattati nel livello 5 dell’internet reference model. Agire sulla qualità del servizio (quality of service, QoS), cioè l’insieme di funzionalità di rete (dei livelli 2 e 3 dell’internet reference model) che consentono di differenziare il trasporto del traffico IP (gestione della priorità delle code, assegnazione di banda minima garantita, … ), ha scarso impatto (miglioramento di pochi punti %) sui due parametri chiave che limitano il throughput, (round trip time e packet loss), e quindi da sola non è determinante per migliorare la QoE e per abilitare nuovi servizi che richiedono maggiori prestazioni — come ad es. video streaming 4K e realtà virtuale a 360 gradi.
Ad esempio, per lo streaming video HD il TH richiesto è compreso tra circa 4 e 6 Mbps, e per streaming video 4K il TH richiesto è compreso tra circa 25 e 35 Mbps. Se i valori di RTT e PL sono ‘alti’, anche con un bit rate di 10 Mbps non si riesce ad avere un TH di 4÷6 Mbps, cioè un rapporto TH / BR del 40%÷60%. Per il video 4K anche con un bit rate di 50 Mbps (ad esempio utilizzando connettività fiber to the cabinet, FTTC) non si riesce ad avere un TH di 25÷35 Mbps, cioè un rapporto TH / BR del 50%-70%. Il rapporto TH / BR è compreso nel range 25%-40%, ma difficilmente raggiunge valori superiori al 35%.
Pertanto, anche bit rate di 100 Mbps (target dell’Agenda Digitale 2020) e oltre non consentiranno di fornire servizi avanzati ad elevati requisiti di throughput e basso download time se il round trip time (= latenza x 2) e il packet loss non verranno ridotti a livelli sempre più bassi. Ricordiamo che RTT e PL limitano il throughput rispetto al bit rate, e hanno un impatto negativo sul download time – TH e DT rappresentano i principali KPI per applicativi / servizi. Pertanto, onde migliorare le performance e/o fornire le prestazioni richieste da applicativi / servizi è necessario ridurre il round trip time (che impatta direttamente sul throughput), mentre sono meno semplici interventi ’significativi’ sul packet loss.
Non esiste un valore di riferimento per RTT, piuttosto variabile nel mondo in funzione dei Paesi, delle aree geografiche e delle ore del giorno – con notevoli differenze tra ora di picco e ora con il minimo traffico. Si tende a valori < 15-20 msec, e ancora meno con il 5G (che prevede latenze < 5 msec e per alcuni servizi di 1 msec), a fronte dei 30÷50 msec riportati in documenti UE 2014. La situazione è in costante miglioramento, anche a seguito del dispiegamento di reti UBB, ma nonostante la riduzione del RTT il rapporto TH / BR in genere resta costante o addirittura peggiora. In ogni caso, dato che le reti UBB incrementano il bit rate, è necessario ridurre il RTT per utilizzare in modo efficiente le risorse di rete, per ‘monetizzare’ l’ultrabroadband (cioè per avere ricavi incrementali dalle reti UBB) e per consentire la fornitura di nuovi servizi, come ad esempio, la realtà virtuale a 360 gradi, che richiede 1 Gbps — di throughput, non di bit rate !
Con riferimento al PL, valgono considerazioni analoghe a quelle fatte per RTT. Anche per il PL i valori nel mondo sono molto variabili in funzione dei Paesi, delle aree geografiche e delle ore del giorno, con forti differenze tra ora di picco e ora con il minimo traffico. Valori nella fascia ‘bassa’ riportati in documenti UE 2014 per le reti fisse sono compresi tra 0,2% e 0,02%. Per le reti mobili, il PL è più alto e in accesso arriva, nelle ore di punta, anche al 15-20%.
Quindi, onde migliorare le prestazioni degli applicativi / throughput e quindi la QoE, occorre (i) aumentare il bit rate (reti ultrabroadband), (ii) ridurre latenza / round trip time e packet loss (‘avvicinando’ i contenuti agli utenti fruitori degli stessi) e (iii) separare i servizi applicativi dai servizi di rete / connettività.
Il punto (i) è stato trattato nel precedente articolo sulle NGN, mentre del (iii) si parlerà nel prossimo — la ‘rivoluzione’ over the top (OTT). Relativamente al punto (ii), si può ricorrere sostanzialmente a due tipi di piattaforme per migliorare la QoE:
§ Piattaforme Telco cloud (function caching) per l’esecuzione di funzioni di rete e software applicativo in prossimità degli end user – cioè ai bordi (“edge”) della rete – riducendo round trip time e (in parte) packet loss. La distribuzione del cloud consente di realizzare la network function virtualization (NFV) e altre funzionalità necessarie per alcune piattaforme che migliorino le prestazioni e di eseguire il software degli applicativi vicino agli end user (ad esempio driverless car). La distribuzione del cloud nelle reti di Telco / ISP è uno dei principali argomenti della standardizzazione 5G ed è il punto chiave del progetto Mobile Edge Computing dell’ETSI.
§ Piattaforme che migliorano le prestazioni degli applicativi (QoE), sostanzialmente ‘avvicinando’ i contenuti ai fruitori (content caching) e riducendo in tal modo round trip time e (in parte) packet loss.
Relativamente al secondo punto (miglioramento della QoE), si possono impiegare varie opzioni operative. Ad esempio, gli ‘acceleratori di protocollo’ dividono la connessione tra sorgente e destinazione in più connessioni a minore RTT, con impatto generalmente favorevole sul round trip time complessivo. Le piattaforme di front end optimization tendono a minimizzare il numero di messaggi scambiati tra sorgente e destinazione all’avvio di ciascuna sessione, riducendo il download time. E così via. Il vantaggio maggiore si ha comunque avvicinando il più possibile i contenuti all’utente finale, facendo ‘fare meno strada’ ai contenuti per raggiungere la destinazione e riducendo quindi latenza / round trip time.
E’ quanto si usa fare da tempo con le content delivery network (CDN), reti di server / data center gestiti da operatori specializzati (e.g. Akamai) ovvero fornitori di contenuti (e.g. Google) strategicamente posizionate nei territori serviti dagli ISP, server nei quali vengono caricati contenuti predefiniti e/o richiesti con maggiore frequenza / probabilità dagli utenti finali vicini a quegli specifici server – in base a valutazioni statistiche o di convenienza economica dei gestori CDN. Le CDN stanno ora evolvendo verso sistemi gestiti direttamente dagli operatori Telco, che decidono quali contenuti memorizzare in (mini) data center sempre più capillarmente collocati sul territorio – in areole anche di ~50 kmq – e avvicinare i contenuti più popolari agli utenti finali — “transparent caching”. In tal modo vengono ridotti round trip time e packet loss (cioè il throughput e di conseguenza la QoE) e la quantità di traffico in transito sulla rete, che scambia i contenuti completi solo all’inizio delle sessioni, per poi scambiare solo il “delta” informazione tra un caricamento e il successivo. Le piattaforme di transparent caching agiscono in maniera “intelligente”, utilizzando funzionalità di machine / self learning per selezionare i contenuti più (prevedibilmente) richiesti sulla base delle inclinazioni e comportamento degli utenti, e memorizzandoli in data center nelle vicinanze degli utenti finali, per renderli immediatamente disponibili su richiesta degli stessi.
In conclusione, le prestazioni dipendono dal servizio / applicativo e quindi, poiché i valori di RTT e PL variano per i diversi servizi, non è importante definire valori target per RTT e PL, quanto migliorare il rapporto throughput / bit rate (TH / BR) delle reti ultrabroadband. Tale rapporto, per reti sia fisse che mobili, dovrebbe crescere almeno al 70-80% per poter:
· abilitare nuovi servizi (che richiedono alti valori di TH);
· monetizzare le reti UBB;
· ottimizzare i costi di rete (migliorando l’utilizzo delle risorse di rete e della banda radio nella rete d’accesso per le reti mobili).
Le considerazioni qui illustrate sull’importanza cruciale del round trip time sulle prestazioni applicative potrebbero ridimensionare in parte il ruolo del satellite (~250 msec RTT nei satelliti geostazionari), fixed wireless access (FWA) e simili per applicazioni specifiche ad alto throughput – CDN / caching di prossimità a parte -, per le quali al momento sembrerebbero più efficienti le reti terrestri, fisse e/o mobili (4G, 5G), eventualmente utilizzando in aree più svantaggiate (remote / rurali) ulteriori sistemi di ottimizzazione quali i citati acceleratori di protocollo, front end optimization, ecc.
Qui il primo articolo della serie “Interconnessione, accesso e net neutrality: lo spariglio di Internet”
Qui il secondo articolo della serie “Ngn, così le reti risponderanno ai servizi “bandwith hungry”
