wiki:Diario/Gnappo

Context Navigation

Version 31 (modified by gnappo, 17 years ago) (diff)
Aggiornamento del diario,

Diario di gnappo

Diario di gnappo

05 Giugno 2007

1000 - 1100

Autenticazione su piattaforma trac.

09 Giugno 2007

0930 - 1030 (1h)

Ricerca su Internet:

-> overhead da tenere presenti? http://www.ieee-infocom.org/2003/papers/21_01.PDF : si tratta di uno studio di un'anomalia di 802.11b (se in una rete c'e' un client 802.11b lento, questo penalizza gli altri!). Durante la dissertazione viene fatto un calcolo dell'overhead introdotto da 802.11b (circa il 30%). Questa percentuale cresce se ci sono contese (e quindi backoff algorithm). Nel documento sono presenti formule che modellano adeguatamente l'overhead.

-> come valutare il carico in presenza di PCF? Unsolved question.

-> QoS, spunti interessanti?

11 Giugno 2007

1400 - 1845 (4.75h)

-> Diffusione di PCF: sembra che a causa delle carenze di specifiche non sia largamente implementato ( A survey of quality of service in IEEE 802.11 networks, la bibbia cap. 9), per tanto il carico potrebbe essere analizzato supponendo di essere in DCF.

-> Attualmente una STA seleziona un BSS un AP in base alla sola potenza del segnale (RSSI) che e' evidentemente insufficiente ai nostri scopi.

On Access Point Selection in IEEE 802.11 Wireless Local Area Networks (02): innanzitutto mette in luce che se una stazione sceglie di trasmettere ad un rate basso per evitare errori (magari sente un segnale disturbato), si ha un degrado del throughput globale poiche' il protocollo di accesso al mezzo e' fair, e quindi la lumaca puo' occupare il mezzo per tempi considerevoli (visto il basso rate).
La selezione dell'AP e' fatta in base al throughput ottenibile dalla STA (stimabile con una equazione da verificare che tiene conto anche del frame error rate espresso in funzione di SNR). Inoltre lo studio tiene conto anche dell'impatto della STA sul nuovo BSS (vedi sopra). Viene presa in considerazione anche la possibilita' di una selezione dinamica dell'ap che viene fatta ad intervalli di tempo variabili per evitare scan non necessari (tempo di scan 1, 2 secondi). In particolare il periodo aumenta se l'ap candidato rimane sempre lo stesso.

Improved Access Point Selection (03): mette in luce altri fattori che intervengono nella selezione di un access point, come politiche di filtering (MAC, port), limiti di bandwith o di utilizzo (servizio a pagamento) ecc... Per tanto propone dei test per valutare l'effettiva qualita' di un BSS. Potremmo esplorare anche questa strada.

-> da vedere: SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks

-> poco utile: http://people.nokia.net/cedric/Papers/VTC06multiaccess.pdf

12 Giugno 2007

0910 - 1310 (4h)

Improved Access Point Selection (03): il test che propongono e' il seguente:

1. trova tutti gli AP disponibili
2. colleziona i beacon
3. per ogni AP "in chiaro"
4.   prova ad ottenere un indirizzo IP (con dhcp)
5.   se ottieni l'IP
6.     stima RTT con il server di riferimento (ping)
7.     testa le porte aperte
8.     stima il bandwidth

Virgil, questo il nome del progetto, e' in fase di sviluppo su piattaforma linux (anche se non sembra reperibile). Utilizza wireless tools (iwlist, iwconfig) per collezionare statistiche e per ogni AP incontrato viene lanciato un pthread incaricato della valutazione della bonta' dell'AP. L'overhead introdotto con questa soluzione non e' cosi' esorbitante considerando il fatto che sono necessari 2,5 secondi solo per un iwlist scan.

SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks (05): discute principalmente di quando piazzare i momenti di scan preferendo lo scanning attivo (probe request, probe response) rispetto al passivo per la sua "immediatezza" (non sono costretto ad aspettare un beacon interval). Ci interessa molto marginalmente.

Decentralized Access Point Selection Architecture for Wireless LANs - Deployability and Robustness - (06): propone un algoritmo di selezione di un AP basato sulla massimizzazione del throughput locale. I fattori che in ultima analisi sembrano incidere di piu' nella determinazione del throughput locale sono il packet error rate (ricavabile in funzione del SNR) e il numero di stazioni connesse all'AP (ottenibile mediante scan). Lo studio assume, pero', che le probabilita' di collisioni siano trascurabili. Inoltre, viene proposto un algoritmo dinamico, dal momento che le condizioni delle reti wireless sono volubili. Nella simulazione si tiene anche conto della concomitanza nella stessa area geografica di nodi che utilizzano RSSI per la selezione e altri che invece utilizzano l'algoritmo proposto. In ogni caso una selezione siffatta incrementa il throughput minimale di tutti i nodi, siano essi dotati o no del nuovo sistema.

-> sia (02) che (06) valutano il packet error rate in funzione di SNR

Energy-Efﬁcient PCF Operation of IEEE 802.11a Wireless LAN (07): contiene una sintesi del packet error rate in base a SNR. Fa riferimento a distribuzioni statistiche, e' molto tecnico.

1500 - 1900 (4h)

An Optimized Load-Balancing Algorithm for Infrastructure Based Short-Range Wireless Networks (09): l'algoritmo di selezione dell'AP si fonda su una relazione pesata tra il numero di ritrasmissioni necessarie per consegnare un pacchetto e il ritardo nella trasmissione. Inoltre, lo studio evidenzia, piuttosto grossolanamente, come le prestazioni degradino notevolmente con l'aumentare dei nodi associati al BSS.

Client Channel Selection for Optimal Capacity in IEEE 802.11 Wireless Networks (11): lo studio propone un semplice (e, secondo me, non corretto) modello per la valutazione dello stato di un canale. La capacita' di un canale wireless e' fondamentalmente condizionata da due parametri: dalla tecnologia utilizzata (802.11{b,g}) e dalla natura della comunicazione (i.e. onde radio, si pensi ai disturbi di reti overlapped).
Se vi sono N client associati con un access point la capacita' Ca disponibile a ciascun client e cosi' limitata:
Cm >= Ca >= Cm/N dove Cm e' la massima capacita' disponibile nella rete wireless (limitata dagli overhead associati al protocollo, vedi limitazione della tecnologia). Inferiormente e' limitata a Cm/N poiche' la politica di assegnazione del canale dovrebbe essere fair.
Inoltre la capacita' del canale e' anche limitata dal teorema di Shannon (vedi limitazione della comunicazione). Il minimo di queste due valutazioni dovrebbe restituire un capacita' minima "garantita". L'access point con capacita' minima migliore sara' l'access point da selezionare (scelta conservativa).
I parametri per operare questa scelta sono di facile reperibilita': il numero dei nodi associati si ottiene con un semplice scan, la massima capacita' del canale e' disponibile nei beacon mentre la potenza del segnale (per calcolare Shannon) e' direttamente disponibile dall'hardware.
Critica: in tutti questi ragionamenti si suppone, celatamente, che ogni client operi alla medesima bandwidth il che, oltre a non essere realistico, ha anche conseguenze tutt'altro che trascurabili per gli altri nodi in quanto puo' diminuire drasticamente la banda loro disponibile.

