1 / 25

Alessio Bianchi

Gestione della mobilit à verticale su base applicazione : progetto e realizzazione per la piattaforma Android. Alessio Bianchi. Relatore : Prof. Francesco Lo Presti Co-relatori : Prof. Stefano Salsano , Ing . Marco Bonola. La mobilità verticale. UMTS.

chaeli
Download Presentation

Alessio Bianchi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Gestionedellamobilitàverticalesu base applicazione:progettoe realizzazioneper la piattaforma Android Alessio Bianchi Relatore: Prof. Francesco Lo Presti Co-relatori: Prof. Stefano Salsano, Ing. Marco Bonola

  2. La mobilità verticale UMTS • Nodo mobile che si sposta tra reti di accesso eterogenee(basate su IP) • Virtualmente nessuna interruzione delle comunicazioniin corso • Handover verticale 802.11

  3. Mobilità su base applicazione • Decisioni di handover differenziate per ciascuna applicazione • Scenario tipico: • Notebook connesso via WLAN e 3G • Videoconferenza + download aggiornamenti SO • In caso di disconnessione della WLAN • handover della videoconferenza su rete 3G • interruzione download aggiornamenti

  4. I problemidellamobilitàsu IP NAT1 Internet Default GW R1 LAN1 NAT2 IF1 CorrespondentHost (CH) R2 IF2 LAN2 Mobile Host (MH)

  5. La soluzione UPMT (1) Universal Per-application Mobility management using Tunnels

  6. La soluzione UPMT (2) AnchorNode (AN) “Secondlevel” NAT NAT1 Internet R1 LAN1 IF1 NAT2 IF2 VirtualIF CorrespondentHost (CH) R2 Mobile Host (MH) LAN2

  7. Incapsulamentoe instradamento • Incapsulamento UDP/IP: • Instradamento pacchetti nei tunnel tramite PAFT: Per-Application Forwarding Table • application flow  tunnel id UDP IP UDP or TCP IP Application payload Tunnel header IP src: realifaceaddress IP dst: AN address Original header IP src: virtualifaceaddress IP dst: CH address Application flow: <protocol, src IP, dst IP, src port, dst port>

  8. Obiettivi del lavoro di tesi • Implementare la gestione delle applicazioni in UPMT • Rilevare i flow di un’applicazione e instradarne i pacchetti sul tunnel corretto • Permetterel’handoversu base applicazione e per singolo flow • Supportare la definizione di politiche di handover su base applicazione • Porting deicomponentirealizzatisu Android

  9. Interface Architettura del Mobile Host Functioncall UPMT module UCE GUI Signaling Agent external module local socket UCE - UPMT Control Entity upmt-appmon Application Monitor DBUS Network Manager JNI NETLINK socket upmtconf User-space Kernel Exception filter NETLINK socket Modulo xt_UPMT Modulo upmt PAFT

  10. Il modulo xt_UPMT (1) • Rileval’apertura di flussi di rete da parte delleapplicazioni • Estensione di Netfilter e iptables con un target apposito: • Aggiungevocinella PAFT per instradarecorrettamente i pacchetti dei flussi di rete • Applica politiche di gestionedellamobilità per applicazione • Uso di specifici tunnel per un’applicazione • Applicazioni non gestitetramite UPMT • Impedisce al traffico locale, multicast e broadcast di essereinviato sui tunnel iptables -AOUTPUT -oupmt0 -mconntrack --ctstateNEW -j UPMT

  11. Il modulo xt_UPMT (2) xt_UPMTmantienele liste: Tunnel da usare per una data applicazione Inizializzata all’avvio della Control Entity con i tunnel specificati dalle politiche di ciascuna applicazione Le applicazioni non presenti in questa lista usano un tunnel di default Applicazioni che non devono essere gestite tramite UPMT Inizializzata all’avvio della Control Entity secondo le politiche utente

  12. Associazionetraflow e applicazioni Netfilter, e quindi il target UPMT, non può risalire al processo che ha generato un pacchetto Problema: Patch al kernel: aggiunta del campo tgid al socket buffer contenente il PID (tgid) del processo Soluzione: • In Linux desktop, tipicamente vale l’assunzione: • nome applicazione == nome file eseguibile su disco pid structmm_struct* structtask_struct* struct file* structdentry* exe_file: f_path: d_name: mm: dentry firefox-bin

  13. Gestione nuovi flow netlink flow per app politiche udp UCE - UPMT Control Entity upmt-appmon Application Monitor JNI flow, app paft new flow upmtconf User-space Kernel apps flow, app Modulo xt_UPMT Modulo upmt PAFT flow, tid

  14. Handover flow per app netlink politiche udp UCE - UPMT Control Entity upmt-appmon Application Monitor JNI app, tid app, tid paft flow, tid upmtconf flow, tid User-space Kernel apps Modulo xt_UPMT Modulo upmt PAFT

  15. Eccezioni per applicazione e per traffico locale • Scrittura di un hook Netfilterper intercettare tutti i pacchetti in uscita • Rerouting effettuato dall’hook per inoltrare i pacchetti verso l’interfaccia di uscita corretta Applicazioni da non gestire Per ogni interfaccia fisica: rotta per l’instradamento diretto sulla sottorete corrispondente Traffico sulla rete locale Traffico broadcast / multicast

  16. Porting su piattaforma Android • Kernel Linux (con qualche modifica) • Applicazioni scritte in Java, eseguite dalla Dalvik VM • Numerosi dispositivi e modelli  Grande diffusione • Open-source: GPLv2 per il kernel, Apache per la piattaforma

  17. Problemi affrontati nel porting (1) • Architettura ARM  cross-compilazione • bionic come libreria C (invece di glibc) • leggera, licenza Apache, no compatibilità binaria con glibc • No iproute2 • iptables compilato staticamente, non estendibile con target personalizzati • A livello kernel • No tabelle di routing multiple • No packet mangling

  18. Problemi affrontati nel porting (2) Applicazioni scritte in Java  il nome file eseguibile è quello della Dalvik VM! • I processi Android hanno il package name dell’applicazione nella cmdline (descrittore di memoria) • Lettura del primo argomento della cmdlinepackage name  nome applicazione Una sola interfaccia di rete attiva e connessa alla volta • Interfaccia 3G attiva solo se l’interfaccia wifi è spenta o non associata • Modifica del codice sorgente di Android per evitarlo ROM custom!

  19. Porting di UPMT su Android Componenti realizzati: compatibili con Android by design • Kernel custom: • Patch per il TGID nel socket buffer • Supporto a tabelle di routing multiple • Packet mangling in Netfilter • ROM custom: • Patch per più interfacce connesse contemporaneamente • iptables con target UPMT • iproute2

  20. to kang (verb): to take and make better Wifi e 3G connessi contemporaneamente! Kernel custom UPMT ROM custom

  21. Performance a livello di sistema Utilizzo CPU sull’Anchor Node Utilizzazione CPU [%] Utilizzo CPU sul Mobile Host Pacchetti generati [pacchetti/s]

  22. Performance a livello di utente (1)

  23. Performance a livello di utente (2)

  24. Sviluppi futuri • Porting su Android della Control Entity e, in particolare, della GUI • Miglioramenti sul Decision Maker: • Basato su misure di performance delle interfacce • Location-based mobility (per-ESSID, per-APN…) • Ottimizzazioni • Caching della corrispondenza TGID / nome app

  25. :wq Grazie per l’attenzione Alessio Bianchi

More Related