| 24 | | Ho letto qualcosa su come si instaura una connessione tra una client e un AP:vi è praticamente una serie di richieste tra il client e l'AP affinchè la connessione venga instaurata;nota importante è che il client prima di collegarsi all'AP deve autenticarsi sull'AP stesso.Una volta fatto cio' AP manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova connessione.Naturalmente vi sono già delle primitive implementate atte a svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che per le reinstaurazione). |
| 25 | | Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro (es che fece anche il seminarista se non ricordo male) e per fare ciò si inviano delle simpatiche "pancette" con dentro il proprio timestamp;a monte comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda pancette ai client conessi a lui;quindi vi è una doppia sincronizzazione:una tra AP e client e una tra client e client.(cap 11 del documento ieee 802.11) |
| | 24 | Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi è praticamente una serie di richieste tra il client e l'AP affinchè la connessione venga instaurata; nota importante è che il client prima di collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova connessione. Naturalmente vi sono già delle primitive implementate atte a svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che per le reinstaurazione). |
| | 25 | Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro (es che fece anche il seminarista se non ricordo male) e per fare ciò si inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda pancette ai client conessi a lui; quindi vi è una doppia sincronizzazione: una tra AP e client e una tra client e client (cap 11 del documento ieee 802.11). |
| | 26 | |
| | 27 | ---- |
| | 28 | ||''La seguente introduzione intende descrivere in maniera sintetica quanto detto, discusso, analizzato fino ad ora.''|| |
| | 29 | |
| | 30 | L'avvio e l'approccio di questo studio dipende in maniera forte dagli aspetti |
| | 31 | architetturali del protocollo 802.11. La questione non entra in gioco soltanto |
| | 32 | nel definire una bozza di implementazione, ma, ancor prima, nel comprendere |
| | 33 | quali siano le strade da intraprendere per una realizzazione a livello mentale. |
| | 34 | |
| | 35 | Dalle conoscenze iniziali dell'intero gruppo di lavoro e' risultato evidente |
| | 36 | che la ricerca non poteva perseguire una soluzione che lavorasse al di sopra di |
| | 37 | tutto lo stack IEEE 802.11. In questo tipo di scenario si renderebbe necessaria |
| | 38 | la ri-associazione ad ogni cambio di canale, una operazione che richiede tempi |
| | 39 | lunghi (o biblici, e' da considerare anche l'autenticazione), se comparati ai |
| | 40 | tempi di trasmissione dei dati. |
| | 41 | |
| | 42 | Se come riferimento si prende lo stack ISO/OSI, da quanto detto risulta |
| | 43 | evidente che la ricerca sara' orientata al di sotto del livello "network". |
| | 44 | |
| | 45 | Sono dunque da approfondire: |
| | 46 | * interfaccia offerta dal livello MAC e da quello PHY; |
| | 47 | * quanto e' dipendente il livello PHY dall'hardware sottostante? |
| | 48 | |
| | 49 | ||''Cio' che segue e' una traduzione-sintesi-scrematura delle porzioni da me analizzate del documento IEEE 802.11''|| |
| | 50 | |
| | 51 | === Gestione degli strati === |
| | 52 | I due livelli (data link e fisico) su cui lo standard e' definito possiedono |
| | 53 | un insieme di operazioni primitive proprie, ma lungi dal poter essere |
| | 54 | considerate vere e proprie interfacce: si tratta delle "MAC layer management |
| | 55 | entities" (MLME) e delle "PHY layer management entities" (PLME). |
| | 56 | E' assai importante notare che lo strato MAC non oscura il sottostante PHY, ma |
| | 57 | permette alla "station management entity" (SME) di interagire direttamente con |
| | 58 | esso. Le varie entita' hanno la possibilita' di comunicare fra loro secondo le |
| | 59 | specifiche dello standard, attraverso i SAP (service access point). Tale |
| | 60 | concetto intende aggregare l'insieme di chiamate che una determinata entita' |
| | 61 | espone alle altre per realizzare forme di comunicazione o invocazione. |
| | 62 | |
| | 63 | === Primitive di gestione generica === |
| | 64 | Get e set sugli attributi dello specifico strato |
| | 65 | |
| | 66 | ==== Interfaccia del MLME SAP ==== |
| | 67 | * POWERMGT: richieste al modulo che gestisce il risparmio energetico |
| | 68 | * SCAN: scansione della rete alla ricerca di BSS disponibili |
| | 69 | * JOIN: sincronizzazione con un BSS |
| | 70 | * AUTHENTICATE: autenticazione con un BSS |
| | 71 | * DEAUTHENTICATE: deautenticazione con un BSS |
| | 72 | * ASSOCIATE: associazione fra una STA e un AP |
| | 73 | * REASSOCIATE: associazione fra una STA e un altro AP |
| | 74 | * DEASSOCIATE: disassociazione fra una STA e un AP |
| | 75 | * RESET: azzeramento |
| | 76 | * START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete |
| | 77 | ad-hoc) |
| | 78 | |
| | 79 | ==== Interfaccia del PLME SAP ==== |
| | 80 | ||''La sezione e' volutamente vuota perche' da completare''|| |