Network Selection Decision in Wireless Heterogeneous Networks: affronta la tematica di selezione di una rete wireless di qualsiasi tipo, per altro a livelli che non ci competono.

Scalable and Robust WLAN Connectivity Using Access Point Array: per valutare il carico di un AP propone di analizzare i silenzi, poiche' il numero di stazioni associate ad un AP e' un indicatore troppo debole (ci sono studi che lo dimostrano). Un canale e' occupato quando ci sono dati, oppure quando c'e' un silenzio dovuto ad una contesa. Il canale e' libero quando non e' occupato. Da approfondire.

Formattazione del diario.

13 Giugno 2007

0940 - 1140 (2h)

Upload del diario e breve formattazione.

Prosecuzione dello studio del paper 12:
Scalable and Robust WLAN Connectivity Using Access Point Array (12): per calcolare il tempo libero del canale la stazione deve operare in monitor mode. In particolare dovra' saltare su tutti i canali di interesse e nel frattempo tenere anche traccia del numero di stazioni associate, facilmente ricavabile con un analisi dell'header dei pacchetti. Ovviamente le STA completamente inattive non verranno tracciate ma cio' ha poca importanza dal momento che non generano traffico. Ancora una volta, lo studio si svolge in un contesto in cui la coordinazione d'accesso al mezzo e' distribuita ignorando di fatto quella centralizzata. L' idle time del canale si trova per differenza tra il tempo totale e il tempo in cui il mezzo e' rilevato essere occupato. Tutte le informazioni necessarie al calcolo del tempo in cui il canale e' in uso sono reperibili negli header dei frame (e.g. il transfer rate di ciascuna STA). La valutazione dei silenzi dovuti al backoff e' difficile, se non impossibile e quindi viene scelto un approccio calibrativo.

1500 - 1645 (1.75h)

Punto della situazione con SoujaK.

Prosecuzione dello studio del paper 12:
Scalable and Robust WLAN Connectivity Using Access Point Array (12): lo studio in generale affronta il problema dell'ottimizzazione di distribuzione di carico su piu' access point, pertanto sono previste politiche di non congestionamento.

Performance Analysis of the IEEE 802.11 Distributed Coordination Function : da vedere.

14 Giugno 2007

0905 - 1235 (3.50h)

Rilettura del documento 02: conseguenze del multirate in una cella: se in una cella sono presenti una STA operante a 11Mbps e una a 1Mbps il loro throughput e' comparabile! Questo fattore dovrebbe essere tenuto in considerazione.

da vedere: "Evaluation of “Performance Anomaly of 802.11b” paper through simulation results"

"MiFi?: A Framework for Fairness and QoS Assurance for Current IEEE 802.11 Networks With Multiple Access Points": un altro studio di Bejerano, dopo quello analizzato da soujak, caratterizzato dallo stesso rigore formale. Viene subito evidenziato come DCF non si presti a politiche di QoS in particolar modo riferite ad applicazioni RT (Real Time), a differenza di PCF. Per tanto lo studio suppone che gli access point forniscano tale servizio, che ricordo, ai fini del nostro studio, non essere diffuso. Inoltre, si assume che piu' access point che coprono la medesima area passino simultaneamente dal CFP al CP e viceversa, comportandosi idealmente come un singolo access point (il rapporto CFP/CP e' addirittura dinamico). Lo studio quindi s'interroga sull'equa ripartizione degli slot di tempo tra le STA, un problema non risolvibile in tempi polinomiali (a meno che P=NP).
In conclusione, la soluzione prevede delle modifiche sostanziali agli AP lasciando inalterate le STA e 802.11.

"An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process": lo studio analizza dettagliatamente il tempo necessario per un handoff (802.11b), proponendo infine delle linee guida per ottimizzare questa funzione. Consultabile solo per riferimenti temporali.

Un po' fuori traccia:
Techniques to Reduce IEEE 802.11b MAC Layer Handover Time : lo studio cerca di ottimizzare i tempi necessari per la fase di ricerca di un AP e cerca di individuare anche un fattore di scelta di quando effettuare un handover (cambio di AP). I prodotti attualmente in commercio utilizzano il numero di frame non ACK'ed per decidere quando cambiare AP (questo parametro sintetizza, indistinguibilmente, collisione congestione e perdita di segnale). Durante la fase di ricerca degli AP, viene evidenziato un problema: nel caso di piu' BSS sullo stesso canale quanto tempo devo ascoltare per ricevere i beacon di tutti? Con lo scanning attivo si aggira il problema.

Aggiornamento del diario.

15 Giugno 2007

0930 - 1030 (1h)

Creazione indice documenti.

Ricerche su Internet:

A Study on Dynamic Load Balance for IEEE 802.11b Wireless LAN (16): propone un algoritmo di bilanciamento diviso in tre fasi: coordinazione tra AP (nella quale vengono assegnati canali distinti per evitare noiose interferenze), decisione della STA con quale AP associarsi e scelta del momento in cui cambiare AP. E' interessante osservare che utilizzano il valore RSSI medio delle STA e il numero di STA associate come criteri fondamentali per le due ultime fasi.

1120 - 1200 (1.66h)

Performance Anomaly of 802.11b (17): e' lo studio che mette in risalto l'anomalia di 802.11b tale per cui una stazione con un basso tasso trasmissivo danneggia tutte le altre che hanno un tasso piu' alto. Rimane da capire se questa anomalia persiste anche in 802.11g, cosa che personalmente reputo probabile dal momento che, a memoria, non vengono introdotte modifiche alla tecnica di assegnazione del mezzo. Nel documento viene derivata una semplice espressione per il calcolo del throughput disponibile, che e' fortemente influenzato dal numero di stazioni che si contendono il mezzo e dopo viene dimostrata l'anomalia.

1411 - 1512 (1.01h) Punto della situazione con sjk: aggiornamenti, chiarimenti e sviluppi futuri.

1700 - 1820 (1.00h) Ricerca di ulteriore documentazione.

19 Giugno 2007

(3h)

IEEE 802.11e Wireless LAN for Quality of Service (18): il documento si pone l'obiettivo di illustrare le principali novita' introdotte con 802.11e. In particolare vengono evidenziate le differenze con 802.11 per quanto riguarda le politiche di accesso al mezzo. 802.11 fornisce un po' di supporto per QoS grazie a PCF, che pero' soffre principalmente di due problemi: la non predicibilita' dei ritardi dei beacon e il non controllo della durata delle trasmissioni di STA CF-Pollable. Il ritardo di beacon, in generale, si ha quando avvengono delle trasmissioni nell'intorno del TBTT, dal momento che 802.11 consente di inviare frame il cui tempo di consegna puo' sforare il prossimo TBTT. Un ulteriore problema e' rappresentato dalla STA nascosta che potrebbe interferire durante il CFP (e.g. se non sente un beacon).
In 802.11e due nuove modalita' di accesso al mezzo vengono definite: EDCF (Enhanced DCF) e HCF (Hybrid Coordination Function). La prima viene utilizzata durante i CP, mentre la seconda durante CFP e CP. Una STA chiamata HC (Hybrid Coordinator) svolge compiti analoghi al PC.
Con EDCF vengono introdotte le Traffic Categories (TC), che intervengono pesantemente nel calcolo del backoff. In una STA si hanno fino a 8 code di trasmissione e quindi 8 istanze di backoff counter. Idealmente quindi vi sono 8 STA virtuali che concorrono per l'assegnazione del mezzo. Se il backoff counter di una STA virtuale scade in contemporanea ad altri si ha una collisione virtuale risolta da un opportuno scheduler che avvantaggera' la trasmissione a priorita' piu' alta (cfr. TC). HCF estende EDCF, fornendo funzionalita' per un accesso libero da contesa. E' compito dell'HC organizzare i tempi e i modi dei CFP, determinando, tra l'altro, chi deve parlare e per quanto tempo. Inolte l'HC ha anche la facolta' di effettuare del polling durante i periodi con contesa utilizzando interframe space piu' corti rispetto a quelli impiegati con (E)DCF. Al fine di minimizzare le collisioni esiste un meccanismo di prenotazione, basato su TC, della STA presso l'HC.
Dal momento che con EDCF non esiste una coordinazione centralizzata, e' possibile statisticamente ottenere QoS sfruttando le TC. Rimane, pero', il problema di BSS overlapped: e' allo studio un meccanismo di selezione dinamica delle frequenze.

