Progetto di sistema

Progetto di sistema

4.1 Architettura di rete

4.1.1 Problematiche e linee guida per la loro risoluzione

L’esigenza di rispettare dei vincoli Real-Time durante la trasmissione di informazioni audio-video impone l’utilizzo di un approccio di tipo application

dependent nello studio di una soluzione Power Saving che supporti l’esecuzione

di applicazioni di multimedia networking. Questo lavoro è pensato per applica-zioni che operano lo Streaming di informaapplica-zioni Audio prememorizzate (Stored

Audio Streaming) con riferimento all’audio in formato MP3. Visti i risultati dei

precedenti lavori in materia di Power Saving [1, 2, 3] viene riproposta l’architettura di TCP-Indiretto che coinvolge un Mobile Host, un Access Point ed un Fixed Host. Il Mobile Host è un terminale mobile dotato di scheda di rete wi-reless; il Fixed Host è una macchina fissa dotata di accesso alla rete di tipo clas-sico; l’Access Point è pure una macchina fissa dotata di due interfacce di rete: una di tipo classico per le comunicazioni con il Fixed Host, l’altra di tipo wireless che gli permette di comunicare con il Mobile Host su link wireless. Si ipotizza che il

Mobile Host sia inserito in una WLAN e che l’Access Point si trovi sul limitare della stessa WLAN.

Per consentire un’attività di Streaming è necessario che il Mobile Host o-spiti un Web Browser ed un Media Player e che presso il Fixed Host eseguano un Web Server ed uno Streaming Server: ai fini di questa trattazione però, è suffi-ciente concentrarsi sulle attività dei soli Media Player e Streaming Server. Il col-loquio tra Media Player e Streaming Server avanza secondo le regole del protocol-lo RTSP mentre viene usato RTP per trasferire i frame MP3 veri e propri. Contra-riamente a quanto avviene di solito, RTP è noto sia presso gli end-point Mobile Host e Fixed Host, sia presso il nodo intermedio Access Point che deve distingue-re i pacchetti RTP in arrivo per riservadistingue-re loro una strategia di scheduling appro-priata, differente da quella adoperata per i pacchetti non-RTP. Stesso discorso per RTSP: è noto anch’esso sia a Mobile Host e Fixed Host sia ad Access Point.

Sulla connessione wired fra Fixed Host ed Access Point è necessario spo-sare il rischio di congestione con l’esigenza di ridurre quanto più possibile il ri-tardo end-to-end e rispettare i vincoli Real-Time: si ipotizza pertanto l’utilizzo di UDP assieme al protocollo TFRC (TCP Friendly Rate Control) che ne incrementa l’affidabilità. TFRC (TCP Friendly Rate Control) stabilisce le modalità di tra-smissione (scheduling) in funzione della congestion-avoidance come pure le rego-le per il monitoraggio del canarego-le e la stima di RTT e packet loss. Sulla connessio-ne wireless tra Access Point e Mobile Host si utilizza STP [2] invece di UDP:

Mobile Host Access Point Fixed Host

fig. 4.1: Aspetto delle pile protocollari.

Media Player RTP / RTSP RT PS STP IP WMAC Streaming Server RTP / RTSP TFRC UDP IP MAC RTP / RTSP RT PS STP IP WMAC TFRC UDP MAC

rantisce dei trasferimenti reliable gestendo il riordino dei pacchetti e, in caso di perdite, le ritrasmissioni. La continuità fra le due connessioni wired e wireless è gestita dall’Access Point che smista opportunamente i dati dall’una all’altra.

Durante lo Streaming si prevede che lo Streaming Server presso il Fixed Host invii i dati all’Access Point prima possibile adottando una politica di schedu-ling di tipo Searly [6, 9] che rispetti le esigenze di Smoothing del traffico audio.

All’Access Point vengono aggiunte funzionalità di Proxy, come incoraggiato dai risultati di [8, 9] esposti nel Capitolo 2, allo scopo di gestire lo Smoothing

(Smoo-thing on-line) del traffico verso il Media Player sul Mobile Host. L’Access Point è

più adatto del Server all’uopo perché dispone con maggiore facilità delle informa-zioni sulle risorse ed i vincoli del Media Player. L’Access Point deve anche occu-parsi di supportare la politica di Power Saving. Si deve osservare che gli obiettivi classici dello Smoothing sono in netto contrasto con gli obiettivi di Power Saving. Minimizzare il Peak Rate infatti, riduce la richiesta di banda ma causa un aumento dei tempi complessivi di trasferimento (pur nel rispetto dei limiti al ritardo

end-to-end imposti dall’applicazione) e dunque di utilizzo della scheda di rete. Tuttavia,

il fatto che una WLAN metta a disposizione una grossa banda nominale (fino a 54Mbps) permette di scansare il problema della minimizzazione del Peak Rate e sacrificare la causa dello Smoothing in favore di quella del Power Saving. Si sosti-tuisce pertanto, solo presso l’Access Point, il problema dello Smoothing con il problema del Power Saving, o meglio, gli obiettivi dell’uno, con quelli dell’altro poiché i vincoli restano immutati (vincoli di riproduzione) come pure gli strumen-ti da adottare per perseguirli (polistrumen-tica di scheduling, adozione di un buffer in cui inviare i pacchetti in anticipo rispetto al loro istante di riproduzione, imposizione di un ritardo iniziale prima della riproduzione).

Il compito di integrare gli obiettivi di Power Saving nella gestione delle trasmissioni fra Access Point e Mobile Host pur nel rispetto delle esigenze del traffico Real-Time viene affidato al protocollo RT_PS (Real Time – Power

Sa-ving) che va a collocarsi nell’architettura di rete logicamente sopra STP sia presso

Access Point sia presso Mobile Host.

La fig. 4.1 mostra l’aspetto della pila protocollare presso Mobile Host, Ac-cess Point e Fixed Host sulla base di quanto fin qui esposto.

Il problema del Power Saving viene affrontato con l’ausilio di un modello Single-Link1 i cui nodi sono rappresentati dal Proxy presso l’Access Point e dal Client che gestisce il problema del Power Saving presso il Mobile Host. Si ipotiz-za che tutto il file da inviare al Client sia disponibile presso il Proxy: si studia dunque il caso ottimo rispetto al quale, come dimostrato dai risultati teorici esa-minati, il caso reale in cui il Proxy gestisca uno scheduling on-line differisce solo con un lieve calo di prestazioni. I vincoli della schedulazione concepita dal Proxy sono quelli presentati nel Capitolo 2: verranno ripresi nel seguito.

Per gestire la scheda di rete in maniera opportuna si ricorre lato Proxy, ad uno scheduling On-Off sfruttando la possibilità di spegnere o mandare in Sleep la scheda negli Off-period. Purtroppo, a causa della frequenza sostenuta con cui si alternano in uno scheduling On-Off gli On-period e gli Off-period e del fatto che alternare il funzionamento della scheda di rete da uno stato On ad uno stato Off ha un costo in termini temporali, spesso non c’è convenienza a spegnere la scheda. La scheda di rete infatti, impiega un intervallo temporale D1 per passare dallo stato

