Always Best Packet Switching su Android x86

Transcript

1 Alma Mater Studiorum Università di Bologna FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Always Best Packet Switching su Android x86 Relazione del progetto di Sistemi Distribuiti Presentata da: Davide Malagoli Giulio Grassi Lara Codecá

2 Indice 1 Abstract 2 2 Introduzione 3 3 Parte tecnica RWMPC: Robust Wireless Multi-Path Channel Rilevamento errore nella comunicazione RWMPC: dettagli implementativi Monitor TED: Transmission Error Detector ULB: bilanciatore del carico UDP Porting Configurare l ambiente di lavoro Modifiche ed aggiunte Abilitazione wireless Riconoscimento dispositivi usb wvdial Bionic Creazione dell immagine ISO Valutazione risultati Successi Sorprese e imprevisti Wave Dial (wvdial) Conclusioni 16 1

3 Capitolo 1 Abstract Le infrastrutture di rete wireless stanno modificando il mondo delle reti di calcolatori e dispositivi mobili. I vantaggi che rendono questa tecnologia così richiesta sono la mobilità e la flessibilità. Gli svantaggi intrinseci invece sono i fenomeni di interferenza, riflessione, attenuazione e perdita di segnale a cui si aggiungono problemi di compatibilità e sicurezza. Parlando dei dispositivi mobili, si aggiungono problemi energetici legati al fatto che usiamo dispositivi a batteria. Il nostro scopo è supportare effettivamente servizi multimediali mobili. Attualmente, un dispositivo equipaggiato di più interfacce wireless eterogenee (NIC), non sfrutta a pieno le sue capacità. Infatti, le attuali architetture distribuite dedicate alla gestione della mobilità permettono al dispositivo mobile di selezionare ed usarne solo una per volta. Al contrario quello che si vuole adottare, il modello Always Best Packet Switching (ABPS)[2], fornisce un meccanismo che permette alle applicazioni di utilizzare simultaneamente tutte le interfacce disponibili, introducendo nuove funzionalità e la possibilità di creare politiche sia per il bilanciamento del carico che per il controllo della comunicazione. Questo meccanismo è gia implementato e funzionante su sistema operativo Linux, il prototipo presentato è per Android x86[1]. 2

4 Capitolo 2 Introduzione Lo scenario in cui si inserisce questo studio, prevede la presenza di un nodo mobile dotato di più interfaccie wireless con necessità di trasmettere uno stream audio. Il protocollo VoIP[3] necessita di requisiti di QoS precisi, come il ritardo della trasmissione inferiore ai 150ms e la perdita di pacchetti inferiore al 3% (linee guida ITU-T G.1010[4]). Per ottenere una infrastruttura wireless per la trasmissione affidabile di dati su dispositivi mobili abbiamo utilizzato un meccanismo chiamato Robust Wireless Multi-Path Channel (RWMPC)[2] che adotta il modello ABPS per soddisfare i requisiti di interattività e qualità del servizio (QoS) citati precedentemente. Il modello Always Best Packet Switching (ABPS) permette, avendo l opportunità di inviare e ricevere attraverso più interfaccie di rete, di trasmettere utilizzando sempre il canale migliore, dove il concetto di migliore si decide mediante un euristica (per esempio sono nocessarie euristiche differenti usufruendo di un contratto a pagamento con tariffa a tempo invece che tariffa a Byte trasmessi). L attenzione è focalizzata sul traffico UDP, utilizzato dalle applicazioni VoIP. Sfruttando i servizi di RWMPC, le applicazioni VoIP potranno stabilire e mantenere attivi differenti link con differenti access point (AP), i quali danno accesso a differenti reti cablate, in modo da selezionare per ogni pacchetto UDP il miglior link da usare per i fini della comunicazione. Il meccanismo RWMPC monitora ogni link in uso e notifica l applicazione se riscontra una perdita di datagram. In questo caso, l applicazione ritrasmette i dati usando un link alternativo, se disponibile, mediante una delle altre interfacce. Questo sistema è gia implementato nel sistema operativo Linux. Quello che vogliamo realizzare in definitiva è il porting dell approccio ABPS nella gestione della connettività wireless su una nuova piattaforma mobile. Per assicurarsi la compatibilità con i cellulari di recente generazione e con i computer portatili, abbiamo deciso di utilizzare Android TM [5]. Sviluppato da Google TM [6] in partner-ship con 50 aziende (Open Handset Alliance TM [7]), fornisce un set completo di software per dispositivi mobili: un sistema operativo, uno strato middleware e applicazioni mobili. Essendo basato sul kernel Linux, al quale è stato 3

