Monitoraggio Delle Reti Mobile Broadband

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Reti di Calcolatori I
Monitoraggio Delle Reti Mobile Broadband
Anno Accademico 2015/16
Candidato:
Marco Reccia
matr. N46001414
Relatore:
Ch.mo Prof. Antonio
Pescapè
Correlatore:
Ch.mo Ing. Giuseppe Aceto
[Dedica]
Indice
Indice .............................................................................................................. 3
Introduzione .................................................................................................... 4
Capitolo 1: Il Progetto MONROE .................................................................. 6
1.1 Introduzione .......................................................................................... 6
1.2 La Piattaforma MONROE .................................................................... 7
1.3 Use Cases ............................................................................................ 10
Capitolo 2: La NorNet Edge ......................................................................... 24
2.1 La Struttura ......................................................................................... 24
2.2 Misure sugli Stati di Radio Resource Control .................................... 25
2.3 Misure sul Tempo di Download ......................................................... 27
2.4 Misure di Packet-Loss ........................................................................ 28
Capitolo 3: Misure di QoE ........................................................................... 33
3.1 Introduzione ........................................................................................ 33
3.2 Analisi QoE per YouTube .................................................................. 34
Conclusioni ................................................................................................... 36
Bibliografia ................................................................................................... 37
3
Introduzione
Le reti mobili a banda larga stanno diventando, col passare degli anni, le più
importanti
infrastrutture
di comunicazione. Nell'ultimo decennio,
in
particolare con l'espansione a livello globale di dispositivi mobili e con la
disponibilità di reti mobili ad alta capacità, 3G e 4G, è cambiato radicalmente
il modo in cui le persone accedono ad Internet. Il traffico nelle reti MBB
(Mobile BroadBand) è cresciuto di 12 volte negli ultimi dieci anni ed è
destinato ad incrementare ulteriormente negli anni successivi.
Data l'importanza delle reti mobili a banda larga, c'è un forte bisogno di
ottenere informazioni oggettive sulle loro stabilità e performance.
Obiettivo di questo elaborato è quello di mostrare il lavoro fatto nelle
misurazioni di grandezze relative a tali reti da parte di alcuni studi di ricerca,
quali quelli del progetto MONROE, che occuperà una gran parte
dell'elaborato insieme alla descrizione dell'infrastruttura di nodi su cui
MONROE si appoggia, ovvero la NorNet Edge, dando una visione d'insieme
degli Use Cases di applicazione del progetto MONROE e di possibili progetti
futuri implementabili su tale piattaforma.
Verranno forniti poi dati ed esperienze effettuate nella valutazione di
parametri di Quality of Service, come Round Trip Time, Packet-Loss, e di
parametri di Quality of Experience, che influenzano il giudizio soggettivo
4
dell'utente finale, in varie condizioni di funzionamento della rete, sia in
condizioni di Handover tra più reti che in condizioni di elevata mobilità.
Queste valutazioni riguarderanno svariati progetti, sia Europei (Simula
Research Laboratory in Norvegia) che Internazionali (Università statale del
Nord Carolina e Instituto di ricerca della Corea). Per ogni progetto,
esperimento o quant'altro, verranno fornite spiegazioni circa i parametri, i
protocolli e le possibili soluzioni a problematiche che affliggono le reti mobili
a banda larga, in modo tale da rendere un quadro completo di ciò che si sta
trattando.
5
Capitolo 1: Il Progetto MONROE
1.1 Introduzione
Negli ultimi anni, nel mondo delle telecomunicazioni, l'utilizzo di reti mobili
a banda larga (MBB, Mobile Broadband) è cresciuto enormemente grazie alla
rapida diffusione e immensa popolarità di dispositivi portatili dall'uso
quotidiano, quali smartphone e tablet, e grazie inoltre alla disponibilità di reti
mobili ad alta capacità (3G/4G).
In questo contesto è necessario comprendere al meglio le caratteristiche di tali
reti, volgendo maggior attenzione ed interesse alle misurazioni.
Il progetto MONROE, a questo scopo, propone di progettare e realizzare la
prima piattaforma multinazionale Europea per un monitoraggio indipendente,
multi-homed e a larga scala e per valutazioni prestazionali delle reti MBB in
ambienti eterogenei, dato che, come noto, i segnali broadband sono soggetti a
molte interferenze dovute alla presenza di ostacoli, al particolare materiale di
questi ultimi, alla lontananza dalla base station e soprattutto al sovrapporsi di
più sistemi di TLC in una stessa area geografica.
La suddetta piattaforma deve inoltre essere flessibile per venire incontro agli
interessi e bisogni dei vari stakeholders. A questo scopo, MONROE
progetterà ed eseguirà esperimenti per identificare metriche affidabili per le
6
reti MBB. Inoltre MONROE è pensata per essere aperta agli utenti esterni
permettendoli di sviluppare degli esperimenti personalizzati.
L'obiettivo fondamentale è quello di stimare e migliorare l'esperienza utente
sia per i servizi attualmente in esecuzione sulle preesistenti infrastrutture a
banda larga, sia per fornire dei feedback per la prossima tecnologia 5G.
1.2 La Piattaforma MONROE
La piattaforma MONROE è complementare e fornisce funzioni esclusive alle
piattaforme sperimentali esistenti come RIPE Atlas, la rete di sonde per le
misurazioni di connettività e raggiungibilità della RIPE NCC, uno dei cinque
Regional Internet Registry esistenti in ambito IANA, responsabile
dell'assegnazione degli indirizzi IP.
Le principali caratteristiche [1] della piattaforma sono:
1. Ampia copertura geografica e a larga scala: MONROE è infatti
composto da 450 nodi in larga parte distribuiti tra Norvegia, Svezia,
Italia e Spagna, come mostrato in Figura 1. Alcuni di questi nodi fanno
parte del preesistente NorNet Edge, altra infrastruttura di misurazioni
ed esperimenti nelle reti MBB, attualmente in funzione.
La distribuzione dei nodi non è casuale: MONROE è in grado di
collezionare misure sotto diverse condizioni, da grandi città quali
Torino, Madrid, Stoccolma, dando una visione dettagliata delle
condizioni della rete in aree urbane, fino a raggiungere remote aree
rurali quali isole al nord della Norvegia.
7
Figura 1: distribuzione dei nodi MONROE [1]
2. Mobilità: per fornire una visione del MBB anche in condizioni di
mobilità, sono stati installati circa 150 nodi su treni e pullman per
coprire sia aree urbane che rurali.
3. Multi-Homed: ogni nodo MONROE ha più interfacce di rete, in
particolare sono connessi simultaneamente a tre reti broadband, cosa
che rende possibile condurre un'ampia gamma di misurazioni ed
esperimenti sia per confrontare le varie tipologie di reti, sia per trovare
modi per trarre vantaggio dalla combinazione di più risorse da ogni
rete.
8
4. Nodi flessibili e ad alte prestazioni: per garantire l'esecuzione di
esperimenti anche per applicazioni pesanti quali lo streaming video, i
nodi sono progettati in modo tale da poter sopportare grandi quantità di
dati. La flessibilità è una caratteristica necessaria per sperimentare
nuovi servizi ed applicazioni basati sul MBB, ciò è perseguito
permettendo ai nodi dei cambi di configurazione (es. modifiche del
kernel).
5. Informazioni ad ampio contesto: i nodi MONROE, oltre a rilevare
informazioni riguardo reti, hanno un supporto interno per collezionare
metadati da altri modem, come l'ID della cella, la potenza del segnale e
la modalità di connessione.
6. Open access: MONROE è aperta agli utenti e rende possibile l'accesso
al sistema e lo sviluppo di esperimenti su tutti o un insieme di nodi.
7. Open data: i risultati dei vari esperimenti vengono collezionati in un
database, presentati attraverso un sistema di visualizzazione real-time e
forniti come open data ad intervalli regolari.
9
1.3 Use Cases
La piattaforma MONROE è progettata in modo tale da soddisfare le
aspettative di differenti categorie di stakeholders, supportando una varietà di
use-cases, per garantire quanta più possibile flessibilità nei confronti dei vari
esperimenti che l'utente finale potrebbe introdurre.
Introduciamo tre principali categorie di casi d'uso [2]:

Metriche chiave per il mobile broadband.

Performance delle applicazioni.

Innovazioni di protocollo e servizio.
1.3.1 Metriche Chiave per il Mobile Broadband
La funzionalità principale della piattaforma MONROE è quella di fornire un
ricco set di metriche, da cui diversi stakeholders potranno poi estrarre le
informazioni d'interesse riguardanti performance e affidabilità delle reti MBB.
Differenti stakeholders hanno differenti requisiti per le metriche supportate
dalla piattaforma. Ad esempio, alcuni avranno bisogno di informazioni di
connettività, copertura e velocità; gli operatori saranno interessati in report su
instabilità e anomalie; inoltre gli sviluppatori avranno bisogno di controllare i
parametri per la QoS per progettare servizi e protocolli robusti.
Da queste considerazioni è chiaro che c'è bisogno di un ricco set di metadati
da associare alle misure di stabilità e performance.
Le metriche da monitorare includono parametri di QoS a livello rete quali:
RTT, round trip time e perdita di pacchetto (ICMP e UDP), sia in condizioni
normali che di sovraccarico che di rete sottoutilizzata, jitter, ovvero la
10
varianza rispetto al ritardo medio, disconnessioni e statistiche di disponibilità
di connessione. Questi parametri forniscono una visione d'insieme e
consistente delle performance e della stabilità di una rete MBB.
Vi è bisogno poi di metadati a livello rete per inquadrare il contesto entro cui
vengono fatte misurazioni di performance. I metadati a livello rete sono
cruciali non solo per informazioni di copertura ma anche durante le analisi di
misurazioni per capire i fattori che afferiscono le performance.
Di questa categoria fanno parte parametri quali: stato di connettività della
rete, tipo di tecnologia di accesso radio e parametri specifici ad esso collegati
come RSSI, Received Strenght Signal Indicator, che ci da indicazione del
segnale complessivo, composto da segnale utile e da rumore, RSRP,
Reference Signal Received Power, che fornisce indicazioni sulla potenza del
segnale e, infine, RSRQ, Reference Signal Received Quality, fattore che
indica la qualità del segnale di riferimento ricevuto e lo calcola in base ai
precedenti parametri.
Le performance della rete vengono poi stimate tramite analisi di traffico. Per
questo motivo sono necessari strumenti di analisi che monitorano e riportano
statistiche riguardanti il traffico, possibilmente in tempo reale. A questi scopi
è utilizzato Tstat, uno strumento open source per il monitoraggio continuo dei
pacchetti in un link, sviluppato a partire dal 2001 dal POLITO. Tstat elabora
più di 100 differenti statistiche di performance sia a livello IP che TCP [4],
permettendo una buona visione complessiva delle performance di rete.
11
1.3.2 Performance delle Applicazioni
A livello delle applicazioni, le misure di performance del progetto MONROE
forniscono una potenziale opportunità di esaminare l'esperienza utente.
Oggigiorno l'attenzione da parte degli utilizzatori delle MBB, soprattutto gli
operatori, è volta all'utente finale, in particolare alla QoE, la Quality of
Experience.
La QoE è un concetto complesso che combina la percezione dell'utente e le
sue aspettative, rappresenta il grado di piacere o di seccatura nell'utilizzo di
un'applicazione o servizio, dipende, inoltre, anche dal particolare tipo di
utente.
Misurare soggettivamente la QoE è un'operazione dispendiosa in termini di
risorse e di tempo, motivo per il quale un approccio più realistico e preferito
dagli operatori è quello di misurare oggettivamente la QoS e mappare le
misure per percepire la QoE. Un modello di mappatura QoS-QoE può essere
stabilito, testato e verificato a partire da un ampio set di misurazioni che
MONROE fornirebbe. Ciò è necessario affinché gli operatori possano avere
una miglior conoscenza di come i loro clienti percepiscono i servizi forniti
dalla loro rete. L'utente finale, ma anche i service provider, grazie a tali
misurazioni, potrebbero acquisire una maggiore conoscenza delle prestazioni
delle varie reti MBB e scegliere il network che fornisce la miglior qualità dal
loro punto di vista, in base soprattutto ai loro interessi.
Non minore importanza hanno gli sviluppatori di applicazioni, quali Netflix,
Google, ecc, che hanno bisogno di fare totale affidamento alle caratteristiche
della rete per poter ottimizzare al massimo i loro servizi.
12
Dato che la percezione dell'utente varia da servizio a servizio, oltre che da
utente ad utente, MONROE definisce ulteriori metriche di performance per
ogni applicazione.
Basandosi sui trend del traffico dati e sulle analisi della domanda degli utenti,
il consorzio MONROE ha selezionato i seguenti servizi da implementare:

Servizi video: in base agli studi effettuati da Cisco ed Ericsson sul
traffico mobile globale, il traffico video è quello in maggiore, continua
e futura crescita. Si prevede infatti che è destinato a crescere del 55%
annualmente fino al 2021, finché occuperà circa due terzi del traffico
mobile [3].
Il traffico video è dispendioso in termini di risorse ed ha requisiti di
qualità elevatissimi. Gli esempi classici di servizio video di cui
MONROE ha maggior considerazione sono lo streaming video e la
video sorveglianza.
Lo streaming video è sicuramente il servizio di dominante importanza
e dispendiosità in termini di risorse e che è destinato ad essere al centro
dell'attenzione anche negli anni a venire. E' importante per gli operatori
conoscere i limiti della propria rete per non causare frustrazione e
abbandono dei servizi offerti. Ad esempio le reti 4G ad oggi non sono
ancora in grado di garantire una perfetta trasmissione in video
streaming.
I maggiori fornitori di streaming video, Youtube e Netflix, utilizzano
HTTP-DASH.
HTTP-DASH è una tecnica di streaming a bitrate adattativo che
permette uno streaming di alta qualità su Internet basandosi su server
13
web HTTP convenzionali, il client DASH prima ottiene una MPD [5],
media presentation description, che descrive le informazioni del
segmento come il timing, risoluzione del video, bit rates, ma
soprattutto le codifiche alternative del componente multimediale.
Utilizzando queste informazioni, il client DASH sceglie la codifica
appropriata e inizia lo streaming tramite richieste HTTP GET. Dopo un
appropriato buffering, il client, oltre a ricevere segmenti, monitora le
fluttuazioni della banda della rete. In base a queste misurazioni, il
client decide come adattarsi alla banda disponibile, prelevando
segmenti con più alto o più basso bit-rate, mantenendo un adeguato
buffer ed evitando l'interruzione della trasmissione.
Essendo al momento la tecnica di streaming più utilizzata e soprattutto
utilizzata dai colossi dello streaming, MONROE volge maggior
attenzione alle performance di HTTP-DASH su reti MBB, coprendo
scenari statici e dinamici.
La video sorveglianza è fondamentale non solo in scenari statici quali
case, piazze, strade ma anche in mobilità, su veicoli quali bus e treni.
Il problema è che la video sorveglianza produce una quantità di dati
tale da non rendere possibile la loro spedizione nei centri di sicurezza
in tempo reale. La soluzione più immediata sarebbe prevedere la
memorizzazione del video sul veicolo stesso per poi effettuare un
upload al termine della corsa o della giornata, tramite connessioni
economiche e ad alta velocità.
Il problema di una soluzione del genere è chiaro, la sicurezza dovrebbe
aspettare diverse ore per poter prendere visione del video.
14
In questo contesto, tramite la piattaforma MONROE, si stanno
sperimentando nuove soluzioni per garantire agli operatori della
sicurezza di avere accesso on-demand ai video di sorveglianza
utilizzando una console che gli permetta di selezionare l'intervallo di
tempo del video richiesto. Il sistema MONROE sarà utilizzato per
valutare l'efficienza della video sorveglianza nell'upload di video
tramite reti MBB, tenendo presenti fattori quali la grandezza del video,
il rate di upload e le deadline specificate dagli operatori della
sicurezza.

Traffico web: i servizi web danno un grande contributo al corrente
traffico nelle reti MBB. Per questo motivo è importante stimare le
performance dei servizi web su reti MBB considerando sia lo standard
HTTP/1.1 che l'emergente HTTP/2.
Le metriche di performance a livello applicazione da misurare
potrebbero essere il tempo di transazione per il browsing web, ovvero
l'intervallo di tempo da quando è stata inviata la prima richiesta fino al
completamento del caricamento della pagina, e il ritardo per il
caricamento del trasferimento file.

