[[PageOutline]]
= Diario di SoujaK =

== 4 Giugno 2007 ==
(2.00h)[[BR]]
Strumenti di lavoro su XT3: creazione del gruppo e dell'alias 'tirocinio07', inizializzazione dell'ambiente Trac e del repository Subversion.

== 5 Giugno 2007 ==
(1.00h)[[BR]]
Strumenti di lavoro su XT3: messa a punto dell'autenticazione sul server web.

== 11 Giugno 2007 ==
(0.40h)[[BR]]
Sincronizzazione del diario della settimana scorsa, inizializzazione della pagina wiki della Milestone di rilevamento del carico.

__1400-1740__[[BR]]
00: l'articolo propone l'identificazione di una bandwidth potenziale ottenibile da un determinato AP a partire dalle condizioni di carico che un client è in grado di rilevare in esso.
Lo studio prende in considerazione uno scenario privo di disturbi ambientali, senza coordinamento centralizzato.
Assumendo che i frame beacon non abbiano priorità sugli altri, è possibile stimare il tempo medio di attesa di trasmissione osservando il ritardo dei frame beacon (si ricordi la presenza del "Beacon Interval" e del "Target Beacon Transmission Time").
Inoltre fornisce spunti perché una stazione possa inferire una probabilità di perdita di trasmissioni, sfruttando i numeri di sequenza ("Sequence number") dei frame che cattura e il "Retry Bit".
La veridicità delle conclusioni dipende dalla veridicità delle assunzioni poste e dalla generalità dell'hardware utilizzato per le sperimentazioni effettuate.

__1800-1820__[[BR]]
__1900-1920__[[BR]]
01: La selezione ottimale dell'Access Point è strettamente legata a politiche di allocazione del traffico in grado di gestire in maniera ottimizzata le risorse disponibili. Il problema viene affrontato da un punto di vista piuttosto teorico, oltre che distante dai nostri scopi, rendendolo quasi per nulla interessante.

__1920-2000__[[BR]]
__0910-0930__[[BR]]
02: L'articolo propone parametri concreti per la valutazione della bontà degli AP, che prevede essere calcolati direttamente dal loro ''firmware''(testato con IPW 2915) e periodicamente comunicati alle STA tramite i ''frame beacon''. Nonostante la forte dipendenza da modifiche ai ''firmware'' presumo che i calcoli dei parametri, di davvero grande rilevanza, effettuati dagli AP possano essere eseguiti anche lato ''client''.

== 12 Giugno 2007 ==
__1000-1020__ (0.33h)[[BR]]
Sincronizzazione del diario.

__1030-1100__ (0.50h)[[BR]]
Punto della situazione assieme a gnappo.

__1120-1155__ (0.58h)[[BR]]
03: In appendice è presente un'interessante calcolo dell'impatto degli errori di trasmissione sulle prestazioni, calcolando diligentemente i dettagli relativi ai backoff incrementali.