5 aggiunto un interfaccia grafica personalizzata ed altri strumenti, risulta comunque possibile replicare lo stesso metodo utilizzato per computer fissi o laptop questa volta applicato a dispositivi mobili. Nella realtà il porting è stato effettuato per Android x86, che attualmente non ha una compatibilità completa con Android TM. Il progetto Android x86 è giovane e in costante evoluzione. Lo scopo di quest ultimo è ottenere una piattaforma per x86 completamente compatibile con Android (piattaforma arm) per permettere a tutti di implementare applicazioni Android, eseguire i test su un comune laptop, e solo infine cross-compilarle per architetture arm. Nei capitoli successivi introdurremo ABPS e lo strato RWMPC che lo implementa. Descriveremo il lavoro eseguito su Android TM, evidenziando le parti da modificare per supportare il nuovo approccio. Analizzeremo gli obbiettivi, gli aspetti progettuali e le fasi implementative utilizzate per lo svolgimento del lavoro, concludendo con alcune valutazioni dell effettivo beneficio apportato dall utilizzo di queste tecniche per la comunicazione mobile wireless. 4

6 Capitolo 3 Parte tecnica 3.1 RWMPC: Robust Wireless Multi-Path Channel La progettazione di RWMPC è basata su un approccio cross-layer grazie al quale é possibile acquisire dati provenienti dai diversi livelli di astrazione dello stack ISO/OSI, dai quali é possibile ottenere informazioni sulla qualitá del canale di comunicazione. Questi dati vengono usati dall applicazione al fine di eseguire il monitoraggio dei link di comunicazione wireless usati per la trasmissione della voce. Gli elementi che caratterizzano questo tipo di approccio rispetto ad altri giá esistenti sono i seguenti: un meccanismo di monitoraggio rileva se ogni datagram UDP è stato perso durante la trasmissione tra l interfaccia del dispositivo mobile e l access point con il quale è associato; in aggiunta, comunica queste informazioni all applicazione che ha prodotto il datagram perso. Anche se limitato, questo monitoraggio risulta essere molto importante perché in una comunicazione tra due nodi mobili il punto critico per la perdita di pacchetti sono i link wireless, presenti appunto tra il nodo mobile e il primo hop (access point). l applicazione può ritrasmettere ogni datagram UDP VoIP perso usando interfacce differenti Rilevamento errore nella comunicazione Nelle specifiche IEEE b/g/n [14, 15, 16], durante una comunicazione tra due nodi, il ricevente (in questo caso l access point) invia in risposta un messaggio (ack) al fine di confermare al mittente che il frame unicast è stato ricevuto. Quando i dati o gli ack sono persi, il livello MAC del mittente ritrasmette il frame sul collegamento wireless finché il numero di ritrasmissioni raggiunge un limite predeterminato. Superato questo limite, il livello MAC rileva l errore, ma rigetta 5

7 Figura 3.1: Schema dei componenti di RWMPC e delle loro interazioni silenziosamente i frame, senza generare nessuna notifica. I dati scartati non arriveranno mai a destinazione: la loro perdita può essere riconosciuta dal livello applicazione troppo tardi per effettuare una procedura di recupero, come descritto nel precedente punto. Nel modello ABPS, quando il livello MAC rileva questo tipo di errore, notifica la mancata trasmissione del frame all applicazione che ha generato il flusso di dati, in modo da permettere una corretta e soprattutto tempestiva procedura di recupero. 3.2 RWMPC: dettagli implementativi RWMPC é composto principalmente da 3 elementi: TED (Trasmission Error Detector): si occupa di rilevare se un frame inviato ha raggiunto oppure no l access point Monitor: gestisce le varie interfacce di rete ULB (UDP Load Balancer): gestisce la trasmissione dei pacchetti voci sulle interfacce di rete disponibili. La figura 3.1 mostra nel dettaglio le interazioni tra le varie parti che compongono questo meccanismo ed il sistema ospite Monitor Configura dinamicamente le interfacce wireless e le regole di routing, notificando il componente ULB quando sono state configurate con successo e sono pronte 6

