sistemi informatici mobili

SISTEMI INFORMATICI MOBILI
VinX
Indice
1 Introduzione
1.1 Da dove veniamo . . . . . . . . . . . . . . . .
1.2 Dove andiamo . . . . . . . . . . . . . . . . . .
1.2.1 Struttura base di un sistema nomadico
1.2.2 Modello a clessidra . . . . . . . . . . .
1.2.3 Mattoni e clessidra . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
2
3
2 Applicazione ed Interfacce
2.1 Adattabilità e trasparenza . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Adattamento dei dati . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Interazione e/o distribuzione componenti: Estensione modello
2.1.3 Mobilità del codice . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Cambiamento: altri modelli . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Architettura tuple space . . . . . . . . . . . . . . . . . . . . .
2.2.2 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Peer-To-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Livello orizzontale . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6 Livello verticale . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Piattaforme orizzontali: WWW . . . . . . . . . . . . . . . . . . . . .
2.3.1 Nuove tecnologie . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Rimedi a livello architetturale . . . . . . . . . . . . . . . . . .
2.4 Piattaforme Orizzontali: WAP . . . . . . . . . . . . . . . . . . . . .
2.4.1 WAP2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Piattaforme Orizzontali: I-Mode . . . . . . . . . . . . . . . . . . . .
2.6 Piattaforme Orizzontali: J2ME . . . . . . . . . . . . . . . . . . . . .
2.7 Impatto sul sistema operativo . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
client/server
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
6
9
9
11
12
12
13
14
15
15
15
16
19
20
20
21
3 Comunicazione Wireless
3.1 Caratteristiche . . . . . . . . . . . . . . . . .
3.2 Modalità di utilizzo . . . . . . . . . . . . . . .
3.2.1 Tecniche di condivisione . . . . . . . .
3.2.2 Regole d’uso delle tecniche (protocolli)
3.3 Wireless LAN . . . . . . . . . . . . . . . . . .
3.3.1 Protocollo IEEE802.11 . . . . . . . . .
3.3.2 802.11: livello logico MAC . . . . . . .
3.4 HiperLAN . . . . . . . . . . . . . . . . . . . .
3.5 Wireless WAN . . . . . . . . . . . . . . . . .
3.5.1 GSM . . . . . . . . . . . . . . . . . . .
3.5.2 GPRS . . . . . . . . . . . . . . . . . .
3.5.3 Wireless 3G . . . . . . . . . . . . . . .
3.5.4 UMTS . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
23
23
23
26
27
28
35
36
36
37
38
39
4 Gestione della mobilità
4.1 Algoritmi di Tracking . . . .
4.1.1 Tracking Esplicito . .
4.1.2 Tracking Implicito . .
4.1.3 Tracking Ibrido . . . .
4.2 Reti con infrastruttura . . . .
4.2.1 Routing per nodo . . .
4.2.2 Cambiare indirizzo IP
4.2.3 MobileIP . . . . . . .
4.2.4 Cellular IP . . . . . .
4.2.5 HAWAII . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
41
41
41
42
42
42
44
57
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.3
4.4
4.5
4.6
HMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reti senza infrastruttura . . . . . . . . . . . . . . . . . . . .
4.4.1 DSDV . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 OLSR . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 DSR . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.4 Routing gerarchico . . . . . . . . . . . . . . . . . . .
4.4.5 Metriche di routing: LRI . . . . . . . . . . . . . . .
Reti cellulari . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Architettura del GSM . . . . . . . . . . . . . . . . .
4.5.2 Architettura del GPRS . . . . . . . . . . . . . . . .
4.5.3 Operazioni: GSM/GPRS . . . . . . . . . . . . . . .
4.5.4 GPRS Architettura del protocollo di comunicazione
TCP in reti mobili . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Problemi TCP in ambiente mobile . . . . . . . . . .
4.6.2 Indirect TCP (I-TCP) . . . . . . . . . . . . . . . . .
4.6.3 Snooping TCP . . . . . . . . . . . . . . . . . . . . .
4.6.4 MobileTCP . . . . . . . . . . . . . . . . . . . . . . .
4.6.5 Fast Retrasmit/Fast Recovery . . . . . . . . . . . . .
4.6.6 Selective Retransmission (SACK) . . . . . . . . . . .
4.6.7 Transaction Oriented TCP . . . . . . . . . . . . . .
4.6.8 Confronto tra i diversi approcci . . . . . . . . . . . .
4.6.9 Miglioramenti a TCP per reti cellulari . . . . . . . .
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
62
62
63
64
65
66
66
67
67
69
71
72
74
75
76
77
77
77
77
78
1
Introduzione
I sistemi informatici mobili possono essere visti come sistemi distribuiti aventi le seguenti proprietà:
• ubiquità: disponibilità di interconnessione in rete su scala globale;
• nomadicità: disponibilità di servizi anche lontano dall’ambiente di riferimento;
• pervasività: presenza diffusa di servizi anche in ambienti non specifici.
In altre parole sono sistemi distribuiti dove la posizione delle entità cambia durante il loro ciclo di vita.
Qui di seguito sono elencati alcuni esempi che descrivono questo tipo di sistemi:
• Commesso viaggiatore: gli archivi sono centralizzati e consistenti, mentre l’utente si può connettere
da qualsiasi postazione.
• Rimpiazzamento di reti fisse: vengono sostituite reti con sensori remoti, lan in edifici storici, ecc...
• Divertimento, istruzione, ecc...: accesso ad Internet in ambienti esterni, guida di viaggio intelligente con informazioni aggiornate adattate alla posizione attuale oppure reti ad-hoc per giochi
multiplayer.
• Servizi “location aware”: sono servizi come stampante, telefono, fax, ecc... che si trovano nella rete
locale.
• Servizi “follow on”: trasmissione dell’ambiente di lavoro verso la posizione attuale, come ad esempio
l’inoltro automatico delle chiamate.
• Servizi di informazione: vengono suddivisi in servizi “push” (ad esempio offerte speciali che sono
fatte in un supermercato in un determinato istante) e servizi “pull” (ad esempio conoscere dove si
trova la pasticceria più vicina).
• Servizi di supporto: permettono il caching, informazioni di stato e seguono il dispositivo mobile
attraverso la rete fissa.
1.1
Da dove veniamo
I nodi in un sistema distribuito tradizionale sono inamovibili. Ogni nodo ha un’elevata potenza di calcolo,
un’elevata memoria ram, numerosi dispositivi di i/o ed energia illimitata. La comunicazione tra nodi
invece viene attuata da supporti fisici basati su cavi di varia natura. Questi possiedono una banda elevata
ed un tasso di errore (ber) molto piccolo.
osi
Livello
Protocollo
2
3
Datalink
Network
mac
ip
4
Trasporto
udp/tcp/rpc
5
Session
Application
6
7
Presentation
Application
Instradamento nodo-nodo
Algoritmi di routing: distance vector, link state
Comunicazione tra processi end-to-end con diverse proprietà:
udp asincrono demultiplexing service
tcp reliable byte stream service
rpc request reply service
Basi di dati, filesystem, sistemi ipertestuali.
Ogni applicazione è basata su punti di vista
ovvero la tipologia di applicazioni abilitate
ad entrare in contatto con quel tipo di dato.
Il middleware è un livello intermedio tra il sistema operativo e le applicazioni, ciò alza il livello di
astrazione della macchina. Un esempio di middleware può essere rappresentato dalle api per applicazioni
distribuite object-oriented.
Dobbiamo notare che per ogni applicazione viene utilizzata una specifica tipologia di dati. Le basi di
dati, ad esempio, forniscono un accesso ad un insieme di strutture dati sulle quali compiono operazioni
1
relazionali. Mentre un filesystem è composto da un insieme di oggetti con nome, struttura gerarchica ed
operazioni.
I dati possono contenere informazioni isocrone, ovvero oggetti che devono essere ricevuti e decodificati in
sincronia sia in ricezione che in trasmissione. Invece i dati push permettono la diffusione dell’informazione
da una sorgente ad una molteplicità di utenti dichiarati (sottoscrittori) o potenziali.
1.2
Dove andiamo
Ciò che abbiamo detto nel paragrafo precedente sarà esteso in modo da poter definire cos’è un sistema
nomadico, in particolare questo genera nuovi problemi rispetto ai sistemi statici. Infatti nei sistemi
statici quello che cambia è l’esecuzione, mentre nei nomadici la regola. I cambiamenti possono riferirsi
alla posizione dei nodi ed oggetti, al controllo della visibilità di ogni posizione e dell’interoperabilità tra
nodi. Quindi vogliamo che in un sistema nomadico siano presenti questi comportamenti.
Notiamo che i nodi facenti parte dei sistemi nomadici possiedono una potenza di calcolo e memoria molto
variabile tra loro quindi bisogna far coesistere questi nodi nel sistema. Inoltre il canale di comunicazione
si basa su radio frequenze e la banda è anch’essa soggetta ad un’alta varianza.
Un sistema nomadico possiede gli stessi parametri di interesse rispetto ai sistemi statici, ma siccome i
nodi si spostano, sono piccoli e leggeri, allora i risultati di interesse cambiano drammaticamente durante
il movimento di ogni singolo nodo. Quindi il primo problema consiste nel garantire la comunicazione tra
i nodi quando sono in movimento.
1.2.1
Struttura base di un sistema nomadico
La soluzione generale per alcuni problemi consiste nello stabilire delle “ricette” condivise da tutti o
comunque dalla maggioranza. Tale approccio risulta vantaggioso per l’utente perché può confrontare
più prodotti dai vari fornitori. Quindi bisogna definire un adattamento, ovvero la capacità di reagire e
comportarsi bene in un ambiente che può cambiare rapidamente.
1.2.2
Modello a clessidra
Per i sistemi distribuiti classici si utilizza il modello a strati, ovvero uno stack di protocolli. Tale approccio
non è adeguato per i sistemi che stiamo trattando, infatti si presuppone che il sistema sia omogeneo e
di conseguenza si dà troppa importanza alla comunicazione. Anche l’utilizzo di un comune middleware
risulta non sufficiente a risolvere questo problema.
Il modello a clessidra consiste nell’utilizzare uno speciale middleware che deve essere in grado di
gestire risorse distribuite su scala globale. Tuttavia molto spesso la trasparenza delle risorse non è
garantita da questo tipo di middleware. Ciò nonostante, l’interfaccia fornita da questi middleware non
è esente da problemi causati dalla lontananza delle risorse. Quindi il middleware può essere visto come
una generalizzazione del sistema operativo a livello globale. Tuttavia il collo di bottiglia è presente a
livello di rete. Di conseguenza bisogna utilizzare una grande varietà di tecnologie che sfruttano i vari
livelli dello stack di protocolli.
2
Non è possibile costruire un sistema automatico proprio per la grande varietà di contesti ed elementi
da gestire, sopratutto quando i protocolli di basso livello sono stati standardizzati mentre quelli di alto
livello sono ancora in corso di definizione.
Purtroppo l’utilizzo del protocollo ip è estremamente vincolante dato che i sistemi nomadici sono
molto eterogenei. L’ip backbone fornisce un supporto all’interazione tra sistemi eterogenei aventi reti
fisse e mobili, dove gli handover verticali consistono nel passare da una tipologia di rete ad una diversa
(si espande in ampiezza), mentre gli handover orizzontali consistono nel passare da una rete all’altra
dello stesso tipo.
1.2.3
Mattoni e clessidra
Per quanto riguarda il livello applicativo dobbiamo trattare aspetti come l’architettura software, il middleware ed il sistema operativo. In un sistema nomadico la comunicazione non si esaurisce durante la
comunicazione mobile, pertanto sorgono i seguenti problemi:
• disomogeneità hardware, ovvero bisogna supportare le diverse capacità di elaborazione dei nodi;
• movimento fisico, tipicamente molto rapido;
• movimento logico, ovvero l’attraversamento di domini amministrativi.
L’adattamento in un sistema nomadico a livello di rete genera il problema sulla gestione degli handover/
prefetching, mentre a livello applicativo bisogna adottare una codifica multi-livello ed una riallocazione
dinamica. Per garantire la mobilità del sistema bisogna quindi adottare una speciale tecnologia che
permetta di spostare sia i nodi (con l’handover per la mobilità su piccola scala e localizzazione su grande
scala) che le reti (con l’uso del routing e reti di ad-hoc). Bisogna inoltre specificare quali canali wireless
utilizzare per far dialogare diversi sistemi tra loro, senza contare che è necessario definire una politica
per la gestione dell’energia.
3
2
Applicazione ed Interfacce
Un sistema nomadico non è rappresentato da un solo sistema di comunicazione mobile. Nel precedente
capitolo abbiamo visto che sono presenti un gran numero di problematiche legate al sistema che spaziano
dalla disomogeneità dell’hardware ai vincoli sulle prestazioni, dal movimento fisico a quello logico. Tali
problematiche impattano a livello architetturale sia di quello del middleware che su quello del sistema
operativo.
Il problema relativo alle applicazioni ed interfacce verrà trattato sotto tre aspetti:
1. architettura software: dove parleremo di adattamento e/o cambiamento.
2. middleware.
3. sistema operativo.
L’architettura software è la strutturazione di un’applicazione in:
• componenti: avendo a che fare con un ambiente di nodi mobili aventi risorse limitate, si suggerisce
di collocare la maggior parte delle funzionalità sui nodi della rete fisica, tuttavia l’inaffidabilità
della rete wireless ci suggerisce di collocare tali funzionalità sui nodi mobili.
• modalità di interazione: è necessario capire se l’approccio classico di richiesta/risposta sia adatto
in un sistema nomadico.
2.1
Adattabilità e trasparenza
Per poter rispettare i vincoli definiti per questo tipo di sistemi siamo costretti ad adottare soluzioni
differenti per ognuno di questi, ciò implica che per ottenere una soluzione che accomuna le singole
decisioni prese per ogni vincolo bisogna costruire una “versione” dell’architettura che si adatta al variare
delle condizioni ambientali. Per fare ciò bisogna innanzitutto identificare quale modello sia adattabile e
quale livello di trasparenza devono avere le applicazioni.
L’adattabilità può quindi essere realizzata in due modi, variando:
1. la qualità dei dati disponibili ai nodi mobili, ovvero cambiare il grado di fedeltà rispetto all’originale.
2. la modalità di interazione: partizionamento variabile dei compiti tra nodi mobili e nodi di rete
fissa. Data una una certa strutturazione cambio le varie parti, ad esempio la mobilità del codice.
Occorre poi trattare problemi su quale elemento sarà il responsabile della realizzazione dell’adattamento.
Quindi bisogna definire il grado di trasparenza nei seguenti casi:
1. application transparent: al di sotto dell’applicazione ci sarà un qualcosa che cerca di appiattire
l’eterogeneità in modo da permettere di lavorare a livello applicativo come se non esistessero. Ma
dato che non si ha il controllo completo dell’adattabilità la soluzione potrebbe essere non ottimale.
2. laissez-faire: nel livello inferiore all’applicazione vengono passate solo informazioni e parametri.
Ciò non richiede il supporto del sistema ma ha potenziali problemi dovuti all’assenza di arbitraggio
e richiede un grande sforzo di sviluppo.
3. application aware: consiste in una collaborazione tra chi sta sotto e chi sta al livello superiore. Ad
esempio un’applicazione che sfrutta le informazioni provenienti dal livello inferiore per realizzare
qualche forma di adattamento, nel caso in cui non riesca può chiedere aiuto al livello sottostante.
2.1.1
Adattamento dei dati
Il problema in questo caso consiste in una sorgente che spedisce ad un destinatario attraversando
collegamenti con capacità diverse.
4
Per risolvere tale problema si usa l’adaptation agency, ovvero si associa un’entità ad ogni (non necessariamente) nodo.
La struttura aa è composta dal modello rappresentato nella seguente figura dove i componenti interni
sono:
• event manager (em): vengono considerati gli eventi rilevanti per pilotare la qualità, ovvero per
pilotare l’adattamento. Tale componente ha il compito di informarsi sugli eventi o caratterizzare
uno stato. Ad esempio la sicurezza oppure le informazioni appartenenti ad altri nodi.
• resource manager (rm): gestisce le risorse necessarie all’adattamento.
• application specific adapter (asa): è il modulo che implementa le modifiche.
Il comportamento di questo modello è costituito dai seguenti passi:
1. arrivano i dati,
2. asa comunica le risorse modificate al rm,
3. rm riceve da em le informazioni sullo stato delle informazioni e le elabora,
4. em riceve le informazioni dal rm e comunica le modifiche all’asa.
2.1.2
Interazione e/o distribuzione componenti: Estensione modello client/server
Si prende in considerazione come modello di base quello client/server. Tale modello possiede la caratteristica di accoppiamento stretto, ovvero abbiamo una comunicazione sincrona (accoppiamento temporale)
ed il mittente/destinatario devono conoscersi (accoppiamento spaziale). Sfruttando questo modello siamo
in grado di realizzare i protocolli rpc. Purtroppo questo modello difficilmente si adatta ad un contesto
in cui i nodi si muovono proprio perché richiede un accoppiamento sia spaziale che temporale. Quindi
nasce la necessità estendere questo modello con l’adattamento oppure utilizzare modelli alternativi.
Le estensioni del modello client/server possono essere:
1. Modello base con accodamento: stiramento al modello progettuale dove si abbandona o si rende
meno stringente l’esigenza di comunicazioni sincrone.
5
In questo caso si realizzano meccanismi di accodamento per rendere più asincrona la comunicazione,
ovvero vengono inoltrate richieste solo se il canale risulta disponibile, altrimenti vengono mantenute
e poi spedite in base a determinate politiche di scheduling.
2. Modello client/agent/server: in questo caso viene utilizzato il componente aggiuntivo chiamato
agent. L’agent ha il compito di agire nella rete fissa come sostituto del nodo mobile nella rete fissa,
in quanto il nodo mobile potrebbe non essere sempre connesso. Ciò rende il client sempre visibile
nella rete anche se esso non è realmente connesso.
Tipicamente questo approccio serve a gestire il risparmio energetico, ad esempio il client sa che
una particolare richiesta richiede un tempo non trascurabile. La inoltra e si spegne. In tal caso
l’agente è in grado di raccogliere la risposta fornita dal server.
Questa tecnica è migliore rispetto al caso di client leggeri, che si poggiano cioè solo su nodi mobili.
A tal proposito distinguiamo l’agente intermediario in due tipi:
(a) agente generalista: intermediario per varietà di client (vicino al server), ovvero legato ad uno
specifico tipo di server.
(b) agente dedicato: dedicato ad uno specifico tipo di client (vicino al client).
3. Modello client/intercept/server: per risolvere i problemi lato client, ad esempio la perdita di una richiesta, viene inserito un componente aggiuntivo sul nodo mobile, ovvero sul client. Questo modello
rappresenta l’estensione del modello con accodamento sfruttando il modello client/agent/server.
Infatti i due agenti cooperano per ridurre le trasmissioni sul collegamento wireless, per migliorare
la disponibilità dei dati e supportare le computazioni interrotte del nodo mobile. Inoltre si può
realizzare un’ottimizzazione della trasmissione, per specifiche applicazioni e di gestire nei due sensi
le disconnessioni.
Tale modello è adatto per client pesanti, ad esempio quelli che usando il prefetching, oppure quando
i nodi comunicano molto spesso tra loro.
2.1.3
Mobilità del codice
Anche in questo caso abbiamo diverse possibilità su come fornire la mobilità del codice:
1. Sistema location unaware: lo schema di interazione tra i componenti è sempre lo stesso a prescindere
dalla loro collocazione fisica.
6
L’ambizione è quella di avere un livello trasparente. Tuttavia si presenta il problema di localizzazione, ovvero se l’entità che si trova nel livello inferiore è eterogenea e dinamica (come i nodi mobili
che stiamo considerando), bisogna scoprire se le entità che si trovano nel livello superiore siano
vicini o meno. Per risolvere questo problema bisogna separare i vari componenti in compartimenti
stagni in modo da avere un sistema location aware.
2. Sistema location aware: in questo caso i componenti sono partizionati e possono cambiare la loro
posizione in momenti separati. In questo modo abbiamo un miglioramento delle prestazioni del
sistema ed è supportata la mobilità dei componenti software.
Anche questo caso possiede però un ulteriore problema, ovvero bisogna decidere se e quando spostare un componente. Tocca sottolineare il fatto che la mobilità del codice non consiste nella
migrazione di processi e di conseguenza non è un aspetto gestibile dal progettista software. Dato
che non esiste una soluzione univoca a tale problema bisogna decidere caso per caso.
Un componente è composto da:
1. codice: parte statica che rappresenta la logica dell’applicazione.
2. stato: parte dinamica composta dal valore delle variabili locali, dallo stack di esecuzione e dal
program counter.
3. risorse: descrittori di file.
Per poter spostare un componente possiamo usare le seguenti tecniche:
7
1. si sposta solo il codice:
(a) remote execution: un nodo spedisce il codice ad un’altra locazione, delegando gli altri nodi
alla sua esecuzione.
Ad esempio, il nodo A vuole eseguire del codice su un nodo esterno. Supponiamo che il nodo
B possieda le risorse di interesse per l’esecuzione del codice di A. A questo punto il nodo A
spedice il codice al nodo B, esegue il codice su B ed attende i risultati dell’esecuzione.
(b) code on demand : A trova del codice in un’altra locazione che estende le sue funzionalità e lo
richiede.
2. viene spostato sia il codice che lo stato:
(a) strong mobile agent: A si muove su un’altra locazione con tutto il suo stato (program counter,
stack e dati). A può riprendere la sua esecuzione in una nuova locazione dal punto esatto in
cui si è bloccato.
(b) weak mobile agent: A si muove verso un’altra locazione solo con i suoi dati privati. A ha
bisogno di metodi per determinare il punto in cui aveva interrotto la sua esecuzione.
(c) close-to: B è associato ad A e deve rimanere connesso. Se A si muove ad una nuova locazione
B lo deve eseguire.
8
Questa tecnica comporta un adattamento dei server a particolari esigenze ed una riduzione del
traffico sulla rete. Inoltre sono supportate le operazioni di disconnessione o quelle debolmente
connesse. Questa tecnica permette l’accompagnamento nella rete fissa di nodi mobili.
Gli agenti mobili non sono necessariamente intelligenti. Se sono dotati di capacità decisionali bisogna
utilizzare due tipi di linguaggi, uno per programmare le operazioni ed uno per rappresentare la conoscenza
in modo da esprimere obiettivi, compiti, preferenze, ecc...
Tuttavia abbiamo un problema di sicurezza. Infatti l’architettura basata su codice mobile non è
ortogonale a quella client/server (o le sue estensioni). Ad esempio nel modello client/agent/server,
l’agente può essere visto come un caso particolare di agente statico.
Il modello ad agenti mobili è un caso particolare di rilassamento architetturale organizzato secondo
l’idea che il codice eseguibile di una applicazione può cambiare locazione mentre l’applicazione è in
esecuzione. Tuttavia se un client è un nodo mobile, l’interazione con N server diventa molto dispendiosa.
Una possibile soluzione a questo problema consiste nello spedire la parte che implementa la logica dell’applicazione verso il server con il quale si interagisce ogni volta. Dopo che il componente intelligente
ha elaborato la risposta, questa viene rispedita al client e di conseguenza anche il relativo componente.
Un’altra soluzione è quella in cui si sposta il componente tra vari server. Questo componente può
contenere:
• solo il codice eseguibile;
• sia codice eseguibile che stato (tipico degli agenti mobili).
Una volta elaborata la risposta viene rispedito sia il componente che la risposta al client. Ciò permette
un notevole risparmio di risorse rispetto alla precedente soluzione. Tuttavia quest’ultimo approccio si
può applicare solo se è garantita l’esistenza di un ambiente sicuro su ogni nodo di esecuzione. In generale
la macchina che ospita tali applicazioni è la jvm.
Tale modello può essere visto come un’estensione del modello client/server perché per far interagire le
entità, queste devono interagire tra loro. Ovvero si deve creare un bind tra le interfacce (accoppiamento).
2.2
Cambiamento: altri modelli
In questo paragrafo riportiamo alcuni modelli alternativi al modello client/server che si adattano alle
esigenze delle applicazioni nomadiche e non richiedono particolari adattamenti. Rispetto alla modalità
di interazione possiamo considerare due modelli di comunicazione alternativi a quello client/server: tuple
space e broadcast.
2.2.1
Architettura tuple space
Questa modalità permette una comunicazione generativa dove abbiamo interazione e coordinazione tra
i componenti asincrona e connectionless.
Per implementare un tuple space viene usato un apposito linguaggio di coordinazione: linda. Le
operazioni messe a disposizione da questo linguaggio sono le seguenti:
• out(T): aggiunge una nuova tupla allo spazio;
• in(T): estrae la tupla T e la elimina dallo spazio;
• rd(T): estrae la tupla T e la mantiene;
9
Operazioni
• eval(T): aggiungo una tupla attiva, almeno un processo.
dove una tupla rappresenta una sequenza di dati, record, struttura e campi contigui.
Bisogna notare che le operazioni in() ed rd() si basano sul concetto di pattern matching, ovvero se
abbiamo una tupla T si trova nel tuple space e la confrontiamo con un’altra tupla Ts allora si ha un
pattern matching solo se:
Pattern
Matching
• i numeri dei componenti sono identici;
• e se, rispetto all’i-esimo elemento:
– se T e Ts sono costanti con lo stesso valore;
– se T e Ts variabili e sono dello stesso tipo;
– se T costante e Ts variabile allora T deve avere lo stesso tipo di Ts .
Il protocollo linda definisce inoltre le seguenti regole:
Regole
1. non si può stabilire un percorso diretto tra mittente e destinatario;
2. il mittente e destinatario non devono necessariamente conoscersi (disaccoppiamento spaziale);
3. l’iterazione è tipicamente asincrona (disaccoppiamento temporale).
In generale le tuple presenti nel tuple space non contengono le informazioni relative all’autore della tupla.
Quindi tramite il tuple space vengono ignorate sia le informazioni relative agli utilizzatori di una tupla
che quelle che identificano chi l’ha prodotta.
In realtà esiste un meta-livello che garantisce una relazione tra il produttore ed il consumatore, infatti
senza questo accordo la comunicazione fallisce. Per il matching delle richieste (risposte) tra produttori
(consumatori) vengono definite:
1. sintassi: desidero una strutturazione;
2. semantica: desidero che abbia un significato comprensibile.
Le ontologie rappresentano un modo in cui si può manifestare un accordo. È facile vedere come sono
costruite le strutture dati in un tuple space. Consideriamo un caso semplice ma importante: possiamo
salvare un vettore di n elementi come n tuple aventi la seguente forma:
Esempio
(‘‘V’’, 1, primo-elemento)
(‘‘V’’, 2, secondo-elemento)
...
(‘‘V’’, n, ennesimo-elemento)
Per leggere il j-esimo elemento del vettore ed associare il valore x si esegue il seguente comando:
rd(‘‘V’’, j, ?
x)
Per cambiare l’i-esimo elemento in un ambiente locale eseguiamo i seguenti comandi:
in(‘‘V’’, i, ?
vecchio-valore)
out(‘‘V’’, i, nuovo-valore)
invece se l’ambiente è esterno e condiviso a tutti eseguiamo:
in(‘‘V’’, i, ?
vecchio-valore)
out(‘‘V’’, i, computer-remoto())
Questo tipo di comunicazione si colloca bene nei sistemi nomadici, infatti abbiamo:
1. disaccoppiamento spaziale e temporale.
10
Proprietà
dei
nodi mobili
2. non è necessario il re-binding: un tuple space non è associato a nessun mittente o destinatario
particolare.
3. fornisce di per sè un servizio di accodamento, la tupla infatti è persistente.
4. il tuple space può essere utilizzato per rendere disponibile a chiunque sia interessato variazioni degli
indici di qos di qualsiasi tipo.
Il modello simile è il publish/subscribe dove:
• un’entità produce informazioni e le pubblica;
• le entità interessate ad una specifica informazione effettuano una sottoscrizione al relativo servizio;
• un servizio invia le informazioni a tutte le entità che sono sottoscritte ad esso.
Tuttavia tra publish/subscribe e tuple space ci sono le seguenti differenze:
• Nel publish/subscribe non esiste il concetto di contenitore, ovvero le informazioni sono volatili.
Di conseguenza tali informazioni appena vengono prodotte sono subito consegnate al destinatario,
quindi se vengono prodotte prima che qualcuno abbia mostrato il proprio interesse queste vengono
perse.
• Nel il tuple space abbiamo un disaccoppiamento spaziale e temporale dal punto di vista del produttore. Ciò può essere esteso con una versione non bloccante delle letture, garantendo cosı̀ anche
un disaccoppiamento dei consumatori.
2.2.2
Broadcast
Rispetto all’approccio del tuple space, l’operazione di broadcasting risulta limitata, infatti l’informazione
viene definita in un insieme di elementi aventi un contenuto ed una chiave univoca dove lo scambio dei
dati avviene in modalità request/response (on demand). Questo paradigma viene usato nei database.
Ogni utente invia una richiesta inviando una chiave, la risposta è singolare, ovvero il numero di richieste
è pari al numero di risposte.
Tuttavia se gli utenti sono mobili sorgono dei problemi. Infatti il problema principale è il consumo
energetico in quanto il client rimane acceso finché non riceve una risposta (tempi di risposta esponenziali).
Una soluzione è che il database piuttosto che funzionare in maniera reattiva, manda le informazioni
quando vengono richieste, le raggruppa e le spedisce in un unico blocco (burst). Se un client è interessato
all’elemento j-esimo non deve effettuare richieste, ma accendersi ed aspettare che arrivi.
I vantaggi di una simile modalità sono:
1. Qualunque sia il numero di utenti che accedono, il tempo di attesa è medio. Quindi il sistema è
esente da congestioni e gli utenti non si manifestano.
2. Non c’è consumo di energia, infatti il consumo energetico risulta maggiore per le richieste rispetto
alle risposte.
Gli indici di prestazione di questo approccio sono:
latenza (access time) il tempo medio che passa quando il nodo mobile n manifesta interesse ad una
informazione, a quando compare. In altre parole è il tempo trascorso tra la richiesta di un elemento
e la sua occorrenza nel broadcast.
11
consumo di energia (tuning time) il tempo di ascolto tra la richiesta di un elemento e la sua occorrenza nel broadcast. Indica per quanto tempo l’interfaccia mobile deve rimanere in attesa.
Solitamente la latenza è maggiore o uguale al consumo di energia.
Per ottimizzare gli indici di prestazione:
• lato server vengono usati:
broadcast schedule posso modificare lo schema classico (cerchio di informazioni) rispetto alle
richieste. In questo modo viene aumentata la frequenza di trasmissione dell’elemento più
popolare.
Ciò permette una riduzione sia dell’access time che del tuning time medio, ma genera il
problema che non si conosce la popolarità dal momento che gli utenti non si manifestano. Per
risolvere tale problema si può schedulare un messaggio contenente le statistiche relative alle
richieste.
broadcast index i dati che devono essere comunicati sono indicizzati.
Ad esempio, il client si accende, scarica l’indice relativo alla risorsa a cui è interessato, si
spegne e si riconnette quando passa la risorsa.
Ciò porta ad una riduzione dell’access time medio ma ad un aumento del tuning time medio
(ovvero trasmetto dati ed indice).
• lato client normalmente si usa il broadcast index in modo tale da ridurre il consumo energetico.
Inoltre si possono usare tecniche come il caching/prefetching1 , in questo modo si riduce sia l’access
time che il consumo energetico.
Purtroppo la riduzione del consumo energetico non è garantita poiché anche se è vero che esiste
una probabilità non nulla che una determinata risorsa verrà utilizzata, è anche vero che esiste una
probabilità complementare che questa risorsa non sarà utilizzata. Quindi tutto dipende dalla bontà
delle previsioni che una data risorsa sarà utilizzata.
2.2.3
Peer-To-Peer
In questo modello non c’è nessuna distinzione tra client e server, infatti ogni nodo della rete possiede
entrambe i comportamenti. Permette l’implementazione di un’architettura decentralizzata e quindi le
responsabilità sono condivise tra i vari nodi del sistema. Ogni nodo può entrare ed uscire dalla rete con
relativa libertà. Inoltre il p2p è adeguato a situazioni in cui non è possibile adottare un’architettura
client/server.
2.2.4
Middleware
È uno strato software che si appoggia sul sistema operativo di rete2 . I protocolli di rete usati da questo
sistema operativo rendono accessibili le risorse locali da parte di nodi remoti e forniscono delle interfacce
per accedervi.
Purtroppo non si può standardizzare un middleware generando problemi come la riconfigurazione dei
dispositivi fisici, riconfigurazione delle applicazioni, monitoraggio del contesto e gestione delle informazioni.
1 Per
prefetching si intende il prelievo anticipato delle informazioni che sono probabilmente le più richieste.
il sistema operativo vero e proprio con i protocolli di rete.
2 Rappresenta
12
Lo strato middleware può essere scritto in linguaggi forniti per sistemi distribuiti. Questi linguaggi
possono essere classificati in:
• linguaggi orizzontali : offrono servizi generici che vanno bene per qualunque applicazione;
• linguaggi verticali : offrono uno specifico supporto ad una classe particolare di applicazioni.
Nei seguenti paragrafi analizzeremo in primo luogo gli aspetti di un middleware a livello orizzontale, cioè
non vincolati dalle applicazioni, nello specifico tratteremo le modalità di interazione/coordinazione. A
seguire tratteremo gli aspetti verticali.
2.2.5
Livello orizzontale
Il livello orizzontale viene anche detto modello request/response. Questo modello è fortemente legato
al modello client/server sull’organizzazione dell’architettura software dove è presente un meccanismo
di elezione per le applicazioni distribuite. La comunicazione è tipicamente connection-oriented, ovvero è sincrona (accoppiamento temporale stretto) dove il mittente ed il destinatario devono conoscersi
(accoppiamento spaziale stretto), ciò viene realizzato dai protocolli rpc.
Dobbiamo considerare l’impatto sulla mobilità che consiste nell’attraversamento dei confini fisici (possibile disconnessione dei nodi) o dei confini logici (cambio dei diritti di accesso, ingresso in diversi domini
amministrativi). A tal proposito esiste una variante del modello request/response, chiamata rpc-like,
che lo rende adattivo. L’adattamento può essere di tre tipi:
1. most platform: monitoraggio della qos del canale di comunicazione tramite stima del round trip
time (rtt). L’informazione sul qos stimata viene passata al livello applicativo, ciò è realizzato
usando il protocollo udp.
2. mobiledce: introduce il concetto di dominio, ovvero un insieme di macchine con risorse condivise
gestite da un manager di dominio (dm). Ogni client mobile possiede un manager locale. Quando
un nodo mobile entra in un nuovo dominio, dialoga con i dm per decidere se:
• mantenere il bind con un servizio remoto;
• fare re-bind ad un nuovo servizio nel nuovo dominio;
• emulare localmente, in caso di disconessione, il servizio e poi reinviare i messaggi quando la
connessione ritorna.
3. rover toolkit: fornisce il supporto per rendere asincrone le procedure di chiamate remote (accodamento). Quindi supporta la migrazione del codice da un nodo fisso ad un nodo mobile. Ciò si
presenta come un insieme di librerie che forniscono delle funzionalità. Tale tecnica si basa su due
concetti:
(a) rdo: oggetti rilocabili dinamicamente;
(b) qrpc (rpc accodate): qrpc è un protocollo che gestisce l’accodamento delle chiamate. Lo
scheduler decide come e quando svuotare la coda.
La comunicazione tra rdo usando qrpc consiste nel seguente procedimento: ogni qrpc emessa
da un rdo nel client viene accodata in un registro locale (log) ed il controllo ritorna ad rdo. Uno
scheduler di rete invia al server le qrpc accodate in background quando la connessione è attiva,
eventualmente compattando e riordinando le richieste.
La proprietà dell’approccio rpc-like consiste nell’avere caratteristiche comuni ai tre ambienti:
1. rilassamento della sincronia (meccanismi di ritardo ed accodamento di rpc in caso di cattiva qos
o disconnessione).
2. approccio connection-oriented (bind e re-bind in caso di sconnessione con meccanismi di emulazione
local).
Tuttavia rimane il problema che abbiamo un’interfaccia non uniforme per informazioni sulla qos non
riguardanti la comunicazione (ad esempio il consumo di energia).
13
2.2.6
Livello verticale
Abbiamo precedentemente detto che un middleware può avere due tipi di livelli, uno orizzontale ed uno
verticale, specifico per le varie applicazioni. Vediamo alcuni servizi di quello verticale:
Filesystem ha come obiettivo quello di fornire un accesso trasparente ed efficiente a file condivisi
cercando di garantire la consistenza dei dati.
I problemi generici che possono sorgere sono le risorse limitate dei dispositivi mobili, poca banda
e variabile, le frequenti disconnessioni, l’eterogeneità sia dell’hardware che del software, le reti
wireless poco affidabili e filesystem standard quasi inutilizzabili. Per risolvere tali problemi di
solito si adotta una replicazione dei dati ed una raccolta anticipata dei dati.
Possiamo avere anche problemi di consistenza, ovvero consistenza debole e rilevamento di conflitti.
Se vogliamo accedere ad un filesystem con connettività limitata abbiamo dei problemi di:
1. simmetria: relazione client/server o peer-to-peer, supporto nella rete fissa, singolo filesystem
o filesystem multiplo, un namespace per i file o più namespace.
2. trasparenza: nascondere il supporto alla mobilità alle applicazioni sui nodi mobili, gli utenti
non dovrebbero accorgersi di meccanismi addizionali.
3. modello di consistenza: ottimo (tutti la stessa visione del file) o pessimistico.
4. caching e prefetching: singoli file o directory che vengono cachati permanentemente o temporaneamente.
5. gestione dei dati: gestione dei dati nel buffer e copie, sono necessari richieste di aggiornamento
e rilevamento delle modifiche sui dati.
6. risoluzione conflitti: può essere specifica per l’applicazione o generale, errori.
Il fileststem coda è un’estensione del modello client/server che è trasparente alle applicazioni. La
consistenza è gestita con approccio ottimistico, a grana grossa cioè per file di grandi dimensioni.
Database le caratteristiche di un database sono:
1. elaborazione delle richieste: risparmio energia, dipendenza dalla posizione, efficienza.
2. gestione delle repliche (simile al filesystem).
3. gestione della posizione: mantiene traccia della posizione degli utenti mobili per fornire dati
replicati o dipendenti dalla posizione al momento e nel luogo esatti (hlr nel gsm).
4. elaborazione delle transazioni: abbiamo transazioni mobili (non si basano necessariamente
sullo stesso modello delle transazioni su rete fissa acid (atomicità, consistency, isolation,
durability), modelli a transazioni deboli.
14
2.3
Piattaforme orizzontali: WWW
www è caratterizzato dal protocollo http e dal linguaggio html. http1.0 è stateless, usa un modello
di tipo request/response. Il protocollo è connection-oriented, ovvero viene usato tcp. http è stato
progettato per essere utilizzato su banda larga con un basso delay, inoltre sono presenti header di grandi
dimensioni ed i file sono trasferiti senza compressione. Oltre al protocollo tcp, viene usato il lookup del
dns e ciò causa del traffico addizionale.
Anche html non è adatto per dispositivi mobili poiché è stato progettato per pc ad alte prestazioni. Il
problema consiste nel fatto che i dispositivi mobili possiedono schermi piccoli a bassa risoluzione, quindi
le pagine Web si adattano poco all’eterogeneità dei sistemi finali.
Il Web non è paragonabile ad un filesystem, infatti le pagine non sono semplicemente da scaricare. Queste
possono avere un contenuto sia statico che dinamico e richiede comunque l’interazione con il server per
poter fornire le corrette informazioni. Il caching viene spesso disabilitato dagli isp proprio perché sono
presenti contenuti dinamici. Gli hyperlink vengono caricati, ricaricati automaticamente o reindirizzati.
Per quello che è stato appena detto, si evince che i due componenti di www non sono stati progettati
per ambienti mobili e ciò crea non pochi problemi. Lo stack di protocolli che supporta il Web non è
particolarmente indicato alle esigenze che il sistema offre. Infatti i dispositivi mobili stanno “stretti” in
questa pila di protocolli. Il caching ad esempio non può essere utilizzato da parte dei nodi mobili per
problemi di sicurezza. A tal proposito sono state proposte due soluzioni: nuove tecnologie e rimedi a
livello architetturale.
2.3.1
Nuove tecnologie
È possibile utilizzare:
1. una tecnologia push, dove non è richiesto un pull da parte del client.
2. il protocollo http1.1 che usa connessioni persistenti, richieste multiple, aumento del numero di
header per il controllo della cache e supporto ai meccanismi di codifica/compressione.
3. i cookies che permettono l’uso di sessioni statefull.
2.3.2
Rimedi a livello architetturale
Possiamo usare:
1. browser potenziati : si usa il meccanismo di caching lato client. Il problema che può nascere è
proprio che il server che fornisce le pagine blocca tale operazione.
2. componenti addizionali : caching (se offline) e prefetching di pagine.
15
3. proxy: è un agente che si interpone in maniera trasparente.
Il client proxy permette l’uso offline dei contenuti, caching e prefetching. Migliora la qualità, il
tempo di risposta ed il controllo di energia.
Il network proxy si adatta al contenuto (rende general-purpose l’applicazione), supporta il caching/prefetching (miglioramento delle prestazioni del sistema), ma i componenti non sono fruibili
offline.
Possiamo combinare sia il client proxy che il network proxy, in questo modo si combinano le
caratteristiche dei due approcci semplificando i protocolli. Infatti viene utilizzato un protocollo
specializzato.
2.4
Piattaforme Orizzontali: WAP
wap sta per wireless application protocol. È una piattaforma pensata per adattare il modello ad una
situazione in cui i nodi hanno una capacità ridotta sia di hardware che di comunicazione.
Bisogna ricreare lo stesso modello architetturale concettuale alla base del Web cioè il modello client/server riprendendo, specificando e modificando i concetti fondamentali (standard uri, tipo di mime,
codifica delle informazioni html, standard di trasferimento http).
L’architettura del wap si presenta ad alto livello con i seguenti componenti:
16
1. Interprete: Nella precedente figura è presente un gateway. In questo caso il modello di programmazione wap mantiene alcune caratteristiche quali: browser (microbrowser); linguaggio; formato dei
contenuti. Inoltre aggiunge alcuni protocolli utili in modo tale che possano appoggiarsi a quelli comunemente usati nel Web (ad esempio wta-wtai è usato per sfruttare gli standard delle compagnie
telefoniche). Sempre nella precedente figura, il gateway effettua una codifica al nuovo protocollo,
ovvero traduce i dati provenienti dal Web in oggetti usabili nel wap.
2. wml: è un linguaggio di markup simile all’html indicato per reti povere.
3. Stack di protocolli : è componibile, ovvero non è detto che l’applicazione debba usare tutti i
protocolli.
Descriviamo la precedente figura:
WAE comunica direttamente con il browser. Viene usato su sistemi con risorse limitate, dove utilizza i
seguenti elementi:
1. linguaggi di markup:
• wml a differenza dell’html prevede un formato specifico.
Sfrutta la metafora deck & card, ovvero immaginiamo una serie di carte successive disposte
in una sequenza, ognuna delle quali definisce una logica del documento. Ogni carta
contiene uno o più elementi e definisce istruzioni o il contenuto. Ciò rappresenta lo stato
dell’oggetto.
Quindi wml descrive in modo astratto solo la logica dell’interazione. Mentre lo strato di
presentazione è dipendente dalle caratteristiche del dispositivo. Solitamente questo strato
fornisce un supporto a documenti testuali, interazione utente, navigazione e gestione del
contesto (persistente).
• wml script: è un linguaggio dichiarativo, procedurale, con loop e condizioni. Inoltre tutte
le variabili sono globali ed è estendibile tramite librerie. Ciò ci permette la creazione di
programmi aventi una logica più complessa. Tale linguaggio di scripting è necessario per
incorporare costrutti di programmazione logica e funzionale.
2. microbrowser : rappresenta l’interprete dei linguaggi di markup, ovvero effettua le richieste e
fa parsing delle risposte. Questo opera in un ambiente limitato, quindi mantiene variabili in
modo persistente.
3. meccanismi di integrazione telefonica wta: sono usati dei server ad-hoc. Tali meccanismi
risultano indipendenti dal dispositivo di rete e sono asincroni, ovvero pilotati ad eventi. Ad
esempio una segreteria telefonica.
Il modello logico di wae permette due tipi di interazione:
1. richiesta/risposta;
17
2. push/pull:
• service indication: il server dice solo dove è disponibile il servizio (breve comunicazione
del servizio tramite push ovvero identificazione tramite uri).
• caricamento del servizio: il servizio viene fornito automaticamente (breve comunicazione
push al client tramite uri, ovvero l’user agent decide sull’utilizzo tramite pull e quindi
trasparente per un utente).
WSP si occupa del mantenimento di connessioni persistenti. L’obiettivo è quello di garantire ed implementare il concetto di sessione tra client e server. Quindi wsp fonisce servizi a livello applicazione
sia di tipo push che pull, a seconda del protocollo che si sta utilizzando, di tipo:
• connection oriented (wtp): gestione di sessione, invocazione dei metodi, comunicazione in
caso di errori, push senza conferma, push con conferma, interruzione/ripresa sessione.
• connectionless (wdp): invocazione di metodi, push, generalmente affidabile.
Sia wtp che wdp possono usare wtls per creare connessioni sicure. Attualmente supporta
applicazioni di tipo browsing come wsp/b statefull mentre http1.1 è stateless.
WTP sta per wireless transaction protocol ed ha il compito di gestire lo scambio delle richieste/risposte.
È un servizio molto leggero basato su transazioni datagram. Le transazioni di richiesta/risposta
sono implementate in modo affidabile, ovvero ogni applicazione può selezionare l’affidabilità e
l’efficienza opportuna.
Questo protocollo fornisce una comunicazione unidirezionale che può essere affidabile, ad esempio
il server vuole sapere quello che riceve, o non affidabile, ad esempio il server non è interessato alla
ricezione.
È efficiente poiché usa tecniche come segmentazione/riassemblaggio, ritrasmissione selettiva, compressione degli header e setup della connessione ottimizzato.
WTLS è il protocollo che serve a garantire la sicurezza.
WDP sta per wireless datagram protocol. È simile ad udp, la cui comunicazione è trasparente usando
tecnologie di trasporto differenti. Non è affidabile per comunicazioni di tipo end-to-end.
L’obiettivo è quello di creare un sistema di trasporto su scala mondiale interoperabile. Se una
piattaforma wap si poggia su Internet non c’è bisogno della sua implementazione.
WCMP simile a icmp
Qui di seguito vediamo degli esempi di architetture che possono essere fatte tramite wap:
1. applicazione ipertestuale con ambiente di sviluppo wap
2. applicazione client/server
18
3. solo mapping tra funzioni wap ed udp
4. architettura wap push con proxy-gateway
2.4.1
WAP2.0
wap2.0 è nato dalla standardizzazione di html (o meglio xhtml che fornisce una sintassi rigorosa)
e delle specializzazioni dei protocolli tcp/http pensate per ambienti wireless. Questa nuova versione
permette di avere una grafica a colori, animazioni e caricamento di grandi quantità di dati.
L’obiettivo consiste nell’integrare diverse tecnologie come www, Internet, wap ed I-mode. Data l’ambiziosità del progetto non è stata ancora realizzata completamente.
Qui di seguito sono presenti varie tipologie di architetture:
• Dispositivo wap/Gateway/Web Server: il gateway fa la conversione tra gli stack di protocolli. Nel
dispositivo wap bisogna avere tutto lo stack di protocolli. Abbiamo però un problema quando si
fa la conversione tra wtls e tls, infatti tale conversione mette in chiaro le informazioni.
• Dispositivo wap/wap-proxy/Web Server: in questo caso sono usati i protocolli tcp’ ed http’ che
sono stati adattati all’ambiente mobile.
• Dispositivo wap/wap-proxy/Web Server/tls tunneling: viene usato per la risoluzione delle debolezze relative alla sicurezza.
19
• Dispositivo wap/ip router/Web Server: si usa semplicemente quello che c’è sullo strato di rete.
2.5
Piattaforme Orizzontali: I-Mode
È stato proposto da NTT DoCoMo Japan ed ha avuto un grande successo in questa nazione. Il motivo di
un cosı̀ grande successo è dovuto dal modello di business che ne ha promosso l’uso (guadagnava molto chi
forniva il contenuto) e dalle attività sociali come ad esempio parlare in treno o giocare con un cellulare.
La caratteristica principale è quella dell’adattabilità. Infatti sono stati usati protocolli Internet riadattati
al mondo wireless.
Può anche basarsi su wap, come è avvenuto in europa, in particolar modo in germania.
2.6
Piattaforme Orizzontali: J2ME
Solitamente le applicazioni sono fortemente dipendenti dal sistema operativo sottostante. Tramite j2me
si evitano questo genere di problemi. Infatti questa piattaforma è composta dal seguente stack di
componenti:
20
Applicazioni
Profilo (mdp)
Configurazione specializzata in un profilo
dei dispositivi.
Configurazione (cdc, cldc)
Insieme ridotto di librerie Java.
java virtual machine (jvm)
Sistema Operativo
Hardware
Con questa tecnologia abbiamo solo due possibili architetture. La prima è relativa a dispositivi con poca
memoria e poca capacità di calcolo, mentre la seconda è adatta a dispositivi con capacità maggiori in
entrambe i sensi.
Queste architetture sfruttano wap o I-mode. Inoltre dato che sono basate su una jvm minimale allora
viene garantita l’indipendenza dall’hardware sottostante.
2.7
Impatto sul sistema operativo
Per i dispositivi mobili non è possibile usare un sistema operativo general-purpose. Infatti è necessario che
il sistema operativo consumi poca memoria ovvero abbiamo bisogno di un sistema operativo specializzato
che sfrutti la memoria flash del dispositivo.
La memoria flash è più affidabile poiché non possiede testine e consuma poca energia data l’assenza delle
componenti meccaniche. Inoltre i tempi di lettura sono molto buoni, quasi come la dram ma a differenza
della dram e degli hard disk abbiamo un consumo di energia minore. Il problema sta sulle scritture che
richiedono tempi lunghi, oltre alla presenza dell’usura per questo tipo di memorie (numero limitato di
scritture).
Per questo tipo di memoria il filesystem viene modificato secondo le seguenti regole:
1. Organizzazione fisica:
• nessuna necessità di copiare file nello spazio di indirizzamento della dram poiché i tempi
di accesso sono paragonabili a quelli della dram. Di conseguenza abbiamo un risparmio di
energia e di tempo.
• viene usato un buffer nella dram per file riscritti più volte in modo da ridurre le scritture
sulla memoria flash in modo tale che si possa prevenire l’usura.
2. Per quanto riguarda l’organizzazione logica non c’è bisogno nè di raggruppare i file correlati nè di
avere la presenza di livelli multipli di redirezione.
Ad esempio l’impatto sul sistema operativo di una memoria flash necessita delle seguenti modifiche sulla
memoria virtuale:
• si deve garantire la protezione tra processi senza aumentare la dimensione dello spazio di indirizzamento.
• il codice può essere allocato ed acceduto direttamente sulla memoria flash mentre i dati e lo stack
rimangono sulla dram. Quindi la parte dinamica sta in ram, mentre quella statica sulla flash
memory.
21
Memoria Flash
3
Comunicazione Wireless
Finora abbiamo trattato le problematiche relative allo sviluppo/supporto di applicazioni in ambiente
mobile, in particolar modo considerando i modelli concettuali, la strutturazione e le proposte tecnologice.
In questo paragrafo scenderemo di livello focalizzando l’attenzione sul wireless link mettendolo in
relazione agli standard e sistemi conosciuti. Tratteremo le problematiche relative alle tecnologie ed ai
protocolli wireless per realizzare l’interazione tra i vari nodi del sistema di tipo wireless. Dopo una
panoramica sulle modalità di utilizzo (tecniche di condivisione e protocolli generali che utilizzano tali
tecniche) passeremo all’analisi della wireless lan.
3.1
Caratteristiche
Le caratteristiche generiche delle reti wireless sono le seguenti:
1. ber maggiore;
2. tasso di trasmissione basso;
3. forti variazioni di qualità;
4. generalmente la comunicazione è di tipo broadcast;
5. è realizzato con due tecnologie: infrarossi e radiofrequenze.
Le radio frequenze possiedono una banda più alta ma necessitano di permessi da parte di organi
governativi. Mentre gli infrarossi sono facilmente bloccabili da parte di ostacoli.
La rete wireless può essere classificata in due modi: reti con infrastruttura e reti senza infrastruttura.
Nelle reti con infrastruttura esistono nodi specializzati, gli access point (ap), che gestiscono il traffico
di una certa zona. Quindi la comunicazione tra due nodi della rete non è mai diretta, infatti per
comunicare con un nodo bisogna spedire un messaggio prima sull’ap, successivamente il messaggio verrà
instradato su altri ap fino ad arrivare al nodo destinazione. In questo tipo di reti abbiamo le seguenti
proprietà:
• progettazione semplificata dei client;
• non abbiamo il problema del terminale nascosto (vedi il punto 2 dei protocolli basati su contesa);
• la gestione della rete è semplice;
• è poco flessibile.
Nelle reti senza infrastruttura, tutti i nodi possiedono le stesse responsabilità. Dove ogni nodo è in grado
di comunicare con qualsiasi altro nodo che si trova nelle sue vicinanze. Se due nodi fanno parte di due
reti diverse non possono comunicare. L’unico modo per farlo consiste nel mettere un ap di confine,
ovvero costruire una rete ad-hoc.
Tale approccio richiede maggior carico sulle responsabilità dei singoli nodi, di conseguenza aumenta il
consumo energetico e il carico computazionale. Tuttavia questa rete è molto veloce, flessibile e meno
invasiva. Questa classificazione vale per reti wireless non necessariamente mobili.
La portata di reti wireless è la seguente:
Ampia
Media
Piccola
wireless wide area network (wwan)
wireless local area network (wlan)
wpan/wdan
Dobbiamo quindi introdurre un compromesso, infatti più aumenta il raggio di copertura, più diminuisce
la capacità di trasmissione. In altre parole all’aumentare della capacità di banda c’è una diminuzione
dello spostamento possibile.
Come si vede nella seguente figura studieremo la tassonomia delle reti wireless, in particolare guarderemo
il livello link e quello networking.
22
3.2
Modalità di utilizzo
Il problema ora da prendere in considerazione consiste nel gestire la condivisione dello stesso canale da
parte di più utenti. Le tecniche di base per la condivisione sono 3+1. A seguire vedremo i protocolli basati
su una di queste tecniche per definire in maniera più chiara ed esaustiva come realizzare la condivisione.
3.2.1
Tecniche di condivisione
Le tecniche di condivisione sono realizzate lungo 3+1 dimensioni: frequenza, tempo, codice, spazio (per
reti cellulari).
FDM condivisione di frequenza Si ha un insieme di frequenze che vengono suddivise in n sottoinsiemi di dimensione variabile. Ogni sottoinsieme viene utilizzato da un utente.
In questo caso ogni utente ha a disposizione una capacità minore di quella totale e ciò è scarsamente
efficiente. Tuttavia l’implementazione risulta molto semplice.
TDM condivisione di tempo Un utente ottiene l’intero spettro per un certo ammontare di tempo,
ovvero chi vuole trasmettere usa tutta la capacità del canale per un intervallo di tempo limitato (assegnato
o autoassegnato). In questo modo viene migliorata l’utilizzazione del canale.
Possiamo combinare fdm e tdm in modo tale che sia migliorata la sicurezza della comunicazione degli
utenti. Infatti risulta più difficile intercettare un canale. Tale combinazione viene usata dalla tecnologia
gsm.
CDM condivisione di codice Ogni utente possiede un codice univoco. Tutti gli utenti trasmettono
contemporaneamente usando tutte le frequenze disponibili. Per evitare il caos bisogna codificare il segnale
di ogni utente usando un codice differente per ogni trasmissione.
CDS condivisione di spazio È il meccanismo alla base delle reti cellulari. Generalmente è con
infrastruttura. Si ha una banda per trasmettere delle frequenze. L’idea alla base consiste nel frazionare
l’area di copertura e successivamente ripartizionare i canali (frequenze) in modo da aumentare il numero
degli utenti attivi in una certa area. In questo modo le stesse frequenze possono essere riutilizzate nelle
celle adiacenti. In realtà viene applicata la combinazione di fdm/tdm/cdm nella stessa cella.
3.2.2
Regole d’uso delle tecniche (protocolli)
Le varie tecniche di condivisione possono essere usate con le seguenti regole:
1. controllo statico (fdma/fdm; tdma/tdm; cdma/cdm);
2. controllo casuale, ovvero su contesa (csma/tdm; maca/tdm);
23
3. controllo dinamico, ovvero su prenotazione (polling/tdm; prma/tdm).
Nella seguente tabella sono rappresentati sia i vantaggi che gli svantaggi di ogni regola, dove “Si” e “No”
sono da considerare in termini di probabilità.
Statico
Casuale
Dinamico
Banda inutilizzata
Collisioni
Traffico Aggiunto
Si
No
No
No
Si
No
No
No
Si
Protocolli basati su assegnazione fissa Sono orientati sul circuit switching. Richiedono una rete
con infrastruttura ed un coordinamento centralizzato. Questi suddividono la banda disponibile in canali
di uguale dimensione, dove ognuno viene usato da un nodo per comunicare con l’ap. Inoltre sfruttano
tutte e tre le tecniche di utilizzo: fdma (alloca la frequenza), tdma (alloca il tempo) e cdma (alloca
il codice). Le prime due possiedono al più N valori, mentre l’ultima può attribuire un codice anche
all’n + 1-esimo utente.
Protocolli basati su contesa Richiedono una rete senza infrastruttura e la tecnica usata è tdma. Il
protocollo che usa questa tecnica è aloha. Ogni utente trasmette quando vuole, se il suo tentativo non
va a buon fine, ovvero si ha una collisione, allora ritrasmette il messaggio. Il rendimento è molto basso
(18%), quindi può essere usato solo se c’è un basso numero di utenti (minore probabilità di collisione).
Per migliorare questo protocollo si utilizzano due soluzioni:
1. Slotted aloha: ogni trasmettitore è costretto a trasmettere all’inizio di uno slot. La capacità trasmissiva raddoppia, ovvero il rendimento è pari a circa 36%. Tuttavia è necessaria una
sincronizzazione di tutti i nodi.
2. csma (carrier sense multiple access): viene usata una rete ad-hoc, quindi i canali vengono usati
usando tecniche adatte a reti senza infrastruttura. Se qualcuno vuole trasmettere deve prima
ascoltare il canale e controllare che sia libero. In questo modo la probabilità di collisione viene
ridotta notevolmente. A tal proposito possono essere usati due approcci:
(a) csma/cd (collision detection): durante la trasmissione di dati su un canale, l’utente è in
grado di ascoltare le collisioni. Se avviene una collisione allora l’utente si ferma e riprova dopo
un tempo randomico (backoff esponenziale). Tale approccio funziona bene se il carico è basso.
Il protocollo che utilizza tale tecnica è ethernet (ieee802.3).
(b) csma/ca (collision avoidance): un utente ascolta il canale, se questo è libero fà partire un
timer. Se allo scadere del timer il canale è ancora libero allora l’utente spedisce il messaggio
altrimenti attende lo scadere di un ulteriore timer. Il successo di questa tecnica è dovuto dal
fatto che i timer sono tutti diversi, ovvero il valore del timer è casuale.
Tramite questo approccio si riducono le collisioni, ma se il numero di utenti è basso si ha una
sotto-utilizzazione del canale. Il protocollo che utilizza tale tecnica è wifi (ieee802.11).
I protocolli a contesa tuttavia soffrono dei seguenti problemi:
(a) Terminale nascosto (1): abbiamo problemi sul rilevamento delle collisioni. In questo caso il
collision detection non funziona a causa della diversa potenza del segnale tra gli utenti che
stanno trasmettendo dati sul canale. Ad esempio se A e C trasmettono contemporaneamente
verso B. B rileva la collisione ma questa non viene rilevata nè da A e nè da C.
(b) Terminale nascosto (2): abbiamo problemi sul carrier sense. Ad esempio se A trasmette prima
di C, C rileva il canale come libero poiché non è in grado di ascoltare i messaggi di A.
24
(c) Terminale esposto: supponiamo che B vuole comunicare con A e C con D. In questo caso B
e C trasmettono contemporaneamente generando collisioni.
I problemi di terminale nascosto ed esposto non si verificano in caso di reti con infrastruttura.
Per risolvere i problemi relativi al terminale nascosto/esposto viene utilizzato il protocollo maca.
Questo protocollo viene usato in reti senza infrastruttura ed è basato sul protocollo aloha con
prenotazione, ovvero un protocollo ibrido tra casuale e dinamico. L’idea di base consiste nel fatto
che la trasmissione viene preceduta da un preambolo che invia un rts al destinatario, ovvero
un messaggio che contiene la tripla: mittente, destinatario e durata. L’utente che riceve questo
messaggio, a sua volta, invia un messaggio di tipo cts. Se l’utente riceve il messaggio rts ma
non è il destinatario e capta la presenza del messaggio cts allora ferma la trasmissione dati poiché
potrebbe generare una collisione. Quindi chi ascolta il cts rimane bloccato per tutta la durata
della trasmissione.
maca
Tramite questo meccanismo le collisioni sono presenti solo nel preambolo, in questo modo si riduce
notevolmente la loro presenza. Naturalmente dal momento che il preambolo ha un suo costo è
ragionevole incrementare la dimensione dei messaggi da inviare.
Protocolli basati su prenotazione Sono usati in reti con infrastruttura. L’idea consiste in una
stazione slave che trasmette solo se viene interpellata dal master. L’ordine di trasmissione è deciso dal
master, il quale può utilizzare diverse tecniche come round-robin, random, techiche basate su prenotazione
o su contesa.
Il protocollo prma usa la tecnica di condivisione tdm. Ogni pacchetto è suddiviso in tre parti: frame,
slot e preambolo. L’idea di base consiste nel fatto che l’accesso al canale avviene su scansioni regolari
di tempo, dove l’unità di misura è pari al tempo di uno slot. Quindi abbiamo la presenza di frame che
si ripetono periodicamente. Il primo slot di ogni frame è costituito da un preambolo che fornisce delle
informazioni sullo stato del frame, in questo modo le stazioni sono in grado di capire quali slot possono
essere utilizzati. Quindi se uno slot è prenotato per una stazione nessuno può usarlo. Se la stazione per
cui è prenotato non lo usa, al preambolo successivo lo slot diventa libero. Se lo slot non è prenotato e
nessuno lo usa sarà libero anche nel preambolo a seguire. Se lo slot non è prenotato ed esiste una stazione
che deve trasmettere, la stazione compete per lo slot e se vince allora ha diritto di trasmettere anche nel
successivo preambolo. Se lo slot non è prenotato ed esistono più stazioni che devono trasmettere allora
abbiamo una collisione, quindi in questo caso si può adottare una variante della contesa dove le stazioni
decidono di trasmettere con una certa probabilità. Insomma, una stazione che ha conquistato uno slot
ha la garanzia che avrà un suo slot in ogni preambolo. L’efficienza quindi aumenta all’aumentare della
quantità dei dati. L’inefficienza, invece, è dovuta dal fatto che esistono slot potenzialmente inutilizzati.
25
prma
Riassumendo il collision detection non funziona nei meccanismi a contesa. La prenotazione è adatta ad
un traffico in cui è garantita la disponibilità del canale. Infatti se abbiamo un traffico bulky (massiccio)
conviene smaltirlo in maniera regolare nel tempo. Quindi i meccanismi a contesa sono più adatti ad un
traffico bursty.
Protocolli a condivisione di spazio Per aumentare il numero di utenti teoreticamente è sufficiente
aumentare le partizioni della cella. Tuttavia la superficie di ogni partizione diminuisce rendendo difficile
lo spostamento di un utente all’interno dell’area. Una soluzione a questo problema consiste nell’usare
la tecnica di handoff. Tuttavia questa tecnica risulta costosa, di conseguenza al ridursi dello spazio
aumentano gli handoff ed aumentano i costi. Bisogna scegliere il giusto tradeoff tra il partizionamento
ed i costi di handoff.
Per fare l’handoff un utente deve stare in una zona in cui è presenta una sovrapposizione del segnale di
due celle diverse. In questa zona avviene lo sgancio dal vecchio punto di accesso al nuovo. Nella seguente
figura si vede come allo scendere della qualità sale quella dell’altro.
Dopo che la decisione viene presa eseguiamo le seguenti operazioni:
• ho required: inizia la procedura di handoff, quindi informo le unità di gestione;
• ho request: se si hanno canali a disposizione, l’unità di gestione prova a contattare un nuovo punto
di accesso;
• Channel activation: informo il punto di accesso del nuovo canale.
3.3
Wireless LAN
In questo paragrafo tratteremo le wireless lan.
A livello di collegamento bisogna specificare i protocolli usati dalla wlan. In particolare a livello datalink
bisogna definire la configurazione della rete (tipo di infrastruttura), il protocollo di accesso (mac ed il
protocollo che controlla il canale (llc). Mentre a livello fisico (plcp/pmo) bisogna scegliere quale mezzo
fisico utilizzare, ad esempio ir o rf, e quanta banda utilizzare.
26
Handoff
Nei seguenti sottoparagrafi del livello logico e delle relative problematiche. Ciò che si vuole garantire è:
1. sicurezza:
(a) safe: non causare danni alla salute;
(b) security: protezione dati.
2. trasparenza ai livelli superiori;
3. interoperabilità;
4. facilità di utilizzo.
3.3.1
Protocollo IEEE802.11
Questo protocollo è stato proposto nel 1990. I progettisti hanno impostato il protocollo in modo tale che
possano garantire:
1. comunicazione asincrona: inizialmente fino a 2MBit con banda a 2.4GHz (senza necessità di
permessi), ora fino a 50MBit con bande diverse (sempre non regolarizzate).
2. garanzia sui tempi: supporta le trasmissioni con picchi temporali (voce) per garantire una qos
accettabile.
Il protocollo è realizzato tramite due schemi:
1. dcf che sta per distribuited coordination function (trasmissione best effort).
2. pcf che sta per point coordination function (trasmissione time bounded).
Inoltre al suo interno sono presenti politiche per il risparmio energetico, risolve il problema del terminale
nascosto/esposto e supporta la mobilità dell’utente.
Tipologia dei nodi
DS
Rappresenta l’insieme di nodi connessi ad un oggetto e definisce il sistema di distribuzione.
IBSS Rappresenta l’insieme di nodi connessi tra loro ma che non comunicano con l’esterno. Questi
possono lavorare sia in una rete con infrastruttura che senza, ovviamente la seconda è la più tipica.
ESS Rappresenta l’insieme di nodi che si connettono al resto del mondo. Formato da più bss aventi
dei punti di accesso tra loro. Se questi nodi si trovano in una rete con infrastruttura allora è trasparente
alla tipologia di connessione adottata (wireless o meno). Quindi il formato dei frame rimane lo stesso.
Mobilità dei nodi
La mobilità dei nodi può essere intrabss o intrads (roaming). Ci accorgiamo che un nodo si sta spostando
quando questo esce dalla portata dell’ap attualmente utilizzato e si ascoltano altri segnali provenienti
da altri ap. Per fare ciò, un nodo fà lo scanning dei canali (ascolta i segnali sulla frequenza di beacon
oppure viene fatta una richiesta esplicita). Se sono stati trovati nuovi ap allora il nodo ne invia una
richiesta di collegamento. A questo punto se la risposta di riassociazione è positiva allora il nodo può
partecipare alla contesa del canale gestito dal nuovo ap. Se vince la contesa allora vengono aggiornate
le informazioni di locazione relative al nodo, altrimenti si riprende l’operazione di scanning e si prova su
un altro ap. Può capitare che il sistema di distribuzione (ds) informa il vecchio ap per consentire un
eventuale rilascio delle risorse. Naturalmente se il nuovo ap non fa parte del ds allora ci troviamo nel
caso di mobilità tra ess differenti, ovvero interds. In questo caso è richiesto l’intervento di altri schemi
di gestione della mobilità, come ad esempio mobileip.
27
3.3.2
802.11: livello logico MAC
Il protocollo mac consente le seguenti operazioni: l’accesso al mezzo trasmissivo, la frammentazione dei
dati degli utenti e la sicurezza (crittografia). Sopra il livello mac i pacchetti saranno identici a quelli di
una qualunque rete 802.x.
Inoltre si può fare il bridging verso altre reti tramite l’uso del livello llc. Questa funzionalità permette
l’estensione dello spazio di indirizzamento su più lan, oltre a tradurre nel corretto formato i frame delle
due lan differenti.
Bridging
Per quanto riguarda l’accesso al mezzo possiamo usare dcf o pcf. Per il dcf possiamo usare:
dcf
• due vie (Data/ack): se non viene ricevuto l’ack, il protocollo mac ritrasmette.
In questo modo viene ridotta la latenza rispetto agli interventi correttivi affidati ai protocolli di
più alto livello. Lo scambio dei frame avviene secondo un meccanismo di contesa. Se si vince la
contesa si ha la garanzia che finché non arriva un ack nessun altro nodo occupa il canale.
Le perdite degli ack sono gestiti con dei timer, ovvero viene adottato il metodo di collision
avoidance.
• quattro vie (rts/cts/Data/ack): funziona come il protocollo maca, dove per prima cosa si accede
alla contesa del preambolo e successivamente si accede al frame. In questo modo garantiamo
l’assenza del problema sul terminale nascosto/esposto.
La trasmissione dei dati con il dcf è affidabile e ci sono garanzie di equità nell’utilizzo del canale wireless.
Usando invece pcf abbiamo garanzie sui tempi di attesa.
Per quanto riguarda il concetto di sicurezza nelle reti wlan è stato adottato wep, tuttavia è facilmente
bucabile.
Sono stati proposti vari formati dei frame basati su reti wlan, quello quasi-standard è rappresentato
dalla seguente figura.
28
Formato
frame
del
Il campo frame control specifica il tipo di frame, e a seconda del tipo alcuni campi compaiono o meno.
Descriviamone alcuni campi:
• versione: versione che si sta usando;
• to/from ds: indicano a seconda del valore il significato dei campi indirizzo come è elencato nella
seguente tabella.
0
0
1
1
0
1
0
1
rete ad-hoc
ap parla con la stazione (terzo passo di indirizzamento)
sta parla con ap (primo passo di indirizzamento)
ap parla con un altro ap (secondo passo di indirizzamento
• More frgs: specifica se non ci sono altri frammenti.
• Power mgmt: specifica se è attivo il risparmio energetico.
• More Data: se l’ap ha ulteriori dati da mandare nel frame.
• wep: specifica se il frame è crittografato o meno.
• Order : se ai livelli superiori è richiesto l’ordine della sequenza.
Il campo Duration id del frame è sempre presente in quanto indica il tempo necessario a trasmettere il
frame per intero (comprensivo anche dei messaggi di ack di ritorno).
Tuttavia il frame non sempre contiene tutti e quattro gli indirizzi. Il numero varia a seconda del tipo di
rete.
Supponiamo di avere due bss connessi ad un ds. L’utente di un bbs (U1 ) vuole comunicare con uno
dell’altro bbs (U5 ). I passi da fare in una comunicazione interds sono tre, dove ad ogni passo abbiamo
bisogno di tre indirizzi:
Esempio
inter ds
1. Inizialmente l’utente U1 invia un messaggio al suo ap con il frame avente l’indirizzo del mittente
(U1 ), l’indirizzo logico del destinatario (U5 ) e l’indirizzo mac del destinatario (ap1 ).
2. A questo punto vi è la comunicazione tra ap dove il messaggio comprende l’indirizzo logico del
mittente (ap1 ), l’indirizzo logico del destinatario (U5 ) e l’indirizzo fisico del destinatario (ap2 ).
3. Infine dal secondo ap verrà mandato un messaggio al destinatario contenente i seguenti indirizzi: l’indirizzo logico del mittente (U1 ), l’indirizzo fisico del mittente (ap2 ) e l’indirizzo fisico del
destinatario (U5 ).
Il controllo di sequenza indica il numero della sequenza nel caso in cui il pacchetto sia frammentato. La
frammentazione dipende dallo stato del canale, quindi si tende ad usare la frammentazione se il canale
è disturbato.
I frame possono essere suddivisi nelle seguenti categorie:
frame dati contiene tutti i dati tranne, eventualmente, il quarto indirizzo. L’uso dei campi indirizzo
dipende dalla configurazione di rete (ibss o ess) e dal tipo di trasferimento, come si vede nella
seguente tabella.
Scenario
to ds
from ds
address 1
address 2
address 3
address 4
ad-hoc
from ap
to ap
ap to ap
0
0
1
1
0
1
0
1
da
da
bssid
ra
sa
bssid
sa
ta
bssid
sa
da
da
sa
29
Categorie
frame
di
frame di controllo contiene i seguenti messaggi:
• ack: possiede un campo atomico che contiene solo l’indirizzo del destinatario. Chi riceve
questo messaggio conosce il mittente proprio per l’atomicità della comunicazione.
• rts
• cts: il campo ra è identico al campo ta del frame rts corrispondente.
Anche la comunicazione dei frame di tipo rts e cts è atomica, quindi non può essere interrotta.
La comunicazione è basata su csma/ca dove:
1. Carrier Sensing (cs): una trasmissione non è abilitata alla comunicazione se il canale è occupato.
Ci sono due modi per gestire il cs:
(a) fisico: ascolto a livello fisico;
(b) virtuale: basato su nav (network access vector). Ogni utente possiede un contatore (nav)
che viene aggiornato in base al campo Duration id dei frame. Ovvero questo contatore è un
timer interno che segnala in modo virtuale l’occupazione del canale.
Un canale è libero se non ha alcun segnale (cs fisico) ed il contatore nav è nullo (cs virtuale).
2. Collision Avoidance (ca): è la combinazione di due meccanismi: interframe spacing (ifs) di durata
costante o a durata variabile.
Il ca si basa su opportuni intervalli di attesa. Abbiamo ifs differenti per ottenere priorità differenti
all’accesso del canale:
(a) difs (dcf interframe spacing): rappresenta l’intervallo per la connessione al canale in caso
sia libero.
Supponiamo che un utente sia pronto ad inviare un messaggio ed inizia ad ascoltare il canale
tramite cs. Se il canale è libero per un tempo difs, l’utente inizia ad inviare. Invece se il
canale risulta occupato, la stazione deve attendere un tempo difs dopo la fine dell’occupazione
ed attende anche per un tempo di backoff. Il tempo di backoff viene decrementato di 1 ad ogni
slot time in cui il canale è libero. Quindi la stazione trasmette quando il tempo di backoff è
nullo.
(b) pifs (priority interframe spacing.
30
Fisica
(c) sifs (short interframe spacing): rappresenta l’intervallo di tempo per l’ack.
Supponiamo che una stazione è in attesa per un tempo difs prima di inviare i dati. Il
destinatario invia un ack se il pacchetto viene ricevuto correttamente (crc valido). In pratica
il destinatario attende un tempo sifs prima di inviare l’ack. Quindi sifs<difs assicura
l’atomicità. Inoltre bisogna notare che il timer difs tiene conto anche dell’ack. Se il mittente
non riceve l’ack allora vi è la ritrasmissione automatica raddoppiando il cw (contention
window).
Tramite il dcf viene garantita anche la fairness, ovvero se un’altra stazione occupa il canale durante
il tempo di backoff di una stazione, allora il timer di backoff si blocca. Quando il canale si libera
di nuovo, la stazione non genera un nuovo intervallo di backoff, in questo modo viene fornita una
maggiore priorità ai messaggi più vecchi.
Con questo approccio abbiamo un problema, ovvero il campo dati è lungo, quindi se una stazione non
avverte collisioni (terminale nascosto) allora occupa il canale fino alla fine del frame. Di conseguenza
abbiamo un notevole spreco di banda. Usando invece uno schema rts/cts si ha un minore rischio di
collisioni ed un minore spreco di banda. In questo caso tutte le stazioni nel bss che ascoltano i frame
rts/cts aggiornano il loro contatore nav tramite il valore contenuto nel campo Duration id di questi
frame. Ovviamente questo schema è vantaggioso solo se il campo contenente i dati è abbastanza grande,
altrimenti si genera troppo overhead. La trasmissione risulta atomica fino alla ricezione dell’ack.
31
Scambio di dati
Logica di funzionamento
rts/cts
Se un frame deve essere frammentato, il protocollo deve garantirne la trasmissione in modo atomico.
Innanzitutto la frammentazione viene realizzata dal livello mac se il pacchetto dati inviato dal livello
llc è troppo grande oppure se il tasso di errore nel canale è molto alto. Il comportamento di questo
approccio consiste nel fatto che il canale non viene rilasciato finché tutti i frammenti sono stati spediti
(ack per ogni frammento). Può capitare che si verifichino degli errori (ack non ricevuto), in questo
caso la stazione compete di nuovo per il canale e ritrasmette l’ultimo frammento senza ack (reazione
più veloce rispetto a tcp).
Fin ora abbiamo visto le funzionalità dcf di base. Esse forniscono la garanzia di equità, ma non ci
danno nessuna garanzia sui tempi di attesa. Per assurdo infatti si può attendere all’infinito. Quindi dcf
garantisce che il canale sarà acquisito ma non si conosce quanto tempo si deve aspettare.
Il protocollo pcf (point coordination function) è costruito sopra il dcf e sfrutta alcune delle sue caratteristiche. Questo protocollo è utilizzabile solo nel caso di reti con infrastruttura in quanto si usa un
controllore centralizzato (point coordinatior pc). L’ap che gestisce il bss organizza il tempo secondo uno
schema preciso e ripetitivo (polling). Il tempo è suddiviso in intervalli, che a loro volta sono suddivisi
in sottointervalli. In questo protocollo ogni stazione nel bss può chiedere di essere aggiunta alla lista
di polling. Il pc avvia periodicamente un contention free period (cfp), in questo modo si garantisce
l’alternanza tra cfp e cp (contention period in modalità dcf).
In ogni ciclo si alterna una fase di pcf ed una dcf. L’ap ha il compito di regolare la proporzione di
tempo pcf e la frequenza con cui si alternano gli intervalli. Quindi a seconda del tipo di comunicazione
viene scelta la corretta combinazione tra proporzione e frequenza. Per attuare questa operazione, l’ap
obbliga le altre stazioni ad un determinato comportamento tramite il frame beacon. Il frame beacon è
un frame contenente tutte le informazioni necessarie e viene inviato all’inizio di ogni intervallo. In esso
viene specificata anche la durata del pcf. Ogni stazione, nel periodo in cui è presente il frame beacon,
non può parlare, a meno che non venga direttamente contattata dal master (polling).
Il coordinatore per prendere il canale invia un frame beacon avente una priorità più alta rispetto alle altre
stazioni solo se pifs<difs. Inoltre notiamo che pifs>sifs altrimenti l’atomicità non sarebbe garantita
32
Frammentazione
pcf
(in ogni caso il ritardo è al massimo della capacità massima di un frame). Il coordinatore spedisce i dati
alla stazione che ha intenzione di usare il canale, ovvero sono eseguite le seguenti operazioni:
1. una stazione selezionata da pc riceve il segnale di polling.
2. la stazione invia l’ack sia al controllore che alle altre stazioni presenti nel bss.
pc termina la fase di cfp inviando un frame di tipo CF end.
Le funzioni di gestione sono:
Funzioni di gestione
1. Sincronizzazione orologio: Per ogni funzione di gestione è importante mantenere sincronizzati gli
orologi interni. Viene realizzata in due modi:
(a) con infrastruttura: più semplice. Periodicamente viene mandato un beacon con valore del
suo orologio. Viene spedito con meccanismo pcf. Anche in caso di collisioni l’invio avviene
sempre all’istante teorico.
(b) senza infrastruttura: nessuno ha priorità. Sono tutti autorizzati a spedire il valore dell’orologio. Tutte le stazioni entrano in competizione per trasmettere il proprio frame.
33
2. Risparmio di energia: Le stazioni si spengono in modalità “sleep” per un certo intervallo di tempo.
Infatti un’interfaccia di rete attiva in stato idle consuma energia quasi quanto un’interfaccia che
trasferisce dati. Senza contare che eventuali nodi mittenti devono conservare in un loro buffer
interno tutti i frame che si trovano in modalità sleep.
Le stazioni che mettono in atto una politica di risparmio energetico devono riaccendersi in intervalli
regolari, ovvero possiedono un timer. Questo timer serve a far svegliare le stazioni nell’istante in
cui un mittente può annunciare la presenza di frame. Quindi la stazione che deve ricevere i frame
deve rimanere sveglia finché il frame non viene trasmesso. Di conseguenza abbiamo bisogno di una
funzione di sincronizzazione chiamata timing synchronization function (tsf). Anche in questo
caso distinguiamo due varianti:
(a) con infrastruttura: ad intervalli regolari l’ap trasmette un beacon contenente una mappa
chiamata traffic indication map. Questa mappa specifica quali stazioni devono ricevere dei
dati. A questo punto ogni stazione elencata nella mappa richiede i dati all’ap, secondo la
modalità pcf, inviando un frame di tipo PS poll. Se è settato il bit “More Data” nel frame
che l’ap invia alla stazione allora la stazione continua a richiedere dati finché non sono esauriti.
Il beacon può contenere anche una delivery traffic indication map (dtim) nel caso in cui tutti
si devono svegliare, ovvero viene usata per creare una comunicazione di tipo broadcast.
(b) senza infrastruttura: tutte le stazioni si sincronizzano tramite frame di beacon distribuiti. In
questo caso ogni stazione costruisce un frame di beacon. Tutte le stazioni nell’ibss competono
per trasmettere il beacon in modalità dcf. La prima stazione che acquisisce il canale vince
la contesa e quindi tutte le altre eliminano il loro frame di beacon ed aggiustano il loro timer.
Ad intervalli regolari tutte le stazioni si devono svegliare e devono rimanere accese per un
certo intervallo atim (ad-hoc traffic indication map). Tale intervallo è una finestra riservata
alla segnalazione della presenza di dati. In questa finestra si avvia la normale contesa, tutti
sono autorizzati a mandare frame. Ciò rende l’approccio poco scalabile poiché aumenta la
probabilità di collisione ed il ritardo di tramissione.
34
3. Sicurezza: basata sull’algoritmo wep (wired equivalent privacy). Questo algoritmo è basato sull’algoritmo rc4 prng che possiede una chiave simmetrica condivisa, ma lo standard non definisce
come scambiare la chiave. Quindi il livello mac mittente crittografa i dati, mentre quello ricevente
li decritta e li invia al livello superiore.
L’autenticazione è a chiave condivisa. Ovvero una stazione prova la sua identità crittografando e
restituendo un testo di prova. In questo modo viene autenticata la stazione presso l’ap, ma non è
vero il contrario.
Tra gli sviluppi abbiamo 802.11e il quale introduce la gestione di code basate su priorità. Ci sono code
con priorità più alta. La garanzia di priorità del servizio è gestita giocando sull’intervallo ifs. Quindi
una classe A con priorità maggiore rispetto alla classe B avrà un itf minore. È stata introdotta anche
la possibilità di spedire più pacchetti contemporaneamente. I problemi sono relativi alla coesistenza con
altri protocolli che usano le stesse frequenze (ad esempio forno a microonde).
Invece in 802.11i abbiamo la sostituzione di wep in favore a wpa2.
3.4
HiperLAN
etsi (european telecommunications standardization institute) è uno standard europeo che permette il
miglioramento delle lan e la loro interoperabilità con le reti fisse.
La famiglia di reti hiperlan purtroppo non soddisfa tutti i requisiti come portata, banda e qos, oltre ad
avere dei forti vincoli commerciali.
35
3.5
Wireless WAN
Tratteremo questa parte secondo due aspetti:
• Livello mac: accesso ed uso del canale wireless;
• Livello più alto: routing.
Le reti wireless wan sono realizzate usando un’infrastruttura di tipo cellulare. Sono nate per il supporto
al traffico avente un alto trasferimento di dati. Questa infrastruttura è stata usata anche per supportare
l’invio dei dati su scala geografica. Tuttavia non è esente da problematiche legate alla sua estendibilità,
infatti non sono molto adatte per trasmettere informazioni di tipo dati.
Le wlan permettono una maggiore interoperabilità ed un maggiore tasso di trasmissione. Mentre
le wwan forniscono una maggiore mobilità e copertura. Tuttavia il numero di utenti ed il consumo di
energia è simile per entrambe i tipi di rete.
3.5.1
GSM
È uno standard per supportare il traffico europeo. La sua architettura è la seguente:
Livello MAC rete di livello datalink che garantisce l’accesso al canale da parte degli utenti. Il livello
superiore garantisce l’aggancio con nodi fissi. L’area geografica in cui si muovono i nodi mobili è
ripartita in celle. I nodi mobili sono definiti come ms. Ogni cella è coperta da una stazione base
(antenna) bts. Più bts sono coordinate da un bsc. Più bsc fanno capo ad un msc.
Meccanismi di accesso La tecnica di condivisione usata è il circuit switching basato su tdma. La
divisione è fissa in scala temporale, ovvero si dividono gli slot e si raggruppano in frame. Ogni
frame è composto da 8 slot. Lo slot è calibrato sul tipo di informazione che trasporta (156bit).
Circuit Switching Si fa una fase di setup prima della connessione per vedere chi vuole utilizzare il
canale. Se termina con successo mi trovo assegnato uno slot che ricorre nei frame consecutivi, fin
quando non si chiude la connessione. Questo slot può rimanere anche inutilizzato. Le possibilità
di connessione sono di due tipi: full rate (uno slot per ogni frame) o half rate (uno slot ogni due
frame).
Handoff Dal momento che stiamo parlando di una rete cellulare, c’è anche la condivisione dello spazio
con conseguente meccanismo di handoff. L’handoff viene scatenato dal rilevamento della degradazione progressiva del segnale del canale in cui un ms è collegato, insieme all’aumento della qualità
del segnale di un canale il ms sta sentendo. Sono previsti quattro tipi di handoff:
Tipo 1 tra due celle gestite dallo stesso bts.
36
Tipo 2 tra due celle con bts diversi ma stesso bsc.
Tipo 3 tra due celle con bts e bsc diversi ma stesso msc.
Tipo 4 celle contigue ma con msc diversi. Questo caso è simile a quello delle wlan di bss diversi.
Anche in questo caso bisogna usare meccanismi di routing.
L’estensione del gsm all’invio di dati sul canale vocale è stata la prima occasione per rilevare i suoi limiti.
La prima soluzione banale è stata quella di codificare negli slot anche dei frammenti di dati. Ci sono
però problemi di inefficienza (posso inviare al massimo 20Kb per frame) ed economici dal momento che
pago gli slot riservati anche se non vengono inviati i dati. Inoltre abbiamo altri problemi come:
• rigidità: spreco di risorse per via del circuit switching.
• basso tasso di trasmissione.
• modello di addebito basato su durata della connessione.
3.5.2
GPRS
gprs sta per general packet radio service. È un’estensione del gsm mirata soprattutto ad andare
incontro alle esigenze di traffico dei dati, ovvero si appoggia su gsm per migliorare la trasmissione dei
dati minimizzando i costi aggiuntivi. L’obiettivo consiste quindi nel realizzare una rete packet switching
sfruttando l’architettura del gsm.
In questo caso vengono usati tutti gli slot inutilizzati dal traffico vocale per la trasmissione dei dati.
L’accesso avviene sempre meccanismi di contesa. Statisticamente la conversazione vocale ha fasi di
silenzio durante i quali gli slot non sono occupati, per cui è improbabile che non si trovino slot da
dedicare alla comunicazione dati. In ogni caso ci sono delle configurazioni che prevedono di riservare
alcuni slot per il traffico dati. Il modello di addebito è basato sul volume di traffico, tasso di trasmissione
variabile, garanzia di profili di qos e sistemi wireless di terza generazione costruiti su questa tecnologia.
Il modello di servizio prevede due fasi:
Fase 1 servizio pacchetti ptp (point-to-point):
• ptp connectionless network service (ptp-clns): servizio datagram.
• ptp connection oriented network service (ptp-cons): stabilisce una connessione a circuito
virtuale. In questo caso gprs mantiene il circuito virtuale anche in caso di handoff.
Fase 2 servizio ptm (point-to-multipoint).
La qos ha 4 classi di ritardo, 3 classi di affidabilità, 9 classi di throughput di picco e 19 di throughput medio. gprs alloca le risorse dinamicamente in modo da soddisfare le richieste di qos. Ci sono
delle garanzie di affidabilità sui ritardi. Tuttavia non sono dei ritardi simili a quelli di altre reti come
quelle cablate. Il problema nasce quando interagiscono i due sistemi. Ad esempio usando tcp i ritardi
aumentano notevolmente.
L’architettura del gprs comprende la gran parte dei componenti usati nel gsm. Infatti gprs è una sua
evoluzione incrementale e minimale. I nuovi componenti riguardano la parte sulla gestione della mobilità.
37
Bisogna anche dire che la coesistenza tra le due architetture è molto buona. In uno scenario in generale,
si prevede la comunicazione packet switching anche in locale.
Per la comunicazione wireless è stato realizzato uno schema di accesso a contesa su canale wireless. A
livello mac abbiamo la comunicazione tra nodi di bsc differenti. Quindi il gprs ai livelli superiori è vista
come una rete di livello 23 .
In particolare la comunicazione tra sgsn e la stazione mobile utilizza il protocollo sndcp che permette
il mapping delle caratteristiche del protocollo di rete sul sottostante livello datalink. Invece la comunicazione tra gsn (ggsn e/o sgsn) utilizza il protocollo gtp per fare il tunnelling dei pacchetti su diverse
reti. Questo protocollo, infatti, sfrutta ip+tcp/udp per la comunicazione sul backbone. Inoltre fornisce
una maggiore uniformità nella comunicazione tra nodi mobili appartenenti a differenti reti.
3.5.3
Wireless 3G
Tutto è nato per fornire un accesso ad Internet da qualunque luogo e con qualunque mezzo, in ogni
istante. I progettisti del 3G hanno voluto una standardizzazione della comunicazione digitale e delle reti.
L’evoluzione in questo senso ha creato:
3 Si
nota che il protocollo ip è usato a livello 2.
38
• gprs per garantire la connettività Internet sui dispositivi mobili.
• wap per l’Internet Web browsing sui terminali mobili.
• bluetooth per fornire servizi su un’area ridotta (pan).
3.5.4
UMTS
Proposta in ambito europeo su richiesta imt2000 per definire un nuovo standard per il miglioramento
della trasmissione. Questa tecnologia garantisce dei livelli di qualità. Infatti rispetto alle tecnologie viste
nei precedenti parargrafi, umts si differenzia per le capacità trasmissive e le velocità dei nodi mobili.
umts è basato sulla rete utra (umts terrestrial radio access). La sua architettura è identica a quella
del gprs, cambia solo il segnale emesso dall’antenna. Infatti gli elementi di utran (utra network) sono:
rnc (radio network controller), rns (radio network subsystem, Node b, cn (core network). Il node b
può supportare le tecniche fdd o tdd (time division duplex) o entrambe. rnc invece è il responsabile
sulle decisioni di handoff. Nella seguente figura vediamo l’integrazione di gsm, gprs e umts.
39
4
Gestione della mobilità
Durante la comunicazione in presenza di nodi mobili abbiamo un problema relativo alla loro localizzazione.
In assenza di mobilità la localizzazione del destinatario è effettuata staticamente. La tecnica usata di
solito è l’utilizzo di un id che incorpora le informazioni per la localizzazione (ad esempio l’uso di un ip
o un numero di telefono).
Nel caso di Internet il routing si basa sull’indirizzo ip dove il prefisso di rete determina la sottorete
fisica. Un router utilizza la sua tabella di routing per instradare i pacchetti in ingresso verso l’apposita
interfaccia d’uscita.
Il problema si verifica solo quando il nodo inizia a muoversi ed adottando la tecnica precedente non siamo
in grado di rintracciarlo.
4.1
Algoritmi di Tracking
Nel caso di mobilità, l’id statico è solo l’identificativo del dispositivo ma non fornisce ulteriori informazioni
sulla sua localizzazione. Tali informazioni, tuttavia, devono prevedere un aggiornamento dinamico.
Esistono due algoritmi di aggiornamento, detti algoritmi di tracking, che differiscono tra loro per i
momenti in cui viene aggiornato il percorso. Le due famiglie conosciute sono:
40
• proattivi (espliciti, table-driven): mantengono aggiornate le informazioni a prescindere dalle esigenze di comunicazione. Il sistema stesso si impegna nella localizzazione.
• reattivi (impliciti, on-demand): è la situazione complementare, ovvero finché non esiste l’esigenza
di comunicazione non si fa nulla.
4.1.1
Tracking Esplicito
L’algoritmo è attivato in modo controllato e rigoroso dove l’aggiornamento può esserci periodicamente,
per cambi di configurazione di rete o nel movimento del dispositivo. In generale si possono costruire in
anticipo le informazioni per la localizzazione.
Ciò comporta il vantaggio che le informazioni riguardanti la localizzazione sono immediatamente disponibili e quindi si ha una riduzione del ritardo di localizzazione. Tuttavia per applicare questa tipo di
tracking abbiamo bisogno di grandi database che contengono le informazioni di localizzazione, possiamo
avere dei ritardi negli aggiornamenti e c’è un notevole consumo di risorse di rete e di energia, ovvero è
presente un overhead per il traffico di controllo.
Le tecnologie che usano quest’algoritmo sono: mobileip, gsm/gprs, manet (dsdv, olsr), hawaii.
4.1.2
Tracking Implicito
Questo algoritmo è guidato dalla presenza effettiva del traffico. Viene attivato solo se effettivamente
qualcuno vuole parlare. All’inizio si procede alla cieca (flooding) con un conseguente raffinamento fornito
da algoritmi per esclusione dei campi. L’utilizzo di una cache distribuita permette un miglioramento
dell’efficienza di questo tipo di tracking. Una tecnica che riduce i costi è la cache lifetime cioè non si
procede alla cieca ma in base alle informazioni precedenti. Tuttavia si corre il rischio di avere informazioni
obsolete oppure di avere un traffico di controllo oneroso a seconda delle tecniche di validazione della cache
utilizzate.
Abbiamo quindi una potenziale riduzione del traffico di controllo con una conseguente riduzione dell’utilizzazione della rete e consumo di energia. “Potenziale” in quanto vi è una riduzione del traffico
effettivo solo se si verificano determinate condizioni, ad esempio se le esigenze di comunicazione sono
piccole rispetto alla quantità di nodi, in generale se le comunicazioni sono scarse. Tuttavia dobbiamo
tenere in conto la presenza di un maggiore ritardo della localizzazione.
Le tecnologie che usano questo algoritmo sono: lan (learning bridges), manet (dsr, aodv).
4.1.3
Tracking Ibrido
Un compromesso tra i due è un tipo di tracking ibrido, che è basato su due concetti:
1. Localizzazione ibrida: si riduce la precisione dell’informazione raccolta con gli algoritmi espliciti.
In questo caso sono usati i metodi espliciti con un livello di precisione più grossolano. L’area viene
suddivisa e si mantengono le informazioni sulla presenza o meno del nodo nella sottoarea, senza
sapere con precisione la locazione. L’esatta localizzazione avverrà solo se effettivamente si ha la
necessità di contattare uno specifico nodo.
Questo approccio comporta una riduzione dei costi e richiede una localizzazione on-demand limitata.
Ad esempio mobileip può usare un tracking proattivo a livello di rete ed una localizzazione reattiva all’interno della sottorete oppure usa una binding cache aggiornata reattivamente. Invece in
gsm/gprs è presente un tracking proattivo a livello di location area ed una localizzazione reattiva
all’interno della location area.
2. Adattamento dinamico: la localizzazione statica definisce la ripartizione in maniera statica (ad
esempio nella rete cellulare le antenne sono fisse). C’è la proposta di un’altra soluzione cioè le
partizioni sono adattate dinamicamente e personalizzate per ogni nodo mobile.
41
Esempi
4.2
Reti con infrastruttura
Nel caso della mobilità, un cambio di sottorete fisica implica un cambio di indirizzo ip per avere un
indirizzo topologicamente corretto oppure sono necessarie informazioni aggiuntive nella tabella di routing.
Il problema è quello di cercare una soluzione che non cambi il routing ip alla base. Quindi l’obiettivo è
quello di lasciare intatta la struttura della localizzazione tradizionale.
4.2.1
Routing per nodo
La prima soluzione prevede l’arricchimento delle tabelle di routing usate dal router. L’idea consiste
nell’aggiungere sulla tabella di routing il percorso verso un nodo mobile. Per ogni interfaccia si specifica
l’elenco degli indirizzi ip raggiungibili tramite quest’interfaccia.
Il lato debole di un simile approccio è legato alla scalabilità. Infatti si obbliga i router a gestire delle
tabelle troppo grandi, infatti potrebbe esserci potenzialmente un elemento per ogni nodo mobile. Gli
aggiornamenti delle tabelle, inoltre, contengono le informazioni relative a tutti i router, collegamenti e
nodi mobili coinvolti. Ciò rende questi aggiornamenti molto frequenti, ovvero ogni volta che un nodo
si muove su un link differente. In generale questi problemi di scalabilità sono ricollegabili al numero di
nodi molto grande, numero di percorsi per nodo, frequenza di movimento di un nodo mobile.
4.2.2
Cambiare indirizzo IP
Nel momento in cui un nodo mobile si sposta, cambia la sua identità. Un’altra soluzione al problema
consiste nel far cambiare l’indirizzo al nodo mobile in modo tale che possa adattarsi alla nuova rete.
Il protocollo dhcp permette il cambio di ip. È nato originariamente per altre esigenze, ovvero facilitare
l’installazione di un nuovo nodo su una rete. Inoltre fornisce ai nodi tutte le informazioni necessarie
all’installazione (indirizzo ip, dns, ecc...). Quindi consente l’integrazione automatica di un nodo in una
Intranet o Internet.
Quando un nodo si collega alla rete parte un protocollo di scoperta realizzato a livello datalink. Viene
usato un modello client/server dove il client invia tramite un mac-broadcast una richiesta al server dhcp,
tramite dhcp relay. Le richieste e le repliche devono essere inviate senza che il client sia un nodo Internet.
42
Protocollo dhcp
In generale questo meccanismo può essere applicato anche per sottoreti collegate tra di loro purché ci
siano dei relay. Notiamo inoltre che ci possono essere più server dhcp.
Fornisce i seguenti messaggi:
DHCP DISCOVER il client richiede delle informazioni per configurarsi.
DHCP OFFER i vari server dhcp mandano le loro offerte al client.
DHCP REQUEST ha un suo timeout, se arrivano più offerte le esamina e risponde.
DHCP PACK viene confermata la configurazione. Ogni nodo configurato ha un suo timeout. Se il
nodo non invia una richiesta di refresh, l’ip viene tolto.
Più server possono essere configurati come server dhcp ma non vi è un coordinamento standardizzato.
Gli indirizzi ip sono richiesti periodicamente in modo da semplificarne il protocollo rispetto a quello di
inizializzazione visto nella figura precedente.
Tuttavia con questo protocollo abbiamo dei problemi di sicurezza. Infatti potrebbe accadere che un
server malizioso finga di essere il dhcp. Il protocollo dhcp può essere usato per risolvere il problema
della mobilità ma con dei limiti:
1. Traduzione dei nomi : cambio di indirizzo ip richiede la registrazione del nuovo indirizzo al server
dns. Infatti se l’identità del nodo cambia i relativi server dns devono essere informati. Deve essere
lui ad avviare una comunicazione altrimenti non risulta più raggiungibile. Un problema simile si
risolve solo se non è il client ad iniziare la comunicazione (possibile irraggiungibilità). Si potrebbe
risolvere questo problema utilizzando un nome di dominio immutabile, ovvero vengono aggiornate
solo le tabelle dei dns. Rimane comunque il problema che tipicamente un server dns non è molto
tempestivo nella comunicazione, rischiando in ogni caso dei momenti di oscuramento finché il dns
non viene aggiornato.
2. Operazioni tcp/udp: questi due protocolli assumono che l’indirizzo finale rimanga costante. Il
cambio di indirizzo rompe una connessione tcp/udp in corso. Quindi il cambio di indirizzo ip non
funziona se voglio mantenere la raggiungibilità durante una sessione. Ovvero consente la mobilità
ma non la nomadicità (interruzione sessioni).
Si potrebbe gestire la mobilità dei nodi a livello datalink, tuttavia anche in questo caso abbiamo un
grande limite, ovvero bisogna avere tutti i nodi con lo stesso livello datalink. Purtroppo questo livello è
molto eterogeneo, quindi è una buona soluzione su scala locale ma non su scala globale. Per la mobilità su
scala globale viene adottato mobileip. Questa soluzione garantisce la raggiungibilità ed una connessione
affidabile. È un prodotto completo ma ha poca diffusione.
43
4.2.3
MobileIP
Questa tecnologia permette la gestione della mobilità dei nodi su Internet. Ogni nodo ha bisogno di due
indirizzi ip:
1. home address (ha): identificativo univoco del nodo (id del nodo) che appartiene alla home network,
ovvero la rete associata all’home address.
2. temporary address (ta): identificativo di localizzazione del nodo.
Notiamo che su Internet, che è di per sé distribuito, l’home address viene usato per localizzare la tabella
che contiene le informazioni sulla localizzazione attuale del nodo. Quindi il protocollo ip usa un solo
indirizzo per entrambe i casi.
La comunicazione verso il nodo mobile avviene nel seguente modo:
Comunicazione
• il nodo sorgente invia pacchetti verso l’home address;
• i pacchetti raggiungono la home network;
• i pacchetti devono essere reindirizzati per raggiungere il nodo di destinazione al suo attuale temporary address;
• i pacchetti vengono instradati verso la temporary network;
• il reindirizzamento viene “disfatto” per recuperare l’indirizzo originale.
Mentre la comunicazione verso un nodo fisso avviene nel seguente modo:
• il nodo sorgente invia pacchetti verso l’home address;
• i pacchetti raggiungono l’home network;
• i pacchetti raggiungono la destinazione.
Risulta evidente che per fornire un supporto ai nodi mobili bisogna mantenere l’associazione tra home
address e temporary address in un’apposita location directory (ld). Il sistema di localizzazione è
distribuito dal momento che su ogni home network viene caricato un ld con le informazioni relative ai
nodi della sottorete. Nella home network deve esserci una funzione f che gestisce ld. ld deve essere
aggiornata ogni volta che il nodo mobile si muove verso una nuova posizione. I messaggi di aggiornamento
sono inviati ad ld. L’operazione di redirezione diventa quindi un’operazione remota.
Nella precedente figura c’è l’entità g che prende il pacchetto e lo converte nella forma originaria. Il
destinatario con uno schema del genere non si accorge di nulla. Le informazioni sulla collocazione del
nodo mobile sono aggiornate indipendentemente dalla richiesta, quindi il suo comportamento è proattivo.
Ogni volta che il nodo si sposta viene aggiornato la ld di ha.
I requisiti per il mobileip sono:
• trasparenza: i nodi mobili mantengono il loro indirizzo ip originario. Deve essere possibile la
continuazione della comunicazione dopo l’interruzione del collegamento. Il punto di connessione
alla rete fissa può cambiare ma è trasparente al client.
• compatibilità: supporta gli stessi protocolli di secondo livello. In questo caso non si hanno dei
cambiamenti sui router, quindi i nodi mobili possono comunicare con i nodi fissi.
44
Requisiti
• sicurezza: autenticazione di tutti i messaggi di registrazione.
• efficienza e scalabilità: vengono aggiunti solo pochi messaggi. Inoltre deve fornire un supporto su
scala mondiale.
La terminologia utilizzata per mobileip è la seguente:
Terminologia
Mobile Node mn. È il nodo che può cambiare il punto di connessione sulla rete fissa senza cambiare
il suo home address.
Home Agent ha. Tipicamente è un router nella home network del nodo mobile che mantiene aggiornata
la ld registrando la locazione attuale di mn e reindirizza (tunnelling) i pacchetti verso la rete attuale
(coa).
Foreign Agent fa. Tipicamente è un router nella rete attuale del nodo mobile. Inoltra (reindirizzamento) verso mn i pacchetti ricevuti, quindi rappresenta il gateway di default per il nodo
mobile.
Care-Of Address coa. Indirizzo del punto di terminazione del tunnel verso mn. Può essere associato
ad un fa o direttamente ad mn. Dal punto di vista ip rappresenta il ta di mn ed esso può essere
scelto ad esempio tramite dhcp.
Correspondent Node cn. È il partner di comunicazione con mn. Potrebbe essere mobile, ma lo
assumiamo fisso.
Abbiamo visto come il dhcp risolva solo parzialmente il problema relativo alla gestione della mobilità in
quanto consentiva solo di farsi parte promotrice di una nuova comunicazione. Supponiamo che cn vuole
spedire dei dati verso mn che normalmente risiede nella hn ma che al momento si trova su un’altra rete.
Quindi cn conosce solo l’ha di mn.
Nella precedente figura abbiamo il seguente comportamento:
1. cn costruisce un messaggio ip con l’home address di mn.
2. ha intercetta il pacchetto riconoscendo il fatto che il nodo al quale è destinato non si trova nella
sottorete.
A questo punto si hanno due scenari possibili:
(a) ha coincide con il router della home network. In questo caso ha instrada direttamente il
pacchetto verso il nodo mobile costruendo un tunnel verso coa. coa è rappresentato da fa,
ovvero fa agisce come router di default.
(b) ha non è un router di quella sottorete, ciò vuol dire che il destinatario si trova all’interno
della sottorete. In questo caso il router della home network spedisce il pacchetto verso ha.
45
Trasferimento
dei dati
Il pacchetto viene catturato tramite il protocollo arp4 e deve essere spedito direttamente
sull’indirizzo fisico. Se non si conosce l’indirizzo a livello datalink si manda una richiesta di
broadcast. In scenari normali (fissi) risponde solo il nodo interessato, ma in questo caso la
risposta proviene da ha che svolge funzioni di proxy arp.
3. fa decapsula il pacchetto, rimuove gli header addizionali ed inoltra il pacchetto originale a mn. Il
pacchetto avrà come indirizzo sorgente l’indirizzo di cn mentre l’indirizzo destinatario è quello di
mn. In questo caso la mobilità non è visibile, infatti mn riceve il pacchetto con lo stesso mittente
e destinatario che avrebbe avuto se fosse stato nella sua home network. Anche in questo caso ci
sono due scenari possibli:
(a) coa = fa: indirizzo nel caso iniziale è quello di fa (si delinea il caso precedentemente
descritto).
(b) coa = mn: l’indirizzo temporaneo di cui è a conoscenza ha non è quello di fa ma direttamente
quello di mn nella nuova locazione. In questo caso il tunnel finisce direttamente su mn. Questo
approccio sembrerebbe più vantaggioso ma l’operazione dello spacchettamento dell’header
deve essere implementata direttamente da mn, pertanto mn è a conoscenza del fatto di non
trovarsi nella sua home network (non è trasparente).
Normalmente per trasferire dei dati dal nodo mobile, supponiamo che il nodo cn sia un nodo fisso.
Nel caso esso sia un nodo mobile dovremmo effettuare gli stessi passi elencati in precedenza. Ci
accorgiamo che il percorso sorgente-destinatario/destinatario-sorgente è un percorso triangolare.
In generale per effettuare l’operazione di trasferimento dei dati sono necessarie altre funzioni:
Funzioni di base del mobileip
1. Agent Discovery: scoperta ed indicizzazione degli agenti:
(a) ha e fa inviano periodicamente messaggi (advertisement) all’interno delle loro sottoreti fisiche.
(b) mn ascolta questi messaggi e rileva se si trova nella hn o nella fn. In assenza degli advertisement, mn può mandare delle sollecitazioni in modo da scoprire se un agente è presente.
(c) mn può rilevare un coa dal messaggio di advertisement di fa.
Il messaggio di advertisement viene inviato in multicast a tutti i nodi della sottorete (224.0.0.1)
oppure è inviato in unicast ad un nodo che ha richiesto un sollecito. Tale messaggio possiede un
ttl (time-to-live) pari a 1.
Sia ha che fa segnalano la loro presenza nella rete in modo che il nodo mobile sia in grado di
capire se si trova nell’home network o meno. Tali messaggi sono realizzati tramite l’aggiunta di
una “estensione di mobilità” a messaggi di tipo icmp (internet control message protocol).
4 È
un protocollo di mapping tra indirizzi di livello datalink e network.
46
Agent Advertisement
I campi del protocollo base sono:
type tipo del messaggio icmp (9);
code 0 se l’agente gestisce anche il traffico da nodi non mobili, 16 se gestisce solo il traffico da
nodi mobili;
checksum controlla la correttezza dell’intero messaggio;
addresses numero di indirizzi pubblicizzati dal messaggio;
address size dimensione di ogni indirizzo pubblicizzato espressa con un numero a 32 bit;
lifetime tempo massimo, espresso in secondi, di validità degli indirizzi pubblicizzati;
router address i indirizzo ip del router i-esimo;
preference level i preferenza del router i-esimo rispetto agli altri presenti nella sottorete.
Mentre i campi dell’estensione sono:
type in questo caso il suo valore è pari a 16;
lenght 6 + 4N , dove N è il numero di coa pubblicizzati;
sequence number conteggio del numero di messaggi di advertisemet inviati dall’agente, a partire
dalla sua inizializzazione;
registration lifetime durata, espressa in secondi, del tempo che l’agente accetta come richiesta
di durata di una registrazione;
bit R fa richiede la registrazione piuttosto che l’uso di un coa “co-locato”;
B fa non accetta nuove registrazioni poiché è troppo occupato (busy);
H l’agente offre servizi di ha in questa sottorete;
F l’agente offre servizi di fa in questa sottorete;
M l’agente può ricevere pacchetti con incapsulamento minimale;
G l’agente può ricevere pacchetti con incapsulamento generico;
r ignorato;
T abilita il reverse tunnelling.
reserved spazio riservato per estensioni future, quindi ignorato dal ricevente;
COA i coa i-esimo fornito da questo agente, deve essercene almeno uno.
Si usa questo protocollo per motivi economici e per evitare possibili conflitti di configurazione con
nuovi protocolli. Sorge il problema tra le variabili di configurazione tra mobileip e le indicazioni
originali. Ad esempio il tempo di 3 secondi è accettabile per nodi fissi ma per nodi mobili abbiamo
tempi troppo lunghi.
2. Registration: tramite questa operazione un nodo mobile comunica il suo coa al suo ha. La
registrazione può avvenire tramite fa oppure, come replica diretta, ha invia un ack al fa o al mn.
In questo modo viene aggiornato la ld.
Inoltre dobbiamo dire che l’operazione è resa sicura tramite autenticazione.
47
Quindi dopo che mn ha scoperto dove si trova, deve comunicare ad ha la sua posizione. In questo
modo mn richiede ad ha il servizio di inoltro verso la fn, informa ha del suo coa, può rinnovare
un binding in ld, si avrà una deregistrazione al momento di ritorno alla home. Notiamo che il
binding, l’aggiornamento con mn a coa ha una durata limitata. Anche per la registrazione ci sono
due modalità (rappresentate nella seguente figura):
(a) fa agisce come intermediario. In questo caso mn vuole registrare il coa di fa. mn prende
questo indirizzo dal messaggio di advertisement di fa. Questo è il caso in cui il tunnel arriva
fino a fa. Tuttavia potrebbe accadere che nodi mobili differenti hanno lo stesso coa.
(b) mn si registra direttamente con il suo ha. In questo caso mn ha ottenuto un indirizzo valido
direttamente da dhcp, quindi il tunnel viene gestito da lui (coa co-locato).
In entrambe i casi, la procedura consiste in uno scambio di messaggi di richiesta e replica. I
messaggi scambiati usano udp per motivi di efficienza, per evitare cioè l’overhead tipico di tcp.
È vantaggioso sopratutto nel caso di link con elevato tasso di errore. Pur appoggiandosi su udp
l’inoltro dei messaggi rimane affidabile, in quanto l’affidabilità è gestita a livello di mobileip.
Per ottenere un coa si adottano due schemi:
(a) coa del fa: si ottiene tramite un messaggio di advertisement di fa. Infatti il coa è un
indirizzo ip del fa. Di conseguenza il punto finale del tunnel è fa. In questo modo differenti
nodi mobili possono condividere lo stesso coa.
(b) coa co-locato: il nodo mobile ottiene in qualche modo un indirizzo ip locale tramite dhcp o
impostazioni prefissate. In questo caso il punto finale del tunnel è il nodo mobile stesso.
I campi per la richiesta di registrazione sono i seguenti:
type assume valore 1;
bit S è pari a 1 se il nodo mobile vuole che ha mantenga anche il binding attuale, ovvero quando
ha riceve la richiesta non deve sovrascrivere il precedente coa ma lo affianca, ovvero si
hanno due coa in ld. Ciò è inefficiente ma evita altre inefficienze per la gestione per
ha. Viene usato infatti nel caso in cui mn sia in grado di capire che si sta muovendo tra
locazioni contigue e potrebbe rispostarsi.
B è pari a 1 se il nodo mobile vuole ricevere broadcast ricevuti dall’ha nella home network.
D è pari a 1 se il nodo mobile è in grado di estrarre messaggi incapsulati inviati a coa (coa
co-locato).
M viene usato per richiedere all’ha l’incapsulamento minimo dei pacchetti inviati nel tunnel.
G viene usato per richiedere l’incapsulamento gre.
T richiede ai nodi mobili di usare un reverse tunnelling sul collegamento dal nodo mobile a
cn.
r,x sono 2bit riservati, quindi ignorati.
lifetime durata, espressa in secondi, della registrazione. Questa non deve eccedere il valore pubblicizzato da fa. Se questo valore viene posto a 0 allora si fa una richiesta di cancellazione
della registrazione.
48
Registration
Request
home address indirizzo ip del nodo mobile nella home network.
home agent indirizzo ip dell’ha del nodo mobile.
COA indirizzo ip del punto terminale del tunnel.
identification è un id a 64bit costruito dal nodo mobile. Questo associa le richieste di registrazione a repliche di registrazione, oltre a proteggere contro attacchi di tipo reply i messaggi di
registrazione.
IP source address è pari all’indirizzo dell’interfaccia del nodo mobile.
destination address indirizzo ip di fa preso da un messaggio di advertisement, se la registrazione avviene tramite fa. Se l’indirizzo di fa è ignoto viene usato l’indirizzo multicast
224.0.0.11 con ttl pari a 1 e l’indirizzo del livello datalink posto uguale a quello dell’agente mobile. Infine se la registrazione è diretta con ha allora si usa l’indirizzo ip di
quest’ultimo.
UDP source port è variabile, ovvero è assegnata dinamicamente dal sistema operativo.
destination port è sempre pari alla porta 434.
I seguenti campi invece sono relativi al caso in cui si sta mandando un messaggio di registration
replay:
type è pari a 3.
code indica l’esito della registrazione. Se la registrazione è andata a buon fine allora assumerà
il valore 0 se viene accettata, oppure 1 se è accettata ma la registrazione simultanea non è
supportata. Invece se la registrazione viene negata da fa allora avrà un codice compreso
tra 64-88. Mentre se la registrazione viene negata da ha allora avrà un codice compreso tra
128-136.
lifetime durata della validità del binding.
home address indirizzo ip del nodo mobile.
home agent indirizzo ip dell’ha del nodo mobile.
identification è un id a 64bit usato per l’autenticazione.
3. Tunnelling: realizzazione del tunnel tramite incapsulamento:
(a) ha deve inviare pacchetti a mn tramite un tunnel verso coa;
(b) il tunnel viene realizzato tramite incapsulamento ip-in-ip.
49
Registration
Replay
Questa funzione viene realizzata per l’inoltro di pacchetti da ha verso il coa del nodo mobile. In
generale il tunnel è definito come una conduttura virtuale per pacchetti dati tra un punto iniziale
ed un punto finale; i pacchetti che entrano nel tunnel ne escono invariati. Generalmente è una
funzione implementata ad un livello diverso.
Ci sono diversi meccanismi a supporto di questa tecnologia: L’incapsulazione rappresenta il meccanismo per creare un tunnel. Può essere usato in vari contesti, in questo caso è usato all’interno
dello stesso livello di protocollo di rete:
• ip-in-ip encapsulation: obbligatorio.
• minimal encapsulation: opzionale.
• generic record encapsulation (GRE): opzionale.
Il principio alla base è molto semplice. Si ha un messaggio originale con un proprio ip-header al
quale viene aggiunto un ulteriore IP. Notiamo che non è detto che l’ip-header contenuto nel nuovo
pacchetto sia lo stesso del precedente.
Analizzeremo a seguire alcuni scenari che chiariranno la questione. Vediamo ora in dettaglio i vari
meccanismi per l’incapsulamento:
(a) ip-in-ip: non apporta quasi nessuna modifica all’header originale se non quella del ttl decrementato di 1 (come nei router) per rendere invisibile al nodo mobile la distanza dalla home. Il
nodo in questione sa solo di non essere nella home ma non sa quanto sia distante. I vantaggi
che si ottengono con questa tecnica sono messaggi di multicast o broadcast. Tuttavia il nodo
mobile “ignorante” potrebbe fare delle scelte sbagliate.
Diamo una descrizione dell’outer ip header:
version 4 per ipv4.
ihl lunghezza, espressa in byte, dell’outer header.
ds tipo di servizio.
lenght lunghezza dell’intero pacchetto incapsulato.
IP id, flags, fragment offset nessun significato per mobileip.
protocol type ip-in-ip.
source address indirizzo dell’incapsulatore (ha).
destination address indirizzo del decapsulatore (coa).
50
Incapsulazione
(b) Minimal Encapsulation: riduce l’overhead di ip-in-ip evitando la ripetizione dei campi identici.
Questo approccio è applicabile solo con pacchetti non frammentati. L’header originale diventa
outer-header con dei combiamenti minimali:
• Il tipo di protocollo diventa 55.
• L’indirizzo sorgente invece con l’indirizzo ip dell’incapsulatore (ha).
• L’indirizzo di destinazione viene sostituito con l’indirizzo ip del decapsulatore (coa).
Mentre per quanto riguarda l’header interno abbiamo:
•
•
•
•
Il protocollo copiato dall’header originale.
Se il campo S è pari a 1 allora è presente l’indirizzo sorgente originale di cn.
L’indirizzo del destinatario viene copiato dall’header originale (mn
L’indirizzo sorgente se presente viene copiato dall’header originale.
(c) gre: è stato introdotto a prescindere dalle necessità legate alla mobilità. L’obiettivo principale
era quello di permettere la comunicazione anche tra reti utilizzando protocolli differenti. È
uno schema generale per incapsulare pacchetti e non solo ip datagram.
gre opera con le seguenti azioni:
• l’header di gre viene aggiunto come prefisso dell’header originario;
• l’outer header viene aggiunto come ulteriore prefisso;
• il protocollo associato ad outer header realizza il tunnel.
Dell’header gre ne esistono due versioni:
i. una prima semplificata, in cui gre contiene poche informazioni e cioè a quale stack di
protocolli appartiene il messaggio originale.
51
ii. oltre alle informazioni contenute nella versione semplificata, vengono aggiunte altre informazioni, quasi tutte opzionali.
In questo caso l’header gre possiede i seguenti bit addizionali:
C se è 1 il checksum è presente.
R se è 1 il source routing è presente. Viene adottato per una tipologia di routing non
standard, quindi è alternativo al normale ip in cui il cammino viene deciso passo
passo. Infatti contiene il cammino esplicito. Esiste il source routing stretto e quello
lasco.
K se è 1 la key è presente.
S se è 1 il sequence number è presente, ovvero se il protocollo originale richiede ordinamento dei pacchetti.
s se è 1 viene utilizzato il source routing stretto, dove il suo offset dirà quanto grande è
il campo routing mentre in routing si avrà la lista dei router disponibili.
recursion numero di possibili incapsulamenti aggiuntivi. Ovvero viene usato per limitare
l’incapsulamento.
reserved sono bit ignorati dal ricevente del messaggio.
version viene posta a 0.
protocol type tipo di protocollo originale.
checksum viene fatto in base alla combinazione dell’header gre e del pacchetto originario.
offset utilizzato per definire il formato del campo routing.
key la chiave viene inserita dall’incapsulatore per supportare i meccanismi di autenticazione. Tuttavia gre non specifica secondo quale procedura bisogna incapsulare questa
chiave.
sequence number fornito dall’incapsulatore. Questo numero consente al decapsulatore il riordino dei pacchetti ricevuti. Ciò è utile se un protocollo che richiede la
trasmissione ordinata viene incapsulato in uno che non la garantisce.
routing informazioni per il source routing stretto.
header originale invariato.
Abbiamo visto come il mobileip sia una tecnica che si basa su algoritmi proattivi, con un tipo di comunicazione triangolare. Il mobileip si basa su un’architettura sostanzialmente distribuita, infatti ogni ap
gestisce porzioni di rete e tutti i nodi mobili ad esso registrati. Il routing triangolare ha però una serie
di svantaggi:
52
Smoot handoff
1. può dar luogo a situazioni di paradossale inefficienza (se due nodi mobili vicini ma i rispettivi ha
sono molto lontani, paradossalmente dovrò contattarli).
2. periodo di oscuramento: questo periodo è il periodo che va da quando abbandono il vecchio fa a
quando non completo la nuova procedura di registrazione. Infatti il tempo per questa operazione
non è trascurabile.
Ponendoci come obiettivo quello dell’eliminazione della triangolazione, otteniamo, tramite lo smooth
handoff, una maggiore garanzia sul numero di pacchetti persi durante la transazione tra una rete e
l’altra. Il procedimento di base è il seguente:
• cn invia pacchetti all’home address del nodo mobile.
• ha inoltra i pacchetti al coa attuale ed informa cn del coa del nodo mobile.
• cn aggiorna la sua binding cache.
• I pacchetti futuri vengono inviati tramite un tunnel diretto da cn al nodo mobile.
La procedura in caso di un ulteriore spostamento del nodo mobile è:
• Il nodo mobile richiede la registrazione al nuovo fa.
• Il nuovo fa informa il vecchio fa. Ciò è più veloce del tempo di oscuramento.
• Il vecchio fa risponde con un ack.
• cn manda i dati al vecchio fa. Che a sua volta li redirige al nuovo fa e quest’ultimo li spedisce al
nodo mobile.
• Opzionalmente il vecchio fa manda un warning a cn, nel quale informa che il nodo mobile ha
cambiato locazione.
• Di conseguenza cn manda una richiesta di aggiornamento.
Si nota che gli elementi della cache di cn vengono creati/aggiornati se l’informazione è autenticata
e ricevuta da ha o fa.
Si può adoperare una variante, ovvero cn potrebbe chiedere l’aggiornamento al vecchio fa o ad
ha.
Tramite questo approccio si ha una comunicazione più efficiente ed una riduzione della perdita di
pacchetti. In generale si sono introtti elementi di reattività in un modello proattivo: la cache viene
aggiornata solo se cn vuole parlare con mn.
Qualunque nodo può gestire una binding cache, infatti questa contiene i coa di uno o più nodi mobili.
Inoltre gli elementi della cache sono creati o aggiornati solo se l’informazione autenticata viene ricevuta
da ha o fa. Mentre vengono eliminati dopo un tempo finito. Ovviamente la cache possiede una propria
politica di rimpiazzamento, come ad esempio lru.
Tuttavia l’autenticazione è uno dei problemi principali di questa tecnica. Senza contare il fatto che è
presente un effetto collaterale facendo uno smoot handoff durante il cambio di fa, ovvero:
• I pacchetti in transito durante il cambio potrebbero perdersi.
• Il nuovo fa informa il vecchio fa sulla nuova locazione del nodo mobile per evitare la perdita di
pacchetti, quindi il vecchio fa è costretto ad inoltrare i pacchetti arrivati per conto del nodo mobile.
• Questa informazione consente anche al vecchio di fa di rilasciare le risorse assegnate al nodo mobile.
I messaggi utilizzati per l’ottimizzazione del routing, ed il conseguente smooth handoff, possono essere
di quattro tipi: binding request, binding update, binding ack e binding warning.
53
Smooth
Handoff
Ciò rende il cn più oneroso nel consumo delle risorse dato che ci sono nodi mobili e c’è il costo della
gestione della cache.
I firewall guardano tutto il contenuto dei pacchetti che attraversano una rete.
Si delineano due possibili scenari quando il nodo mobile invia pacchetti con il suo home address come
source address, infatti i firewall spesso accettano solo indirizzi topologicamente corretti:
1. Supponiamo di essere nel punto del firewall (F2 ) della precedente immagine. mn invia i pacchetti.
F2 vede il campo del mittente e si accorge che non appartiene alla rete. In realtà un simile contesto
non rappresenta una vera minaccia alla sicurezza dal momento che non sta cercando di entrare
qualcosa ma sta uscendo. Questo comportamento impedisce al nodo mobile di comunicare con gli
altri usando il suo home address come source address. Per questioni di galateo comunque questi
pacchetti sono considerati pericolosi da parte del firewall.
Un firewall nel foreign domain filtra i pacchetti che vengono dall’interno con source address esterno.
2. Supponiamo di essere nel punto del firewall (F1 ) della precedente immagine. mn vuole parlare con
nodi nella sua home domain. F1 vede arrivare dall’esterno qualcuno che fa finta di essere della sua
rete e lo filtra. In questo modo il firewall previene che nodi esterni possano spacciarsi per nodi
interni. Quindi impedisce al nodo mobile di comunicare con il suo home domain.
Un firewall nell’home domain filtra i pacchetti che vengono dall’esterno con source address interno.
La soluzione ai problemi dovuti alla presenza di firewall nella rete consiste nell’utilizzo di un reverse
tunnelling. Ovvero il nodo mobile invia i pacchetti al fa. fa lo incapsula (indirizzo mittente della rete di
fa) e lo manda ad ha che lo decapsula. Ora l’indirizzo mittente che esce appartiene alla home network.
Notiamo che con questo approccio i pacchetti sono topologicamente corretti. Inoltre vengono risolti i
problemi del multicast e di ttl.
Tuttavia il reverse tunnelling non risolve alcuni problemi con il firewall, ovvero il tunnel inverso potrebbe
essere usato impropriamente per aggirare i meccanismi di sicurezza (tunnel hijacking). Senza contare
il fatto che il cammino seguito dai pacchetti è inefficiente poiché i pacchetti vengono inoltrati a cn
attraverso un tunnel che passa per ha (doppio routing triangolare). Quindi questo approccio funziona
anche se è un pò “pesante”.
54
Firewall
Il nat è la tecnica che ammortizza l’esaurimento degli indirizzi ip. Gli indirizzi ip dei nodi di una
sottorete sono validi solo su scala locale. Il problema nasce dal fatto che non si ha più un indirizzo ip
che identifica univocamente il nodo. A tal proposito si ossono usare indirizzi di tipo ipv6 che possiedono
128bit. Questo tipo di indirizzo consente un ridotto overhead amministrativo tramite autoconfigurazione
degli indirizzi o neighbour discovery. Possiede una ragionevole sicurezza poiché supporta l’autenticazione,
privacy e distribuzione delle chiavi. Oltre ad essere adatto in ambienti mobili.
Sviluppando mobileip con ipv6 vengono semplificati notevolmente i protocolli:
ipv6
• La sicurezza è integrata nel protocollo, quindi l’autenticazione della registrazione è inclusa.
• coa può essere assegnato tramite configurazione (dhcpv6). Quindi ogni nodo è dotato di capacità
di autoconfigurazione degli indirizzi.
• Non vi è più la necessità di avere un fa separato, infatti tutti i router mandano un messaggio di
router advertisement che può essere usato al posto dell’agent advertisement (ha continua invece
ad essere necessario).
• mn può notificare direttamente il suo coa. In questo caso l’invio tramite ha non è necessario,
infatti abbiamo ottimizzazione automatica del routing.
• Viene supportato il soft handover, cioè senza perdita di pacchetti tra sottoreti:
– mn invia il suo coa al vecchio router.
– Il vecchio router incapsula tutti i pacchetti entranti destinati a mn e li inoltra al nuovo coa.
– L’autenticazione è garantita.
In base a quanto detto mobileip possiede ancora dei problemi, infatti per quanto riguarda la sicurezza:
• Autenticazione con fa è problematica, in genere fa appartiene ad un’organizzazione differente.
• Non è stato standardizzato nessun protocollo sulla gestione e distribuzione delle chiavi.
• Restrizioni sui brevetti e le esportazioni.
Ricordiamo che i requisiti della sicurezza sono:
• Integrità: modifica dei dati tra mittente e destinatario deve essere rilevabile dal destinatario.
• Autenticazione: indirizzo del mittente deve essere realmente quello.
• Confidenzialità: solo mittente e destinatario possono leggere i dati.
• Non ripudio: il mittente non può negare di aver inviato i dati.
• Analisi del traffico: non dovrebbe essere possibile la creazione di profili utente.
55
Problemi
mobileip
con
• protezione contro replay.
L’architettura della sicurezza in ip consiste in due o più entità che devono negoziare i meccanismi di
sicurezza per realizzare un’associazione di sicurezza. Sono stati pertanto definiti due header:
• Authentication-Header : garantisce l’integrità e sicurezza dei pacchetti ip. Anche il non ripudio può
essere garantito, se si usa uno schema di crittografia asimmetrica.
• Encapsulation Security Payload : protegge la confidenzialità nella comunicazione tra partner.
A tal proposito viene usata la mobile security association per le registrazioni, infatti vengono passati dei
parametri per mn, ha e fa. Esistono comunque delle estensioni dell’architettura della sicurezza di ip
come l’autenticazione estesa delle registrazioni e prevenzione del replay.
Per quanto riguarda la distribuzione delle chiavi, ha ha il compito di distribuire le chiavi di sessione. Il
fa possiede un’associazione di sicurezza con ha. Il nodo mobile registra presso l’home agent un nuovo
binding (coa) e l’home agent risponde con una nuova chiave di sessione per il nodo mobile ed il foreign
agent.
Distribuzione
delle chiavi
Tipicamente in mobileip si adatta male ai firewall, pertanto sono necessarie configurazioni speciali, quali
il reverse tunnelling. Inoltre, garantire la qualità di servizio, per pacchetti invisibili (incapsulati) è molto
problematica, infatti l’utilizzo del tunnelling si adatta male al qos.
È stato anche pensato un meccanismo di supporto alla micromobilità (caso del paradosso tra vicini).
L’idea è infatti quella di applicare tali meccanismi anche su Internet:
Altri problemi
• handoff locale efficiente all’interno di un dominio straniero senza coinvolgere ha.
• riduce il traffico di controllo;
• necessario sopratutto in caso di route optimization.
In questo modo riduco i tempi di latenza in cui il nodo non è raggiungibile. La micromobilità purtroppo
introduce dei problemi di inefficienza dovuti sia al traffico inutile che causa l’oscuramento temporaneo dei
nodi. Alla base della soluzione ci sono i meccanismi di sincronizzazione delle reti cellulari. Ad esempio
cellularip (cip gateway), hawaii.
In generale bisogna guardare la sicurezza, efficienza, scalabilità, trasparenza e maneggevolezza.
56
Micro-Mobilità
4.2.4
Cellular IP
In cip (cellular ip) possiamo sfruttare le seguenti operazioni:
• I nodi cip mantengono informazioni di routing (soft state) per ogni nodo mobile.
• Abbiamo la possibilità di avere informazioni multiple per uno stesso nodo mobile.
• Le informazioni sul routing sono aggiornate in base ai pacchetti inviati dal nodo mobile.
Il cip gateway agisce come mobileip tunnel endpoint e gestisce la registrazione iniziale. Per quanto
riguarda la sicurezza tutti i nodi cip condividono una chiave di rete. Ogni nodo mobile possiede una
propria chiave generata tramite md5, sfruttando la combinazione della chiave di rete ed il suo indirizzo
ip. Inoltre il nodo mobile ottiene una chiave al momento della registrazione.
Questo approccio permette l’autoconfigurazione dei nodi e se viene integrato il cip gateway nel firewall
allora le funzionalità della mobilità saranno facilitate. Tuttavia è inefficienze sul forward dei pacchetti su
percorsi multipli e sono necessarie delle modifiche sul nodo mobile (non trasparenza). Inoltre dato che
le tabelle di routing possono essere cambiate in base ai messaggi di un nodo mobile allora se i messaggi
vengono spoofati le tabelle di routing conterranno dei dati non corretti (manca la sicurezza).
4.2.5
HAWAII
In una rete hawaii abbiamo le seguenti operazioni:
• Il nodo mobile ottiene un coa co-locato (vedi punto 1 della figura), e viene registrato tramite ha
(vedi punto 2 della figura).
• Per l’operazione di handoff, il nodo mobile mantiene il coa, la nuova base station risponde alle
richieste di registrazione (vedi punto 3 della figura) ed aggiorna la tabella di routing (vedi punto 4
della figura).
• Il nodo mobile vede la base station come un foreign agent.
57
Tramite questo approccio il meccanismo di challenge/response è obbligatorio e non c’è bisogno di
modificare i nodi mobili. Ma data la presenza del coa co-locato non possoamo avere ip privati.
4.3
HMIPv6
hmipv6 sta per hierarchical mobile ipv6. Questa rete supporta le seguenti operazioni:
• La rete contiene un punto di ancoraggio chiamato map, dove viene mappato il regional coa (rcoa)
con il link coa (lcoa).
• Durante l’handoff il nodo mobile informa solo map, in questo modo ottiene un nuovo lcoa e
continua a mantenere rcoa.
• ha viene contattato solo se cambia map.
Quindi abbiamo un routing diretto dove le connessioni con cn sono condivise. Tuttavia dobbiamo
introdurre un nuovo elemento nell’infrastruttura ed abbiamo la necessità di un’autenticazione forte per
poter prevenire attacchi di tipo ddos.
4.4
Reti senza infrastruttura
Trattiamo ora il caso della gestione della mobilità in reti senza infrastruttura. La differenza sostanziale
sta nel fatto che in reti con infrastruttura, idealmente, ogni nodo è alla portata dell’altro. Nelle reti
senza infrastruttura non è detto che tutti i nodi siano tra loro visibili (single hop). Le motivazioni sono,
ad esempio, legate al problema relativo alle aree remote, a meeting occasionali, aree disastrate, ecc...
senza contare inoltre che comunque una rete con infrastruttura presuppone dei costi aggiuntivi per il suo
cablaggio.
Gli svantaggi sono:
58
Proprietà delle
reti ad-hoc
• Le operazioni hanno vincoli di bandwidth:
– link wireless hanno tipicamente minore capacità;
– la congestione è una regola più che un’eccezione.
• Le operazioni hanno vincoli sull’energia:
– il risparmio energetico può essere un criterio alla base della progettazione;
– alcuni o tutti i nodi sono alimentati da batterie.
• Limitata sicurezza fisica, ovvero vi è una maggiore probabilità di intercettazione.
Mentre i vantaggi sono:
• in un contesto simile le soluzioni alla raggiungibilità sono robuste;
• la distribuzione fornisce robustezza contro i fallimenti dei singoli nodi.
Mentre nel caso delle reti con infrastruttura assumevamo la presenza di router fissi e nodi mobili, in un
contesto del genere abbiamo router e nodi mobili.
Il routing nelle reti ad-hoc è fortemente influenzato dalla dinamicità della rete in termini di topologia e
qualità di movimento e dalla presenza di link asimmetrici (in un verso o nell’altro le caratteristiche di
connessione sono differenti). I problemi del routing sono legati al fatto che i parametri sono noti in modo
impreciso (traffico, capacità del link), che questi e la topologia della rete possono variare frequentemente, all’interferenza tra i nodi trasmittenti, alla necessità di considerare e garantire un certo risparmio
energetico nonché alla necessità di gestire link a bassa capacità.
Tra gli algoritmi di routing tradizionali troviamo:
• Distance Vector (dv): è un algoritmo sostanzialmente distribuito. Ogni router possiede informazioni sui nodi che riesce a raggiungere. Le caratteristiche sono:
– Uno scambio periodico di messaggi con tutti i vicini fisici con informazioni su chi può essere
raggiunto e a quale distanza.
– Selezione del cammino più breve tra quelli disponibili.
59
Routing
Tale approccio genera dei possibili problemi:
– I cambiamenti ad un nodo si propagano lentamente.
– Sono necessarie strategie per evitare il problema del conteggio all’infinito.
– Potenziali regioni irraggiungibili.
– Potenziale presenza di cicli.
• Link State (ls): i router scambiano informazioni sullo stato di tutta la rete. Tra quelli verrà poi
selezionato il cammino minimo. Le caratteristiche sono:
– Notifica periodica di tutti i router sullo stato corrente di tutti i link fisici.
– Ogni router ha un quadro completo della rete.
Un esempio di routing tradizionale applicabile in reti ad-hoc è quello utilizzato da arpa, ovvero il dvrouting. Dove lo scambio delle tabelle di routing avviene ogni 7.5sec, con l’informazione anche sulla
qualità dei link. L’aggiornamento delle tabelle avviene anche al ricevimento dei pacchetti. Mentre i
problemi di routing sono risolti tramite un flooding limitato.
Gli algoritmi tradizionali presentano dei problemi se applicati al routing per le reti ad-hoc:
• dv possiede un tasso di convergenza lento verso un nuovo stato stabile della rete (ad esempio rip).
• ls risulta non funzionale dato che vengono scambiati troppi dati oppure non è in grado di gestire
collegamenti asimmetrici (ad esempio ospf).
Nel caso degli algoritmi basati su reti ad-hoc possiamo:
• basarci su informazioni a livello datalink, che contengono informazioni sulla connettività e sulla
qualità dei collegamenti.
• basarci sul fatto che tutti i nodi possono essere router.
• evitare la tecnica di routing attraverso l’hop count.
Gli approcci al routing ad-hoc dipendono da alcune considerazioni preliminari. La struttura della rete
può essere:
• non gerarchica: le decisioni prese tra tutti i nodi.
• gerarchica: impone una scelta gerarchica sull’insieme dei nodi. Tale scelta viene fatta da algoritmi
di clustering o dall’individuazione del cluster head.
Le modalità di definizione del routing sono:
• reattiva:
– costruisce informazioni di routing on-demand;
– potenziale riduzione dell’utilizzazione del link e del consumo energetico.
– maggiore ritardo nella determinazione di un cammino.
• proattiva:
– costruisce in anticipo le informazioni per il routing;
– riduzione del ritardo per la scoperta del cammino.
Sulla base di quanto detto, le decisioni progettuali sono da prendere in base ai seguenti obiettivi:
1. Operazioni distribuite: ovvero quelle ovvie ed essenziali;
2. Evitare cicli : in questo modo si evitano i casi peggiori. Sono pertanto preferibili approcci espliciti
rispetto a quelli basati su ttl.
3. Sicurezza: si deve impedire la modifica o il danneggiamento delle operazioni del protocollo.
60
4. Modalità sleep: i nodi devono poter entrare in modalità sleep se non ricevono e non trasmettono
ed il routing deve tollerare questo meccanismo minimizzandone gli effetti negativi.
5. Supporto per link unidirezionali : gli algoritmi di routing tradizionali assumono tipicamente dei
collegamenti bidirezionali. Ciò può non essere vero in ambiente wireless.
Le metriche di prestazione sono suddivise in:
1. metriche esterne:
• throughput e ritardo end-to-end: misura dell’efficacia del routing;
• tempo di acquisizione di un cammino: importante sopratutto per algoritmi reattivi.
• percentuale di pacchetti ritrasmessi fuori ordine: influenza dei protocolli di livello più alto
come il tcp.
2. metriche interne (efficienza):
• Rapporto tra il numero medio di bit trasmessi ed il numero medio di bit dati che hanno
raggiunto la destinazione (flooding).
• Rapporto tra il numero medio di bit di controllo trasmessi ed il numero medio di bit dati che
hanno raggiunto la destinazione.
• Rapporto tra il numero medio di bit di controllo e dati trasmessi ed il numero medio di dati
che hanno raggiunto la destinazione.
I fattori da tenere sotto controllo che influenzano le prestazioni sono:
1. la dimensione della rete;
2. la connettività della rete (numero medio di collegamenti per nodo);
3. tasso di cambio della topologia;
4. capacità del link (tasso effettivo depurato dagli effetti di perdita, codifica, overhead per accessi
multipli, ecc...);
5. frazione di link unidirezionali;
6. struttura del traffico (destinazioni uniformi e non uniformi - usando o meno i cluster, traffico
bursty/non bursty);
7. frazione e frequenza dei nodi sleep.
Nella seguente figura è rappresentata la tassonomia dei protocolli di routing per reti ad-hoc. Si pu‘o
notare che dsr è in realtà ibrido.
61
4.4.1
DSDV
dsdv sta per destination sequenced distance vector e rappresenta l’estensione del dv-routing.
Il dv-routing è basato su scambi periodici di informazione tra vicini. I cambiamenti ad un nodo si
propagano lentamente attraverso la rete, quindi sono necessarie strategie per evitare questo problema
(split-horizon, poisoned reverse). Questo approccio possiede dei problemi, ovvero potrebbero esserci delle
regioni irraggiungibili oppure è possibile la presenza di cicli all’interno della rete.
dsdv estende dv-routing aggiungendo:
• Numeri di sequenza: inclusi in ogni aggiornamento inviato. Questi consentono di applicare gli
aggiornamenti nell’ordine corretto. Tuttavia sorge il problema che questi aggiornamenti possono
propagarsi su più cammini. Questo problema nasce dall’avere brutte reazioni ai cambi di topologia classica. Infatti se i cambi sono troppo rapidi le informazioni di aggiornamento rischiano di
sovrapporsi.
Ad esempio X riceve informazioni da Y relative al cammino verso Z.
Chiamiamo S(X) ed S(Y ) il numero di sequenza per il nodo Z memorizzato su X, ed il numero di
sequenza per il nodo Z inviato da Y ad X all’interno della sua tabella di routing, rispettivamente.
X esegue i seguenti passi se:
– S(X) > S(Y ): X ignora l’informazione ricevuta da Y ;
– S(X) = S(Y ) ed il costo del cammino attraverso Y è minore: X pone Y come prossimo nodo
nel cammino verso Z.
– S(X) < S(Y ): X pone Y come prossimo nodo nel cammino verso Z e S(X) = S(Y ).
• Damping: rappresenta i cambiamenti della topologia di rete che possono essere di breve durata e
non dovrebbero destabilizzare il routing. Gli aggiornamenti che cambiano la topologia memorizzata
in un nodo sono mantenuti fin quando non diventano stabili. In altre parole, il nodo attende fin
quando la topologia non si stabilizza.
• Triggered updates: avvengono quando si cambia la topologia. Questi sono inoltre cambiati periodicamente.
Possiamo dire che dsdv è proattivo e non gerarchico, benché possa essere usato anche nel caso di routing
gerarchico. I vantaggi sono: l’assenza di cicli, bassa richiesta di memoria (come i Distance Vector),
convergenza rapida (grazie ai triggered updates). Gli svantaggi consistono nelle informazioni di routing
che consumano banda ed energia.
4.4.2
OLSR
olsr sta per optimized link state routing. Con questa tecnica l’overhead della diffusione ai vicini
(flooding) di informazioni sullo stato dei link viene ridotto diminuendo il numero di nodi che inoltrano
l’informazione. L’informazione proveniente da un nodo X viene trasmessa in broadcast solo ai nodi
appartenenti al suo multipoint relay set. Il multipoint relay di X è rappresentato da ogni nodo “immediatamente vicino” (distanza pari ad 1 hop) di X tale che ogni vicino di X che si trova a distanza
2-hop da X è un vicino immediato di un multipoint relay di X. In questo modo ogni nodo trasmette
periodicamente la sua lista di vicini immediati, in modo che tutti i nodi siano in grado di determinare i
loro vicini a distanza 2-hop, per scegliere i loro multipoint relays. Il multipoint relay set di X, invece, è
un sottoinsieme arbitrario di tutti i multipoint relay di X, tale che ogni vicino 2-hop di X è a distanza
1-hop da un nodo del sottoinsieme.
62
Nella precedente figura i nodi C ed E sono multipoint relay del nodo A. I soli vicini 2-hop di A sono i
nodi G ed H. Solo C ed E inoltrano in broadcast l’informazione proveniente da A ai vicini.
Il passo successivo consiste nei nodi C ed E che inoltrano l’informazione ricevuta da A. Mentre i nodi
A ed H diventano i multipoint relay del nodo E.
Solo H inoltra l’informazione ricevuta da E, infatti A la aveva già ricevuta dato che è la sorgente. I nodi
E e K diventano i multipoint relays del nodo H, ma solo K inoltrerà questa informazione dato che E
l’aveva già inoltrata.
Ricapitolando oslr diffonde l’informazione sullo stato dei collegamenti solo attraverso i multipoint relay.
Quindi l’informazione di stato diffusa da un nodo riguarda solo i suoi multipoint relay. Ovviamente i
cammini usati da olsr includono solo multipoint relay come nodi intermedi. olsr è proattivo ed è
basato su informazioni link-state.
4.4.3
DSR
dsr sta per dynamic source routing. È un Distance Vector reattivo e non gerarchico (anche se lo
supporta). Questo approccio suddivide il routing in due parti:
1. route discovery: avviene nel momento in cui un nodo manifesta la sua volontà di comunicare con
un altro. Nello schema classico del Distance Vector, ogni nodo possiede una tabella, mentre nel dsr
si usa il route discovery per trovare la strada. In generale, un nodo tenta di scoprire un cammino
verso una data destinazione solo se:
• Il nodo ha traffico per quella destinazione.
• Il nodo non è già a conoscenza di un cammino.
Inoltre:
• Non sono previste le tradizionali tabelle di routing nei nodi intermedi.
• Non vi è un aggiornamento periodico.
• Nessun messaggio sullo stato del link.
In generale, infatti, le informazioni di routing sono inglobate in un messaggio. Ovvero ogni
messaggio possiede informazioni interne con indicazioni per arrivare a destinazione.
Il messaggio viene inviato in broadcast contenente un indirizzo di destinazione ed un id univoco.
Se un nodo riceve il pacchetto ci sono tre possibli scenari:
(a) Se il nodo ricevente scopre che il pacchetto lo aveva già ricevuto prima (tramite l’id) ignoro
il pacchetto.
(b) Se il nodo ricevente è il destinatario e si riconosce come tale (riconosce l’indirizzo) restituisce
il pacchetto al mittente (invertendo il cammino che è stato raccolto nel pacchetto).
(c) Se non si verifica nessuno degli scenari precedenti, il nodo prende il pacchetto, viene aggiunto
il suo indirizzo e lo reinoltra in broadcast.
Con un meccanismo del genere il pacchetto possiede una lista dei nodi attraversati. Il mittente
pertanto riceve il pacchetto di ritorno con il cammino attuale (lista di indirizzi). Per ottimizzare
questo meccanismo di scoperta possiamo ipotizzare un diametro massimo (se possibile), oppure
fare del caching di liste di indirizzi dove se un nodo vede passare un pacchetto con una lista di
indirizzi interessanti può decidere di metterlo nella sua cache.
63
2. route maintenance: prevede l’uso di una conoscenza pregressa (occorrerà capire se è ancora valida
oppure no). Un nodo controlla un cammino che è in uso, se sono stati rilevati dei problemi con il
cammino selezionato, o si usa un cammino alternativo o se ne crea uno nuovo.
Ovvero dopo l’invio di un pacchetto:
• si aspetta che arrivi un ack di livello datalink, se applicabile;
• si ascolta il mezzo trasmissivo per rilevare se altre stazioni inviano il pacchetto, se possibile;
• si richiede un ack esplicito.
Se l’informazione è negativa, se una stazione ad esempio incontra problemi, può informare il
mittente e cercare localmente un nuovo cammino.
Le strutture dati utilizzate da dsr sono:
1. route cache: per ogni nodo è prevista una cache di percorsi. Questa contiene zero o più cammini
verso una destinazione specificata. Le operazioni sono: inserisci, ottieni, elimina cammino.
2. route request table: contiene informazioni sui messaggi route request originati o inoltrati dal nodo.
3. due buffer (code): entrambe i buffer sono gestiti da un timeout:
(a) send buffer : messaggi da inviare. Rappresenta la coda di pacchetti in attesa di trasmissione
perché il cammino non è ancora noto. I pacchetti vengono rimossi dalla coda dopo l’invio o
allo sparire del timeout.
(b) retransmission buffer : coda di pacchetti inviati in attesa dell’ack. I pacchetti sono rimossi
dalla coda dopo l’ack o dopo il superamento del numero massimo di ritrasmissioni.
Con questo approccio abbiamo i seguenti vantaggi:
• assenza di cicli;
• bassa richiesta di memoria;
• riduzione dell’informazione di routing inviata, con conseguente risparmio della banda;
• riduzione del numero di trasmissioni sulle informazioni di routing, con conseguente risparmio di
energia;
• funzionamento con collegamenti asimmetrici.
Gli svantaggi sono:
• Può operare male se ci sono cambi frequenti di topologia (l’estrazione di cammini dai pacchetti
passanti non funziona).
• Potenziali problemi di scalabilità se il numero di destinazioni cresce.
• Non supporta un vero multicasting ma un flooding controllato.
In generale il risparmio si ha se il dinamismo della rete e la frequenza di interazione non superano una
certa soglia, in caso contrario non è conveniente.
4.4.4
Routing gerarchico
I protocolli appena visti (dsdv e dsr) assumono che ogni nodo sia coinvolto in egual misura nella
comunicazione. Nel caso di molti nodi, però può essere conveniente dare una struttura gerarchica al
tutto.
Si possono utilizzare dei cluster per ottenere una maggiore scalabilità. I cluster sono utilizzati generalmente per ottenere una gerarchia. In questo modo il routing globale viene effettuato in base ai cluster
mentre quello locale verso i nodi del cluster. Quindi il numero di nodi da attraversare viene ridotto.
A tal proposito viene definito un nodo speciale, chiamato cluster-head, per ogni cluster. Questo nodo
è responsabile del routing da e verso gli altri cluster. Può essere un nodo speciale oppure un nodo
individuato tramite algoritmi di clustering. Gli algoritmi utilizzati sono:
64
Cluster
1. Clustering: per la divisione in cluster. Ad esempio basati sulla vicinanza fisica o sulla visibilità.
2. Identificazione del cluster: può far parte del clustering.
3. Routing: applicato ad ogni livello della gerarchia.
Alcuni criteri di clustering sono:
• Località: si cerca di massimizzare la connettività.
completa nel cluster.
Può avere come obiettivo la connettività
• Affinità: localizza il traffico e minimizza il traffico tra cluster.
• Efficienza energetica: la combinazione tra affinità e località.
• Dimensione: numero di nodi.
• Considerazioni relative il leader. Ad esempio si vuole avere la garanzia che ogni cluster contenga
un nodo speciale.
4.4.5
Metriche di routing: LRI
Gli esempi precedenti usano la lunghezza del cammino come metrica. In realtà questa metrica è semplice
(numero di hop) ma non è una garanzia in uno scenario di mobilià. Una metrica efficace è il least
interference routing (lri). In generale questa metrica prende in considerazione il numero minimo di
interferenze. L’interferenza ad un nodo è proporzionale al numero di altri nodi che possono ascoltare una
sua trasmissione. Si assume che il costo di un link è minore se una trasmissione ha minori probabilità
di interferire con altre trasmissioni da parte di altri nodi. Si basa pertanto su informazioni locali. In
altre parole, si conta quanti nodi vengono disturbati da una comunicazione che passa per quel cammino.
Consideriamo, infatti, che se si hanno due cammini possibili ed uno inibisce meno di un altro, il throughput totale cresce dal momento che crescono i messaggi paralleli possibili. In teoria ci sono altre metriche
che possono essere utilizzate. La metrica lri rimane comunque semplice perché richiede informazioni sui
vicini immediati.
Nella precedente immagine, i percorsi trattegiati sono migliori rispetto ai rispettivi a linea continua
usando la metrica lir. La comunicazione rossa è la seguente:
• linea continua: vengono disturbati 6 nodi (N1 , N2 , S2 , N5 , N6 , R2 ).
• linea trattegiata: vengono disturbati solo due nodi (N3 , N4 ).
Ci accorgiamo come la scelta della linea rossa tratteggiata permetta l’instaurazione del parallelo della
comunicazione blu.
65
4.5
Reti cellulari
Generalmente le reti wan si appoggiano alle infrastrutture delle reti centralizzate. L’idea di base consiste
nella localizzazione di un nodo. Per prima cosa si vuole determinare l’identità della cella in cui si trova
(ap della cella). La coppia id-nodo+id-ap è l’informazione per raggiungere in maniera univoca il nodo
che si sta cercando. Per ottenere tali informazioni andiamo a comunicare con i seguenti elementi:
• l’hlr contiene il record [msid , vlrcur ]. Ogni record è unico. L’hlr contiene in se tanti records per
quanti utenti ha con tutte le loro informazioni statiche e le informazioni dinamiche (vlr sotto la
cui giurisdizione si trova il nodo mobile).
• Il vlr contiene record [msid , lacur ]. Dopo aver contattato hlr occorrerà contattare vlr che contiene le informazioni su come localizzare un nodo. Contiene l’identificativo della cella, un’informazione
grossolana di dove si trova un nodo mobile.
I requisiti per la mobilità in reti wwan sono: la trasparenza all’utente, il mantenimento della confidenzialità, minimizzazione del carico del sistema per messaggi di controllo e scalabilità.
4.5.1
Architettura del GSM
Il routing viene applicato in transizione di tipo 4 e a volte di tipo 3.
I componenti che fanno parte di questa architettura sono i seguenti:
MSC controlla una o più bsc, punto di switch verso altre reti (isdn, pstn), controllo di chiamate,
addebiti.
HLR è il nodo base dei dati della gerarchia di cui i vlr sono foglie.
VLR contengono la replica di informazioni parziali di hlr. Questi elementi sono associati gli msc.
vlr è responsabile di informare l’hlr dei cambiamenti relativi alle mobile station sotto la sua
giurisdizione. Il cambiamento di vlr e dei relativi servizi è detto roaming.
Per ogni msc esiste un vlr in maniera univoca. In generale vlr ed hlr sono delle basi di dati
accedute molto frequentemente:
• la lettura dei dati utente avviene ad ogni chiamata, ovvero i dati del chiamante per l’autenticazione ed i dati del chiamato per informazioni sulla localizzazione e lo stato della
connessione.
• la modifica dei dati dell’utente per segnalare l’accensione/spegnimento del cellulare, la connessione o la modifica della locazione da parte dell’utente.
• l’architettura db per migliorare prestazioni/affidabilità, ovvero garantisce replicazione/partizionamento.
Notiamo che l’hrl è concettualmente un database unico, in realtà è distribuito e replicato.
66
4.5.2
Architettura del GPRS
Ricordiamo che il gprs è un’ingegnerizzazione del gsm in modo tale che si possa adattare al traffico dati.
Usa una gerarchia a due livelli:
• sgsn: interfaccia tra backbone e sottostistema wireless. Richiede indirizzi utente al registro gprs.
Gestisce informazioni sulla locazione dei cellulari ed inoltre è in grado di gestire uno o più bsc (in
qualche modo analogo di fa in mobileip).
• ggsn: gateway tra rete dati a pacchetto esterna e la rete gprs. Questo gestisce il routing per gli
utenti gprs, quindi converte anche gli indirizzi. Ha il compito di instradare i pacchetti verso sgsn
utilizzando il backbone gprs (basato su ip). Questo elemento rappresenta la porta d’accesso del
traffico, ovvero tramite il quale i pacchetti vanno dalla rete interna a quella esterna. È l’analogo
dell’hlr in gsm. Contiene informazioni statiche e dinamiche. È un oggetto di livello datalink.
Notiamo che tipicamente in ra è contenuto il la. Quindi ra è un suo sottoinsieme.
4.5.3
Operazioni: GSM/GPRS
La gestione della localizzazione in gsm/gprs si articola in due funzioni:
1. tracking: usata per mantenere traccia della locazione corrente di una mobile station. Questa
funzione è proattiva, ovvero ogni volta che la mobile station cambia viene aggiornata.
Data una suddivisione finché il nodo si muova nella sua location area, le informazioni non vengono
aggiornate. Il movimento nella la genera degli handoff di tipo 1-2-3 (purché il 3 non esca da la),
infatti se vado in un’altra la con un msc differente si ha un handoff di tipo 3, ma si aggiorna
comunque il vlr. Aggiorniamo l’hlr se si ha un handoff di tipo 4, cioè se entro in una la contigua
a quella in cui mi trovo ma con vlr differente.
Dopo aver acceso la mobile station, questa determina la location area attuale (segnale inviato
periodicamente in broadcast). La mobile station invia la coppia [msid , lacur ] al vlr opportuno.
vlr invia a sua volta la coppia [msid , vlr] all’hlr, fin quando la mobile station è attiva. Le seguenti
operazioni vengono fatte quando la mobile station è accesa:
• Se ms cambia la allora ms invia la coppia [msid , lanew ] all’opportuno vlr.
• Se si cambia vlr allora il nuovo vlr invia la coppia [msid , vlrnew ] all’hlr, in questo modo
vi è la rimozione del record [msid , vlrold ] esplicita oppure implicita tramite timeout.
Se la ms viene spenta allora viene inserito il record [msid , N on − Raggiungibile] nel vlrcur .
Per garantire la sicurezza esiste una chiave per accedere all’hlr che corrisponde all’identità del nodo
mobile. Se si identifica ms viene mandata un’identità temporanea, comunicata al vlr. Occorre
quindi evitare che la chiave viaggi sul canale wireless. A tal proposito viene usato uno schema
proattivo per mantenere le informazioni aggiornate.
67
2. locating: determina la locazione attuale “esatta” della mobile station per stabilire una connessione/comunicazione. Questa funzione è reattiva, ovvero si attiva se qualcuno vuole parlare con il
nodo mobile.
Nel momento in cui si vuole stabilire una comunicazione si deve capire univocamente qual’è la cella
in cui si trova la mobile station.
msc-s interroga l’hlr per ottenere, dato msc-did il record [ms-did , vlr-d]. L’hrl interroga a sua
volta vlr-d per reperire [ms-did , la-d]. Se viene trovato ms-d allora ritorna cellid altrimenti il
terminale non è raggiungibile.
In altre parole, attraverso il numero di telefono viene contattato l’hlr da cui ricavo il vlr che ha
la giurisdizione della mobile station di interesse. msc connesso al vlr cerca la location area del
nodo. Se il nodo è acceso risponde e viene restituita la risposta al nodo chiamante. Notiamo che
la comunicazione della ir/raggiungibilità del nodo dipende se questo è stato spento (msc sa che è
spento ed evita la ricerca) oppure no. Nel secondo caso infatti viene effettuata la ricerca e richiede
del tempo fino al termine del timeout. Il caso limite è quando abbiamo una la con una sola cella,
in questo caso non viene fatto il locating.
I parametri che influenzano le prestazioni di questi due algoritmi sono:
Parametri
prestazione
di
1. dimensione della location area.
2. tipo della location area: come vengono ripartite le celle, ovvero sono definite dal sistema (statica)
oppure definite dalle mobile station (dinamica).
Mentre gli indici di prestazione (costo) sono:
Indici di prestazione
1. Traffico generato: se la cresce la frequenza di transizioni decresce, di conseguenza descresce il
traffico sui livelli più alti.
2. Consumo di energia per mobile station: se la aumenta allora diminuisce il consumo energetico, di
conseguenza diminuisce il numero di messaggi da inviare per gli aggiornamenti.
3. Ritardo di localizzazione: se la decresce allora il ritardo di localizzazione decresce.
Nella realtà la ripartizione di la è statica. Esistono però degli studi concettuali che suggeriscono schemi
dinamici. La ripartizione statica è definita dal sistema. Questa prevede la suddivisione statica delle celle
in porzioni contigue. Il rischio è quello di un eccessivo traffico di tracking per le mobile station che si
muovono vicino ai bordi. Ho insomma potenzialmente molto traffico sul confine.
68
Per quanto riguarda la ripartizione dinamica l’idea è che ad ogni nodo è associata una propria la che
gli viene costruita intorno e viene registrata nel sistema finché il nodo non si sposta. Nel caso in cui
il nodo esca dalla sua la dinamica viene ricostruita una nuova area. Questo approccio però può dare
dei problemi, cioé può esserci un potenziale ritardo nella localizzazione. Per risolvere questo problema
è possibile aggiornare la man mano che la mobile station si avvicina ai bordi. Studi tecnici definiscono
che questo schema in media genera un traffico minore. In generale:
• Ogni ms ha la sua la che si modifica dinamicamente in relazione agli spostamenti della ms.
• la è centrata intorno alla cella in cui la mobile station notifica la sua posizione.
• Tempi di aggiornamento si possono basare su:
– tempo: ogni t secondi;
– spostamento: ogni m cambi di cella;
– distanza: quando la cella attuale è a distanza d dalla cella da cui è stata fatta l’ultima notifica.
4.5.4
GPRS Architettura del protocollo di comunicazione
Abbiamo visto in precedenza come la rete cellulare gsm è circuit switching. La prima evoluzione del
gsm è il gprs e poi a seguire l’umts che fornisce una maggiore efficienza di trasmissione dei dati con
un’architettura sostanzialmente identica.
In gprs la gestione della localizzazione non si discosta molto da un database gerarchico. Rispetto al
gsm cambiano le sigle e la tipologia di traffico. Ovvero non si hanno più dei circuiti (dei canali dedicati),
ma sostanzialmente la concezione è identica. gprs possiede una gerarchia a due livelli (ggsn-sgsn).
sgsn comunica con la ra (routing area). Il passaggio da una ra all’altra di un ms è un’informazione
propagata al ggsn. La filosofia è quindi simile a quella gsm.
69
Per quanto riguarda la comunicazione tra gsn (ggsn e/o sgsn) possiamo dire che viene utilizzato il
protocollo gtp. Questo inoltra i pacchetti dati aggiungendo opportune informazioni di routing tramite
il backbone gprs (tunneling). gtp sfrutta tcp/udp+ip per la comunicazione sul backbone.
La comunicazione sgsn-ms utilizza sndcp, ovvero viene fatto un mapping delle caratteristiche del
protocollo di rete sottostante a livello datalink.
La rete protocollare di Internet è invisibile. Infatti il cammino sottostante è realizzato dal tunnel. L’interazione tra ms e bbs occupa la comunicazione wireless. sgsn usa o tcp o udp in base al protocollo
di routing usato a livello end-to-end. ipx25 assume che i pacchetti che arrivano siano disponibili (comunicazione affidabile). L’indirizzo ip per il tunnel è privato al ggsn che si occuperà di togliere l’header
aggiuntivo.
Nella precedente figura è rappresentato lo stack dei protocolli utilizzati in gprs. Tra i più importanti
troviamo: gtp (gprs tunnelling protocol), sndcp (subnetwork dependent convergence protocol), bssgp
(bss gprs protocol) e rlc (radio link protocol).
La tecnica usata per la richiesta di accesso ad una rete gprs è basata su un protocollo a contesa di tipo
slotted aloha.
Il modo di interazione tra le entità ggsn e sgsn è basata sul protocollo ip. Infatti vengono creati dei
tunnel come nel mobileip. Ma a differenza di mobileip che è distribuito, il gprs ha una risoluzione di tipo
centralizzata. Inoltre nei sistemi 3G i due sistemi voce e dati saranno integrati, ovvero tutto è basato su
packet switching.
Consideriamo il seguente scenario. I nodi mobili sono visti come dei client. In generale nella linea
telefonica ms non è identificato dall’indirizzo ip ma dal numero di telefono. Il primo ggsn dal numero
di telefono è in grado di risalire ai componenti da contattare. Infatti dal numero di telefono si conosce
il sgsn-d. Fisicamente lo stesso nodo svolge le funzioni di msc ed sgsn. La tendenza evolutiva è quella
di trattare tutto come gprs.
Come si vede nella precedente figura il routing del gprs è basato su incapsulamento e tunnelling:
1. sgsn-s incapsula il pacchetto da ms-s e lo invia al ggsn appropriato (ggsn-s).
2. ggsn-s esamina l’indirizzo ed invia il pacchetto al ggsn appropriato (ggsn-d) attraverso una rete
dati.
70
Relazione con
la rete Internet
gprs vs gsm &
mobileip
Routing
3. ggsn-d controlla la destinazione e determina l’sgsn appropriato (sgsn-d).
4. sgsn-d riceve il pacchetto e lo invia alla ms-d.
4.6
TCP in reti mobili
Abbiamo un problema nell’utilizzo del protocollo tcp, infatti fa deduzioni sbagliate in reti wireless mobili.
Infatti su una rete mobile i problemi nascono da un problema implicito di inefficienza. La comunicazione
attraverso tcp rimane comunque affidabile ma vi è una degradazione notevole delle prestazioni.
Tipicamente il protocollo tcp in reti fisse crea un canale di trasporto affidabile tra client e server.
Questo protocollo è stream oriented e non transaction oriented. È “network friendly”, ovvero gestisce
la congestione e lo slowdown. Prima di avviare una sessione si ha una fase di setup. In una rete fissa il
tempo di setup risulta trascurabile. Nel mondo mobile un simile ritardo può creare notevoli problemi,
infatti in gprs la sola fase di setup può durare anche un secondo. Quindi tcp regola il traffico in
Internet e garantisce un uso equo delle risorse basandosi sul monitoraggio dello stato della connessione
controllando la perdita di pacchetti.
Le caratteristiche del tcp sono:
Caratteristiche
del tcp
• progettato tipicamente per: sistemi finali fissi e reti fisse di tipo wired.
• attività di ricerca: prestazioni, controllo di congestione e ritrasmissione efficiente.
• controllo della congestione:
– perdita dei pacchetti in reti fisse tipicamente dovuta a situazioni (temporanee) di sovraccarico.
– i router devono scartare i pacchetti se i buffer diventano sovraccarichi.
– tcp riconosce situazioni di congestione indirettamente tramite ack mancanti.
– usa l’algoritmo di slow start come reazione.
Tramite l’algoritmo di slow start si cerca di prevenire la congestione del tcp e funziona nel seguente
modo:
Slow Start
1. il mittente calcola una congestion window (cw) per un destinatario;
2. inizia con una cw di dimensione 1;
3. incrementa esponenzialmente il cw fino a raggiungere un valore di congestion treshold (ct). Da
lı̀ in poi si ha una decrescita lineare.
4. ack mancanti causano la riduzione della ct a metà della cw attuale.
5. cw riparte da 1.
Il meccanismo di tcp chiamato fast retrasmit/fast recovery migliora il rilevamento della perdita di un
pacchetto. La perdita di un pacchetto può essere infatti rilevata tramite:
• scadenza del timeout di ricezione dell’ack;
71
Fast Retrasmit
/ Fast Recovery
• ack duplicati: due ack distinti ma uguali. Ovvero viene riconosciuto il numero di pacchetto come
lo stesso. Ad esempio supponiamo che si sta inviando una sequenza di pacchetti 100, 101, e 102.
100 arriva ed il mittente riceve l’ack con il numero del pacchetto successivo che si aspetta (101).
Il pacchetto 101 si perde. Il destinatario riceve 102 ma manda ancora l’ack con il numero del
pacchetto che si aspetta 101. Quindi il mittente vede arrivare due ack con lo stesso numero.
In generale abbiamo visto come un pacchetto perso viene tradotto come qualcosa di serio. L’ack duplicato indica la presenza di un problema temporaneo, una congestione comunque superata dal momento
che il pacchetto successivo è arrivato. L’uso degli ack duplicati permette la discriminazione tra problemi
persistenti e problemi transitori. Se il problema è transitorio allora si usa un approccio più rapido (fast
retrasmit, fast recovery). L’algoritmo di questo meccanismo è il seguente:
1. tcp invia un ack solo dopo la ricezione di un pacchetto.
2. se un mittente riceve ack duplicati (dupack) per lo stesso pacchetto allora tcp nota che è presente
un “buco” nei pacchetti ricevuti dal destinatario.
3. la ricezione di dupack indica che, comunque, tutti i pacchetti prima del buco sono stati ricevuti
ed anche i pacchetti successivi.
4. la perdita non è dovuta ad una congestione e si può dunque continuare con il cw attuale, ovvero
non si usa lo slow start.
4.6.1
Problemi TCP in ambiente mobile
Abbiamo visto come il tcp assume la presenza di congestione nel caso di pacchetti mancanti. Questo è
tipicamente sbagliato in reti wireless/mobili dove spesso i pacchetti vengono persi per:
• alto tasso di errori di trasmissione del collegamento wireless;
• elevata probabilità di disconnessioni causate dalla mobilità, come l’handoff, zone non coperte, picchi
di traffico per sovraffollamento.
Le prestazioni di tcp non modificato degradano considerevolmente in uno scenario di questo tipo. L’attivazione dei meccanismi di controllo sulla congestione causano un decremento del throughput, un aumento
del ritardo e le perdite multiple causano la creazione di burst. Il problema nasce dal fatto che tcp non
può essere modificato radicalmente, la base installata su rete fissa è troppo grande, ed il tcp deve rimanere compatibile nell’ambiente mobile. Si nota quindi come nel nodo mobile cadono le assunzioni di
base del tcp.
Le contromisure adottate sono:
1. uso di un protocollo diverso: come era stato pensato inizialmente nel caso di wap. Abbiamo visto
però come una simile soluzione non è praticabile dal momento che tcp è ovunque e si rischierebbe
di relegare ad una nicchia la nuova tecnologia.
2. Adattamento del tcp al nuovo contesto: questo segue due filosofie:
(a) trasparente al mittente: si nasconde al mittente la perdita dovuta a congestioni. In questo
modo non sono richieste modifiche sul mittente. Un link con alti tassi di perdita appare come
un collegamento di alta qualità ma con bassa banda. In questo modo la maggior parte delle
perdite viste dal mittente vengono attribuite alla congestione.
Ad esempio: airmail, i-tcp, tcp snooping.
Il mittente ha l’impressione di lavorare con un destinatario con basso tasso di trasmissione.
(b) non trasparenti al mittente: si avverte il mittente di perdite dovute alla congestione, ovvero il
mittente evita di attivare meccanismi del controllo sulla congestione quando vengono rilevate
delle perdite.
In questo caso è il mittente che si adatta ai comportamenti differenti della rete.
Ad esempio eln.
72
Le soluzioni proposte per questi problemi sono basate su tre filosofie (come si vede nella precedente
figura):
1. Split connection: la connessione è spezzata in due parti. Si immagina che ci sia un’entità intermedia. Nel primo tratto wired viene usato il tcp standard, nel secondo tratto wireless abbiamo un
protocollo di rete ad-hoc. In altre parole la connessione tcp termina al punto di accesso fisso /
mobile. Nasconde al mittente il collegamento wireless. Quindi il mittente non è consapevole delle
perdite non dovute alla congestione. La connessione è separata ed affidabile tra il punto di accesso
ed il nodo mobile.
La connessione wireless è realizzata tramite: tcp avanzato (con ack negativi o selettivi) o srp su
udp. Gli studi sull’impatto non mostrano alcuna differenza tra l’uso srp o tcp. In questo modo si
isola il tcp normale dai problemi wireless, ma si viene a perdere la semantica end-to-end propria
del protocollo tcp. Se il mittente riceve l’ack non è detto che il destinatario abbia ricevuto il
pacchetto al momento che l’ack arriva all’intermediario:
(a) il timeout del mittente tcp sul link wireless spesso può scadere bloccando il mittente originario.
(b) Overhead: i pacchetti attraversano due volte il protocollo tcp nel punto di accesso fisso /
mobile.
(c) Handoff complicato e lento per le necessità di mantenere sul punto di accesso l’informazione
di stato per ogni connessione.
(d) La semantica end-to-end è violata, ovvero gli ack dal punto di accesso possono raggiungere
il mittente (fn) anche prima che i pacchetti raggiungano mn.
(e) Non si possono usare i meccanismi di sicurezza del tcp.
2. End-to-End : Risolve il problema di Split connection della perdita della semantica propria del
protocollo tcp, ovvero la connessione rimane unica.
Prevede due modi per gestire le perdite:
• Uso appropriato del fast retrasmission.
73
• Uso di sack (selective acknowledge) per consentire al mittente di reagire a perdite multiple
in una cw senza attendere la scadenza di un grande timeout.
I sack permettono di specificare quali pacchetti sono andati persi.
• Il mittente è avvertito di perdite non causate da congestione tramite meccanismi eln.
3. Link Layer : Viene realizzata una semantica end-to-end. Nella sezione critica si fanno intervenire meccanismi aggiuntivi a livello datalink per rimediare al “volo”. Se mi accorgo di problemi
ritrasmetto. Mi baso sempre sul fatto che Lwired > Lwireless .
Questo meccanismo si colloca tra le due classi viste in precedenza. Nasconde a tcp le perdite
causate dal link wireless tramite:
• ritrasmissioni locali in risposta ai messaggi arq/cdma/tdma.
• forward error connection (fec).
I protocolli ll operano indipendentemente dai protocolli di livello più alto. Non si deve mantenere
un’informazione di stato per ogni connessione. Vi sono però le seguenti problematiche:
(a) effetti negativi su tcp:
• ritrasmissioni concorrenti in ll e tcp interagiscono e riducono il throughput.
• tcp dupack causano fast retrasmit anche per pacchetti ritrasmessi localmente da ll.
• inoltro non in ordine a causa di fast retrasmit di tcp non necessario.
(b) necessità di protocolli ll.
4.6.2
Indirect TCP (I-TCP)
Usa la modalità split connection. I nodi sulla parte fissa della rete non notano le caratteristiche della parte
wireless. Per connessioni wired si usa il protocollo tcp standard. Mentre per connessioni wireless si usa
un protocollo tcp ottimizzato per nodi mobili. L’ottimizzazione si basa sulla mappatura tcp su mobileip.
I fa svolgono non solo il ruolo di fa ma anche di gestori tra le due parti di connessione. Questo elemento
ha il compito di raccogliere i pacchetti nel buffer e reinstradarli al nodo mobile. Quindi se il nodo mobile
si sposta e la comunicazione passa per un nodo differente, fa1 , deve spedire i pacchetti immagazzinati a
fa2 altrimenti andrebbero persi. Devo pertanto spostare il socket ed il buffer. L’overhead che ne deriva
non è banale. I vantaggi di questo approccio consistono in:
1. nessun cambio sulla rete fissa, nessun cambio dei nodi, tutte le ottimizzazioni attualmente usate
da tcp continuano a lavorare.
2. gli errori di trasmissione tra link wireless non si propagano nella rete fissa.
3. semplice da controllare, ovvero il tcp mobile viene usato su un solo segmento di rete (one hop) (ad
esempio tra fa e mn).
4. è possibile utilizzare il fast retrasmit, se il ritardo (breve) sul segmento wireless è noto.
Tuttavia possiede i seguenti svantaggi:
1. perdita della semantica end-to-end;
2. maggiore latenza dovuta al buffering dei dati su fa ed inoltro al nuovo fa.
74
4.6.3
Snooping TCP
Utilizza la modalità Link-Layer. Estensione trasparente di tcp all’interno di fa. La comunicazione
rimane comunque end-to-end, ma vengono aggiunti dei meccanismi per evitare l’uso a sproposito dei
meccanismi di gestione della congestione tcp, ovvero è mappato su mobileip. fa cerca di vedere che
tipo di traffico passa (in ambo i sensi). Nel caso in cui rilevi degli ack duplicati ed il mittente non sia in
grado di fare il fast retrasmit, fa può filtrare il dupack buttandolo e riviandogli i pacchetti mancanti.
Deve quindi mantenere un buffer come nel caso i-tcp con la differenza che non deve mandare o ricevere
degli ack ma mantiene le informazioni per una maggiore sicurezza. In questo contesto la transizione del
nodo da fa1 a fa2 non prevede la ritrasmissione del buffer, pertanto aumenta l’efficienza.
Le caratteristiche di questa estensione del tcp sono le seguenti:
1. buffering dei pacchetti inviati a mn;
2. ritrasmissione locale: i pacchetti che sono persi sul collegamento wireless (in ambo le direzioni)
vengono ritrasmessi da mn o fa.
3. snoop: fa sbircia nel flusso di pacchetti e riconosce gli ack che è eventualmente in grado di filtrare.
4. il tcp cambia solo all’interno di fa.
Per trasferire i dati verso il nodo mobile, fa conserva in un buffer i dati finché non riceve un ack da mn;
inoltre fa rileva la perdita di pacchetti tramite dupack o scadenza del timeout. In questo modo c’è la
possibilità di ritrasmettere rapidamente in maniera trasparente sulla rete fissa. Invece per il trasferimento
dei dati dal nodo mobile, fa rileva la perdita di pacchetti sul collegamento wireless tramite i numeri di
sequenza e lo comunica direttamente a mn tramite nack. A questo punto mn può ritrasmettere i dati
con un ritardo molto piccolo. Per quanto riguarda il livello mac bisgna aggiungere meccanismi simili
a quelli di tcp, inoltre bisogna ricordare che a questo livello già si è in grado di rilevare i pacchetti
duplicati per ritrasmissione e scartarli. i-tcp necessita sia del vecchio fa che di quello nuovo, mentre in
questo caso fa non fà nulla di “necessario” se non migliorare le prestazioni. Quindi non si impone un
uso massiccio della varianza. Inoltre usando questa tecnica si:
• preserva la semantica end-to-end, ovvero un crash di fa non ha alcun effetto sulla rete.
• le modifiche sono concentrate su fa, quindi non è richiesta nessuna modifica per cn.
• Non abbiamo la trasmissione di dati tra fa ( risulta come un timeout sul client).
• fa può anche non usare il protocollo di snoop.
75
Tuttavia presenta anche degli svantaggi quando ci sono meccanismi di crittografia. Infatti fa non è in
grado di decodificare i pacchetti, pertanto lo snooping tcp funziona solo nella comunicazione in chiaro:
• snoop tcp non isola il link wireless quanto i-tcp, se fa deve ritardare l’invio dei dati sul canale
wireless verso mn allora il timeout di cn potrebbe scadere.
• la presenza di un nack tra fa ed mn assume che mn sia in grado di gestirli.
• la crittografia come abbiamo già detto non permette la decodifica dei pacchetti.
4.6.4
MobileTCP
Usa la modalità split connection. La collocazione è in realtà incerta in quanto garantisce l’end-to-end.
Bisogna quindi introdurre un’entità intermedia. Tuttavia questo approccio non ha uno status in mobileip,
ma si focalizza su una particolare categoria di problemi. Infatti i pacchetti possono essere persi su un
canale disturbato (alto ber) oppure su un canale non disponibile. Questo approccio offre una speciale
gestione delle connessioni lunghe e/o frequenti. Usa anche la suddivisione della connessione come in
i-tcp:
• rete fissa: tcp non modificato fino ad un supervisory host (sh).
• rete wireless: tcp ottimizzato da sh a mn. Non viene usato lo slow start. Si ha quindi la necessità
di avere un bandwidth manager per l’uso equo della banda. Infatti sh:
– controlla più ap, gestisce routing e connessioni verso mn.
– non effettua caching e ritrasmissione (se un pacchetto viene perso sul canale wireless deve
essere ritrasmesso dal mittente originario, garantendo cosı̀ la semantica end-to-end).
– controlla tutti i pacchetti e se rileva disconnessioni:
∗ pone a 0 la cw del mittente;
∗ il mittente va in persistent mode;
∗ il vecchio o il nuovo sh riapre la finestra quando avviene la riconnessione.
L’idea alla base consiste nella sua attivazione quando l’entità intermedia scopre una disconnessione in
atto, non rilevando più ack da mn. In questo caso azzera la cw del mittente che viene pertanto congelato.
Cosı̀ facendo non scatta lo slow start. Quando si riapre la connessione, la comunicazione viene ripristinata
con il mittente che riprenderà da dove interrotto.
Questo è quindi un meccanismo valido nel caso di disconnessioni abbastanza lunghe. Ma se abbiamo un
alto tasso di perdita di pacchetti non è conveniente. Ciò porta ai seguenti vantaggi:
1. conserva la semantica end-to-end (sh non invia ack di sua iniziativa, ma inoltra solo quelli
provenienti da mn).
2. nel caso di disconnessione evita le ritrasmissioni inutili, slow start ed perdita della connessione.
3. non ha bisogno di un buffer di dati poiché nel passaggio tra shold ed shnew i pacchetti persi vengono
ritrasmessi automaticamente dal mittente.
Gli svantaggi invece sono:
1. perdite dovute ad errori che si propagano sul link wireless e di conseguenza sulla rete fissa, infatti,
a differenza di i-tcp, sh non è un proxy;
2. il tcp modificato sulla parte wireless comporta modifiche anche su mn.
76
4.6.5
Fast Retrasmit/Fast Recovery
Funziona in modalità end-to-end. Bisogna considerare che un cambio di fa (handoff) dà spesso luogo
a perdita di pacchetti. Il tcp standard reagisce con lo slow start anche se non c’è congestione. Con
questo approccio quando mn passa da fa1 a fa2 , mn manda ack duplicati. Se il mittente adotta fr
ritrasmette i pacchetti verso fa2 , inoltre il tcp su mn è forzato a continuare a trasmettere con la stessa
cw senza andare in slow start. In questo modo si riesce ad evitare di dover aspettare il timeout. Il
tutto nell’ipotesi che i tempi d trasmissione degli ack duplicati siano inferiori al timeout. Cosı̀ tramite
semplici cambiamenti si dà luogo a miglioramenti significativi. Porta tuttavia uno svantaggio, ovvero un
ulteriore miscelamento tra mobileip e tcp, non fornendo la trasparenza con il client.
4.6.6
Selective Retransmission (SACK)
Lavora in modalità end-to-end. In questo caso non si mascherano le perdite di pacchetti (go-back-n
retransmission), ma le rendiamo visibili. Ovvero vengono indicati i buchi nella sequenza. Quindi se il
mittente sa gestire i sack può spedire solo quello che serve. Ciò garantisce un’ottima efficienza, ma
complica il software lato destinatario oltre ad adottare un buffer più grande.
4.6.7
Transaction Oriented TCP
Questo approccio va un pò fuori dalla politica di adattamento. Infatti presuppone una modifica del
tcp. È nata per rendere più efficienti le interazioni di un certo tipo, in particolare quando lo scambio di
informazioni è breve in relazione alla fase di setup (three-way-handshake per setup e rilascio). In realtà è
un protocollo diverso perché le fasi di setup, trasferimento e rilascio vengono combinate (da 7 pacchetti,
minimo a 3). In altre parole si combina la fase di setup e rilascio con i dati dell’utente. Ciò genera
efficienza ma la modifica al tcp non affronta comunque i problemi intrinsechi alla mobilità.
4.6.8
Confronto tra i diversi approcci
Approccio
Meccanismo
Vantaggi
Svantaggi
i-tcp
spezza una connessione
tcp in due connessioni
“sbircia dati ed ack,
ritrasmissione locale
isolamento del link
wireless, semplice
trasparente per
connessioni end-to-end
possibile integrazione
con mac
conserva la semantica
end-to-end, gestisce
sconnessioni frequenti
e abbastanza lunghe
semplice ed efficace
perdita della semantica
tcp, alta latenza per handoff
problemi con crittografia,
cattivo isolamento del
link wireless
Snooping tcp
m-tcp
Selective
Retransmission
suddivide in due una
connessione tcp,
“soffoca” il mittente
tramite cw
evita slow-start dopo
handoff
congela lo stato di tcp
al momento della
sconnessione, lo
riesuma alla riconnessione
ritrasmette solo dati
mancanti
Transaction
oriented tcp
combina setup/rilascio
con trasmissione dei dati
Fast retransmit/
Fast recovery
Transmission/
time-out freezing
indipendente da
contenuto e crittografia,
funziona anche con
interruzioni molto lunghe
molto efficiente
efficiente per certe
applicazioni
Problemi affrontati sono riassunti nella seguente tabella:
77
cattivo isolamento del
link wireless, overhead
per gestione banda
livelli mescolati,
non trasparente
modifiche necessarie in
tcp, dipende dal livello
mac
software più complesso
al destinatario, necessario
buffer maggiore
richiede cambi in tcp,
non trasparente
Indirect
tcp
High ber
Bursty error
Handoff
Long
disconnections
Frequent
disconnections
Bandwidth
Cell Size
Power scarcity
Serial timeouts
Packet size
variations
End-to-end tcp
semantics
Compatibilty
4.6.9
m-tcp
Snooping
tcp
Fast Retransmit/
Fast Recovery
Selective
Retrasmission
Miglioramenti a TCP per reti cellulari
Bisogna adattare l’attuale versione di tcp in modo tale che si adatti a convivere con bassi tassi di dati
e comunicazioni asimmetriche. Si potrebbero adottare i seguenti suggerimenti:
• grande sending window iniziale;
• grande mtu;
• sack;
• notifica esplicita della congestione;
• nessuna compressione dell’header.
Già in uso su i-mode su foma e wap2.0. Notiamo che la larghezza di banda massima è calcolata secondo
la seguente formula:
0.93mss
bw ≤
√
rtt p
dove mss indica la dimensione massima del segemento, mentre p indica la probabilità di perdita.
Si potrebbe introdurre pep che sta per performance enhancing proxies. pep è un’entità intermedia che
gestisce al meglio le due parti (fissa e mobile) del canale. In esso confluiscono più idee su quelle viste.
Inoltre bisogna considerare una notevole contraddizione tra i vari documenti ietf che trattano questa
entità. Le sue caratteristiche sono le seguenti:
1. transport layer: ritrasmissione locale ed ack.
2. livello applicativo: content filtering, compression, picture downscaling, Internet/wap gateway.
Gli svantaggi di pep sono quelli di non garantire la modalità end-to-end e non garantisce la sicurezza.
78
pep