| | 275 | === DSSS === |
| | 276 | 20061021-???? gnappo [[BR]] |
| | 277 | DSSS (Direct Sequence Spread Spectrum) e' un'altra specifica del livello fisico |
| | 278 | che permette di raggiungere in linea teorica un capacita' trasmissiva pari a |
| | 279 | 11Mbit/s (802.11b). Attraverso opportune tecniche e' possibile fornire bitrate |
| | 280 | inferiori (in tal modo si ottiene compatibilita' all'indietro). |
| | 281 | Come per FHSS l'importante e' garantire l'indipendenza di MAC rispetto ad una |
| | 282 | specifica implementazione di PHY. Anche in questa occasione, avremo |
| | 283 | opportune funzioni di convergenza atte a garantirci questa proprieta'. |
| | 284 | Il PPDU e' differente (e arricchito) rispetto a quello definito per FHSS (nel |
| | 285 | seguito troverete qualche dettaglio). Interessante osservare che il preambolo e |
| | 286 | l'header del frame sono trasmessi, diversamente dal resto, ad un 1Mbit/s per |
| | 287 | assicurarsi che l'interlocutore capisca effettivamente questa parte essenziale |
| | 288 | della comunicazione. L'effettivo invio del payload (MPDU) potra' essere |
| | 289 | compiuto con modulazioni diverse opportunamente specificate nell'header (campo |
| | 290 | SIGNAL). |
| | 291 | |
| | 292 | |
| | 293 | ==== Algoritmo di trasmissione ==== |
| | 294 | 20061021-???? gnappo [[BR]] |
| | 295 | Per trasmettere i dati, PHY-TXSTART.request dev'essere abilitata per portare PHY |
| | 296 | nello stato di trasmettitore (precedentemente su ricevitore). Il canale su cui |
| | 297 | trasmettere e' regolato via PLME. Se il canale risulta libero (PHY-CCA.indicate) |
| | 298 | allora MAC puo' procedere all'effettivo invio invocando la primitiva |
| | 299 | PHY-TXSTART.request (PHY-SAP) passando i parametri necessari (DATARATE, |
| | 300 | TX_ANTENNA, TXPWR_LEVEL). Una volta terminato l'invio del preambolo, attraverso |
| | 301 | una serie di chiamate PHY-DATA.request(DATA) verrano scambiati i dati tra MAC e |
| | 302 | PHY. Al termine della trasmissione l'entita' fisica ritornera' allo stato di |
| | 303 | ricevitore. |
| | 304 | |
| | 305 | |
| | 306 | ==== Algoritmo di ricezione ==== |
| | 307 | 20061021-???? gnappo [[BR]] |
| | 308 | Per quanto riguarda la ricezione e' necessario che l'entita' fisica sia nello |
| | 309 | stato di ricevitore (quindi PHY-TXSTART disabilitato). Attraverso la PLME e' |
| | 310 | possibile scegliere il canale su cui ascoltare ed il metodo di CCA (Clear |
| | 311 | Channel Assessment). Altri parametri (come per la trasmissione) sono passati |
| | 312 | attraverso PHY-SAP. |
| | 313 | Non appena il dispositivo ha rilevato attivita' sul canale sul quale e' in |
| | 314 | ascolto, PHY invoca la primitiva PHY-CCA.indicate con la quale informa MAC che |
| | 315 | il canale e' BUSY. Dopodiche' PHY va alla ricerca di un delimitatore di inizio |
| | 316 | frame e procede alla lettura dell'header. Se la lettura va a buon fine (i.e. |
| | 317 | formato riconosciuto, niente errori su CRC) allora viene chiamata la primitiva |
| | 318 | PHY-RXSTART.indicate per mettere a conoscenza di MAC di informazioni contenute |
| | 319 | nell'header (i.e. campo SIGNAL, lunghezza del MPDU, RX_ANTENNA, RSSI, SQ, |
| | 320 | campo SERVICE). I dati successivamente ricevuti saranno assemblati e |
| | 321 | presentati a MAC attraverso la primitiva PHY-DATA.indicate(DATA). Al termine |
| | 322 | dell'intera ricezione lo stato del ricevitore ritornera' IDLE e la primitiva |
| | 323 | PHY-RXEND.indicate(NoError) sara' sollevata. |
| | 324 | Se la ricezione non andasse a buon fine, PHY informerebbe MAC attraverso la |
| | 325 | primitiva PHY-RXEND.indicate della causa dell'errore (e.g. !CarrierLost). |
| | 326 | |
| | 327 | ==== Note ==== |
| | 328 | Per quanto riguarda questioni di tempistiche ed altre informazioni dettagliate |
| | 329 | (MIB attributes) rimando alle specifiche ieee, capitolo 15. |
| | 330 | |