Inizio lettura di Characterizing User Behavior and Network Performance in a Public Wireless LAN (19).

20 Giugno 2007

(1h)

Ultimazione lettura di (19): essenzialmente si analizzano i comportamenti e abitudini di utenti 802.11 che nella fattispecie partecipavano ad una conferenza. Lo studio va oltre cio' che ci interessa. Comunque la cosa, secondo me, piu' rilevante e' che in base alle rilevazioni da loro effettuate il carico di un AP non puo' basarsi solamente sul numero di utenti associati ma in realta', come intuibile, dipende dal traffico che ogni singola STA genera. Per altre osservazioni particolari, ma a noi poco utili, rimando alla lettura del documento.

1550 - 1820 (2.5h)

New Insights from a Fixed Point Analysis of Single Cell IEEE 802.11 WLANs (20): lo studio richiede un background statistico che attualmente non mi appartiene e quindi si fa veramente complesso (alcune parti sono state saltate in tronco). E' la prosecuzione di uno studio precedente di Bianchi che in questa sede viene generalizzato e semplificato (in particolare si parte da equazione con punto fisso). L'ipotesi e' che le STA abbiano sempre una coda di trasmissione piena. Con questa condizione e' possibile capire l'allocazione del canale analizzando i backoff. Si assume anche che i parametri per il calcolo del backoff siano gli stessi per tutti i nodi. A partire da queste ipotesi vengono fornite formule per il calcolo della probabilita' di collisione, il data-rate, il throughput della rete.
Da notare che nel corso dell'analisi si ribadisce come una stazione con basso tasso trasmissivo abbia un impatto negativo in BSS partecipati da stazioni piu' prestanti.

Aggiornamento del diario.

Sistemazione dell'indice dei documenti.

21 Giugno 2007

0920 - 1340 (4.33h)

Aggiornamento del diario (19 e 20 Giugno).

Punto della situazione con soujak: aggiornamenti sul lavoro svolto negli ultimi giorni, sviluppi futuri e individuazione di alcuni parametri di base utili per la determinazione del carico.

Approfondimento dello studio (02): per stimare il throughput ottenibile e l'impatto della STA sul nuovo BSS a cui desidera associarsi, occorrono due valori che, a parer loro, devono essere comunicati dall'AP: il numero di STA associate e il tempo di occupazione del canale da parte delle altre STA. Queste informazioni, a mio parere, si possono carpire abbastanza agevolmente mediante azioni di sniffing.

1500 - 1640 (1.66h)

Incontro con gli altri componenti del gruppo: sviluppi futuri e breve condivisione di conoscenze.

1705 - 1735 (0.5h)

Approfondimento di (09).
Analisi e commenti insieme a soujak su i grafici dello studio di Bejerano precedentemente da lui analizzato.

22 Giugno 2007

0935 - 0955 (0.33h)

Aggiornamento del diario.

1140 - 1320 (2.66h)

Ulteriori appunti su (09): viene definita perdita di efficienza a causa di ritrasmissione di pacchetti il rapporto tra l'utilizzazione del canale nel caso ideale (i.e. senza data-loss e con RSSI massimo) e utilizzazione reale del canale che comprende errori bad CRC, ACK timeout, tempi di backoff e numero di ritrasmissioni (quest'ultimo calcolato in funzione di SNR). Analogamente, la perdita di efficienza dovuta al congestionamento della rete invece e' calcolata come il rapporto tra l'utilizzazione del canale nel caso ottimo e nel caso di congestionamento. Per stimare quest'ultimo fattore si guarda al ritardo di accodamento che va sommato al normale tempo di trasmissione.
La funzione obiettivo per la scelta dell'AP e' il prodotto tra la perdita di efficienza in caso di congestionamento ed in caso di perdita di pacchetti.

Ricerca di documentazione.

1500 - 1800 (3h)

Lavoro con soujak: mappa mentale sul carico (kdissert), sviluppi futuri.

1815 - 1845 (0.5h)