8 ad essere usate. A livello datalink vengono svolte le operazioni che permettono ad ogni scheda wireless di individuare la presenza di AP e la relative configurazioni per la comunicazione e le operazioni per la gestione delle interfacce quando un access point non é piú raggiungibile. Questi compiti vengono svolti dal processo wpa supplicant, il quale racchiude tutte le funzionalità relative all autenticazione e la sicurezza delle reti. wpa supplicant guida l adattatore wireless nell effettuare lo scan dei canali radio per individuare gli AP dei quali conosce le informazioni di autenticazione. Se più AP sono disponibili, wpa supplicant seleziona quello che ha il miglior segnale radio, eseguendo la procedura di associazione. Grazie ad alcune modifiche wpa supplicant non permette che due diverse interfacce si associno allo stesso AP. Dopo che wpa supplicant ha configurato il livello data link di una interfaccia wireless, associandola ad un dato AP, il kernel informa il Monitor, il quale avvia il client DHCP. Quest ultimo richiede un indirizzo IP, una maschera di rete ed un gateway. Quando il client termina correttamente la configurazione del livello network dell interfaccia, il Monitor crea una nuova regola ip ed una nuova tabella di routing (tramite i comandi ip rule ed ip route) al fine di avere un routing dinamico tramite quella interfaccia. Questa regola e tabella di routing impone ad un datagram IP che ha lo stesso indirizzo IP sorgente dell interfaccia, di essere inviato tramite quest ultima, indipendentemente dall IP della destinazione. Una volta configurata con successo, la scheda può essere usata dal componente ULB. Quando infine perde l associazione con l AP il driver dell adattatore avvisa il kernel, il quale comunica al Monitor di disabilitare l interfaccia e di eliminare le regole di routing su di essa finché non é disponibile nuovamente una rete TED: Transmission Error Detector Questo componente che lavora tra i livelli trasporto, network e datalink, ha il compito di individuare i frame per i quali il dispositivo non riceve l ack dall AP. TED implementa due strumenti: un sistema per l estrazione degli identificativi dei frame inviati dalle interfacce di rete: la syscall sendmsg, la quale é responsabile della trasmissione dei datagram UDP, é stata modificata per fornire all ULB l identificativo del datagram inviato. un sistema di notifiche implementato a livello MAC dello stack wireless; a questo livello si hanno le informazioni sulla sorte dei pacchetti inviati. Queste informazioni vengono notificate all ULB, che le associa al pacchetto inviato tramite l id giá citato. 7

9 3.2.3 ULB: bilanciatore del carico UDP Il componente ULB è responsabile della trasmissione dei pacchetti voce attraverso tutte le interfaccie disponibili, oltre che del recupero di possibili pacchetti persi. Riceve le notifiche degli errori dal componente TED e decide se il datagram UDP perduto debba essere ritrasmesso, Inoltre, basandosi su notifiche ricevute dal TED, decide quale interfaccia wireless tra quelle disponibili usare per le successive trasmissioni. ULB riceve informazioni su tutte le interfacce da parte del Monitor e crea un socket UDP per ognuno di essi, usando la system call bind per assegnare l indirizzo IP dell adattatore in questione al socket associato. Grazie alle regole di routing create dal Monitor, tutti i datagram appartenenti ad un dato socket saranno instradati tramite la relativa interfaccia al quale il socket è stato associato. 8

10 Capitolo 4 Porting Configurare l ambiente di lavoro Per la creazione di Android è necessario utilizzare un sistema operativo Linux o Mac OS. Il build di Android è testato di solito sulle recenti versioni di Ubuntu (6.06 e successive), ma è ovviamente compatibile con quasi tutti gli altri sistemi GNU/Linux. Per poter utilizzare il monitor all interno della shell di Android si é reso necessario potenziare quest ultima aggiungendo dei comandi. Per fare ció é stato utilizzato busybox, che combina diverse applicazioni standard di Unix in un piccolo eseguibile Modifiche ed aggiunte Principalmente le modifiche o aggiunte apportate al sistema si suddividono in tre tipologie: modiche al kernel, alle applicazioni e agli script di build e boot. Per quanto riguarda il kernel, sono stati modificati i seguenti files: /android-abps/kernel/net/ipv4/ip output.c /android-abps/kernel/net/ipv4/ip sockglue.c /android-abps/kernel/net/ipv4/udp.c /android-abps/kernel/net/mac80211/makefile /android-abps/kernel/net/mac80211/main.c /android-abps/kernel/net/mac80211/tx.c /android-abps/kernel/include/net/ip.h /android-abps/kernel/include/linux/errqueue.h 9