Traffico di background: aggiornamenti di sistema o traffico peer to
peer costituiscono il traffico di background che su dispositivi mobili è
molto ricorrente e può influenzare le performance di altre applicazioni.
È importante per MONROE ottenere misurazioni di come il traffico in
foreground sia correlato con quello in background e come si
influenzano le performance a vicenda.
15
Sicuramente tutto ciò è importante per applicazioni cosiddette delay
sensitive come il VoIP, dato che le reti MBB utilizzano buffer di grandi
dimensioni, causando il fenomeno chiamato bufferbloat, secondo cui
l'eccessivo buffering di pacchetti causa latenza e variazione dei ritardi
delle trasmissioni (jitter). Quando un router è configurato per utilizzare
grossi buffer, anche con reti ad alta velocità, è difficile rendere
possibile l'utilizzo di applicazioni interattive, soprattutto quando vi è
traffico di background.
Il North Carolina State University negli Stati Uniti e l'Ulsan National
Institute of Scienze and Technology della Corea hanno effettuato delle
misurazioni su come il traffico di background influisca sul web
browsing sugli smartphone [14]. Gli smartphone moderni sono dotati
di almeno 1 GB di RAM e di un processore quad-core, per cui ci si
aspetta la possibilità di poter effettuare del web browsing o del gaming
online mentre si sta effettuando il download di file musicali, video, o
comunque vi sono presenti applicazioni in background, quali
WhatsApp o Facebook che effettuano continui scambi con la rete.
È stato scoperto che la corrente implementazione del TCP va incontro
ad enormi ritardi per il flusso interattivo (Web Browsing o Gaming
Online) dato che il buffer è riempito di pacchetti provenienti dal flusso
in background.
La Figura 2 mostra come il tempo di prelievo di un oggetto web è
profondamente degradato se in background vi è del download. In
questo esperimento è stato simulato il traffico Web con richieste di
contenuti random dalla dimensione di 8, 16, 32, o 64 KB.
La scelta di contenuti così piccoli fa sì che il ritardo per poterli
prelevare dipenda solamente dal Round Trip Time. Quando vi è traffico
16
di background e la formazione di lunghe code, il tempo di prelievo di
un oggetto descritto precedentemente diventa più lungo di 2.6 volte.
Figura 2: tempo di prelievo con o senza download di background. [14]
La soluzione proposta [14] riguarda un aggiustamento della Receive
Window tramite l'algoritmo detto Dynamic Receive Window
Adjustment. Come sappiamo, la Receive Window di TCP fu progettata
originariamente per informare il mittente della dimensione del buffer
del ricevitore, in modo che il receiver non venga inondato di più dati
di quanti ne possa elaborare. In questo modo il TCP realizza il
controllo di flusso.
In pratica, una volta stimato il Round Trip Time, l'algoritmo calcola la
quantità di dati ricevuta ad ogni RTT e modifica la Congestion
Window, variabile che impone un vincolo sulla quantità di dati
trasmessi e non ancora riscontrati dal mittente [15] e settata
inizialmente pari alla quantità di dati ricevuta nel primo RTT, in
questo modo:
17
CongWin(n+1) = CongWin(n) * α + data_received * (1-α)
α è un valore che varia da 0 a 1, nell'implementazione considerata 7/8.
Questo nuovo valore è utilizzato per determinare la Receive Window,
che viene settata come:
RcvWin(n) = λ * RTTmin/RTT(n) * CongWin(n)
Dove λ è un parametro modificabile e maggiore di 1.
Se il RTT in quel momento ha valori simili al RTT minimo registrato,
implicando che la rete non sia congestionata, la Receive Window
aumenterà rapidamente. Al contrario se l'ultimo RTT registrato è
elevato, l'algoritmo decrementa gradualmente il valore della finestra.
Misure di RTT hanno mostrato che l'algoritmo DRWA riduce il
ritardo nelle reti TCP di circa 25-49%, con risultati superiori al 50%
in alcuni scenari.
1.3.3 Protocolli e Servizi Innovativi
Abbiamo già accennato come la piattaforma MONROE ha, tra le sue
caratteristiche, quella di essere flessibile ed infatti non solo fornisce misure per
protocolli e servizi esistenti, ma ne permette anche per altri nuovi ed
innovativi.
Il multi-homing e la distribuzione geografica dei nodi nei posti più eterogenei,
garantisce a ricercatori e service providers di sperimentare nuovi protocolli ed
algoritmi che sfruttano le connessioni multiple a loro vantaggio, ad esempio in
18
parallelo o scegliendo, tra quelle disponibili, quella con il miglior servizio
disponibile per incrementare robustezza e performance o comunque per avere
la soluzione con un miglior rapporto costi-performance.
In caso di congestione della rete o per diminuire il carico del traffico, gli
operatori possono beneficiare dello “scarico” o “offloading” del traffico,
chiamato anche WiFi Offloading, riduce il carico di dati destinato a reti MBB,
liberando banda per altri utenti, è utilizzato anche nel caso in cui la ricezione è
scarsa, permettendo agli utenti di connettersi via servizi wired con una
migliore connettività.
A causa del sovraccarico del traffico mobile (si pensi allo streaming video in
alta definizione), l'offloading è sempre più al centro dell'attenzione per
beneficiare sia utenti che operatori. Gli utenti traggono vantaggio dall'offload
per utilizzare reti migliori; gli operatori, grazie all'offload, riducono il carico
del traffico e alleviano la congestione della rete.
Una serie di misurazioni è necessaria per gli operatori affinché valutare
l'applicabilità, le performance e l'efficienza di tale pratica.
Gli utenti finali sono soggetti a numerosi problemi dai differenti tipi di
middlebox.
Reti moderne fanno sempre più affidamento a tali middlebox, che nello
specifico sono componenti hardware dedicati ad eseguire avanzate
funzionalità
come,
ad
esempio:
l'aumento
delle
performance
di
un'applicazione tramite cache, proxy o acceleratori di traffico; bilanciamento
di carico che permette di distribuire il carico della rete su più nodi;
ottimizzazione dell'utilizzo dello spazio d'indirizzamento di Ipv4 tramite NAT,
traduttori che permettono a molteplici host di condividere un unico indirizzo
IP; sicurezza, tramite filtri firewall basati su un set di regole predefinite
dall'amministratore di rete.
19
Uno dei maggiori problemi di tali approcci è che le middlebox potrebbero, in
alcuni casi, filtrare del traffico non conforme a comportamenti attesi, rendendo
Internet un ambiente ostile alle innovazioni, è infatti diventato problematico
estendere
protocolli,
limitando
le
opportunità
di
ottimizzazione.
Conseguentemente, una piattaforma come MONROE è necessaria per
osservare e caratterizzare le operazioni dei middlebox, per determinare se una
soluzione di ottimizzazione abbia avuto un buon impatto sull'ecosistema del
MBB.
La piattaforma MONROE permette di testare vari protocolli e parametri del
livello trasporto, per valutare le loro performance su MBB e WiFi. Essendo il
protocollo del livello trasporto più utilizzato nelle reti mobili, il TCP è
sicuramente al centro dell'attenzione.
Tuttavia il TCP non fu progettato per reti MBB ed inoltre recenti studi hanno
mostrato come le connessioni TCP sottoutilizzano la banda disponibile in reti
LTE, addirittura in media del 50% della banda è inutilizzata, ciò causa
problemi come l'allungamento dei tempi nel download dei dati, causando
un'inutile addizionale spreco di energia.
TCP ha inoltre molti differenti parametri volti al controllo della congestione,
quali slow start, buffer in ricezione, recupero dei pacchetti persi che
collettivamente o individualmente hanno impatti negativi sulle performance
delle diverse applicazioni. Un altro importante aspetto è come il TCP gestisce
l'handover tra differenti reti e tecnologie MBB.
Altro aspetto che il progetto MONROE tiene in considerazione è il trasporto in
multipath, ovvero trarre vantaggio dai differenti percorsi dello stesso segnale
radio, causati sia volontariamente introducendo diversità tramite sistemi di
trasmissione MIMO, sia a causa di fenomeni di riflessione dovuti alla presenza
di ostacoli. Il trasporto in multipath ha mostrato che, se trattato in maniera
corretta, fornisce dei benefici dall'efficienza in banda all'aumento della
robustezza.
20
Per fornire un'alta qualità di servizio tramite percorsi multipli sono necessari
meccanismi quali gestione del percorso, scheduling dei pacchetti e controllo
della congestione.
Trarre vantaggio dal multipath non è un'operazione semplice se consideriamo
le caratteristiche dinamiche di una rete MBB, soprattutto in condizioni di
elevata mobilità, e delle reti WiFi, che hanno caratteristiche molto differenti
dalle reti MBB.
Uno scenario in cui entrambe le reti coesistono è lo smartphone, che fornisce
due interfacce di rete, una per Wifi e l'altra per MBB.
L'obiettivo di MONROE è quello di progettare meccanismi robusti e adattativi
per trarre vantaggio da scenari del genere.
1.3.4 Ulteriori Use Cases
MONROE fornisce una lista di ulteriori potenziali casi d'uso [2] che
introducono nuovi quesiti a cui utenti esterni al progetto potrebbero rispondere
utilizzando la piattaforma.