Approfondimento dell'appendice dello studio sjk03.
Metodo per stimare la latenza e il bandwidth in un collegamento tra un nodo X e un nodo Y:
sia p il packet error rate sul canale, t la latenza che intercorre in un scambio di dati con esito positivo (per l'accesso RTS/CTS e' la differenza di tempo tra l'RTS e il primo ACK). Sia b il valore medio iniziale del backoff counter, espresso in unita' di tempo (b=CWMin*SlotSize/2).
L'ammontare di tempo per effettuare il primo tentativo di trasmissione e' pari a b+t TU. Se la trasmissione fallisce (la probabilita' di fallimento ricordo essere p), si raddoppia la finestra di contesa cosicche' il secondo tentativo occupera' 2b+t TU, che sommati al primo tentativo diventano 3b+2t TU. Generalizzando il procedimento, tenendo conto del packet error rate, si ha che la latenza totale l all'iesimo tentativo e' pari a:

Da scrivere formulaccia generalizzata in funzione del packet error rate.

Si noti che vengono fatte due assunzioni: il frame viene ritrasmesso fin tanto che questo non viene ricevuto dal destinatario e non c'e' limite superiore alla CW. S'intuisce che queste due approssimazioni non sono molto significative, considerando che nella maggior parte dei casi reali un MSDU viene trasmesso in pochi tentativi.
L' error rate del collegamento puo' essere determinato da una STA esterna e passiva semplicemente osservando i numeri di sequenza dei pacchetti (secondo me vale la pena guardare quegli studi in cui l' error rate e' espresso in funzione di SNR in modo tale che la STA possa calcolarlo autonomamente, vedi 02).
La bandwidth del collegamento sara' pari a Sdata/l dove Sdata e' la dimensione dei dati e l la latenza appena calcolata.

25 Giugno 2007

1005 - 1340 (3.58h)

Aggiornamento del diario.

Formalizzazione con soujak dei pensieri fin qui fatti e impostazione di una soluzione (kdissert).

1500 - 1815 (3.25h)

Affinamento della soluzione proposta (con soujak).

26 Giugno 2007

1100 - 1400 (3h)
1600 - 1738 (2.63h)

Con soujak:

caricamento della mappa mentale che sta guidando le nostre attività;
ulteriori chiarimenti riguardo le modalità di considerazione della presenza della STA associanda;
abbozzo di metrica per la aggregazione del carico teorico ed effettivo all'interno della stima;
formalizzazione delle questioni aperte e del sottoinsieme da proporre a Ghini;
aggiornamento della mappa mentale;
stesura del diario della giornata.

Aggiornamento del diario.

Ricerca di documentazione riguardo la determinazione della bandwidth.

27 Giugno 2007

1100 - 1230 (1.5h)

Aggiornamento del diario.

Rilettura del diario alla ricerca di spunti interessanti (soprattutto in vista di un raffinamento teorico):

in 02, 06, 07 e 09 si stima il frame error rate in base al solo RSSI;
in 17 per calcolare il throughput effettivo viene data una stima semplificata del tempo speso per la contesa. Si basa essenzialmente sul numero di STA in competizione per il mezzo e sulla grandezza della finestra di congestione.

Lettura del diario di soujak alla ricerca di spunti interessanti.

1325 - 1510 (2.75h)

Assieme a soujak: raffinamento del modello teorico: analisi dei tempi persi sia a causa di errori sui frame sia di attesa dei tempi di backoff. Individuazione di alcuni parametri utili al fine di stimare queste grandezze.

1830 - 2000 (1.5h)

Incontro con il prof. Ghini: aggiornamento sui lavori fin qui svolti da me e tittarello, alcuni chiarimenti sulla caratterizzazione dello scenario (banda utile, tempi di ascolto).

28 Giugno 2007

1100 - 1120 (0.33h)

Condivisione, approfondita, con Roma delle conoscenze acquisite sul carico.

1120 - 1240 (1.33h)

Incontro con il resto del team: aggiornamento sui progressi fin qui fatti sia per quanto riguarda la determinazione del carico sia per il rilevamento di un servizio di roaming (con DS a supporto). Pianificazione delle attivita' future, a livello di contenuti e di tempistiche.

1740 - 1815 (0.58h)

Condivisione di conoscenza con soujak dell'appendice a sjk03. Alcune riflessioni a proposito di un eventuale impiego di quel modello, soprattutto incentrate sulla potenza di calcolo necessaria.

29 Giugno 2007

1500 - 1530 (0.5h)

Aggiornamento del diario riguardante le ultime due giornate di lavoro.

1620 - 1835 (2.25h)

Assieme a soujak: rilettura di 02 e approfondimento delle questioni ancora poco chiare. Schedulazione degli obiettivi a breve termine.

01 Luglio 2007

1150 - 1300 (1.16h)

Ricerca su Internet di documenti riguardanti le modalita' di selezione del data rate nei prodotti attualmente in commercio (#1).
In http://www.dell.com/downloads/global/shared/broadcom_802_11_g.pdf si parla di aggiustamenti del data rate al fine di minimizzare gli errori di comunicazione, senza entrare pero' nello specifico.

21 : viene anzitempo chiarito che lo standard non definisce alcuna istanza di RCA (Rate Control Algorithms). L'analisi si concentra sugli algoritmi utilizzati nei prodotti Atheros con driver MadWiFi. Ne sono disponibili piu' d'uno, e tutti utilizzano il concetto di errore di trasmissione inteso nel suo senso piu' ampio.

02 Luglio 2007

1020 - 1305 (2.75h)

Aggiornamento del diario.

Approfondimento di #1.
21 : gli algoritmi di selezione dinamica del data rate possono essere implementati sia via hardware che via software. Nel caso particolare dell'accoppiata Atheros e MadWiFi, l'algoritmo risiede in moduli all'interno del driver. Le informazioni riguardanti il current rate e i tentativi di ritrasmissione sono comunicati direttamente dall'hardware. Attualmente sono disponibili tre RCA:

ONOE: e' un algoritmo basato su crediti determinati in funzione del numero di trasmissioni con esito positivo, con esito fallimentare e del numero di ritrasmissioni, il tutto calcolato in un intervallo di tempo. Il cambio di data rate si effettua nel momento in cui si varcano determinate soglie. Si veda il driver MadWiFi per i dettagli.
AMRR: si basa sul meccanismo MRR (Multi Rate Retry), il quale prevede che l'invio di un frame avvenga, se necessario, provando piu' tassi trasmissivi. Per ogni rate si hanno a disposizione un numero limitato di tentativi: nel momento in cui questi si esauriscono (i.e. invio non riuscito) si passa a rate piu' bassi. AMRR (Adaptive MRR) cambia i tassi trasmissivi ed il valore del numero di tentativi ad essi associato ad intervalli di tempo calcolati utilizzando la tecnica BEB (Binary Exponential Backoff). Si veda 22 per i dettagli.
SampleRate: e' l'RCA piu' aggressivo poiche' periodicamente trasmette dei pacchetti a data rate piu' alti del corrente, valutando effettivamente le prestazioni del canale. Si comincia dal data rate piu' alto e si procede con gli aggiustamenti fin tanto che non si raggiunge quello ottimale. Si veda 23 per i dettagli.

1350 - 1720 (3.5h)
1730 - 1835 (1.08h)
24: lo studio s'interroga sulle ripercussioni dell'adeguamento del data rate in condizioni di congestionamento. I meccanismi attualmente utilizzati per l'adeguamento del tasso trasmissivo si classificano in base al fattore su cui si fondano: frame error rate, throughput ottenibile, SNR. Tra i meccanismi frame error based si citano: ARF (Auto Rate Fallback) e AARF (Adaptive ARF), impiegati in schede WaveLAN-II (si rimanda a 22), ONOE e AMMR di cui si accennava prima (schede Atheros). Tra quelli throughput based si ricorda SampleRate.
Se in un canale non si hanno collisioni, il frame error rate puo' essere stimato a partire dall'SNR. I meccanismi basati su SNR selezionano il tasso appropriato consultando una tabella precompilata (in realta' si utilizza l'RSSI). L'RSSI misura l'ammontare di energia rilevata sul canale durante la ricezione di un'intestazione PLCP.
Nel corso del documento si valuta l'impatto delle collisioni nella scelta del tasso trasmissivo. Viene fatto notare come certi algoritmi basati sul tasso di errore dei frame (e.g. ARF), non distinguendo la natura dello stesso, diminuiscano inutilmente il data rate (non c'e' correlazione tra tasso trasmissivo e collisioni). Esiste un algoritmo, CARA (Collision-Aware Rate Adaption, vedi 25), che tiene conto del problema e discrimina le perdite dovute a collisione analizzando le perdite di frame RTS (si tenga presente che e' un'approssimazione).
Gli algoritmi di selezione basati sul throughput ottenibile e su SNR non dovrebbero risentire delle collisioni. Viene sollevata una questione proprio riguardo SNR: non e' chiaro se le correnti implementazioni di 802.11 forniscano l'SNR oppure l'SINR (Signal-to-Interference-and-Noise ratio).

L'interpretazione assoluta dell'RSSI non e' definita nello standard, comunque molti produttori usano una scala dove ad ogni incremento di RSSI corrisponde un incremento di circa un dB della robustezza del segnale.

25: lo studio affronta la tematica della selezione del data rate. Per fare cio' introduce alcune nozioni che risultano utili alla comprensione. Nel momento in cui si parla di RTS/CTS, come meccanismo per risolvere il problema del nodo esposto, viene fatto notare che in pratica e' raramente utilizzato a causa degli overhead. Ne proporranno un uso alternativo per determinare la probabilita' di collisione.
Nel mercato 802.11, e' ARF lo schema di adeguamento del data rate piu' implementato: ogni STA mantiene un timer e tiene traccia dei frame ACK perduti, se due ACK consecutivi non vengono ricevuti, viene effettuata una ritrasmissione ad un rate piu' basso e viene fatto partire il timer. Nel momento in cui scade il timer oppure vengono ricevuti con successo 10 ACK si alza il tasso trasmissivo ed il timer viene reimpostato. Con questo algoritmo non si discriminano perdite dovute a collisioni oppure a errori sul canale.
L'idea centrale dell'algoritmo che propongono, CARA, e' che un fallimento dell'invio di un RTS denoti una collisione, dal momento che un errore di trasmissione dovuto a cattive condizione del mezzo e' trascurabile (il frame e' molto corto e il data rate al quale viene trasmesso garantisce una certa robustezza). Congiuntamente a questa tecnica di rilevamento si puo' applicare lo schema ARF, che questa volta risultera' operare correttamente.

Condivisione con soujak del lavoro svolto ultimamente.

Idea: dal momento che ARF tiene conto degli errori in toto e gli errori dovuti alle condizioni del mezzo sono ricavabili in funzione di RSSI (o SNR?), per "differenza" (cosa significa?) possiamo stimare una probabilita' di collisione (i termini di questa equazioni non sono comparabili dimensionalmente).

03 Luglio 2007

0950 - 1415 (4.41h)

Aggiornamento del diario.

Riflessione: dal momento che SNR dovrebbe essere sufficiente per la valutazione delle condizioni del mezzo, mi chiedo perche' i produttori di schede 802.11 non utilizzino questo fattore: una causa potrebbe essere ricercata nel fatto che questo indicatore non e' sufficientemente preciso (e.g. troppo discretizzato).

Approfondimento di 25.

Dando un'occhiata veloce a 26, trova forse risposta la domanda precedente: gli AP, e piu' in generale i dispositivi 802.11, possono utilizzare tecniche per limitare la potenza trasmissiva in un'ottica di economia degli apparecchi. Lo studio puntualizza pero' che questi meccanismi sono raramente adottati (questa informazione necessita di verifica dal momento che lo studio e' piuttosto datato). Lo studio assume che l'RSS abbia, in media, una relazione lineare con l'SNR.

Correlazione tra l'RSSI e qualita' del collegamento: da ricerche effettuate sembrano emergere pareri discordanti riguardo la bonta' di questo indicatore. I detrattori sostengono che non c'e' uniformita' tra gli implementatori e che i valori forniti non sono affatto precisi. In aggiunta, si consideri anche il problema evidenziato in precedenza legato al controllo della potenza di trasmissione.
Sembra essere piu' affidabile (per la stima del packet error rate), invece, il Link Quality Indicator (LQI) che meriterebbe un approfondimento.

Assieme a soujak: breve condivisione di conoscenze, aggiustamento della mappa mentale (sottoalbero carico teorico) alla luce di alcune considerazioni effettuate sugli errori dei frame e loro incidenza sulla determinazione del carico.

1520 - 1530 (0.16h)

Aggiornamento del diario.

1630 - 1830 (2h)

Assieme a soujak: riflessioni sulla determinazione del data rate della STA associanda alla luce di quanto letto recentemente. Essendo la questione abbastanza problematica si e' deciso che si faranno delle approssimazioni che potrebbero essere significative. Una soluzione che stimi il data rate conoscendo il vendor di una scheda, e quindi il meccanismo adottato, appare non percorribile.

04 Luglio 2007

0925 - 0955 (0.5h)

Aggiornamento del diario e chiusura ticket #1.

1115 - 1205 (0,83h)

Ricerca documentazione su RSSI e SNR.

SNR: rapporto tra potenza del segnale e il rumore di fondo.

RSSI: e' la misura della potenza del segnale rilevata dal circuito presente nella scheda wireless. IEEE 802.11 prevede che questo valore, intero, oscilli tra 0 e 255. Il range dei valori possibili, essendo molto esteso, viene in genere limitato dai produttori ad un valore RSSI_Max strettamente minore di 255. Ad esempio Cisco prevede 101 valori, Atheros 61, Symbol 32. Lo standard non specifica come la potenza del segnale debba essere rilevata (e.g. in dBm o mW) e lascia al produttore la liberta' di scegliere l'accuratezza, la granularita' e la scala di questa misurazione. Viene piuttosto specificato quando deve essere rilevata, cioe' tra l'inizio dello SFD e la fine dell'intestazione PLCP. Lo standard aggiunge che il parametro e' opzionale: fortunatamente ad oggi sembra che tutte le schede forniscano tale indicazione.
Dal momento che la rappresentazione della potenza del segnale e' discretizzata, non tutti i possibili valori di energia del segnale possono essere rappresentati. Per decodificare un segnale in una stringa di bit, occorre un minimo di potenza al di sotto della quale il valore di RSSI e' 0.

1530 - 1600 (0.5h)
1615 - 1720 (1.08h)

Assieme a soujak:
riflessioni sulla praticabilita' di alcuni pensieri fin qui fatti (stima del data rate della STA associanda) e sull'organicita' della soluzione.

Aggiornamento del diario.

05 Luglio 2007

0925 - 1140 (2.25h)

Aggiornamento del diario.

Parziale lettura di 27 (sezione politiche adottate): l'indice RXQ, menzionato da soujak, ivi utilizzato e' in realta' introdotto gia' nel tool airodump-ng. Ne viene proposta un modifica, per soddisfare gli scopi dello studio, che introduce un'instabilita' che, come chiarisce anche l'Autore del documento, e' da ricercare nei pessimi criteri utilizzati per rilevarlo (rimando al documento). Mancano delle considerazioni su cosa in realta' rappresenti questo fattore e a tal proposito mi sorgono dei dubbi sulla qualita' dello stesso, che ricordo esprimere il rapporto tra frame catturati e frame totali (quelli non catturati si rilevano analizzando il sequence number).
In generale, come gia' detto da soujak, manca una qualsivoglia analisi ad alto livello.

1140 - 1215 (0.5h)

Leggendo della documentazione su airodump-ng si esplicita che una variazione di questo parametro, RXQ, puo' essere causata da molteplici fattori. Il grado di raffinatezza che possiamo/vogliamo raggiungere fa si che questo parametro appaia poco interessante.

1300 - 1715 (4.25h)

Assieme a soujak.

06 Luglio 2007

1020 - 1120 (1h)

Lettura di sjk05.

1150 - 1400 (2.16h)
1630 - 1830 (2h)

Assieme a soujak.

07 Luglio 2007

1100 - 1400 (3h)

Assieme a soujak: era Sabato.

09 Luglio 2007

1130 - 1400 (2.5h)

Assieme a soujak: scarabocchi a Matematica.

1620 - 1830 (2.16h)

Assieme a soujak: scarabocchi a Matematica.

10 Luglio 2007

1130 - 1400 (2.5h)

Assieme a soujak.

1600 - 1707 (1.11h)

Profonde riflessioni su una possibile soluzione fondata sulla ripartizione degli accessi partorita insieme a soujak durante la mattinata. Prima formalizzazione degli aspetti piu' rilevanti.

1707 - 1740 (0.55h)

Aggiornamento del diario.

Lettura del diario di wiki:Diario/Roma e wiki:Diario/Zeratul.

1740 - 1835 (0.91h)

11 Luglio 2007

1745 - 1900 (1.25h)

Assieme a soujak.

12 Luglio 2007

1130 - 1300 (1.5h)

Incontro con Roma. Revisione della prima documentazione riguardante il supporto al roaming.

1430 - 1640 (2.16h)

Assieme a soujak.

13 Luglio 2007

1750 - 1850 (1h)

Riflessioni sulla ripartizione degli accessi corredate da qualche appunto in forma cartacea.

14 Luglio 2007

1108 - 1120 (0.20h)

Assieme a soujak.

16 Luglio 2007

1313 - 1430 (1.45h)

1500 - 1715 (2.25h)

1815 - 1845 (0.5h)

Aggiornamento del diario.

17 Luglio 2007

Con soujak.

1235 - 1605 1645 - 1900

18 Luglio 2007

1050 - 1400 1530 - ...

19 Luglio 2007

1020 -

5 Ottobre

1715 - 1945

Incontro con il Prof. Ghini: punto della situazione e sviluppi futuri prima della conclusione.

9 Ottobre

1445 - 1710

Videoconferenza con soujak (video e audio su SIP, desktop su VNC). Ripresa dei lavori: riletture della documentazione prodotta in precedenza, riflessioni, considerazioni sul livello di compiutezza del lavoro, accordi sugli incontri successivi.

10 Ottobre

1500 - 1740

Incontro con soujak.
Considerazioni sulle questioni ancora aperte e sull'eventuale lavoro da svolgere prima della stesura della relazione: si investirà ancora un'oretta per definire meglio il modello matematico. Domande sulla simmetria fra datarate in trasmissione e ricezione. Aggiornamento del diario.

11 Ottobre

1130 - 1330
1345 - 1430

Lavoro con gnappo.
Ulteriori chiarimenti sul concetto di carico:

rilevanza non solo per il calcolo del throughput ottenibile, ma anche (in

qualche modo) per calcolare la latenza del canale, intesa come ritardo introdotto dalla presenza delle varie STA; filosofie sul significato di bandwidth, di troughput e di latenza

formalizzazione precisa e definitiva del carico (pesato) della stazione s:

l_{s}={\frac{w_{s}}{r_{s}}

analisi della possibilità di inserimento nel modello matematico di un

coefficente di attività (da moltiplicare al carico pesato), in grado di descrivere il grado di partecipazione di ogni stazione (rimembranze di conclusioni fatte a Luglio).

1625 - 1850

Con soujak.
Analisi del modello matematico chiarendo il concetto di peso del carico: è la quantità di dati inviati in media da una determinata STA in un giro. Proprio il concetto di "giro", inteso come tempo medio nel quale tutte le STA che hanno voglia di trasmettere ne hanno occasione, è difficilmente calcolabile. Aumentare in questa maniera la complessità del modello rischia, in generale, di allontanarlo dagli obiettivi di stabilità ed affidabilità nel definire un comportamento "di massima" della rete che si sta analizzando. Si è sottolineato anche la versatilità del modello, in grado, grazie all'eventuale presenza di parametri configurabili, di descrivere situazioni diverse dalla realtà: definire casi limite o prevedere l'andamento di certe variabili in gioco.

12 Ottobre

1240 - 1347
1415 - 1530
1640 - 1710
1740 - 2010

Con soujak.
Lavori per la stesura documento di tirocinio: definiti i contenuti del primo terzo del documento.
Aggiornamento parziale del deposito subversion [9].

15 Ottobre

1050 - 1315

Con soujak.
Lavori per la stesura documento di tirocinio: iniziata la sezione relativa al modello matematico.

1550 - 1737

Con soujak.
Lavori per la stesura documento di tirocinio: quasi conclusa la sezione relativa al modello matematico.

16 Ottobre 2007

1108 - 1305

Lavoro con soujak per la stesura della relazione:

paragrafi sui valori ricavabili dal modello matematico;
qualche refactoring nel modello matematico.

1340 - 1346

Aggiornamento del diario (solo locale).

1545 - 1700

Lavoro con soujak per la stesura della relazione:

reperimento sorgente LaTeX smarrito;
paragrafi sui valori ricavabili dal modello matematico;
chiarimenti concettuali qua e là.

1710 - 1740 (0.5h)

Aggiornamento del diario.

2125 - 2320

Documento di tirocinio: finita la sezione relativa al modello matematico, iniziata la parte sulla simulazione.

17 Ottobre 2007

1125 - 1340

Lavoro con soujak per la stesura della relazione:

migliorata e completata l'introduzione al modello matematico;
parziale organizzazione dei contenuti sulla simulazione.

1445 - 1755

Lavoro con soujak per la stesura della relazione:

chiarimenti sui problemi legati alla simulazione;
rilevazione della mancanza di un'importante assunzione sulla tipologia di

rete considerata: single-hop;

ulteriori (quando finiranno?) considerazioni sul concetto di carico: l'AP non

ne genera direttamente e le trasmissioni AP->STA producono carico per la STA; conseguentemente:

il modello matematico aggiungerà al carico della stazione il carico

derivante dalle ricezioni (sotto assunzioni di saturazioni pari ad 1/numero stazioni);

la simulazione inserirò anche il traffico in download (AP->STA). Si terrà

presente che l'AP ha gli stessi diritti delle altre STA nell'aggiudicarsi gli accessi e che ogni STA ha diritto ad almeno 1/n degli accessi in download (riapplicazione del concetto di giro, usando una coda delle trasmissione gia' effettuate dall'AP).

aggiornamento del diario.

18 Ottobre 2007

0925 - 1200

Lavoro con soujak:

aggiornamento del deposito svn [13];
ricerca del Prof. Ghini, spedizione email, accordi per appuntamento.
individuazione delle prossime attività;
~~chiacchiere sulla conclusione del tirocinio e altro~~

1500 - 1615

Incontro assieme a soujak col Prof. Ghini sulla possibilità di conclusione abbreviata dei lavori: esito negativo;

1635 - 1905

Lavoro con soujak:

aumento della motivazione di soujak (3 minuti);
programmazione e valutazione carichi delle prossime attività;
adeguamento della definizione di carico per il modello matematico.

19 Ottobre 2007

0955 - 1340

Lavoro con soujak:

rilevazione della necessità di meglio definire il concetto di latenza:

analisi del problema;

discussioni sulla gestione del progetto;
revisione del concetto di latenza definendo adeguatamente la "downlink

latency" e la "uplink latency";

1600 - 1838

Lavoro con soujak:

ridefinizione della latenza;
revisione della formalizzazione del carico;
scelta di un formalismo adeguato per la presentazione del modello matematico.

22 Ottobre 2007

1000 - 1145
1230 - 1345

Lavoro con soujak:

pianificazione attività della giornata;
inizio della stesura della sezione dedicata alla simulazione;
aggiornamento locale del diario.

1545 - 1832

Lavoro con soujak sulla sezione dedicata alla simulazione:

aggiunta di necessari fondamenti teorici;
introduzione all'algoritmo (non conclusa).

Aggiornamento locale del diario.

23 Ottobre 2007

0955 - 1005

Aggiornamento del diario e del deposito subversion [15].

1005 - 1400

Lavoro con soujak sulla sezione dedicata alla simulazione:

riorganizzazione dei contenuti necessari all'esposizione dell'algoritmo;
partizione concettuale dell'algoritmo;
revisione e formattazione LaTeX della prima fase dell'algoritmo (una disputa

ha allungato i tempi);

1515 - 1700

Lavoro con soujak sulla sezione dedicata alla simulazione:

revisione e formattazione LaTeX della seconda fase dell'algoritmo;
revisione della terza fase dell'algoritmo.

1710 - 1825

Con soujak.
Lavoro sulla sezione dedicata alla simulazione per la formattazione della terza fase dell'algoritmo.

24 Ottobre 2007

0950 - 1100
1150 - 1250
1430 - 1846

Lavoro con soujak sulla sezione dedicata alla simulazione: rilettura, correzione, formalizzazione e formattazione dell'algoritmo.

25 Ottobre 2007

1030 - 1810

Lavoro con soujak sulla sezione dedicata alla simulazione:

rilettura e correzione definitive dell'algoritmo;
ulteriori ed definizioni e interessanti conclusioni teoriche relative al

modello di rete necessario al simulatore;

aggiornamento locale del diario.

26 Ottobre 2007

1030 - 1240

Discussioni sulla gestione dei lavori futuri con soujak, accenni alla futura organizzazione.

29 Ottobre 2007

1100 - 1322

Con soujak:

punto della situazione sull'avanzamento dei lavori;
discussione e scelta delle metodologie di lavoro: inizio parallelismo;
discussione e scelta e degli strumenti d'ausilio: uso di soli sorgenti TeX,

meglio gestibili dai software di versionamento;

definizione prossime attività da svolgere;
decisione monte ore settimanale: circa 15.

1500 - 1605

Aggiunta documento ToDo al deposito subversion [18].

Preconfigurazione di un profilo di unison per la sincronizzazione diretta SoujaK <-> gnappo.

1607 - 1740

Considerazioni sulle trasmissioni AP -> STA.

L'AP e' saturo, in trasmissione, sse e' presente in ogni epoca (deriva dalle assunzioni di equita' del mezzo). Una stazione e' satura in download se l'AP ha sempre qualcosa in coda da consegnarle.

Di conseguenza se la stazione associanda e' satura in ricezione, l'AP lo e' in trasmissione e quindi sara' presente in ogni epoca.

E' necessario capire la dinamica della sua coda di trasmissione per poter simulare gli accessi dell'AP. Purtroppo nell'introduzione di [http://twelve.dit.unitn.it/docs/PI-6.pdf "Providing Air-time Usage Fairness in IEEE 802.11 Networks with the Deﬁcit Transmission Time (DTT) Scheduler"] si

16 Ottobre 2007

1108 - 1305

Lavoro con soujak per la stesura della relazione:

paragrafi sui valori ricavabili dal modello matematico;
qualche refactoring nel modello matematico.

1545 - 1700

Lavoro con soujak per la stesura della relazione:

reperimento sorgente LaTeX smarrito;
paragrafi sui valori ricavabili dal modello matematico;
chiarimenti concettuali qua e là.

2125 - 2315

Lavoro con soujak per la stesura della relazione:

conclusa la sezione sul modello matematico;
iniziata la sezione sul simulatore (necessita di qualche riorganizzazione dei contenuti).

17 Ottobre 2007

1125 - 1340

Lavoro con soujak per la stesura della relazione:

migliorata e completata l'introduzione al modello matematico;
parziale organizzazione dei contenuti sulla simulazione.

1445 - 1755

Lavoro con soujak per la stesura della relazione:

chiarimenti sui problemi legati alla simulazione;
rilevazione della mancanza di un'importante assunzione sulla tipologia di rete considerata: single-hop;
ulteriori (quando finiranno?) considerazioni sul concetto di carico: l'AP non ne genera direttamente e le trasmissioni AP->STA producono carico per la STA; conseguentemente:
- il modello matematico aggiungerà al carico della stazione il carico derivante dalle ricezioni (sotto assunzioni di saturazioni pari ad 1/numero stazioni);
- la simulazione inserirò anche il traffico in download (AP->STA). Si terrà presente che l'AP ha gli stessi diritti delle altre STA nell'aggiudicarsi gli accessi e che ogni STA ha diritto ad almeno 1/n degli accessi in download (riapplicazione del concetto di giro, usando una coda delle trasmissione gia' effettuate dall'AP).
aggiornamento del diario.

18 Ottobre 2007

0925 - 1200

Lavoro con soujak:

aggiornamento del deposito svn [13];
ricerca del Prof. Ghini, spedizione email, accordi per appuntamento.
individuazione delle prossime attività;
~~chiacchiere sulla conclusione del tirocinio e altro~~

1500 - 1615

Incontro assieme a soujak col Prof. Ghini sulla possibilità di conclusione abbreviata dei lavori: esito negativo;

1635 - 1905

Lavoro con soujak:

aumento della motivazione di soujak (3 minuti);
programmazione e valutazione carichi delle prossime attività;
adeguamento della definizione di carico per il modello matematico.

19 Ottobre 2007

0955 - 1340

Lavoro con soujak:

rilevazione della necessità di meglio definire il concetto di latenza: analisi del problema;
discussioni sulla gestione del progetto;
revisione del concetto di latenza definendo adeguatamente la "downlink latency" e la "uplink latency";

1600 - 1838

Lavoro con soujak:

ridefinizione della latenza;
revisione della formalizzazione del carico;
scelta di un formalismo adeguato per la presentazione del modello matematico.

22 Ottobre 2007

1000 - 1145
1230 - 1345

Lavoro con soujak:

pianificazione attività della giornata;
inizio della stesura della sezione dedicata alla simulazione;
aggiornamento locale del diario.

1545 - 1832

Lavoro con soujak sulla sezione dedicata alla simulazione:

aggiunta di necessari fondamenti teorici;
introduzione all'algoritmo (non conclusa).

Aggiornamento locale del diario.

23 Ottobre 2007

0955 - 1005

Aggiornamento del diario e del deposito subversion [15].

1005 - 1400

Lavoro con soujak sulla sezione dedicata alla simulazione:

riorganizzazione dei contenuti necessari all'esposizione dell'algoritmo;
partizione concettuale dell'algoritmo;
revisione e formattazione LaTeX della prima fase dell'algoritmo (una disputa ha allungato i tempi);

1515 - 1700

Lavoro con soujak sulla sezione dedicata alla simulazione:

revisione e formattazione LaTeX della seconda fase dell'algoritmo;
revisione della terza fase dell'algoritmo.

1710 - 1825

Con soujak.
Lavoro sulla sezione dedicata alla simulazione per la formattazione della terza fase dell'algoritmo.

24 Ottobre 2007

0950 - 1100
1150 - 1250
1430 - 1846

Lavoro con soujak sulla sezione dedicata alla simulazione: rilettura, correzione, formalizzazione e formattazione dell'algoritmo.

25 Ottobre 2007

1030 - 1810

Lavoro con soujak sulla sezione dedicata alla simulazione:

rilettura e correzione definitive dell'algoritmo;
ulteriori ed definizioni e interessanti conclusioni teoriche relative al modello di rete necessario al simulatore;
aggiornamento locale del diario.

26 Ottobre 2007

1030 - 1240

Discussioni sulla gestione dei lavori futuri con soujak, accenni alla futura organizzazione.

29 Ottobre 2007

1100 - 1322

Con soujak:

punto della situazione sull'avanzamento dei lavori;
discussione e scelta delle metodologie di lavoro: inizio parallelismo;
discussione e scelta e degli strumenti d'ausilio: uso di soli sorgenti TeX, meglio gestibili dai software di versionamento;
definizione prossime attività da svolgere;
decisione monte ore settimanale: circa 15.

1500 - 1605

Aggiunta documento ToDo al deposito subversion [18].

Preconfigurazione di un profilo di unison per la sincronizzazione diretta SoujaK <-> gnappo.

1607 - 1740

Considerazioni sulle trasmissioni AP -> STA.

L'AP e' saturo, in trasmissione, sse e' presente in ogni epoca (deriva dalle assunzioni di equita' del mezzo). Una stazione e' satura in download se l'AP ha sempre qualcosa in coda da consegnarle.