On a quello Off ed un intervallo _{D2 »D1} per passare dallo stato Off a quello On. Durante questi intervalli temporali la scheda di rete consuma come se fosse acce-sa: spesso la somma degli intervalli di spegnimento e di riaccensione è superiore o uguale alla durata di uno Off-period per cui non è conveniente spegnere la scheda per poi riaccenderla ed è possibile che la scheda resti accesa durante tutto il trasfe-rimento. Si può combinare una strategia di scheduling On-Off con la messa in Sleep della scheda di rete: i passaggi della scheda di rete dallo stato On a quello

1 _{La trattazione sulla riduzione del modello Tandem al modello Single-Link resta valida poiché non impone}

ipotesi che la presenza del Proxy faccia cadere. Unico vincolo che la trattazione impone è quello della mini-mizzazione della allocazione di memoria lato Client.

Sleep e dallo stato Sleep a quello On sono praticamente istantanei (circa 500ms) ed è sempre possibile mettere in Sleep la scheda di rete durante gli Off-period per quanto piccoli essi siano.

Presso il Mobile Host infine, è necessario introdurre un buffer a disposi-zione del Media Player ed imporre un ritardo iniziale prima dell’avvio della ripro-duzione per assorbire il ritardo end-to-end ed il jitter e contemporaneamente ap-poggiare l’arrivo dei pacchetti schedulati in anticipo secondo quanto impone la politica di Power Saving. L’impiego del buffer ed il ritardo iniziale imposto alla riproduzione devono essere entrambi minimizzati visto il costo della memoria per il terminali mobili, unitamente al fatto che i ritardi prima della riproduzione sono mal tollerati dall’utente se superiori ai 5-10sec., particolarmente per sequenze brevi.

Obiettivo di questo lavoro è stato progettare ed implementare il livello RT_PS su Access Point e Mobile Host. Nel seguito, si trascura il Fixed Host e si considerano soltanto i nodi Access Point e Mobile Host.

Si procede richiamando dapprima i ruoli dei protocolli RTP ed RTSP per il trasferimento di informazioni audio-video e, successivamente, descrivendo il pro-tocollo RT_PS concepito per supportare le funzionalità di Power Saving. I mes-saggi scambiati tra Access Point e Mobile Host nell’ambito del protocollo RT_PS assumono il formato standard del pacchetto RT_PS definito anch’esso nel seguito. Infine, nella parte dedicata allo scheduling, vengono forniti i dettagli sulla gestio-ne degli istanti di messa in Sleep e della durata stessa degli intervalli di Sleep del-la scheda di rete del Mobile Host, interamente a carico dell’Access Point.

4.1.2 Ruoli di RTP ed RTSP

Il protocollo RTP, descritto nel Capitolo 3, prevede che per il trasferimen-to di un file MP3 attraverso Internet i frame del bit-stream vengano riarrangiati al-lo scopo di ottenere una sequenza di ADU frame: ciò garantisce un aumento della

Loss Tolerance durante la trasmissione perché evita la moltiplicazione delle

perdi-te. I pacchetti RTP contengono dunque frame ADU. Il livello RTP previsto presso l’Access Point si occupa di generare i pacchetti RTP a partire dai frame MP3: converte una sequenza di frame MP3 nella corrispondente sequenza di frame ADU, riordina la sequenza ottenuta secondo i dettami dell’interleaving (opziona-le) ed incapsula infine i frame ADU nei pacchetti RTP. Il livello RTP previsto presso il Mobile Host ha compiti duali: ricevuta una sequenza di pacchetti RTP, li ordina in base al Sequence Number riottenendo la sequenza di frame ADU interal-lacciati (eventualmente), disfa l’interallacciamento e riottene la sequenza originale di frame ADU, ripristina infine il meccanismo del bit-reservoir e riottene la se-quenza originale di frame MP3 da passare al Media Player per la riproduzione.

Il protocollo RTSP, anticipato nel Capitolo 2, definisce lo standard per la gestione di una sessione di Streaming tra un Client ed un Server. La sessione è co-stituita dall’insieme dei trasferimenti che hanno luogo tra due entità e che riguar-dano sia i dati (audio in questo caso) sia i comandi. La sessione di Streaming è ge-stita dalle due entità Client RTSP e Server RTSP che risiedono rispettivamente presso il Mobile Host ed l’Access Point. Per avviare il trasferimento di un file au-dio MP3 il Client RTSP deve inviare una RTSP SETUP request al Server RTSP; la sessione è da considerarsi aperta quando il Client riceve la RTSP SETUP re-sponse dal Server RTSP assieme all’identificatore di sessione da ripetere ad ogni invio. Aperta la sessione il Client può inviare i comandi di PLAY, PAUSE, RE-CORD, etc.; in seguito ad ogni richiesta il Server RTSP risponde comunicando un codice che può segnalare il successo o l’insuccesso dell’operazione oppure il veri-ficarsi di una situazione di errore. Ai fini della presente trattazione è sufficiente evidenziare che per richiedere la riproduzione di un brano, una volta aperta una

nuova sessione, il Client RTSP deve inviare una RTSP PLAY request al Server RTSP e questi deve prima rispondere con una RTSP PLAY response, poi avviare la trasmissione dei pacchetti RTP. Ricevuto tutto il brano il Client RTSP invia una RTSP TEARDOWN request al Server che risponde terminando così la sessione.

4.2 Protocollo RT_PS

Compito del protocollo RT_PS (Real Time – Power Saving), come antici-pato sopra, è quello di offrire un supporto all’implementazione delle strategie di Power Saving da adoperarsi durante le trasmissioni in Streaming fra Access Point e Mobile Host. Il protocollo definisce la sequenza di scambi tra Access Point e Mobile Host per la trasmissione dei frame audio e le modalità per impartire i co-mandi di messa in Sleep e di riattivazione della scheda di rete del Mobile Host. Presso il Mobile Host e l’Access Point risiedono rispettivamente il Client RT_PS ed il Server RT_PS (livelli RT_PS delle rispettive pile protocollari): nel seguito il comportamento previsto per loro dal protocollo.

4.2.1 Comportamento del Client RT_PS

Il Client RT_PS deve interagire con i livelli RTSP ed RTP del Mobile Host, da una parte, e con il Server RT_PS dell’Access Point dall’altra. Il Client RT_PS ha il compito di intercettare ogni richiesta di SETUP fatta dal Media Pla-yer attraverso il Client RTSP per il Server RTSP e di generare subito dopo una ri-chiesta RT_PS per l’Access Point: essa contiene il nome del brano da riprodurre e la dimensione del buffer a disposizione presso il Mobile Host. Il Client RT_PS