Comunicazioni Device-To-Device: la D2D è una componente
tecnologica per il LTE-Advanced. Nelle comunicazioni D2D, i
terminali utente trasmettono segnali dati tra di essi tramite un link
diretto utilizzando risorse cellulari invece di comunicare attraverso la
Base Station. La comunicazione può avvenire sia sullo spettro cellulare
(in band) sia su spettro non licenziato (outband). In una tradizionale
rete cellulare, tutte le comunicazioni devono attraversare la Base
Station anche se i due componenti comunicanti trarrebbero maggior
vantaggio tramite un diretto collegamento D2D. Quest'ultimo tipo di
architettura va bene per i convenzionali servizi per reti mobili a bassi
21
data rate come chiamate o messaggi in cui solitamente i due terminali
comunicanti non sono in un range di copertura tale da permettere una
comunicazione diretta. Tuttavia, gli utenti mobili nelle reti cellulari di
oggi utilizzano servizi ad elevati data rate, quali streaming video e
gaming, in cui potrebbero potenzialmente essere in un certo range per
la D2D. Per questi motivi, le comunicazioni D2D in scenari simili può
aumentare notevolmente l'efficienza spettrale della rete. Inoltre,
aumentando l'efficienza spettrale, D2D può migliorare throughput
(livello di utilizzazione della rete), efficienza energetica, ritardo e
fairness.
Motivi questi che ci fanno capire come misurare le performance di
servizi legati al D2D è interessante per future applicazioni. Le
misurazioni potrebbero riguardare la scoperta e la connessione di
coppie di dispositivi D2D, scambio di dati e test sia su nodi mobili che
statici.
L'use case D2D può essere applicato anche per testare nuove tecnologie
come la connettività WiFi Direct, che permette a due dispositivi di
stabilire una connessione Peer-To-Peer in WiFi senza necessità di un
router wireless.

Servizi di video conferenza: più complicato dello studio della QoE
dello streaming video è sicuramente il VVoIP, Voice and Video calls
over IP, data la natura real-time e la modalità di comunicazione
interattiva. Tuttavia il VVoIP è ormai un mezzo fondamentale per
interconnettere le persone, sia socialmente che professionalmente.
Le API di WebRTC supportano applicazioni per l'utilizzo di VVoIP su
reti MBB, senza l'utilizzo di plug-in esterni. Il tool di MONROE
potrebbe essere combinato con le API di WebRTC per effettuare
misurazioni di QoS, in modo tale da avere una miglior comprensione
degli aspetti della QoE.
22