Di conseguenza se la stazione associanda e' satura in ricezione, l'AP lo e' in trasmissione e quindi sara' presente in ogni epoca.

1740-1800

Con soujak: condivisione reciproca sugli sviluppi dei lavori.

Aggiornamento del diario e del deposito subversion [19].

30 Ottobre 2007

1415 - 1515

Con soujak:

punto della situazione;
chiacchiere con Bononi;
schedulazione attività.

1610 - 1655

Considerazioni sull'algoritmo di simulazione comprendente anche le trasmissioni AP -> STA. Riflessioni sulla possibilità di agire in analogia con quanto avviene già con le trasmissioni.

1655 - 1800

Con soujak: discussioni sulle modalità di riorganizzazione dei contenuti della porzione di relazione dedicata alla modellazione teorica, in particolare sulla possibilità di inserimento di un coefficiente d'attività delle stazioni.

31 Ottobre 2007

1600 - 1740

Incontro con prof. Ghini:

condivisione delle conoscenze;
chiarimento sviluppi in ambito tesi.

1821 - 1854

Con soujak:

aggiornamento locale del diario;
discussioni sull'organicità e chiarezza sia attuali che future;
riflessioni sul modello teorico, in particolare sul coefficiente di attività.

02 Novembre 2007

0958 - 1037

