Changes between Version 15 and Version 16 of Protocollo

Timestamp:

Nov 9, 2006, 2:28:25 PM (19 years ago)

Author:

soujak

Comment:

Piccole correzioni tipografiche e migliorie wikificanti. Qualche commento su punti poco chiari.

Protocollo

@@ -121 +121 @@
 qui.'',,[[BR]]
 {{{
-Il periodo di inattivita'  che le STA si autoimpongono e' detto CW (''contention
+Il periodo di inattivita' che le STA si autoimpongono e' detto CW (''contention
 window'') e viene ripetuto ogni volta che si presenti una collisione. Viene
 inoltre incrementato a fronte di ogni collisione con andamento esponenziale (per
@@ -395 +395 @@
  1. si sono riuniti i [http://en.wikipedia.org/wiki/Chip_rate "chips"] 
     in gruppi da 8 formando cosi chiavi a codice complementario 
-    (8-chip complementary code keying, aka CCK) che vengono spediti alla stessa 
-    frequenza del DSSS (11 MHz), ottimizzando cosi l'uso della banda del canale;
- 2. sono state aggiunte delle funzionalita'  opzionali per aumentare il
+    (''8-chip complementary code keying'' a.k.a. CCK) che vengono spediti alla
+    stessa frequenza del DSSS (11 MHz), ottimizzando cosi l'uso della banda del
+    canale;
+ 2. sono state aggiunte delle funzionalita' opzionali per aumentare il
     bandwith, che sono utilizzabili solo se l'hardware e' abbastanza recente
     da supportarle. [[BR]]
     Le funzionalita' sono le seguenti:
-    * sostituzione del CCK con il packet binary convolutional coding
+    * sostituzione del CCK con il ''packet binary convolutional coding''
       (HR/DSSS/PBCC);
     * HR/DSSS/short, ovvero possibilita'  di ridurre il preambolo PLCP
@@ -407 +408 @@
       pero' la possibilita'  di coesistenza con il DSSS a sole alcune
       particolari circostanze;
-    * inserimento del Channel Agility, ovvero una particolare implementazione
-      che consente di superare diversi problemi dovuti all'assegnamento di un
-      canale statico, senza dover aggiungere alla totale implementazione il
-      costo di questa funzionalita' .[[BR]]
+    * inserimento del ''Channel Agility'', ovvero una particolare
+      implementazione che consente di superare diversi problemi dovuti
+      all'assegnamento di un canale statico, senza dover aggiungere alla totale
+      implementazione il costo di questa funzionalita'. [[BR]]
 
 Purtroppo l'IEEE non ha concesso le specifiche inerenti all'evoluzione della
@@ -417 +418 @@
 circa 54 Mbps.[[BR]]
 Parlandone con il Dott. Bononi, si e' arrivati ad ipotizzare che lo sviluppo
-sempre + veloce della tecnologia abbia portato ad un'alta precisione e
-sensibilita'  di ricezione/trasmissione che quindi, ha portato ad un'aumento dei
-simboli (in modulazione un simbolo e' un particolare segnale che identifica una
-serie di bit) e ad una diminuzione dei bit adibiti al controllo di errori, cosi
-aumentandone di molto il bit rate potenziale.[[BR]]
+sempre piu' veloce della tecnologia abbia portato ad un'alta precisione e
+sensibilita'  di ricezione/trasmissione che abbia sua volta portato ad
+un'aumento dei simboli (in modulazione un simbolo e' un particolare segnale che
+identifica una serie di bit) e ad una diminuzione dei bit adibiti al controllo
+di errori, cosi aumentandone di molto il bit rate potenziale.[[BR]]
 Rimaniamo comunque nella ricerca di specifiche piu' recentemente rilasciate,
 lasciando quest'ultima parte di paragrafo come "prossima ad essere aggiornata".
@@ -428 +429 @@
 
 Uno degli aspetti piu' importanti, per quanto riguarda la connessione di piu'
-hosts ad una rete wireless, e' sicuramente il meccanismo di sincronizzazione, il
+host ad una rete wireless, e' sicuramente il meccanismo di sincronizzazione, il
 quale deve esistere per permettere la comunicazione all'interno della rete. Per
-permettere cio' ogni nodo ha al suo interno un TSF (Timing Synchronization
-Function) che funge da orologio per tutti i nodi. La sincronizzazione e'
+permettere cio' ogni nodo ha al suo interno un TSF (''Timing Synchronization
+Function'') che funge da orologio per tutti i nodi. La sincronizzazione e'
 presente sia nei BSS che nei IBSS e avviene in maniere differenti.
 
 In un BSS la sincronizzazione viene mantenuta dall'AP, che inizializza il suo
-TSF interno e invia beacons a tutti i nodi della rete con all'interno il proprio
-timer. Ogni nodo che riceve il beacon deve sincronizzare il proprio timer con il
-valore del timestamp ricevuto.
+TSF interno e invia ''beacons'' a tutti i nodi della rete con all'interno il
+proprio timer. Ogni nodo che riceve il beacon deve sincronizzare il proprio
+timer con il valore del timestamp ricevuto.
 
 In un IBSS invece ogni nodo partecipa allla sincronizzazione mediante l'utilizzo
@@ -486 +487 @@
 affermativo l'AP inviera' una risposta (positiva o negativa) alla stazione.
 
-=== Power Management ===
+=== ''Power Management'' ===
 ,,20061108-1512 Roma,,[[BR]]
-Le stazione possono cambiare il proprio power management, informando 
+Le stazione possono cambiare il proprio power management, informando
 preventivamente l'AP al quale sono associate, accondando la richiesta di cambio
-al campo Frame Control del frame inviato all'AP.
-L'AP deve tener traccia di tutte le stazione che operano in modalita' power
-save
-in quanto la trasmisisone dei dati a tali stazioni deve avvenire in modo 
-differente rispetto alle stazioni che non operano in tale modalita'  ;infatti un
-AP non puo' trasmettere i dati in maniera arbitraria alle stazioni in modalita' 
-power save ma deve bufferizzarli e trasmetterli in periodi precisi.
-Tutte le stazioni che ricevono dati bufferizzati dall'AP sono riunite nel 
-TIM (Traffic Indication Map) il quale rappresenta un campo dei vari beacon 
-generati dall'AP stesso.Ogni stazione per sapere se i dati ricevuti sono stati
-bufferizzati per lei deve ricevere e interpretare il TIM associato al beacon (
-per fare cio' ogni stazione si mette peridicamente in ascolto di beacon,e quindi
-in ascolto per ricevere eventuali TIM,secondo opportune funzioni).
-In un BSS ogni stazione (in modalita' power save) per sapere se dei dati sono
-stati correttamente bufferizzati invia un PS-Poll frame all'AP, il quale 
-rispondera' o inviando direttamente i dati bufferizzati o acknowleggiando la
-richiesta e inviando i dati successivamente.
+al campo Frame Control del frame inviato all'AP. L'AP deve tener traccia di
+tutte le stazione che operano in modalita' ''power save'' in quanto la
+trasmissione dei dati a tali stazioni deve avvenire in modo differente rispetto
+alle stazioni che non operano in tale modalita'; infatti un AP non puo'
+trasmettere i dati in maniera arbitraria alle stazioni in modalita' ''power
+save'' ma deve bufferizzarli per poi trasmetterli in momenti precisi. Tutte le
+stazioni che ricevono dati bufferizzati dall'AP sono riunite nel TIM (''Traffic
+Indication Map'') il quale rappresenta un campo dei vari ''beacon'' generati
+dall'AP stesso.
+,,20061109-1424 SoujaK: ''Il pezzo seguente e' da chiarire'',,[[BR]]
+Ogni stazione per sapere se i dati ricevuti sono stati bufferizzati per
+lei deve ricevere e interpretare il TIM associato al beacon ( per fare cio' ogni
+stazione si mette peridicamente in ascolto di beacon, e quindi in ascolto per
+ricevere eventuali TIM, secondo opportune funzioni). In un BSS ogni stazione (in
+modalita' ''power save'') per sapere se dei dati sono stati correttamente
+bufferizzati invia un frame di tipo PS-Poll all'AP, il quale rispondera' o
+inviando direttamente i dati bufferizzati o acknowledgiando la richiesta e
+inviando i dati successivamente.
 
 Ogni stazione puo' lavorare in due modalita':
- * awake 
- * doze
-
-Nella modalita' awake la stazione lavora a piena potenza e puo' ricevere frames
-in qualsiasi momento; e' detta anche modalita' attiva. Nella modalita' doze la
-stazione lavora in power save e riceve frames attraverso il meccanismo sopra
-descritto. Naturalmente le stazioni possono passare da una modalita' all'altra,
-ma possono farlo solo alla fine di uno scambio di dati informando l'AP del
-cambio.
-
-=== Power Management in un IBSS ===
+ * ''awake''
+ * ''doze''
+
+Nella modalita' ''awake'' la stazione lavora a piena potenza e puo' ricevere
+frame in qualsiasi momento; e' detta anche modalita' attiva. Nella modalita'
+''doze'' la stazione lavora in ''power save'' e riceve frame attraverso il
+meccanismo sopra descritto. Naturalmente le stazioni possono passare da una
+modalita' all'altra, ma possono farlo solo alla fine di uno scambio di dati
+informando l'AP del cambio.
+
+=== ''Power Management'' in un IBSS ===
 
 In un IBSS le stazioni devono essere tutte sincronizzate al fine di poter
@@ -526 +528 @@
 affinche' l'operazione si possa effettuare. Tale annuncio e' dato tramite
 l'invio di un ATIM (Ad hoc TIM) quando tutte le stazioni dell' IBSS sono in
-modalita' awake. Quando i dati devono essere transmessi la stazione trasmittente
+modalita' ''awake''. Quando i dati devono essere trasmessi la stazione
+trasmittente
 invia prima un frame ATIM nel ATIM Window (che e' un periodo nel quale vengono
-inviati solo frame ATIM o beacon) e aspetta l'ack di quel frame; se cio' non
-avviene la stazione attiva la procedura di ritrassmisione dell'ATIM. Una
-stazione che acknowleggia l'ATIM durante l'ATIM Window deve rimanere nella
-modalita' awake e aspettare l'annuncio.Una volta che avviane l'ack ed e' passato
-l'ATIM Window,i dati possono essere trasmessi dalla stazione in modalita' power
-save.
+inviati solo frame ATIM o beacon) e aspetta l'ACK di quel frame; se cio' non
+avviene la stazione attiva la procedura di ritrasmissione dell'ATIM. Una
+stazione che acknowledgi l'ATIM durante l'ATIM Window deve rimanere nella
+modalita' ''awake'' e aspettare l'annuncio.
+,,20061109-1424 SoujaK: ''Anche il seguente periodo e' abbastanza
+oscuro'',,[[BR]]
+Una volta che avviane l'ACK ed e' passato l'ATIM Window, i dati possono essere
+trasmessi dalla stazione in modalita' ''power save''.
 
 == Appunti vari ==