Stato dell’arte
1.1. Concetti di Power Saving
Un terminale mobile di tipo laptop o hand-held, vista la quantità limitata di energia fornita dalla batteria, deve prevedere nell’ambito delle normali esecuzioni una serie di attività aggiuntive volte ad economizzare l’utilizzo delle risorse coin-volte nelle applicazioni correnti. I concetti di utilizzo ottimizzato ed in economia delle risorse vengono riassunti dall’idea di Power Saving. E’ possibile fare Power
Saving per un terminale mobile, a diversi livelli: la procedura solitamente seguita
prevede l’individuazione di un target hardware o software da ottimizzare, lo stu-dio del suo profilo di consumi e l’ideazione di una strategia di risparmio dedicata. Gestire un componente hardware in economia prevede di solito che venga spento completamente oppure messo in uno stato dormiente dopo un periodo più o meno lungo di inattività: è l’approccio seguito per dischi fissi, monitor, unità funzionali di elaborazione (si pensi alle FPU). Ovviamente in questo tipo di gestione la cosa più delicata è la scelta dei tempi di inattività dopo i quali spegnere i componenti hardware: dovrà basarsi su delle stime statistiche dei tempi di accesso e di utilizzo di detti componenti.
Ottimizzare il software in funzione del consumo energetico, invece, prevede di ri-durre la complessità computazionale delle applicazioni (si riduce così l’utilizzo della CPU), di ridurre il numero di accessi ai dischi, di ridurre cioè, laddove pos-sibile, l’impiego delle risorse hardware in generale. Oltre a questo, le applicazioni software devono cercare di utilizzare le risorse hardware in maniera quanto più regolare possibile così da facilitare l’impiego delle strategie di spegnimento dei componenti hardware concepite a basso livello. Di interesse crescente, negli ul-timi tempi, sono i lavori dedicati alla ricerca di strategie di Power Saving per ap-plicazioni di networking.
1.1.1 Power Saving in attività di networking
In materia di networking i consumi sono riconducibili all’utilizzo dell’interfaccia di rete che può operare in stato di ricezione, di trasmissione, op-pure può restare in uno stato di attesa (idle). E’ stato osservato come in uno scena-rio di telefonia cellulare il grosso dei consumi sia riconducibile allo stato di tra-smissione mentre i consumi negli stati di ricezione ed attesa sono del tutto trascu-rabili: in uno scenario del genere le strategie di Power Saving sono orientate alla riduzione del numero di trasmissioni ed alla minimizzazione del tempo comples-sivo di trasmissione. Allo scopo è possibile, ad esempio, concentrare gli invii nei momenti in cui è disponibile una banda molto alta e ritardarli nei momenti di maggiore carico della rete. In uno scenario di Wireless LAN (WLAN) è stato pro-vato invece come il consumo energetico della scheda di rete in stato di trasmis-sione sia decisamente confrontabile con quello in stato di ricezione ed addirittura in stato di attesa. Questo è dovuto fondamentalmente ai meccanismi di base del livello MAC per cui il dispositivo mobile deve ascoltare continuamente il canale per controllare se gli vengono spediti dei dati. In un simile ambito pertanto le stra-tegie di Power Saving devono necessariamente ricorrere allo spegnimento della scheda di rete o all’imposizione di uno stato dormiente (Sleep) della medesima
ogni qual volta non sia strettamente necessaria (stati idle di attesa). Una strategia accurata prevedrà una riorganizzazione completa degli intervalli di funzionamento della scheda (trasmissione, ricezione, attesa) con l’obiettivo di minimizzare sia i tempi di trasmissione sia quelli di ricezione (basta farli coincidere con i periodi di massima disponibilità di banda sulla rete) anche a costo dell’aumento, laddove necessario, dei tempi di attesa (idle) nei quali comunque i consumi crollano grazie allo spegnimento o alla messa in Sleep. Una simile riorganizzazione è possibile solo quando si riesce a tenerla nascosta all’utente finale dell’applicazione di ne-tworking: non è infatti pensabile perseguire gli obiettivi di Power Saving a scapito della diminuzione delle garanzie sulla qualità del servizio (QoS) reso all’utente finale. Una buona strategia di Power Saving deve pertanto essere trasparente e provocare al più lievi rallentamenti nell’esecuzione delle attività che supporta.
Per implementare queste strategie è possibile agire a diversi livelli. A li-vello fisico è possibile operare un monitoraggio del canale di comunicazione per valutarne il livello di rumore e di conseguenza la probabilità di successo o insuc-cesso di una trasmissione (ogni insucinsuc-cesso rende necessaria una o più ritrasmis-sioni ed allunga quindi il tempo complessivo di trasmissione) onde consentire o rimandare una comunicazione. A livello di Sistema Operativo è possibile, ad e-sempio, inserire delle considerazioni sulla banda disponibile per le comunicazioni in rete nelle politiche di scheduling del processore ed assegnare così massima priorità alle applicazioni di networking quando la banda è alta, minima quando la banda disponibile è bassa. A livello trasporto e middleware (fra livello trasporto ed applicativo) è possibile operare in funzione di un particolare tipo di applicazio-ne che esegua a livello soprastante (soluzioni application dependent) e del quale si conosca l’esatto comportamento nei confronti delle comunicazioni oppure è pos-sibile fare delle considerazioni del tutto generali sul profilo di traffico senza rife-rimento alcuno al particolare tipo di applicazione che lo generi (application
inde-pendent). A livello applicativo infine, è possibile sfruttare la conoscenza esatta del
profilo di traffico generato, ricorrere alla compressione dei dati prima della loro trasmissione onde limitarne i tempi, etc.: queste soluzioni garantiscono certamente
i risultati migliori ma mancano di flessibilità prevedendo che ciascuna applicazio-ne abbia un piano di Power Saving concepito appositamente per essa il che risulta decisamente scomodo.
1.1.2 Quadro dei consumi in ambiente mobile
Un’attività di networking che coinvolge sia host fissi sia host mobili è sog-getta a delle problematiche introdotte dalla presenza di canali fisici wireless di cui bisogna tener conto nella ideazione di una strategia di Power Saving. La mobilità viene gestita a livelli bassi nella pila protocollare: a livello data-link in base allo standard IEEE 802.11, a livello network secondo le direttive del Mobile IP, ed è completamente trasparente a livello trasporto. Su di una rete wireless pertanto, dal punto di vista della mobilità, il livello trasporto è paragonabile a quello di una rete wired e viene gestito tipicamente alla stessa stregua con l’impiego di TCP. Tutta-via una simile gestione è soggetta a delle inefficienze dovute al controllo di con-gestione attuato da TCP. Tali malfunzionamenti risultano evidenti se si considera, ad esempio, il caso di uno host mobile che voglia accedere ad un qualche servizio reso da un server collegato alla rete Internet fissa. In questo caso, la connessione fra host mobile ed host fisso si appoggia in parte su dei link fissi ed in parte su dei link wireless. L’insieme dei link wireless è soggetto, per caratteristiche fisiche, a notevoli perdite di pacchetti, e TCP interpreta queste perdite come effetto di una congestione in atto: rallenta le trasmissioni lungo l’intera connessione allungan-done la durata complessiva, prolunga l’attività della scheda di rete ed aumenta fi-nalmente il consumo energetico. Altra causa di rallentamento delle trasmissioni fra mobile host ed host fisso è l’effettiva presenza di congestione sulla parte wired della connessione. Essa, come la perdita di pacchetti sui link wireless, causa un rallentamento della velocità di trasmissione sull’intera connessione rendendola notevolmente inferiore alle potenzialità dei link wireless che pertanto non possono
essere sfruttate a pieno e questo, per quanto detto, è imputabile all’adozione di TCP a livello trasporto.
Per affrontare questi problemi è stata adottata un’architettura nota in lette-ratura col nome di TCP-Indiretto. Essa prevede che la connessione fra un mobile host ed uno host remoto venga splittata in due parti: una fra il mobile host ed una entità chiamata Access Point che si trovi ai bordi della WLAN, l’altra fra Access Point ed host fisso. All’Access Point è demandato il compito di garantire la conti-nuità tra le due connessioni, trasferendo i dati che arrivano dall’una sull’altra. Lo splitting è efficace perché riesce a disaccoppiare le componenti wireless da quelle wired dell’unica connessione precedente. Eventuali congestioni presenti sulla trat-ta fissa non vanno ad influenzare le trasmissioni sulla connessione wireless poiché vengono risolte fra Access Point ed host fisso: la trasmissione verso il terminale mobile ha luogo soltanto quando i dati sono effettivamente presenti presso l’Access Point e pertanto avviene alla velocità massima consentita dal canale wi-reless. Risultati soddisfacenti sono inoltre stati ottenuti sostituendo completa-mente TCP con protocolli di trasporto molto più leggeri ottenendo il duplice van-taggio di sollevare il mobile host dall’onere computazionale di un protocollo pe-sante quale TCP da una parte, e di eliminare definitivamente i problemi legati al controllo di congestione di TCP.
1.1.3 Lavori precedenti
Il TCP-Indiretto consente dunque di velocizzare le trasmissioni, tuttavia, come accennato in precedenza è necessario, soprattutto in scenari in cui siano pre-senti delle WLAN, arricchirlo con politiche di spegnimento della scheda di rete del mobile host. Queste strategie vengono solitamente inserite a livello trasporto in maniera da garantire trasparenza verso il livello applicativo, che non necessita di alcuna modifica, e verso il livello fisico sottostante conservando così l’indipendenza dalla particolare tecnologia dell’interfaccia di rete utilizzata.
La scelta dei tempi di inattività dopo cui spegnere o mettere in uno stato dormiente la scheda di rete, come pure della durata degli intervalli di spegnimento determina certamente il successo di una soluzione Power Saving rispetto ad un’altra. In [1, 2] viene seguito un approccio di tipo application dependent e viene proposta una soluzione Power Saving dedicata al Web browsing. Viene utilizzato il modello di TCP-Indiretto ed introdotto, nella connessione tra mobile host ed Access Point un protocollo di trasporto esemplificato (STP - Simplified Transport
Protocol) al posto di TCP. L’Access Point funziona da Proxy facendo prefetching
dei dati ed inoltre si preoccupa di stimare i tempi di arrivo dei pacchetti futuri e di inviare queste stime al mobile host che valuta l’opportunità di spegnere o meno la scheda di rete. Le stime sono calcolate tenendo conto della banda disponibile sulla connessione con il fixed host, opportunamente monitorata, con l’ausilio di modelli statistici del traffico Web. In [3] viene seguito un approccio di tipo application
in-dependent e viene prodotta una soluzione Power Saving generale, utilizzabile da
diverse applicazioni che gestiscono traffici di dati di natura differente. Viene ri-proposto il modello di TCP-Indiretto e riutilizzato il protocollo STP tra mobile host ed Access Point. L’Access Point conserva la storia recente dei trasferimenti e la utilizza per caratterizzare dinamicamente il comportamento del traffico corrente (non altrimenti identificato) e stimare di conseguenza gli intervalli di inattività ed i tempi di spegnimento per la scheda di rete del mobile host. Invia al mobile host i comandi di spegnimento della scheda di rete assieme ai tempi di spegnimento. L’efficacia delle due soluzioni application dependent ed application independent è misurata con l’indice di Power Saving:
classico TCP approccio un con to sperimenta consumo Saving Power soluzione la con to sperimenta consumo ps I _ _ _ _ _ _ _ _ _ _ _ _ _ = .
La soluzione application dependent consente un risparmio dell’80%ca. dei con-sumi riscontrati con un approccio TCP classico, un po’ meno la soluzione
appli-cation independent (70% ca.) che però è più flessibile. I risultati sperimentali
di-mostrano inoltre che l’introduzione delle strategie di Power Saving non incide ne-gativamente sulla qualità del servizio avvertita dall’utente: essa viene misurata in
termini di URT (User Response Time) che è il tempo che intercorre dal momento in cui l’utente invia una richiesta di dati, al momento in cui li riceve integral-mente. Lo URT aumenta, rispetto ad un approccio classico TCP, meno di 2sec. con la soluzione application dependent e meno di 2.5 sec. con la soluzione
appli-cation independent. L’indice usato per la misura della QoS (Quality of Service) è
l’indice di page delay:
+ =URT con architettura Power Saving pd I_ _ _ _ _ . _ _ _
_con architettura TCP classica URT