11 Queste parti sono state estratte dai sorgenti del kernel già precendentemente sviluppati sul kernel rc5. I nuovi files che sono stati aggiunti per supportare le nuove funzionalità sono: /android-abps/kernel/net/mac80211/abps mac80211.c /android-abps/kernel/net/mac80211/abps mac80211.h É stato necessario inoltre modificare la configurazione del kernel per includere il supporto del maggior numero di schede tramite i moduli appropriati. Per quanto riguarda le applicazioni l unico programma richiesto per l implementazione del meccanismo RWMPC é il Monitor. Infatti wpa supplicant è già presente tra i sorgenti di Android, al quale andrebbero apportate le modifiche per la selezione di differenti AP sulle varie schede wifi. Per lo scopo di questo lavoro e a causa dello stato ancora sperimentale delle modifiche su wpa supplicant è stato scelto per il momento di non apportarle. Visto peró che ogni interfaccia gestita dal Monitor era associata ad una istanza differente di wpa supplicant, é stato possibile ottenere lo stesso risultato manipolando i file di configurazione utilizzati dalle varie istanze. Insieme al Monitor sono stati inclusi inoltre i due tool per il test del meccanismo RWMPC chiamati recvudp e sendudp Abilitazione wireless Nella versione di Android in nostro possesso, ottenuta dal repository ufficiale di Android, non era abilitato l utilizzo di WiFi, perció, per poter instaurare connessioni wireless si é reso necessario modificare il file di configurazione utilizzato per stabilire alcune impostazioni del sistema, abilitando per l appunto il supporto alla connessione WiFi Riconoscimento dispositivi usb Poter utilizzare il meccanismo RWMPC anche usando dispositivi usb per la connessione ad internet é molto importante perché, soprattutto nell ambito delle tecnologie 3G, attualmente in commercio, oltre ai modem integrati, sono molto diffusi anche i modem usb; inoltre, anche per quello che riguarda i dispositivi WiFi sono presenti in commercio periferiche usb, anche se in questo caso molto meno diffuse rispetto alle schede integrate. Per poter utilizzare su Android anche dispositivi usb per la connessione ad internet si sono rese necessarie alcune modifiche a file di configurazione, oltre all aggiunta di alcune librerie, i cui sorgenti sono stati scaricati dal repository della distribuzione linux Ubuntu. Le librerie che sono state aggiunte sono le seguenti: 10

12 libusb usb modeswitch usbutils wvdial 1.60 Di base su Android per architetture x86 non sono presenti strumenti per l utilizzo di interfacce 3G per la connessione ad internet. Per superare questo problema si é reso necessario fare il porting di wvdial, uno dei programmi piú diffusi in ambiente linux per la gestione di connessioni ad internet basate su modem, come per l appunto le tecnologie 3G. Il porting su android del pacchetto wvdial 1.60 é stato fatto partendo dai sorgenti scaricati dai repository della distribuzione Ubuntu Dipendenze di wvdial Android, basandosi su una versione ridotta di un sistema Linux, non contiene alcuni pacchetti e alcune librerie che invece si trovano normalmente di base in un sistema Linux. Per questo il porting di wvdial su Android comporta l inclusione di alcune librerie non presenti (libwvstreams), oltre che la modifica di alcune definizioni di funzioni e macro presenti nelle librerie bionic di Android. Come per il pacchetto di wvdial, anche le librerie mancanti sono state prese dal repository di Ubuntu. I pacchetti aggiunti per poter utilizzare wvdial sono i seguenti: ucontext libwvstream pppd regex crypt libc stack end Bionic Molte delle modifiche descritte in precedenza per portare a termine il porting dei pacchetti mancanti sono state necessarie perchè Android non contiene una versione delle libc completa, ma solo una sua versione ridotta che prende il nome 11