Online gaming: nell'ultima decade la crescita dell'online gaming è
paragonabile a quella dello streaming video, la quasi totalità dei
videogame, su PC o console, è abilitata se non esclusivamente volta
all'utilizzo della rete. Un'ulteriore crescita si è avuta con l'introduzione
dei videogame per mobile.
Al pari, se non più, dello streaming video e dei servizi VVoIP, l'online
gaming è un'applicazione delay sensitive ed ha stretti requisiti di QoE.
23
Capitolo 2: La NorNet Edge
2.1 La Struttura
Come abbiamo già detto precedentemente, molti dei nodi facenti parte del
progetto MONROE sono quelli preesistenti della NorNet Egde.
La NorNet Edge è un'infrastruttura dedicata alla misura e alle sperimentazioni
su reti mobile a banda larga [6].
La NorNet Edge consiste di più di 400 nodi, cosa che ha permesso e permette
di avere una visione globale della rete. I nodi sono distribuiti in Norvegia,
isole incluse.
La scelta non è casuale, la complessa topografia e le condizioni climatiche
difficili della penisola scandinava, permettono di avere misurazioni molto
variegate e che quindi possono offrire una più ampia visione delle cose.
I nodi eseguono sotto il controllo di una distribuzione Linux, garantendogli
elevata flessibilità, ed hanno un'elevata potenza di calcolo per poter
fronteggiare le applicazioni più pesanti, quali quelle riguardanti video.
Come abbiamo già visto per la piattaforma MONROE, i nodi sono dedicati di
più interfacce di rete per realizzare il paradigma Multi-Homed e allo scopo di
poter trarre vantaggio dalla contemporanea connessione a più reti mobili a
banda larga e di poter essere quanto più aperti, flessibili a nuove
sperimentazioni. Ogni nodo è connesso a un numero che va da 2 a 5 provider
24
di reti MBB, per alcuni di questi è prevista una connessione fissa ad Internet,
quando possibile. A livello trasporto i nodi sono dotati dei nuovi protocolli
SCTP e MPTCP.
SCTP, Stream Control Transmission Protocol, è un protocollo unicast [7] in
grado eseguire funzionalità a livello trasporto al pari di TCP, effettuando
consegna ordinata e affidabile dei dati. SCTP è un protocollo TCP-friendly,
ovvero nodi SCTP e nodi TCP possono cooperare senza problemi di
compatibilità, introduce il supporto al Multi-Homing, che come abbiamo visto
è fondamentale per gli strumenti di misurazione.
MPTCP , MultiPath TCP, è un protocollo di livello trasporto [8] ancora sotto
sviluppo, che punta a permettere alle connessioni che utilizzano il
Transmission Control Protocol di utilizzare percorsi multipli per massimizzare
l'utilizzo di risorse e aumentare la ridondanza per una maggior robustezza e
affidabilità.
2.2 Misure sugli Stati di Radio Resource Control
Sono stati effettuati vari esperimenti sugli stati RRC, Radio Resource Control.
RRC è il protocollo radio utilizzato nelle interfacce aeree di LTE e UMTS, le
sue funzionalità principali riguardano lo stabilimento, riconfigurazione e
rilascio della connessione, broadcast di informazioni di sistema, procedure di
connessione in mobilità e procedure di power-saving [9]. Il funzionamento del
protocollo RRC è guidato da una macchina di stato, che definisce 5 stati di
funzionamento [10] mostrati in Figura 3, ad ognuno dei quali è associato un
diverso livello di consumo energetico.
25
Figura 3: Stati e transizioni di stato RRC. [10]
Il primo stato è l'IDLE-MODE o no-connection, che in realtà non è uno stato
allo stesso livello degli altri, è uno stato di basso consumo.
Il secondo stato è il CELL_DCH (Dedicated Channel), in cui è allocato un
canale fisico dedicato in uplink e downlink.
Il terzo stato è il CELL_FACH (Forward Access Channel), in cui non è
allocato nessun canale dedicato per il terminale utente che in questo stato
monitora continuamente il canale FACH per ricevere messaggi di
segnalazione, dati utenti diretto ad esso o messaggi in broadcast.
Quarto e quinto stati sono CELL_PCH (Cell Paging Channel) e URA_PCH,
in termini di modalità di funzionamento, è molto simile allo stato IDLE. L'user
26
equipment non può spedire o ricevere dati utenti, può solo monitorare il canale
di paging per ricevere messaggi di paging.
Varie reti implementano e configurano gli stati RRC differentemente in
termini di quali stati sono usati, di data rate richiesti per sostenere i vari stati e
di timer usati per passare a stati di basso consumo. Questi fattori hanno un
enorme impatto sia sulle performance che sull'efficienza in potenza della rete.
Per questi motivi è necessario effettuare delle misurazioni per vedere come la
rete reagisce ai cambiamenti di stato.
Nella NorNet Edge è stato implementato un semplice algoritmo [6]:
spedizione di un pacchetto dati da 1 KB al secondo, finché non è
riportato il cambiamento di stato in CELL_DCH per quindi fermare
immediatamente la spedizione. Aspettare quindi finché non è registrato il
passaggio di stato in CELL_FACH e successivamente in CELL_PCH o
IDLE. Viene misurato il tempo per ogni passaggio di stato causato
dall'algoritmo e ripetuto tutto per 100 volte sulle diverse reti.
Il parametro più importante da quest'esperimento è l'intervallo di tempo
che va dalla spedizione del primo pacchetto al raggiungimento dello stato
CELL_PCH, a cui si va ad aggiungere il ritardo dell'apertura di una
connessione.
2.3 Misure sul Tempo di Download
Altro esperimento eseguito sulla NorNet Edge riguarda l'analisi del
tempo di download. L'esperimento è molto semplice, si basa sulla
misurazione del tempo che ci vuole per effettuare il download di un file
da 1 MB utilizzando curl, uno strumento di trasferimento dati da o verso
27
un server che può fare affidamento a diversi protocolli (FTP, HTTP,
ecc).
Come mostrato in Figura 4, è mostrato il rapporto tra l'intensità del
segnale e la velocità in download nei casi di connessioni 2G e 3G. Le
velocità raggiunte, come ci si aspettava, sono superiori per il 3G, ma il
risultato più importante è che il rate di trasmissione non è molto sensibile
al cambiamento dell'intensità del segnale ricevuto, a patto che ci sia del
segnale ricevuto.
Figura 4: Velocità in download in funzione dell'intensità del segnale. [6]
2.4 Misure di Packet-Loss
Il Simula Research Laboratory in Norvegia ha effettuato degli studi di
misurazione su larga scala della perdita dei pacchetti nelle reti UMTS
[11].
Le misurazioni sono state effettuate tramite la NorNet Edge, con un
numero di nodi che varia da 108 a 253 in vari periodi dell'anno, e su 4
diverse reti mobile broadband norvegesi.
Per misurare la perdita di pacchetto, i ricercatori hanno spedito pacchetti
UDP da 20 byte ad un echo server, cioè un server che rispedisce indietro
28
lo stesso pacchetto, ogni secondo, per poi calcolare l'intervallo di tempo
da questo evento fino alla risposta dal server. Nei pacchetti erano previsti
un timestamp ed un numero di sequenza incrementale per la rilevazione
di duplicati e per il calcolo del round trip time. Il round trip è
normalmente di poche decine di millisecondi, tuttavia sono stati osservati
ritardi di alcuni secondi. Ciò può essere causato da un eccessivo rate di
ritrasmissioni e di buffering. Un pacchetto è considerato perso se non
arriva un riscontro entro 60 secondi.
Il loss rate, definito come il rapporto tra numero di pacchetti perduti e
numero di pacchetti spediti, è risultato essere trascurabile in molte reti,
più del 50% delle connessioni considerate hanno avuto meno dell'1% di
packet loss, causata soprattutto dal cambio da 3G a 2G e viceversa.
In
mobilità [12], il
packet
loss
è sicuramente
più elevato.
Nell'esperimento in mobilità sono stati considerati nodi su treni, il cui
percorso è mostrato in Figura 5. È stato necessario l'utilizzo di GPS per
identificare la posizione dei nodi e per monitorare la velocità dei treni.
Non sono stati considerati pacchetti UDP da 20 byte ma, in questo caso,
contenitori di pacchetti della durata di 5 minuti, detti bin. La RAT, Radio
Access Technology, può essere costante durante un intero bin o
addirittura per una serie di bin, come mostrato in Figura 5, ma può
capitare che uno stesso bin vada incontro a diversi cambiamenti della
RAT, come nel caso del bin b2 in figura che subisce un handover da 4G
a 3G. È possibile anche che vi sia un degradamento tale del segnale da
causare una perdita di connettività, con conseguente perdita dell'indirizzo
IP. Quando la connessione è persa, un nodo controlla immediatamente se
è in copertura per riconnettersi. Un'altra causa di perdita di pacchetti è lo
stesso handover inter-RAT.
29
Figura 5: percorso dei treni e sequenza di connettività tipica. [11]
I nodi della NorNet Edge utilizzati in questo studio cercano sempre di
connettersi alla RAT più veloce disponibile, ad esempio se vi sono
connessioni LTE e 3G disponibili, preferiranno la prima. Per misurare la
perdita in RAT differenti, vengono considerate due categorie principali
di bin. I primi sono i bin che subiscono uno o più handover tra RAT. I
secondi sono bin caratterizzati da un RAT predominante (3G o LTE) ma
con uno o più episodi di perdita di servizio.
Da come si vede dalla Figura 6, la stragrande maggioranza dei bin che
subiscono handover inter-RAT, circa il 92%, va incontro al packet-loss.
Le cose migliorano, anche se di poco, per l'altra categoria considerata, di
cui l'80% va incontro al packet-loss.
30
Figura 6: percentuali di perdita di pacchetto per diversi bin. [11]
Ulteriore esperimento interessante, effettuato dal Simula Search
Laboratory [13], è stato fatto durante un concerto del noto Justin Bieber,
avvenuto in Norvegia nel 2013. Una platea di più di 20 mila persone che
continuamente (cercava di) condividere foto e video sui noti social
network, mettendo a dura prova la capacità delle reti mobili a banda larga
norvegesi (Telenor, Tele2, Netcom e Network Norway).
Per quanto riguarda il packet-loss, si è cercato di ricevere uno stream di
dati da 1 MB ogni secondo, prima e durante il concerto.
Come mostrato dalla Figura 7, le percentuali di packet-loss prima del
concerto erano molto vicine allo 0% per poi subire un brusco
innalzamento da 20% fino a 100%, rendendo praticamente impossibile
l'utilizzo della rete.
Un altro parametro valutato è il Round Trip Time. Nel peggiore dei casi,
normalmente, il RTT è di circa 100 ms. Un ritardo del genere è
accettabile ed ha un impatto minimo sull'esperienza d'uso, ma, durante il
concerto, i ritardi registrati hanno raggiunto punte di 10 secondi.
Conseguenza diretta di questi valori è che la maggior parte delle
applicazioni si “arrende” e mostra a video un messaggio d'errore. Ciò che
è risultato più strano è come gli operatori di rete configurino le loro reti,
31
cercando di recuperare il pacchetto nonostante il ritardo sia ormai di
multipli secondi. Sarebbe più conveniente, per diminuire la congestione
della rete, droppare pacchetti con un certo ritardo.
Figura 7: percentuali packet-loss pre, durante e post concerto. [13]
32
Capitolo 3: Misure di QoE
3.1 Introduzione
L'esperienza di un utente con una qualsiasi applicazione [16] è
condizionata da molteplici parametri, molto diversi fra loro, quali
caratteristiche tecniche dell'applicazione, personalità ed aspettative
dell'utente stesso, età dell'utente, tipologia del terminale in uso e contesto
di utilizzo.
Applicazioni basate sulla navigazione in rete, come YouTube e
Facebook, devono tener conto delle opinioni degli utenti, identificando i
parametri di performance che sono più rilevanti nell'esperienza utente.
Ciò è fatto analizzando e correlando tre livelli mostrati in Figura 8:
il livello rete, che tiene conto dell'influenza sulla rete dei parametri di
QoS (banda disponibile, RTT, percentuali di packet-loss, ecc.); il livello
applicazione che considera sia le caratteristiche tecniche (es. bit-rate dei
video) sia i parametri di performance percepibili dell'applicazione (es.
tempo di caricamento, numero di blocchi del video, ecc.); infine il livello
utente, che riguarda le opinioni soggettive dell'utente.
33
Figura 8: livelli di valutazione della QoE
3.2 Analisi QoE per YouTube
Nell'esperimento proposto dal Centro di ricerca TLC di Vienna, sono
stati considerati diverse categorie e numero di utenti: 12 partecipanti
donne, 21 uomini, l'età media di 32 anni. Metà dei partecipanti studenti e
quasi il 45% impiegati. Una grande fetta dei partecipanti (circa il 70%)
utilizza Internet giornalmente per un lasso di tempo variabile da 1 a 5
ore, mentre il restante si divide tra quelli che usano più intensamente o
più di rado. I partecipanti hanno utilizzato modem 3G con una larghezza
banda in download controllata e modificata da 64 a 4096 Kbps per
influenzare l'esperienza utente. I partecipanti, inoltre, sono stati istruiti
per giudicare la qualità della connessione e l'esperienza generale secondo
la MOS, Mean Opinion Score, in cui il range di giudizio va da pessimo
(1) ad eccellente (5). Per di più gli utenti hanno feedback riguardo
l'accettabilità generale dell'applicazione, dicendo se l'avrebbero utilizzata
in seguito.
Gli utenti sottoposti all'esperimento hanno guardato 2371 diversi video
su YouTube, tutti alla stessa risoluzione di 360p, con diversa durata. Un
rate in download di circa 768 Kbps è stato sufficiente per raggiungere il
34
90% di rating positivi, come mostrato in Figura 9. La saturazione della
QoE si è avuta intorno ai 1024 Kbps, per poi aumentare di soli 0.2 punti
MOS al quadruplicare del rate in download.
La QoE di YouTube diventa molto sensibile quando il bit-rate del video
è più alto del rate in download, aumentando la possibilità di avere
blocchi nella visione con corrispondente cattiva esperienza dell'utente.
Per studiare la correlazione tra il bit-rate del video e il rate in download,
è stato considerato il parametro β, pari al rapporto tra il primo e il
secondo parametro. Le porzioni di video in cui β > 1 hanno ricevuto
punti bassi di MOS, al di sotto di 3, mostrando come, anche se tali
porzioni sono relativamente brevi rispetto al resto del video in cui β < 1,
influenzano notevolmente le misure di QoE finali.
Per quanto riguarda i blocchi, come mostrato in Figura 10, un singolo
blocco ha già un notevole impatto sulla QoE. La saturazione delle
opinioni si ha dopo 2 blocchi, riducendo la QoE da 2.5 a 2 punti fino a 10
blocchi.
Figura 9: rapporto tra punti MOS e rate in download. [16]
35
Conclusioni
In questo elaborato abbiamo visto come le reti mobile Broadband siano un
settore ancora tutto da scoprire e soprattutto da migliorare. I problemi relativi
alla perdita di pacchetti in caso di handover o di perdita di segnale, al ritardo
end-to-end, all’eccessivo buffering delle attuali soluzioni a livello trasporto e
molti altri problemi ancora, rendono necessari misurazioni, studi e proposte di
soluzioni, soprattutto nei nostri giorni, dove connettersi ad una rete Broadband
è un’azione all’ordine del giorno e i requisiti di qualità sono sempre più
elevati.
36
Bibliografia
[1] MONROE: Measuring Mobile BroadBand Networks in Europe
[2] MONROE: Measuring Mobile BroadBand Networks in Europe Report on use cases
[3] Ericcson Mobility Report 2016
[4] Experiences of Internet traffic monitoring with tstat – 2011
[5] Encoding.com - http://www.encoding.com/mpeg-dash/
[6] The Nornet Edge platform for mobile broadband measurements Amund Kvalbein, Dziugas Baltrunas, Kristian Evensen, Jie Xiang,
Ahmed Elmokashfi,
Simone Ferlin-Oliveira - 20 Dicembre 2013
[7] R. Stewart, Stream Control Transmission Protocol (SCTP), 2007.
<http://tools.ietf.org/html/rfc4960> (Internet RFCs, RFC 4960, ISSN
2070-1721).
[8] A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar,
Architectural guidelines for multipath TCP development, 2011.
<http://tools.ietf.org/html/rfc6182> (Internet RFCs, RFC 6182, ISSN
20701721).
[9] UMTS RRC Protocol specification (version 12.4.0 Release 12)
(PDF), European Telecommunications Standards Institute, February
2015
[10]
ftp://www.3gpp.org/tsg_ran/WG2_RL2/TSGR2_06/Docs/Pdfs/r299807.pdf
[11] Dissecting Packet Loss in Mobile Broadband - Networks from
the Edge - Dziugas Baltrunas, Ahmed Elmokashfi, Amund Kvalbein Simula Research Laboratory
Oslo, Norway - 2015
[12] Investigating Packet Loss in Mobile Broadband Networks under
Mobility - Dziugas Baltrunas, Ahmed Elmokashfi, Amund Kvalbein,
Ozgu Alay - Simula Research Laboratory, Oslo, Norway Nexia, Oslo,
Norway - 2016
[13]
https://www.nntb.no/nornet-edge-observed-mobile-networks37
during-justin-biber-concerts/
[14]Tackling Bufferbloat in 3G/4G Networks Haiqing Jiang,
Yaogong Wang, Kyunghan Lee, and Injong Rhee - North Carolina
State University, USA - Ulsan National Institute of Science and
Technology, Korea
[15]
https://it.wikipedia.org/wiki/Controllo_della_congestione_in_TCP
[16]YouTube & Facebook Quality of Experience in Mobile
Broadband Networks - Pedro Casas, Andreas Sackl, Sebastian Egger,
and Raimund Schatz
38