Aggiornamento locale del diario.

1043 - 1445

Con soujak.
Individuazione delle relazioni che intercorrono tra i concetti principali presenti nello studio.
Riflessioni sul carico:

chiarimenti sulla sua relazione con il concetto di epoca;
caratterizzazione del carico di una stazione: considerazioni sulla natura del coefficiente di attività: dipende sia dalla necessità trasmissiva della stazione, sia dalla presenza delle altre stazioni.

Tentativi di soluzione al problema della determinazione del carico di un BSS senza l'utilizzo di tecniche round-robin.

1547 - 1600

Aggiornamento locale del diario.

1640 - 1900

Con soujak.
Prima riorganizzazione, cartacea, dei concetti. Diverrà lo schema di relazione.

05 Novembre 2007

1515 - 1815

Con soujak.
Digitalizzazione e raffinamento dello schema elaborato in forma cartacea.

06 Novembre 2007

1020 - 1025

Aggiornamento locale del diario.

1030 - 1345

Riflessioni sul concetto di carico e sul suo impiego all'interno dello studio. Adeguamento dello schema alla luce delle considerazioni fatte.

1345 - 1400

Sincronizzazione parziale con il diario online. Aggiornamento, locale, del diario.

1525 -

08 Novembre 2007

1046 - 1415