13 di Bionic. I motivi che hanno portato gli sviluppatori di Android a fare questa scelta sono principalmente 3: licenza: si è voluto lasciare fuori dall user space tutto il codice con licenza GPL e le Bionic usano una licenza BSD. dimensioni: queste librerie devono essere caricate in ogni processo, perciò devono essere di dimensione ridotta, soprattutto quando si utilizza dispositivi come cellulari. velocità: Android nasce per cellulari, quindi per dispositivi che non hanno una elevata potenza di calcolo (messi a confronto con dei PC), perciò é necessario avere delle librerie che siano il più leggere possibili per quello che riguarda la velocità di esecuzione. Durante il nostro lavoro abbiamo cercato di lasciare il più intatto possibile la struttura delle librerie Bionic infatti tranne la signature di una system call tutto il resto delle funzioni mancanti sono state inserite in external con tutte le modifiche da noi appportate, e riunite nella libreria libmissing Creazione dell immagine ISO Un immagine ISO é un file contenente l intero contenuto di un disco ottico che puó essere inciso su di un supporto fisico tramite processo di masterizzazione oppure utilizzato direttamente, tramite software di emulazione. Un immagine ISO puó contenere un intero file system e i relativi metadata, comprese le informazioni sulla fase di boot. Tramite questo unico file puó venir utilizzato un sistema operativo sulla propria macchina senza aver la necessitá di doverlo installare su di essa. Ció comporta peró il limite di non poter accedere in scrittura al file system della root. Per poter avere un prodotto finito funzionante e facilmente utilizzabile abbiamo creato un immagine live del sistema Android con le modifiche sopra descritte, utilizzando una funzionalitá apposita del comando make usato per compilare Android. Una volta ottenuta l immagine di sistema, non avendo a disposizione una macchina reale su cui poter testare il meccanismo RWMPC, é stata creata una macchina virtuale usando VMWare. 12

14 Capitolo 5 Valutazione risultati Come precedentemente detto, esisteva giá una implementazione funzionante di ABPS per macchine Linux, non c é quindi da stupirsi che gran parte del nostro operato sia stato costellato di successi, poiché anche Android é basato sul medesimo sistema operativo. Nel corso del nostro lavoro abbiamo tuttavia incontrato anche una serie di sorprese e imprevisti. Uno di questi imprevisti in particolare ci ha impedito di ultimare l implementazione ed il testing di wvdial su Android, per cui ne parleremo in modo piú diffuso. 5.1 Successi Siamo riusciti con successo a: 1. configurare correttamente una interfaccia wifi (mediante wpa supplicant) 2. integrare la gestione dell interfaccia wireless all interno del gestore wifi di Android 3. apportare le modifiche al kernel per permettere la notifica dei pacchetti persi 4. integrare il monitor e i tool di test di ABPS all interno dell ambiente di Android x86 5. permettere il rilevamento automatico di chiavette UMTS USB 5.2 Sorprese e imprevisti Con nostra enorme sorpresa, abbiamo notato che é abbastanza facile aggiungere o modificare funzionalità di pacchetti già presenti senza pregiudicare le funzionalitá preesistenti. 13