re-sta poi in attesa di ricevere dall’Access Point i pacchetti RTP di contenuto audio ed i comandi che gli permettono di avviare la riproduzione del brano e di mettere in Sleep la scheda di rete. Il colloquio con il Server RT_PS può essere scomposto in due parti: la prima va dall’istante della richiesta del Media Player all’istante di inizio della riproduzione, la seconda dall’istante di inizio della riproduzione all’istante in cui termina la trasmissione del file MP3. Nella prima parte il Client RT_PS riceve continuamente dal Server i pacchetti RTP audio assieme all’indicazione dell’istante Start Point in cui deve incominciare la riproduzione (comando AUDIO_SP). La ricezione di un comando di DELAY segnala la possi-bilità mettere in Sleep la scheda di rete per un tempo comunicato assieme al co-mando stesso. Al termine del periodo di Sleep il Client riattiva la scheda e lo se-gnala al Server (messaggio CHECK) che può riprendere così la trasmissione. Il comando di DELAY prevede altresì l’aggiornamento dell’istante di inizio della riproduzione che deve essere ritardato il più possibile. La ricezione di un comando di ReSeT prevede che il Client RT_PS termini la sessione ed invii un comando TEARDOWN al Client RTSP. Infine, in alcuni casi particolari, è possibile che il Server RT_PS invii al Client la richiesta di accordare un particolare istante di ini-zio della riproduini-zione (può essere ad esempio troppo lontano e pertanto aver biso-gno di “accordo tra le parti”), comunicato nella richiesta stessa (ASK_DILATION). Il Client RT_PS deve valutare l’opportunità di un simile ri-tardo e rispondere poi accettando la richiesta (OK_DILATION), dopo avere ol-tremodo aggiornato lo Start Point, oppure rifiutando (NO_DILATION) e termi-nando subito dopo la sessione analogamente a quando riceve un comando di ReSeT.

Segue la descrizione del comportamento del Client RT_PS durante la pri-ma parte della sessione fino all’inizio della riproduzione:

On_SETUP_from_Media_Player { send REQuest to Proxy; evaluate Start_Point;

while (!Start_Point elapsed && !PLAY command received) { wait for message;

switch (message_type) {

case ReSeT: { send TEARDOWN to Media_Player; terminate;

}

case AUDIO_SP: { update Start_Point; store audio into buffer; send ACK response;

}

case DELAY: { send ACK_DELAY response; suspend_card(delay_time); update Start_Point;

wait for end of delay_time; raise_card;

send CHECK request; }

case WAKEUP: send AWAKE response;

case ASK_DILATION: { evaluate max_attesa;

if (Start_Point is too far) { send NO_DILATION response; send TEARDOWN to Media_Player;

terminate;

} else {

send OK_DILATION response; update Start_Point;

} } }

}

La seconda parte del colloquio incomincia allo scattare dello Start_Point fissato per l’inizio della riproduzione oppure in seguito alla ricezione da parte del Server RT_PS del comando di PLAY allo scopo di anticipare la riproduzione. Il comportamento del Client RT_PS è analogo a quello condotto nella prima parte tranne che per la gestione dello Start_Point, assente in questa fase. Il Client RT_PS riceve dal Server RT_PS i pacchetti RTP accompagnati dal comando AUDIO. Può ricevere inoltre il comando di SLEEP in seguito al quale mette in Sleep la scheda di rete per un tempo fornito pure dal Server assieme al comando ed infine i comandi di ReSeT e di END in seguito ai quali termina la sessione per-ché si è verificato un errore o un problema che non può essere gestito (ReSeT) oppure perché la trasmissione del file è completata (END).

On_PLAY_received_or_Start_Point_elapsed { send RTSP PLAY response to Media_Player; send START message to Proxy;

while (!END message received) { wait for message

switch (message_type) {

case ReSeT: { send TEARDOWN to Media_Player; terminate;

}

case AUDIO: { store audio into buffer; send ACK response;

}

case SLEEP: { send ASLEEP response; suspend_card(sleep_time); wait for end of sleep_time; raise_card;

send CHECK request; }

case WAKEUP: send AWAKE response; }

}

Qualche dettaglio in più sulla gestione degli intervalli di Sleep: il Client mette in Sleep la scheda di rete, come detto, in seguito alla ricezione dei comandi di DELAY e di SLEEP; provvede inoltre a settare un timer con il valore dell’intervallo di Sleep comunicato dal Server RT_PS e, allo scattare del timer, riattiva la scheda di rete ed invia al Server RT_PS un messaggio di CHECK per comunicare che le trasmissioni possono ricominciare perché la scheda è stata riat-tivata. Il Server RT_PS decide a questo punto, dopo aver stimato il throughput di-sponibile sulla connessione, se continuare a trasmettere o meno: invia un comando di WAKEUP seguito dai pacchetti RTP (messaggi AUDIO o AUDIO_SP) in caso affermativo oppure un nuovo comando di SLEEP o DELAY accompagnato dalla durata del nuovo intervallo di Sleep in caso contrario.

4.2.2 Comportamento del Server RT_PS

Presso l’Access Point risiede il Server RT_PS: esso deve inviare i pacchet-ti RTP al Mobile Host seguendo una appropriata polipacchet-tica di scheduling e valutare gli istanti in cui fare andare in Sleep la scheda di rete del Mobile Host come pure la durata degli intervalli di Sleep. Anche il comportamento del Server RT_PS può essere analizzato in due fasi: prima e dopo l’inizio della riproduzione del brano da parte del Media Player del Mobile Host. La sessione comincia con l’arrivo della richiesta (REQuest) dal Client RT_PS presso il Mobile Host. Il Server RT_PS do-po aver stimato la banda disdo-ponibile sulla connessione e calcolato l’istante di ini-zio della riproduini-zione in funini-zione del valore della banda e di numero e dimensioni dei frame che compongono il brano richiesto, comincia a trasmettere i pacchetti RTP con i frame del brano assieme al valore dello Start_Point. Lo Start_Point viene ricalcolato continuamente in funzione della banda monitorata ad ogni tra-smissione. Prima di trasmettere un nuovo pacchetto RTP audio il Server RT_PS valuta l’opportunità di mandare in Sleep la scheda del Client. Nel caso ce ne sia la possibilità, invia un comando di DELAY accompagnato dalla durata dell’intervallo di Sleep per la scheda e si mette in attesa di una comunicazione da parte del Client (CHECK) quando abbia riattivato la scheda. Ricevuta la comuni-cazione il Server stima nuovamente la banda disponibile sulla connessione e valu-ta nuovamente le condizioni per la messa in Sleep della scheda. Invia quindi al Client un comando di DELAY per mandare di nuovo in Sleep la scheda oppure di WAKEUP per confermare il prosieguo della trasmissione e subito dopo i pacchet-ti RTP incapsulapacchet-ti in messaggi AUDIO_SP. Compito del Server RT_PS in questa fase è pure valutare la necessità di anticipare l’inizio della riproduzione del brano; nel caso, il Server invia un comando di PLAY. La prima fase della sessione ter-mina con la ricezione del messaggio di START dal Client RT_PS a comunicare l’inizio della riproduzione da parte del Media Player. Segue la descrizione tramite pseudocodice per questa prima parte:

on_REQuest_from_Mobile_Host() { evaluate throughput;

evaluate Start_Point;

if (Start_Point is too far) {

send ASK_DILATION(Start_Point) request;

wait for message;

if (message_type == NO_DILATION)

terminate; }

while (!START message received) { evaluate delay_condition

while (delay_condition == true) { evaluate delay_time;

send DELAY(delay_time) command; wait for ACK_DELAY response; wait for CHECK request; evaluate throughput; evaluate delay_condition;

if (delay_condition == false) { send WAKEUP command;

wait for AWAKE response; }

}

evaluate Start_Point;

send AUDIO_SP(Start_Point) message; wait for ACK response;

evaluate start_condition; if (start_condition == true) send PLAY command;

} }

La seconda parte della sessione comincia per il Server RT_PS con la rice-zione del messaggio di START che indica che il Media Player presso il Mobile Host ha cominciato a riprodurre il brano. Il Server RT_PS non deve più aggiorna-re lo Start Point e si limita a gestiaggiorna-re la trasmissione dei pacchetti RTP. Continua però ad aggiornare ad ogni trasmissione il valore del throughput disponibile ed a valutare la possibilità per il Mobile Host di mettere in Sleep la scheda di rete. Quando possibile invia un comando di SLEEP comunicando oltremodo l’intervallo di Sleep per la scheda e resta poi in attesa della comunicazione dal Client RT_PS in seguito alla quale avvia una nuova fase di verifica delle condi-zioni di Sleep ed invia un comando di WAKEUP oppure un nuovo comando di

SLEEP. La sessione termina quando sono stati inviati tutti frame: il Server invia allora un comando di END e si sincronizza con il Client aspettando la sua risposta (QUIT). Segue lo pseudocodice associato:

on_START_received() {

while (!End Of MP3_File) { evaluate sleep_condition

while (sleep_condition == true) { evaluate sleep_time;

send SLEEP(sleep_time) command; wait for ASLEEP response; wait for CHECK request; evaluate throughput; evaluate sleep_condition;

if (sleep_condition == false) { send WAKEUP command;

wait for AWAKE response; }

}

send AUDIO message; wait for ACK response; }

send END message;

wait for QUIT response; }

Sia nella prima parte della sessione sia nella seconda, qualora si verifichi un errore o altra condizione che impedisce il prosieguo della trasmissione, il Server RT_PS invia un comando di ReSeT al Client che ha l’effetto di terminare immediatamente la sessione.

on_error() {

send RST command; }

4.2.3 Formato del pacchetto RT_PS

Il pacchetto RT_PS prevede uno header (intestazione), un body (corpo), un trailer (coda). Lo header è sempre presente e contiene diverse informazioni (si ve-da sotto) tra cui la lunghezza del body e del trailer. Il body è destinato a contenere il pacchetto RTP delle informazioni audio; la sua lunghezza dipende dal particola-re frame trasportato (si ricorda che il pacchetto RTP trasporta frame ADU e non

RT_PS header RTP header ADU descriptor ADU frame RT_PS trailer

fig. 4.2: Struttura di un pacchetto RT_PS.

frame MP3 standard). Il trailer è destinato a contenere delle informazioni di con-trollo che completano, in taluni casi, lo header del pacchetto. Lunghezza e struttu-ra del tstruttu-railer dipendono dal tipo di comando tstruttu-rasportato nel pacchetto RT_PS. Il body ed il trailer possono non essere presenti. Nella fig. 4.2 è riportato il formato del pacchetto RT_PS: RTP header, ADU descriptor ed ADU frame costituiscono insieme il pacchetto RTP.

Lo header del pacchetto RT_PS contiene:

· Tipo: è una parola chiave che differenzia i vari pacchetti RT_PS e permet-te l’avanzamento del protocollo tra Access Point e Mobile Host. Consenpermet-te di distinguere tra pacchetti audio che trasportano i frame ADU e pacchetti di controllo che possono contenere invece un comando, una richiesta, una risposta o che possono attestare uno stato.

· Timestamp: è l’informazione temporale che testimonia l’istante di invio di un pacchetto. Nei pacchetti di acknowledgement (ACK) inviati a conferma della ricezione dei pacchetti audio, il timestamp è la replica di quello del pacchetto audio ricevuto e serve a consentire il calcolo del RTT.

· Lunghezza del pacchetto RTP: se diversa da zero indica che l’intestazione RT_PS è seguita da un pacchetto RTP che trasporta un nuovo frame audio e ne specifica la lunghezza.

· Lunghezza del trailer: se diversa da zero indica la presenza di un trailer in fondo al pacchetto RT_PS (dopo il body se presente, dopo lo header quan-do il body non è presente) e ne specifica la lunghezza.

4.2.4 Elenco dei pacchetti RT_PS previsti

REQ: contiene header e trailer. Nel trailer è indicato il nome del brano di cui il Mobile Host chiede la riproduzione assieme alla dimensione del buffer destinato a ricevere i frame da riprodurre.

AUDIO: prevede intestazione e body; nel body è contenuto un pacchetto RTP.

AUDIO_SP: prevede intestazione, body e trailer. Il body contiene (come il pac-chetto AUDIO) un pacpac-chetto RTP; il trailer invece contiene una informazione temporale che corrisponde all’aggiornamento dello Start Point. A differenza dei pacchetti AUDIO, i pacchetti AUDIO_SP vengono trasferiti quando il Media Pla-yer non ha ancora incominciato a riprodurre il brano e l’istante di inizio della ri-produzione è ancora in fase di definizione.

ACK: prevede il solo header. Viene generato come risposta alla ricezione dei pac-chetti AUDIO ed AUDIO_SP e contiene nel campo timestamp la replica del time-stamp del pacchetto ricevuto e di cui fa acknowledgement.

PLAY: è un pacchetto di comando che comprende solo lo header RT_PS. L’Access Point sollecita così l’inizio della riproduzione perché si sono verificate delle condizioni che ne vogliono l’anticipo rispetto all’istante Start Point calcola-to.

START: il formato prevede il solo header. E’ il pacchetto di risposta al pacchetto PLAY e serve a comunicare che il Media Player ha avviato la riproduzione del brano.

RST: il pacchetto comprende solo lo header; con esso l’Access Point comunica che per qualche motivo la schedulazione non può cominciare o deve essere inter-rotta.

ASK_DILATION: il pacchetto prevede header e trailer. Nel trailer è specificato un tempo: uno Start Point proposto dall’Access Point.

OK_DILATION: prevede il solo header. Viene usato in risposta al pacchetto ASK_DILATION quando lo Start Point proposto da questo viene accettato.

NO_DILATION: prevede solo lo header e viene usato anch’esso in risposta al pacchetto ASK_DILATION ma stavolta per rifiutare la proposta di Start Point dell’Access Point.

SLEEP: il formato del pacchetto prevede uno header ed un trailer. Con questo comando l’Access Point sollecita il Mobile Host a mettere in Sleep la scheda di rete ed a riattivarla dopo un certo tempo specificato nel trailer dello stesso pac-chetto.

ASLEEP: contiene solo lo header e viene usato per comunicare che si sta spe-gnendo la scheda di rete. Di fatto il pacchetto ASLEEP è l’ultimo ad essere invia-to prima di un intervallo di Sleep.

DELAY: il formato prevede header e trailer. Come con il pacchetto di SLEEP, l’Access Point sollecita, con il pacchetto di DELAY, il Mobile Host a mettere in Sleep la scheda di rete ed a riattivarla dopo un certo tempo specificato nel trailer

del pacchetto RT_PS stesso. Il pacchetto di DELAY però, a differenza del pac-chetto di SLEEP, può arrivare quando la riproduzione non è ancora cominciata e l’Access Point chiede di ritardare l’istante di inizio della riproduzione quanto più possibile (l’istante di inizio della riproduzione è da calcolarsi sommando a quello di richiesta del brano da parte del Mobile Host l’attesa massima concordata nella prima fase della schedulazione).

ACK_DELAY: contiene solo lo header ed ha funzioni analoghe al pacchetto A-SLEEP. Viene inviato dopo la ricezione del comando di DELAY prima di mettere in Sleep la scheda di rete.

CHECK: contiene solo lo header. Viene inviato dal Client RT_PS per comunicare la riattivazione della scheda di rete dopo un periodo di Sleep.

RTT_CHECK: il formato prevede soltanto lo header. Viene utilizzato durante la fase di probing per la valutazione del throughput disponibile sulla connessione tra Access Point e Mobile Host. Durante la fase di probing il Server RT_PS invia una sequenza di pacchetti RTT_CHECK e per ciascuno attende di ricevere il pacchetto ACK di risposta per calcolare il valore del RTT.

RTT_STOP: prevede anch’esso solo lo header. Viene inviato per comunicare che la fase di probing è finita e che non vengono più inviati pacchetti di RTT_CHECK.

WAKEUP: il pacchetto contiene solo lo header, con esso l’Access Point comunica al Mobile Host che deve mantenere attiva la scheda di rete perché sta ricomin-ciando a trasmissione.

AWAKE: prevede solo lo header. Viene inviato in risposta ad un pacchetto di WAKEUP come acknowledgement.

END: il pacchetto contiene solo lo header. L’Access Point comunica che la tra-smissione del file è terminata.

QUIT: prevede solo lo header. Viene inviato in risposta ad un pacchetto di END come acknowledgement.

4.3 Scheduling per Power Saving

L’algoritmo di scheduling stabilisce le regole per l’invio dei frame (ADU frame) del file MP3 dall’Access Point al Mobile Host. Prima di passare alla de-scrizione dell’algoritmo però, è necessario affrontare una serie di argomenti pre-liminari per chiarire alcuni aspetti dello scheduling, sottolinearne i problemi e mo-tivare le soluzioni scelte. Si comincia con l’illustrare i motivi dell’adozione di un algoritmo di scheduling di tipo On-Off; si definisce una terminologia per la de-scrizione dei vincoli di scheduling e si affronta il problema della esistenza o meno di uno schedule On-Off che si adatti ad un particolare file MP3. Si prosegue trat-tando i problemi legati alla scelta dell’istante di inizio della riproduzione e della dimensione del Client buffer e si conclude fornendo la descrizione dettagliata dell’algoritmo di scheduling adottato.

4.3.1 Motivazione ed obiettivi dello Scheduling On-Off

Lo schedule più adatto alle esigenze di Power Saving da eseguirsi lato Proxy è di tipo On-Off: il Proxy alterna intervalli di trasmissione (On-Period) ed intervalli di non trasmissione (Off-Period) ed il Client, su terminale mobile, si tro-va a ricevere quando il Proxy trasmette (On-period) e ad aspettare senza far nulla

quando il Proxy non trasmette (Off-period). Il Client gestisce la sua scheda di rete attivandola in fase di ricezione durante gli On-period, e lasciandola dormiente, in

Sleep durante gli Off-period in cui resterebbe comunque idle. I consumi della

scheda sono in termini di potenza: WON durante gli On-period e WSLEEP << WON

durante gli Off-Period. Il consumo complessivo lato Client durante tutta la sche-dulazione risulta pertanto:

E= × + × ,

dove TON è la durata complessiva degli intervalli di trasmissione e TSLEEP quella

degli intervalli di non trasmissione.

Lo scopo principale della schedulazione è di minimizzare il consumo e-nergetico lato Client, pertanto è necessario minimizzare sia TON sia TSLEEP. In

re-altà questi due tempi non possono essere minimizzati contemporaneamente. Il problema della minimizzazione di TSLEEP è equivalente al problema della

mini-mizzazione dell’idle-ratio nella trattazione sullo Smoothing On-Off condotta in [10] (si riferisca sempre al Capitolo 2): comporta la riduzione del rate di trasmis-sione e l’allungamento della durata dei trasferimenti, quindi di TON. Minimizzare TON è più importante che minimizzare TSLEEP: il peso di TON nel calcolo

dell’energia consumata dalla scheda di rete infatti, è maggiore di quello di TSLEEP

(WSLEEP << WON); si sceglie pertanto di trasmettere, durante gli On-Period, al rate

massimo possibile, impegnando tutta la banda disponibile. A differenza dei lavori precedenti sullo Smoothing On-Off, la schedulazione proposta in questo lavoro non è di tipo single-rate e prevede che il rate di trasmissione cambi da On-period ad On-period.

4.3.2 Formalizzazione dei vincoli di Scheduling

L’algoritmo di scheduling seguito dal Proxy nell’inviare i frame al Client deve rispettare i vincoli imposti dalle esigenze di riproduzione da una parte e dalle

n. byte y=M VB

fig. 4.3: Rappresentazione grafica dei vincoli di Scheduling

2 e vengono ora brevemente ripresi: sono solitamente rappresentati come in fig. 4.3. La sequenza audio è composta da N frame; l’i-esimo frame (1£i£ N) oc-cupa fi byte, ed M è la dimensione complessiva, sempre in byte, dell’intera

se-quenza (

å

pla-yout e mostra come i dati vengono consumati dal Client: nell’istante generico t il decoder

MP3 ha già prelevato dal Client buffer V(t)

byte per riprodurli, così

V(t) è la quantità di byte che deve essere giunta almeno al Client entro l’istante t. V(t) è una funzione discontinua ed i punti di discontinuità si hanno in

corrispon-denza degli istanti di prelievo dei frame dal buffer da parte del decoder. L’intervallo , fra un prelievo ed il successivo è costante e la sua lunghezza è de-terminata dal numero di campioni presenti in un frame e dalla frequenza di cam-pionamento che caratterizzano la sequenza. , corrisponde al tempo di esecuzione di un frame (numero di campioni in un frame / frequenza di campionamento) e viene chiamato frame-time. VB(t) si ottiene traslando V(t) verso l’alto di B byte

(pari alla dimensione del Client buffer): nell’istante generico t il Client non può

aver sperimentato l’arrivo nel suo buffer di più di VB(t) byte di cui V(t) già avviati

alla riproduzione e B ancora presenti nel buffer. S(t) è la curva di scheduling e

coincide per ipotesi con la curva degli arrivi: si trascurano infatti in questa tratta-zione i problemi legati al ritardo end-to-end ed al jitter per quanto illustrato nel

Capitolo 2. S(t) deve restare sopra la curva di playout per evitare l’underflow del

Client buffer e sotto la funzione VB_{(t) per evitare l’overflow:}

4.3.3 Condizioni per l’esistenza di uno Schedule On-Off

Gli studi condotti in [10] dimostrano che, a causa dei vincoli di riprodu-zione e della dimensione limitata del Client buffer, non è sempre possibile ese-guire uno Smoothing On-Off per una sequenza audio-video. In particolare la

pos-sibilità di eseguire uno Smoothing On-Off è legata alla disponibilità di una banda

minima R sulla connessione tra Proxy e Client.

Il valore di R dipende dalle dimensioni dei frame della sequenza audio da schedulare e dalla dimensione del Client buffer. Si calcola seguendo un procedi-mento basato sulla costruzione di una funzione definita inviluppo della curva di playout: ER(t): se V(t) è la curva di playout che descrive la sequenza audio e se SR(t) è uno schedule possibile per la medesima sequenza, di tipo single-rate

(ese-guito cioè dall’inizio alla fine con il medesimo rate di trasmissione) a rate R,

al-lora esiste uno schedule On-Off minimo ER(t) tale chet, 0£t£ N×D:

S_R ³ _R .

ER(t) è la curva di inviluppo a rate R (R-envelope) della funzione di playout V(t):

lo schedule di tipo On-Off a rate costante R più prossimo alla curva di playout.

Per una definizione analitica formale della curva di inviluppo si rimanda a [10]; qui è sufficiente definire la successione E_R

[ ]

i-stanti che delimitano i frame-time in corrispondenza dei quali il decoder MP3 pre-leva i frame dal buffer:

[ ]

(

)

_{

_{[ ]}

(

(

)

)

₍

₎

_}

con 0£k <N ed Rk pari al numero di byte trasmissibili in un frame-time a rate R.

E’ possibile schedulare una sequenza audio con uno schedule SR(t) di tipo

On-Off a rate costante R a patto che la sua funzione V(t) ammetta un inviluppo

VB(t) e dai due assi orizzontali y=0 ed y=M. Il rate minimo R per uno schedule

On-Off si definisce dunque come R =min

{

}

Un qualunque schedule SR(t) di tipo On-Off, ammissibile per la sequenza V(t), ha una curva più discosta rispetto ad ER(t) dalla curva di playout; questo

cau-sa un maggior fabbisogno di memoria nel buffer del Client. La dimensione mini-ma del buffer del Client per uno schedale On-Off a rate R è infatti dato dalla rela-zione:

( ) ( )

{

}

4.3.4 Calcolo dell’istante di inizio della riproduzione

Nello scenario di partenza il Client chiede al Proxy di riprodurre un file audio MP3; il Proxy deve cercare il file nel suo file system e valutare la possibilità di trasmetterlo al Client secondo uno schedule On-Off per venire incontro alle e-sigenze di Power Saving. Il Proxy deve calcolare il rate minimo R necessario allo scheduling On-Off del brano richiesto dal Client ed il rate R0 disponibile sulla connessione con il Client; se dal loro confronto risulta che R0 <R _{lo schedule}

non esiste e non è possibile fare Power Saving, il Proxy deve dunque comunicare al Client di non poter effettuare la trasmissione per insufficienza di banda; se in-vece R0 ³R_{, lo schedule On-Off esiste ed il Proxy può avviare la trasmissione.}

Accertata l’esistenza dello schedale, il Proxy deve procedere col calcolare e co-municare al Client l’istante in cui può avviare la riproduzione del brano.

Nel calcolo del ritardo iniziale di riproduzione, che va dall’istante di avvio della trasmissione all’istante in cui la riproduzione comincia effettivamente, oc-corre tener conto:

· del tempo di attesa imposto all’utente che ha chiesto la riproduzione; · del throughput disponibile sulla connessione con il Client;

Ci si può aspettare che dall’istante in cui l’utente fa richiesta del play lato Client, all’istante in cui la riproduzione incomincia effettivamente, non possa tra-scorrere più di un certo numero di secondi da intendersi come il tempo massimo che l’utente è disposto ad aspettare per l’ascolto (un limite massimo di attesa). In questo intervallo temporale devono rientrare il trasferimento della richiesta al Proxy e tutto quanto viene fatto dal Proxy per gestire lo scheduling prima di in-cominciare a trasmettere, principalmente: la ricerca nel file system della sequenza audio da inviare e la procedura di stima del throughput disponibile sulla connes-sione con il Client. Si può pensare che avanzi ancora un intervallino, di 3 sec ad esempio, in cui poter fare pre-buffering e creare una riserva di dati da consumare quando il throughput si abbassi e si rischi l’underflow del buffer. Il Proxy dunque può comunicare al Client un’attesa di al più 3 sec a partire dall’istante di inizio della trasmissione (coincidente per ipotesi con l’istante del primo arrivo al Client) prima di avviare la riproduzione.

L’istante di inizio della riproduzione va calcolato in maniera diversa a se-conda del throughput disponibile sulla connessione. Si suppone che il Proxy di-sponga di una stima R_AVG della banda mediamente disponibile sulle sue connes-sioni ottenuta calcolando la media pesata dei throughput sperimentati nelle con-nessioni passate. In un istante generico n la stima si ottiene dalla formula:

) ( ) 1 ( ) 1 ( ) (n R n R n R_AVG == _AVG - + -= ,

dove R(n) è la banda corrente valutata nell’istante n, RAVG(n-1) la banda media

stimata nell’istante precedente n-1, RAVG(n) la banda media stimata nell’istante n

corrente, 0£ = £1 opportunamente grande per dare maggior peso alle stime pre-gresse piuttosto che alla banda corrente ed assorbire eventuali picchi. E’ possibile sfruttare la stima della banda pregressa per esprimere un giudizio qualitativo sulla banda corrente. Se R(t) è la banda corrente ed RAVG(t) la banda pregressa (valore

con-Proxy inizia a trasmettere dispone delle stime: _{R per la banda disponibile inizial-}0

mente sulla connessione con il Client ed 0

AVG

R per la banda media sfruttata nelle connessioni pregresse. In caso di throughput basso il Proxy deve chiedere al Client di ritardare la riproduzione per trarre vantaggio dal pre-buffering, in caso di throughput alto invece comunica al Client un ritardo di riproduzione iniziale mi-nimo.

Anche dopo l’inizio della riproduzione il Proxy trasmette quando il rate è alto per minimizzare TON, e rimanda la trasmissione quando il rate è basso a patto

che ci sia garanzia sufficiente contro i rischi da underflow (si veda nel seguito).

Il calcolo del ritardo iniziale da imporre al Client prima di avviare la ripro-duzione ed indicato tipicamente come Start Point (SP), ha delle implicazioni sul-la durata complessiva degli Off-period dello Scheduling On-Off. [10] dimostra come, definendo lo Start Point molto vicino all’istante in cui è cominciata la tra-smissione, si riduce la durata complessiva degli Idle Period (TSLEEP) lasciando

in-variata la durata degli On-Period, e si contribuisce quindi a minimizzare il con-sumo della scheda di rete del Client. Le figg. 4.4-5 mostrano come la scelta dello

Start Point incida sulla quantità di dati che il Proxy riesce ad inviare nel primo On-Period. Nella fig. 4.4 è illustrata la strategia A che prevede di sfruttare

l’intervallo fra l’inizio della trasmissione e l’inizio della riproduzione per fare pre-buffering fino a riempire il buffer del Client: lo Start Point coincide proprio con l’istante in cui il buffer si riempie; la strategia B della fig. 4.5 invece prevede di anticipare l’inizio della riproduzione il più possibile e lo fissa subito dopo l’arrivo del primo frame. Alla fine del primo On-Period, negli istanti tA e tB

rispettiva-mente, con la strategia B sono stati trasmessi lB byte mentre con la strategia A ne

sono stati trasmessi l_A < , quindi, la strategia B è da considerarsi migliore. In l_B

conclusione, anticipare la riproduzione e favorire così un maggior ricambio dei dati nel buffer è preferibile a riempire prima tutto il buffer per poi rallentare la tra-smissione in un secondo momento, in attesa che la riproduzione faccia spazio a nuovi dati consumando quelli vecchi. La strategia B è più vantaggiosa rispetto alla

n. byte VB

fig. 4.4: Calcolo dello Start Point – strategia A

n. byte bB* lB VB

fig. 4.5: Calcolo dello Start Point – strategia B

strategia A anche nel caso in cui, in un istante t* generi-co si verifichi un crollo improvviso del throughput: la strategia B vanta in-fatti in questo caso un trasferimento maggiore di dati re-alizzato fino a t* (bB* byte) rispetto

alla strategia A (bA* < bB* byte) che ha già interrotto la tra-smissione tre volte in corrispondenza degli Idle-Period

(nel caso in cui t* < lA le due strategie offrono prestazioni equivalenti).

Riassumendo quanto esposto su, avvicinando il più possibile lo Start Point all’istante di inizio della trasmissione del Proxy:

i. si riduce la durata complessiva degli Idle Period (TSLEEP),

ii. si inviano più dati nel primo On-Period,

iii. si sfrutta meglio la banda prima di un eventuale crollo di throughput. Lo Start Point che soddisfi queste esigenze si ottiene calcolando l’intersezione fra l’inviluppo E (t)alla funzione di playout V(t) e l’asse delle ascisse. Nelle figg.

n. byte M E

fig. 4.6: Costruzione della curva di inviluppo

n.byte M

fig. 4.7: Costruzione della curva di inviluppo

4.6-7 si mostrano due esempi di determinazione dello Start Point: l’intersezione della curva di inviluppo con l’asse delle ascisse viene scelta come origine del

si-stema di riferimento ed è l’istante in cui il Proxy inizia a trasmet-tere; precede l’inizio della riproduzione per il Client, di un intervallo

SP, il minimo possibile,

tale da garantire una ri-produzione senza un-derflow. Questo è vero a patto che il Proxy e-segua una schedulazio-ne On-Off a rate costan-te pari al racostan-te iniziale R0

(R0 - On-Off

Smoo-thing). Una simile

ipo-tesi è giustificata dal fatto che all’inizio della trasmissione l’unico dato certo è il rate corrente R0 e che non se ne possa prevedere l’evoluzione futura, pertanto, si deve organizzare lo schedule in maniera da riuscire a portarlo a termine con successo con il rate a di-sposizione inizialmente, R0, alto o basso che sia. Se da un lato questa idea è ragio-nevole, dall’altro non ci si può permettere di trascurare la possibilità che il throu-ghput diminuisca per evitare di incorrere nell’underflow del Client buffer. Iniziata la riproduzione infatti, il prelievo dei dati dal buffer è scandito dalla curva di pla-yout e, se la banda diminuisce rispetto a quella valutata inizialmente può accadere che il prelievo dal buffer avvenga con velocità maggiore rispetto alla velocità con cui i dati arrivano nel buffer. Per scongiurare una simile evenienza è necessario posticipare la riproduzione in modo che i dati vengano accumulati prima nel

Client buffer senza essere consumati e creino una riserva di byte che, integrata dagli arrivi, anche a rate ridotto, dal Proxy, riesca a supportare la riproduzione, almeno entro certi limiti.

Dovendo ricorrere ad una soluzione di compromesso, si decide di antici-pare la riproduzione quel tanto che basta a tutelarsi da un possibile dimezzamento del throughput: il Proxy calcola l’istante di inizio riproduzione in funzione dell’intersezione fra l’inviluppo alla curva di playout a rate R0/2 (E_R

2

0 ), e l’asse

delle ascisse: sia

÷÷ø ö ççè æ 2 0 R

SP lo Start Point così individuato. In termini

probabili-stici:

{

}

Qualora posticipare la riproduzione ad

÷÷ø ö ççè æ 2 0 R

SP comporti un’attesa supe-riore a quella ammessa dal Client, la durata del pre-buffering viene adeguata alle esigenze del Client, accontentandosi perciò di una minore garanzia contro l’underflow.

4.3.5 Dimensione del Client Buffer

La dimensione del Client buffer viene utilizzata come parametro della schedulazione. Pur mantenendo la sua minimizzazione come uno degli obiettivi da perseguire, si decide di non imporre vincoli inizialmente e di osservare l’efficacia del protocollo dal punto di vista del Power Saving, al variare della di-mensione del buffer per scegliere infine una grandezza ottimale anche se non mi-nima.

4.3.6 Descrizione dell’algoritmo di Scheduling

In seguito alla richiesta fatta dal Client il Proxy deve anzitutto verificare che ci siano i presupposti per eseguire uno Scheduling On-Off e, nel caso, stabilire il ritardo iniziale di riproduzione SP0 da comunicare al Client. Procede pertanto calcolando il rate minimo R necessario alla schedulazione del file richiesto dal Client e valutando il throughput _R0_{disponibile sulla connessione. Se R}0 _{< R il}

Proxy comunica al Client che non è possibile procedere, chiude la connessione e termina. Se R0 ³ R _{la schedulazione è possibile. Nella scelta del ritardo iniziale}

di riproduzione, il Proxy fa uso del valore della banda media sulle connessioni pregresse, 0

AVG

R , per distinguere se il throughput disponibile è alto o basso e del valore dell’attesa massima consentita dal Client: inizialmente 3s. Il Proxy stima inizialmente il ritardo di riproduzione in SP(R0). Si può verificare che

· SP(R0) > 3s: il Proxy comunica al Client che la riproduzione non può

par-tire entro i 3s ma che dovrà essere ritardata di SP(R0)s, ed aspetta una con-ferma per procedere. Se il Client avvisa di non essere disposto ad atten-dere, il Proxy chiude la connessione e termina, se invece il Client comu-nica che è disposto a ritardare la riproduzione, il Proxy fissa lo Start Point ad SP(R0) ed aggiorna il valore di riferimento per l’intervallo di attesa massima del Client, pure ad SP(R0).

· (SP(R0)£ ) & (3s R0 ³RAVG0 ): il throughput è alto per cui il Proxy calcola

il ritardo di riproduzione in modo da anticiparlo il più possibile per sfrut-tare meglio la banda disponibile. Fissa pertanto

þ ý ü î í ì ÷÷ø ö ççè æ = SP R s SP ,3 2 min 0 0 _; · (SP(R0)_{£ ) & (}3s 0 0 AVG R

R < ): il throughput è basso ed il Proxy ritarda al massimo l’istante di inizio riproduzione fissando SP0a 3s.

Dopo questa fase preliminare il Proxy inizia a trasmettere. Il rate di tra-smissione in un istante t generico è R(t) pari al throughput disponibile in quel

momento; per evitare di sprecare tempo inviando frame che verranno poi scartati dal Client, il Proxy prima di inviarne uno, controlla di riuscire a trasmetterlo tutto prima del suo istante di playout (calcolato a partire dallo Start Point): per un gene-rico frame fi deve valere che (t +

) (t R

f_i

) < Playback_Timei. I frame che falliscono

il test vengono scartati e se raggiungono il 20% della dimensione complessiva del file il Proxy fa abortire la schedulazione per eccesso di perdite. Ad ogni trasmis-sione il Proxy valuta la banda sperimentata ed aggiorna opportunamente i valori del throughput R(t) e della banda media RAVG(t). Inoltre, fin quando la riprodu-zione non incomincia, il Proxy aggiorna pure il valore dello Start Point (SP) avvi-cinandolo quando la banda aumenta, allontanandolo quando la banda diminuisce, e lo comunica di volta in volta al Client. Se R(t)³ R_AVG

þ ý ü î í ì ÷ ø ö ç è æ = SP R t attesa SP ,max_ 2 ) (

min , dove max_attesa è il ritardo di riproduzione massimo consentito dal Client e può essere di 3s o maggiore se concordato con il Client in precedenza; se R(t)<R_AVG

Trascorso il ritardo di riproduzione SP il Client avvia la riproduzione lanciando il Media Player ed il Proxy smette di aggiornare lo Start Point. La riproduzione può essere anticipata qualora il Client buffer si riempia prima che sia trascorso lo Start

Point, in questo caso è il Proxy a comandare al Client di avviare subito la riprodu-zione.

Durante la riproduzione il decoder MP3 preleva i dati dal buffer del Client seguendo la funzione di playout V(t). Il Proxy aggiorna costantemente le stime di

R(t) ed RAVG(t) e controlla il livello di riempimento del buffer del Client: non deve

scendere sotto un valore minimo di acqua bassa (LW) variabile nel tempo in fun-zione del throughput (si veda sotto). Quando il Client buffer si riempie il Proxy interrompe la trasmissione e comanda al Client di mettere in Sleep la scheda di re-te. Analogamente quando il throughput scende sotto RAVG(t) (basso): il Proxy in

te deve verificare che il livello di riempimento del Client buffer sia superiore alla soglia minima di sicurezza acqua bassa(LW) per non rischiare l’underflow. Il Proxy, unitamente al comando di Sleep, comunica al Client dopo quanto tempo riattivare la scheda. Le trasmissioni vengono riprese successivamente quando pre-sumibilmente il throughput si sarà rialzato oppure quando i dati nel buffer saranno vicini alla soglia di acqua bassa.

Quando il Client ha la scheda di rete in Sleep, il Proxy resta in attesa di ri-cevere sue comunicazioni. Terminato l’intervallo di Sleep, per t=t*, il Client invia dei pacchetti di controllo al Proxy che stima così la banda R(t*) disponibile sulla connessione in quel momento e calcola l’istante più lontano in cui poter ricomin-ciare a trasmettere in funzione della curva di inviluppo a rate R(t*)/2 (si veda la fig. 4.8). Se t2 è l’istante in cui la riproduzione arriva a consumare tutti i dati già

schedulati nell’istante attuale t* (t2 t.c.: V(t2) = S(t*)) e t1 l’istante in cui la curva di

inviluppo a rate 2

) (_t*

R

raggiunge la medesima altezza dello schedule:

 * 2

), e t1 è l’istante più lontano in cui poter

ricominciare a trasmettere. Si rischia l’underflow nel Client buffer quando lo

n. byte V_B

schedule S(t) per t=t* è troppo vicino alla curva di inviluppo E_{R t}* ₂

questo si traduce nella relazione _t*_{- t1 <Dminsec, con} min

, opportunamente pic-colo; il livello del Client buffer nell’istante t1 si considera come livello di acqua bassa (LW). Il Proxy ricomincia a trasmettere subito in caso di acqua bassa, per evitare l’underflow, oppure nel caso in cui il rate di trasmissione stimato sia supe-riore ad RAVG(t*) (e c’è posto nel Client buffer per accogliere nuovi dati), per

sfrut-tare la disponibilità di banda. Se nessuna di queste condizioni è verificata e poten-do attendere fino all’istante t1 appena calcolato per ricominciare a trasmettere, il

Proxy comanda al Client di rimettere in Sleep la scheda di rete e torna ad attendere sue comunicazioni. Il nuovo intervallo di Sleep comunicato al Client è fissato dal Proxy a metà dell’intervallo che va dall’istante corrente t* fino a t1. In questo

mo-do si prevede di infittire il monitoraggio del canale man mano che lo schedule si avvicina alla curva di inviluppo ed aumenta il rischio di underflow.

Una strategia di messa in Sleep della scheda di rete del Client analoga a quella appena descritta nel caso in cui la riproduzione sia già incominciata, è pre-vista anche prima dell’inizio della riproduzione quando il Proxy trasmette ed ag-giorna il rate corrente R(t), la banda media RAVG(t) e lo Start Point per l’inizio del-la riproduzione. Se R(t)< R_AVG

Point per l’inizio della riproduzione con l’istante massimo fino a cui il Client può attendere la riproduzione. Il Proxy, inoltre, verifica la possibilità di mandare in

Sleep la scheda di rete del Client, calcola l’istante più lontano in cui poter rico-minciare a trasmettere e finalmente comanda lo Sleep della scheda al Client e smette di trasmettere restando in attesa di nuove comunicazioni.

Il Proxy termina quando ha completato la trasmissione dell’intero file MP3 oppure quando i frame scartati hanno raggiunto il 20% della dimensione comples-siva del file.

4.3.7 Esempio

Nella fig. 4.9 il Proxy comincia a trasmettere a rate R0, (l’istante di inizio trasmissione è fissato come origine del sistema di riferimento) e comunica al Client di avviare la riproduzione con un ritardo di )

2 (

0

R

SP rispetto all’istante di arrivo del primo pacchetto (per ipotesi coincidente con l’istante di trasmissione dello stesso). Il primo On-Period termina con il riempimento del buffer lato Client: la trasmissione è interrotta e la scheda di rete del Client fatta mettere in

Sleep (primo Off-Period).

Alla fine del frame-time il buffer si svuota parzialmente: la scheda di rete viene riattivata e la trasmissione riprende, sempre a rate R0 (ancora disponibile). Seguono On- ed Off-Period analoghi, fino all’istante t* in cui, riempito il buffer, la scheda è fatta mettere di nuovo in Sleep fino al termine del frame-time.

Il Proxy si accorge allora che il throughput è cambiato: R(t*) sia il nuovo. Trattandosi di un throughput basso, decide di non riprendere la trasmissione e comunica al Client di mantenere in Sleep la scheda di rete.

n. byte V_B

L’Off-Period dura allungo poiché il throughput non migliora nel frattempo. La trasmissione deve riprendere, seppure con rate basso R(t*), al raggiungimento del limite di acqua bassa (nella figura corrisponde all’intersezione fra la funzione di schedulazione S(t) e l’inviluppo E_R(t*₂₎(t)alla funzione di playout V(t)). Infine durante l’On-Period così cominciato il throughput si risolleva, il rate di trasmissione viene adeguato e rimane immutato fino al termine della schedulazione.