1500 - 1850

13 Novembre 2007

1110 - 1338

1500 - 1730

Prima stesura dell'algoritmo. Chiarimenti con soujak riguardo l'algoritmo.

14 Novembre 2007

0930 - 1426

Miglioramento in termini di chiarezza dell'algoritmo di simulazione (solo trasmissioni): ora vi sono solo due fasi ben distinte: costruzione dell'epoca e schedulazione della stessa.

Alcuni pensieri sulle modalità implementative dell'aggiunta delle trasmissioni AP -> STA.

Alcuni chiacchere con soujak riguardo la modellizzazione.

1650 - 1846

Formalizzazione, su carta, di una bozza di algoritmo che consideri trasmissioni AP -> STA

16 Novembre 2007

0920 - 1345

Prima stesura dell'algoritmo comprendente anche le trasmissioni AP -> STA. Alcuni chiarimenti con soujak riguardo la modellizzazione e condivisione di parte dell'algoritmo di simulazione.

1505 - 1815

Ottimizzazione dell'algoritmo:

la schedulazione in output avviene contemporaneamente alla costruzione dell'epoca;
migliorata la coerenza tra epoca e periodo.

19 Novembre 2007

0905 - 0937

Aggiornamento sia locale che remoto del diario.

0948 - 1315

Chiarimenti con soujak riguardo equità del mezzo, epoca e saturazione.