15 Non é peró altrettanto facile aggiungere software da zero ai sorgenti di Android. In particolare, in Android le opzioni di compilazione non vengono specificate mediante GNU Makefiles, ma attraverso Android.mk, che sono un dialetto dei Makefile, specifico per Android. Non esiste un modo per generare in automatico gli Android.mk dato un Makefile, in quanto si reputa che i Makefile possano potenzialmente mostrare strutture troppo complesse per essere trattati da un qualunque script automatico. Questo implica che la generazione dei Makefile di Android doveva essere fatta a mano, e questo ci ha rallentato un po. Anche in fase di compilazione abbiamo dovuto riscontrare una pessima abitudine dei tool che usavamo: é possibile specificare i percorsi delle librerie, ma se una libreria non viene trovata nel path di Android il compilatore utilizza i percorsi di default della macchina ospite. Questa scelta non ci é sembrata ottima, soprattutto perché non esiste nessuna forma di feedback per identificare quando il problema si presenta, ed introduce una dipendenza basata sull ambiente della macchina ospite piuttosto che sull ambiente di Android. Abbiamo ridotto l incidenza di questo problema creando un ambiente controllato, diverso dall ambiente del nostro sistema, mediante chroot, ed utilizzando tutti lo stesso ambiente. Normalmente un software puó accedere a tutti i dischi e le risorse del sistema operativo, compatibilmente con i permessi; L operazione di chroot consiste nell eseguire il programma bloccato dentro una sottodirectory, permettendogli di accedere solo alle risorse di cui ha strettamente bisogno. Android non possiede una implementazione completa delle librerie C, in quanto la disponibilitá di capacitá di calcolo e memoria di un dispositivo mobile sono nettamente inferiori ad un sistema standard. Questo ci ha portato a confrontarci piú volte con il problema delle funzioni mancanti. Generalmente il problema é stato risolto prendendo in prestito dei brani di codice dalle librerie standard C 1 e portandoli su Android Wave Dial (wvdial) Wave Dial é decisamente il componente che ha richiesto piú lavoro di tutti, ma ne valeva la pena. Questo software é l unico riconosciuto per la sua capacitá di configurare qualsiasi tipo o quasi di modem 3G usb, ed era quindi vitale per il tipo di test che ci era stato richiesto. Wvdial si appoggia sulle librerie libuniconf, le quali si basano su un altra serie di librerie ed eseguibili, tra cui libwvstreams e pppd. L albero completo delle sue dipendenze é molto vasto, e quindi un primo passo é stato quello di capire quali erano opzionali e quali invece obbligatorie, per non sforare con i tempi. Fatto questo, ci siamo scontrati piú volte con la mancanza di alcune funzionalitá nelle librerie Bionic, come menzionato nel paragrafo precedente, e siamo stati 1 ci siamo basati sulla versione glibc 2.9 disponibile per Ubuntu

16 costretti ad aggiungerle. Tutto sembrava funzionare bene, fino a che non siamo incappati nella mancanza della syscall setenv. Nelle librerie C infatti per ogni syscall esiste un file, scritto in assembly, che imposta lo stack per la chiamata della funzione, che viene quindi richiamata generando un interrupt per il sistema operativo [8]. Non era chiaro come si dovessero generare questi file, e soprattutto come generarli per l assembler x86. Siccome la syscall setenv operava sullo stack del processo chiamante, spostando il puntatore del frame corrente, anche solo un piccolo errore poteva portare ad instabilitá nel funzionamento del processo e del sistema, potenzialmente creando accessi incondizionati ad aree di memoria arbitrarie. Abbiamo cosí deciso di fermarci qui, visto che i tempi di implementazione e di testing rischiavano di risultare troppo lunghi. 15

17 Capitolo 6 Conclusioni Il porting dell infrastruttura gia presente su sistema operativo Linux é avvenuto correttamente per quanto riguarda la parte WiFi. Le modifiche apportate all interno dello stack funzionano, il monitor é capace di gestire le interfacce WiFi e il programma di testing riceve le informazioni aggiuntive di cui necessita. Riguardo la parte delle tecnologie 3G, il porting del demone ppp é andato a buon fine, il gestore delle interfacce USB attualmente le riconosce appropriatamente e le dispone in /dev. Il problema riguarda il modulo wvdial, per la gestione delle connessioni modem-based. Infatti wvdial si appoggia alla libreria libwvstreams; questa si appoggia a delle chiamate di sistema presenti nelle libc6 ma non nella loro versione presente nelle librerie Bionic. In pratica si é ad un punto cruciale: il porting di tutte le dipendenze delle libwvstreams é avvenuto con successo, se con l avanzamento del progetto Androidx86(1) aggiungeranno altre system call (cosa giá avvenuta precedentemente per un altra chiamata di sistema necessaria sempre alle libwvstreams) é possibile che il porting sia definitivo e funzionante. Un altra possibile soluzione vede l utilizzo di un modulo equivalente a wvdial che non necessiti delle libwvstreams e che si appoggi direttamente al demone ppp. Per ora questa alternativa non é stata trovata. 16

18 Bibliografia [1] Android x86 [2] V. Ghini, G. Lodi, F. Panzieri, Always Best Packet Switching: the Mobile VoIP Case Study, Journal of communications, vol. 4, no. 9, Ottobre 2009 [3] Autori vari: IETF, ISI, Voice Over IP, Website, [4] ITU-T Recommendation G.1010, TRANSMISSION SYSTEMS AND ME- DIA, DIGITAL SYSTEMS AND NETWORKS, Quality of service and performance [5] Android TM [6] Google TM [7] Open Handset Alliance TM [8] Funzionamento delle syscall in Linux 17