| 342 | | ,,gnappo: ''chiarire meglio tutte le primitive con il loro significato. Sara' |
| 343 | | utile nella comprensione delle specifiche del livello PHY (ad esempio DSSS).'',, |
| | 342 | ,,20061211-2200 gnappo,,[[BR]] |
| | 343 | L'unica primitiva per il supporto dell'interazione ''peer-to-peer'' e' |
| | 344 | PHY-DATA alla quale sono associati i seguenti significati: |
| | 345 | * PHY-DATA.request(DATA): trasferisce un ottetto di dati alla ''PHY |
| | 346 | entity'' successivamente ad una confermata richiesta di trasmissione |
| | 347 | (PHY-TXSTART.confirm). Quando la ''PHY entity'' ricevera' l'ottetto di |
| | 348 | dati indichera' l'avvenuta ricezione attraverso la primitiva |
| | 349 | PHY-DATA.confirm. |
| | 350 | * PHY-DATA.indication: trasferisce un ottetto di dati dal livello fisico |
| | 351 | al livello MAC. |
| | 352 | * PHY-DATA.confirm: come gia' accennato, viene sollevata dalla ''PHY |
| | 353 | entity'' per confermare l'avvenuta ricezione dei dati dalla ''MAC entity''. |
| | 354 | |
| | 355 | Le altre primitive sono: |
| | 356 | * PHY-TXSTART.request(TXVECTOR): permette al sottolivello MAC di |
| | 357 | richiedere all'entita' fisica di cominciare la trasmissione di un MPDU. |
| | 358 | Come dato in ingresso, prende un vettore contenente parametri sia del |
| | 359 | sottolivello PLCP che di PHY. |
| | 360 | * PHY-TXSTART.confirm: viene sollevata dal sottolivello PHY per |
| | 361 | confermare, alla ''MAC entity'', l'avvenuto inizio di trasmissione. In |
| | 362 | questo modo, l'entita' fisica, si dichiara disponibile a ricevere dati |
| | 363 | attraverso PHY-DATA.request(DATA). |
| | 364 | * PHY-TXEND.request: e' invocata dalla ''MAC entity'' per forzare il |
| | 365 | completamento della trasmissione del MPDU corrente. Viene generata |
| | 366 | conseguentemente all'ultima chiamata PHY-DATA.confirm per l'MPDU |
| | 367 | corrente. |
| | 368 | * PHY-TXEND.confirm: utilizzata dal sottolivello fisico per notificare |
| | 369 | all'entita' MAC il completamento della trasmissione. Il recepimento di questa |
| | 370 | primitiva da parte della ''MAC entity'' fornisce il riferimento temporale per |
| | 371 | il protocollo di ''backoff''. |
| | 372 | * PHY-CCARESET.request: viene richiesta dalla ''MAC entity'' per ottenere |
| | 373 | un reset dell'automa a stati finiti per il ''Clear Channel Assessment'' |
| | 374 | (valutazione del canale libero). E' generata dalla ''MAC entity'' allo |
| | 375 | scadere del ''NAV timer''. |
| | 376 | * PHY-CCAREST.confirm: sollevata dall'entita' fisica per confermare |
| | 377 | l'avvenuto ''reset'' dell'automa di cui al punto precedente. |
| | 378 | * PHY-CCAREST.indication: questa primitiva ritorna, all'entita' MAC, lo |
| | 379 | stato del canale (''idle'' oppure ''busy''). Viene generata ogni qualvolta |
| | 380 | si ha una transizione del canale da libero a occupato e viceversa. |
| | 381 | * PHY-RXSTART.indication: sollevata dal livello fisico per informare il |
| | 382 | livello MAC che e' stato ricevuto un SFD e un'intestazione PLCP valida (e |
| | 383 | che quindi avra' inizio la ricezione di un ''frame''). |
| | 384 | * PHY-RXEND.indication: grazie a questa primitiva l'entita' fisica |
| | 385 | comunica all'entita' MAC la fine della ricezione di un MPDU ed indica |
| | 386 | eventuali errori occorsi. |