Changes between Version 5 and Version 6 of Diario/Gnappo

Timestamp:

Jun 14, 2007, 12:46:07 PM (17 years ago)

Author:

gnappo

Comment:

Aggiornamento del diario.

Diario/Gnappo

@@ -154 +154 @@
 
 Formattazione del diario.
+
+= 13 Giugno 2007 =
+
+0940 - 1140 (2h)
+
+Upload del diario e breve formattazione.
+
+Prosecuzione dello studio del paper 12: [[BR]]
+[http://ieeexplore.ieee.org/iel5/9904/31476/01467803.pdf "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
+
+Punto della situazione con SoujaK.
+
+Prosecuzione dello studio del paper 12: [[BR]]
+[http://ieeexplore.ieee.org/iel5/9904/31476/01467803.pdf "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.
+
+
+[http://dcg.ethz.ch/members/pascal/refs/mac_2000_bianchi.pdf "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). [[BR]]
+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: [[BR]]
+[http://web.it.kth.se/~hvelayos/papers/TRITA-IMIT-LCN%20R%2003-02%20Handover%20in%20IEEE%20802.pdf "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.