Uno dei parametri che pu`o essere settato nel database degli abbonati `e l’UE Aggregate Maximum Bit-Rate, ovvero il massimo bit-rate a cui pu`o invia- re e ricevere i pacchetti un utente abbonato. Allo stato di sviluppo at- tuale, UERANSIM riceve dal core di rete 5G questa informazione, ma non la utilizza per limitare il traffico dell’UE. Nel dettaglio, la gNodeB si do- vrebbe occupare di limitare il traffico di ciascuna sessione PDU in base al min(P AP N s AM BR, U E AM BR). Al fine di testare questa funzionalit`a, `
e possibile implementare in UERANSIM un semplice algoritmo di token buc- keting in grado di limitare il rateo di invio e ricezione dei pacchetti sulla/dalla socket UDP associata alla sessione PDU.
Il principio su cui si basa l’algoritmo `e semplice: `e disponibile un secchio (bucket) che contiene dei token ognuno dei quali garantisce la possibilit`a di inviare o ricevere un byte o un pacchetto di dimensione predefinita (nel caso in esame utilizzeremo i byte). I token vengono generati e inseriti nel secchio con una certa frequenza; se questo `e pieno, i token generati verranno scartati. Se un processo vuole inviare N byte deve consumare N token e nel caso non siano presenti deve attendere la loro generazione.
Prima di poter implementare l’algoritmo, `e necessario comprendere come funziona la gestione di una sessione PDU da parte della gNodeB. Il task che si occupa di ci`o, implementa un event loop per gestire i dati. In particolare, ad ogni ciclo preleva un messaggio da una coda che pu`o essere un messaggio di downlink o uplink. Nel primo caso, si tratta di un datagramma UDP da cui `e possibile ottenere il messaggio GTP e successivamente il pacchetto IP; questo verr`a passato al livello inferiore. Nel secondo caso, si tratta di un pacchetto IP che deve essere incapsulato in un messaggio GTP che a sua volta verr`a inviato come datagramma UDP.
Siccome i messaggi vengono gestiti tramite event loop `e possibile im- plementare una classe che descrive il bucket senza dover preoccuparsi degli accessi concorrenti. Alla costruzione del bucket `e necessario specificare la ca- pacit`a e il tempo impiegato per riempirsi. La classe implementa un metodo tryConsume che prende in input il numero di token da consumare; questo metodo verr`a invocato ogni volta che deve essere inviato o ricevuto un pac- chetto passandogli la dimensione di quest’ultimo. La prima azione svolta dal
(a) Speed test senza limitazione (b) Speed test con AMBR limitato a 2Mb/s sia in upload che download
Figura 5.77: Comparazione risultati speed test
metodo `e computare il numero in pi`u di token nel secchio a partire dall’ulti- ma volta che `e stato invocato; in questo modo non `e necessario implementare il bucket come entit`a proattiva che periodicamente incrementa il suo numero di token. Il codice che implementa il bucket `e contenuto in [A.4.1].
Implementata la classe, `e necessario creare due oggetti TokenBuket da utilizzare per l’upload e il download. Tutte le volte che si deve inviare/rice- vere una pacchetto PDU dal tunnel GTP `e necessario richiedere, dal bucket apposito, un numero di token pari alla grandezza del pacchetto IP che questo incapsula per poter completare la procedura. Purtroppo, l’utilizzo di un buc- ket cos`ı semplice e la gestione dei dati ricevuti e inviati mediante event-loop causa dei problemi qualora si vogliano inviare e ricevere dati simultaneamen- te. Infatti, bloccare l’event loop per limitare una delle due direzioni (upload o download) causa anche il rallentamento dell’altra. Ad ogni modo, l’im- plementazione in oggetto serve esclusivamente per verificare se `e possibile limitare upload e download in base al valore AMBR impostato nel database degli abbonati e per fare ci`o ci si avvarr`a di uno speed test. Perci`o `e pos- sibile ritenere l’implementazione sopra descritta sufficiente per eseguire tale validazione.
La macchina virtuale su cui `e in esecuzione UERANSIM possiede 2 VCPU e 4 GB di RAM ed `e dotata di una connettivit`a nell’ordine del Gigabit. Stabilendo una sessione PDU e reindirizzando il traffico di Firefox `e possibile navigare a 35 Mb/s sia in upload che in download. Ovviamente, l’hardware su cui esegue il simulatore fa da collo di bottiglia e non permette di navigare a velocit`a superiori. Inserendo nel database degli abbonati un AMBR per l’UE `e possibile limitarlo a velocit`a desiderate. Nelle figure sottostanti `e mostrato il risultato di uno speed test senza limitazione e con limitazione a 2Mb/s [5.77].
Conclusioni e sviluppi futuri
La tesi si `e concentrata sullo studio, la messa in esecuzione e la configura- zione automatizzata dei core di rete 4G e 5G. Dopo una prima panoramica introduttiva in merito agli aspetti teorici rilevanti, sono stati presentati gli strumenti software utili per la parte pratica.
Quest’ultima ha permesso di capire come NFV, CUPS e Cloud possano garantire flessibilit`a e scalabilit`a dell’architettura minimizzando i costi d’inve- stimento e gestione. In pi`u `e stato possibile studiare in maniera dettagliata il traffico scambiato nelle diverse procedure e comprendere come vengono gesti- ti aspetti fondamentali quali l’instaurazione dei tunnel GTP e delle sessioni PFCP. Il controllo diretto dell’infrastruttura Cloud ha permesso di notare un aspetto che spesso viene ignorato a causa della dematerializzazione delle risorse apportata dallo stesso: l’aumento di scalabilit`a e flessibilit`a `e sicura- mente notevole, ma deve comunque fare i conti con la potenza dell’hardware su cui si appoggia l’intera infrastruttura. Inoltre, la presenza massiva di software implica l’aumentare del numero di possibili errori che possono ren- dere i servizi di rete non disponibili. Ovviamente, queste considerazioni sono frutto di sperimentazioni fatte con software open-source e auto gestito; in uno scenario reale, l’utilizzo di soluzioni standard offerente da aziende leader diminuisce problemi di questa natura. Tuttavia, `e ragionevole pensare che non li estingua.
Gli sviluppi futuri sono innumerevoli. Lo scenario messo in campo ha permesso di acquisire familiarit`a con i diversi strumenti e comprenderne i limiti. Costituisce una base di partenza che verr`a migliorata per uno studio pi`u accurato delle possibilit`a offerte dal 5G. In particolare, potrebbe essere interessante approfondire: la messa in esecuzione dei gateway che si occupano del piano dati sulla parte edge del Cloud, la creazione di slice di rete in grado di soddisfare requisiti differenti, valutare l’adozione di native charms anzich´e proxy charms in modo da distribuire la potenza computazionale richiesta su pi`u V.M e introdurre la parte di configurazione di day 2 per il monitoraggio del core.