Changes between Version 18 and Version 19 of Diario/Gnappo

Timestamp:

Jul 3, 2007, 10:11:30 AM (18 years ago)

Author:

gnappo

Comment:

Aggiornamento.

Diario/Gnappo

@@ -545 +545 @@
 suo senso piu' ampio.
 
+== 02 Luglio 2007 ==
+
+1020 - 1305 (2.75h)
+
+Aggiornamento del diario.
+
+Approfondimento di #1. [[BR]]
+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) [[BR]]
+1730 - 1835 (1.08h) [[BR]]
+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. [[BR]]
+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. [[BR]]
+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). [[BR]] 
+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. [[BR]]
+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. [[BR]]
+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).
+
 
 == Documenti ==