1400 - 1843

Con soujak.
Formalizzazione della tesi di equità del mezzo in termini di epoca. Conseguenti abbozzi di dimostrazione per partecipazione generalizzata.

20 Novembre 2007

1750 - 1910

Aggiornamento locale del diario.
Inizo digitalizzazione e correzione di alcuni errori dell'algoritmo elaborato il 16 Novembre.

21 Novembre 2007

0930 - 1040
1100 - 1140

Aggiornamento locale del diario.
Digitalizzazione dell'algoritmo.

1210 - 1850

Con soujak.
Breve condivisione dell'algoritmo.
Riflessioni sulla tesi di equità (locale) del mezzo utilizzata fino ad ora: pare essere troppo stretta.
Alcuni pensieri sulla tesi di equità basata unicamente sulle epoche.

22 Novembre 2007

1700 - 1845

Alcune riflessioni e letture (Bianchi ed altri) sull'equità di DCF.

23 Novembre 2007

0935 - 0945

Aggiornamento locale del diario.

Documenti

02 On Access Point Selection in IEEE 802.11 Wireless Local Area Networks
03 Improved Access Point Selection
05 SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks
06 "Decentralized Access Point Selection Architecture for Wireless LANs
07 Energy Efficient PCF Operation of IEEE 802.11a Wireless LAN
09 An Optimized Load-Balancing Algorithm for Infrastructure Based Short-Range Wireless Networks
11 Client Channel Selection for Optimal Capacity in IEEE 802.11 Wireless Networks
12 Scalable and Robust WLAN Connectivity Using Access Point Array
13 "MiFi: A Framework for Fairness and QoS Assurance for Current IEEE 802.11 Networks With Multiple Access Points"
14 "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process"
15 Techniques to Reduce IEEE 802.11b MAC Layer Handover Time
16 A Study on Dynamic Load Balance for IEEE 802.11b Wireless LAN
17 Performance Anomaly of 802.11b
18 IEEE 802.11e Wireless LAN for Quality of Service
19 Characterizing User Behavior and Network Performance in a Public Wireless LAN
20 New Insights from a Fixed Point Analysis of Single Cell IEEE 802.11 WLANs
21 IEEE 802.11 Rate Control Algorithms: Experimentation and Performance Evaluation in Infrastructure Mode
22 IEEE 802.11 Rate Adaptation: A Practical Approach
23 Bit-rate Selection in Wireless Networks
24 Scalability Analysis of Rate Adaptation Techniques in Congested IEEE 802.11 Networks: An ORBIT Testbed Comparative Study
25 CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs
26 Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength Measurement

Download in other formats:

Plain Text