__1210-1310__ (1.00h)[[BR]]
04: Lo studio effettua una stima dell'effettiva ''bandwitdth'' disponibile, in base al tempo che intercorre fra la richiesta di invio del frame e la notifica di avvenuta trasmissione.
In questo calcolo vengono a sommarsi i tempi di attesa per l'accesso al mezzo (rilevazione di mezzo disponibile e successiva contesa), la procedura RTS/CTS, l'effettiva trasmissione dei dati e del'ACK, IFS relativi.
Questa ''bandwidth'' e` fortemente influenzata dalla dimensione dei ''frame'' e viene quindi normalizzata rispetto ad un frame di riferimento per avere una misura da essa indipendente.
Lo studio proseguirebbe su politiche di ammissione di una STA in un BSS, formalizzando il concetto di proporzione del tempo del canale (CTP, ''Channel Time Proportion'') di un determinato flusso dati, ottenibile dal rapporto fra la ''bandwitdth'' direttamente richiesta dal flusso e la ''bandwitdth'' disponibile appena citata.
I concetti appena descritti appaiono come spunti piuttosto rilevanti ai nostri fini.

__1450-1617__ (0.45h)[[BR]]
Ricerche ulteriori.

__1650-1720__ (0.33h)[[BR]]
05: L'articolo propone una algoritmo di controllo della associazione (lato client) che si configura come erede degli algoritmi precedentemente proposti da altri studi.

== 13 Giugno 2007 ==
__0900-0910__ (0.16h)[[BR]]
Approfondimento di 04.

__1000-1025__ (0.41h)[[BR]]
Sincronizzazione del diario.

__1025-1140__ (1.25h)[[BR]]
05: Lo studio ha come fine l'ottimizzazione delle risorse, intese in senso globale e propone un algoritmo per la gestione delle associazioni basato sul rilevamento del carico degli AP.
Il concetto di carico totale di un AP viene definito come la somma dei carichi di ogni singolo client, i.e. il tempo che un AP impiega a fornire ad ognuno degli utenti una unità di traffico.
Questa definizione, in realtà scopiazzata da 06, viene successivamente arriccchita, definendola piuttosto come sommatoria degli inversi dei tassi di trasmissione di ogni client associato ad un determinato AP.
In pratica si calcola il tempo necessario affinché ognuna delle stazioni associate con l'AP in questione trasmettano una unità di dati, supponendo che esse abbiano sempre dati in attesa di invio.
Così facendo si definisce il concetto di tasso di trasmissione ottenibile (''attainable data rate''), parametro fondamentale per l'algoritmo di associazione che viene proposto.

__1220-1330__[[BR]]
~~Amministrazione su argon.~~


__1500-1520__ (0.33h)[[BR]]
Punto della situazione con gnappo.

__1520-1605__ (0.75h)[[BR]]
05: L'algoritmo per il controllo dell'associazione che viene proposto tiene conto della presenza di congestioni, dal momento che il massimo tasso trasmissivo ottenibile non può che essere influenzato da questa eventualità.
Propone inoltre che il client effettui rilevazioni sui carichi degli AP disponibili non solo nei momenti di necessità (non ancora associato), ma anche a intervalli regolari (già associato) per individuare alternative sempre migliori.
Questo tipo di approccio risulta quantomai interessante nella prospettiva di avere a disposizione, come nel nostro caso, una molteplicità di dispositivi 802.11 su ogni singola STA.

__1605-1715__ (1.16h))[[BR]]
06: Lo studio si propone quantomeno come la fondazione teorica di una politica di allocazione delle risorse equa min-max (''min-max fairness'') e bilanciata che intende essere la più vicina all'ottimo (perché il problema sarebbe NP-hard).
Per equità max-min si intende una situazione nella quale non vi è modo per fornire ''bandwidth'' addizionale ad un client senza doverne togliere almeno altrettanta a qualche altro.
Lo studio formalizza in maniera rigorosa il concetto di carico di un AP.

== 14 Giugno 2007 ==

__1110-1235__ (1.41h)[[BR]]
06: La definizione di equità max-min è stata approfondita in tutta la sua complessità che la definizione formale esprime, facendo emergere spunti utili non alla [milestone:"Rilevamento del carico" milestone attuale] ma a possibili politiche di bilanciamento del carico, eventualmente rilevanti per la scelta dell'AP a cui associarsi.

__1300-1330__ (0.50h)[[BR]]
06: La definizione di carico che l'articolo propone è allineata al resto dalla letteratura informatica.
Informalmente il carico dell'AP ''a'' indotto da una STA ''s'' è l'inverso del ''bitrate'' effettivo che ''s'' rileva, normalizzato rispetto allo specifico peso della STA.
Il carico di ''a'' è poi il massimo fra le due sommatorie di tutti i carichi indotti da tutte le associazioni effettive (che, cioé, producono un ''bitrate'' non nullo), la prima sui ''bitrate'' dei collegamenti AP-STA, la seconda sui ''bitrate'' del collegamento AP-!ReteEsterna.

__1330-1347__ (0.28h) [[BR]]
Aggiornamenti su Trac: scritta la descrizione della [milestone:"Rilevamento del carico" milestone] e gli appunti sul lavoro della mattinata.

__1420-1511__ (0.88h)[[BR]]
06: Lo studio spende energie non indifferenti (considera infatti anche situazioni che tengano presente il carico su un insieme di AP) per dimostrare con rigore teoremi e proprietà che sono indispensabili alla dimostrazione dello stretto legame che intercorre fra una scelta di associazioni bilanciate min-max e una scelta di allocazione della ''bandwidth'' che sia equa max-min.
Quest'ultimo teorema, oltre che essere sprovvisto di una dimostrazione completa, è non soddisfatto nel caso di associazioni singole.
[[BR]]
L'articolo prosegue per strade che mi sono parse allontanarsi sempre più dai nostri interessi, ma tengo a sottolineare i risultati che gli autori hanno ottenuto durante una simulazione di confronto fra le più note politiche di gestione dell'associazione.
Lo schema proposto non solo supera di un 20% il ''throughput'' del metodo SSF (''Strongest Signal First''), intuitivamente lontano dall'ottimo, ma arriva al __triplo__ di quello di LLF (''Least Loaded First'')!
Terrei quindi presente la possibiltà di riprendere in mano il documento per comprendere meglio l'algoritmo di bilanciamento (che, spaventato dalla complessità, non ho analizzato) o per mettere in dubbio l'attendibilità dei risultati delle simulazioni.

__1511-1519__ (0.13h)[[BR]]
Sincronizzazione del diario.

__1519-1600__ (0.68h)[[BR]]
Ricerca e cernita di altri documenti: si aggiungono alla lista 07, 08, 09.[[BR]]

__1620-1800__ (1.67h)[[BR]]
07: L'articolo riprende i concetti formali di 06 per elaborare una strategia ottimale per gestire le associazioni fra stazioni e i punti di accesso, astraendo completamente dalle possibili implementazioni e dai relativi problemi (reperimento delle informazioni, localizzazione del gestore ...).
[[BR]]
08: L'articolo propone un algoritmo dinamico di bilanciamento di carico che si fonda, a differenza di tutti gli altri studi finora analizzati, proprio sul valore di RSSI.
Il problema viene definito informalmente come l'individuazione di uno schema di associazioni tali che l'RSSI medio sia massimizzato e le variazioni nel RSSI medio di ogni AP e nel numero di STA associate ad ogni AP siano minimizzate.
Dal momento che si propongono cambiamenti al comportamento degli AP, questo studio resta interessante per la sua originalità nei parametri considerati nella gestione delle associazioni.
[[BR]]
Una riflessione che mi sorge spontanea è sul legame che intercorre fra l'RSSI di una STA presso un  AP e la banda effettivamente resa disponibile al medesimo AP. Credo che solo sviscerando questa relazione ci sarà possibile individuare dei parametri di valutazione che siano un buon compromesso fra effittività e non-invasività.
[[BR]]
09: Lo studio propone una strategia di bilanciamento del carico implementata a livello di AP, tramite frequenti comunicazioni fra di essi attraverso una dorsale Ethernet che si suppone li colleghi.
Al di là della specificità delle ipotesi, ciò che colgo come interessante è il fatto che anche qui si sia scelto come metrica del carico degli AP il ''throughput'' (invece del numero di utenti, G. Bianchi, I. Tinnirello, "Kalman Filter Estimation of the Number of Cometing Terminals in an IEEE 802.11 Network", o della quantità di traffico, G. Bianchi, I. Tinnirello, "Improving Load Balancing mechanisms in Wireless Packet Networks").

== 16 giugno 2007 ==

__1250-1411__ (1.35h) [[BR]]
Revisione, formalizzazione e stesura dei pensieri di ieri.
Prescindendo dalle modalità con le quali questo parametro venga valutato nella effettiva scelta di associazione (sto pensando a politiche di bilanciamento del
carico in maniera equa), il carico del BSS rimane l'oggetto del[milestone:"Bilanciamento del carico" la milestone di cui mi occupo].
La definizione che più mi è parsa corretta e indicativa è quella contenuta in 05 e 06: il carico è inversamente proporzionale al ''datarate''.
Purtroppo però questa informazione non è direttamente disponibile a meno che non si prendano in considerazione BSS che aderiscano a 802.11e (peraltro non ancora analizzato né da me, né da [wiki:Diario/Gnappo gnappo]) o a meno che non si effettuino dei test effettivi di comunicazione, rinunciando molto probabilmente alla scalabilità che si intravede fra gli obiettivi della soluzione ricercata.
Ciò detto risulta evidente la necessità di andare a ricercare elementi che siano calcolabili da ogni STA grazie ad azioni di sniffing sui vari canali per poi andare a calcolare una stima del ''datarate'' (e quindi del carico).
L'adeguatezza di questi fattori e dei calcoli che conducono alla stima può essere verificata per via sperimentale con uno sforzo che rimane considerevole.

Riporto quindi di seguito un elenco di tutte quelle pratiche che risultano
essere interessanti.
 * Misurazione del tempo di accodamento dei ''beacon'' da parte dell'AP (00).
 * Calcolo dell' ''error rate'' delle trasmissioni su un determinato canale (00).
 * Misurazione del ''throughput'' medio della STA associate all'AP che si sta analizzando.
 * ''Bit-rate'' nominale delle STA associate all'AP che si sta analizzando.
 * Misurazione del ''datarate'' effettivo tramite invii diretti (ed invasivi).
 * Reperimento di informazioni dai campi aggiuntivi di 802.11e.

__1411-1512__ (1.01h)[[BR]]
Punto della situazione con gnappo: aggiornamenti, chiarimenti e sviluppi futuri.

__1700-1800__ (1.00h) [[BR]]
Ricerca di ulteriore documentazione e suddivisione dei nuovi documenti.

== 19 Giugno 2007 ==

__1230-1300__ (0.50h)[[BR]]
Individuazione e sistemazione errori nei permessi del portale Trac.

__1300-1336__ (0.60h)[[BR]]
Punto della situazione e inizio lettura di 10.

__2010-2030__ (0.33h)[[BR]]
Sincronizzazione del diario.

== 20 Giugno 2007 ==

10: Si propone un modello matematico semplice ma accurato (e per questo così utilizzato) che permette di calcolare il ''throghput'' in una rete 802.11 saturata (nella quale, cioé le code di invio di ogni STA siano sempre non vuote).
Partendo da un modello probabilistico che rappresenta la gestione dei periodi di ''backoff'' si procede per via analitica andando a ricavare il ''throughput'' massimo.
Dato l'alto grado difficoltà del documento non mi è chiaro se il fine del documento risiede nel modello stesso o se esso sia strumento per calcoli realmente utili.
A patto che le informazioni di partenza siano ricavabili o stimabili dall'ascolto sul canale, mi azzardo a dire che questo modello non sia così distante dai nostri obiettivi.
Una serie di simulazioni sperimentali confermano validità del modello proposto e mettono in luce come le prestazioni dipendano in misura tutt'altro che marginale dalle impostazioni della rete, in particolare dall'ampiezza iniziale della finestra di contesa (`CWmin`).

In aggiunta a questo non mi sono ben definite nemmeno le informazioni iniziali da cui il ''throughput'' sia ricavabile.

Lettura di 11 e 12: appunti cartacei.

== 21 Giugno 2007 ==
__0905-0925__ [[BR]]
11: L'articolo propone 2 nuove metriche per la valutazione del carico a fini di bilanciamento di generiche reti wireless a pacchetti che siano gestite da coordinatori centrali quali bluetooth, UMTS o l'amato IEEE 802.11 (nella sua variante con PCF).
La prima, chiamata ''Gross Load'' intende calcolare il numero medio di trasmissioni in una cella in un dato periodi di tempo; la seconda, chiamata ''Packet Loss'' stima invece le ''performance'' a partire dal carico di ogni pacchetto, ricavato dalle probabilità di perdite di trasmissioni.
[[BR]]
12: Lo studio mira ad esprimere il numero ''n'' di stazioni concorrenti presenti in una rete 802.11 in regime DCF come funzione della probabilità di collisione.
Il fine è quello di riuscire a stimare ''n'' per poter adeguare intelligentemente il parametro `RTS-Treshold` per massimizzare le prestazioni.

__1002-1337__ [[BR]]
Punto della situazione e analisi sviluppi futuri assieme a gnappo: stesura di una lista delle informazioni elementari che potranno essere alla base delle metriche di valutazione legate al carico degli AP.

__1500-1640__ [[BR]]
Meeting dell'intera squadra: condivisione delle conoscenze fra i due gruppi di lavoro e revitalizzazione degli obiettivi legati alla milestone:"Roaming".

__1720-1735__ [[BR]]
Condivisione conoscenze con gnappo riguardo lo studio di Bianchi (10).

__1929-2002__ [[BR]]
Rilettura di 02 con l'individuazione di alcune sezioni interessanti.

== 22 Giugno 2007 ==

__1021-1055__ [[BR]]
02: Come [wiki:"Diario/SoujaK#a11Giugno2007" precedentemente] accennato il documento propone una serie di metriche per la valutazione della qualità degli AP: anzitutto, nonostante si palesi ancora una volta l'insufficienza del solo RSSI, il parametro rientra fra i parametri considerati a causa della sua grande rilevanza.
''In secundis''propone una metrica che trovo significativa: il ritardo di trasmissione aggregaato, cioé il tempo medio che intercorre fra l'accodamento di un pacchetto e la ricezione della conferma di trasmissione a livello MAC (si suppone che sia il ''driver'' a ricevere periodicamente questa informazione direttamente dal ''firmware'').
In questo modo questa misura del ritardo tiene in considerazione non solo il tasso trasmissivo nominale utilizzato per la trasmissione, ma anche i ritardi dovuti a collisioni ed errori.

__1140-1248__[[BR]]
Sincronizzazione degli ultimi tre giorni di diario.

__1250-1320__[[BR]]
Installazione locale di KDissert.

== 25 Giugno 2007 ==
__1023-1350__ [[BR]]
Punto della situazione con gnappo: confronto, chiarimento e decisione della
prima sostanziosa parte della soluzione.

__1501-1610__ [[BR]]
Lavoro con gnappo: formalizzazione della soluzione della mattinata (e della
precedente settimana) e in generale delle idee che la riguardano.

__1610-1813__ [[BR]]
Ancora con gnappo: sviluppi futuri riguardo la presenza della STA all'interno
dello scenario finora considerato.

__1955-2020__ [[BR]]
Rilettura dei documenti {06, 07, 09} alla luce della distinzione fra gli obiettivi di individuazione del throughput ottenibile e di bilanciamento del carico.
Nell'eventualità di una milestone dedicata a politiche di bilanciamento, mi pare che tutte le considerazioni finora fatte per definire una stima della bandwidth ottenibile siano riutilizzabili, dal momento che passano per una stima del carico dei BSS.

== 26 Giugno 2007 ==
__1005-1035__[[BR]]
Rilettura del [wiki:Diario/Gnappo diario di gnappo] e della seconda mezza dozzina dei miei documenti alla ricerca di nuovi spunti.
Sorge una domanda ancora non presa in considerazione: quanto sono le conclusioni sinora tratte dipendenti dalla presenza del solo DCF?[[BR]]
Viaggi mentali su una modalità lasca per innescare il cambio di BSS (secondo i parametri di valutazione in oggetto del presente studio) al fine di scongiurare un eterno e continuo ''handoff''.

__1114-1126__[[BR]]
Aggiornamento e sincronizzazione del diario.

__1126-1400__ __1600-1654__ [[BR]]
Con gnappo:
 * caricamento della [source:CaricoBSS/caricobss.kdi 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 [source:CaricoBSS/caricobss.kdi mappa mentale];
 * stesura del diario della giornata.

== 27 Giugno 2007 ==

__1320-1510__ [[BR]]
Con gnappo: affinamento del modello teorico approfondendo le cause di calo prestazionale in termini di throughput rispetto ai valori nominali (ritrasmissioni e attese di backoff), individuandone successivamente fonti per la loro stima.

__1820-2000__ [[BR]]
Incontro con il professor Ghini: chiarimento di alcuni dettagli riguardo lo scenario d'opera.

== 28 Giugno 2007 ==
__1120-1240__[[BR]]
Meeting squadra: condivisione delle conoscenze (in particolar modo riguardanti la milestone:"Rilevamento del carico"), consigli e suggerimenti utili al proseguimento della milestone:Roaming, chiarimenti riguardo gli sviluppi futuri dell'intero tirocinio e i relativi tempi.

__1740-1811__ [[BR]]
Con gnappo: chiarimenti riguardo le prossime raffinazioni del modello teorico.

__1958-2020__[[BR]]
Appunti nella mappa mentale sulle ultime parole scambiate con gnappo, per timore di dimenticare.

== 29 Giugno 2007 ==
__1430-1500__[[BR]]
Rilettura di (e riflessioni su) alcuni documenti, in particolare 06, 07, 09.

__1620-1835__[[BR]]
Aggiornamento del diario.[[BR]]
Con gnappo: analisi del nodo ancora da sciogliere (determinazione accurata del throughput teorico delle STA già associate).
Lettura accurata delle parti ancora poco chiare di gnp02, qualche questione rimane insoluta.
Conseguente individuazione dei nuovi obiettivi a breve termine (#1, #2, #3).
Breve indagine riguardo il significato di RSSI e SNR (#2).[[BR]]
Apertura dei ticket e aggiornamento del diario.

== 30 Giugno 2007 ==
__1316-1340__[[BR]]
Rapida occhiata alla tesi di Benatti e Borsari (Ghn00).

== 2 Luglio 2007 ==
__1830-1940__[[BR]]
Ghn00: la sezione riguardante le politiche di valutazione della qualità dei BSS mette in luce un approccio quantomai approssimativo e pragmatico al calcolo del punteggio di qualità, apparentemente senza alcuna base teorica.
Un primo particolare interessante, seppur marginalmente, è che gli autori, consci della grande portabilità a cui mira il progetto MEW (Ghn01), tengono in considerazione la possibilità di utilizzare dispositivi sprovvisti della modalità monitor, adottando in quel caso una politica differente.[[BR]]
Una altra questione sollevata dagli autori che vale la pena menzionare è l'instabilità di uno dei parametri da loro utlizzati, RXQ.
Si tratta dell'indice più importante utilizzato per le valutazioni eseguite con il supporto del ''monitor mode'' ed è il rapporto fra il numero dei frame catturati e il numero dei frame transitati sul canale (frame catturati + frame persi).
Questo valore, la cui accuratezza ci si aspetterebbe essere direttamente proporzionale rispetto al tempo di ascolto sul canale, risulta invece essere parecchio instabile per cause che mi sono ancora ignote.
Dal momento che un simile calcolo dei frame transitati è alla base del calcolo del ''throughput'' effettivo che intendiamo effetuare, mi occuperò quanto prima di ricercare le motivazioni di questa anomalia.

__2144-2208__[[BR]]
Lettura della prima parte dell'articolo su MEW (Ghn01).

== 3 Luglio 2007 ==
__1130-1216__[[BR]]
Formalizzazione e digitalizzazione degli appunti cartacei presi negli ultimi giorni (con rilettura di alcuni passaggi chiave di Ghn00).

__1216-1220__[[BR]]
Aggiunta di due macro in fondo alla presente.

__1220-1255__[[BR]]
Aggiornamento riguardo i ticket in consegna:[[BR]]
#3: Gli ''wireless tools'' offrono tre informazioni legate alla qualità della connessione: qualità, livello del segnale, livello del rumore. Dalla differenza degli ultimi due è possibile ricavare il famoso SNR (''Signal to Noise Ratio''), mentre il primo esprime due valori (graficamente separati da una barra nel caso si interroghi `iwlist`): l'RSSI e il rumore di fondo (''noise floor'').[[BR]]
#2: Mentre il significato di RSN mi appare piuttosto chiaro, RSSI rimane piuttosto fumoso. Quest'ultimo viene inoltre segnalato dal driver del dispositivo con valori in scale diverse a seconda del produttore (così riporta  [http://en.wikipedia.org/wiki/RSSI wikipedia:RSSI] ma anche Ghn00).

== 4 Luglio 2007 ==
__1530-1600__[[BR]]
con gnappo: punto della situazione intorno alla calcolabilità del ''bitrate'' della stazione associanda in maniera portabile e quantomeno accurata.

__1630-1635__[[BR]]
Aggiornamento del diario.

__1700-1720__[[BR]]
Con gnappo: altri chiarimenti per migliorare la padronanza degli obiettivi da raggiungere.

__1720-1900__[[BR]]
Riflessioni ad alto livello[[BR]]
Anzitutto credo che la stima della ''bandwidth'' ottenibile che intendiamo effettuare non possa limitarsi al livello MAC proprio di 802.11 come si era esplicitato giorni fa. Il motivo è duplice: da un lato condurrebbe ad errori poiché nei calcoli che prospettiamo di fare si sta tenendo conto di fattori propri del protocollo, da un altro questo non sembra condurre molto lontano dal datarate nominale del collegamento. Questa considerazione conduce alla serie di fattori (in buona parte già affrontati assieme a gnappo in maniera meno organica) che intervengono nel generare il carico addizionale implicabile al protocollo. Creazione di una nuova mappa mentale contenente una parziale formalizzazione di tutti gli ''overhead'' dovuti allo strato MAC, sperabilemente utile alle successive indagini.

__1853-1900__[[BR]]
Aggiornamento del diario.
== 5 Luglio 2007 ==

__1300-1715__[[BR]]
Gnappo

== 6 Luglio 2007 ==

__1150-1400__, __1630-1830__[[BR]]
Gnappo

== 7 Luglio 2007 ==
__1048-1345__[[BR]]
Gnappo

== 9 Luglio 2007 ==
__1130-1430__, __1620-1830__[[BR]]
Gnappo

__2000-2015__[[BR]]
Approfondimenti e riflessioni.

== 10 Luglio 2007 ==
__1025-1035__[[BR]]
Approfondimenti e riflessioni.

__1120-1400__[[BR]]
Gnappo

__1735-1845__ [[BR]]
Gnappo

== 11 Luglio 2007 ==

__1745-1900__[[BR]]
Gnappo
Revisione documentazione sul supporto al roaming (Roma e Zeratul)

== 12 Luglio 2007 ==

__1130-1300__[[BR]]
Incontro con l'intero team.

__1430-1640__[[BR]]
Gnappo

== 13 Luglio 2007 ==
__????-1645__[[BR]]
Gnappo

== 14 Luglio 2007 ==
__1058-1120__[[BR]]
Gnappo

== 16 Luglio 2007 ==

__1258-????__
Con gnappo

== 17 Luglio 2007 ==

__1235-1605__[[BR]]
Con gnappo

__1645-1732__[[BR]]
Con gnappo: impostazione del documento e del pacchetto `algorithmic`o

__1732-1900__[[BR]]
Con gnappo.

== 19 Luglio 2007 ==
__1120-1400__ __1440-????__[[BR]]
Con gnappo: affrettata conclusione dei lavori in vista della pausa estiva.

== 24 Luglio ==
__1322-1542__[[BR]]
Approfondimenti e chiarimenti sparsi nella mappa mentale, nell'ottica di produrre un html decente da inviare al Prof. Ghini.[[BR]]
Invio dell'ultima versione della mappa al deposito SVN.[[BR]]
Aggiornamento (finalmente!) del diario.

== 5 Ottobre ==
__1715-1945__[[BR]]
Incontro con il Prof. Ghini: punto della situazione e sviluppi futuri prima della conclusione.

== 9 Ottobre ==
__1445-1710__[[BR]]
Videoconferenza con gnappo (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.

__1710-1740__[[BR]]
Formattazione in LaTeX di un paio di formule.[[BR]]
Aggiornamento deposito SVN.[[BR]]
Aggiornamento Diario.[[BR]]

== 10 Ottobre ==

__1500-1740__[[BR]]
Incontro con gnappo.[[BR]]
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.

__1740-1745__[[BR]]
Aggiornamento del deposito subversion.

== 11 Ottobre ==
__1130-1330__ __1345-1430__[[BR]]
Lavoro con gnappo.[[BR]]
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).

__1500-1530__[[BR]]
Trascrizione di qualche appunto nel diario e successivo aggiornamento.

__1530-1550__[[BR]]
Aggiornamento del deposito subversion: [7] e [8].

----

= Collegamenti =

== Articoli ==
 * 00 [http://www.usenix.org/events/imc05/tech/full_papers/vasudevan/vasudevan.pdf Facilitating Access Point Selection in IEEE 802.11 Wireless Networks]
 * 01 [http://www.cs.unt.edu/~rakl/AP05.pdf Optimal Access Point Selection and Traffic Allocation in IEEE 802.11 Networks]
 * 02 [http://www.imconf.net/imc-2006/papers/p25-sundaresan.pdf The Need for Cross-Layer Information in Access Point Selection Algorithms]
 * 03 [http://www.cs.umd.edu/users/slee/pubs/cs-tr-4504.pdf The Case for a Multi-hop Wireless Local Area Network]
 * 04 [http://www.caida.org/workshops/isma/0312/abstracts/shah.pdf Available Bandwidth Estimation in IEEE 802.11-based Wireless Networks]
 * 05 [http://doi.acm.org/10.1145/1143549.1143694 A novel association algorithm for congestion relief in IEEE 802.11 WLANs]
 * 06 [http://doi.acm.org/10.1145/1023720.1023751 Fairness and Load Balancing in Wireless LANs Using Association Control]
 * 07 [http://ece.iisc.ernet.in/~anurag/papers/anurag/kumar-kumar05association.pdf Optimal Association of Stations and APs in an IEEE 802.11 WLAN]
 * 08 [http://www2.tku.edu.tw/~tkjse/2-1/2-1-6.pdf Dynamic Load Balance Algorithm (DLBA) for IEEE 802.11 Wireless LAN]
 * 09 [http://ieeexplore.ieee.org/iel5/9179/29132/01313270.pdf?tp=&isnumber=&arnumber=1313270 Load Balancing in Overlapping Wireless LAN Cells]
 * 10 [http://dcg.ethz.ch/members/pascal/refs/mac_2000_bianchi.pdf Performance Analysis of the IEEE 802.11 Distributed Coordination Function]
 * 11 [http://ieeexplore.ieee.org/iel5/7828/21515/00996984.pdf Improving Load Balancing mechanisms in Wireless Packet Networks]
 * 12 [http://www.ieee-infocom.org/2003/papers/21_02.PDF Kalman Filter Estimation of the Number of Competing Terminals in an IEEE 802.11 network]

== Documenti da Ghini ==
 * 00 Benatti, Borsari, ''Politiche di selezione di Access Point da parte del client mobile''
 * 01 V. Ghini, G. Lodi, F. Panzieri, ''Mobile E-Witness''

== Vari ==
 * [http://portal.acm.org/portal.cfm?coll=GUIDE&dl=GUIDE&CFID=25283952&CFTOKEN=64874456 Portale ACM]
 * [http://portal.acm.org/citation.cfm?id=1024744 Network Selection and Discovery of Service Information in Public WLAN Hotspots]: roaming

----
= Ticket =

== Assegnati ==
[[TicketQuery(status=assigned,order=priority,owner=soujak)]]

== Nuovi, della milestone:"Rilevamento del carico" ==
[[TicketQuery(status=new|reopened,milestone=Rilevamento+del+carico,order=priority,group=type)]]